** 참고 : 아래의 모든 과정을 그래픽 UI로 처리할 수 있는 아주 훌륭한 툴이 있다. 이 툴에서는 각 인증서의 신뢰관계를 그래프로 아주 보기좋게 표시해 준다.
XCA – X Certificate and key management이며 리눅스, 맥, 윈도우에서 사용 가능하다.

거의 대부분의 자료 출처 : http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/

주옥같은 한국식 공인인증서 말고… SSL/TLS를 위한 국제표준식 인증서를 생성하기 위한 작업이다.
OpenSSL을 사용하므로 리눅스나 맥에서 작업해야 하겠다. 윈도우에서는… 시그윈 깔면 될지도 모른다. (안해봄)
물론 생성한 인증서는 국제표준이므로 윈도우에서도 사용 가능하다.

다음 내용에 따라 생성한 CA는 어디까지나 사설 인증서이므로 아무도 신뢰해주지 않는다.
수동으로 신뢰목록에 추가해줘야 하고, 키가 유출되지 않도록 매우 신중하게 관리해야 한다.
가능하다면 접근제어가 가능한 폐쇠형 네트워크에서만 사용하는게 좋겠다. 예를들면 테스트용 서버라던지…

1. CA 생성
CA : Certificate Authority는 인증서 신뢰성을 보장해주는 인증기관을 나타낸다. 형태자체는 똑같은 인증서다.
공인인증기관의 최상위인증서(RootCA)는 시스템이나 브라우저 차원에서 신뢰하는 인증서 목록으로 보유하고 있다.
이런 인증기관은 Web of Trust의 제3자 감시를 받으므로 신뢰성을 인정받는 것이다. 국내에서는 최근에 KISA가 Web of Trust 인증을 받았다.

사설인증에 사용할 CA인증서를 하나 만들어야 한다. 이 인증서는 RootCA로 작동할 것이며, Intermediate CA는 안 만들거다.
인증서 생성은 우선 RSA 열쇠쌍을 만드는 것부터 시작한다. RSA 2048비트 키를 생성한다.

openssl genrsa -aes256 -out rootCA.key 2048

이 키는 RootCA의 개인키가 저장되므로 절대 외부로 유출되면 안된다.
접근제어를 위해 AES256으로 암호화하여 저장하며, 키 접근용 암호를 두 차례 입력한다. rootCA.key 파일이 생성된다.
rootCA.key 파일은 퍼미션 400으로 바꿔주자. 이 파일은 (유출되어 Revoke되지 않는 이상) 바뀔 일이 없다.

이제 Self-signed CA를 만들어야 한다.

openssl req -x509 -new -nodes -key rootCA.key -days 3650 -out rootCA.pem

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:KR
State or Province Name (full name) [Some-State]:Seoul
Locality Name (eg, city) []:Seoul
Organization Name (eg, company) [Internet Widgits Pty Ltd]:TEST Certificate Authority
Organizational Unit Name (eg, section) []:TEST Certificate Authority
Common Name (eg, YOUR name) []:TEST Certificate Authority
Email Address []:[email protected]

days 옵션에는 RootCA의 유효기간을 일 단위로 입력한다. 너무 짧으면 불편하고 너무 길면 보안문제가 생길 수 있다. 적당히 1년에서 10년 사이로 입력하자.
RSA키를 만들때 암호화 해 두었다면 암호부터 입력해야 한다. 이후 인증서 정보를 입력해야 한다. 주어진대로 차분히 입력하자.

이렇게 만들어진 PEM파일에 루트 인증서 정보가 저장된다. 이 파일에는 공개키 정보만 저장되어 있으므로 배포해도 무방하다.
물론 이걸 받는 사람이 신뢰할지 여부는 전적으로 상대방에게 달려있다.

2. 사설인증서 생성
사설 RootCA를 생성했으니 이제 개별 서버에서 사용할 인증서를 만들어줘야 한다. 이 절차는 인증서를 필요로 하는 서비스마다 한 번씩 수행해야 한다.
우선 각 서버에서 사용할 개인key를 생성한다.

openssl genrsa -out device.key 2048

