나를 찾아 떠나는 여행 / A Journey to Myself

OS X의 쓰레기통을 비우고나서 로그를 보면 Locum이란 프로세스가 종료되었다고 하는 것을 항상 볼 수 있다.

그 녀석이 항상 비울때 마다 뜨는 이유를 GREG MILLER님의 글에서 볼 수 있다.
대강의 설명을 하자면 사용자 자신에게 권한이 없는 파일이나 디렉토리들을 지우기 위해서 실행되는 프로세스란다.

어떻게 생각해 보면 그냥 사용자가 권한 상승을 통해서 해당 삭제를 해도 되겠지만, 보안성을 생각했을때 나름 애플측의 세심한 배려라고 볼 수 있다.

패럴럴에 오픈 솔라리스를 GNOME환경과 Xwindow없이 설치하는게 쉬운일이 아니었다.
일단 패키지 선택이 쉽지 않았다. 익숙하지 않은 수많은 패키지를 보면서 gnu gcc를 쓰기 위한 패키지 설치가 만만하지 않다.
그리고 오픈 솔라리스에서 새로 소개된 pkg라는 IPS방식의 패키지 인스톨 패키지가 디스크에 없어서 한번 설치시 제대로 설치하지 않으면 다시는 설치할 수 없었던듯 하다... 네트웍 드라이버는 사이트 설명대로 패럴럴에 있는 iso이미지에서 찾아서 설치하면 된다. 그리고 설치시 메모리를 1GB보다 작게 주었더니 GUI인스톨 화면이 나오지 않더라.

그리고 패럴럴에서 DHCP아이피 할당을 할 때 /Library/Preferences/Parallels/parallels_dhcp_leases 라는 파일에서 mac어드레스를 보고 게스트 OS마다 다시 해당 IP를 할당해 준다.

Mac OS X에서 POSIX 규격의 세마포어는 사실 Mach semaphore 기반으로 구현이 되어 있다고한다 ( Mac OS X Internals 도서 9.18.5 참고 ).

한가지 사소한 문제점이라면 OS X에서 POSIX규격의 unnamed semaphore(binary semaphore)가 구현되어 있지 않다는 점이다. 그래서 POSIX unnamed semaphore를 구현하려면 2가지 대체 방안을 사용할 수 있다.

1. POSIX의 named semaphore를 사용
2. Mach semaphore를 사용

 POSIX의 named semaphore를 사용하는 방법은 POSIX unnamed semaphore를 생성할때 사용하는 함수인 sem_init()대신 sem_open()을 사용하는 방법이다. sem_open("/tmp/sem", O_CREAT, 0777, 0)) 처럼 구체적인 파일을 열어야 한다.

오픈소스인 openVPN을 사용하여 구성한 VPN서버에 쉽게 접속하기 위한 OS X용 클라이언트를 소개한다.


오픈소스로 Tunnelblick이란 프로젝트가 있다. openvpn커맨드라인 소스코드와 tun/tap 오픈소스를 이용해서 GUI로 간편하게 openvpn서버에 접속하게 해 준다. 요 근래에 다시 프로젝트가 활성화되어 레퍼드에서 접속 문제가 있던 것을 해결한 버전이 올라와 있다.

상용으로는 인터페이스가 깔끔한 Viscosity라는게 있다. 이녀석을 외국인들은 추천을 하는듯. KT망으로는 DNS가 막힌건지 우회해서 다운받았다.

설치는 간단히 다운로드 받아서 원하는 곳에 복사해 놓으면 된다.

그리고 실행을 해보면 이렇게 썰렁하게 막혀있는 터널모양의 아이콘이 메뉴막대에 나타난다.

일단 연결 예제를 보여주기 위해서 AlwaysVPN이라는 미국에서 베타로 제공중인 서비스를 이용하겠다. 연결을 위해서 사이트에서 제공하는 익명연결을 지원하는 인증서를 다운로드 받는다.

그리고 받은 파일을 ~/Library/openvpn 디렉토리 아래에 적당한 폴더를 만들어 집어 넣고 이제 Tunnelblick을 다시 실행한다.
그리고 메뉴 아이콘에서 'Details...'를 선택하면 두개의 vpn연결설정이 있음을 확인할 수 있다. ( 주: 이미지의 나머지 하나는 개인적인 연결이다...)


