Chapter 1
|
D.M.Z
CONTENT
NEXT
1.1 History
1.2 UUCP Networks
1.3 TCP/IP Networks
1.4 Linux Networking
1.5 Maintaining Your System
1.6 Outlook on the Following Chapters
네트워킹의 아이디어는 의사소통이라는 것만큼 오래된 것일 것이다. 북을 쳐서 메시지를 전하는 석기시대라고 가정하자. A 원시인이 B 원시인에게 돌 던지기 놀이를 하자고 초대하려 하나, B가 그 북소리를 듣기엔 너무도 멀리 떨어져 있다면 A가 할 수 있는 일은? 그는 1) B가 살고 있는 곳까지 찾아가거나, 2) 더 큰 북을 쓰거나, 3) A와 B 사이에 사는 C에게 메시지를 전해달라고 요청할 수 있을 것이다. 이들 중 마지막 것이 바로 네트워킹이다.
물론, 우리는 원시 농경시절 선조의 도구보단 훨씬 발전된 도구를 갖고 있다. 오늘날 우리는 전선의 다발, 광 케이블, 전파 등을 통하여, 토요일의 축구경기 약속을 맺기위해 컴퓨터로 통신한다. 다음에서 우리는 이러한 일들이 이루어지는데 대한 의미와 방법에 관해 다룰 것이다.
이 문서에서는 두 가지의 네트웍에 관해 기술할 것인데, 하나는 UUCP기반, 또 하나는 TCP/IP 기반이다. 이들은 두 컴퓨터간에 자료를 전달하는 프로토콜과 소프트웨어 패키지이다. 이 장에서 우리는 그 두 타입의 네트웍과, 그들 밑에 깔린 원리에 관해 살펴볼 것이다.
네트웍은 상호간에 교신(주로 전용 호스트들의 서비스에 의존하여) 할 수 있는 호스트(host)의 모음이라고 정의할 수 있다. 호스트들은 대부분 컴퓨터이지만 꼭 그래야만 하진 않다. 즉 X-터미널 또는 고지능 프린트도 호스트가 될 수 있다는 것이다. 작은 호스트의 집단 역시 사이트(site)라 불릴 수 있다.
커뮤니케이션은 언어나 코드의 정렬 없이는 불가능하다. 컴퓨터 네트웍에서 이런 언어들은 프로토콜(protocol)이라고 불리워 진다. 그러나 당신도 여기에 프로토콜에 관해 적혀 있다곤 생각치 않을 것이다. 대신, 정상회담 같은 곳에서 관찰되는 행동 양식 같은 고 수준으로 정형화된 코드라고 생각하자. 비슷한 양상에서, 프로토콜은 둘 이상의 호스트 간에 메시지를 교환하는 엄격한 룰일 뿐이다.
1.2 UUCP Networks
UUCP는 Unix-to-Unix Copy의 약자이다. 그것은 시리얼 라인(serial line)을 통하여 파일을 교환하고, 전송의 흐름을 통제하며, 리모트 호스트에서의 프로그램 실행을 초기화 하는 프로그램 패키지에서 출발한 것이다. 70년도 후반의 최초 implementation 이후로 몇번의 주된 변화가 있어 왔으나 그것이 제공하는 서비스에 있어서는 여전히 엄격하다. 그리고 아직도 dial-up 전화 링크에 기반한 광역 네트웍에 응용된다.
UUCP는 1977년 Bell Laboratories에서 그들의 Unix-개발 사이트와 교신하기 위해 개발되었다. 1978년 중반, 이 네트웍은 이미 80개의 사이트와 연결되었고 리모트 프린팅 같은 어플리케이션으로서 e-mail을 돌리고 있었다. 그러나 그 시스템은 주로 신 소프트웨어와 bugfix를 배포하는데 주로 사용되었다. 오늘날에는, UUCP는 더이상 UN*X환경에만 제한 되지 않고, 무료나 상용으로 AMigaOS, DOS, Atari's TOS 같은 여러 플랫폼(Platform)으로 포팅(porting)이 가능하다.
UUCP의 가장 큰 결점은 느린 속도이다. 전화 장비라는 것이 최대 전송률에 제한을 주는 것이고, 또 한가지로 UUCP링크가 영구적인 연결이 아니기 때문이다. 즉, 호스트가 일정 간격을 두고 dial-up으로 상호간에 연결을 하므로 mail message가 UUCP 네트웍을 통과하는데 걸리는 대부분의 소요시간은 다음번 연결을 기다리며 호스트의 디스크에 낭창하게 앉아 있는데 있는 것이다.
이러한 제약에도 불구하고 세상엔 아직도 많은 UUCP 사이트가 존재한다. 그것들은 대부분, 취미가가 운영하거나, 개인사용자에게 일정요금을 받고 네트웍에 접근시켜주는 ISP(Internet Service Provider)형식으로 운영되는데, UUCP가 인기를 누리는 주된 원인은 당연히 Big Internet Cable에 컴퓨터를 연결하는 것보다 비용이 저렴하기 때문이다. 컴퓨터를 하나의 UUCP 노드(node: 네트웍의 분기점이나 단말장치의 접속점)로 만들기 위해 필요한 것이라곤 단지 모뎀, 작동중인 UUCP Implementation, 그리고 mail과 news를 제공하길 원하는 또 다른 UUCP 노드 뿐이다.
1.2.1 How to Use UUCP
UUCP에 내재된 원리는 단순하다. 즉, 그것의 이름이 가리키듯, 그것은 단순히 한 호스트로 부터 다른 호스트로 file을 복사하는 것이다. 그러나 그 뿐 아니라 리모트 호스트에서 어떤 작업을 수행 하게도 한다.
당신의 머신이 swim이라는 가상의 호스트에 접근이 허용되어 있고, 당신이 lpr 커맨드를 실행시키고 싶다고 할 때, 다음과 같이 커맨드라인에 적어주면 이 문서를 swim에서 프린트 할 수 있을 것이다.
$ uux -r swim!lpr !netguide.dvi
이것은 uux(UUCP suite의 커맨드)가 swim의 작업을 스케쥴하도록 한다. 이 작업은 netguide.dvi라는 입력파일을 lpr에게 feed하도록 요청한다. -r flag는 리모트 시스템에 즉시 요청하지 않고 다음번의 연결이 있을 때까지
job을 저장해 놓도록 하는 구실을 한다. 이것을 spooling이라고 한다.
UUCP의 또 다른 특성은 job들을 여러 호스트(그들의 협력하에)를 통해 포워드 시킬수 있다는 것이다. swim이 많은 량의 UN*X aplication archive를 지닌 groucho라는 곳과 UUCP 링크가 되어 있다고 가정할 때, tripwire-1.0.tar.gz라는 파일을 당신의 사이트로 다운로드하고 싶다면 다음과 같이 하면된다.
$ uucp -mr swim!groucho!~/security/tripwire-1.0.tar.gz trip.tgz
생성된 job은 groucho로부터 파일을 가지고 오도록 swim에 요청하고, 당신의 사이트에 trip.tgz라는 이름으로 저장되고 파일의 도착을 알리는 mail이 전달될 것이다. 이것은 3단계에 의해 수행되는데, 첫번째로 당신의 사이트가 swim에게 job을 보낸다. 다음으로 swim이 groucho와 접속한 뒤 파일을 다운로드한다. 그리고 마지막은 swim에서 당신의 사이트로 실제 전송하는 것이다.
현재 UUCP에 의해 제공되는 가장 중요한 서비스는 mail과 news이다. 이에 관해선 다음에 다룰 것이므로 여기선 간략한 소개만 하도록 한다.
Electronic mail(짧게는 email)은 리모트 호스트에 접근하는 방법을 몰라도 사용자가 message를 교환할 수 있도록 한다. 당신의 사이트에서 목적 사이트까지 message를 보내는 임무는 mail handling system에 의해 완벽하게 수행된다. UUCP 환경에선 mail은 주로 수신자 주소와 mail message를 넘겨주도록, rmail 커맨드를 이웃한 호스트에 실행함으로써 운반된다. rmail은 목적지에 도착할 때 까지 message를 포워드 시킬 것이다. 이것에대해선 Chapter 13에서 보다 더 자세히 다를 것이다.
News는 배포된 bulletin board system의 모음이라고 말하는 것이 가장 정확할 것이다. 종종, 이러한 관점에서는 Usenet News를, 집계된 것만 120,000이나 되는 사이트들이 참여하고 있는 news exchange network으로 본다. Usenet의 기원은 1979년, Unix V7과 함께 UUCP가 릴리즈 된 후, Unix community에서의 일반정보교환의 아이디어를 갖고 있던 세 명의 대학원생이 몇개의 script를 집어 넣어 만든 것이며, 그것이 최초의 netnews system이다. 1980년 이 네트웍은 북 캘로리아에 소재한 두 대학의 duke, unc, 그리고 phs에 연결되었고, 이 이외에도 Usenet은 성장했다. 물론 그것이 UUCP기반 네트웍에 기원한다고 해도 이제 더 이상 하나의 단일 네트웍에만 제한되지 않는다.
기본적인 정보의 요소는 특정 주제 전용의 newsgroup 계층에 포스팅된 글이다. 대부분의 사이트는 선택된 newsgroup 만을 수신하는데, 이는 하루당 평균 60MB에 이른다.
UUCP 세계에서, news는 일반적으로 요청된 group의 글을 수집하여 몇개의 batch(컴퓨터로 일괄처리되는 job의 묶음 - 역자주)로 packing하여 UUCP링크를 따라 수신 사이트로 보내진다. 그리고 수신 사이트는 보내온 news를 unpacking하고 그 외의 추가 프로세스를 수행하는 rnews 커맨드를 제공한다.
마지막으로 UUCP는 일반 접근을 허용하는 많은 dial-up archieve 사이트의 매개체이다. UUCP를 이용해서 guest 사용자로 login하여 일반인이 접근가능한 파일을 다운로드할 수 있다. 이러한 guest 계정은 종종 login명으로 쓰이고 그것의 password는 uucp/nuucp 혹은 그와 유사한 것들이다.
UUCP가 저렴한 네트웍 커넥션이란 점에선 좋은 선택일지 몰라도, 그것이 가지는 store-and-forward 기술이 경직된 것임을 입증하는 몇몇 상황이 존재하는데, 예를 들자면 Local Area Network(LAN)이 그러한 것이 되겠다. LAN은 보통 같은 건물 내, 혹은 같은 층에 있는 소수의 컴퓨터들이 상호간에 동일한 작업환경을 제공하도록 연결됨으로써 이루어진다. 전통적으로 이들 호스트(host) 상호간에 파일을 공유하거나 다른 머신에 존재하는 어플리케이션도 실행할 수 있다.
이러한 task는 근본적으로 다른 방식의 네트웍 접근을 필요로 한다. job description(작업 수행 순서도라고 보면됨)에 따라 전체파일을 포워드(forward)하는 대신, 모든 데이터를 작은 조각(혹은 packet)으로 나누어 즉시 목적지 호스트로 보내져 그 곳에서 재 조합된다. 이런 방식의 네트웍을 packet-switched 네트웍이라 하고, 타 종류들 중에서도 이것은 네트웍 너머에서 반 능동적인 어플리케이션 실행을 가능케 한다. 이것의 비용은 그 소프트웨어의 복잡성(혹은 정교성?)에 따라 증가한다.
UN*X system(또 non-UN*X site)가 채용한 해답은 TCP/IP라 알려져 있다. 이 절에서 그에 내재된 개념을 살펴보도록 하자.
1.3.1 Introduction to TCP/IP-Network
TCP/IP의 기원은 1969년에 United States DARPA(Defence Advenced Research Project Agency)가 착수한 연구 프로젝트에서 찾을 수 있다. 시험적인 네트웍이었던 ARPANET, 이것은 성공적인 것으로 판명되어 1975년에 실제 작전 가능한 것으로 변환 되었다.
1987년, TCP/IP는 표준으로 채택되어 모든 네트웍 호스트가 그것을 사용하게 되었다. ARPANET이 인터넷으로 성장하게 되었을 때, (1990년에 ARPANET 자체는 사라졌음에도) TCP/IP의 사용은 인터넷 전체로 퍼지게 되었다. 대부분의 주목할 만한 대상은 LAN이었지만, ISDN과 같은 고속 디지털 전화장비의 출현으로, dial-up 네트웍도 전송수단의 하나로써의 미래를 기약하게 되었다.
TCP/IP를 논함에 있어 구체적인 사항을 보여주기 위해 다음 절에서는 Fredland에 위치한 Groucho Marx University(GMU)를 예로서 들 것이다. 다수의 학과가 자신의 로컬 네트웍을 운영하고, 이들 중 몇몇은 하나를 공유하기도 하며, 어떤 곳은 여러개의 로컬 네트웍을 운영하기도 한다. 그들은 모두 내부적으로 연결되어 있고, 하나의 고속 link로 인터넷과 연결되어 있다.
당신의 리눅스 머신이 수학과내에 erdos라는 이름의 호스트로 (UN*X 호스트로 이루어진) LAN에 연결되어 있다고 가정하자. 이 때, 물리학과의 quark에 접근하려 한다면, 다음의 명령어를 입력하면 된다.
$ rlogin guark.physics
Welcome to the Physics Department at GMU
(ttyq2) login:
프롬프트에 login name을 andres라 넣고 패스워드를 입력하라. 그러면 quark쉘이, 마치 당신이 그 시스템 콘솔에 앉아 있는 것 처럼 주어질 것이다. 그 쉘을 빠져 나오면 다시 자기 머신의 프롬프트로 돌아온다. 지금 당신은 지금 막, TCP/IP가 제공하는 즉흥적이고도 능동적인 프로그램인 remote login을 사용해 보 았다.
quark에 연결되어 있는 동안, X11 기반 어플리케이션, 즉 function plotting 프로그램 또는 PostScrip previewer같은 것을 실행시키고 싶다고 하자. 이들 어플리케이션이 당신 호스트의 화면으로 표시되도록 하기 위해선 DISPLAY 환경변수를 지정해야 한다.
$ export DISPLAY=erdos.maths:0.0
이제, 어플리케이션을 실행시키면 그것은 quark대신, 당신의 X서버와 접촉하여 당신의 화면에 그 프로그램의 모든 윈도우를 표시할 것이다. 물론, 이것은 erdos의 X11서버가 실행중이라는 가정하에서 가능하다. 이의 요지는 TCP/IP가 quark와 erdos사이에 X11패킷을 주고 받음으로써 마치 단일 system을 사용하고 있다는 환상을 준다. 여기서의 네트웍은 대부분 투명성을 지닌다.
TCP/IP 네트워킹에 있어, 또 한가지 중요한 응용법은 NFS로, 이것은 Network File System의 약자이다. 이는 네트웍을 투명성 있게 만드는 또다른 형태인데, 그 이유는 그것이 다른 호스트에서 디렉토리 영역을 마치 local FS(FileSystem)처럼 mount하도록 한다는 것이다. 예를 들자면, 모든 사용자의 홈 디렉토리는 중앙 서버머신에 존재하고, LAN상의 다른 호스트는 그 디렉토리를 mount하는 상황이 있는데, 이의 효과는 사용자가 어느 호스트에서 login하더라도 동일한 홈 디렉토리를 사용할 수 있게 한다. 이와 비슷하게, (TEX 같이)디스크 용량을 많이 차지하는 어플리케이션을 하나의 머신에 설치하고, 다른 머신에 이 디렉토리를 export 시킬수도 있다. 이러한 NFS에 대해선 Chapter 11에서 다시 다루고자 한다.
물론, 이들은 단지 TCP/IP 네트웍에서 할 수 있는 일의 예제일 뿐이고, 그의 가능성은 무궁무진하다
1.3.2 Ethernets
LAN에서 가장 많이 쓰이는 하드웨어 종류는 보통 이더넷(Ethernet)으로 알려져 있다. 그것은 connector, tap 또는 transceiver를 통해 단일 케이블과 연결된 호스트들로 이루어져 있다. 단순한 이더넷의 경우, 설치시 비용이 저렴하고 초당 10Megabit의 속도 때문에 인기가 있다.
이더넷은 세가지 종류가 있다. 즉, 세부적으로 thick,thin, 그리고 twisted pair라 불리는 것들이다. thin과 thick 이더넷은 각각 동축의 케이블을 이용하지만, 이 케이블의 두께와 이를 호스트에 연결하는 방식이 다르다. thin이더넷은 T형의 "BNC" 커넥터를 케이블에 삽입하여 컴퓨터 뒤쪽 플러그에 끼워 돌린다. thick 이데넷은 케이블에 작은 구멍을 내어 "vampire tab"으로 transceiver를 연결해야 한다. thin, thick 이더넷 케이블은 각각 세부적으로 200, 500 미터 거리까지 놓일 수 있으며, 이를 10 base-2, 10base-5라 부른다. twisted pair는 전화 설치시 볼 수 있는 구리선 2개로 이루어진 케이블을 사용한다. 그러나 보통, 이 외에도 추가적인 하드웨어를 필요로 하는데, 그것은 10base-T라 알려져 있다.
thick 이더넷 상에서 호스트 추가가 약간 조잡하긴 하지만, 그것이 네트웍을 다운시키지는 않는다. 그러나 thin net의 경우, 적어도 몇분간은 네트웍 서비스를 중단해야만 한다. 왜냐 하면, 커넥터를 끼우기 위해 케이블을 절단해야 하기 때문이다.
대부분의 사람들이 thin 이더넷을 제안하는데, 그 원인은 바로 저렴한 비용이다. 즉, PC card는 미화 50$ 정도밖에 안되고, 케이블은 미터당 몇센트 정도이기 때문이다. 그러나 큰 규모의 설치시에는 thick 이더넷이 더 적당하다. 예를 들어, GMU의 수학과에선 thick 이더넷을 사용한다. 그러므로 새 호스트 추가시 네트웍 흐름이 붕괴되진 않을 것이다.
이더넷 기술을 저해하는 한가지 요인은 케이블 길이의 제한으로, 이는 LAN이외의 사용을 가로 막는다. 그러나 몇몇 이더넷 세그먼트는 각각 repeater, bridge, 혹은 router로 연결될 수 있다. repeater는 단순히 둘 또는 여러 세그먼트 사이의 신호를 복사하여 마치 모든 세그먼트가 하나의 이더넷인 것처럼 함께 동작하도록 한다. 타이밍 요구상, 네트웍상의 어떤 두 호스트에 4개이상의 repeater는 존재할 수 없다. Bridge와 router는 이보다 좀더 복잡하다. 그것들은 전달된 데이터를 분석하고 수취하는 호스트가 local 이더넷에 존재하지 않을 경우에만 그를 포워드 시킨다.
호스트가 1500바이트에 이르는 패킷(혹은 frame)을 동일 이더넷 상의 다른 호스트에게 보낼 수 있는 상황에서의 이더넷은 마치 bus system처럼 동작한다. 호스트는 이더넷 보드의 firmware(특정 목적의 논리 설계를 정하는 마이크로 프로그램 - 역자주)에 hardcode된 6바이트 수로써 주소화 된다. 이 주소는 흔히 일련의 2자리 16진수를 각각 콜론으로 나누어 표기한다. 즉, aa:bb:cc:dd:ff처럼 말이다.
한 곳에서 보내진 프레임은 연결된 모든 곳에 보여지나, 단지 목적지 호스트만이 이를 받아 처리한다. 만약 두 곳이 동시에 보내려 한다면 충돌이 일어나는데, 이는 두 곳이 전송을 중단함으로써 해결되며 얼마간의 시간후 다시 시도한다.
1.3.3 Other Types of Hardware
Groucho Marx University같이 보다 큰 규모의 설치에서는 이더넷만이 사용되진 않는다. Groucho Marx University에서 각 학과의 LAN은 campus backbone, 즉 FDDI(Fiber Distributed Data Interface)를 돌리는 광섬유 케이블에 연결되어 있다. FDDI는 데이터 전송(즉 기본적으로 일정수의 token을 주위로 보내는 것을 의미함)에 있어서, station이 token을 잡아 내었을 때만 프레임을 보내게 하는, 사뭇 다른 방식의 접근을 사용한다. 이 FDDI의 주된 장점은 100M bps(초당 100메가 바이트)에 이르는 속도와 200KM에 이르는 최대 케이블 길이이다.
원거리의 네트웍을 연결시키기 위해선 X.25표준에 기반한 다른 종류의 장비가 사용된다. 미국의 Tymnet 또는 독일의 Datex-P같은 Public Data Network이라 불리는 곳에서 이 서비스를 많이 제공한다. X.25는 Packet Assembler/Disassembler, 줄여서 PAD라 부르는 특수한 하드웨어를 요구한다. X.25는 자신만의 네트웍 프로토콜 셋을 정의하나 TCP/IP나 다른 프로토콜을 사용하는 네트웍에 연결할 때도 종종 사용된다. IP 패킷이 단순히 X.25로 map될 수 없기 때문에(혹은 그 반대의 경우) 그것들은 단순히 X.25 패킷을 캡슐화 하여 네트웍 너머로 보낸다.
종종, 아마추어 무선기사는 그들의 장비를 컴퓨터의 통신장비로 사용하기도 하는데, 이것을 packet radio 또는 ham radio라 부른다. 이에 사용되는 프로토콜을 가리켜 AX.25라 하는데, 이것은 X.25에서 유래한 것이다.
느리지만 저렴한 또 한가지 기술은 전화연결을 위한 serial line이다. 이것은 패킷을 전송하기 위해, 차후에 다룰 SLIP이나 PPP같은 또 하나의 프로토콜을 사용한다.
1.3.4 The Internet Protocol
물론, 당신의 네트웍이 이더넷에 한정되는 건 원치 않을 것이다. 이상적으로는, 무슨 하드웨어 상에서 실행되든, 어떻게 많은 하부단위로 구성되는 지에 상관없이 네트웍을 사용하길 원할 것이다. 예를 들어 Groucho Marx University와 같은 대규모의 설치에서 연결된 이더넷은 보통 몇개로 나누어 진다. GMU에서 수학과는 2개의 이더넷을 가동하고 있는데, 교수와 대학원생을 위한 빠른 머신의 네트웍이, 그리고 학생들을 위한 느린 머신의 것이 존재한다. 양쪽 모두 FDDI campus backbone에 연결되어 있다.
이러한 연결은 게이트웨이(gateway)라 불리는 전용 호스트에 의해 조정된다. 그리고 이 게이트웨이는 반입되거나 반출되는 패킷을 양 이더넷간과 광섬유 케이블간에 복사함으로써 조정한다. 예를 들어 수학과에 있는 당신의 리눅스 머신에서 물리학과의 quark에 접근하고자 한다면, 이 때 이들은 동일 이더넷상에 존재하지 않으므로 네트워킹 소프트웨어는 quark에 직접 패킷을 보낼 수 없다. 그러므로 그것은 포워드로서의 임무를 수행하는 게이트웨이에 의존하게 된다. (sophus라는 이름의) 게이트웨이는 물리학과의 niels라는 동료 게이트웨이에게 backbone을 통해 이들 패킷을 포워드 시키고, niels는 이를 받아, 다시 목적지 호스트에 배달하게 된다. erdos와 quark의 데이터 흐름은 그림 1.1과 같다.
그림 1.1: erdos에서 quark로 데이터그램을 보내는 과정
리모트 호스트에 데이터를 돌리는 이러한 구조를 라우팅(routing)이라 하고, 패킷은 종종 이 구절에서 데이터그램이라 불릴 것이다. 용이함을 위해, 하드웨어 독립적인 프로토콜, 즉 IP(Internet Protocol)에 의해 데이터그램 교환이 관리된다. IP와 라우팅에 관해서는 2장에서 보다 자세히 다루고자 한다.
IP의 가장 큰 잇점은 물리적으로 다른 네트웍을 외관상 동일한 네트웍으로 변환시키는데 있다. 이를 가리켜 internetworking이라 하고, "meta-network"(여러종류의 다른 네트웍이 결합된 - 역자주)의 결과물을 일컬어 하나의 internet이라 한다. 일반명사로서의 internet과 고유명사로서의 Internet의 미묘한 차이가 바로 이에 있다. 후자는 전 세계적인 'internet'의 공식적인 이름이다.
물론, IP는 하드웨어 독립적인 주소화 구조를 필요로 한다. 이는 IP 주소라고하는 독특한 32비트 수를 각 호스트에 부여함으로써 이루어진다. IP 주소는 보통 4개의 10진수로 표기되며, 이들은 각각 8비트씩 '.'으로 나뉜다. 예를 들어, quark의 IP주소가 0x954C0C04이라고 할 때, 이는 다시 149.76.12.4로 표기될 수 있다. 이러한 양식을 dotted quad notation이라고 한다.
이제, 우리는 주소의 3가지 다른 양식을 알고 있다. 하나는 quakr와 같은 호스트명(hostname)이고, 또 하나는 IP 주소, 그리고 마지막으로 이더넷의 6바이트 주소와 같은 하드웨어 주소이다. 이들은 어쨌든 일치되어야 한다. 그래서 rlogin quark를 쳤을 때, 네트워킹 소프트웨어가 quark의 IP 주소를 얻어서 IP가 데이터를 물리학과의 이더넷으로 전달하면, 그것은 또 어떠한 절차에 의해 그 IP와 상응하는 이더넷 주소를 찾아낼 것이다. 그리고 그것은 다소 혼란스럽다.
우리는 이에관해 여기서 논하진 않고, 대신에 다음 Chapter2 에서 다룰 것이다. 지금은 주소를 찾는 이러한 단계가, 호스트명을 IP주소로 매핑할 때는 hostname resolution이라고 하고, IP 주소를 하드웨어 주소로 매핑할 때는 address resolution이라 부른다는 것만 기억하면 된다.
1.3.5 IP over Serial Lines
시리얼 라인(serial line)상에서, SLIP(Serial Line IP)라는 "사실상의" 표준이 종종 사용된다. SLIP을 보완할 것이 CSLIP(compressed SLIP)이며 IP 헤더를 압축함으로써 시리얼 링크가 제공하는 비교적 낮은 대역폭을 보다 잘 사용할 수 있게 한다. 또 다른 시리얼 프로토콜은 PPP(Point-to-Point Protocol)이다. PPP에는 link negotiation(링크양도) phase를 비롯하여, SLIP보다 더 많은 특성이 있다. 그러나 그것이 SLIP보다 더 나은 한가지 이유는 그것이 IP 데이터그램만을 전송하는데 그치지 않고 다른 어떤 종류의 데이터그램도 전송하도록 설계된데 있다.
1.3.6 The Transmission Control Protocol
물론 데이터그램을 한 호스트에서 다른 것으로 보내는 것이 이야기의 전부는 아니다. 만약 당신이 quark에 login한다면, erdos의 rlogin 프로세스와 quark의 쉘 프로세스 간에 신뢰성 있는 연결을 수립하길 원할 것이다. 그리하여 오가는 정보는 sender에 의해 패킷으로 나누어지고, reciever에 의해 다시 문자의 흐름으로 재 조합된다. 사소한 것처럼 보이지만, 이것에는 골치아픈 task들이 따른다.
IP에 관해 알아야할 아주 중요한 것은 그것이 의도적으로 신뢰성이 없다는 것이다. 당신 이더넷상의 열명의 사람들이 일제히 GMU의 FTP서버에서 XFree86의 최신판을 전송받는다고 가정해보자. 이것이 초래하는 전송량은 게이트웨이가 다루기엔 너무도 크게 될 것이다. 왜냐하면 너무 느리고, 메모리를 소진하게 될 것이기 때문이다. 지금 만약 quark로 패킷을 보낸다면, sophus는 당분간 버퍼 영역이 사라지고, 그것을 포워딩 시킬수도 없다. 이경우 IP는 단순히 그 패킷을 파기해 버림으로써 이 문제를 해결한다. 이 패킷은 되살릴 수 없이 사라지므로 데이터의 보존성과 완전성을 체크하고 에러발생시 재 전송하는 것은 통신하고있는 호스트의 임무이다.
이러한 일은 다른 프로토콜, 즉 TCP(Transmission Control Protocol)에 의해 수행되며, 이는 IP의 최상층에 위치하여 신뢰성 있는 서비스를 구축한다. TCP의 근본적인 특성은, 그것이 IP를 이용하여 당신의 호스트와 리모트 머신의 두 프로세스 간이 단순히 연결되어 있는 것 같은 환상을 줌으로써 당신의 데이터가 어떻게, 그리고 어떤 경로를 따라 이동하는지 신경쓰지 않토록 한다. TCP 커넥션은 근본적으로 양쪽다 읽고 쓰기가 가능한 두갈래의 파이프처럼 동작한다. 즉, 전화 통화 같다고 생각하면 되겠다.
TCP는 두 호스트의 IP 주소와 각 호스트상의 포트(port)라 불리는 수로써 커넥션의 말단 지점을 인식한다. 포트는 네트웍 연결에서 부착지점처럼 보인다. 전화를 예로써 들자면 지역번호는 IP 주소에, 개인별 번호는 포트에 비유된다.
rlogin에서, 클라이언트 프로그램(rlogin)은 erdos의 포트를 열고 quark의 513번 포트, 즉 rlogind 서버가 listen (특정 포트로 접근하는 클라이언트의 요청을 기다리는 것)하고 있는 곳에 연결한다. 이것이 TCP 커넥션을 수립하고, 이 커넥션을 사용하여 rlogind는 인증절차를 수행하고 쉘을 준다. 쉘의 표준입력과 출력은 TCP 커넥션으로 redirect되므로 당신머신의 rlogin에 쳐 넣은 것들은 TCP 스트림(stream)을 따라 통과하여 그 쉘의 표준 입력으로 전해진다.
1.3.7 The User Datagram Protocol
물론, TCP는 TCP/IP 네트워킹에서, 단지 사용자 프로토콜이지만은 않다. rlogin같은 프로그램에서는 적절할 지라도, NFS와 같은 프로그램에서는 과중한 경비가 든다. 그래서 TCP 대신에 형제(sibling) 프로토콜인 UDP(User Datagram Protocol)을 사용하는데, TCP와 마찬가지로 UDP 역시 원격 호스트의 특정 포트의 서비스에 접속할 수 있도록한다. 그러나 그것은 이를 위해 하나의 커넥션을 성립하는게 아니라, 대신 그 이름처럼 단일 패킷들을 목적 서비스에 보내는 것일 뿐이다.
가령, 학과의 중앙 NFS 서버(galios)의 TEX 디렉토리를 mount했다고 가정하고 LATEX의 사용법을 설명한 문서를 보길 원한다고 생각해 보자. 당신은 초기에 파일의 전부를 읽어내는 편집기를 실행하나, 그것은 galios와 TCP 커넥션을 성립하고, 파일을 보내고, 양도하기엔 너무도 과중하다. 그래서 그 대신에, galios로의 요청이 생기면 그것은 그 파일을 몇개의 UDP 패킷으로 나누어 보내는 데, 이 편이 훨씬 빠르다. 그러나, UDP는 패킷 유실이나 손상에 관해선 고려하지 않으므로 (이경우 NFS처럼) 어플리케이션이 이에 관해 조치하도록 한다.
1.3.8 More on Ports
포트는 네트웍 연결의 부착점 처럼 보인다. 만약 어떤 프로그램이 특정 서비스를 제공하길 원한다면, 그것은 자신을 포트에 부착시켜 놓고 클라이언트를 기다린다(이것을 포트상에서 listening한다고 한다). 이 서비스를 사용하고자 하는 클라이언트는 지역호스트의 포트를 할당하고 원격 호스트의 서비스 포트로 연결한다.
포트의 한가지 중요한 특성은, 연결이 클라이언트와 서버간에 성립되면, 또 다른 서버의 복제가 서버의 포트에 부착하여 더 많은 클라이언트를 기다리게 된다는 것이다. 이것은 가령 513번 포트를 사용하여 한 호스트에 동시에 remote login하는 것을 가능케 한다. TCP는 각각에서의 연결을 처리할 수 있는데, 이것은 그들 모두가 각각 다른 포트 또는 호스트에서 온 것이기 때문이다. 예를 들어, erdos에서 quark로 두개의 login을 한다면 첫번째 rlogin 클라이언트는 로컬 포트 1023을 사용하고 두번째는 1022번 포트를 사용할 것이다. 그러나 둘 모두 quark의 513번 포트에 같이 연결하게 된다.
위 예제는 포트가 랑데뷰 지점처럼 사용됨을 보여주는데, 그 지점에서 클라이언트는 특정 서비스를 얻기위해 특정 포트를 접촉한다. 클라이언트가 적절한 포트를 알기위해선, 양 시스템의 관리자 간에 협약이 수립되어 있어야 한다. rlogin같은 서비스가 광역적으로 쓰이기 위해선 이 숫자는 중앙적으로 관리되어야 한다. 이러한 일은 IETF(Internet Engeneering Task Force)에 의해 이루어 지며, 정기적으로 Assigned Numbers라는 주제의 RFC를 내 놓는다. 그것은 well-known services에 지정된 번호를 기술해 놓았다. 리눅스는 /etc/services라는 파일로 서비스를 수로 매핑해 놓았다. 이에 관해서는 The services and protocol Files 절에서 알아보도록 하자.
TCP와 UDP가 같은 포트에 의존하더라도 이 수는 서로 충돌하지 않는다. 이것은 TCP 포트 513과 UDP포트 513간에 차이가 있다는 말이다. 사실상, 이 포트는 서로다른 두 서비스의 용도로 사용되는데, rlogin(TCP)와 rwho(UDP)가 그것이다.
1.3.9 The Socket Library
UN*X 상에서, 모든 일을 수행하는 소프트웨어와 위에 기술된 프로토콜은 보통 커널의 일부이며 이것은 리눅스의 경우에도 해당된다. UN*X 환경에서 일반적인 프로그래밍 인터페이스는 바로, Berkely Socket Library으로, 그 이름은 포트를 소켓으로 보고, 포트에 연결하는 것을 플러그를 꽃는 것에 비유한 데 유래한다. 그것은 리모트 호스트와 전송 프로토콜, 그리고 프로그램이 (connect(2), listen(2), and accept(2)를 사용하여) 연결할 수 있거나 청취하고 있는 서비스를 특정화 하는데 (bind(2))콜을 제공한다. 소켓 라이브러리는 다소 일반적인 것으로, 그것은 TCP/IP기반 소켓(AF_INET 소켓) 뿐만 아니라, 머신의 로컬 연결을 제어하는 클래스 (AF_UNIX 클래스)도 제공한다. 어떤 것은 XNS(Xerox Networking System)프로토콜이나 X.25같은 다른 클래스도 제어할 수 있다.
리눅스에서 소켓 라이브러리는 표준 libc C 라이브러리이다. 현행상, 그것은 AF_INET과 AF_UNIX 소켓만을 지원한다. 그러나 Novell의 네트워킹 프로토콜을 지원하도록 하자는 운동이 전개되고 있으므로 이들을 위한 하나 또는 그 이상의 소켓클래스가 추가될 것이다.
세계 각지의 프로그래머들의 노력의 결과로, 전 세계적인 네트웍 없이 리눅스는 존재하지 않았을 것이다. 그래서 발전 초기에 몇몇 이들이 네트웍을 통해 그것을 공급하기 시작했다는 것은 별로 놀라운 일이 아니다. UUCP는 거의 시작단계에 리눅스에서 운영되었고, Ross Biro를 포함한 사람들이 Net-1라 알려진 것을 만들었을 때, 즉 1992년 가을 무렵에 시작된 TCP/IP 기반 네트워킹에 착수하게 되었다.
Ross가 1993년 5월에 실질적인 개발을 그만두게 된 후, Fred van Kempen은 새로운 시도, 즉 코드의 대부분을 다시 쓰는 일에 몰두했다. 계속되는 이러한 노력을 Net-2라 하고, 첫번째 릴리즈인 Net-2d는 1992년 여름에 (커널 0.99.10의 일부분으로서) 만들어 졌다. 그리고 이를 Alan Cox같은 몇몇 이들이 유지하고 확장한 것이 Net-2 Debugged이다. 수 차례의 디버깅과 코드의 개선 후, 그는 Linux 1.0이 릴리즈되자 그 이름을 Net-3로 바꾸었다. 이것이 현재 정식 커널 릴리즈에 포함된 네트워킹 코드이다. Net-3는 (시리얼 라인을 통해 네트웍을 사용할 수 있게) SLIP과 (pararell 포트를 위한)PLIP처럼, 다양한 디더넷 보드의 디바이스 드라이버를 광범위하게 제공하는데, Net-3에서, 리눅스는 로컬 네트웍 환경에서 잘 동작하는 TCP/IP implementation과 상용 PC unice에 육박하는 runtime을 지닌다. 현재의 발전방향은 인터넷 호스트로서 운용되기 위한 안정성과 신뢰성이다.
이러한 유용성 외에도, 리눅스를 다채롭게할 몇몇 프로젝트가 진행중이다. PPP(Point-to-Point Protocol의 약자로, 시리얼 라인을 통해 네트웍을 연결시키기 위한 또다른 수단)는 현재 Beta stage이고, ham radio용 AX.25는 Alpha stage이다. Alan Cox는 Novell의 IPX 프로토콜을 위한 드라이버를 만들었으나 Novell의 것과 완벽히 호환하는 것은 조금더 기다려야 할 것 같다. 그 이유는 Novell에서 필요한 문서를 제공하길 원치 않기 때문이다. 현재 착수 계획중인 것은 samba와, Andrew Tridgell이 만든 Unice를 위한 무료 NetBIOS 서버이다.
1.4.1 Different Streaks of Delvellopment
그 동안에도, Fred느 Net-2e의 개발을 계속했는데, 이것은 기존의 네트웍 layer 디자인을 대폭 수정한 것이다. 이 원고를 적을 당시 Net-2e는 아직 Beta 소프트웨어였다. Net-2e에 관해서 주목할 만한 것은 DDI(Device Driver Interface)의 포함이다. DDI는 모든 네트워킹과 프로토콜에 공통된 형태의 접근과 설정 메쏘드를 제공한다.
또 하나의 TCP/IP 네트워킹의 implementation은 Matthias Urlichs, 즉 Linux와 FreeBSD용 ISDN 드라이버를 만든이에 의해서였다. 이를 위해 그는 리눅스 커널 내의 BSD 네트워킹 코드를 집대성 했다.
그러나 아마도 Net-3가 나올 것이다. Alan은 현재 ham 무선기사가 사용하는 AX.25개발에 여념이 없다. 의심할 여지 없이, 아직 개발중인 커널의 "module" 코드(개발이 끝나고 현재 사용중에 있다 - 역자주)는 네트워킹 코드에 새로운 자극을 줄 것이다. 모듈은 run time에 커널에 드라이버를 추가 할 수 있게 할 것이다.
이들 서로다른 네트워킹 implementation이 모두 동일한 서비스를 제공하기 위해서 시도되었음에도, 커널과 디바이스 차원에선 각기 다르다. 그러니까, Net-2d나 Net-3에서 쓰이는 유틸리티로 Net-2e커널을 설정할 수 없다는 것이다. 이것은 단지 커널과 관계하는 커맨드가 보다 내부적으로 적용된다는 것으로, 어플리케이션이나 네트워킹 커맨드, 이를테면 rlogin이나 telnet같은 것들은 이들 중 하나에서만 실행된다는 것이다.
그렇지만, 이들 서로다른 네트웍 버전에 걱정하지 않아도 된다. 당신이 실제적인 개발에 참여치 않는 한, 어떤 TCP/IP 버전을 당신이 사용중인지 염려치 않아도 된다. 정식 커널은 항상 커널 내의 네트워킹 코드와 호환되는 네트워킹 툴과 함께 릴리즈 된다.
1.4.2 Where to Get the Code
Linux 네트웍 코드의 최신 버전은 다양한 익명 FTP에서 얻을 수 있으나, Net-3의 정식 FTP 사이트는 sunacm.swan.ac.uk이고, sunsite.unc.edu가 system/Network/sunacm에 미러링 하고 있다. Net-2e 패치 킷과 바이너리는 ftp.aris.com에서 전송 가능하다. Matthias Urlichs의 BSD유래 네트워킹 코드는 ftp.ira.uka.de의 /pub/system/linux/netbsd 밑에 있다.
nic.funet.fi의 /pub/OS/linux/PEOPLE/Linux내에서 커널의 마지막 버전을 배포하고, sunsite와 tsx-11.mit.edu가 이 디렉토리를 미러링하고 있다.
이 책을 통해 우리는 설치와 설정에 관해 주로 다룰 것이다. 그러나 관리는 그 이상의 것을 요한다 - 서비스를 세팅한 후, 계속 실행 되도록 유지해야 한다. 서비스 중 mail과 news같은 것들은 약간씩만 돌보면 되나, 어떤 것은 시스템을 최신의 것으로 유지해야 하는 임무를 수행해야 한다. 이에 관해서는 차후에 살펴보자.
확실한 최소의 유지방안은 시스템과 어플리케이션 로그 파일을 에러상태와 비정상적인 이벤트에 관해 체크하는 것이다. 보통, 이러한 일을 몇개의 쉘 스크립트를 작성하고, cron에서 정기적으로 이를 실행하길 원할 것이다. 어떤 주요 어플리케이션의 소스 배포판, 이를 테면 smail이나 C News같은 것은 이러한 스크립트를 내포하는데, 이를 당신의 요구와 기호에 따라 짜집기 하면 된다.
어떤 cron job의 산출물은 mail로써 관리자 계정에 전해지는데, 기본적으로 많은 어플리케이션들이 에러 보고, 사용 통계, 또는 로그파일의 요약을 root계정으로 보낼 것이다. 이는 당신이 root계정으로 종종 로그인 해야만 알 수 있는 것으로, 더 나은 방법은 mail alias를 지정함으로써 root의 mail을 당신의 개인 계정으로 포워드 시키는 것이다. 이에 관해선 14장에서 보고자 한다.
조심스럽게 당신의, 사이트를 설정해 놓았더라도, 머피의 법칙은 때때로 어떤 문제점을 `아마도' 안겨줄 것이다. 게다가 시스템의 운영은 시스템의 불평을 들어야함을 의미한다. 보통, 사람들은 시스템 관리자는 적어도 root계정으로 mail을 받을 수 있을 것이라 기대하나, 통상적으로 사람들을 접촉하는 또 다른 mail 주소가 특정한 관리 측면에 책임을 진다. 예를 들자면, mail 설정의 오동작에 대한 불평은 postmaster로 가게 되고, news 시스템에 대한 문제점은 newsmaster나 usenet으로 보고될 것이다. hostmaster로의 mail은 호스트의 기본적인 네트웍 서비스와, 네임서버를 운영 중이라면, DNS 네임 서비스를 맡고 있는 사람에게 redirect 될 것이다.
1.5.1 System Security
네트웍 환경에서의 또 다른 시스템 관리의 주요 측면은 당신의 시스템과 사용자를 침입자로 부터 보하나는 것이다. 부주의하게 운영되는 시스템은 짖궂은 사람들의 타겟이 된다. 즉, 패스워드 유추에서 부터 이더넷 스투핑(snooping)까지의 공격 범위와, 날조된 mail 메시지에서 데이터 손실 또는 사용자의 프라이버시 침해까지도 초래할 수 있다. 우리는 그것이 일어나는데 대해 논하는 특정 문제점과, 그것을 방어하는 일반적인 방법을 언급하고자 한다.
이 절에서 시스템 보안에 관계된 몇몇 예제와 기본적인 기술을 얘기하고자 한다. 물론 다루어진 주제가 당신이 쉴새 없이 직면할 수도 있는 모든 보안 문제를 취급할 수는 없다. 단지, 발생할 수 있는 문제점을 단순히 서술할 뿐이다. 그래서 보안에 관한 좋은 책을 읽는 것은, 특히 네트웍화된 시스템에서는, 절대적인 것이다. Simon Garfinkel의 "Practical UNIX Security"([Spaf93]을 보라)를 읽을 필요가 있다.
시스템 보안의 시초는 양호한 시스템 관리이다. 이것은 치명적일 수도 있는 파일과 디렉토리의 소유권과 퍼미션을 점검하는 것과, 특권을 가지는 계정의 사용을 관찰하는 것 등등이다. 예를 들어, COPS 프로그램은 당신의 파일 시스템과 통상적인 설정 파일에 이상한 권한 부여 또는 그 외의 이상유무를 점검한다. 그리고, 유추하기 어려운 패스워드를 사용자가 쓰도록 강제하는 특정 법칙을 가지는 패스워드 프로그램을 사용하는 것도 현명한 것이다. 가령 shadow password 프로그램은 적어도 5자가 넘고 대문자와 소문자, 그리고 숫자가 포함된 것만을 패스워드로 요구한다.
네트웍에 접근 가능한 서비스를 만들 때, 그것에 "최소 권한"을 주었는지 확인해야 하는데, 이는 설정된 이외의 일을 하기위한 권한을 주지 않음을 의미하며, 예로써 당신은 정말로 필요할 때만 root 또는 다른 특별권한을 지니는 계정을 만들 것이다. 그러나 아주 제한된 어플리케션으로 서비스를 사용하길 원한다면, 당신의 특수한 어플리케이션이 허용하는 만큼 최상으로 설정하기를 주저해서는 안된다. 실례로써, 디스크 없는 호스트를 당신의 머신에서 부팅할 수 있게 하고자 하는 것을 들 수 있는데, 그것들이 /boot 디렉토리에서 기본적인 설정 파일을 다운로드 할 수 있도록 TFTP(trivial file transfer service)를 제공해야 한다. 그러나 제한없이 사용된다면 TFTP는 세계 어디서나 어느 사람이건 파일시스템내의 world-readable 파일을 다운로드 할 수 있게 하므로 이러한 일을 원치 않는다면, TFTP 서비스를 /boot 디렉토리에 제한하라.
이와 비슷한 생각으로, 당신은 특정 서비스를 단지 특정 호스트들, 이를테면 당신의 네트웍 내의 것들의 사용자에 한해 제한하기를 원할 수도 있다. Chapter 8에서 우리는 다양한 네트웍 어플리케이션을 위해 이러한 일을 하는 tcpd를 소개할 것이다.
또 다른 중요한 점은 "위험한" 소프트웨어를 피하는 것이다. 물론 당신이 사용하는 소프트웨어는 위험할 수 있다. 이유는 소프트웨어가 버그를 지니고 있고, 똑똑한 사람들이 당신의 시스템에 접근하기 위해 그것을 이용할 수도 있기 때문이다. 이러한 일이 일어나는 데엔 완벽한 보호방법이 없다. 이런 문제점은 공개 소프트웨어건 상용 제작품이건 똑같이 영향을 끼친다. 그러나 특정 권한을 필요로 하는 프로그램은 대대로 다른 것보다 위험하다. 왜냐하면, 약간의 구멍마저도 치명적인 결과를 초래할 수 있기 때문이다. 만약, 네트웍을 목적으로한 setuid 프로그램을 설치하고자 한다면 문서에서 빠뜨린 것이 없는지 두배로 주의해야 한다. 그리한다면 우연히 보안의 틈을 만드는 것을 막을 수 있다.
당신이 얼마나 조심스러웠는지는 고려하지 않고, 당신의 사전 주의가 실패할 경우를 배제하지 않는다면 불청객을 미연에 방지한다고 확신할 수 있을 것이다. 시스템의 로그파일을 체크하는 것은 좋은 출발점이나, 불청객이 아마도 영리하기에 그/그녀가 떠날 때 명백한 증거물을 지울 것이다. 그러나, tripwire같은 툴은 주요한 시스템 파일의 내용이나 퍼미션이 바뀌었는지 체크한다. tripwire는 이러한 파일에 다양한 checksum을 산출하고 그것을 데이터베이스로 저장한다. 이후의 실행시엔, checksum을 재 산출하여 저장된 것과 비교하고 수정이 가해졌는지 찾아내게 된다.
1.6 Outlook on the Following Chapters
다음의 몇장에서는 Linux를 TCP/IP 네트워킹에 맞도록 설정하는 것과, 몇개의 주요 어플리케이션을 돌리는 것에 관해 다룰 것이다. 파일을 편집한다는 식으로 손을 더럽히기에 앞서, IP에 관해 2장에서 보다 자세히 고찰하겠다. 만약 당신이 IP 라우팅의 동작방식과, 어떻게 주소분석(address resolution)이 이루어 지는 지에 관해 이미 알고 있다면 이 장은 건너 뛰어도 된다.
3장은 아주 기초적인 설정에 관해 다루고 있다. 즉, 커널을 생성하고 이더넷 보드를 세팅하는 것 같은 것들이다. 시리얼 포트를 설정하는 것은 별도의 장에서 다룬다. 그 이유는 그것이 단지 TCP/IP 네트워킹에만 적용되는 것이 아니라, UUCP와도 관련이 있기 때문이다.
5장은 당신의 머신을 TCP/IP 네트워킹을 사용할 수 있도록 세팅하는 것을 도와준다. 여기엔 loopback만이 가능한 standalone호스트와 이더넷에 연결된 호스트를 설치하는 데 대한 힌트가 실려 있다. 그리고 또, 당신의 세팅을 테스트하고 디버그할 수 있는 유용한 툴도 소개한다. 그 다음 장에선 hostname resolution을 어떻게 설정하는 지, 그리고 home server를 셋업하는 방법에 관해 논의한다.
다음의 두 장은 SLIP과 PPP의 설정과 사용에 관해 설명한다. 7장에선, 어떻게 SLIP 연결을 성립하는 지에 관해 설명하고, dip(필요한 절차를 자동화 시킬 수 있는 도구)에 관해 자세히 논한다. 8장에선 PPP와 pppd(PPP에 필요한 PPP daemon)을 다룬다.
9장에서는 주요 네트웍 어플리케이션 중 몇몇, 이를테면 rlogin,rcp등과 같은 것들,을 셋업하는데 대해 짧게나마 소개한다. 여기선 어떻게 서비스들이 inetd 감독하에 운영되는 지, 그리고 어떻게 특정한 보안관련 서비스를 신용되는(trusted) 호스트에 제한하는지도 설명한다.
다음의 두 장은 NIS(Network Information System)과 NFS(Network File System)에 관해 논한다. NIS는 사용자 패스워드 같은 관리 정보를 로컬 네트웍 상에 뿌려 주는 유용한 툴이다. NFS는 네트웍 상의 몇몇 호스트 간에 파일 시스템을 공유할 수 있도록 한다.
12장은 Tayler UUCP,즉 UUCP suite의 공개 implementation의 관리에 대해 보다 폭 넓은 소개를 한다.
이 책의 나머지 부분은 e-mail과 Usenet News에 관한 자세한 관찰로 채워져 있다. 13장에선 e-mail에 관한 핵심적인 개념에 관해 소개하고, 어떻게 mail handling system이 당신의 메시지를 수취인에게 보내도록 관리하는 지에관해 설명한다.
14장과 15장은 리눅스에서 사용할 수 있는 2개의 MTA(Mail Transfort Agent)인 smail과 sendmail의 셋업에 관해 각각 다룬다. 이 책에선 두 가지 모두를 설명하는 데, 이유는 smail이 초보자에겐 설치하기 더 쉽고, sendmail은 보다 유연성 있기 때문이다.
16장과 17장은 news가 Usenet에서 어떻게 관리되는지 설명하고 Usenet news를 관리하는 대중적인 소프트웨어 패키지인 C news의 설치와 사용방법을 소개한다. 18장에선 간략하게나마, news reading access를 제공할 수 있도록, 어떻게 NNTP daemon을 당신의 로컬 네트웍에 셋업하는 지에 관해 논한다. 19장은 어떻게 다양한 news reader를 설정하고 관리,유지 하는 지를 보여준다.
1. Introduction to Networking
2. Issues of TCP/IP Networking
3. Configuring the Networking Hardware
4. Setting up the Serial Hardware
5. Configuring TCP/IP Networking
6. Name Service and Resolver Configuration
7. Serial Line IP
8. The Point-to-Point Protocol
9. Various Network Applications
10. The Network Information System
11. The Network File System
12. Managing Taylor UUCP
13. Electronic Mail
14. Getting smail Up and Running
15. Sendmail+IDA
16. Netnews
17. C News
18. A Description of NNTP
19. Newsreader Configuration
A. A Null Printer Cable for PLIP
B. Sample smail Configuration Files
C. The GNU General Public License