이 키는 각 인증서에 할당되는 고유 개인키이다. 역시나 유출되면 안 되므로 필요하면 암호화하여 저장하자.
다만 암호화한 경우 서버를 재시작 할 때마다 암호를 입력해야 한다. 서버 관리자가 알아서 판단할 부분이다.

키를 생성했으면 이제 CSR 파일을 생성해야 한다. Certificate Signing Request = 말그대로 서명요청 파일이다.

openssl req -new -key device.key -out device.csr

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:KR
State or Province Name (full name) [Some-State]:Seoul
Locality Name (eg, city) []:Seoul
Organization Name (eg, company) [Internet Widgits Pty Ltd]:TEST Server
Organizational Unit Name (eg, section) []:TEST Server
Common Name (eg, YOUR name) []:your-service.address
Email Address []:[email protected]

입력요령은 RootCA때와 같으나 서버 정보를 입력한다.

이 때 가장 중요한 것이 Common Name이다. 서버의 도메인 주소를 정확하게 입력해야 한다. IP로 접속한다면 IP주소를 입력한다.
이 주소가 틀리면 정확하게 Signing되더라도 인증서 오류를 낸다. 따라서 서버 주소가 바뀐다면 인증서도 새로 발급받아야 한다.

잘못 입력하면 어떻게 되는지는 https://www.rootca.or.kr 에서 무슨 일이 벌어지는지 참고할 것.

이 파일을 Device key로 서명하면 Self-signed 인증서가 되는거고, RootCA key로 서명하면 CA-signed key가 되는 것이다.
이제 RootCA key로 서명한다.

openssl x509 -req -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out device.crt -days 365

이제 개별 서버용 인증서가 발급되었다. crt 파일과 개인 키를 서버에 올려서 사용하면 된다.

맥북에서 부트캠프로 윈도우를 설치하면 하이브리드 MBR로 시스템이 구성된다. 덕분에 고생을 좀 해서 글을 남김.

사실 하이브리드 MBR은 표준에 부합하지 않는 변칙 구성이다. 잘 구성된 환경에서야 어떻게든 굴러가겠지만, 조금만 삐끗하면 구성이 틀어지면서 4차원으로 날아간다.
이는 맥 계열이 인텔 EFI 2.0을 구현하지 않기 때문이다. 맥 계열에서는 EFI 1.x를 구현하며, 이는 윈도우 등 다른 OS와 호환성이 없다.
따라서 윈도우 설치를 위해 BIOS를 에뮬레이션 하며, 덕분에 GPT 미지원, 그리고 하드웨어 퍼포먼스 하락 등 다양한 문제가 발생한다.

애플이 나쁜거라고!

1. 하이브리드 MBR
MBR과 GPT가 무엇인지는 알아서 검색하시라. 사실 이게 뭔지 모른다면 이 글을 읽을 필요도 없을 것이다.
여튼 GPT에서는 최소한의 하위 호환성을 보증하기 위하여 Protective MBR을 구현한다.

사실 보호MBR은 별거 없다. 구형 OS에서 GPT 디스크를 열었을 때 “이 디스크는 니가 모르는 파티션으로 꽉 차있어”라고 보이게 만드는 것이다.
이렇게 함으로써 우발적인 디스크 초기화(=0번 섹터를 밀어버림) 및 GPT 데이터 훼손을 방지한다.

보호MBR은 단일 파티션을 가지며, 해당 파티션의 타입은 EEh, 그리고 1번 섹터부터 GPT 파티션의 마지막 섹터까지 스팬하도록 구성된다.
물론 2TB보다 큰 디스크에서는 그냥 2TB 경계까지만 스팬한다. 2TB 경계를 넘어가는 영역은 MBR 만으로는 죽었다깨나도 접근 못한다.

하이브리드MBR은 보호MBR을 변형한 형태다. 알다시피 MBR에는 4개까지 파티션 테이블을 저장할 수 있는데, 보호MBR은 이 중 하나만 사용한다.
그렇다면 남은 3개 테이블에 값을 넣어 쓸 수 있지 않을까, 에서 시작한게 하이브리드MBR이다.

