OpenAFS/ko

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page OpenAFS and the translation is 100% complete.

Other languages:
English • ‎français • ‎русский • ‎日本語 • ‎한국어

이 안내서는 젠투 리눅스에서 OpenAFS 서버 및 클라이언트를 설치하는 방법을 보여드립니다.

간단히 살펴보기

이 문서 정보

이 문서는 젠투 리눅스에 OpenAFS 서버를 설치하는데 필요한 단계 정보를 제공합니다. 이 문서의 각 부분에는 AFS FAQ 및 IBM의 AFS 간편 초보자 안내서로부터 내용을 가져왔습니다. 글쎄요. 바퀴를 굳이 또 찍을 이유가 없죠 :)

AFS란게 뭔가요?

AFS는 로컬, 광역 네트워크를 통해 파일 시스템 자원을 효율적으로 공유하는 호스트(클라이언트 및 서버)간 협업을 가능케 하는 분산 파일 시스템입니다. 클라이언트는 주로 사용하는 객체(파일)을 빠르게 접근할 수 있도록 보관하고 있습니다.

AFS는 본래 카네기 멜론 대학 정보 기술 센터에서 개발한 "앤드류 파일 시스템" 분산 파일 시스템을 기반으로 합니다. "앤드류"는 카네기 멜론 대학 의 연구 프로젝트 이름이었으며 대학교 설립자를 기리는 의미를 내포합니다. 트랜스아크를 설립하고 AFS를 상용화 하고 나서는 AFS가 앤드류 연구 프로젝트를 떠났고 제품 수준의 품질을 지닌 파일 시스템으로서 지원을 받았기에 "앤드류"라는 이름을 버렸습니다. 그러나 /afs 는 파일 시스템의 루트이며 셀이라는 개념을 가지고 있고, 이 셀은 파일 시스템 상에 여러 개가 존재했습니다. 그 때에, 파일 시스템의 루트를 바꾸는 일은 결코 간단한 일이 아니었습니다. 따라서, 파일 시스템 이름을 바꾸는데 있어 이전의 AFS 사이트를 유지하기 위해 AFS는 이름으로 그대로 남았으며 파일 시스템 루트가 되었습니다.

AFS 셀은 뭔가요?

AFS 셀은 관리 관점상 하나의 집단으로 묶은 서버의 모음이며, 단일 복합 파일 시스템으로 보입니다. 보통 AFS 셀은 동일한 인터넷 도메인(예: gentoo.org)을 활용하는 호스트의 모음이며, 사용자는 사용자가 접속할 셀의 서버에서 정보와 파일을 요청하는 AFS 클라이언트 워크스테이션에 로그인합니다. 사용자는 찾아볼 어떤 파일이 어떤 서버에 있는지 알지 못합니다. 게다가 서버가 다른 방에 있겠다 하더라도 모든 볼륨을 복제하고 사용자에게 별 다른 내용을 알려주지 않고 다른 서버로 옮기기 때문에 서버가 어디있는지 또한 알지 못합니다. 파일은 언제든 접근할 수 있습니다. 스테로이드 시스템 상의 NFS랑 비슷해보이는군요 :)

AFS를 쓰면 뭐가 좋아요?

AFS는 캐싱 처리 요소(클라이언트, 보통 100M에서 1GB), 보안 기능(커베로스 5 기반, 접근 관리 목록), 주소 관리 단순화(오직 하나의 파일 시스템만 보유), 확장성(필요한만큼 셀에 서버를 더 추가함), 통신 프로토콜 의 주요 기능을 보유하고 있습니다.

더 많은 내용은 어디서 찾아볼 수 있나요?

AFS FAQ를 읽어보십시오.

www.openafs.org의 OpenAFS 메인 페이지

AFS는 지금은 IBM이 소유한 트랜스아크에서 개발했습니다. 2005년 4월부터 IBM 제품 카탈로그에서 없어졌습니다. IBM은 AFS 제품의 소스 코드 브랜치를 분리했고, 2000년에 커뮤니티 개발용과 관리용 두가지 용도로 소스코드 복제본을 만들었습니다. 그들은 OpenAFS 릴리즈라 불렀습니다.

문제를 어떻게 디버깅하죠?

OpenAFS에는 대단한 기록 설비를 갖추고 있습니다. 그러나 기본적으로 여러분의 시스템에 있는 로깅 체계로 기록하기보단 자체 기록에 바로 남겨둡니다. 서버 로그를 시스템 로거에서 처리하도록 하려면 -syslog 옵션을 모든 bos 명령에서 활용하십시오.

이전 버전으로부터 업그레이드

도입부

이 부분에서는 기존의 OpenAFS를 OpenAFS 1.4.0 이상으로 업그레이드하는 과정을 도와드립니다(또는 1.2.13부터 시작하는 1.2.x가 됩니다만, 후자는 대부분 사람들이 linux-2.6 지원, 대용량 파일 지원, 버그 수정판을 원하기 때문에 따로 다루지 않겠습니다).

