'2016/09'에 해당되는 글 8건

Host OS: Ubuntu 16.04 (amd64)
Container template: ubuntu

ubuntu 템플릿을 가지고 Linux Container를 만들고 난 직후에 환경변수가 하나도 잡혀 있지 않아서 몇 가지 불편한 점이 있었다.

vi는 HOME 환경변수를 참조해야 하는데 없어서 설정파일 저장을 못하고, screen 툴은 TERM 환경변수가 없어서 아예 실행이 안되는 문제가 있었다. 그 외에도 PATH 환경변수가 없으니까 심지어 apt-get install조차 안되었다.

내가 Linux Container 생성 단계에서 뭔가 빠뜨린 것인지 모르겠지만, 일단 기본으로 생성한 Container에서 필요한 몇 가지 환경 변수를 메모하게 되었다.

TERM은 vt100이 무난하다는 의견이 있어서 이것으로 했다. 이렇게 적용했더니 쉘에서 ls를 쳤을 때 파일 종류별로 색상이 달라지는 등 소소한 변화가 있었다. 아니면 xterm을 써도 상관없다.

그냥 Container를 만들고 시작하면 root 계정으로 들어가길래 /root/를 HOME으로 설정했다.

PATH의 경우 일단 최소한으로 시스템 도구들의 위치를 참조하게 했다.

이 환경변수 값들을 /root/.bashrc 파일에 추가해줄 수도 있지만, Container는 full virtualization처럼 이미지 파일로 독립된 공간을 유지하는 것 같지 않아서 잘 모르겠다. Container를 더 익숙하게 사용하게 되면 이 글을 다시 고칠 예정이다.

Host OS: Ubuntu 16.04 LTS (amd64)

Linux Container를 이용해서 ns-3에서 네트워크 시뮬레이션을 할 필요가 생겼다. 일단 ns-3 공식 사이트에 나와 있는 튜토리얼을 따라해 보니 Linux Container 생성은 되는데, 외부 네트워크에 접속할 수 없다. 개별 네트워크 설정이 가능한 Container가 인터넷이 되게 하는 방법은 VM과 다를 바가 없지만, Container 생성 단계에서 약간의 작업이 들어가기 때문에 기록하게 되었다.

1. Host 머신 설정

Host가 Container들을 브릿지로 관리하는지, NAT로 관리하는지에 따라 설정이 다른데, 여기서는 NAT를 쓰는 경우를 기준으로 설명한다.

우분투에 lxc를 설치하고 나면 자동으로 브릿지가 하나 생성되어 있는데 보통 br과 lxc라는 단어가 동시에 들어가 있다. 필자의 경우 lxcbr0 이름으로 브릿지가 생성되어 있었고, IP주소는 10.0.3.1로 잡혀 있었다.

(Host에서 lxc 설치 후에 lxcbr0 인터페이스가 새로 생긴 것을 확인할 수 있다.)

Host에서 NAT를 통해 인터넷 접속을 허용하기 위해서 몇 가지 작업을 해 줘야 한다. 먼저 iptables에서 NAT 내부에서 인터넷으로 나가는 패킷을 masquerade 시켜 준다.

그리고 /etc/sysctl.conf 파일에서,

위 라인의 주석을 제거한 다음, sysctl을 새로 적용한다.

일단 ns-3에서 Linux Container를 생성해서 "시뮬레이션용 네트워크"에 연결하는 튜토리얼 [1] 을 따라해 보면 샘플 lxc 설정 파일이 있는데, 여기에 외부접속 용도의 네트워크 인터페이스를 하나 추가해 준다.

lxc 설정 파일(여기서는 ns-3에서 샘플로 쓰는 lxc-left.conf 파일에 내용 추가 [1])에 아래 내용을 추가한다.

이제 위의 설정파일을 가지고 left라는 이름의 Container를 생성하고 시작한다.

2. Container 내부 설정

만약 Container가 정상적으로 생성되었다면 left라는 이름의 root 계정으로 쉘 프롬프트가 바뀔 것이다. ifconfig를 쳐 보면 아래와 같이 eth1 인터페이스가 인식되는 것을 볼 수 있다. (eth0의 경우는 원래 설정되어 있던 것)

(lxc-left.conf 설정파일에 새로 추가한 eth1 인터페이스가 설정한 IP주소 

10.0.3.2로 표시되는 것을 확인할 수 있다.)

Container를 시작한 직후에는 default route가 설정되어 있지 않기 때문에 인터넷 상의 머신으로 ping이 되지 않는다. 따라서 Container 상의 쉘에서 Host 머신과 연결하는 route를 추가한다. Host 머신의 lxcbr0 인터페이스의 IP주소가 10.0.3.1이기 때문에, default route의 게이트웨이를 10.0.3.1로 설정한다.

여기까지 설정하면 IP주소를 통해 인터넷 상의 아무 컴퓨터에나 접속할 수는 있다. 다만 도메인 네임 서버가 설정되어 있지 않으므로 www.google.com 과 같은 도메인 네임으로는 주소를 찾을 수 없다.

도메인 네임 서버 설정은 여러가지 방법이 있지만, Container 자체가 약간 휘발성에 잠시 쓰는 느낌이 있어서, 일단 임시방편으로 /etc/resolv.conf 파일을 직접 수정했다. (좋은 방법은 아닌 것 같지만... 당장 되긴 되니까.)

