'IT/Linux'에 해당되는 글 90건

OS: Raspbian Jessie

HW: Raspberry Pi 2 Model B

NIC: TP-LINK TL-WN722N (Atheros ath9k_htc)

라즈베리파이에 USB 무선랜 카드를 2개를 동시에 꽂아서 쓰면서, 편의를 위해서 각 인터페이스 이름(wlan0, wlan1, ...)에 네트워크 설정을 강제로 지정해 두었다. 예를 들어, wlan0은 hostapd를 돌려서 항상 AP가 되도록 하고, wlan1은 ad-hoc 모드로 다른 라즈베리파이와 네트워크를 구축하도록 하였다.

<문제 상황>

그런데 재부팅하고 나면 거의 매번 인터페이스 이름에 실제로 매핑되는 USB 무선랜카드가 달라지는 현상이 있었다. 인터페이스 이름에 할당되는 무선랜카드의 맥주소(물리적 주소, MAC address, HW address)가 재부팅할 때마다 랜덤하게 배정되는 것이다. 즉, ifconfig로 인터페이스 정보를 볼 때, 아래와 같은 출력 결과에서 HWaddr 영역이 서로 뒤바뀌는 일이 비일비재하게 나타났다.

(라즈베리파이 기본 설정에서는 NIC가 여러 개일 경우, 

부팅할 때마다 빨간색 표시한 HWaddr 부분이 랜덤으로 계속 바뀐다.)

일반적인 상황에서는 별 문제가 아닐 수도 있겠지만, 내 경우에는 이렇게 맥주소가 뒤바뀌는 현상 때문에 애드혹 네트워크(ad-hoc network)를 구성할 때마다 여간 불편한 일이 아닐 수가 없었다. 애드혹 네트워크 설정을 /etc/network/interfaces 파일에 해 두더라도, 실제로 통신이 가능해지기 위해서는 서로 ping을 주고받는 과정과 어느정도의 시간을 거쳐서 각자 ARP 테이블을 구성해야만 한다.

만약 모든 라즈베리파이의 wlan1 인터페이스를 애드혹 네트워크로만 쓰기로 하고, 각 wlan1 인터페이스의 맥 주소와 고정IP 주소를 가지고 수동으로 ARP 테이블에 등록하는 스크립트를 만들어서 부팅 때마다 자동으로 실행되게 한다면, 불편하게 ping을 여러 차례 날릴 필요 없이 애드혹 네트워크를 바로 사용할 수 있게 된다. 하지만 맥주소가 부팅할 때마다 뒤바뀌면 ARP 테이블을 수동으로 추가하더라도 엉뚱한 맥주소가 등록됨으로 인해서 통신을 할 수가 없다.

<해결 방법>

udev에 network rule을 추가하면 된다. [1]

참고로 우분투 데스크탑에는 기본으로 맥주소와 인터페이스 이름을 고정해서 기억하게 되어 있다.

아래와 같은 문법으로 파일을 수정하거나, 없으면 파일을 만들어서 추가한다.

ATTR{address} 부분에 랜카드의 맥주소, NAME 부분에 강제 지정할 인터페이스 이름을 입력한다.

<참고자료>

[1] https://wiki.archlinux.org/index.php/Network_configuration#Device_names

tcpdump를 실행할 때, -i 옵션을 통해서 네트워크 인터페이스를 지정해 주어야 정상적으로 로그를 표시할 수 있다.

동시에 여러 개의 네트워크 인터페이스로부터 정보를 수집하려면, 두 가지 방법이 가능하다.

1. 그냥 tcpdump 프로세스를 각 인터페이스별로 여러 개 실행

screen 같은 도구를 써서 동시에 여러 instance를 실행시킨다. 

예를 들면:

문제는 여러 개의 로그가 별개로 생성되는 것. (같은 로그 파일 이름으로 지정해서 시도하지는 못해서 모르겠다.)

2. tcpdump -i any 옵션으로 실행

이렇게 하면 모든 인터페이스에 대하여 로그가 일괄 수집된다.

문제는 수집할 필요 없는 인터페이스의 로그까지 같이 수집된다.

(머신의 최대 인터페이스 개수가 N일 때, 수집 대상이 1개도 N개도 아닌 경우)

"-i any" 옵션으로 실행할 경우, 각 네트워크 인터페이스에 할당되는 IP 주소의 대역을 의도적으로 다르게 함으로써, 나중에 수집된 로그 파일에서 receiver의 IP 주소 대역을 보고 필터링하는 형태로 원하지 않는 인터페이스에 해당되는 로그를 배제시키는 수밖에 없겠다.

Client OS: Ubuntu Desktop 14.04.1 LTS (amd64)

Host OS: Ubuntu Server 14.04 LTS (amd64)

우분투 데스크탑에서 원격 컴퓨터에 SSH로 로그인하면서 X윈도우를 통한 앱을 쓰려면 서버와 클라이언트 양쪽 모두 X11 forwarding 옵션을 켜야 한다.  서버 쪽에서는 /etc/ssh/sshd_config 파일에서 X11Forwarding yes 항목이 주석 없이 적혀 있어야 한다. 클라이언트 쪽에서는 간단하게 "-X" 옵션만 추가하면 되지만, 이 때 에러 메세지가 발생하는 경우가 있는데, 그 중에 다음과 같이 .Xauthority 파일에 접근을 하지 못하는 에러가 발생할 때가 있다.

일단 위와 같은 에러 메세지가 뜨더라도 SSH 로그인은 되기 때문에, /home/[로그인 사용자 계정]/.Xauthority 파일을 확인해 보니 권한이 600 (루트만 읽고 수정가능)으로 되어 있었다. 그래서 일단 이 파일의 권한을 모든 사용자가 읽고 쓸 수 있게 바꾸어 보았다.