OpenAFS 1.4 버전을 아얘 처음부터 설치한다면 이 부분을 안전하게 건너뛸 수 있습니다. 허나, 이전 버전에서 업그레이드한다면, 다음 부분의 안내서를 따라가시는게 좋습니다. 이빌드의 트랜지션 스크립트는 간단한 업그레이드 및 재시작을 도와주도록 설계했습니다. (보안상 이유로) 설정 파일과 이전 위치의 시작 스크립트를 지우지 마시고 부팅 설정을 새 스크립트로 자동으로 바꾸지 않음을 참고하십시오. 더 확실한 방편이 필요하다면, 이전 OpenAFS 커널 모듈을 업데이트한 시스템 바이너리와 함께 사용할 때 커널이 더 잘 맛이 갈 수 있습니다. 따라서, 바닥부터 깔끔하고 쉽게 전환하겠습니다. 그렇게 할거죠?


참고
이 장은 다양한 시스템 설정을 염두에 두고 작성했습니다. 여전히 사용자가 만들어내는 꼼수 덕분에 여기서 설명하지 않을 별난 상황들이 일어날 수 있습니다. 시스템을 이리저리 설정할 충분한 자신감을 지닌 사용자라면 적재적소의 주어진 참고 사항을 충분히 적용하는 경험을 거쳐야합니다. 이 같은 경우가 아니라면 시스템에서 일부 과정만 진행하겠지만 이전 이빌드를 설치하면 앞으로 나타날 대부분의 경고 상황은 건너뛸 수 있습니다.


이전 버전과의 차이점

예전부터 OpenAFS는 코드를 포킹하기 전 IBM 트랜스타크 연구소에서 사용한 동일한 경로 이름 규칙을 사용합니다. 당연히도, 이전 AFS 설정은 이전 경로 이름 규칙을 계속 활용할 수 있습니다. 최근 설정에서는 (대부분의 리눅스 배포판에서 본 대로) 표준 경로를 활용한 FHS에 맞추었습니다. 다음 표에서는 OpenAFS 배포 타르볼의 README와 설정 스크립트의 내용을 비교합니다:

디렉터리 사용목적 트랜스아크 모드 기본모드 젠투용 변환
viceetcdir 클라이언트 설정 /usr/vice/etc $(sysconfdir)/openafs /etc/openafs
unnamed 클라이언트 바이너리 unspecified $(bindir) /usr/bin
afsconfdir 서버 설정 /usr/afs/etc $(sysconfdir)/openafs/server /etc/openafs/server
afssrvdir 내부 서버 바이너리 /usr/afs/bin (servers) $(libexecdir)/openafs /usr/libexec/openafs
afslocaldir 서버 상태 /usr/afs/local $(localstatedir)/openafs /var/lib/openafs
afsdbdir Auth/serverlist/... databases /usr/afs/db $(localstatedir)/openafs/db /var/lib/openafs/db
afslogdir 로그 파일 /usr/afs/logs $(localstatedir)/openafs/logs /var/lib/openafs/logs
afsbosconfig 감독관 설정 $(afslocaldir)/BosConfig $(afsconfdir)/BosConfig /etc/openafs/BosConfig

트랜스아크 모드에서 바이너리 파일 같은걸 /usr/vice/etc에 넣는 이상한 점이 보이지만, 전체적으로 정리하려는 의도에서 이 목록을 제시한건 아닙니다. 오히려 설정 파일을 변환하는데 있어 문제를 해결하기 위한 참고자료로 제시할 뿐입니다.

또한 경로를 바꾸면 기본 디스크 캐시 위치는 /usr/vice/cache에서 /var/cache/openafs로 바뀝니다.

게다가 초기화 스크립트는 클라이언트와 서버 부분으로 나뉘었습니다. 종종 /etc/init.d/afs 를 보유하고 있지만 이제 /etc/init.d/openafs-client/etc/init.d/openafs-server로 쪼갤 시간입니다. 따라서, /etc/conf.d/afs 설정파일은 /etc/conf.d/openafs-client/etc/conf.d/openafs-server 로 나눕니다. 또한 클라이언트 또는 서버를 가동하는 /etc/conf.d/afs의 옵션은 오래되어 방치됩니다.

초기화 스크립트에서 바꿔야 할 다른 부분은 디스크 캐시 설정을 더이상 확인하지 않는 부분입니다. 이전 코드는 따로 나눈 ext2 분할 공간을 /usr/vice/cache에 마운트해야합니다. 어떤 문제가 있냐면:

  • 매우 논리적으로 설정했음에도 불구, 캐시에서는 따로 분할 공간을 둘 필요가 없습니다. 실제로 디스크 캐시 사용 정보가 있는 /etc/openafs/cacheinfo 에서 여러분이 지정한 공간을 확인하는 만큼 안전합니다. 그러니까 실제로 루트 분할 공간에 캐시가 있으니 문제는 없습니다.
  • 어떤 사람은 실제 디스크 캐시 겅로에 소프트링크를 걸어두는 경우가 있습니다. 초기화 스크립트는 이런 방식을 선호하지 않는데, 이 캐시 위치는 /proc/mounts에서 마운트하지 않았기 때문입니다.
  • 오늘날 대부분은 ext3 를 ext2 보다 선호합니다. 두 파일 시스템은 디스크 캐시 용도로 아직도 유효합니다. 다른 어떤 파일 시스템은 지원하지 않습니다.(예: reiserfs는 시도하지 마십시오. 엄청난 경고가 뜨고, 나중에 가동 실패가 뜹니다).

