오늘의 주제는 말 그대로 IPv6 를 위한 bind9 ( named ) 설정 따라하기.
( 컴파일 등은 과감히 생략.. 하기 위해서 배포본은 우분투를..;; 나이먹으니 귀찮귀찮... )
0. root@test:/# apt-get update
1. Bind 를 설치한다. root@test:/# apt-get install bind9
(패키지 의존성 검사 후 설치하겠냐고 물으면 Y 엔터 )
2. 설치가 종료 된 후 이미 친절하게 서비스를 돌리고 있는 우분투에게 감사하며, ps -ef | grep bind 정도로 확인해 준다.
3. named.conf 설정
본 설정은 아주 단순히 zone 파일 대강 생성 및 AAAA 레코드 등록을 목적으로 하므로,
기타 옵션에 대해서는 생략한다.
root@test:/# vi /etc/bind/named.conf
..
....
include "/etc/bind/named.conf.local" # 요 앞쪽에 추가 하고자 하는 zone을 명시해 준다. 물론 뒤에 넣어도 무관계
zone "myowndomainname.com" IN {
type master; # slave 인 경우에는 slave 라고 써준다.
file "/var/cache/bind/myowndomainname.com.zone" ; # 디렉토리 위치는 배포판별로 약간씩 다르다. 주의.
};
...
..
4. zone 파일 설정
완전히 새로 쓰려면 웬지 노력이 많이 드니까 zone file의 내용에 대해 이해한다면 그냥 가져오자.
root@test:/# cp /etc/bind/db.local /var/cache/bind/myowndomainname.com.zone root@test:/# vi /var/cache/bind/myowndomainname.com.zone # 우분투 9.04 디폴트 위치인듯.
....
.. 수정 ..
$TTL 604800
@ IN SOA localhost. myowndomainname.com. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
@ IN AAAA 2002:cbec:d22c:0:7cb3:13a3:a167:XXXX
yourblog IN AAAA 2002:cbec:d22c:0:7cb3:13a3:a167:XXXX
hungry IN AAAA 2002:cbec:d22c:0:4ce2:b2ff:fe2e:XXXX
# 기타 필요한 레코드 추가
요 단계는 꼭 해 주도록 하자. root@test:/# chown -R root:bind /var/cache/bind
5. zone file reload
zone 파일이 무진장하게 많다면 당삼 /etc/init.d/bind9 restart 같은 짓은 하지 말자. 경우에 따라 2시간 이상 서비스 굿바이 당할 수도.
상큼하게 reload 사용 해 준다. root@test:/# /etc/init.d/bind9 reload
* Reloading domain name service... bind9
...done.
6. 테스트.
물론, 클라이언트와 방금 설정한 서버가 도달 가능한 IPv6 네트워크에 위치하고 있어야 함은 물론이다.
hungry.myowndomainname.com has AAAA address 2002:cbec:d22c:0:7cb3:13a3:a167h:XXXX
# 만약 잘 안나온다면,
>set type=AAAA
# 해서 결과를 보도록 하자.
현 시점에서 ( 2010.06.08 ) , AS 넘버를 가진 규모의 사업자가 아니라면 ipv6 를 공인망으로 사용하는 경우는 잘 없는 듯 하다. 비용도 워낙 비용이고. 하지만 소프트웨어 제작사의 경우 이러한 환경의 테스트를 거치지 않은 경우 문제가 될 수도 있지 않을까.
간단한 테스트를 위해서라도 bind 서버가 필요한 경우가 있다. 몇줄 바꿔주면 잘 동작하느니 만큼 편하게 사용하면 되시겠다.
담에는 IPv6 over IPv4 에 대해서 간단하게.... ( 언제나 기약없는 약속; )
급하신 분들은 요기 Cisco 를;
윈도우 웹 서버에서 세션을 공유하는 방법은 일전에도 소개 한 바와같이 2가지란다. ( InProcess 의 경우 시스템 하는 사람 기준에는 '공유' 의 방법으로 보이지 않아서 제외 )
하나는 ASP.NET 의 State Service 를 사용하는 방법, 다른 하나는 MSSQL DB를 사용하는 방법.
이 중 두번째 방법은 그냥 그 개념을 생각만 해도 세션 전용의 디비를 두어야 하나 싶을 정도로 고민스러운 방법이라 패스. ( 그 수많은 요청에 의한 세션 정보 열람을 위해 디비에 접근하는 웹서버를 상상해 보시라! )
뭐 아시는 분들은 다 아실만한 이야기 들이지만, 이번에 어찌저찌 하다 보니 보게되어 소개 한다.
웹 서버의 로드밸런싱을 처리하다 보면 세션 공유의 필요성이 발생하게 되는데, 유닉스/리눅스 기반에서는 jsp 라면 웹로직이나 기타 WAS 의 도움을 받는 경우가 대부분이고, php 등은 memcached 를 사용하거나 NFS(?) 를 사용하는 등의 방법이 많다. 여기에 고객의 수가 증가하게 되면서 보다 안정적인 서비스로 가기위해서는 이 세션 공유 서버에 대한 복제 등이 지원이 되어야 하는데, asp state service 는 여기까지는 지원을 하지 않는 듯 하다.
대략적인 IIS 의 Session State 의 동작에 대한 다이어그램은 다음과 같다.
대체 Session State 라는게 뭐냐? 라는 점이 궁금하신 분은, 닷넷 개발자면 아주 잘 아는 내용을 억지로 시스템하는 사람이 번역한 아래의 내용을 참조 하시면 되겠다. 물론, 충분한 이해를 바탕으로 한 것이 아니기 때문에 뭔가 알맹이-껍데기 스러운 번역이기에 괜히 머리 복잡해 지기 싫으신 분은 안펼쳐도 무방하겠다. lol (나중에 현희형이 감수 및 이해를 도와주면 보다 윤기가 흐르는 번역이 될지도... 퍽!!@!! )
고전적인 ASP 환경에서는 Session 의 상태는 asp.dll 라이브러리의 free-threaded COM 오브젝트에 기본적으로 구현되어 있다. ( 보다 궁금하신 분들은, 오브젝트 CLSID D97A6DA0-A865-11cf-83AF-00A0C90C2BD8 를 참조하기 바란다. ) 이 오브젝트는 name/value 의 조합으로 구성된 데이터이다. name 지시자는 session 정보의 검색을 위한 key 이며, value 지시자는 세션 상태가 저장된 컨텐츠이다. Name/vaule 조합은 세션 ID 별로 그룹화 되며, 따라서 사용자는 오로지 자신이 생성한 데이터만 열람이 가능하게 된다.
ASP.NET 에서는, 고전적인 ASP 와 Session State 에 대한 프로그래밍 인터페이스가 거의 동일 하지만 본질적인 부분에서 완전히 다른 구조로서 보다 향상된 확장성 및 유연성, 프로그래밍 파워를 제공한다. ASP.NET 의 session-state를 살펴 보기 전에, ASP.NET 의 세션 인프라에 대한 구조 및 기능을 리뷰해 보자.
ASP.NET 에서는, 수신되는 모든 HTTP 요청이 HTTP 모듈의 파이프라인을 지나게 된다. 각 모듈은 request 가 가지고 있는 정보의 양을 조절한다. Call Context 로 알려진 각 Request 에 따라 붙는 정보들은 HttpContext 오브젝트에 의해 재구성 될 수 있다. Request 의 컨택스트는 단지 데이터 컨테이너 일 뿐 또 다른 Items 컬렉션에 의해 제공된 상태 정보의 컨테이너로 인식되지 않아야 한다. HttpContext 오브젝트는 다른 모든 state 오브젝트와 다르며, (예. Session, Application, Cache ) request 가 처리되는데 필요한 시간을 제한하는 lifetime 을 가지고 있다. 각 요청은 HTTP 모듈의 필터 체인을 통과 하게 되고, 이 요청에 대한 HttpContext 오브젝트는 관련된 Global 오브젝트 ( Application/Cache ) 및 Session (Session-specific ) 관련 정보가 함께 바인딩 되어 프로세싱 될 준비가 된다.
각 세션의 state 을 셋업하는 모듈은 SessionStateModule 이다. IHttpModule 인터페이스가 구성된 이후, ASP.NET 어플리케이션에 대한 세션 상태에 따른 유동적 서비스를 제공할 수 있게 되었다. 서비스는 세션 ID 생성, 쿠키를 사용하지 않는 세션 관리 및 외부 state provider에 의해 제공되는 session 데이터 검색, request call context 의 데이터 바인딩 등을 제공한다.
HTTP 모듈은 내부적으로 세션 데이터를 저장하지 않는다. 세션 상태는 state providers 라는 외부 컴포넌트에 의해 유지되고 캡슐화 되어 IStateClientManager 인터페이스를 통해 외부와 통신하게 된다. session-state HTTP 모듈은 세션 상태에 대한 읽기/쓰기를 위해 해당 인터페이스를 호출한다. ASP.NET 1.1 은 아래와 같은 3개의 다른 state providers 를 제공한다.
InPorc : 세션의 데이터는 워커 프로세스 ( aspnet_wp.exe / w3wp.exe ) 의 메모리에 저장된다. (기본 옵션)
StateServer : 세션 데이터는 Serialize 되어 구분된 다른 프로세스의 메모리에 저장되며 (aspnet_state.exe),
외부의 다른 머신에서 구동 될 수도 있다.
SQLServer : 세션 데이터는 Serialize 되어 MSSQL서버에 저장된다. SQL서버 역시 로컬 또는 외부 머신에서
동작이 가능하다.
이러한 세가지의 session-state HTTP 모듈은 web.config 의 <sessionState> 로 사용이 가능하다.
<sessionState mode="InProc | StateServer | SQLServer />
위의 설정에서 지정한 3가지 다른 타입에 따라 각기 다른 프로시저 및 다른 프로세스를 통해 세션 정보가 저장/참조 되게 된다. 디폴트 설정은 ASP.NET 의 워커 프로세스의 (프로그래밍으로 접근이 불가능한) ASP.NET Cache 오브젝트의 private slot 에 저장된다. 세션 상태는 이처럼 내부가 아닌 외부에도 Windows NT 서비스인 aspnet_state.exe 를 통해 유지 될 수 있으며, 세번째 옵션인 SQLServer 는 SQL Server 2000에 의 ad-hoc 테이블에 세션 데이터를 저장한다.
Request 가 시작될때, HTTP 모듈은 세션 값을 딕셔너리 오브젝트에 사용하여 deserialize 한다. 딕셔너리는 HttpSessionState의 오브젝트 타입이며, HttpContex/Page 클래스의 Session 프로퍼티를 사용하여 프로그래밍으로 접근가능하게 만들어 진다. request 가 종료 되기 전, 개발자에게 보여지는 session-state 값과 session object 가 최종적으로 바인딩 된다. request 가 정상적으로 종료되면, 모든 상태 값은 다시 state provider 에 의해 serialized 되어 다른 request 에 의해 재사용 가능하게 된다.
아래의 그림은 ASP.NET 페이지와 session value 사이의 통신을 보여준다.
The architecture of session state in ASP.NET 1.1
출처 : MSDN
request 가 처리되어 종료되는 동안 session state의 값은 lock 된다. Lock 은 HTTP 모듈의 내부적으로 관리되며, session-state 에 대한 직렬화 된(순차적) 접근을 제공하기 위해 사용된다.
session-state 모듈은 web.config 에 정의된 방법에 의해 정의 되며, 이 정의된 각 3가지의 방법들은 서로 다른 초기화 과정을 거치게 된다. 예를 들면, SQL Server state 의 경우 out-of-process 매니저에 의해 지정된 TCP 정보를 가지고 database 에 대한 커넥션을 생성한다. 반면에 InProc 의 경우 reference 를 callback 함수에 저장하며, 이는 element 가 캐쉬에서 지워질때 실행되고, 어플리케이션에 Session_OnEnd 이벤트를 보낼때 사용되게 된다.
아무튼, 본 서비스를 사용하여 윈도우 서버의 세션 공유는 다음의 순서로 적용할 수 있다. ( Windows 2008 서버 이상
기준 )
1. 서비스 설치
서비스의 설치는, 다른 윈도우 구성요소와 마찬가지로 윈도우 Feature 추가에서 쉽게 찾을 수 있다.
2. 서비스의 구동.
서비스를 구동하고 netstat -na 를 통해 바인딩 된 포트 및 주소를 확인 해 보면,
127.0.0.1:42424
로 리스닝 하는 것을 볼 수 있다.
당연히 많은 서버의 로드 밸런싱에 사용 할 것이므로, 로컬 호스트 리스닝은 의미 없다. 다음의 레지스트리를 수정하여
바인딩 되는 주소를 변경하도록 한다.
HKML\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnections
의 값을 0에서 1로 변경하고 서비스를 재시작 후, netstat -na 를 다시 찍어 보면
0.0.0.0:42424
를 확인 가능하다.
물론, 이때 외부에서 해당 포트로 접근을 시도하면 당삼 안된다. 윈도우 방화벽의 Inbound 에 해당 포트 규칙을
추가하자. 이후 타 서버에서 정상적으로 접근이 가능하다면, 설정 완료.
+ 다음의 설정 값을 통해 포트도 변경이 가능하다.
HKML\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\Port
일본의 조그마한 호텔방 안에 편의점에서 사온 돈까스 도시락과 노트북을 책상에 펴 두고 입에 밥알 반 돈까스 반을 우물 거리던 중 Youtube 로 보고 있던, 일전에도 포스팅 했던 어느 예능의 '어부바' 에피소드에 BGM으로 깔렸던 그 노래.
입안에 음식을 가득 물고 우물 거리던 채로 노트북의 12인치 작은 화면과 찢어지는 듯한 스피커를 통해 나오는 노래에 눈물을 찔끔 쏟을 것 같았던, 그런 기억이 이 노래와의 첫 만남.
가수가 누군지도 몰랐고, 노래는 더더욱 몰랐지만 뭔가 슬펐던 그 음악.
굳이 찾아서 들어야겠다 라는 생각할 겨를도 없이 정신없는 2주일이 지나고 나서야 빗소리에 문득 기억이 나서 구글링.
노래를 처음부터 끝까지 가만히 들어 보면, 가사는 참 아름다우면서도 뭔가 꽁냥이질이 나올것만 같은 닭살 스러움이 있는, 즐거워 져야만 하는 노래 같지만 왜 나는 비행기 착륙할 때의 하강기류를 만나 위장이 턱으로 올라오는 듯한 느낌의 슬픔이 밀려오는지 모를 일이다.
가사를 주욱 적어 보자면,
첫사랑이죠 - 나윤권,아이유
어쩜 우리 어쩜 지금 어쩜 여기 둘이 됐을까요 흐르는 시간 별처럼 많은 사람 속에..
내 맘 가득 그대 소복소복 쌓여요 내 마음 속 내 눈 가득 온통 그대 소복소복 쌓여요 차가운 손끝까지 소리없이 따뜻해 지나봐..
말하지 않아도 우리 마주 본 두 눈에 가득 차 있죠 이젠 그대 아플 때 내가 이마 짚어줄 거예요 겁내지 말아요 우리 꿈처럼 설레는 첫사랑이죠 조심스럽게 또 하루하루 늘 차곡차곡 사랑할게요..
그댈 떠올리면 발그레해지는 맘 그대 얼굴 그 목소리 떠올리면 발그레해지는 맘 하얗게 얼어있던 추운 하루 녹아내리나봐..
보이지 않아도 우리 마주 쥔 두 손이 참 따뜻하죠 그대 잠 못 드는 밤 내가 두 볼 감싸줄 거예요 서로를 믿어요 우리 별처럼 반짝일 첫사랑이죠 두근거려도 또 한발 한발 좀 더 가까이..
반가운 첫눈처럼 나에게 온 그대와 첫 입맞춤을 하고파 들려요 그대 마음 세상엔 우리 둘 뿐 인가봐..
말하지 않아도 우리 마주 본 두 눈에 가득 차 있죠 이젠 그대 아플 때 내가 이마 짚어줄 거예요 겁내지 말아요 우리 꿈처럼 설레는 첫사랑이죠 조심스럽게 또 하루하루 늘 차곡차곡 사랑할게요 You`re my first love...
첫사랑이라는 머리털 나고 나와 다른 염색체를 지닌 사람에 빠져 한마디에 가슴아프고 손짓 하나에 기쁘게 되는 '타인으로 인한 한시적 조울중' 비슷한 열병이 바로 이 노래의 주제.
받아 줄런지 안받아 줄런지 모를 알쏭달쏭한 날들을 끙끙 앓으며 버티다 버티다 드디어 참을성의 한계로인해 용자가 되어 수줍고도 힘든 고백의 단계를 지나 서로가 가까워 지는 설레임에 대하여, 세상 사는 사람 누구라도 한번은 느꼈을 가슴 뛰는 그 감정과 상황에 대한 노래를 들으며 왜 가슴이 먹먹해 지는지 나름 짱구를 굴려 보았는데.
누구에게나 그 시작은 참 아름답고 순수하며 사심없이 그사람의 웃음을 위해 목숨이라도 던질 수 있다는, 이해 관계 따위는 이미 아스트랄한 세계로 던져 대뇌 피질의 모든 것이 상대방의 행동 하나 하나를 새기기 위해 생겨났다고 믿을 정도로 단지 "그대를 위해" 라는 혼자만의 대명제 안에서 무엇이라도 할 것만 같던 시간들.
5년이 지나고, 10년이 지나고 나면 그런 시간의 끝자락 마저 아름답고 순수했다고 느낄 테지만, 두루마리 휴지 한덩이를 스텐드만 켜진 책상의 눈물을 지우느라 다 써버렸던 시간을 겪고 있는 와중에는 세상에 절망도 그런 절망이 없을테다.
그대들 그리도 가깝고 행복해 지고 있지만, 그래서 '뇌'의 모든 기능을 상대방에 대한 모든 것의 기억에 쏟아 붇지만
결국 그 모든것이 잊어야 할 기억이 되었을때 만큼 슬픈일이 있던가.
반대로 상대방의 문자 한통에, 수화기 넘어 들리는 나직한
한마디에 세상을 얻은 것 같은 그런 기분 좋은 일이 살면서 또 있었던가.
원점으로 돌아가 그럼 왜 이 노래가 참 슬플까 하는데는, 뭐 나는 예술적 감각에 대해서는 이미 블로그 제목에서 부터 "저 그런사람 아닙니다" 라고 강하게 어필하고 있기 때문에, 철학적 용어 전혀 없는 완전 주관적인 이유를 들어 보자면
"다시는 돌아갈 수 없는 시간에 대한 짙고도 강한, 어찌할 수 없는 향수"
가 아닐까 싶다.
더 쉽게 말하면 "이제는 절대 그런 사랑은 할 수 없을 것 같아" 이런 뭔가 자괴적인 느낌?
나는 이제 '누군가에게' 뜨거웠던 적이 있었는 지를 고민하지 않으며,
다만 '무엇에' 뜨거워 져야 하는지를 생각하는 나이.
첫사랑이라는 나에게만은 소중했던 별들만큼 많은 사람들 속의 기억에서,
1곡 무한 반복으로 들으며 일을 하고 있는 현실이 애처로와 적어 본다.