맥에서 부트캠프를 설치하면, 보호MBR은 첫 번째 파티션(애플EFI)만을 보호하도록 설정된다. 두 번째와 세 번째는 각각 맥OS 주 파티션, 복원 파티션으로 설정된다.
당연하지만 네 번째는 윈도우용 파티션으로 지정된다.
이렇게 함으로써 BIOS 모드로 부트해도 디스크의 파티션에 문제없이 접근할 수 있는 것이다. 추가 파티션은 못 만들지만!

2. 하이브리드 MBR에서 Mismatch 문제
자, 부트캠프를 이용하여 하이브리드MBR을 제작하면 GPT와 MBR 양쪽 모두 쓸 수 있다는걸 알았다. 그럼 뭐가 문제일까?
파티션 조작 툴이 이걸 이해 못한다는게 문제다. 거듭 말하지만 파티션 조작 툴의 문제가 아니다. 하이브리드MBR은 표준이 아니거든! 애플이 나쁜거다.

하이브리드MBR 디스크는 유효한 GPT와 MBR을 모두 가진다. 그렇다면 어느 걸 써야 할까? 아 고민된다.
이게 표준이 있으면 좋겠지만 아쉽게도 없다. OS마다 다르다는 이야기.

맥은 당연히 GPT를 우선 사용한다. 리눅스도 GPT를 사용한다. 윈도우는? MBR을 우선 사용.
더 웃긴건 윈도우에서 돌아가는 파티션 도구 중 일부는 GPT를 먼저 쓴다는 점이다. 어느거를 쓰는지는 케이스-바이-케이스. 해 봐야 안다.

여튼 파티션 크기가 바뀌지 않는다면 비일치 문제도 생기지 않는다. 문제는 파티션 크기를 바꿔야 할 때.
예를들어 고스트로 백업뜬걸 복구한다고 해 보자… 파티션 크기가 바뀝니다 지우고 새로 만들기 때문에.

하이브리드MBR을 제대로 지원해서 양쪽 다 올바로 수정해 준다면 상관이 없겠지만, 아쉽게도 그런 툴은 아직 존재하지 않는다.
어느 한 쪽만 휙 수정하고 만다. 덕분에 비일치 문제가 생긴다.

예를들어, 파티션툴로 윈도우 파티션 크기를 10GB 줄였다고 해 보자. 근데 이 툴이 GPT를 우선 인식했다!
이러면 GPT에서는 10GB 줄어들었고 디스크 뒤쪽에 10GB가 남게 된다. 근데 MBR에서는 여전히 디스크 꽉찼다고 나온다.

이 상황에서 다른 툴을 이용해서 윈도우 파티션크기를 다시 늘렸다. 근데 이 툴은 MBR만 인식한다. 이러면 MBR은 correct.
문제는 GPT는 10GB가 비어있는거로 나온다는 점이다. 아이고 머리야. 여기에 파티션이라도 만들었다가는? 데이터 오염으로 사망한다.

3. 어떻게 해야 하는가?
다행히도 gdisk 같은 툴로 만져서 MBR과 GPT 파티션 테이블을 직접 수정할 수 있다.
다만 잘못 건들면 디스크 전체가 날아간다.

4. 결론
하이브리드MBR은 웬만하면 쓰지 말자. 만약 써야 한다면 파티션 크기는 바꾸지 말자.
어쩔 수 없이 파티션 크기가 바뀌었다면, 매 번 동기화해 줘야 한다.

윈도우 KMS 클라이언트 인증용 키

http://technet.microsoft.com/en-us/library/jj612867.aspx

저 페이지에 있는 키를 설치하는 경우, 정당한 KMS 인증을 못 받으면 라이센스 무효다.

소속기관에서 윈도우 8.1 설치 이미지를 배포 안 하는 경우
MSDN 이미지 + KMS Key 로 설치후 KMS 인증을 받는다.

호스팅 이전하고서 문제가 생겼으니, wiki에서 한글 URL을 제대로 받아먹지를 못한다.