새 경로로 전환

우선 최신 버전의 OpenAFS로 이전 설정 파일을 덮어쓰지 말아야합니다. 스크립트는 시스템에 이미 있는 파일을 바꾸지 않도록 했습니다. 그래서 이전의 설정과 새 위치의 설정으로 설정을 완전히 꼬아놓더라도 스크립트는 그 이상의 문제를 유발하지 않습니다. 또한 OpenAFS 가 동작중이라면, 데이터베이스가 깨질 가능성을 막기 위해 설치를 중단합니다.

한가지 주의하셔야 할 게 있는데, 젠투에서 /etc 디렉터리에 올려둔 보호 설정을 일부 비활성화해둔 이빌드가 인터넷에 돌아다닙니다. 이 이빌드는 젠투에서 배포한적이 없습니다. 다음 명령으로 CONFIG_PROTECT_MASK 변수 값을 확인하십시오:

root #emerge info | grep "CONFIG_PROTECT_MASK"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d"

이빌드에서 /etc/afs에 있는 파일을 건드리지 않지만, 업그레이드 과정에서 이전 OpenAFS 설치를 제거합니다. 이전 설치에 속한 CONFIG_PROTECT_MASK에 있는 파일 역시 마찬가지로 제거합니다.

소프트 링크(e.g. /usr/afs/etc to /etc/openafs )를 직접 추가하여 시스템을 직접 설정한 경우를 경험한 사용자들이 분명히 해야할 점이 있는데, 이전 설정 파일을 여전히 사용중에도 새 설치 과정을 실행하는게 좋습니다. 이 경우, 실제 트랜지션을 수행하지 않고 이전 설치를 정리하면 OpenAFS 설정이 깨집니다.

이제 어떤 일도 일어나지 않는다는걸 확인했으니 어떤 동작을 하는지 알아볼 차례입니다:

  • /usr/afs/etc/etc/openafs/server 에 복사
  • /usr/vice/etc/etc/openafs 에 복사
  • /usr/afs/local/var/lib/openafs 에 복사
  • /usr/afs/bin//usr/libexec/openafs로, /usr/afs/etc/etc/openafs/server로, /usr/afs/bin(앞에서와 같이 / 제외)를 /usr/bin 로 바꾸는 동안 /usr/afs/local/BosConfig/etc/openafs/BosConfig 에 복사
  • /usr/afs/db/var/lib/openafs/db 에 복사
  • 모든 이전 옵션을 클라이언트 전용으로 해둘 /etc/conf.d/afs 설정 파일을 /etc/conf.d/openafs-client에 복사

자체 업그레이드

OpenAFS 서버를 설정하지 않았다고요? 했으면 이전 어떤 상황인지 여전히 대기중인지 알아채셨죠?

그럼 시작하지요!

서버가 실행중이면 일단 끄십시오.

root #/etc/init.d/afs stop

명령 실행이 끝나면 자체적으로 업그레이드를 실행하십시오.

root #emerge --ask openafs

OpenAFS 다시 시작하기

OpenAFS 서버를 가동중이라면, 끄지 않아도 됩니다. 이제 해당 과정을 진행할 차례입니다.

root #/etc/init.d/afs stop

서버 내리는 시간을 최소화해야 한다면 OpenAFS 서버를 바로 다시 시작할 수 있습니다.

root #/etc/init.d/openafs-server start

다음 명령으로 제대로 동작중인지 확인할 수 있습니다:

root #/usr/bin/bos status localhost -localauth

OpenAFS 클라이언트를 다시 시작하기 전 캐시 설정을 충분한 시간동안 확인하십시오. /etc/openafs/cacheinfo에서 설정합니다. OpenAFS 클라이언트 설치를 다시 시작하려면 다음을 입력하십시오:

root #/etc/init.d/openafs-client start

과정 후 정리

정리하기 전, 업그레이드하고 재시작한 후 모든 부분이 무난하게 동작하는지 확인하십시오(제대로 동작하지 않는다면 이전 설치 프로그램을 여전히 동작하고 있을지도 모릅니다).

중요
/usr/vice를 삭제할 때 /usr/vice/cache를 디스크 캐시 용도로 사용중이 아닌지 확인하십시오!!

시스템에서 다음 디렉터리를 안전하게 제거하셔도 됩니다:

  • /etc/afs
  • /usr/vice
  • /usr/afs
  • /usr/afsws

다음 파일은 필요하지 않습니다:

  • /etc/init.d/afs
  • /etc/conf.d/afs
root #tar czf /root/oldafs-backup.tgz /etc/afs /usr/vice /usr/afs /usr/afsws
root #rm -R /etc/afs /usr/vice /usr/afs /usr/afsws
root #rm /etc/init.d/afs /etc/conf.d/afs

=openafs-1.2.13 또는 =openafs-1.3.85 이빌드를 앞서 호라용했다면 필요없는 파일도 있습니다:

  • /etc/init.d/afs-client
  • /etc/init.d/afs-server
  • /etc/conf.d/afs-client
  • /etc/conf.d/afs-server

초기화 스크립트 변경

