|
1. Xinetd은 무엇인가?
리눅스 6.2까지는 네트웍 커넥션을 처리하기 위해서 inetd를 사용하였습니다.
그러나 레드헷 리눅스 7.0부터는 inetd를 사용하지 않고 Xinetd를 사용합니다.
전통적인 inetd는 포트로 연결요청이 들어오면 이를 tcpd에게 보냈고, 다시
tcpd는 host.allow와 host.deny에 포함되어 있는 rules에 따라 그 요청을 허
락할 것인지 결정합니다. 만약 요청이 허락되면 tcpd는 요청에 적합한 서버
프로그램을 실행시킵니다. 이러한 매커니즘을 tcp_wrapper라고 합니다.
Xinetd는 tcp_wrapper와 비슷한 접근 통제 방법을 제공합니다. 그러나 일부
RPC 서비스의 콘트롤에는 문제가 있습니다. 그렇지만 xinetd는 portmap과도
잘 맞습니다.
* standalone 방식
용자가 웹서비스를 바로 요구할 때 바로 서비스를 제공할 수 있는 방법입니다.
즉 이용자가 서비스를 원하든 원하지 않든 웹데몬의 프로세스가 항상 백그라운드로
돌고 있으므로 웹서비스가 들어오면 바로 서비스를 제공하게 되는 것입니다.
* 슈퍼 데몬 방식 (xinetd)
xinetd라는 슈퍼데몬이 백그라운드를 돌고 있다가 이용자가 웹서비스를 요구하면
슈퍼데몬이 관리하는 파일에서 웹데몬이 등록되어 있는지 확인하고 웹데몬이
슈퍼데몬의 관리파일에 존재하면 서비스가 제공됩니다. 그러므로 standalone에 비해
속도가 느립니다.
일반적으로 자관의 서버가 단순히 웹서버의 목적이라면 standalone방식으로
처리하지만, 자관의 서버가 웹서버 뿐만 아니라 다양한 서버의 역할을 한다면
슈퍼데몬 방식으로 설정할 수 있습니다. 각 서비스 데몬을 어떤 서비스타입으로 설정할
것인지는 관리자가 결정하는 문제가 됩니다.
xinetd 는 일종의 슈퍼 데몬입니다.
/etc/xinetd.d/ 디렉토리에 들어가시면
각각의 서비스들이 있는데 그것들을 관리하는 데몬이지요.
예를 들어 telnet을 서비스하고 싶다면..
/etc/xinetd.d/telnet 을 열어 수정을 한 후
telnet 을 restart하는 것이 아니라
슈퍼 데몬인 xinetd 를 재시작해주는 것으로 telnet 서비스를 정지 | 시작 하는 것이지요.
그 안에 있는 서비스를 사용하지 않는다면 궂이 재시작할 필요는 없습니다.
XINETD는 INETD의 확장형... 즉, 기능 향상판입니다.
어떤 분이 말씀 하신 바와 같이 XINETD나 INETD는... 슈퍼 데몬입니다. 각종 서비스들을 관리 합니다. 그러나, 접속과 접속시 네트워크 접근에 대한 부분을 관리 할 뿐, 서비스의 종료와는 관련이 없습니다!!!
그런 이유로 TELNET 서비스에 접속한 사용자가 잇다고 할 때 XINETD를 제시작 시켜도 일단 연결된 것은 죽지 않습니다. 그래서 아무 문제 없이 돌아 간다는 소리죠. 근대 왜 제시작 하느냐... 서버 셋팅 중에...
아무리 IMAP나 TELNET, POP3 같은 프로토콜을 사용하는 프로그램들이 가동이 되고 싶어도 이것들이 XINETD 하에 있다면 실행이 되느냐 마느냐는 XINETD의 제어 하에 있습니다. 예제 파일을 깔아 놓고 설명을 드리겠습니다.
-- telnet --
service telnet {
server = /usr/sbin/in.telnetd
user = root
wait = no
disable = no
...
...
...
}
-- END OF telnet --
대충 이렇다고 하죠... 저기서 disable 라는 지시어는 이 서비스를 작동 불능 상태로 만들 거냐 아니냐를 설정 하는 겁니다. 지금 no로 되어 있죠... 만약 저게 원래는 yes 라고 가정 한다면 TELNET 접속이 가능할까요? 아닙니다. 접속 안 되죠. XINETD가 yes 인 상태에서 로딩 되었고 시작 될 때 yes로 저장된 파일을 읽었습니다.(설정 파일입니다.) 그렇다면 TELNET 서비스에 대해선 접속을 거부 합니다. 지금은 이제 접속 가능하게 하려고 no로 바꾼 거죠.
어떤 분이 말씀 하셨듯 시스템 서비스 시작 방식은 크게 두 가지 정도로 나눕니다. standalone와 inet기반 입니다. standalone 방식은 시스템 서비스 프로세스 자체가 접속을 관리하며 접속 종료 또한 당연히 관리 합니다. 이 경우 각자의 설정 파일에 따라 동작 합니다. 보안 처리 부분도 마찬가지입니다. 프로세스 자체가 떠서 계속 포트를 감시 하고 있다가 접속이 들어 오면 그것에 따라서 프로세스 포크를 시키던 스래드를 늘리던 하겠죠. 그리고 일을 할 거고요...반면 inet 방식은 inetd나 xinetd 데몬이 포트를 감시 하고 있고 서비스 자체를 행하는 프로세스는 죽어 있습니다. 아니, 실제 접속을 해서 사용하고 있는 실제 프로세스만 동작을 하고 있고 접속을 기다리는 프로세스가 따로 없지요. 대신 inetd나 xinetd가 포트를 감시 하고 있으니까 감시 임무를 그것에 위임 하고 있는 겁니다. 접속 시도가 이루어 지면 각종 정첵을 검토하고 나서 xinetd나 inetd는 해당 서비스 프로세스를 호출 해서 실행 하고 소켓과 연결 시켜 줍니다. 그럼 프로세스가 실행 되면서 소켓과 물리는 거죠. 근대 위의 파일에서 no 부분이 yes라면 아무리 포트로 접속이 들어 온다고 해도 telnet를 부르지 말라는 소리니까 결국 접속이 안 되는 겁니다. no로 고쳤는데 메모리엔 설정이 다시 안 불러 졌으니까 당연히 제시작을 해야 새로 작성된 내용이 메모리로 불러 들여 지고 거기에 따라서 XINETD나 INETD가 동작을 하게 되는 거죠... 다른 서비스 데몬도 다 같은 거니까 이해 하실 겁니다. Apache 같은 경우를 다뤄 보셨다면 이해 하실 겁니다.
XINET나 INETD의 영향을 받도록 컴파일 된 데본은 보통 이런 것들이 있습니다 아래...
TELNET, IMAP, POP3, POP3(SSL), IMAP(SSL), ECHO, CHARGEN, TIME SERVICE ... ... ...
뭐 대강 그렇습니다. 경우에 따라선 SMTP도 여기 끼워 주는 경우도 있죠 후훗... 그럼 도움 되셨으면 좋겠네요... |