영어는 잘 되는데 한글은 CP949로 인코딩하면서 문제가 생기는 듯.
분명 크롬은 URL을 UTF-8로 인코딩해서 넘길 터인데, Escape된 주소를 보면 CP949. 이상하다…
혹시나 해서 IE에서 옵션 확인 후 해 봤지만 실패, 리눅스에서 wget을 날려도 실패.
UTF-8을 직접 떠낸 후 손으로 Escape 해서 보내도 자동으로 바뀐다. 허허허 뭐가 문제지.

알고보니 서버쪽 설정이 좀 잘못되어 있는 것 같다. mod_rewrite에서 UTF-8을 받아도 CP949로 바꿔버리는 듯.

.htaccess 의 적당한 부분에 다음 내용을 추가하면 된다. 서버 환경에 맞게 코드페이지는 바꿔줄 것.
내 경우는 서버와 클라이언트(=웹페이지 인코딩) 모두 UTF-8이니까 아래처럼 설정하였다. Reference 는 못 찾겠다.

ServerEncoding UTF-8
ClientEncoding UTF-8

편의상 이니셜로 표기한다.

2008년 10월부터 X모 업체에서 웹호스팅을 받아오던걸 이번에 M모 업체로 이전하였다.

사실 개인 홈페이지라고 해봐야 메인페이지는 404 Not Found로 돌려두고, 간단히 개발한 웹앱 테스트나 위키 용도로 굴릴 계정이다.
당연히 유지비용 저렴한 업체 위주로 알아보게 되었고, 1년 13200원 = 월 1100원에 호스팅하던 X모 업체에 호스팅을 개설하였다.

그리고 6년이 흘러 현 시점. 대부분의 서버 환경이 한참 업그레이드 되어 PHP5.6.x이 나오는 세상이 되었다.
하드웨어도 64비트 환경이 기본이 되었고 일부 서비스는 SSD를 스토리지로 사용하는 세상이다.

하지만 내가 쓰는 서비스는 08년 신청하던 그대로 그 환경.
사실 커널이 32비트인지 64비트인지, 스토리지가 HDD인지 SSD인지는 이런 소규모 홈페이지에서는 아무래도 상관없는 문제이지만,
서버 환경이 오래된 버전으로 남아있는 것은 좀 심각한 문제상황이다. 특히나 PHP5.2.x 로 남아있는 것은 영 좋지 못한 상황이겠다.
보안 문제도 있고, 각종 오픈소스 어플리케이션들도 PHP 예전 버전에 대한 지원을 중단하는 단계로 넘어갔으니까.

X모 업체에 문의도 해 보았지만 “호환성 문제로 업그레이드 예정 없음”이라고 통보해 왔다. 그야말로 사망선고.
그러던 와중, PHP5.5.x 서비스를 시작한다는 M모 업체를 발견하게 되었고, 이 참에 호스팅을 옮겼다. 1년 23100원 = 월 1925원 꼴.

물론 M모 업체에서도 호환성 문제를 이유로 PHP5.3.x 환경을 기본값으로 두고 있다.
PHP5.5.x 선택하면 “호환성 문제는 지원 못 해 주며 직접 해결해야 한다”는 경고부터 띄우고 본다.

뭐 아무렴 어떤가, XE나 그누보드는 이미 지워버린 상황인데. 호스팅 신청하고 귀찮은 데이터 이전작업도 마쳤다.
사용중인 위키 엔진이(물론 외국산) 2012년에 릴리즈된 버전인데, PHP5.5.x 환경에서도 아무 이상없이 작동한다.
어머나 세상에… 이게 바로 코딩 가이드라인을 준수하는 개발이구나. 약간의 충격과 씁쓸함을 감출 수 없었다.
물론 UTF-8 문제로 머리가 좀 아프지만, 어떻게든 완료될 것 같다. 서버환경 문제로 보이니까.

대한민국 웹호스팅은 결국 제로보드와 XE 돌리는걸 최우선 목표로 하고, 개인 개발 어플리케이션도 유지보수는 포기한 경우가 많다.
하여 서버 환경이라도 손댔다가는 대참사가 벌어지는 탓에 대부분의 서버가 PHP5.2.x 를 벗어나지 못하고 있다.
그나마 일부 업체에서는 최신 환경이라면서 PHP5.3.x 환경을 제공하지만, 이 또한 End of Life 로 접어들어 더 이상의 버전업은 예정이 없는 상태다.