이제 대부분 사람들이 OpenAFS 클라이언트를 시스템을 시작할 때 자동으로 시작하도록 설정했습니다. 이 부분을 안전하게 넘어갈 수 없는 분이 있습니다. 자동으로 시작하도록 시스템을 설정했다면, 초기화 스크립트의 이름이 바뀌었으니ㅣ 다시 활성화해야합니다.

root #rc-update del afs default
root #rc-update add openafs-client default
root #rc-update add openafs-server default

=openafs-1.2.13 또는 =openafs-1.3.85를 설치했다면 기본 런레벨에서 afs-clientafs-server를 제거하시고, 대신 afs를 활용하십시오.

문제 해결: 자동 업그레이드 실패

절망하지 마십시오. 어떤 데이터나 설정 파일도 날라가지 않았습니다. 그러니 상황을 다시 살펴보도록 하겠습니다. 이 경우 bugs.gentoo.org에 버그 보고서를 보내주시고 되도록이면 최대한 정보를 많게 자세히 적절하게 넣어주십시오.

클라이언트 시작시 문제가 있다면 문제를 진단하는데 이 방법이 도움이 될 것입니다:

  • dmesg를 실행하십시오. 클라이언트에서 보통 오류 메시지를 보냅니다.
  • /etc/openafs/cacheinfo를 확인하십시오 . 다음 모양새를 갖춰야합니다: /afs:{path to disk cache}:{number of blocks for disk cache}. 보통 여러분의 디스크 캐시는 /var/cache/openafs 에 있습니다.
  • lsmod 출력 내용을 확인하십시오 . openafs로 시작하는 줄을 확인하십시오.
  • pgrep afsd 명령은 afsd가 실행중인지 아닌지를 언급합니다.
  • cat /proc/mounts 에서 /afs 를 마운트했는지 여부가 나타나야합니다.

서버 시작에 누제가 있다면 다음 실마리가 도움이 될 수도 있습니다:

  • pgrep bosserver 명령의 결과에서는 구조 데몬이 실행중인지 아닌지를 알려줍니다. 하나 이상의 구조 데몬이 실행 중이라면, 뭔가 문제가 있다는 얘깁니다. 이 경우 bos shutdown localhost -localauth -wait 명령으로 OpenAFS 서버를 완전히 중단한 후, bos status localhost -localauth 명령으로 결과를 확인하시고, 남아있는 구조 데몬 프로세스를 전부 강제 종료하고 여전히 동작중인 서버 프로세스가 있는지 (프로세스 목록은 ls /usr/libexec/openafs으로) 확인하십시오. 그 다음 서버 상태를 초기화 하기 위해 /etc/init.d/openafs-server zap 명령을 실행하시고 /etc/init.d/openafs-server start 명령을 다시 실행하십시오.
  • OpenAFS 자체 기록 시스템(기본 설정)을 활용 중이라면, /var/lib/openafs/logs/* 부분을 확인하십시오. syslog 서비스를 활용중이라면, 해당 기록 파일을 통해 문제 해결에 도움을 줄 정보가 있는지 확인하십시오.

문서

AFS 문서 가져오기

원조 IBM AFS 문서를 구할 수 있습니다. 잘 쓰여졌고 AFS 서버를 관리하기에 여러분께 좋다면 읽고 싶어하실지도 모르겠습니다.

root #emerge --ask app-doc/afsdoc

OpenAFS에 들어있는 문서를 활용하여 옵션을 설정하십시오. OpenAFS를 이머지할 때 doc USE 플래그를 적용하면 문서를 설치합니다. 이 문서는 /usr/share/doc/openafs-*/에 있습니다. 이 글을 쓰고 있는 시점에서 문서는 작업중입니다. 허나, IBM AFS 원본 문서에 설명하지 않은 OpenAFS의 새 기능에 대한 설명이 문서에 들어갈 예정입니다.

클라이언트 설치

클라이언트 빌드

root #emerge --ask net-fs/openafs

컴파일이 끝나면 계속 진행할 준비가 끝납니다.

간단한 전역 브라우징 클라이언트 설치

접근하려는 일부 OpenAFS 셀에 있지 않고 존재하는 OpenAFS 공유 자원을 전반적으로 탐색한다면, 설정을 전반적으로 건드리지 않고 OpenAFS만을 설치할 수 있으며, /etc/init.d/openafs-client를 시작할 수 있습니다.

지정 OpenAFS 셀에 접근

지정 셀에 접근하려면 대학 또는 회사의 자체 셀에 요청한 후 일부 설정을 다루어야합니다.

우선 데이터베이스 서버에서 여러분의 셀에 대해 /etc/openafs/CellServDB를 업데이트해야합니다. 이 정보는 보통 관리자에게 제공합니다.

두번째로, OpenAFS 셀에 기록할 수 있으려면, /etc/openafs/ThisCell 과 같은 식의 이름을 지정해야합니다.

코드 CellServDB 및 ThisCell 설정 변경
CellServDB:
>netlabs        #Cell name
10.0.0.1        #storage
  
ThisCell:
netlabs


경고
CellServDB 파일에 있는 공간만 활용합니다. TAB 키를 활용하면 클라이언트가 멈출 수도 있습니다.