다시 ssh -X로 로그인해 보니 위의 에러는 사라졌지만, 로그인 과정에서 잠시 멈춰 있다가 아래와 같은 에러 메세지를 보여 주면서 어쨌든 기본 SSH로 로그인은 되었다. 여전히 X윈도우 관련 어플리케이션은 실행되지 않았다.

이 경우에는 lock에 관여하는 .Xauthority-c, .Xauthority-l 파일들을 삭제하면 된다.

SSH 세션에서 빠져나온 후, 다시 ssh -X를 이용하여 로그인해 보면 에러 없이 로그인이 되고, X윈도우 앱들도 정상적으로 실행됨을 확인할 수 있다.

Target: 윈도우 10 (Windows 10)

OS: Ubuntu 14.04.2 LTS (amd64)

이전 포스팅(http://skylit.tistory.com/177)에서, 원격 데스크톱에 접속한 후에 글꼴을 다듬는 방법을 설명하였으나, 이 방법은 매번 접속할 때마다 설정을 새로 해줘야 하는 번거로움이 있었다. 

리눅스에서 FreeRDP (콘솔에서 xfreerdp) 사용 시, 글꼴 다듬기 옵션을 자동으로 켜려면 /fonts 를 명령줄에 추가하면 된다.

참고로 사용한 FreeRDP 버전은 1.1.0-beta-2013071101 이다.

(FreeRDP 소스코드에서 설치하는 방법:

http://skylit.tistory.com/158 )

Host OS: Ubuntu 14.04.1 LTS (amd64)

Guest OS: Windows 10 (64-bit)

연구실 PC가 메모리가 넉넉한 편이라서(16GB) 가상 머신으로 윈도우를 시험삼아 돌려 보고 있는데, 이상하게 오랜만에 가상머신에 원격으로 접속하면 (원격 데스크탑 RDP 사용) 바탕화면이 뜨는데 상당히 오랜 시간이 걸린다. 정확히 재지 않았지만, 1분은 확실히 넘는 것 같다.

가상머신 구성은 다음과 같다:

• 가상 머신 관리는 QEMU KVM을 사용
• 윈도우 가상 머신에 CPU 2 Cores (물리적으로 2개, 쓰레드 기준으로 4개), 6GB 메모리, 180GB의 하드디스크를 할당
• 평소에 항상 PC를 켜 두고, 리눅스를 주로 사용하다가 몇 시간에 한 번씩 윈도우 가상 머신에 RDP로 연결(리미너 원격 클라이언트 또는 FreeRDP 사용)

확인해본 결과, 우분투는 기본적으로 물리적인 메모리에 상주하는 어플리케이션을 가급적이면 스왑 영역(가상 메모리 영역; 즉 하드디스크)에 옮겨 두려는 경향이 크다는 것을 알게 되었다. 그리고 그 경향을 조절하는 설정 변수가 Swappiness이다. 0부터 100 사이의 값 중에서 기본값이 60으로 되어 있다. 60이라는 숫자가 정량적으로 얼마만큼의 메모리 영역을 스왑 영역으로 보내는지는 확실하지 않지만, 경향성이 매우 높은 편에 속한다는 사실에는 이견이 없어 보인다.

인터넷에서 대부분의 우분투 사용자들이 개인 PC에서 우분투를 쓸 때 성능을 개선하기 위해서 가장 먼저 swappiness부터 조정한다는 것 또한 알 수 있었다. 설정 방법은 /etc/sysctl.conf 파일에 아래와 같이 한 줄을 추가하거나, 이미 있으면 숫자를 아래와 같이 조정한다:

인터넷에서는 보통 swappiness 값을 10 으로 권장하는 분위기이다. 실제로 나도 swappiness 값을 조정하고 나서 윈도우 가상 머신의 원격 데스크탑 접속 로딩 시간이 꽤 단축되는 것을 체감할 수 있었다. 하지만 여전히 몇 시간 후에 다시 접속하면 약 30초 가량의 딜레이가 발생하였다. 그래서 아예 vm.swappiness 값을 3으로 더욱 낮게 설정했더니, 그제서야 길어도 10초 이내로 바로 원격 데스크탑 화면이 나타났다.

개인적인 경험으로 볼 때, 물리적 메모리가 16GB이고 가상 머신을 한 개만 운용하고 있으며, 이외에 메모리를 많이 소비하는 다른 프로그램을 쓰지 않기 때문에 swappiness 값을 매우 낮게 줘도 앞으로 쓰는 데는 문제가 없을 것 같다.

하지만 근본적으로는 서버에서 가상 머신을 돌리는 것이 속도를 개선하는 가장 확실한 방법인 것 같다. 실제로 연구실에서 운용하는 24코어에 64GB 메모리, 5TB의 하드디스크를 갖고 있는 서버에서 동일한 스펙의 가상 머신을 돌리는 것이 개인 PC에서 돌릴 때에 비해 속도가 월등하게 빨랐다. 즉, 그래픽 측면의 이질감과 불편함(폰트 같은 것이 깔끔하게 표시되지 못하고, 게임을 실행하지 못하는 문제)만 감수할 수 있다면, 서버에서 가상 머신을 돌리는 것(결국 클라우드 환경)이 좋을 수밖에 없다.

아직 연구실에 오픈스택(OpenStack)을 적용하지는 못했는데 (당장 이 쪽으로 연구실 구성원 중에 연구주제가 있는 것은 아니고, 운영상의 목적만 있음), 서버 여러 대와 몇몇 잉여 데스크탑 본제들을 조합해서 클라우드 환경을 만들어서 돌려보고 싶다. 일단은 졸업이 급하니 졸업하고 나서 해 봐야겠다. ㅜㅜ