일부에서는 제로보드4.x를 개인이 뜯어고쳐서 쓰는 탓에 PHP4.x + EUCKR 이라는 정말 끔찍한 레거시 환경이 아직까지 살아있는 경우도 있다.

이번에 호스팅을 옮기면서 위키 엔진이 아무 트러블 없이 PHP5.2.x -> PHP5.5.x 마이그레이션에 적응하는 것을 보면서 새삼스럽지만 이것저것 많이 생각해보게 된다.

http://superuser.com/questions/64471/create-rename-a-file-folder-that-begins-with-a-dot-in-windows

윈도우에서 파일/폴더 이름을 . 으로 시작하게 만들려면…

.gitconfig.

으로 입력하면 된다. 마지막 . 은 알아서 삭제된다. 아 문화충격…

참고로 XP는 안된다고 한다. 윈도우7, 8에서 작동 확인됨.

사실 개인 프로젝트는 GitHub이나 bitbucket 써도 된다. 회사 일 때문에 내부 서버를 써야 할 때에나 도움이 될 듯.

1. 하드웨어 준비

실제 머신이 있으면 좋겠지만 돈도 없고 배선도 귀찮고 공간도 좁다. 가상머신 사용하기로 함.
윈도우에서 가장 안정적인 VMware 사용. VM Player는 non-commercial 조건으로 공짜로 사용가능하다.

싱글코어 + 메모리 512MB, 가상 디스크는 4GB, 16GB 두 개로 생성.
작은거에 부트 + 시스템 + 스왑 다 때려박고, 큰거는 온전히 레포지터리 저장용으로만 사용한다.

2. archlinux 설치

https://wiki.archlinux.org/index.php/Installation_Guide

사실 리눅스 배포판에는 ubuntu나 centos 기타등등 유명한게 많지만, 그만큼 덩치가 크다.
git server만 굴릴것이므로 가볍고 용량작은 + 패키지매니저 지원하는 배포판 찾아보니 archlinux가 만만해보임.
apt 사용하려면 lubuntu같은 버전 써도 될거다. 그래도 시스템파티션 크기는 키워야 하겠지만.

https://www.archlinux.org/ 에서 ISO를 다운받는다. 홈페이지에서는 Netboot 추천하는데 잘 안된다.

Live모드로 부트하면 콘솔에서 키보드 커서가 깜빡거리는 상황을 맞이하게 된다. 정상이다(…)
위키페이지를 찬찬히 읽으면서 수동으로(…) 설치하자.

설치할 때 파티션 설정을 조심하자. 마지막거만 주의하면 된다. 저기에 git 저장소가 들어가니까 큰 파티션을 잡아준다.
참고로 루트를 저만큼 잡아도 이것저것 세팅+삽질 이후에도 1.2GB 사용한다. 충분히 넉넉하다는 말임.

/dev/sda1 = /boot 300MB
/dev/sda2 = /     2.7GB
/dev/sda3 = SWAP  1GB
/dev/sdb1 = /srv  16GB **

3. 패키지 설치 및 설정

설치가 완료되면 일단 루트로 로그인한다. 일반계정에서 sudo 사용하려면 visudo 로 설정을 하나 풀어줘야 한다.

wheel 검색한 후 주석을 풀어주고 :wq 하면 wheel 그룹 유저는 sudo 사용이 가능하게 풀린다. 이제 필요한 패키지들을 설치하자.

# pacman -S --needed base-devel wget openssh git
...
# systemctl enable sshd.service
...

4. SSH 설정

https://wiki.archlinux.org/index.php/Secure_Shell

ssh 데몬 설정 편집은 /etc/ssh/sshd_config 파일을 고치면 된다. 적어도 포트번호 변경하고 루트 SSH 차단은 설정해 두자.
설정이 완료되면 ssh 데몬을 재시작하거나 시스템을 재시작.

이제 일반유저로 로그인한다. 원격으로 git을 사용해야 하는데, git 계정의 비밀번호를 까발리고 다닐 수는 없으니 인증키 방식 로그인을 사용해야 한다.