CellServDB은 지정 셀에 접속하려면 어떤 서버가 필요한지 클라이언트에 알려줍니다. ThisCell은 명백하게 적어두어야 합니다. 보통 조직에 따라 고유의 이름을 활용하며, (공식) 도메인이 바람직한 선택이 될 수도 있습니다.

간단하게 시작하려면 /etc/init.d/openafs-client로 클라이언트를 시작하고 여러분 자신을 인증하기 위해 kinit; aklog를 활용하며 셀에 접근하기 위해 시작하십시오. 셀에 자동으로 로그인하려면 아래 적당한 섹션을 찾아보십시오.

캐시 조정

참고
불행하게도 AFS 클라이언트는 캐시를 동작시켜 제대로 동작하기 위해 ext2/3 파일 시스템이 필요합니다. 다른 파일 시스템을 활용하는 경우 일부 문제가 있습니다(예: raiserfs는 별로 좋지 않습니다).

(ext2/3이라면) 기존 파일 시스템에 캐시를 올려둘 수 있거나, 다른 분할 공간에 캐시를 올려둘 수 있습니다. 캐시 기본 위치는 /var/cache/openafs 이지만 /etc/openafs/cacheinfo를 편집하여 위치를 바꿀 수 있습니다. 캐시의 표준 크기는 200MB입니다만 더 늘려도 됩니다.

시스템 시작시 AFS 시작하기

다음 명령은 시스템 시작시 여러분의 afs 클라이언트에 적당한 링크를 만듭니다:

경고
-dynroot 옵션으로 afsd를 시작하지 않으면, afs 클라이언트를 시작할 때 항상 afs 서버를 도메인에서 가동해야합니다. AFS 서버가 가동중이 아닐 경우 연결 제한 시간에 도달하기 까지 시스템은 부팅하지 않습니다(그리고 상당한 시간이 걸립니다).
root #rc-update add openafs-client default

서버 설치

커베로스 서버 설치

OpenAFS는 커베로스 5 인증이 필요합니다. 다음에서는 MIT 커베로스 서버를 설치하는 방법을 보여드립니다. 대신 Heimdal 커베로스 구현체를 활용할 수도 있습니다.

중요
커베로스는 커베로스 서버와 클라이언트간 시간 동기화가 필요합니다. 서버에 ntpd를 설치했는지 확인하십시오.

다음 명령으로 MIT 커베로스 서버 바이너리를 설치하십시오:

root #emerge --ask mit-krb5

/etc/krb5.conf/etc/kdc.conf 설정 파일을 편집하십시오. EXAMPLE.COM 렘 이름을 여러분의 실제 렘 이름으로 바꾸시고 예제의 호스트 이름을 여러분이 보유한 호스트 이름으로 고치십시오.

참고
규칙에 따르면 커베로스 렘 이름은 대문자여야 한다는 점만 빼면 인터넷 도메인 이름과 일치해야합니다.

다음과 같이 커베로스 데이터베이스를 만드십시오:

root #mkdir /etc/krb5kdc
root #kdb5_util create -s

서버 빌드

참고
모든 명령은 한줄로 작성해야합니다. 이 문서에서는 보기 편하게 두 줄로 줄바꿈 처리를 하기도 합니다.

아직 끝내지 않았다면, 다음 명령으로 AFS 서버 클라이언트를 설정할 모든 필요한 바이너리를 설치하십시오.

root #emerge --ask net-fs/openafs

서버 키 생성

OpenAFS 1.6.5 에서는 서비스 키에 강력한 암호화(AES 등)를 지원하며 커배로스 키탭 파일을 직접 읽습니다. OpenAFS 커베로스 서비스 키를 만들었으면, OpenAFS 서비스를 시작하기 전 OpenAFS 서버 프로세스의 키탭에 내보내십시오.

root #kadmin.local -q "addprinc -randkey afs/<cellname>"
root #kadmin.local -q "ktadd -k /etc/openafs/server/rxkad.keytab afs/<cellname>"
중요
rxkad.keytab 파일을 기밀유지하는건 매우 중요합니다. AFS 셀에서 이 파일의 보안은 이 파일이 들어간 서비스키에 달려있습니다.

AFS 서버 시작하기

기본 감독(BOS) 서버를 초기화하려면 서버 머신의 AFS 프로세스를 감시하고 관리하는 bosserver 명령을 실행해야 합니다. 시스템의 초기화 과정 처럼 생각하십시오

참고
OpenAFS 1.6.0에서는 인증을 비활성화할 목적으로 더이상 -noauth 플래그를 포함할 필요가 없습니다. 이렇게 하면 윈도우가 없어 인증을 비활성화 한 상태에서 서버를 실행하므로 설정을 더욱 안전하게 합니다. 또한 서버 설정 과정을 엄청나게 단순화한 부작용도 있습니다.

OpenAFS bosserver를 시작하십시오.

root #/etc/init.d/openafs-server start

다시 부팅할 때 OpenAFS 서버가 시작하는지 확인하십시오:

root #rc-update add openafs-server default

/etc/openafs/server/CellServDB/etc/openafs/server/ThisCell로 만든 BOS 서버를 검증해보십시오:

root #ls -al /etc/openafs/server/
-rw-r--r--    1 root     root           41 Jun  4 22:21 CellServDB
-rw-r--r--    1 root     root            7 Jun  4 22:21 ThisCell