네임서버는 일단 구글 도메인 네임 서버(8.8.4.4)로 했는데, 국내 다른 도메인 네임 서버로 설정해도 상관이 없다.

<참고자료>

[1] https://www.nsnam.org/wiki/HOWTO_Use_Linux_Containers_to_set_up_virtual_networks#Running_an_ns-3_Simulated_CSMA_Network

VIM version: 7.4.1689

우분투에서 VIM (Vi Improved) 에디터를 쓰면서 Home, End, Page Up, Page Down 키가 원래 의도하던 대로 작동했던 것 같다. 하지만 Linux Container 상에서는 작동하지 않았다. 원인은 잘 모르겠지만, 아마 root 계정으로 vim을 실행하게 돼서 몇몇 세팅이 적용이 안됐을 거라 짐작만 하고 있다.

아무튼 Home, End, Page Up, Page Down 키 등이 작동되게 하려면 터미널을 지정해 주면 된다.

만약 vim을 켤 때마다 적용하는 영구적인 설정으로 하고 싶으면 홈 디렉토리에 .vimrc 파일을 만들고 설정을 추가하면 된다.

vim 에디터 창이 열리면 아래 내용을 기록하고 저장한다.

연구를 할 때, 자꾸 이전에 읽었던 논문을 다시 가져와서 그 논문이 풀고자 했던 문제가 무엇이고 어디까지 해결했는지 새로 검토를 하고, 그렇게 내가 논문을 쓰려는 분야 논문들을 새로 살펴보는 경향이 나한테 있는 것 같다.

한번 읽을 때 정리를 잘 해뒀어야만 이런 revisit이 사라질까? 그냥 며칠 시간을 잡고 오로지 관련 연구들만 계속 읽어서 논문의 Related Work 섹션을 만들어 내야 하는 걸까?

보다 근본적으로, 자꾸만 내가 내 논문을 위해서 만들어낸 "문제 정의"가 어딘가 마음에 들지 않아서 그런 것은 아닐까?

분명히 기존 연구 논문들을 읽으면서 공통적으로 고려하지 못해서 생기는 문제 상황은 머릿속에서 이미 수 차례 검증을 했다. 그럼에도 불구하고 실제로 그 문제를 해결하는 방법론을 제시하는 과정에서, 그 방법론이 충분히 매력적으로 보이지 않으면 문제 정의가 제대로 안 된 것인지 의심하는 것은 아니었나 생각해 본다.

아무래도 내가 무언가를 제안할 때, 자꾸만 남들이 보기에 이정도는 되어야 쓸만하다는 강박관념에 사로잡혀서, 빨리 primary idea를 검증해야 할 때조차도 아주 길게 생각하고 아주 많은 상황을 동시에 고려해서 이를 수학적인 분석으로까지 만들어 내려는 내 욕심이 문제인 것 같다. 다르게 표현하자면 뭔가 결벽증 같은 것.

그래서 아이디어는 있고 문제 상황은 비교적 짧은 시간 안에 만들어 내는데도 불구하고, 실제로 아이디어를 검증할 시뮬레이션이나 실험은 천년만년 오랜 시간이 걸리는 게 지금 내 상황인 것 같다. ㅠㅠ

실험환경이 좀 문제가 있어도 좋으니, 선택과 집중을 해서 일단 문제의 핵심이 최소한으로 해결되는지부터 보기 위해서 먼저 간단하게 (자꾸 복잡해지지 말고!! ㅠㅠ) 코딩을 해서 결과부터 만들어 내려는 태도가 필요하다.

이번주에는 결벽증 성향을 마음 속 한켠에 봉인해 놓고, 빨리빨리 시뮬레이션 일처리를 진행하기 위해서 노력해 보자.

데비안 계열 리눅스에서 /etc/rc.local 파일에 고칠 부분이 있어서 고쳤는데, 막상 재부팅을 하기는 싫고 그냥 rc.local에서 수정된 부분만 적용하는 방법이 없는지 잠깐 고민을 했는데, 부질없는 짓이었다. -_-;;

만약 예를 들어 /etc/sysctl.conf 와 같은 "설정 파일"의 경우에는 내용을 고치고 나서 새로 적용할 때, 해당하는 서비스나 프로세스를 재시작하는 것이 맞다.

하지만 /etc/rc.local 파일은 그 자체가 실행 스크립트이고, 파일에 기록하는 내용 또한 쉘 명령들이니까 그냥 파일 자체를 실행하면 되는 거였다. ㅡㅡ;;

다만 rc.local 파일에 원래부터 적혀 있었던 연유로 기존의 특정 명령어가 중복 실행되지 않도록 하고 싶으면, 그냥 방금 수정한 라인들을 쉘에다 복사해서 실행해야 된다. 다른 신기한 방법이 있기라도 하겠는가?

밤에 정신없이 작업하니 스크립트 파일을 설정 파일로 착각하는 일도 생기는 것 같다. ㅜㅜ 하지만 인터넷에는 나같은 바보짓(...)을 똑같이 시도하는 사람들도 많이 있다는 데서 위안을 삼는다. ㅋㅋ [1]

<참고자료>

[1] http://www.linuxquestions.org/questions/slackware-14/execute-rc-local-without-reboot-of-linux-server-467282/