디테일한 내용은 http://opentutorials.org/module/432/3742 등 온라인에 자료 많으니까 넘어가자. 기본값으로 키를 만들면 된다.
암호는 쓸거면 입력하고(당연히 이쪽이 보안상 좋다) 자동로그인이 필요하면 안 만들면 된다.

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/myname/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
...

key를 만들면 ~/.ssh 폴더에 파일 두 개가 생성된다.
혹시모르니 개인키 파일의 권한을 확인한다. 개인키 파일(id_rsa) 권한은 반드시 600이어야 한다.

$ ls -al ~/.ssh
...
-rw------- 1 myname users 1766 Jan 01 00:00 id_rsa
-rw-r--r-- 1 myname users  399 Jan 01 00:00 id_rsa.pub

5. Gitosis 설치

https://wiki.archlinux.org/index.php/Gitosis
https://wiki.archlinux.org/index.php/AUR

아까 git도 설치했었다. 버전 확인하고 설정도 좀 바꿔준다.

$ git --version
git version 1.9.0
$ git config --global user.name "John Doe"
$ git config --global user.email "[email protected]"
$ git config -l
user.name=John Doe
[email protected]

이제 저장소 권한관리 도구인 Gitosis를 설치하자. Gitosis를 이용하면 저장소 별로 접근권한 제어를 할 수 있다.
접근권한 제어는 별도 툴이 있는건 아니고, gitosis-admin 이라는 git 저장소에 키파일과 설정파일을 커밋하면 알아서 반영된다. git으로 git을 관리하다니.

여튼, 원래 Gitosis를 설치하려면 파이썬 깔고 어쩌고저쩌고 해야 하는데, 누군가 고맙게도 이걸 자동화 시켜뒀다.
다만 archlinux 기본 패키지로는 반영 안 돼서 수동으로 패키지 파일을 만들어서 깔아야 한다. 별로 어렵지는 않다.

우선 https://aur.archlinux.org/packages/gitosis-git/ 에서 타르볼을 다운받고 압축을 해제한다.

$ wget https://aur.archlinux.org/packages/gi/gitosis-git/gitosis-git.tar.gz
...
$ tar -xzf gitosis-git.tar.gz
...

압축 풀은 폴더로 들어가서 makepkg로 패키지파일을 만든다. 의존성 해결을 위하여 -d 옵션을 준다.
패키지 빈 게 있어서 sudo 권한을 요구할거다. 설치하고 잠시 기다리면 타르볼을 만들어준다.

$ cd gitosis-git
$ makepkg -s
...
$ ls -al
...
-rw-r--r-- 1 myname users 53552 Jan 01 00:00 gitosis-git-0.2.r50-g9481bb0-1-any.pkg.tar.xz
...

만들어진 타르볼을 패키지 매니저로 설치한다.

$ pacman -U gitosis-git-0.2.r50-g9481bb0-1-any.pkg.tar.xz
...

이제 간신히 Gitosis 패키지를 시스템에 설치한 것이다.

6. Gitosis 설정

이제 Gitosis를 실제로 작동하게 만들자. 루트 권한으로 작업한다.
git이라는 유저는 git 설치과정에서 자동으로 만들어진다.

$ sudo mkdir /srv/gitosis
$ sudo chown git.git /srv/gitosis
$ sudo -H -u git gitosis-init < ~/.ssh/id_rsa.pub
Initialized empty Git repository in /srv/gitosis/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /srv/gitosis/repositories/gitosis-admin.git/

여기까지 하면 git 서버가 작동하는 것이다. 클로닝 해 보자.

$ git clone ssh://git@localhost:22222/gitosis-admin.git
...

ssh-keygen 에서 암호를 입력했으면 암호를 물어볼거다. 입력하면 된다.
클로닝까지 성공하면 Gitosis 설치가 완료된 것이다.

사용자 추가는 keydir 안에 RSA 공개키 파일을 넣어주면 되며, 파일명이 곧 계정명으로 사용된다.
접근권한 설정은 gitosis.conf 에서 한다. 자세한 설정방법은… google it.