서버 프로세스의 셀 이름 정의

이제 셀 이름을 할당하십시오.

중요
이름 형식에 약간의 제한이 있습니다 두가지 중요한 사항이 있다면, 이름에 대문자가 들어가면 안되거나 문자 갯수가 64개를 넘어가면 안된다는 점입니다. 셀 이름은 /afs에 있기 때문에 짧은 이름으로 보통 정한다는 점을 기억하십시오. AFS 서비스를 인터넷에서 접근 가능하게 한다면 셀 이름에 등록한 인터넷 도메인 이름을 활용해야합니다. 이는 AFS의 전체 이름 공간의 혼동을 막습니다.
참고
이 안내서의 다음을 포함한 모든 절차에서, SERVER_NAME 인자 값을 여러분이 설치 중인 머신의 ( afs.gentoo.org 와 같은) 완전한 호스트 이름으로 바꾸십시오. CELL_NAME 인자 값은 (gentoo 와 같은) 완전한 셀의 이름으로 바꾸십시오.

bos setcellname 명령을 실행하여 셀 이름을 설정하십시오:

root #bos setcellname localhost CELL_NAME -localauth

데이터베이스 서버 프로세스 시작하기

다음 bos create 명령을 활용하여 데이터베이스 서버 프로세스 항목을 /etc/openafs/BosConfig 파일에 만드십시오. 이 세가지 프로세스는 데이터 서버 머신에서만 동작합니다.

프로세스 설명
buserver 백업 데이터베이스를 관리하는 백업 서버
ptserver 보호 데이터베이스를 관리하는 보호 서버
vlserver 볼륨 위치 데이터베이스(VLDB)를 관리하는 볼륨 위치 서버. 상당히 중요합니다 :)
참고
OpenAFS에 kaserver라고 하는 커베로스 서버가 있습니다. kaserver는 오래됐으니 새로 설치하고 나면 사용하면 안됩니다.
root #bos create localhost buserver simple /usr/libexec/openafs/buserver -cell CELL_NAME -localauth
root #bos create localhost ptserver simple /usr/libexec/openafs/ptserver -cell CELL_NAME -localauth
root #bos create localhost vlserver simple /usr/libexec/openafs/vlserver -cell CELL_NAME -localauth

bos status 명령을 실행하여 모든 서버를 확인할 수 있습니다:

root #bos status localhost -localauth
Instance buserver, currently running normally.
Instance ptserver, currently running normally.
Instance vlserver, currently running normally.

첫 파일 서버, 볼륨 서버, 셀베이저 시작하기

파일 서버, 볼륨 서버, 구조자(fileserver, volserver, salvager 프로세스)로 구성된 fs 프로세스를 시작하십시오.

root #bos create localhost fs fs /usr/libexec/openafs/fileserver /usr/libexec/openafs/volserver /usr/libexec/openafs/salvager -localauth

모든 프로세스가 실행중인지 확인하십시오:

root #bos status localhost -long -localauth
  
Instance buserver, (type is simple) currently running normally.
Process last started at Mon Jun  4 21:07:17 2001 (2 proc starts)
Last exit at Mon Jun  4 21:07:17 2001
Command 1 is '/usr/libexec/openafs/buserver'
  
Instance ptserver, (type is simple) currently running normally.
Process last started at Mon Jun  4 21:07:17 2001 (2 proc starts)
Last exit at Mon Jun  4 21:07:17 2001
Command 1 is '/usr/libexec/openafs/ptserver'
  
Instance vlserver, (type is simple) currently running normally.
Process last started at Mon Jun  4 21:07:17 2001 (2 proc starts)
Last exit at Mon Jun  4 21:07:17 2001
Command 1 is '/usr/libexec/openafs/vlserver'
  
Instance fs, (type is fs) currently running normally.
Auxiliary status is: file server running.
Process last started at Mon Jun  4 21:09:30 2001 (2 proc starts)
Command 1 is '/usr/libexec/openafs/fileserver'
Command 2 is '/usr/libexec/openafs/volserver'
Command 3 is '/usr/libexec/openafs/salvager'

다음 동작은 셀에서 AFS 파일 서버를 가동하느냐에 따라 다릅니다.

첫 AFS 서버를 셀에 설치한다면 첫 AFS 볼륨을 root.afs로 설정하십시오.

참고
파티션 이름 인자는 머신의 AFS 서버 분할 공간 이름으로 바꾸십시오. 파일 시스템을 마운트한 x 대신에 a부터 z까지 들어가는 /vicepx 디렉터리를 고려하며 이 디렉터리를 보통 AFS 서버 분할 공간으로 활용합니다. 어떤 유닉스 파일 시스템이든 됩니다(클라이언트 캐시와는 달리 ext2/3만 됩니다). 요령을 하나 알려드리자면, 서버에서는 각각의 /vicepx 마운트 지점에 실제로 파일 시스템을 마운트했는지 확인합니다. 만약 마운트를 하지 않았다면 서버에서 활용하려들지 않습니다. 이 동작은 디렉터리에 AlwaysAttach 파일을 놓아서 우선 적용할 수 있습니다.
root #vos create localhost PARTITION_NAME root.afs -localauth

