| ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
D.M.Z
CONTENT
PRE
NEXT
18.1 Introduction 서로 다른 네트웍 전송 수단이 사용되기에, NNTP는 뉴스 교환에 있어 C News와는 전혀 다른 접근 방식을 사용한다. NNTP는 "Network News Trasfer Protocol"의 약어로, 특정 소프트웨어 패키지가 아닌 인터넷 표준을 가리키는 말이다. 그것은 네트웍 내 어딘가에 있는 클라이언트와, netnews를 디스크 저장매체에 보존하는 호스트에 떠있는 서버간의 stream 지향 커넥션 (보통 TCP 상에서)에 기반한다. stream 커넥션은 클라이언트와 서버가 아티클을 전송하는데, 전향(turnaround) 딜레이가 거의 없도록 하고, 아티클 중첩의 수를 낮게 유지할 수 있게 한다. 인터넷의 높은 전송률에 힘입어, 이것은 오리지널 UUCP 네트웍을 훨씬 능가하는 뉴스 전송을 가능케 한다. 몇년 전엔 아티클이 포스팅되어 Usenet의 마지막 코너에 도착하기 까지 2주이상이 걸리던 것이 비정상적인 것이 아니었으나, 이제 이것은 이틀도 걸리지 않게 되었다. 인터넷 자체에선, 그것은 심지어 몇분의 범위내에 일어난다. 클라이언트가 아티클을 찾아오고(retrive), 보내고(send), 포스팅(post)하게 하는 몇가지의 커맨드가 존재한다. 보내는 것과 포스팅간의 차이는 후자가 완전치 않은 헤더 정보를 지닌 아티클을 가지고 있다는 점이다. 아티클 retriving은 뉴스전송 클라이언트와 newsreader에서 사용된다. 이것은 NNTP를, NFS를 사용할 때 필요한 어떤 류의 속임수 없이 로컬 네트웍 상의 많은 클라이언트들에게 뉴스 억세스를 제공하는 굉장한 툴로 만든다. NNTP는 active하고 passive한 뉴스 전송 방법, "pushing"과 "pulling"이라 불리는 것도 지원한다. Pushing은 기분적으로 C News의 ihave/sendme 프로토콜과 동일하다. 클라이언트는 "IHAVE<varmsgid>" 커맨드를 통해 서터에게 하나의 아티클을 주고, 서버는 그 아티클을 이미 갖고 있는지 또는 그것을 원하는지를 지시하는 response 코드를 리턴한다. 만약 그럴경우, 클라이언트는 아티클을 보내고, 뒤 라인 첫번째에 점을 찍어 마지막을 표시한다. 뉴스를 pushing 하는덴 단 한가지 결점이 있는데, 그것은 서버 시스템에 심각한 로드를 일으킨다는 것으로, 그 이유는 그것이 각 싱글 아티클에 대해 그것의 history 데이터 베이스를 설치해야 한다는 것이다. 반대의 테크닉은 pulling으로, 클라이언트가 일정 날짜 이후에 도착한 아티클의 리스트를 그룹에 요청하는 것이다. NETNEWS 커맨드에 의해 그 쿼리가 수행된다. 리턴된 메시지 id의 리스트에서, 클라이언트는 그들 각각에 대해 차례로 ARTICLE 커맨드를 사용하여, 아직 갖지 못한 아티클을 골라낸다. 뉴스를 pulling하는데 따르는 문제점은, 클라이언트가 요청하도록 허락하는 group과 distribution에대해 서버가 면밀하게 컨트롤해야 해야한다는 점이다. 예를 들어, news pulling은 로컬 뉴스 그룹에서의 어떠한 비밀스런 것들을 절대 인증 받지 못한 호스트에 보내지 않는다는 확신이 필요하다. newsreader가 아티클의 header와 body를 별개로, 심지어는 헤더라인의 한 라인만을 받아 올수 있게 하는 몇가지 편리한 커맨드들로 있다. 이것은 모든 뉴스를 중앙 호스트에 보존하고, (로컬로 추정되는) 네트웍 상의 모든 유저들은 NNTP 기반 클라이언트 프로그램을 사용하여 읽고 포스팅하게 한다. 이것은 17장에서 논한 바 있는, NFS로 뉴스 디렉토리를 exporting하는 방법에대한 하나의 대안이다. NNTP의 전반적인 문제점은, 그것이 보낸이의 이름을 바꿔치기하여 뉴스 stream내로 아티클을 집어 넣을 수 있게 한다는 것이다. 이를 일컬어 news faking이라 한다. 확장된(extended) NNTP는 특정 커맨드에 대해 유저인증을 필요로 한다. 사용가능한 여러가지 NNTP 패키지가 존재하는데, 이 중 가장 잘 알려진 하나는 NNTP 데몬으로, reference implementation이라고도 알려져 있다. 원래 그것은 RFC977의 디테일을 예증하기위해 Stan Barber와 Pill Lapsley에 의해 만들어진 것으로, 가장 최신 버전은 nntpd-1.5.11이며, 이는 아래에서 설명한다. 소스를 가져와서 컴파일하든가, Fred van Kempen의 net-std 바이너리 패키지내의 nntpd를 사용하면 된다. 여러가지 사이트-특정 값이 컴파일되어 들어가야하기 때문에, ready-to-go(즉시 사용할 수 있는) nntpd 바이너리는 제공되지 않는다. nntpd 패키지는 inews의 대체하는 하나의 서버와, 뉴스 pulling과 pushing에 대한 두개의 클라이언트로 각각 이루어져 있다. 그것들은 약간의 변형을 가한다면 Bnews 환경에서 사용할 수 있고, C news에서 역시 잘 돌아간다. 그러나 만약 당신의 뉴스서버로 newsreader 억세스를 제공하는 것 이상을 위해 NNTP를 사용할 계획이라면, reference implementation은 더이상 선택적인 것이 아니다. 그러므로 우리는 클라이언트 프로그램은 생략하고, nntpd 패키지 내에 포함된 NNTP 데몬만을 논할 것이다. Rich Salz가 쓴 "InterNet News", 짧게는 INN이라 불리는 패키지도 존재한다. 그것은 NNTP와 UUCP기반 뉴스 전송을 모두 제공하고, 큰 규모의 뉴스 hub에 더 적합하다. NNTP의 용도로 사용할 때, 그것은 nntpd보다 절대적으로 뛰어나다. INN은 현재 버전 inn-1.4sec이다. 리눅스 머신에서 INN을 building하는 kit이 있으며, sunsite.unc.edu의 system/news 디렉토리에서 구할 수 있다. INN을 셋업하고자 한다면, 소스에 딸린 문서와, news.software.b에 정기적으로 포스팅되는 INN FAQ를 참조하라.
NNTP 서버는 nntpd라 부르고, 뉴스 시스템에 예상되는 부하량에 따라 두가지 방법으로 컴파일 될 수 있다. 몇가지 사이트-특정 디폴트 값이 실행 파일 내에 hard-code되어야 하기 때문에, 컴파일된 버전은 존재하지 않는다. 모든 설정은 common/conf.h내에 정의된 매크로를 통해 이루어진다. nntpd는 시스템 부팅시에 rc.inet2에서 구동되는 standalone 서버로, 또는 indetd가 관리하는 데몬으로 설정될 수 있다. 후자의 경우, /etc/inet.conf내에 다음의 엔트리가 들어있어야 한다.
nntp stream tcp nowait news /usr/etc/in.nntpd nntpd
만약 nntpd를 standalone 서버로 설정하였다면, inetd.conf내에 위의 라인이 주석처리 되었는지 확인해야 한다. 그 반대의 경우, /etc/services 내에 다음의 라인이 있는지를 확인해야 한다.
nntp 119/tcp readnews untp # Network News Trasfer Protocol
incoming아티클 등을 임시로 저장하기 위해, nntpd는 뉴스 스풀 내에 .tmp 디렉토리를 필요로 한다. 다음과 같이 만들어 주면된다.
# mkdir /usr/spool/news/.tmp
# chown news.news /var/spool/news//.tmp
NNTP 리소스로의 억세스는 /usr/lib/news 내의 nntp-access 파일에서 주관된다. 그 파일내의 라인들은 외부 호스트에 부여된 억세스 권한에 대해 적고 있다. 각 라인은 다음의 포맷으로 이루어진다.
만약 어떤 클라이언트가 NNTP 포트로 연결한다면, nntpd는 reverse lookup을 통해 그 호스트의 IP 주소에서 FQDN을 얻어뇨려 한다. 클라이언트의 호스트네임과 IP 주소는 그 파일내 각 엔트리의 site 필드에 대해 체크된다. 일치하는 부분은 부분적 또는 전반적인 것일 수 있다. 만약 엔트리가 정확히 일치한다면, 그것이 적용된다. 만약 그것이 부분적이라면, 뒤에 더 일치하는 엔트리가 없을 경우에만 적용된다. site는 다음의 방법중 하나로 지정될 수 있다.
일반적인 것을 먼저 지정하여야 한다. 왜냐하면 보다 정확하게 일치하는 쪽이 일반적인 것을 오버라이드 하기 때문이다. 두번째와 세번째 필드는 클라이언트에 부여된 억세스 권한을 설명하고 있다. 두번째는 pulling(read)에의해 뉴스를 가져오는데 대한, 그리고 pushing(xfer)에의해 뉴스를 전송하는데 대한 권한을 열거한다. both값은 둘 모두를 가능케하고, no는 억세스를 모두 거부한다. 세턴째 필드는 클라이언트에게 아티클을 포스팅하는, 즉 (뉴스 소프트웨어에의해 완성되는) 불완전한 헤더 정보를 가진 아티클을 배달하는데 대한 권한을 부여한다. 만약 세번째 필드가 no를 지닌다면, 그 세번째 필드는 무시된다. 네번째 필드는 선택적인 것으로, 클라이언트의 억세스가 거부되는 그룹들의 comma-seperated 목록을 가지고 있다. 아래는 nntp-access 파일 예제이다.
#
# by default, anyone may transfer news, but not read or post
default xfer no
#
# public.vbrew.com offers public access via modem, we allow
# them to read and post to any but the local.* groups
public.vbrew.com read post !local
#
# all other hosts at the brewery may read and post
*.vbrew.com read post
nntp-access 파일 내의 xfer나 read같은 억세스 표시를 대문자로 쓸 때, nntpd는 개별 작업을 할 때마다 클라이언트에서의 인증을 필요로한다. 예를 들어, Xfer 또는 XFER의 퍼미션을 지정할 때, 클라이언트가 인증과정을 통과하지 못한다면 nntpd는 클라이언트가 당신 사이트로 아티클을 전송하지 못하게 한다. 인증 프로시저는 AUTHINFO라는 새로운 NNTP 커맨드에의해 수행된다. 이 커맨드를 사용함으로써, 클라이언트는 유저네임과 패스워드를 NNTP 서버에게 전송한다. nntpd는 그것들을 /etc/passwd 데이터베이스를 체크함으로써 확인하고, 유저가 nntp 그룹에 속해있음을 입증한다. NNTP 인증의 현재 implementation은 단지 시험적인 것으로, 포팅이 용이하게 되어있지 않다. 따라서 그것은 일반적인 패스워드 데이터베이스에서나 동작한다. shadow 패스워드는 인식되지 않을 것이다.
18.5 nntpd Interaction with C News 아티클을 수신할 때, nntpd는 그것을 뉴스 서브 시스템(subsystem)에 전달해야 한다. 그 아티클이 IHAVE로 수신되었는지, 혹슨 POST 커맨드의 결과로 수신되었는지에 따라, 그 아티클은 각각 rnews 또는 inews로 넘겨진다. rnews를 호출하는 대신, incoming 아티클들을 batching하여 생긴 batch들을 /var/spool/news/in.coming에 옮겨, 다음번 queue 실행시에 relaynews가 그것들을 pick up가게끔 하는 방법으로 (컴파일 시에) 설정할 수도 있다. ihave/sendme 프로토콜을 이상없이 수행하려면, nntpd가 history 파일에 억세스 할 수 있어야 한다. 따라서, 컴파일 시에 path가 올바르게 설정되었는지 확인해 주어야 한다. 또한, C news와 nntpd가 당신의 history 파일 포맷을 인식하는 지도 확인해 주어야 한다. C news는 그 파일에 억세스 할때 dbm 해싱 함수를 사용한다. 그러나, 약간의 차이가 있어 서로 호환되지 않는 dbm 라이브러리 implementation이 존재하기 때문에, 만약 C News가 당신의 표준 libc가 아닌 다른 dbm 라이브러리에 링크되어 있다면, nntpd 또한 그 라이브러리에 링크해 주어야 한다. nntpd와 C News가 데이터베이스 포맷을 인식하지 못할 경우의 보편적인 증상은, 시스템 로그내에, nntpd가 그 파일을 여는데 이상이 있다는가, NNTP로 중복된 아티클이 수신되었다는 에러메시지이다. 이를 테스트하는 좋은 방법은, 당신의 스풀 디렉토리에서 아티클을 하나 집어, nntp 포트로 telnet한 뒤, 아래의 예제처럼 (당신의 입력은 이와 같이 표시된다) nntpd에게 주는 것이다. 물론, <msg@id>는 당신이 nntpd에게 feed하고자하는 아티클의 메시지 ID로 대체해 주어야 한다.
$ telnet localhost nntp
Trying 127.0.0.1...
Connected to localhost
Escape characters is '^]'.
210 vstout NNTP[auth] server version 1.5.11t (16 November 1991) ready at
Sun Feb 6 16:02:32 1194 (no posting)
IHAVE <msg@id>
435 Got it.
QUIT
위의 경우는 nntpd가 이상없이 반응함을 보여준다. "Got it" 메시지는 이 아티클을 이미 가지고 있음을 나타낸다. 만약 그대신 "355 OK" 메시지를 표시한다면, history 파일의 검색이 어떠한 이유로 실패한 것이다. Ctrl+D를 눌러 conversation을 종료하고, 시스템 로그를 체크함으로써 무엇이 잘못된 것인지를 체크할 수 있다. nntpd는 모든 종류의 메시지를 syslog 데몬에 보낸다. 호환되지 않는 dbm 라이브러리가 이유라면, 보통 메시지에 dbminit이 실패했다고 명시된다.
|
Other Chapters |
1. Introduction to Networking
Appendix |
A. A Null Printer Cable for PLIP |