5.1 리눅스(또는 이종) 네트워크에서의 컴퓨터 공유 by David Mertz
리눅스(또는 이종) 네트워크에서의 컴퓨터 공유, Part 1
Secure shell (SSH)과 Virtual Network
Computing (VNC) 비교
난이도 : 초급
David
Mertz 박사, 프로그래머/작가, Gnosis Software, Inc.
2001 년 12 월 01 일
Secure
shell (SSH)과 Virtual Network Computing (VNC)을 여러 각도에서 비교한다. 두 기술 모두
사용자가 하나의 워크스테이션에서 다른 컴퓨터에 있는 애플리케이션을 실행할 수 있도록 하는 기술이다. (파일 및 프린트 공유나
httpd, ftpd, smtp, nntpd와 같은 인터넷 서비스는 다루지는 않을 것이다.) SSH와 VNC를 설치하고 설정하는
팁을 비롯하여 툴 안정성, 툴 선택, 라이센스 등에 관해 설명한다.
다양한 소프트웨어 프로그램을 효율적으로 작성하고 테스트하기 위해서, 내 로컬 네트워크상에는 상당히 많은
컴퓨터들이 있다. 이러한 머신들은 다양한 오퍼레이팅 시스템을 구동하고 있고 다양한 범위의 하드웨어 설정이 되어있다. 가끔씩
다양한 플랫폼상에서 툴을 평가하기도 한다; 직접 작성한 툴을 테스트하고 디버깅 한다.
네트워크 상의 머신들 대부분은 멀티 부팅 설정으로 다중 오퍼레이팅 시스템이 설치되어 있다. 이 중 많은 것은
"headless" 이다. (모니터나 키보드가 없다). VMWare, Plex86, VirtualPC, SheepShaver
등과 같은 하나의 오퍼레이팅 시스템을 가상화(virtualize)하는 툴은 평가하지 않았다. 어떤 부분에서는 그러한 툴들은 이
글에서 논하려는 것과 비슷한 목적을 수행할 것이다.
다양한 기술들로 인해서 한 워크스테이션의 사용자가 다른 컴퓨터의 애플리케이션을 구동할 수 있다. SSH는 원격
컴퓨터에 텍스트 터미널을 제공한다; X Window System은 실제로 실행되는 곳과는 다른 워크스테이션 상에 대화식의
애플리케이션을 디스플레이 하는 데 사용될 수 있다; VNC는 전체 원격 데스크탑에 대해 "리모콘" 역할을 수행한다. 각 기술에는
장단점이 있다. 그들은 모두 리눅스에서 실행되고 다양한 OS환경과 상호작용이 가능하다. 이러한 툴들을 사용하여 나는 한
워크스테이션(최상의 모니터, 키보드, 의자를 갖추고 있다!)에 앉아서 많은 플랫폼상의 애플리케이션들을 실행하고 테스트하며 시간을
재고 있다. 어떤 것도 재부팅 할 필요가 없다.
나만의 네트워크 설정
나의 로컬 네트워크에는 7개의 노드가 있다. 각자 Apollo, Bacchus, Chaos, Delphi,
Echo, Fury, Gaia라는 이름을 붙였다. 이 노드들은 각각 192.168.1.101에서 192.168.1.107까지의
IP 어드레스도 갖고 있다. 물리적으로 같은 머신은 같은 IP 어드레스를 가지고 있다. (가끔씩 DHCP를 사용하는 데 이것은
192.168.1.200 이상의 어드레스를 할당한다). 모두 하드웨어 방화벽/라우터 뒤에 배치되었다. 나는 방화벽을 충분히
신뢰한다. (인터넷을 통해 컴퓨터를 공유해야 하는 독자들이라면 보안에 좀 더 주의를 기울여야 한다. 다음 글에는 보안 문제에
대해서 다루겠다).
앞으로 설명할 쉘 예제를 쉽게 따라올 수 있도록 지금까지 자세한 설명을 했다. 실제로 내가 앉아있는 머신은
Bacchus 이고 로컬 IP 어드레스는 192.168.1.102 이다.
Secure shell (ssh)
컴퓨터를 연결하는 대역 친화적인 방식 대부분은 간단한 테스트 쉘을 통한 것이다. 이 같은 비 보안
(Non-secure) 툴로는 telnet과 rsh 등이 있다. 하지만 이들을
사용할 때 많은 보안상의 문제들이 발생한다. 차라리 통신을 해야 한다면 컴퓨터에 ssh를 설치하는 것이
낫다. 많은 유닉스 계열 오퍼레이팅 시스템(리눅스 포함)들은 디폴트로 ssh가 설치되어 있다. 설치되어
있지 않다면, 참
고자료에 설치 방법이 소개되어 있다.
Secure shell (ssh)은 특정 채널을 통해 오는 모든 트래픽을 암호화 한다.
공개 키 암호가 사용되기 때문에 서버와 클라이언트가 세션 초기화에 앞서 키를 공유할 필요가 없다. 게다가 채널을 통해서는 암호화
되지 않은 어떤 '비밀'도 전송되지 않는다. VNC 또는 X Window 같은 다른 프로토콜들은 ssh의
상단에 놓일 수 있다. 원격 테스트 콘솔을 만드는 데 가장 간단하게 사용될 수 있다.
ssh를 사용하면 로컬 머신상의 다른 오퍼레이팅 시스템으로 쉽게 연결 할 수 있다.
이때, 원격 머신이 sshd 서버를 실행하고, 로컬 머신이 ssh 클라이언트를
실행해야 한다. 예를 들어 OS/2 Warp "Bacchus" 머신을 Slackware Linux "Delphi" 머신으로
연결할 경우, 다음과 같이 할 수 있다:
ssh를 이용하여 HOSTS 이름으로 원격 박스에 연결하기
C:\UTILS % ssh quilty@delphi
Last login: Thu Nov 29 01:41:36 2001 from 192.168.1.102
Linux 2.2.19.
quilty@delphi:~$ exit
logout
Connection to delphi closed.
|
HOSTS 파일이 앨리어스(alias)를 정의하지 않았다면 다음과 같이 한다:
ssh를 이용하여 IP로 원격 박스에 연결하기
C:\UTILS % ssh quilty@192.168.1.104
Last login: Thu Nov 29 01:51:31 2001 from 192.168.1.102
Linux 2.2.19.
quilty@delphi:~$
|
이와 마찬가지로 나는 임대한 웹서버를 다음을 사용하여 관리한다:
ssh를 이용하여 DNS 이름으로 원격 박스에 연결하기
C:\UTILS % ssh gnosis@gnosis.cx
gnosis@gnosis.cx's password:
|
이종 플랫폼 상에서 ssh와 관련된 가장 어려운 점은 올바른 터미널 설정이다. 문제는
ssh 자체의 문제가 아니다. 두 개의 리눅스 머신을 함께 연결하는 것은 별 문제없이
수행된다. 하지만 클라이언트 또는 서버로서 개입된 다른 플랫폼이 있을 때, 디스플레이가 정확하게 되지 않거나 키 바인딩이
예상했던 대로 수행되지 않는다. Win32, BeOS, MacOS, OS/2 같은 비 유닉스 계열 플랫폼이 개입되면 문제는 특히
심각해진다. 심지어 리눅스와 FreeBSD를 연결할 때도 완벽하지 않다.
이종 머신들 간에 ssh 연결을 할 때 발생하는 가장 일반적인 문제들은
코드페이지(codepage)가 틀리거나 "color escape code"들이 틀리다는 것이다. 둘 중 한 문제가 발행하면 기본
명령어 라인을 사용할 수 있다. 종종 컬러가 아닌 단색의 터미널 만이 보이게 된다. 쉘 명령어는 이러한 "impedance
mismatch"으로 인한 문제가 없지만 대화형 curses 또는 slang
타입의 애플리케이션은 많은 문제를 겪는다. 그와 같은 애플리케이션 중 가장 주목할 것은 텍스트 에디터이다. 이것은 대부분 원격
콘솔을 통해 실행해야 하는 애플리케이션이다. jed 는 특별히 훌륭한 원격 텍스트 모드 에디터이다;
강심장을 가진 사람들은 아마도 vim을 사용할 것이다. 다른 대부분의 리눅스/유닉스 에디터는 X
기반이거나 전체적으로 조잡했다.
만일 터미널 설정 문제가 있다면 몇 가지 방법이 있다. 유닉스 계열의 sshd 서버로
연결한다면 원격 TERM 환경 변수를 변경해보라:
대중적인 원격 터미널 세팅
quilty@delphi:~$ TERM=vt100
quilty@delphi:~$ TERM=ansi
quilty@delphi:~$ TERM=linux
|
로컬 ssh 클라이언트는 터미널 타입의 연결을 설정하는 데에 보통 한 가지 방법을
가지고 있다. 플랫폼과 클라이언트 프로그램에 따라, 명령행 옵션이나 환경 변수 또는 메뉴창이 될 수 있다. 두 끝단에서 이름이
똑같은 것으로 끝나지 않을 수도 있다. 여기에는 몇 가지 에러가 있다. 또한 클라이언트 설정 범위내에서 "no codepage
translation"을 사용하고 있는지를 확인해야 한다. "impedance match"를 테스트하려면 "fullscreen
remote application" (jed 또는 기타 에디터)을 실행해보라.
Virtual Network
Computing (VNC)
VNC는 많은 GUI 플랫폼에 포팅되고 있는 클라이언트/서버 시스템이다. VNC는 로컬 시스템상의 원격
컴퓨터의 전체 "데스크탑"을 디스플레이 하는 데에 사용되는 프로토콜을 제공한다. Symantec의 pcAnywhere는
같은 용도로 쓰이는 상용 제품이다. 하지만 Microsoft 오퍼레이팅 시스템에만 제한되어 있다. 반면, VNC는 수십 개의
다른 오퍼레이팅 시스템상에서 실행되며 많은 구현과 "variation"들이 있다.
웹사이트 (참
고자료)에서 스크린샷을 참조하는 것도 VNC를 이해하는데 도움이 된다. 일반적으로, VNC 클라이언트 (vncviewer)
를 가지고 있는 모든 플랫폼은 로컬 윈도우 범위 내에서 VNC 서버 (vncviewer)
를 가진 모든 플랫폼의 가상 데스크탑을 디스플레이 할 수 있다. VNC 클라이언트 버전에 따라, 리사이징(resizing)과
fullscreen 옵션 등을 사용할 수 있다.
X-based 버전의 VNC 서버 (Xvnc)와 다른 플랫폼용 서버 사이에는 약간의
차이점이 있다. Windows, MacOS, BeOS, OS/2 같은 단일 유저 시스템은 X Window System의
수행방식인 "desktop sessions" 개념이 없다. 따라서 Windows VNC 서버는 로컬 시스템상에 나타나는 같은
Windows 데스크탑의 원격 버전만을 디스플레이 한다; 이것은 연결할 때 "desktop :0" 으로 호출된다. 반면 X
Window는 멀티 유저/멀티 세션이다. 각각의 Xvnc 세션은 새로운 데스크탑을 만들고 고유의
해상도, 윈도우 매니저, 상태(state)등을 만든다. 다시말해서, X는 VNC 보다 훨씬 더 훌륭하다.
일단 VNC가 설치되면 세션을 시작하는 것은 간단하다. (참
고자료). 단일 유저 플랫폼의 경우, 기본적으로 애플리케이션은 실행할 수 있다. 어떤 옵션도 없다. X 에서, 몇 가지
명령행 옵션들은 유용하다. OS/2 Warp "Bacchus" 로컬 머신에서 Mandrake Linux "Fury" 머신까지 telnet
세션을 연결한 예를 보자:
Fury에서 VNC 서버 세션 시작
[root@fury quilty]# cat /usr/bin/vnc-sessions
vncserver -name TinyLinux -depth 8 -geometry 640x480
vncserver -name BigLinux -depth 32 -geometry 1260x940
[root@fury quilty]# vnc-sessions
New 'TinyLinux' desktop is fury.gnosis.lan:1
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/fury.gnosis.lan:1.log
New 'BigLinux' desktop is fury.gnosis.lan:2
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/fury.gnosis.lan:2.log
|
클라이언트 측에서 로컬 vncviewer를 사용하여, Fury:1
또는 Fury:2 로 연결 할 수 있다 (또는 한 번에 양쪽 모두 가능). 또한 192.168.1.106:1
을 지정할 수 있었다.
같은 원리가 "non-local" 네트워크에도 적용되며 VNC는 보안 용도로 SSH를 통해 터널로 설정될 수
있다.
대부분의 경우, vncviewer를 원격 컴퓨터에 연결하는 것은 기능상으로 볼 때 그
원격 컴퓨터에 대해 (이것이 headless가 아니라는 것을 가정할 때) 로컬 모니터와 키보드 앞에 앉아 있는 것과 같다.
심미안적으로 볼 때 원격 시스템의 데스크탑은 로컬 머신의 위젯을 사용하여 윈도우에 의해 짜여질것이다. (fullscreen
옵션을 사용하지 않는 한). 이러한 가외의 프레임은 언뜻 보기에는 산만하게 보이지만 조금 사용하다 보면 무뎌진다.
올바른 세션 지오메트리(geometry)와 색상 깊이를 선택하는 것은 중요하다. 원격 데스크탑이 작을 수록
그리고 사용된 컬러 수가 적을 수록, 디스플레이 반응은 좀 더 빨라진다. 컬러 깊이를 줄이는 것이 반응에 약간의 영향을 미친다는
것을 발견했다; VNC의 hextile 인코딩은 스크린의 세련되지 못한 "pixel-by-pixel" 전송 보다 훨씬 더
효율적이다. 하지만 스크린 사이즈는 분명한 차이를 보인다.
일반적으로, 위의 1260x940과 같은 원격 지오메트리를 사용하면 1280x1024 비디오 세팅으로 매우
훌륭히 작동한다. 나는 약간의 여유 공간을 두어 VNC titlebar와 로컬 데스크탑의 taskbar를 위한 공간으로
허용했다. 하지만 vncviewer 윈도우는 여전히 전체 스크린 대부분을
차지하고 있다. 그런대로 괜찮다. 100 Mbit 이더넷 연결을 할 때 로컬 디스플레이 보다 나쁘지 않다. 10 Mbit 이더넷
상에서, 윈도우를 옮기거나 사이즈를 조절할 때 미세한 디스플레이를 보게 된다. 좀 더 느린 속도로는 VNC가 원격 작동에 대한
최적의 솔루션이 되지 않는 경향을 보인다. Cable, DSL, T1 연결 또한 완벽하게 작동한다. 이 보다 작은 것은
비상용(emergency)으로만 쓰인다.
VNC 연결에 있어서 한 가지 문제점은 로컬 데스크탑은 고유의 목적에 맞춰 몇 가지 키스트로크를 이용해야
한다. 특정 클라이언트에 따라, 많은 원격 키스트로크가 다중 키스트로크 작동으로 에뮬리에트 되어야 한다. 예를 들어, 나의 로컬
OS/2 vncviewer의 경우 원격 Alt-F 를 입력하기 위해서는 Alt-A,
F, Alt-A 를 눌러야 한다. 가외의 스트로크들은 가끔씩 조절하기가 힘들다. Macs 같이 고유의 키보드와
(원버튼) 마우스를 가지고 있는 "non-PC" 플랫폼에서 상황은 훨씬 더 복잡해진다. 더 많이 공부해야 겠지만 일반적으로 원격
인풋 액션을 에뮬레이팅하는 방법이 있다. 리눅스에서 리눅스로의 연결은 부드럽게 작동한다.
주목할 만한 VNC 구현이라 한다면 Java 버전일 것이다. 고유의 vncviewer
없는 플랫폼에도 Java 버전을 사용할 수 있다. (JVM이 플랫폼을 위해 존재한다고 가정할 때). VNC-java는 웹
브라우저 내에서 실행될 수 있다. 연결에 필요한 익숙한 인터페이스를 제공한다. 하지만 Java viewer는 브라우저 밖에서는
Java 애플리케이션 처럼 작동할 수 있다. 참
고자료 에서 VNC-java에 대한 정보를 얻기 바란다.
참고자료
- developerWorks worldwide 사이트에서 이 기사에 관한 영어원문.
- 상용 공식 버전의 SSH
: SSH Communications Security 제공. 비 상업적 용도로 무료로 사용할 수 있지만 Free
Software는 아니다.
- 대부분의 리눅스 배포판은 OpenSSH
를 사용한다.
- FreSSH : 기존
코드에 대한 의존성을 피하기 위해 SSH 프로토콜을 재구현 한 것.
- FreeSSH 사이트:
(FreSSH와 혼동하지 말것) 무료/상용 SSH 구현 정보 제공.
- Windows의 경우, Free (MIT 라이센스) Software 프로그램인 PuTTY
를 권한다. 설치가 쉽다.
- BeOS와 OS/2의 경우, 각각 BeBits.com과
Hobbes OS/2 archive를
참조하기 바란다.
VNC 참고자료
VNC 참고자료
기타 참고자료
- David Mertz의 developerWorks 튜토리얼:
리눅스(또는 이종) 네트워크에서의 컴퓨터 공유, Part 2
VNC, Desktop On-Call, remote X, 보안
난이도 : 초급
David
Mertz 박사, 회장/CEO., Gentoo Technologies, Inc
2002 년 3 월 01 일
이 글에서는 원격에서 애플리케이션을 실행하는 방식으로서 SSH, remote X, VNC, 다른
기술들을 비교한다. David는 VNC 설정 문제, IBM의 Desktop On-Call, remote X, 보안 문제를 다룬다.
Part
1 에서는 이종 로컬 네트워크를 설명하고 다른 OS와 아키텍쳐에서 애플리케이션을 비교하고 테스트하는데 이를 어떻게
사용하는지를 설명했다. 하나의 워크스테이션에서 사용자는 다양한 기술을 사용하여 다른 워크스테이션에 있는 애플리케이션을 실행할 수
있다. SSH는 원격 컴퓨터에 텍스트 터미널을 제공한다; X Window System은 이것이 실제로 실행되는 곳이 아닌 다른
워크스테이션에서 인터랙티브 애플리케이션을 나타내는데 사용될 수 있다. VNC는 전체 원격 데스크탑에
리모콘(remote-control) 역할을 한다.
각 기술들마다 장단점이 있다. 그들 모두 리눅스에서 실행되지만 variation(호스트 또는 원격)은 이종
네트워크에 맞는 다양한 OS 환경과 인터랙션이 가능하다. 이러한 툴틀을 조합하여 나는 하나의 워크스테이션(최상의 모니터,
키보드, 의자를 갖춘)에서 어떤것도 재부팅하지 않고 다른 플랫폼들에 있는 애플리케이션을 실행하고 테스트하고 조정한다.
Part
1에서 SSH와 VNC를 소개했다. 이 글에서는 VNC에 대해 좀더 이야기하겠다. 원격 X와 보안도 다루겠다.
네트워크 셋업
나의 로컬 네트워크에는 7개의 노드가 있다. 각각 Apollo, Bacchus, Chaos, Delphi,
Echo, Fury, Gaia라는 이름을 가지고 있다. 이 노드들은 로컬 IP 주소 192.168.1.101 에서
192.168.1.107까지 할당받았다. 다른 OS들로 멀티부팅 될 때 같은 머신이 같은 IP 주소를 얻는다. 공용 인터넷을
통해 컴퓨터를 공유하길 원하는 독자들이라면 보안 문제를 고려해야 한다. 내가 실제로 사용하고 있는 머신은 Bacchus이고 IP
주소는 192.168.1.102 이다.
VNC 설정하기
Part
1 에서 리눅스 플랫폼에서 VNC를 시작하는 방법을 설명했고 스크린 배치와 칼러에 대한 언급을 했었다. 하지만 VNC를
설정하여 사용하는 중요한 문제는 거론하지 않았다. 이 글에서는 오직 UNIX 계열 Xvnc 서버의
사용에 초점을 맞추겠다.
주어진 사용자 계정에서 vncserver가 처음 실행되면, VNC 클라이언트가
연결해야 하는 패스워드 지정을 해야한다. 게다가 몇 개의 디폴트 설정 파일이 만들어진다:
VNC 디폴트 설정
[vnc-user@fury vnc-user]$ vncserver
You will require a password to access your desktops.
Password:
Verify:
New 'X' desktop is fury.gnosis.lan:3
Creating default startup script /home/vnc-user/.vnc/xstartup
Starting applications specified in /home/vnc-user/.vnc/xstartup
Log file is /home/vnc-user/.vnc/fury.gnosis.lan:3.log
|
VNC 세션을 만들었다. 명령행에 어떤것도 지정되지 않으면 기본 해상도가 사용된다. 기본
지오메트리(geometry)는 1024 x 768 이며, 기본 색상 수는 8-bit 이다. Part
1에서는 다른 해상도를 사용하는 스크립트 파일을 구현하는 방법을 설명했다.
첫 실행시 만들어진 ~/.vnc/xstartup 파일을 주목해야 한다. 이 파일은
VNC 세션이 만들어 질때 발생하는 일을 제어한다. 처음 ~/.vnc/xstartup이 만들어질 때
지정된 윈도우 매니저는 twm이다 이것은 거의 모든 X Window System 머신에 존재하는 극소의
윈도우 매니저이다. twm 의 작다는 특성상 대역폭 친화적인 방식으로 VNC를 실행하는 것이 가능하다.
하지만, twm은 KDE, GNOME, WindowMaker 같은 "데스크탑 매니저"의 풍부한 기능에는
미치지 못한다. 많은 사용자들은 xstartup을 편집해야 한다:
VNC "시작" 커스터마이징
#!/bin/sh
xrdb $HOME/.Xresources
xsetroot -solid grey
#xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm &
#exec wmaker
exec startkde
|
위 예제에서, 기본 twm과 xterm에 주석처리를 했다.
WindowMaker의 앞에도 주석을 달았다. 나중에 그들을 복원할 경우를 대비하여 지우지 않았다. 이 계정을 가지고 실제로
하는 것은 KDE를 시작하는 것이다. 하지만 백그라운드와 타이틀바의 색상 변화를 피하고 최소의 움직임 효과를 사용하기 위해
특별히 KDE 데스크탑 설정을 했다. 데스크탑의 분주함을 최소화하면 채널 대역폭에서 KDE가 쉬워진다. 다른 윈도우 매니저에도
비슷한 원리가 적용된다.
VNC 세션을 죽이는 문제를 살펴보자. 이를 서버 끝단에서 수행해야 한다. VNC 세션이 시작했는지를 보는
빠른 방법은 ps -ax | grep vnc를 이용하는 것이다. 원한다면 리눅스의 kill
명령어를 이용할 수 있지만 나중에 수작업으로 지워야하는 세마포어 파일을 남길 수 있다. 깔끔한 접근방식은 vncserver
-kill :1을 사용하는 것이지만 root 계정에서 사용자 VNC 프로세스를 강제로 죽이려면 kill
명령어를 사용한다.
Desktop On-Call &
eComStation
"Charming Python" 칼럼 독자들이라면 OS/2를 참조하는 것에 약간 놀랐을 것이다. 이것은 수년
전에 대중성을 잃은 것이기 때문일 것이다. 하지만 OS/2 Warp의 Workplace Shell은 리눅스, Windows,
MacOS, BeOS에 나타난 어떤 GUI 보다도 훨씬 앞서있다는것이 나의 지론이다. WPS은 정말 좋지만 내가 사용하는 진짜
이유는 관성적으로 사용하는 것에 가깝다. 수년 동안 OS/2 친화적인 툴을 구현해왔다. 그리고 그들은 서로 잘 작동했다.
최근 Serenity Systems' eComStation의 리뷰 카피를 받은것에 흥분되어 있다.
eComStation (eCS)은 작년에 발표되었고 "Warp core"에 최신 패치와 기타 툴들이 포함되어 있다.
eCS에 포함된 툴에는 "Desktop On-Call (DToC)"이라는 IBM 제품이 있다. DToC 서버
버전은 Windows와 리눅스 모두 사용가능하다. 하지만 미국에서는 구입하기 힘들다. DToC가 하는 일은 VNC의 역할과
비슷하다. DToC 서버는 네트워크를 통한 "원격 데스크탑"을 제공하기 위해 HTTP 프로토콜로 전송한다. DToC용 클라이언트
애플리케이션은 JavaScript와 자바 모두 가능한 브라우저이다. 기본적으로, 웹 브라우저는 DToC로의 연결 인터페이스이다.
DToC는VNC 처럼 로컬 캡쳐 키스트로크, 멀티 키 시퀀스, 대역폭/해상도 모순 문제를 갖고 있다.
DToC는 VNC 보다 장점이 많다. HTTP 전송은 DToC가 VNC보다 방화벽 통과가 쉽다는 것을
의미한다. 게다가 DToC안에서 파일 전송 인터페이스를 얻기때문에 DToC가 실행되는 한 개별 FTP, Samba, NFS 등의
전송 서버가 실행될 필요가 없다. 하지만 단점은, DToC는 VNC보다 응답속도가 느리다는 점이다. 하지만 심각할 정도는
아니다.
eCS에 번들된 다른 툴은 Hoblink X11is라고 하는 X Server이다. 아직 사용해본적은 없지만
사용하게 되면 나의 로컬 네트워크의 OS/2 노드에 훨씬 쉽게 통합될 것이다.
Remote X Window System
X Window System은 매우 훌륭한 소프트웨어 발상이다. 대부분의 리눅스 사용자들에게 X Window
System은 (또는 "X11", 하지만 "X Windows"를 칭하는 것은 아님)은 아마도 GUI 애플리케이션을
로컬에서 디스플레이 하기위해 윈도우 매니저를 호출하는 API로서 인식된다. 하지만 실제의 X11은 훨씬 더 재미있다.
X11은 언제나 클라이언트와 서버를 갖고 있다. 심지어 클라이언트와 서버 모두 같은 머신에서 실행될 때도
그렇다. X 클라이언트와 X 서버는 우리가 생각하는 것과는 반대일 것이다. X 서버는 기저의 애플리케이션에 디스플레이 기능을
제공하는 디바이스이다. X 클라이언트는 시각적 아웃풋을 내놓을 수 있는 장소를 제공하는 X 서버와 비슷하다.
서버와 클라이언트는 로컬 워크스테이션에서 실행되면서 순전히 내부 채널을 통해 통신한다. 하지만 로컬 머신과
원격 머신이 개입되면 로컬 머신은 X 서버이고 원격 머신은 X 클라이언트가 된다. 가끔은 다른 워크스테이션에 디스플레이 되어야
할 필요도 있다. 그러할 경우 역할은 보존된다.
X Window System을 충분히 활용하기 위해서는 상단에 윈도우 매니저를 실행하도록 한다. 이렇게 하여
윈도우를 움직이고, 최소화하며 새로운 X 클라이언트를 시작할 수 있다.
로컬 워크스테이션에 디스플레이하기 위해 원격 애플리케이션(X 클라이언트)을 시작하는 방법을 살펴보자. 앞으로
설명될 모든 머신은 리눅스지만 X 서버와 클라이언트가 있는 다른 시스템도 비슷한 방식으로 작동한다. 로컬 머신이 사용할 IP
어드레스를 설정해야한다. ifconfig가 이 경우 훌륭한 툴이 된다.
로컬 머신의 IP 주소 찾기 (X 서버)
[root@bacchus /root]# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:48:54:83:82:AD
inet addr:192.168.1.102 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:15933 errors:0 dropped:0 overruns:0 frame:0
TX packets:10426 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:10 Base address:0xe800
|
그런다음 원격 머신의 애플리케이션이 로컬 X 서버를 사용할 수 있는 로컬 권한을 갖고 있는지를 확인한다:
X 서버 권한 설정
[root@bacchus /root]# xhost -
access control enabled, only authorized clients can connect
[root@bacchus /root]# xhost +192.168.1.106
192.168.1.106 being added to access control list
|
원격 머신에 실행할 애플리케이션을 시작할 수 있다. 직접 머신으로 갈 수도 있지만 대부분의 경우 원격 쉘
세션을 여는 것이 가장 쉬운 방법이다. (여기에서는 불안한 telnet 메소드가 사용된다):
원격 머신 Fury로 연결하기 (X 클라이언트)
[root@bacchus /root]# telnet -l quilty 192.168.1.106
Trying 192.168.1.106...
Connected to 192.168.1.106.
Escape character is '^]'.
Password:
Last login: Tue Nov 27 18:07:51 from 192.168.1.201
|
모든것이 잘 진행된다면, 원격머신은 자동으로 연결되고 있는 머신을 찾는다. 다음은 그 반대의 경우이다:
X Client Fury의 DISPLAY 환경 변수 확인
[quilty@fury quilty]$ echo $DISPLAY
bacchus.gnosis.lan:0
|
X 클라이언트를 시작할 수 있다. 예제에서는 xeyes 애플리케이션이 사용된다:
X 서버상에 나타날 X 클라이언트의 애플리케이션 시작하기
[quilty@fury quilty]$ xeyes &
[1] 9939
|
원격 애플리케이션을 시작할 때의 오류
가끔씩 위와 같은 상황에서 문제가 생긴다. 다음의 전형적인 문제를 보자:
원격 머신 Delphi로 연결하기
[root@bacchus /root]# /usr/local/bin/ssh quilty@192.168.1.104
quilty@192.168.1.104's password:
Last login: Wed Nov 28 01:06:08 2001 from 192.168.1.201
Linux 2.2.19.
|
위와 같은 순서로 실행해보자:
X Client Delphi의 DISPLAY 환경변수 점검
quilty@delphi:~$ echo $DISPLAY
quilty@delphi:~$ xeyes &
[1] 17668
quilty@delphi:~$ Error: Can't open display:
[1]+ Exit 1 xeyes
|
DISPLAY 환경변수로 찾아진 값이 없기 때문에 X 클라이언트는 어떤 서버가
디스플레이를 해줄 서버가 어떤 것인지를 모르고 있다:
No (잘못된) DISPLAY 설정
quilty@delphi:~$ export DISPLAY=192.168.1.102:0
quilty@delphi:~$ xeyes &
[1] 17669
quilty@delphi:~$ Xlib: connection to "192.168.1.102:0.0" refused by server
Xlib: Client is not authorized to connect to Server
Error: Can't open display: 192.168.1.102:0
[1]+ Exit 1 xeyes
|
Bacchus는 X 서버를 사용할 수 있는 권한받은 Delphi가 아직 없다:
X 서버가 연결을 거부했다. 연결하도록 한다.
[root@bacchus /root]# xhost +192.168.1.104
192.168.1.104 being added to access control list
|
모든 것이 잘되어 간다:
Launch an app on X Client to display on X
Server
quilty@delphi:~$ xeyes &
[1] 17670
|
보안 문제
Part
1에서 VNC와 X11 모두 인터넷 채널을 통할 때 불안하다고 언급했다. 모든 원격 디스플레이는 공용 라우터를 통해
암호가 해제된다. 나는 방화벽 뒤에 있는 개인용 LAN을 걱정하지 않는다. 전 세계적으로 원격 컴퓨터를 공유하기 위해 이러한
기술을 사용하려면 VNC 또는 X11 프로토콜은 SSH를 통해 레이어링(layer) 한다.
SSH를 통해 VNC를 설정하려면 "Making VNC more secure using SSH" (참
고자료)를 읽기를 바란다.
SSH를 통한 X 레이어링은 쉽다. OpenSSH를 사용하고 있다면 sshd_config
파일을 수정해야 한다. 다양한 리눅스 배포판들은 이 파일을 각기 다른 장소에 두고 있다. Mandrake 7.1은 /usr/local/etc/에
서, Slackware 7.0은 /etc/ssh/에서 사용한다. 대부분의 경우 파일에는 다음을 포함하고
있다:
X11Forwarding yes
설정을 적용하려면 sshd 데몬을 재시작한다.
로컬 X 서버에 디스플레이하기 위해 X 클라이언트를 시작하는것은 sshd를 올바로
설정하는 것보다 쉽다:
X 클라이언트로 포워팅한 sshd X11 사용하기
[quilty@bacchus quilty]$ ssh -X quilty@192.168.1.104
quilty@192.168.1.104's password:
Last login: Fri Nov 30 16:53:03 2001 from 192.168.1.102
Linux 2.2.19.
quilty@delphi:~$ echo $DISPLAY
delphi:10.0
quilty@delphi:~$ xeyes &
[1] 201
|
Delphi로 연결하더라도 DISPLAY 변수는 X 서버가 Delphi에 있다는 것을
나타내도록 한다.
참고자료
IBM Desktop On-Call 참고자료
X Window System 참고자료
기타 참고자료
필자소개
 |
|
|
|
David Mertz는 20년 동안 프로그래머와 작가로 활동해 왔다. 프로그래밍에 대한 글은 최근에
쓰기 시작했다. 실제로 그는 IT에 지대한 관심을 가지고 있는 인문학 교수이다. 소프트웨어 개발과 관련하여 집필활동을 하기도
하지만 어떤 잡지에는 정치 철학이라는 다소 현학적이고 모호한 분야에 대한 글도 쓰는 등 다양성을 지닌 인물이다. http://gnosis.cx/publish/ 를 방문하면
더 많은 정보를 얻을 수 있을 것이다.
|
목차로 가기
| 
