원격 저장소가 SVN인데 로컬에서 git을 사용하고 싶다면 어떻게 해야 할까.

타 연구실과 공동 작업을 하는데, 원격 저장소가 SVN이다. 근데 연구실에서는 git 기초사용법만 교육한 상태.
git-svn을 알려주면 망할 것 같고, SVN을 쓰자니 영 불편하다. 어짜피 이쪽에는 마일스톤 달성한 것만 올리면 된다.

둘 다 같이 쓸 수 있는 방법은 없을까.

이렇게 할 수 있다. 폴더를 두 개 만들고, 편의상 S, G라고 하자.
S폴더는 SVN 체크아웃 후, 일정 주기로 업데이트. 리비전이 올라간다면 패치를 따서 G폴더에 병합한다.
G폴더는 GIT 저장소로 로컬 운영. 여기에서 주요 개발을 진행한다. S폴더의 패치는 master에 병합 후 dev에 병합.
G폴더에서 마일스톤 달성하면, master로 병합을 완료한 후 패치를 따서 S폴더에 병합, SVN 저장소에 최종 커밋한다.

결국 G폴더의 master가 SVN 저장소와 동기화된다. 사실상 git-svn이 하는 백그라운드 작업을 손으로 대신하는거다.
멍청해 보이지만, SVN도 git도 모두 사용해본 경험이 없는 사람에게는 최선인 방법이다.

근데 번거롭다. 매 번 패치를 따서 넘겨주고 넘겨받고 해야 한다. conflict 발생하기도 쉽고 빼먹은게 생길수도 있다.

구글을 돌려보자. 대체로 내가 하는 고민은 누군가 했던 고민이다.
2012년 9월말에 이미 솔루션이 나왔다. http://danielbachhuber.com/2012/09/30/git-in-my-subversion/

1. 우선 SVN 저장소를 체크아웃한다. 거듭 상기하자면, 여기는 마일스톤 달성한 커밋만이 올라갈 것이다.
2. 콘솔을 열고, git init 또는 git clone
3. SVN 프로퍼티를 추가한다. svn:ignore 프로퍼티에 .git, .gitignore 를 추가한다.
4. .gitignore 파일을 만들고, .svn 을 추가한다.
5. 이제 SVN과 git은 서로의 메타데이터를 서로 무시하게 되었다. 메데타시 메데타시

몇 가지 주의사항을 지켜야 한다.
1. SVN 브랜치 기능은 쓰지 않는다. git이 있으니까 필요가 없다.
2. SVN 다른 브랜치에 접근해야 한다면, 별도 폴더를 만들고 새롭게 git 저장소를 만들어야 한다.
3. SVN update 하기 전에 반드시 git master이며 clean인지 확인한다.
4. SVN update 이후 리비전이 바뀌었다면(즉, 서버쪽에 변경사항이 있다면) 이를 git master에도 커밋한다.
5. git에서 하나의 개발 흐름이 완료되었다면, 이를 git master로 병합한다. 이후 git master를 체크아웃한 뒤 SVN 커밋한다.
6. git에서 개발도중에는 SVN에서 modification이 많이 검출될 것이다. 무시하라. git만 신뢰한다.

** 참고 : 아래의 모든 과정을 그래픽 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은 웬만하면 쓰지 말자. 만약 써야 한다면 파티션 크기는 바꾸지 말자.
어쩔 수 없이 파티션 크기가 바뀌었다면, 매 번 동기화해 줘야 한다.

소니 엑스페리아 Z2 를 사용하는데, 일부 블루투스 페어링된 단말기는 블루투스 목록에서 숨겨진다.
예를 들면 스마트밴드(SWR10)이나 듀얼쇼크3 컨트롤러 등이 이에 해당한다.

프로그램 만들면 수동으로 페어링 단말기 목록 추출이나 삭제가 가능한데 귀찮다 -_-
역시나 친절하게도 다른 사람이 만들어 둔 게 있다.

https://github.com/lorensiuswlt/AndroBluetooth
샘플 APK 수동 설치 후 Paired Deivces 들어가서 Unpair 누르면 삭제된다.
안드로이드 4.4.4 (Z2 빌드번호 23.0.1.A.0.167) 에서 정상 동작 확인.

APK 수동 설치는 안드로이드 보안 설정 해제를 필요로 하며 이는 피싱 사기 등 심각한 보안 위협이 될 수 있다.
필요한 경우에만 잠깐만 설정을 해제하고, 사용이 끝난 경우 다시 설정하도록 한다.

윈도우 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 마이그레이션에 적응하는 것을 보면서 새삼스럽지만 이것저것 많이 생각해보게 된다.