'리눅스'에 해당되는 글 27건

OS: Ubuntu 16.04 (amd64)

Docker version: 17.09.1-ce

도커(Docker)가 활발하게 개발이 진행되고 버전이 자주 바뀌면서 엔진 부분의 기능이 너무 급격하게 바뀌는 것 때문에, 연구를 목적으로 예전의 특정한 버전을 사용해야만 할 때가 있다. 리눅스(예: 우분투)에서 패키지 관리자로 설치하면 비록 완전한 최신 버전은 아니지만 그렇다고 특정한 버전을 골라서 설치할 수도 없기 때문에, 도커 홈페이지에서 예전 버전의 바이너리 형태의 배포판을 찾아서 직접 실행하는 방식으로 사용해야 한다.

가장 먼저, 시스템에 이미 도커가 설치되어 있다면 리눅스(우분투)에서 기본 제공하는 도커 관련 패키지 모두 삭제한다.

아래 링크에 가서 원하는 도커 버전을 다운로드 받는다:
https://download.docker.com/linux/static/stable/x86_64/ 

터미널에서 다운로드 받은 위치에 가서 압축을 푼다.

압축을 풀면 ./docker/ 폴더 아래에 바이너리 실행 파일들이 있음. 이것을 터미널에서 바로 실행 가능한 곳 어딘가에 복사한다. 보통은 PATH 환경변수에서 기본적으로 등록되어 있는 /usr/bin/ 또는 /usr/local/bin 이런 곳이 적당하다.

터미널 하나를 새로 열고, 데몬을 미리 종료되지 않는 형태로 실행시켜 둔다.

터미널을 끄지 않고 내버려 두거나, 백그라운드에서 실행이 되도록 해 둔다.

(screen 같은 도구를 쓰는 것도 백그라운드에서 꺼지지 않게 하는 좋은 방법이 될 수 있다.)

이제 새 터미널에서, 도커 버전이 특정한 예전 버전으로 바뀌었는지 확인해 보고, 원래 하려던 docker 관련 작업(docker run, docker start, docker checkpoint 등)을 진행하면 된다.

OS: Ubuntu 16.04.4 (amd64)

우분투에서 XRDP 서비스를 켜 두고, 윈도우 노트북에서 원격 접속을 하다 보면, 가끔 알 수 없는 문제로 인해 XRDP 서비스가 다운되고 (즉, crash) 이후로는 서비스 재시작이 안 돼서 원격 데스크탑을 쓰지 못하는 경우가 가끔 있다.

보통은 서비스 재시작 ($ sudo service xrdp restart)을 통해 문제가 해결되어야 한다. 하지만 만약 서비스 재시작이 계속 안 된다면, 기존에 실행 중이던 XRDP 서비스가 예기치 않게 죽으면서 자신이 여전히 살아있는 것처럼 정보를 남겨 둬서 그럴 가능성이 높다.

즉, 이미 죽어버린 프로세스의 PID 정보가 살아있는 것처럼 관련 정보 파일이 남겨지면서 (아마 정상적으로 종료가 되었다면 그런 PID 정보 파일들을 삭제를 했을 텐데 crash 되면서 PID 정보를 삭제를 못한 것), 새로 시작되는 XRDP 프로세스는 이미 다른 XRDP 서비스가 실행 중인 것으로 간주, listen을 하지 않고 멈추는 것으로 예상된다.

문제를 해결하려면, XRDP 서비스들과 관련해서 파일로 남겨진 PID 정보를 삭제하고 서비스를 시작한다.

<해결 방법>

1. /var/run/xrdp 디렉토리에서 XRDP 관련 서비스들의 process ID를 확인한다.

2. 위에서 출력된 숫자(프로세스 ID)를 사용하여 프로세스를 kill한다.

3. /var/run/xrdp/ 디렉토리 내의 .pid 파일 2개를 모두 삭제한다.

4. XRDP 서비스를 재시작한다.

위와 같이 작업한 후에 XRDP에서 설정한 포트 번호가 Listen 상태로 뜨면 정상 작동하는 것이다.
XRDP에서 포트 번호를 따로 변경해 주지 않았다면 기본적으로 listen하는 포트 번호는 3389이다.

OS: Ubuntu Server 16.04

연구실 서버에 있는 40개의 CPU 코어를 쪼개서 쓰기 위해 우분투 서버 위에 qemu-kvm을 설치하고, 가상 머신(VM)들을 관리하기 위해서 virt-manager라는 GUI 프로그램도 사용하고 있는데, VM 개수가 10개가 넘어가자 작은 문제가 하나 생겼다.