자 여기서 먼저 'Edit Configuration' 버튼을 눌러서 설정파일의 위치를 확인한다. 왜냐하면 받은 인증서의 경로가 제대로 설정파일에 설정되지 않으면 제대로 작동되지 않기 때문에~ 그림에서 신경써줄 경로는 블럭으로 파랗게 해 놓은 부분이다. 알아서 적절히 고쳐주면 된다.


그렇게 하고 사파리 등에서 이 VPN연결을 통해서 DNS쿼리를 하려면 'Set Nameserver' 를 선택해주면 된다.
이제 설정이 다 되었다면 연결을 눌러보자~ 연결이 성공적으로 되면 뚫린 터널 아이콘을 볼 수 있고 로그에 성공했다고 나온다.




AlwaysVPN서비스의 경우는 미국에서 제공하는 것이고 공개베타라 그런지 느리고 자주 끊어지는 경향이 있다. 아마 조만간 유료화하리라. 그리고 Tunnelblick의 경우에 AlwaysVPN서비스가 제대로 서비스 되지 않아서(조만간 고쳐지기를~ 아마 스크립트나 내부적으로 사용하는 openvpn 2.1rc16 버전의 문제인것으로 보인다.openvpn 2.0.9 stable로 교체하면 잘 될지도 ㅡ0ㅡ; ) shareware인 Viscosity로 접속하고 그 모습을 올려본다. 이상태에서 사파리등으로 우회한 브라우징을 할 수 있다. 들어갈 수 없는 미국의 사이트에 접근이 가능하다. 예를 들어 위 viscosity사이트를 방문해 보길~

아래 이미지는 VPN을 통한 미국내 접근만 가능한 hulu.com의 family guy의 한 에피소드 플레이 모습. 하지만 속도가 느려서 보는건 무리이다.

Leopard의 X11은 Tiger시절의 X11과는 차이가 있다.

내가 이상했던 몇가지 사항은 X11.app 를 단독 실행하면 같이 뜨는 xterm을 마음대로 뜨지 않게 바꾸는게 타이거와 다르다는 사실과 xterm에서 $PATH등의 환경변수가 잘 로딩되지 않는다는 사실이다.

잘 몰랐던 사실이지만 forums.macosxhints.com의 X11관련 게시판을 둘러보면 많은 정보를 얻을 수 있다. 거기 말로는 Leopard에서는 DISPLAY를 체크해서 X윈도우가 필요한 프로그램이 접근시 launchd가 자동으로 X11을 실행한다고 한다. 경로를 제대로 표현하는 경우를 해결해서 사용할 때는 터미널에서 xterm을 커맨드로 쳐서 실행하라고 한다.

KLDP의 ashuaria님의 글을 참고해서 맥을 사용하는 노트북의 IEEE 1394a 포트를 리눅스 데스크탑과 연결해 보았다. 글에서처럼 이상하게도 modeprobe.conf에 alias를 줘서는 IEEE1394가 ehternet장치로 등록이 되지 않았다. 이유는 eth1394모듈이 커널에 올라오지 않기 때문이었다. 그래서 결국 insmod를 이용해 글에 있는것처럼 수동으로 모듈을 올려주면 IP over IEEE 1394 가 가능했다. 리눅스 2.6.x 커널 구현때문에 DHCP를 이용할 수 없다고 하지만 이건 다른 해결책을 강구해 보아야겠다 지금 상황에서는 윈도우처럼 편하게 연결해서 쓰기는 힘들듯 하다.
속도는 대략 스펙보다는 조금 떨어지는 270MBPS정도가 나온다. 노트북이란 상황과 아무래도 속도에 최적화 되지않은 커널 모듈사용에 기인할 수도 있다.

우연히 어쩌다가 지인을 통해서 조판업체에 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라는 유틸의 사용법과 결과가 어디에 나오는지 설명이 그나마 자세히 나온다.

설정할 파일들이 몇가지 있는데

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홈페이지에 있는 메일링 리스트를 검색해 보는 것이 제일 빠를 듯 하다.

리눅스에서 습관적으로 pkill을 사용하다가 맥에서도 당연히 있으리라고 pkill을 했지만 되지 않았다.

알고보니 pkill은 기본 유틸리티가 아니었다. 그래서 pgrep, pfind, pkill을 사용하려면 스크립트를 사용하거나 BSD계열을 위해 만든 proctools라는 유틸들을 받아서 빌드하여 사용하면 된다. proctools는 이미 macport에 포팅되어 있는 간단한 프로그램들이므로 macport를 이용해도 된다.