AFS 파일 서버 머신이 있고 셀의 볼륨이 있다면 로컬 머신의 실제 볼륨 상태와 VLDB(몰륨 위치 데이터베이스)와 동기화하는 vos sncvldb 명령과 vos syncserv 명령을 실행하십시오. 이 과정에서 필요한 모든 데이터를 새 서버로 복사합니다.

명령 실행 과정에서 "partition /vicepa does not exist on the server" 메시지가 떠서 실패할 경우, OpenAFS 서버를 실행하기 전 분할 공간을 마운트했는지, 또는 bos restart localhost -all -cell CELL_NAME -localauth 명령으로 디렉터리를 마운트하고 프로세스를 다시 시작했는지 확인하십시오.

root #vos syncvldb localhost -verbose -localauth
root #vos syncserv localhost -verbose -localauth

업데이트 서버의 서버 기능 시작하기

root #bos create localhost upserver simple "/usr/libexec/openafs/upserver -crypt /etc/openafs/server -clear /usr/libexec/openafs" -localauth

첫 관리 계정 만들기

셀 설정을 마무리 하고 관리 작업을 계속 진행하려면 관리자 계정이 필요합니다. 첫번재 계정은 서버에서 바로 만들어야합니다. 추기 계정은 서버에 ssh로 직접 접근하지 않고 만듭니다.

참고
다음 설명과 명령은 실제 사용자 이름, USERNAME의 모든 인스턴스로 나눕니다.

첫 관리 계정을 만들려면 네가지 작업 과정이 필요합니다.

  • USERNAME/admin 형식의 규칙에 따른 커베로스 인증
  • USERNAME.admin 형식의 규칙에 따른 AFS 사용자
  • 내장 AFS 시스템 및 관리자 그룹 구성원 자격
  • OpenAFS 최고 사용자 목록의 구성원 자격
참고
admin 이나 afsadmin 같은 어떤 이름이든 관리자 인증에 사용할 수 있습니다. USERNAME/admin 형식을 따르지 않는 admin 인증을 만들었다면 kadm5.acl 설정에서 커베로스 KDC 접근 관리 목록을 업데이트했는지 확인하십시오.
중요
커베로스 인증에는 "/" 슬래시 구분 문자가 있지만 불행하게도 AFS에서는 "." 구분자를 활용합니다. 차이를 기억해두십시오.

커베로스 기본 인증 정보를 만드십시오. 이 명령을 커베로스 서버에서 루트 권한으로 실행하십시오:

root #kadmin.local -q "addprinc USERNAME/admin"

AFS admin 사용자를 만드십시오 이 명령을 OpenAFS 데이터베이스 서버에서 루트 권한으로 실행하십시오:

root #pts createuser USERNAME.admin -localauth

AFS admin 사용자를 내장 관리자 그룹에 추가하십시오. 이 명령을 OpenAFS 데이터베이스 서버에서 루트 권한으로 실행하십시오:

root #pts adduser USERNAME.admin system:administrators -localauth

AFS admin 사용자를 최고 사용자 목록에 추가하십시오. 이 명령을 각 OpenAFS 서버에서 루트 권한으로 실행하십시오:

root #bos adduser localhost USERNAME.admin -localauth
참고
부족한 권한과 관련이 있고, AFS 셀 이름이 커베로스 렘 이름과 달라 나중에 문제가 생기면, 이 문제는 /etc/openafs/server/krb.conf 설정 파일에서 렘 이름을 설정하여 재조정할 수 있습니다.

AFS 파일 공간 최상위 레벨 설정

서버 설정이 끝났습니다. AFS 클라이언트를 실행하여 AFS 최상위 디렉터리를 설정하고 올바른 접근 권한을 부여해야합니다. 이 클라이언트는 OpenAFS 서버에 설치할 필요가 없습니다. 단지 관리 권한만 가져오면 됩니다. 이 부분에서 명령 실행 목적의 루트 접근은 필요하지 않습니다.

우선 관리 권한을 가져오겠습니다:

user $kinit USERNAME/admin
Password for USERNAME/admin@REALM: ********
user $aklog
user $tokens
Tokens held by the Cache Manager:
 
User's (AFS ID 1) tokens for afs@mycellname.com [Expires Oct 21 20:26]
   --End of list--

우선 일부 ACL을 설정하여 어떤 사용자든 /afs을 탐색할 수 있게 해야합니다.

참고
기본 OpenAFS 클라이언트 설정은 dynroot 활성화 상태입니다. 이 옵션은 /afs 디렉터리를 /etc/openafs/CellServDB 파일의 내용으로 구성한 가상 디렉터리로 바꿉니다. 다행스럽게도 dynroot에서는 "magic" /afs/.:mount/ 디렉터리를 통해 이름을 통핸 볼륨 접근 방식을 제공합니다. 이렇듯 설정에 따른 동작은 dynroot를 비활성 처리하고 클라이언트를 다시 시작할 필요가 없습니다.
user $fs setacl /afs/.:mount/CELL_NAME:root.afs/. system:anyuser rl

다음에는 루트 볼륨을 만들고 /afs/<cell name>를 읽기 전용으로, /afs/.<cell name>를 읽기/쓰기용으로 마운트해야합니다.