개발자에게 CP949라고 하면 으레 EUC-KR을 기반으로 MS에서 확장 정의한 코드페이지를 생각할 것이다.
PC에서 한글을 표현하는 방법으로서 사실상 표준으로 사용되고 있고[footnote]아직 유니코드로 완전히 이전되지 못했다. 인터넷만 봐도 여전히 많이 쓰이는데 뭐…[/footnote], 당장 위키피디아CP949 페이지를 들어가봐도 Microsoft’s implementation으로 문서가 시작한다.

위키피디아의 CP949 Map

여튼. 어쩌다보니 MBCS 텍스트의 코드페이지를 바꿔 해석해야 하는 코드스냅이 필요하여 자바로 코드를 짜게 되었다.

예를 들면 이런거다. Shift-JIS에서 특수문자 “☆”은 0x8199 로 매핑되는데, 이를 CP949로 해석하면 “걲”이 된다.
이런 사유로, Shit-JIS에서 “☆新年☆”이라는 문자열이 CP949에서 “”걲륷봏걲”이 되어버린다. 허허허…

필요한 코드는 이를 바로잡아주는 코드인데, 사실 코드 자체는 정말 간단하다.

자바는 문자열 처리에 UTF-16BE를 사용하며, 필요한 경우 이를 꽤나 편리하게 바이트 스트림으로 변경이 가능하며,
반대로 바이트 스트림에서 코드페이지를 지정하여 문자열을 만들어낼 수도 있다.

public static String convertCodepage(String src, Charset cpCurrent, Charset cpNew)
{
	byte[] b = src.getBytes(cpCurrent);
	String n = new String(b, cpNew);
	// 사실 한 줄로 줄여도 된다.
	return new String(src.getBytes(cpCurrent), cpNew);
}

이런 코드를 짜고, 파라미터로 CP949를 적용하면 잘 될 줄 알았다.

근데 안 된다 -_-

차근히 찾아보니 자바에서 CP949는 MS 구현이 아니랜다. Charset 클래스에서 CP949는 x-IBM949의 동의어로 처리된다.
흠 그런가? 하고 좀 더 찾아보니, x-IBM949는 단지 EUC-KR에 확장 ASCII 코드를 몇 개인가 더 붙여둔 것 같다.

즉슨, 안타깝게도 x-IBM949는 KS-X-1001[footnote]일부에게는 KS-C-5601이 더 익숙할지도 모르겠다.[/footnote]에 정의된 8,848글자의 한글만 표현할 수 있으며, 이를 벗어나는 이른바 “확장 한글”[footnote]CP949에서 추가로 정의된 글자들. 예를들면 “똠”이나 “쓩”, “뷁” 같은거[/footnote]은 표기할 수 없다.

그렇다면 자바에서 MS 확장을 사용할 수는 없는걸까? 물론 쓸 수 있다. MS 확장 구현은 “MS949″로 정의되어 있다.
위의 코드에서도, 파라미터만 MS949로 변경하니 의도한대로 잘 작동하는 것을 확인할 수 있었다.

다만 안타까운 사실은, 이것을 찾아내는데 장장 세 시간이 넘게 걸렸다는 점 정도일까. 선마이크로시스템즈 나쁜색기들.

맥북에어는 외부모니터 연결 단자로 miniDP 단자만 제공한다. 아직은 HDMI나 DVI가 많이 사용되므로 젠더가 필요하다.

어쩌다보니 넷메이트 제품만 줄줄이 달아두게 되었는데 딱히 스폰받은건 아니고 -.-
룡산에서 집어온게 넷메이트 젠더(가운데거)라 찾기 쉬워서…

miniDP – HDMI(숫) 케이블(2미터) : http://prod.danawa.com/info/?pcode=1216123
맥북과 HDMI 모니터를 직접 연결할 수 있다.

miniDP – HDMI(암) 젠더 : http://prod.danawa.com/info/?pcode=1230327
별도의 HDMI 케이블이 필요하지만 휴대가 간편하다. 요즘 웬만한 세미나룸은 HDMI 케이블을 구비하고 있으니, 휴대가 목적이면 이쪽이 더 편리하다.