연구실 구성원 모두가 터미널(shell) 환경에서만 작업하는 게 아니라서 호스트 서버의 GUI 화면에도 원격으로 접속할 수 있도록 XRDP와 xfce4-session을 설치해 두었는데, RDP로 접속하면 호스트 서버의 GUI 화면 (xfce4-session에 연결되는 VNC 서버)에 대한 기본 포트는 5910으로 되어 있다.

참고로 XRDP에서 디폴트 설정을 그대로 쓰면 로그인할 때마다 포트번호 -1 값으로 새로운 세션을 새로 실행하게 되고, 그러면 5910번 포트에서 숫자가 1씩 커지면서 세션이 하나씩 새로 생성이 된다.

이전에 이미 만들어 둔 세션에 다시 접속하려면 포트번호에 5910을 입력하면 되는데 (참고: XRDP 기존 세션 재활용하기), 어느 날 포트번호 5910을 입력했더니, 호스트 서버의 화면 대신 내가 예전에 생성했던 VM의 내부 화면이 나타났다.

왜 그런가 해서 보니, qemu-kvm에서 실행 중인 VM의 개수가 10개를 넘어가 있어서 그런 거였다.

(16개 중에 12개의 VM이 실행중... 각각 localhost로 VNC 서버를 돌린다. 즉, 5900~5911까지의 포트가 모두 VM의 화면으로 쓰이는 상태다.)

QEMU에서 VM을 하나 생성하면 해당 VM의 화면을 보여주기 위해서 VM마다 자체적으로 VNC 서버를 실행하고, 그 VNC 화면마다 포트번호가 하나씩 할당이 되는데, 그게 5900번부터 시작한다. 그런데 qemu가 실행하는 VM의 개수가 10개를 넘으면, 10번째로 실행되는 VM은 가상 머신의 화면 출력을 위해 포트번호 5910을 할당받게 된다.

다만, 여기에 호스트 서버의 xfce4 세션이 먼저 실행이 되고 포트번호 5910을 미리 할당받고 있는 상태였으면 VM의 화면이 5910 포트를 할당받는 일은 없었을 것이다. 그러나 호스트 서버를 재부팅시키고 나서, 자동으로 시작하도록 설정되어 있는 모든 VM들이 자동으로 부팅이 먼저 되고, 호스트 서버의 xfce4 세션은 사용자가 명시적으로 실행시켜 주지 않으면 5910번 포트가 비어 있게 되므로 10번째로 자동 시작되는 VM이 자연스럽게 5910을 할당받게 된다. 그리고 부팅 직후에 자동으로 같이 부팅되는 VM의 개수가 10개를 넘어간다면, xfce4 세션을 qemu-kvm 서비스보다도 먼저 부팅 직후에 자동으로 실행돼서 세션 하나를 만들어주도록 설정하지 않는 이상 VM 중의 하나가 5910 포트를 점유하게 된다.

결국 원격 데스크톱 연결 앱으로 서버에 접속할 때 맨 처음 나타나는 XRDP 세션 로그인 화면(맨 위의 화면)에서 5911, 5912, ... 이렇게 하나씩 포트번호를 바꿔 가며 접속을 시도해 보니, 호스트 서버를 위한 GUI 세션은 5915번에 할당되어 있었다. (그 당시에 VM 15개가 실행중이었음) 이 상황을 연구실 학생들과 공유를 해야 하는데... 설명하기가 쉽지 않다. ㅜㅜ

여러가지 측면에서 리눅스 서버를 공동으로 관리할 때의 불편함이 있는 것 같다. 그냥 후배들이 똑같은 문제에 봉착하면 그 때 그냥 나와 같은 과정을 거쳐서 XRDP, xfce4-session, qemu-kvm 서비스 및 데몬들이 5900부터 시작하는 포트 번호를 할당받고 반대로 5910 포트를 통해 접근을 시도하면서 서로 어떤 영향을 끼치는지 직접 겪어 보는 수밖에 없는 듯 하다.

회사라면 이런 일을 System administrator가 대신 해 주지만, 연구실은 그렇지 않으니까... 매번 동일한 문제가 생기면 똑같이 겪어 보고 배우는 것이 각자의 이해를 넓히는 측면에서도 바람직한 것이 아닐까 하는 생각도 든다.