Dharma

일단 링크부터 

https://github.com/facebook/hiphop-php/wiki

입니다.  php 로 시작한 페이스북이 대용량 접속을 처리하기 위해서 php 모듈을 c++ 로 변환해주는 방식을 쓴다고 알려져 있었습니다. 그런데 요즘 페이스북이 베타버젼중인 Node.js 로 갈아탔다고 합니다. 그러더니 자신들이 사용하고 있던 그 라이브러리를 오픈소스화 시켰습니다. (사실 이때쯤 유명해지기 시작했다는 것이 더 사실에 가까울 것입니다) 예전 Scribe 때와 똑같은 현상입니다. 카산드라도 그랬던가? 이건 확실하지 않네요. 

구글은 자신들이 계속 사용할 기술들을 오픈소스화 시키는 반면에 페이스북은 자신들이 더이상 사용하지 않을 기술들을 오픈소스화 시킨다는 느낌이 강합니다.

만약 제가 PHP 사이트를 운영중인 회사의 CTO 고, 그 사이트가 최근 대폭적인 사용자의 증가로 계속해서 하드웨어를 늘리면서 버티고 있는 상황에서 기술을 도입해야 할 고민에 쌓여있다면,  고민에 빠져들만도 합니다. 

hiphop-php 를 써야 하나?
그런데 저는 node.js 로 전 사이트를 리팩토링 하는 방법을 선택할것도 같습니다. 왜냐면 페이스북도 hiphop-php 대신 node.js 를 선택했기 때문이지요.

제가 그래서 공개시점이 항상 애매하다고 생각하는 것입니다. 물론 기술적으로는 문제가 없겠지만, 페이스북이 node.js 를 선택한 시점에서 기술 선택을 해야 한다면 node.js 쪽으로 기울지 않겠습니까? 

제가 이런 막되먹은 생각을 마구 하는 이유는 Scribe 가지고 테스트 하다가 현행화가 안되서 고생한 것 때문에 삐져서 이러는 거 아닙니다 쿨럭.. (그리고 공개는 몇년전에 되어 있더군요 최근 활성화 되기 시작한것이지) 

저번 포스트 에서 Emacs 버젼을 24 로 업그레이드 한 후에 가장 큰 문제가 생겼습니다. Clojure 와 Common Lisp 개발환경이 동시에 안되는 문제가 발생했습니다. 

몇번의 노력끝에 결국 Emacs 에서도 편하게 설치하는 쪽을 받아들이게 됐습니다. 기존에는 "이맥스 유저는 이래야 해!!" 라는 말도 안되는 자존심으로 수동으로 이거 저거 설치하는 쪽이였으나 이제 대세를 받아들이기로 했습니다. 

클로져 (Clojure) 개발 환경 설정 

예전 포스트 에서 쉽게 설치하는 방법을 소개한 적이 있었습니다.  그러나 swank-js 를 만들었던 당사자가 더 훌륭한 솔루션이 나왔다고 GG 를 쳐버렸습니다. -0- (당신을 믿고 포스팅을 했었다고!!! ㅜ.ㅜ ) 

nRepl 을 설치해줍니다.  


설치법은 간단합니다. Emacs 24 버젼부터는 Package 관리가 기본으로 포함되어 버렸습니다. 대세는 게을러지기 아니겠습니까? 
.emacs 파일에 다음과 같은 내용을 추가합니다. 