user $vos create SERVER_NAME PARTITION_NAME root.cell
user $fs mkmount /afs/.:mount/CELL_NAME:root.afs/CELL_NAME root.cell
user $fs setacl /afs/.:mount/CELL_NAME:root.afs/CELL_NAME system:anyuser rl
user $fs mkmount /afs/.:mount/CELL_NAME:root.afs/.CELL_NAME root.cell -rw


이 때, 새 AFS 위치에 볼륨을 만들고 파일 공간을 추가할 수 있습니다. 사용자 및 그룹을 만들고 디렉터리 접근 권한 설정을 통해 사용자가 파일과 디렉터리를 만들 수 있게 해야합니다. 볼륨을 만들고 마운트하려면:

user $vos create SERVER_NAME PARTITION_NAME VOLUME_NAME
user $fs mkmount /afs/CELL_NAME/MOUNT_POINT VOLUME_NAME
user $fs mkmount /afs/CELL_NAME/.MOUNT_POINT VOLUME_NAME -rw
user $fs setquota /afs/CELL_NAME/.MOUNT_POINT -max QUOTUM

결국은 해냈습니다!!! 로컬 네트워크에 동작하는 AFS 파일 서버를 두었습니다. 이제 왕컵에 커피를 부어드시고 AFS 문서를 쭉 뽑아두세요!!!

참고
AFS 서버가 제기능을 하려면 모든 시스템의 시계를 동기화하는 것이 중요합니다. ntp 서버를 한대의 머신(예: AFS 서버)에 설치하고 ntp 클라이언트로 모든 클라이언트의 클록을 동기화하면 됩니다. 또한 AFS 클라이언트로도 처리할 수 있습니다.

기본 관리

면책 사항

OpenAFS는 확장 기술입니다. 더 많은 정보를 확인하시려면 AFS 문서를 살펴보십시오. 이 부분에서는 지극히 일부의 관리 작업만 나열합니다.

로그인시 AFS 토큰을 획득하기 위한 PAM 설정

AFS를 이용하려면 커베로스 5 KDC(MIT, Heimdal, ShiShi Kerberos 5 또는 Microsoft Active Directory)에 대해 인증해야합니다. 허나 머신에 로그인하려면 /etc/passwd, NIS, LDAP(OpenLDAP), Hesiod 데이터베이스의 로컬 일부가 될 수 있는 사용자 계정이 있어야합니다. PAM은 젠투에서 AFS에 인증 체계를 붙일 수 있게 하고 사용자 계정으로 로그인할 수 있게합니다.

참고
이 섹션은 오래됐습니다. 리눅스 시스템에서 AFS 로그인 활성화 문서를 보십시오.

다른 설정에서 활용할 /etc/pam.d/system-auth 파일을 업데이트해야합니다. use_first_pass는 사용자가 로그인하면 표시하는 것으로 보이며 ignore_root 는 AFS 또는 네트워크에 문제가 있어 로그인을 허용할 때 로컬 최고 사용자 확인 과정을 중단하게 합니다.

파일 /etc/pam.d/system-auth
auth       required     pam_env.so
auth       sufficient   pam_unix.so likeauth nullok
auth       sufficient   pam_afs.so.1 use_first_pass ignore_root
auth       required     pam_deny.so
  
account    required     pam_unix.so
  
password   required     pam_cracklib.so retry=3
password   sufficient   pam_unix.so nullok md5 shadow use_authtok
password   required     pam_deny.so
  
session    required     pam_limits.so
session    required     pam_unix.so

실제 사용자의 토큰을 유지하고 로컬 사용자가 /etc/pam.d/su의 내용을 바꾸어 AFS 접근 권한을 취득하는 문제를 막으려면 다음 명령을 실행하십시오:

파일 /etc/pam.d/su
# Here, users with uid > 100 are considered to belong to AFS and users with
# uid <= 100 are ignored by pam_afs.
auth       sufficient   pam_afs.so.1 ignore_uid 100
  
auth       sufficient   pam_rootok.so
  
# If you want to restrict users begin allowed to su even more,
# create /etc/security/suauth.allow (or to that matter) that is only
# writable by root, and add users that are allowed to su to that
# file, one per line.
#auth       required     pam_listfile.so item=ruser \
#       sense=allow onerr=fail file=/etc/security/suauth.allow
  
# Uncomment this to allow users in the wheel group to su without
# entering a passwd.
#auth       sufficient   pam_wheel.so use_uid trust
  
# Alternatively to above, you can implement a list of users that do
# not need to supply a passwd with a list.
#auth       sufficient   pam_listfile.so item=ruser \
#       sense=allow onerr=fail file=/etc/security/suauth.nopass
  
# Comment this to allow any user, even those not in the 'wheel'
# group to su
auth       required     pam_wheel.so use_uid
  
auth       required     pam_stack.so service=system-auth
  
account    required     pam_stack.so service=system-auth
  
password   required     pam_stack.so service=system-auth
  
session    required     pam_stack.so service=system-auth
session    optional     pam_xauth.so
  
# Here we prevent the real user id's token from being dropped
session    optional     pam_afs.so.1 no_unlog

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Stefaan De Roeck, Holger Brueckner, Benny Chuang, Tiemo Kieft, Steven McCoy, Shyam Mani
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.