우연히 어쩌다가 지인을 통해서 조판업체에 CentOS를 설치하고 Netatalk를 설치를 하게 되었다.
개인적으로 타이거에서 CentOS에 설치한 AFP over TCP/IP로 접속하는 것은 별 문제가 없어서 원래 Netatalk 포스팅에서는 그리 설정과 참고사항에 대한 언급이 적었다. 하지만 이번에 Mac OS 9과 Mac OS X를 섞어쓰는 환경에서 하루 수십기가의 대량 자료 전송과 동시 작업자들이 작업을 하는 파일서버를 다루면서 이런저런 당황스런 경우를 겪어서 해결을 위해 이리저리 알아본 바를 여기에 포스팅한다.
다시 말하지만 지금의 포스팅은 약 20여대의 맥들이 동시에 동일한 아이디로 연결되서 여러 파일을 읽고 쓰는 Netatalk local network서버에서 설정하고 겪은 경우를 기술한다. 두서가 없는 글이라도 양해를 구한다.
일단 한국 출판업계의 숙적인 쿽3.3K 때문에 아직도 클래식맥을 사용하는 곳이 많다는 것을 새삼 느끼게 되었다. 이런 말을 하는 이유는 이 OS9와 OS X의 동시 접속 사용때문에 많은 일들이 일어나기 때문이다. 그리고 원래 netatalk 패키지는 동양언어 인코딩을 고려하고 있지 않았기 때문에 일본인이신 HAT님의 cjk패치를 해 주어야 한다. 그리고 한글사용 때문에 또 몇가지 다른 문제가 일어나게 된다.
일단 세팅을 하기 위해서는 환결설정화일이 있는 디렉토리에 있는 파일들을 살펴 보아야 한다. 설정을 하는 파일의 자세한 설명은 개인적으로 살펴 본 바 man page가 가장 충실했다. 그래도 기본 메뉴얼을 훑어보는 것은 도움이 되며 FAQ를 보면 DB를 복구하는 cnid_index라는 유틸의 사용법과 결과가 어디에 나오는지 설명이 그나마 자세히 나온다.
설정할 파일들이 몇가지 있는데
이 중에 맥들이 공유 이름으로 AppleTalk연결을 하고 파일 서비스를 하기 위해서 AppleTalk서비스와 AFP서비스를 이용해야 하므로 수정한 파일은 netatalk.conf, atalkd.conf, afpd.conf, AppleVolumes.default, 이다.
먼저 netatalk.conf 파일을 보면
afpd.conf의 경우는
AppleVolumes.default
매뉴얼을 읽어보면 기본으로 netatalk는 UTF-8을 기본 인코딩으로 지원하고 있다고 하는데 문제는 Mac OS 9의 경우 한국에서는 MAC_KOREAN을 기본 인코딩으로 사용되므로 이를 고려해야 한다. 다행히도 클래식 클라이언트에서 netatalk에 연결을 할 때 AFP2.2 이하 프로토콜을 쓰게 되므로 인코딩을 지정하라는 메시지를 보게 되므로 문제는 없다. 그리고 위 설정 화일에 화일 인코딩을 잘 설정해 놓으면 자동으로 한글 이름을 UTF-8로 바꾸어 주게 된다. 그런데 클래식과 OS X의 파일시스템에 차이가 있기 때문에 파일명 길이 제한도 다르고 특수문자의 코드도 다르기 때문에 동시에 사용하는 환경이라면 가급적 키보드에 없는 특수문자를 사용하지 않는게 바람직하다. 아니면 netatalk를 빌드할 때 --disable-afp3를 지정해서 애초에 모든 클라이언트가 AFP2.x로 접속하게 강제를 하는 방법도 있다.
또한 한가지 문제가 클래식 맥에서 사용하는 리소스 포크라는 개념이다. 이것 때문에 실제 클래식 맥을 사용하는 출판업계에서 어쩔 수 없이 netatalk를 공유 서버로 사용해야한 이유가 있다. 그런데 문제는 netatalk가 완전하지 않기 때문에 얘기치 않은 일로 인해서 저장된 데이터베이스가 오염되는 경우가 발생할 수 있다. 최악의 경우 리소스쪽 연결이 모두 깨어지고 AFP연결이 클라이언트에서 되지 않는 경우가 생긴다.
이 때 해결책을 여기저기 검색해 본 결과 체크 및 복구툴인 cnid_index란 툴을 써 보고 그래도 되지 않을 경우, 딱히 명쾌한 방법은 없지만 일단 연결이 되지 않던 공유를 연결하기 위해서 .AppleDB라는 CNID데이터베이스가 저장된 곳을 삭제해 주면 된다. 이렇게 하면 리소스 포크가 망가지게 되는데 이때는 resedit등을 이용해서 기존의 데이터 파일을 가지고 복구를 하면 된다고 한다. 나의 경우도 이런 경우가 발생해서 결국 자료를 날리는 일이 있었기는 했다. 그리고 이렇게 오염을 막기 위해서는 CNID 데이터베이스에 접근하는 방식을 지정하면 되는데 기본이 동시에 여러 사용자가 락을 걸고 쓰는 CDB에서 하나의 데몬을 통해서만 데이터베이스에 접근하는 DBD방식으로 바꾸면 되는데 속도의 감소가 있다고 한다. 그리고 데이터베이스가 망가지지 않게 하기 위해 절대 SIGKILL로 데몬을 죽이지 말고 서비스 명령을 통해서 서비스를 올리고 내리기 바란다.
이전의 설정에 맥쪽 한글 인코딩을 클래식 맥을 위해 MAC_KOREAN이라고 했는데 이것이 OS X와 같이 있는 환경에서 사소한 에러 메시지를 내는 원인이 되기도 한다. afpd는 접속한 쪽 인코딩을 인식하지 못하기 때문에 설정한 대로 인코딩을 변환하려 하기 때문에 가령 로그 메시지에서 afpd[29663]: Conversion failed ( UTF8-MAC to CH_UCS2 ) 혹은 afpd[29498]: Conversion failed ( MAC_KOREAN to CH_UCS2 ) 과 같은 에러를 볼 수 있다. 물론 둘 다 사용에 지장을 주지는 않겠지만(인코딩이 실패하면 그대로 저장한다.) 로그가 쭉쭉 쌓이게 될 수도 있다. 나의 경우 하루에 100메가 가량의 에러로그가 쌓이고 있다. 그렇다고 EUC-KR등의 다른 인코딩을 쓴다고 해서 해결된 문제도 아니다. 그래서 위에서 언급한 --disable-afp3 를 통한 강제 AFP 2.2연결을 시도해 보는 것이 짧은 파일명의 제한이 있지만 괜찮은 솔루션이 아닐까 한다. 하지만 역시나 바로 파일 시스템에 접근해 쓰기를 시도하면 역시나 에러를 낼 수 있다.
그리고 레퍼드에서 사용하는 타임머신의 경우 개발버전인 netatalk 2.1dev에서 구현중이지만 아직 제대로 서비스에 대한 구현이 되어 있지 않아서 작동이 원활히 되는지는 잘 모른다. 하지만 굳이 OS X 부터 리소스 포크를 하지 않는 이상 AFP를 이용해서 공유를 고집하지 않아도 될 듯 하다. 또한 기본적으로 .등의 문자는 hex translation이라는 방식을 통해 :2e 의 형식으로 바뀌게 되는데( 클래식맥에서 이렇게 CAP인코딩을 한다고 한다) 이를 해제하기 위해서는 AppleVolumes.default 메뉴얼을 보기 바란다. 거기에 몇가지 더 유용한 옵션들이 있다.
다른 문제가 있을 경우 netatalk홈페이지에 있는 메일링 리스트를 검색해 보는 것이 제일 빠를 듯 하다.
개인적으로 타이거에서 CentOS에 설치한 AFP over TCP/IP로 접속하는 것은 별 문제가 없어서 원래 Netatalk 포스팅에서는 그리 설정과 참고사항에 대한 언급이 적었다. 하지만 이번에 Mac OS 9과 Mac OS X를 섞어쓰는 환경에서 하루 수십기가의 대량 자료 전송과 동시 작업자들이 작업을 하는 파일서버를 다루면서 이런저런 당황스런 경우를 겪어서 해결을 위해 이리저리 알아본 바를 여기에 포스팅한다.
다시 말하지만 지금의 포스팅은 약 20여대의 맥들이 동시에 동일한 아이디로 연결되서 여러 파일을 읽고 쓰는 Netatalk local network서버에서 설정하고 겪은 경우를 기술한다. 두서가 없는 글이라도 양해를 구한다.
일단 한국 출판업계의 숙적인 쿽3.3K 때문에 아직도 클래식맥을 사용하는 곳이 많다는 것을 새삼 느끼게 되었다. 이런 말을 하는 이유는 이 OS9와 OS X의 동시 접속 사용때문에 많은 일들이 일어나기 때문이다. 그리고 원래 netatalk 패키지는 동양언어 인코딩을 고려하고 있지 않았기 때문에 일본인이신 HAT님의 cjk패치를 해 주어야 한다. 그리고 한글사용 때문에 또 몇가지 다른 문제가 일어나게 된다.
일단 세팅을 하기 위해서는 환결설정화일이 있는 디렉토리에 있는 파일들을 살펴 보아야 한다. 설정을 하는 파일의 자세한 설명은 개인적으로 살펴 본 바 man page가 가장 충실했다. 그래도 기본 메뉴얼을 훑어보는 것은 도움이 되며 FAQ를 보면 DB를 복구하는 cnid_index라는 유틸의 사용법과 결과가 어디에 나오는지 설명이 그나마 자세히 나온다.
설정할 파일들이 몇가지 있는데
netatalk.conf - Netatalk 전체적인 설정을 해 주는 파일
afpd.conf - 파일공유를 위한 데몬을 위한 설정을 하는 파일
atalkd.conf - AppleTalk연결을 위한 설정 파일
papd.conf - 프린트공유를 하기 위한 설정파일
AppleVolumes.default - 공유를 할 마운트 포인트를 설정하는 화일
AppleVolumes.system - 화일별 특성을 지정하는 파일. 수정이 그리 필요하지는 않다.
이 중에 맥들이 공유 이름으로 AppleTalk연결을 하고 파일 서비스를 하기 위해서 AppleTalk서비스와 AFP서비스를 이용해야 하므로 수정한 파일은 netatalk.conf, atalkd.conf, afpd.conf, AppleVolumes.default, 이다.
먼저 netatalk.conf 파일을 보면
AFPD_MAX_CLIENTS=64 #동시 접속자 수를 정한다.
ATALK_NAME=`echo ${HOSTNAME}|cut -d. -f1` # AppleTalk 서비스시 보일 이름을 지정한다.
#-------- 클라이언트(맥)과 서버측 OS 인코딩처리 형식을 지정한다.
ATALK_MAC_CHARSET='MAC_KOREAN'
ATALK_UNIX_CHARSET='utf8'
# 파일서비스 접속시 인증받을 방식을 정한다.
AFPD_UAMLIST="-U uams_dhx.so"
# Netatalk 서비스 시작시 실행해 줄 서비스들을 선택한다.
ATALKD_RUN=yes
PAPD_RUN=no # 프린터 공유를 위한 서비스
CNID_METAD_RUN=yes # DBD 방식으로 db를 접근 할 때 필요하다.
AFPD_RUN=yes
TIMELORD_RUN=no
A2BOOT_RUN=no
# 백그라운드로 돌아가게 할지 설정
ATALK_BGROUND=no
# 파일공유 게스트 사용자ID 설정
AFPD_GUEST=nobody
# 환경변수 등록.
export ATALK_MAC_CHARSET
export ATALK_UNIX_CHARSET
afpd.conf의 경우는
- -transall -uamlist uams_dhx.so -nosavepassword -maccodepage MAC_KOREAN -unixcodepage UTF8
# 하나의 가상 서버에 AFP over TCP, AFP over AppleTalk를 접근가능하게 하고 PAM을 이용한 인증을 하며, 암호를 저장하지 않고, 맥과 유닉스쪽 인코딩방식을 지정한다.
AppleVolumes.default
/data "share" maccharset:MAC_KOREAN volcharset:UTF8 adouble:v2 cnidscheme:cdb veto:/lost+found/
#/data 디렉토리를 share란 이름으로 공유를 하고 각각의 문자셋을 정하고 리소스 포크 처리방식을 v2로 하고 CNID처리를 CDB라는 방식으로 하며, lost+found란 이름이 들어간 디렉토리는 숨긴다
매뉴얼을 읽어보면 기본으로 netatalk는 UTF-8을 기본 인코딩으로 지원하고 있다고 하는데 문제는 Mac OS 9의 경우 한국에서는 MAC_KOREAN을 기본 인코딩으로 사용되므로 이를 고려해야 한다. 다행히도 클래식 클라이언트에서 netatalk에 연결을 할 때 AFP2.2 이하 프로토콜을 쓰게 되므로 인코딩을 지정하라는 메시지를 보게 되므로 문제는 없다. 그리고 위 설정 화일에 화일 인코딩을 잘 설정해 놓으면 자동으로 한글 이름을 UTF-8로 바꾸어 주게 된다. 그런데 클래식과 OS X의 파일시스템에 차이가 있기 때문에 파일명 길이 제한도 다르고 특수문자의 코드도 다르기 때문에 동시에 사용하는 환경이라면 가급적 키보드에 없는 특수문자를 사용하지 않는게 바람직하다. 아니면 netatalk를 빌드할 때 --disable-afp3를 지정해서 애초에 모든 클라이언트가 AFP2.x로 접속하게 강제를 하는 방법도 있다.
또한 한가지 문제가 클래식 맥에서 사용하는 리소스 포크라는 개념이다. 이것 때문에 실제 클래식 맥을 사용하는 출판업계에서 어쩔 수 없이 netatalk를 공유 서버로 사용해야한 이유가 있다. 그런데 문제는 netatalk가 완전하지 않기 때문에 얘기치 않은 일로 인해서 저장된 데이터베이스가 오염되는 경우가 발생할 수 있다. 최악의 경우 리소스쪽 연결이 모두 깨어지고 AFP연결이 클라이언트에서 되지 않는 경우가 생긴다.
이 때 해결책을 여기저기 검색해 본 결과 체크 및 복구툴인 cnid_index란 툴을 써 보고 그래도 되지 않을 경우, 딱히 명쾌한 방법은 없지만 일단 연결이 되지 않던 공유를 연결하기 위해서 .AppleDB라는 CNID데이터베이스가 저장된 곳을 삭제해 주면 된다. 이렇게 하면 리소스 포크가 망가지게 되는데 이때는 resedit등을 이용해서 기존의 데이터 파일을 가지고 복구를 하면 된다고 한다. 나의 경우도 이런 경우가 발생해서 결국 자료를 날리는 일이 있었기는 했다. 그리고 이렇게 오염을 막기 위해서는 CNID 데이터베이스에 접근하는 방식을 지정하면 되는데 기본이 동시에 여러 사용자가 락을 걸고 쓰는 CDB에서 하나의 데몬을 통해서만 데이터베이스에 접근하는 DBD방식으로 바꾸면 되는데 속도의 감소가 있다고 한다. 그리고 데이터베이스가 망가지지 않게 하기 위해 절대 SIGKILL로 데몬을 죽이지 말고 서비스 명령을 통해서 서비스를 올리고 내리기 바란다.
이전의 설정에 맥쪽 한글 인코딩을 클래식 맥을 위해 MAC_KOREAN이라고 했는데 이것이 OS X와 같이 있는 환경에서 사소한 에러 메시지를 내는 원인이 되기도 한다. afpd는 접속한 쪽 인코딩을 인식하지 못하기 때문에 설정한 대로 인코딩을 변환하려 하기 때문에 가령 로그 메시지에서 afpd[29663]: Conversion failed ( UTF8-MAC to CH_UCS2 ) 혹은 afpd[29498]: Conversion failed ( MAC_KOREAN to CH_UCS2 ) 과 같은 에러를 볼 수 있다. 물론 둘 다 사용에 지장을 주지는 않겠지만(인코딩이 실패하면 그대로 저장한다.) 로그가 쭉쭉 쌓이게 될 수도 있다. 나의 경우 하루에 100메가 가량의 에러로그가 쌓이고 있다. 그렇다고 EUC-KR등의 다른 인코딩을 쓴다고 해서 해결된 문제도 아니다. 그래서 위에서 언급한 --disable-afp3 를 통한 강제 AFP 2.2연결을 시도해 보는 것이 짧은 파일명의 제한이 있지만 괜찮은 솔루션이 아닐까 한다. 하지만 역시나 바로 파일 시스템에 접근해 쓰기를 시도하면 역시나 에러를 낼 수 있다.
그리고 레퍼드에서 사용하는 타임머신의 경우 개발버전인 netatalk 2.1dev에서 구현중이지만 아직 제대로 서비스에 대한 구현이 되어 있지 않아서 작동이 원활히 되는지는 잘 모른다. 하지만 굳이 OS X 부터 리소스 포크를 하지 않는 이상 AFP를 이용해서 공유를 고집하지 않아도 될 듯 하다. 또한 기본적으로 .등의 문자는 hex translation이라는 방식을 통해 :2e 의 형식으로 바뀌게 되는데( 클래식맥에서 이렇게 CAP인코딩을 한다고 한다) 이를 해제하기 위해서는 AppleVolumes.default 메뉴얼을 보기 바란다. 거기에 몇가지 더 유용한 옵션들이 있다.
다른 문제가 있을 경우 netatalk홈페이지에 있는 메일링 리스트를 검색해 보는 것이 제일 빠를 듯 하다.