miniDP – DVI/HDMI/DP 멀티젠더 : http://prod.danawa.com/info/?pcode=1535693

참고로 상기 링크는 전부다 passive 방식이며, 최대 해상도 1920×1200까지만 지원한다.
2560×1440 이상 해상도로 넘어가려면 active 방식 젠더를 사용해야 한다. 애플 정품이 17만원 정도 한다.

학교 메일서비스가 용량이 뭐같이 작아서 (교수/교직원 500MB, 대학(원)생 50MB, 졸업자 5MB…)
메일 자동 포워딩을 이용하여 구글 지메일을 실질적인 메일서비스로 쓰고 있었다.
(물론 설정 잡아주면 학교메일 주소로 발송 가능하므로 이렇게 쓸 수 있었다. 나이스 구글.)

며칠전에 학교 메일이 구글 앱스에 연동된다는 공지가 돌았다. 즉, 아예 학교메일 주소로 구글 서비스 로그인과 메일 수발신을 지원한다는 것.
물론 지금 상태로 냅둬도 되지만, 몇 가지 사소한 장점을 핑계로 구글 앱스로 옮겨버렸다.

– 기존 방식으로는 메일포워딩으로 서버를 한 번 더 거치면서 메일 수신이 1~2분정도 지연되는 경우가 있다.
– 지메일 기본 계정은 15GB이지만 구글 앱스 사용시 기본 30GB를 준다. 지금 사용량이 8GB를 조금 넘는 정도라 별 문제는 없지만, 용량은 다다익선.
– 졸업이후 따로 아카이브를 안 해도 된다.

여튼. 구글 계정을 옮겼으니 기존에 쓰던 개인계정에서 새로만든 구글앱스 계정으로 데이터를 옮겨야 한다.
옮길 데이터를 크게 정리하자면 1. 메일 2. 주소록 정도.

사실 주소록 이전은 간단하다. 기존 계정에서 주소록 내보내기 -> 새 계정에서 주소록 가져오기를 하면 잘 이전된다.
드라이브와 캘린더는 안 써서 모르겠다. 다른 서비스는 구글앱스 계정에서 미지원이고.

문제는 메일.
구글에서 자체적으로 이전이나 백업복원을 지원하지는 않고, 인터넷 검색해보면 보통 IMAP 활성화한 다음 메일 클라이언트로 수동으로 옮겨라 식의 가이드만 나온다.
그런데, 이렇게 IMAP으로 하나씩 옮기는건 시간이 보통 오래걸리는 일이 아니다. 작년쯤인가 약 3년분 6천건의 메일을 업로드 하는데만 하루가 꼬박 걸렸으니 뭐.
(사실 이건 IMAP 클라이언트의 비효율적인 작업절차 때문이기도 하다. 메일 하나 올릴 때마다 세션을 새로 열어서 작업하니 뭐…)

하물며 현 시점에 메일은 더 쌓여서 약 8200건 정도고, 용량도 약 8GB를 넘는다. 이걸 메일 클라이언트로 다운로드 받아서 업로드를 새롭게 하려면… 두통이 엄습한다.

이런 고민을 한 사람이 나 뿐이지는 않을테니 좀 더 검색해 본 결과 다음과 같은 프로그램을 찾았다.

Gmvault: gmail backup

제목대로 지메일 백업하는 프로그램인데, 계정정보를 바꿔치기 해서 계정간 데이터 이전에도 쓸 수 있고, 메일 라벨(폴더기능)도 잘 지원한다.
타 클라이언트가 복수 라벨을 제대로 취급 못해서 메일 사본을 만들어내는데, 이 프로그램은 정확하게 라벨을 찾아서 반영해준다.

다만, 파이썬 기반이라 작업을 콘솔에서 명령어 쳐서 해야 하는게 좀 불편할지도 모르겠다.
사용할 지메일 계정에서는 IMAP 사용설정을 해 줘야 하고, 전체편지함을 IMAP에서 볼 수 있도록 활성화도 해 줘야 작동한다.
설정이 제대로 안 되어 있으면 오류를 뿜어내니 잘 읽어보자.