(require 'package)
(add-to-list 'package-archives
    '("marmalade" . "http://marmalade-repo.org/packages/"))
(package-initialize)

그리고 재 시작후 , M-x list-packages 로 출력해서 nrepl 을 찾아서 설치해 주거나 , 설명 페이지에서 추천하는 대로 

M-x package-install [RET] nrepl [RET]

로 설치해주시면 됩니다. 추가로 편리하게 사용하기 위해서 세팅 몇가지만 해주시면 됩니다. 

(add-hook 'nrepl-mode-hook
     (defun clojure-mode-slime-font-lock ()
         (let (font-lock-mode)
             (clojure-mode-font-lock-setup))))

이제 클로져 관련 파일을 열고나서 M-x nrepl-jack-in  를 입력하시면 익숙한 REPL 버퍼가 보일 것입니다. (속도도 Swank-js 보다 빨라졌습니다)


Common Lisp 개발 환경 설정 (SLIME 설정)
 
이제 이것 설치도 쉽게 하는 방법이 있습니다. SBCL 은 이미 설치되어 있다고 가정합니다. (참조사이트 : http://www.mohiji.org/2011/01/modern-common-lisp-on-linux/ ) 

일단 quicklisp 파일을 다운 받아야 합니다. http://beta.quicklisp.org/quicklisp.lisp 에서 받아줍니다. 적당한 곳에 옮겨주시고요. 


sbcl 을 실행시켜줍니다.


sbcl 상에서 위와 같이 quicklisp 파일이 받아진 것을 읽어들입니다.  


그리고 위와 같이 연속으로 실행시켜줍니다.  이러면 자연스럽게 SLIME 까지 설치가 됩니다. 이제 Emacs 에게 위치를 알려주는 일만 해주면 됩니다. 

(setq inferior-lisp-program "sbcl")
(load (expand-file-name "~/quicklisp/slime-helper.el"))

이제 M-x slime 을 입력하면 자연스럽게 SLIME REPL 이 뜨게 됩니다.  

May The Source Be With You !!!
 

같이 일하는 후배분들에게 PKI 기본 개념을 설명해 주기 위해서 만들었던 자료입니다. 기왕 만든 김에 공개해 볼까 합니다. (10년도 더 전에 했던 내용을 정리한 거라 요즘 트렌드랑은 안 맞을 수도 있지만 기본이야 어디 가겠습니까? ㅎㅎ) 

PKI 는 Public Key Infrastructure 의 약자 입니다. 그대로 해석해서 '공개 키 기반' , 또는 '공개 키 인프라' 라고 해석할 수가 있습니다.  

 
RFC 2459 바로 그 표준에 관한 문서입니다. 이 문서를 보시면 PKI 에 관한 상세한 내용을 다 아실 수가 있습니다. 예전에 눈에 모래바람이 일어날 정도로 열심히 봤던 기억이 나는군요. X.509 는 인증서 포맷을 의미합니다.

이 PKI 기반을 이해할려면 3가지 기본적으로 알고 있어야 하는게 있습니다. 바로 위의 세가지 입니다. 보통 '해쉬 함수' 라고 불리는 Message Digest 와 (그렇지만 일반적으로 Computer Science 에서 부르는 Hash 는 Data Structure 에서 쓰이는 형식을 의미 하기 때문에 보안쪽에서 쓰이는 '해쉬 함수'는 Cryptographic Hash Function 이라고 구별해서 부릅니다. ) 대칭키 (Symmetric Key Algorithm) 과 비 대칭키 (Asymmetric Key Algorithm) 입니다. 

해쉬 (Cryptographic Hash - 암호화 해쉬) 함수입니다. 주로 하는일은 메시지 축약 (Message Digest) 입니다. 아무리 긴 파일이라도 간단하게 축약시킵니다. 대표적인 암호화 해쉬 알고리즘으로는 MD5 와 SHA-1 이 있습니다. MD5 는 128bit 이고 SHA-1 은 160bit 입니다. 즉 결과가 MD5 는 16바이트 , SHA-1 은 20 바이트로 나온다는 것입니다.
사실 토렌트를 사용하시는 분이면 이 암호화 해쉬가 사용된 부분을 심심치 않게 볼 수가 있습니다. 토렌트상에 존재하는 영화파일들은 파일 이름을 자기 맘대로 정할수가 있기 때문에, 이 해쉬값으로 같은 파일인지 체크할 수가 있습니다. 즉 파일 이름이 다르더라도, 크기와 해쉬값이 같다면 같은 파일이라고 볼 수 있다는 것이지요. 
 

일반적으로 '암호화' , '복호화' 라는 말을 쓰긴 합니다. 그런데 이 용어는 나중에 전자서명쪽을 설명 하다보면 혼선을 줄 수가 있습니다.  따라서 Encryption 과 Decryption 이라는 용어로 통일하기로 합니다.  무엇인가 변경을 가하는 것을 인크립션 (Encryption) 이라 하고, 변경된 것을 다시 원 상태로 돌리는 것을 디크립션(Decryption) 이라고 보시면 됩니다. 

 
대칭키 알고리즘 입니다. 말 그대로 키를 한개만 이용하는 것을 말합니다. 즉 인크립션 (Encryption) 과 디크립션 (Decryption) 시 한개의 같은 키를 이용합니다. (원리만 설명하는 것이니 패딩이니 , 이니셜 벡터니 하는 것을 건너 뛰겠습니다) 일반적으로 영화 같은데서 나오는 암호관련한 비밀번호 원리는  거의 이것에 해당합니다. 물론 유닉스의 비밀번호는 단방향이라 암호화 해쉬 함수를 쓰긴 합니다만. 무엇인가 암호화 된 것을 풀어낸다는 말이 나온다면 거의 이것을 의미합니다. 알고리즘 자체는 바이트열에 대해서 XOR 연산등을 적용하는 것들이 대부분 이기 때문에 속도가 빠른편에 속합니다. 트리플 데스 (3DES) 나 AES 가 대표적인 알고리즘 입니다. 

바로 이런식으로 활용됩니다. 평문(Plain Text) 는 아무 변조가 가해지지 않은 글을 의미합니다. 원본이라고 보셔도 무방합니다. 일반적으로 누구나 볼 수 있는 문서 같은 의미로 받아들이면 됩니다. 반면 싸이퍼 텍스트(Cipher Text)는 변조된 문서입니다. 암호문이라고도 볼 수 있습니다. 내용을 알아볼 수가 없는 문서라고 보시면 됩니다.
이런 변경은 양방향이며 인크립션 (Encryption)과 디크립션 (Decryption)시 같은 대칭키 (Symmetric Key)를 이용합니다.

 
비대칭키 알고리즘 (Asymmetric Key) 입니다. 대칭키가 아니라는 말입니다. 이 알고리즘은 두개의 키를 이용합니다. 개인키 (Private Key)와 공개키 (Public Key) 가 바로 그것입니다. 키를 두개 쓰기 때문에 '대칭키가 아니다' 라는 비대칭키 알고리즘이라고 합니다. 이 알고리즘은 인크립션(Encryption)과 디크립션(Decryption)시 서로 다른 키를 씁니다.  대표적인 알고리즘으로 RSA가 있습니다. 세사람의 이름을 따서 부릅니다. 이 알고리즘은 소수(Prime Number: 1과 그 자신외에는 나눠지는 수가 없는 수)를 이용합니다. 따라서 조금 긴 내용을 인크립션(Encryption) 이나 디크립션 (Decryption)하면 시간이 걸립니다. 이 알고리즘의 근거는 리만 가설에 근거하기 때문에 미드 넘버스(Numbers) 에서는 이 가설을 깨서 모든 보안 상황을 다 제거하는 내용도 등장합니다. (뭐 현실은... -ㅅ- )

 

평문 (Plain Text)를 공개키(Public Key) 를 이용해서 인크립션(Encryption)합니다. 여기서 싸이퍼 텍스트(Cipher Text)라는 말을 안쓰고 Encrypted Text 라는 용어를 쓴것은 이게 딱히 암호화다 아니다 라고 말하기가 애매하기 때문입니다. 바로 뒷 장에 개인키(Private Key)를 이용해서 인크립션(Encryption)하는 내용도 나오기 때문입니다. 그림에서 보듯이 공개키(Public Key)를 이용해서 인크립션(Encryption)을 한다면 다시 디크립션(Decryption)할려면 꼭 쌍이 이루어 지는 개인키(Private Key)를 이용해야 합니다. 

보통 공개키를 가지고 인크립션을 하능 경우는 원하는 상대만 풀어주기를 바라기 때문에 암호화쪽에서 많이 씁니다. 그래서 통칭 공개키 '암호화', 개인키 '복호화' 라는 용어를 쓸때도 있습니다. (절대적인것이 절대 아닙니다) 

이 부분은 개인키(Private Key)를 가지고 인크립션(Encryption) 하는 경우입니다. 역시나 Encrypted Text 를 쌍이 되는 공개키(Public Key)로 풀어줍니다. 개인키 (Private Key)는 개인만 가지고 있고 공개키(Public Key)는 공개적으로 공개가 되어 있다는 가정하에 이러한 케이스는 개인이 보낸 내용을 증명할 때 많이 쓰입니다.  따라서 이러한 경우를 보통 개인키'전자서명' , 공개키 '서명 검증' 이라고 불립니다. 

이런 내용의 기반이 되는 가정이 있습니다. 바로 이름 그대로의 '공개키(Public Key)' 와 '개인키(Private Key)' 입니다. 


위와 같은 가정하에서 A 라는 사람만 풀어볼 수 있는 내용을 전달하고 싶으면, 만천하에 공개되어 있는 공개키로 인크립션 (Encryption) 한다면 , 그 당사자만 풀어볼 수가 있습니다. (A의 개인키는 A만 가지고 있으니까요) 

또 A 라는 사람이 어떠한 문서를 보냈다는 것을 확인하고 싶다면, A의 개인키로 인크립션 (Enctyption) 한 내용을 추가하면 됩니다. 그러면 공개키로 디크립션(Decryption) 해서 A 가 보냈는지 증명할 수가 있습니다.   

이 두가지가 바로 공개키 암호화 와 전자서명의 원리입니다. 그리고 이런 공개키 암호화와 전자서명을 사용할 수 있게 기반을 마련해둔 것이 PKI (Public Key Infrastructure) 입니다. 

그러면 실제세계에서 어떻게 쓰이는지 알아보기로 합니다. 설명에서 잠깐 언급했듯이 비대칭키 알고리즘은 대칭키 알고리즘에 비해서 많이 느립니다. 이 속도차이 때문에 현실세계에서는 살짝 복잡한 구조를 이용합니다. 

공개키 암호화에 쓰이는 포맷입니다. 물론 이보다 더 자세히 들어가면 더 복잡해지지만, 일단 이정도로 개념을 알고 있어도 충분할 것입니다. 앞에서 설명했듯이 공개키 암호화의 핵심은 받을 당사자만 풀어볼 수 있게 당사자의 공개키로 내용을 인크립션 (Encryption) 하는 것이 목적입니다.

그런데 위의 그림을 보면 임시 대칭키를 생성합니다. 이 이유가 바로 속도 차이입니다. 평문 (Plain Text) 가 만약 크기가 많이 크다면 이를 공개키를 이용해서 Encrypt 하는데 시간이 많이 걸립니다. 그래서 임시 대칭키를 자동으로 생성하고 이 대칭키로 평문 (Plain Text)을 Encrypt 해서 싸이퍼 문(Cipher Text)로 변경합니다. 그리고 그 생성한 대칭키를 메시지를 받을 A의 공개키(Public Key)로 Encrypt 합니다. (이 Encrypt 된 임시 대칭키를 풀 수 있는 사람은 세상에 A 본인 밖에 없습니다) 그래서 'Cipher Text' 와 A의 공개키로 Encrypt 한 'Encrypted Key' 를 한꺼번에 A에게 보내면 A는 'Encrypted Key'를 자신의 개인키 (Private Key) 로 Decrypt 해서 임시 대칭키를 얻어내고 그 임시 대칭키로 다시 Cipher Text 를 Decrypt 합니다. 그러면 평문(Plain Text)를 얻어낼 수 있는 것이지요. 

전자서명 프로세스의 간단한 설명입니다. 전자서명은 보낸 당사자가 보냈다는 것을 확인하는 절차입니다. 즉 평문 (Plain Text) 자체를 Encrypt 할 필요가 없다는 것입니다. 따라서 평문(Plain Text)를 암호화 해쉬 함수 (Cryptographic Hash Function) 로 축약을 하고 그 축약된 결과를 개인키(Private Key)로 Encrypt 합니다. 이 것을 Signature 라고 편의상 부르기로 합니다. (16 바이트 아니면 20바이트를 Encrypt 하기 때문에 속도가 빠릅니다) 이 Encrypt 한 결과와 평문(Plain Text)을 함께 받을 사람에게 보냅니다. 그러면 메시지를 받는 사람은 보낸 사람의 공개키(Public Key)를 구해서 (공개키 이기 때문에 쉽게 구할 수가 있습니다) Signature 를 Decrypt 합니다. 그러면 축약된 결과가 나오면 같이 들어 있는 평문 (Plain Text) 을 암호화 해쉬 함수로 축약을 하고 그 결과를 앞에서 Signature 를 Decrypt 한 결과와 비교합니다. 같다면 A 가 보낸 문서임을 확신할 수가 있는 것입니다. 말 그대로 서명을 확인 하는 것입니다. 

자 그렇다면 '공인 인증서'란 무엇일까요? 인터넷 뱅킹을 이용한다면 필수적으로 사용할 수밖에 없는 '공인 인증서' 그것에 관해서 이야기 해 보겠습니다. 

PKI 의 기본 가정중에서 개인키(Private Key)는 자신만이 소유하고, 공개키 (Public Key)는 공개해서 다른 사람도 쉽게 구할 수 있다고 했었습니다. 사실 PKI 란 이런 일이 쉽게 가능하도록 인프라를 갖춰두는 것입니다. 

그래서 공인 인증 기관이 등장하는 것입니다. 인증서 비밀번호니, 인증서를 다운 받는다는 둥, 모든 것이 인증서에 집중되어 있는 것처럼 보이지만 사실 가장 중요한 것은 개인키(Private Key)입니다. 보안회사들이나 은행권들은 저 개인키(Private Key)의 존재를 숨기고 싶어서 숨긴것이 아니라, 이 PKI 개념 자체를 설명하기가 부담스러워서 숨긴 것입니다. (사실 은행의 담당자들도 제대로 알지 못할것입니다 ㅎㅎ) 

그래서 공인 인증 기관은 인증서를 발행하는 것이 주요 업무가 아니라 실은 개인키와 공개키 쌍을 만들고 자신이 그 키들을 만들었다고 인증서를 발행하는 것입니다. 

즉 제일 중요한 개인키(Private Key)와 공개키(Public Key) 쌍을 만들고, 그 개인키(Private Key)를 공인 인증 기관에서 적법한 절차를 통해서 만들었다고 인증서를 발행하는 것입니다. (명품백이나 보석류를 사면 주는 인증서나, 강아지 분양 보증서 등등하고 연관 지어보면 명확할 것입니다) 그 개인키(Private Key) 를 보증하기 위해서 그 쌍이 되는 공개키(Public Key)가 바로 인증서에 들어 있습니다. 그리고 그 인증서를 공인 인증 기관이 정식으로 발행했다는 것을 알리기 위해서 '공인 인증 기관의 전자 서명'이 바로 인증서에 들어 있습니다. (그리고 인증서의 대상, 유효기간 등등도 포함되어 있습니다.) 그리고 나서 이 인증서는 신청한 사람한테만 주는 것이 아니라, 공개된 위치에 저장해서 요청하는 사람에게 내려보내 줄 수 있는 시스템이 갖춰져 있습니다. (보통 공인 인증 기관의 LDAP 에 저장됩니다) 

그래서 은행에서 발급받는 '공인 인증서'라는 것은 실은 '개인키 + 인증서' 쌍으로 되어 있습니다. 못 믿겠으면 Windows 사용자 분들은 NPKI 폴더를 뒤져서 자신의 CN 폴더 안에 저장된 파일들을 살펴보세요. 

그러면 공개가 원칙인 인증서에 왠 비밀번호 인가? 라는 생각이 드실만 할것입니다. 이제 지금까지 설명을 통해서 대충 눈치를 채셨겠지만, 바로 개인키 (Private Key)에 대한 비밀번호입니다. 

개인만이 소유해야 하는 개인키(Private Key)가 아무런 보안 장치 없이 공개되어 있으면 곤란하겠지요? 그래서 개인키(Private Key)에는 기본적으로 저장하는 형식이 있습니다. (물론 비밀번호를 필요로 하는 형식입니다) PKCS7 이나 PKCS12 가 바로 그것입니다. 

이상으로 길고 긴 글을 마치게 되었습니다. 이걸 통해서 PKI 를 다 이해할 수 있을 것이라고는 생각하지 않고 만들었습니다. 다만 같이 일하게 되는 후학들에게 PKI 의 기본 개념을 조금이라도 쉽게 설명하고 싶어서 작성한 KeyNote 입니다. 이 블로그에 올리는 이유는 혹시라도 이 내용을 바탕으로 또 다른 사람에게 이 자료를 가지고 설명할 때 설명이 조금이라도 매끄러우면 좋겠다고 사족을 달아둔 것입니다. 올려둔 그림으로 충분하리라 판단하지만 KeyNote 원본을 요청하실 분은 메일 주소를 달아 주시거나, 아니면 제가 전달할 수 있는 다른 방법을 찾아보겠습니다. 

후학들에게 보여주고 싶은 내용입니다. 역시 개발자들이라 그런지 Bottom-up 이라던지 프로토타이핑에 관한 언급이 살짝 살짝 나오는 군요 

5분만에 보는 디아블로 1, 2 스토리입니다.  다시 몇판 돌려볼까? 라는 생각이 솟아오르게 만드는군요 ㅎㅎ 

최근 업무 관계로 바빴습니다. (뭔 웹 사이트를 한달안에 5개를 만들라고 하시는지..) 

기존에 사용하고 있던 Emacs 버젼이 낮은 관계로 업그레이드를 하긴 해야지.. 하다가 지금 릴리즈 되어 있는 버젼이 Shift+SPC 가 안먹는다는 이야기를 접했습니다. 커미터가 서양분인 관계로 Shift+SPC 의 필요성을 모르셨나 봅니다. (이런!!!) 그러다 CJK 언어를 쓰는 동북아 삼국의 맹공 (주로 중국과 일본)을 받고 끝내, 왜 필요한지는 모르겠지만 이라는 사족을 단 채로 Shift+SPC 를 잡아채게 바꿨다고 합니다 ㅎㅎ

그래서 일단 Emacs 소스를 받아옵니다. 여러 레파지토리가 존재하지만 손에 익은 github.com 것을 가져오기로 합니다.

https://github.com/emacsmirror/emacs

적당한 곳에 가서



합니다. 내려 받는데 시간이 좀 걸립니다. 소스 전체 크기가 무려 900메가가 넘기 때문입니다. (소스 자체 크기라기 보다는 변경내역들의 내용이 많을것이라 봅니다)

이대로 컴파일을 하면 라이브러리가 두개 없다고 나옵니다. libgif 와 libtiff 입니다. 따라서 이를 설치해 줘야 합니다.
애플에서 이런 오픈소스 라이브러리에 관련된 페이지가 있습니다.
http://www.apple.com/opensource/ 이 곳인데요. 이곳에서 gif 와 tiff 라이브러리를 찾아서 설치해 줍니다. 

http://sourceforge.net/projects/giflib/?source=dlp
이게 libgif 고 

http://www.remotesensing.org/libtiff/
이게 libtiff 입니다. 

두 소스 다 받아서 압축을 푸시고, 

Emacs 에 Yasnippet 을 설치하면 기본적으로 Text-mode snippet 중에 time 이라는 단축어가 있습니다. 
Text-Mode 상에서 time 을 입력하고 TAB 키를 누르시면

Thu Mar 21 18:36:06 2013

위와 같은 내용이 출력됩니다. 일단 영어이기도 하고 , 제가 필요하 것은 오늘 날짜와 뭐 더 필요하다면 요일정도? 출력이 되면 좋겠다고 생각이 들어서 간단한 함수를 제작했습니다.

(defun current-day-string ()
  (let ((datetime (decode-time))
        (dow '(일 월 화 수 목 금 토)))
    (format "%s-%s-%s %s요일" 
            (nth 5 datetime) 
            (nth 4 datetime) 
            (nth 3 datetime) 
            (nth (nth 6 datetime) dow))))

이제 이 함수를 .emacs 에 넣어둡니다. (전 다른 방법을 쓰지만 쉽게 쉽게 설명합니다 ㅎㅎ) 

그리고 Snippet 을 만들어줄 차례입니다. 

yasnippet 이 설치된 디렉토리로 이동합니다. (제 경우에는  ~/.emacs.d/plugins/yasnippet 에 저장이 되어 있습니다) 



(만약 이 디렉토리들이 존재하지 않는다면, 예전 제 포스트 를 참조하셔야 합니다. yasnippet 부분만 따라하시면 됩니다. ) 
 


(day 라는 이름의 snippet 을 만들어 주라는 것입니다)



자 이제 모든 준비가 끝났습니다. text-mode 상태에서 day 라고 누르고 TAB 키를 눌러주면

2013-3-21 목요일

라고 출력되는 것을 확인하실 수 있습니다.   

어쩌다 보니 이메일 보내는 기능을 구현하게 됐습니다. 요즘 서비스 하나 만들려고 보면 이메일 보내기 기능은 거의 기본적인 기능이라 필수적으로 알아야 하는 부분이라고 볼 수 있습니다. 

이 포스트는 두 부분으로 되어 있습니다.



사실 2번은 무지 쉬웠습니다. nodemailer 라는 훌륭한 패키지가 존재하기 때문이지요. 1번은 너무나 쉽고도 오래된 이야기인지 오히려 관련 문구를 찾기가 어려웠습니다. 

개발환경은 역시나 서버 사이드 이기 때문에 Ubuntu 12.10 버젼에서 테스트 했습니다.

1. Sendmail 을 설치해줍니다.



Postfix 를 요즘 많이 쓴다고 하는데, 귀찮아서 걍 편한 sendmail 을 설치해줬습니다. 처음 설치된 sendmail 은 오로지 Localhost Only 입니다. 사실 이게 편하긴 합니다만, 제 주요 개발 환경은 OSX 이고, 원격에 서버가 설치되어 있는 관계로 sendmail 을 원격에서 접속해서 메일을 보낼 수 있게 설정해 줄 필요가 있습니다.

2. 원격에서 접속할 수 있게 sendmail.mc 를 바꾸어 줍니다.
/etc/mail/sendmail.mc 를 열고 다음줄을 찾아서 바꾸어줍니다.


인 부분을

로 바꾸어 줍니다.

아무데서나 접속가능하게 바꾸어 준것입니다. 자 이제 설정파일을 생성해줍니다.



3. 접속 테스트 시작 
원격에서 접속하는 것을 가정으로 하고 sendmail 이 설치된 서버는 편의상 'crazia.super.com' 이라고 하지요. 

이제 정상적으로 메일이 보내지는 것 까지 테스트 되었습니다. 이제 node.js 로 이메일 보내는 방법에 대해서 알아보겠습니다. 

1. nodemailer package 설치하기 
먼저 테스트를 만들 디렉토리를 한개 만들어 주는 것이 좋겠습니다. 



그리고 npm 으로 가볍게 인스톨 해줍니다. 

$ npm install nodemailer

2. 실제로 보내는 테스트 코드 작성하기


위 내용을 자신의 상황에 맞게 변경하고 접속 host , 이메일 아이디 (제 아이디 쓰시면 아니되옵니다 ㅎㅎ) 저장합니다. 

3. 실행해보기

$ node mail-test.js

어떻습니까? 참 쉽죠? 

 

왠만하면 페북 LOL 에서 뭔가 안 퍼오는데 이건 안 퍼올 수가 없네요 ㅎㅎ . 트리스트나의 모습도 깜찍하네요 

node.js 프로그래밍을 할 때, exception 이 발생하면 , 쉴새 없이 Ctrl+C , 화살표 위 (이러면 전에 실행했던 명령줄이 표시됩니다)를 반복적으로 누르는 것을 막아주기 위해서 설치하는 프로그램인 nodemon 이 Ubuntu 계열에서 오동작을 합니다. (하위 디렉토리에서 변경된 것을 잡아채지 못하더군요) 

소스를 뒤져보니 파일의 변경유무를 알아보던 fs.watch 를 이제 안쓰기 때문이라고 하는데요. 그래서 소스 변경 유무를 다음과 같은 명령 형식으로 알아봅니다. (사실 다음 소스는 동작하는 여부인지 골라내는데 사용하는 코드입니다) 

find -L /dev/null -type f -mtime -1s -print

위 명령이  데비안 계열하고 BSD 계열이 다르게 동작하는데 실은 저 명령은 BSD 계열을 기본으로 해서 만들어 진 것입니다. (개발자가 맥빠였던 것입니다!!) 

그래서 우분투에서 개발하시는 분들은 귀찮으시더라도 패치되기 전까지 supervisor 를 사용하시면 됩니다. 사용법은 비슷합니다.  



편리한 node.js 코딩 되세요.