scheme을 사용하기 위해 이런저런 scheme구현을 빌드하고 있다. 그중 SICP책에서 사용하는 scheme구현인 MIT-Scheme을 빌드하기 위해 최근 스냅샷을 받아서 빌드하려고 안간힘을 썼다. 처음에는 바이너리를 받아서 설치하니까 .dylib가 있는데도 이미지가 없다고 에러를 내기에 아마도 레퍼드의 동적라이브러리를 사용하기 때문이라고 판단하고 소스 빌드를 시도했다.

그런데 또 하나의 문제가 소스를 빌드할때도 역시나 sbcl처럼 자기자신의 컴파일러가 필요했다. 이런.... 쳇.

결국 한참 삽질을 하다가 이전 스냅샷 릴리즈중에 mit-scheme-20070909-ix86-apple-darwin.tar.gz 바이너리를 일단 받아서 /usr/local 아래에 모두 설치한 후 다시 최신 소스 스냅샷을 받아 빌드했다. 소스 버전이 몇가지 되는데 바이너리가 작동 된다면 그냥 Source (.tar.gz) 버전을 받아서 설치하면 된다. 굳이 portable-c버전을 받을 필요는 없다. 어차피 두 소스 다 바이너리가 설치되어 있지 않으면 빌드가 불가능하다. ㅡㅅㅡ;

레퍼드라면 이런 삽질을 하지는 않았을텐데... 왜 미리 레퍼드라고 사이트에 알려놓지 않은건지... 어제 설치한 gambit-c도 자기 마음대로 버전넘버를 prefix에 집어 넣어서 짜증나게 만들더니...

몇몇 GNU유틸을 빌드하다가 /usr/local/man의 man page들이 man으로 볼 수 없다는 사실을 알았다. 그래서 구글링을 해 보니 MacOSFix missing man pages for self-installed utilities - macosxhints.com에서 언급을 하고 있더라. 알고보니 /usr/share/misc/man.conf의 설정에 원인이 있었다.

그리고 /usr/share/man/whatis 는 간단히 유틸들의 설명을 하는 whatis의 인덱싱파일인데 이게 /usr/local/share/man/whatis 에 또 있었다. 이 화일들이 몇몇 유틸들을 설치 후 업데이트가 안되는 듯 했다. Rebuild Mac OS X whatis database에서 Mac OS는 주마다 이 파일을 업데이트 하는 makewhatis가 /etc/periodic/weekly에 있는 실행이 된다고 한다. 그래서 강제로 한번 실행을 해 주고 확인을 해보니 /usr/local/share/man/whatis는 업데이트가 되지 않았다. 그래서 /etc/periodic/weekly에 있는 파일을 열어 보았더니 makewhatis를 실행하는 부분이 아래와 같았다.

if [ -x /usr/libexec/makewhatis.local ]; then
echo ""
echo "Rebuilding whatis database:"
if [ -d /usr/X11R6/man ]; then
MANPATH=${MANPATH:-/usr/share/man:/usr/X11R6/man:/usr/local/man}
else
MANPATH=${MANPATH:-/usr/share/man:/usr/local/man}
fi
makewhatis.local "${MANPATH}"
fi

결국 /usr/local/share/man 디렉토리가 빠져 있었던 것이다. 아마도 원래 Mac이 설치되면 /usr/local/share아래는 없어서 그런가 보다. 그래서 /usr/local/share/man를 두 부분에 추가하고 다시 스크립트를 어드민권한으로 시작해 주니 잘 된다.

ps. 맥에서 find대신 쓸만한 검색 툴이 두가지 있는데 하나는 locate란 녀석이고 하나는 spotlight이다. 둘 다 커맨드라인에서 사용이 가능하다. 단지 locate는 무지 빠르긴 한데 미리 인덱스 파일에서 찾는 것이라 인덱스파일의 업데이트가 주마다 되서 조금 사용시 잘 안될수도 있다.(The locate database). 그리고 makewhatis는 /usr/libexec에 있다.

또 man이 간략한 정보를 제공한다면 info는 자세한 매뉴얼을 제공하는 하이퍼링크를 지원하는 유틸인데 이것 또한 dir라는 이름의 인덱스파일을 만든다. 이것을 수정하는 유틸이 install-info라는 것인데 이것은 여기저기 /usr/local/info와 /usr/local/share/info 를 모두 검색해서 보여주는 듯 하다.