리눅서는 어떻게 크는가?

1998-99년 사이에 마이크로소프트웨어 잡지에 기고한 "기업 환경을 위한 리눅스 블랙박스 만들기, 윈도우와 리눅스의 공존"에 삽입된 글입니다. 세월이 지나서일까요? 현재는 쓸모 없는 구식 방식에 대해서 설명한 부분도 있군요. 그러나 배움에 대한 내용은 크게 다르지 않기 때문에 따로 뽑아서 게시합니다. 리눅서는 어떻게 크는가?    - 리눅스를 쓰고자 마음 먹은 초보 리눅스에게 주는 조언 업체에서, 학교에서 리눅스를 사용하기로 결정한 초보 리눅스가 어떤 자세를 가져야 하는지 생각해 보기로 하자. 어떻게 하면 리눅스를 자유자재로 사용할 수 있을까? 리눅서가 가져야 할 무기는 어떤 것인가? 이런 질문에 대한 대답을 해보기로 하자. 이 글이 이제 막 리눅서로서의 첫 걸음을 시작하려는 독자들에게 도움이 되기를 바란다. 무슨 일이든 기본이 있고 원칙이 있다. 이 것을 지킨다면 빨리 그 분야에 적응할 수 있다. 리눅서가 되기 위한 원칙은 어떤 것이 있는가? 오늘도 통신과 유저넷에는 질문들이 쏟아지고 있다. 그 질문의 대부분은 정말 기본적인 내용에 관한 것이다. "fsck는 어떻게 씁니까?", "mount가 무엇입니까?"... 이미 초보를 통과한 리눅서들에게는 황당하게 보이지만, 이런 질문을 하는 사용자들을 나무랄 수는 없다. 윈도우에 익숙한 사용자들에게 아무리 mount의 개념을 설명해도 알아듣지를 못하기 때문이다. 그래서 유닉스(리눅스)의 기본적인 개념이 없는 사용자는 모든 것이 난해하고 복잡해서 조금 용기를 내 보다가 중도 하차하게 된다. 리눅서들에게는 형용모순처럼 보이는 질문을 하지 않을 수 없는 윈도우 사용자의 위치를 이해하기로 하자. 필자는 최근에 두 명의 윈도우 사용자에게 리눅스에 대해서 알려 주어야 할 일이 생겼다. 한 명은 윈도우 비주얼 프로그래밍을 7년 이상 해 온 개발자이고 다른 한 명은 윈도우 95에서 그래픽을 조금 해 본 초보 프로그래머이다. 이 들에게 어떻게 리눅스에 대해서 설명할 것인가? 이 둘을 만족 시킬 수 있는 한가지 설명 방식을 찾을 수 있을까? RTFM의 진정한 뜻 유저넷을 검색하다 보면 RTFM이라는 문장을 자주 만나게 될 것이다. AFAIK(As Far As I Know), IMHO(In My Humble Opinion), IIRC(If I Remember Correctly) 처럼 축약된 용어인데 이 말의 뜻을 알고 있는 독자들이 많을 것이다. 그 뜻은 "잘 정리된 설명서를 읽어라" (Read The Fine Manual)이다. 그런데 뉴스 그룹에서 보면 조금 이상한 문장 속에서 이 말이 나온다. 즉 "hey, shit! rtfm!!" 이런 방법으로 쓰이고 있는 것이다. 그 이유는 무엇일까? 아래 박스 기사에 나온 것처럼 리눅스를 익히기 위해서 구할 수 있는 수많은 문서가 있다. 그러나 사용자의 대부분은 이런 설명서를 읽지 않는다. 영어가 모국어인 사람들도 이런 지경인데 한글을 쓰는 사용자들은 더 말할 필요가 없다. 이들은 뉴스그룹을 뒤지고 알고 싶은 것이 있으면 그냥 뉴스그룹에 포스팅한다. "이 것을 알려 주세요." 이런 뉴스 때문에 뉴스그룹의 토론이 제대로 이루어지지 않고 수많은 질문 글 사이에서 정보가치가 있는 글이 묻혀 버린다. 거의 대부분의 질문이 FAQ나 HOWTO 또는 LDP 문서에서 찾을 수 있음에도 오늘도 같은 질문이 계속되고 있다. 한 두번 이런 질문에 대해 친절히 대답을 알려 주던 리눅서들이 지치게 된다. 계속되는 질문에 응답하지 않게 되고 질문한 사람들은 왜 대답해주지 않느냐는 글을 올린다. 결국 화난 리눅서는 외칠 수 밖에 없다. rtfm!(read the FUCKING manual), rtfm의 진정한 뜻은 리눅서가 되고 싶으면 "설명서를 읽어라"라는 가장 기본적인 원칙을 무시하는 사용자들을 질타하는 목소리이다. 리눅서가 되고 싶은가? rtfm!!! 리눅스 문서들 리눅스는 한 업체에서 만들지 않기 때문에 출판되어 나오는 공식 문서는 없다. 이런 문제를 해결하기 위해서 LDP(Linux Document Project)가 시작되어 현재 발표된 문서는 초보자를 위한(I&GSG), 커널 해킹을 위한(KHG), 알파포팅을 맡은 팀이 직접 쓴 리눅스 커널 구조설명서(TLK), 네트웍 관리자를 위한(LNAG), 프로그래머를 위한(LPG), 시스템 관리자를 위한(LSAG), 컴파일러등의 사용법에 관한(LUG) 등이 있다. 이 문서들은 sgml 포맷으로 만들어져서 tex, postscript, html로 배포되고 있으므로 원한다면 프린트 해서 보면 된다. 각 문서는 개괄서적인 면이 강하고 구체적인 사항에 대해서는 자세하게 언급되어 있지 않기 때문에 전반적인 개념을 잡는데는 도움을 주지만 특정 문제를 해결하는 데는 큰 도움이 되지 않는다. 그러나 이 문서들을 보지 않고는 결코 리눅서가 될 수 없다. 반드시 숙독을 해야 한다. 유저넷에 올라오는 질문의 90% 이상은 LDP 문서에서 그 답을 찾을 수 있다. LDP 문서는 리눅스를 다루는 지도가 되기 때문에 꼭 읽어 볼 것을 권한다. 이 중에서 번역된 것은 I&GSG, LSAG, LPG, TLK, LNAG,등이 있다. 한글 번역판은 리눅스 한글 문서 프로젝트 사이트(http://kldp.linux-kr.org)에서 구할 수 있다. 이 사이트에서는 그밖에도 한글로 되어 있는 많은 문서를 구할 수 있다. 리눅서라면 여기서 제공하는 문서를 반드시 모두 읽어 봐야 한다. 특정한 문제를 해결하고 싶을 때는 어떤 문서를 참고해야 할까? LDP 프로젝트는 이와 관련해 HOWTO 문서를 제공한다. HOWTO는 NET-3-HOWTO 처럼 리눅스의 네트웍 장치의 종류와 사용법에 대한 개략적인 설명을 한 문서가 있고 DNS-HOWTO 처럼 NET-3-HOWTO에서 간단히 언급된 네임서버 구축을 위해서 어떻게 해야 하는지 구체적으로 설명한 문서가 있으며 mini/Mail-Queue 처럼 팁 성격이 강한 간단한 문제에 대한 해결책을 담은 문서가 있다. 이들의 최신 문서는 http://sunsite.unc.edu/LDP에서 구할 수 있고 비교적 최신 문서는 당신의 하드 디스크에 있다. /usr/doc/HOWTO를 뒤져보기 바란다. 물론 이들 문서 중 일부는 번역되어 있다. /usr/doc/HOWTO/translations/ko를 뒤져볼 것. 번역이 추가되었다면 klpd사이트에 올라와 있을 것이다. 여기서 도움을 받았다면 klpd 사이트 관리자에게 감사편지를 보내는 것을 잊지 말기 바란다. 이들 문서에서도 문제를 해결하지 못했다면 어떻게 해야 할까? 직접 프로그램의 메뉴얼 페이지를 조사해 보자. /usr/man 아래에 있는 수많은 설명서를 지나쳐서는 안된다. /usr/man/whatis 문서는 각 메뉴얼페이지가 어떤 용도로 쓰이는지 간단히 설명되어 있다. 여기를 조사해 보면 원하는 목적에 필요한 프로그램을 찾을 수 있다. 메뉴얼 페이지를 구동할 때는 가능한 -a 옵션을 사용할 것을 권한다. 예를 들어 chroot 라는 프로그램은 3개의 설명서가 있다. C 함수로 쓰일 때, 프로그램 명령 설명(영문,한글) 등이다. -a 옵션을 쓰고 :q 명령을 쓰면 다음 메뉴얼 페이지를 보여 준다. whatis로 충분하지 않으면 아래 명령으로 메뉴얼 페이지를 다 뒤져도 좋다. 내가 원하는 문제와 연관이 있는 단어가 들어 있다면 그 설명서 이름을 보여 줄 것이다. /usr/man# grep "my_problem" */* 메뉴얼페이지가 부족하다면 각 프로그램에서 제공하는 설명서가 있다. /usr/doc 아래를 뒤져보면 각 프로그램을 만든 제작자가 사용법이나 주의점에 대해서 쓴 파일을 찾을 수 있다. 좀 더 구체적인 설명서를 원한다면 /usr/info를 뒤져볼 것. info 라는 프로그램을 실행하면 이 디렉토리에 대한 지도를 보여 주고 방향키를 사용해서 조사해 볼 수 있도록 하고 있다. 이 문서들은 GNU/texinfo 파일 형식으로 된 것을 변환한 것이다. html 처럼 하이퍼텍스트이므로 원하는 주제를 찾아 검색할 수 있다. 프로그래머라면 컴파일러 툴과 라이브러리 레퍼런스가 필요할 것이다. GNU GCC가 사용하는 라이브러리의 함수 목록과 사용법은 어떻게 알 수 있을까? /usr/info/libc-info.gz를 읽어보면 된다. 늘 참조하는 문서이므로 프린트해서 보고 싶다면? GNU 미러 사이트(예를 들어 ftp.kreonet.re.kr:/pub/gnu)에서 gnu-libc 소스 파일을 가져와서 configure; make 하면 libc.dvi라는 파일을 만들어 준다. 이 문서는 libc reference manual로서 약 700페이지 정도 되므로 dvips와 psutil(ftp://sunsite.unc.edu/pub/Linux/apps/wp)의 psnup을 사용하여 압축양면 인쇄를 할 수 있다. GNU 프로그램 중에서 make, GCC, library, bison(yacc), flex(lex), gas(assembler), gdb(gnu debuger)등의 소스파일에는 texi 원본 파일이 있으므로 이들을 프린트하면 된다. 설명서를 이해하기 힘들거나 활용예가 부족해 문제를 해결할 수 없다면 유저넷이나 통신에서 제공하는 문서를 참고할 수 있다. ftp://rtfm.mit.edu에는 유저넷의 모든 뉴스그룹에서 제공하는 FAQ를 보관하고 있다. 리눅스 관련 뉴스그룹은 comp.os.linux. 아래에 수도 없이 많으며 각 나라마다 따로 자기 나라 언어로된 뉴스그룹을 운용하고 있다. fr.comp.os.linux 등과 같은 것들이다. c.o.l. 이하에서 현재 발생하는 문제나 해결책을 구할 수 있을 것이다. 영어를 쓸 수 있다면 질문을 해도 된다. 질문이 자세하고 공손하다면 전세계의 해커들이 답을 줄 것이다. 유저넷의 한글 그룹에는 부족하나마 한글과 한국적 상황에 대한 설명을 찾을 수 있다. han.comp.os.linux, han.comp.mail 등의 그룹을 검색해 볼 것. 한국의 리눅스 해커들을 여기서 찾아 볼 수 있다. 리눅스는 해커 문화가 뿌리 깊어서 실력으로 존경받는 경향이 강하다. 여기에서는 메뉴얼을 뒤지면 간단히 해결할 수 있는 문제나 "컴파일이 안돼요" 같은 황당한 질문이나 "센드메일을 컴파일하는 자세한 방법을 조목조목 알려 주세요" 같은 건방진 질문만 하지 않는다면 이들 해커로 부터 큰 도움이 될 대답을 들을 수 있다. 리눅스 해커들은 자신의 시간을 들여서 대답을 해 주기를 즐기고 이 과정에서 자연스럽게 실력이 드러나기 때문에 존경을 받게 된다. 뉴스그룹을 만들 만큼 주제가 크지는 않지만 활발히 활동하는 사람들은 메일링리스트를 운용하고 있다. 여기서는 현재 만들고 있는 프로그램의 버그, 패치, 구체적 사용법, 성능개선등에 대한 토론이 올라온다. 뉴스그룹에 가입하는 방법은 메일링리스트에 일정 양식의 메일을 보내면 되지만 이 것이 복잡하다면 http://oslab.snu.ac.kr/ djshin/linux/mail-list을 방문해 보기 바란다. 리눅스와 관련된 메일링리스트에 가입/탈퇴를 웹방식으로 편하게 할 수 있다. 메일링 리스트를 가입하면 그 때부터 도착하는 메일을 읽어 볼 수 밖에 없어서 이전에 어떤 문제가 토론되었는지 알 수 없다. 그래서 각 메일링 리스트는 지난 메일을 보관해 놓는 곳이 있다. 예를 들어 http://www.tux.org/hypermail/ 아래에 가면 리눅스 커널 메일링 리스트와 여러 다양한 관련 메일링 리스트가 주제별로 저장되어 있다. 여기 뿐만 아니라 웹을 검색해 보면 수많은 메일링리스트 어카이브 사이트를 찾을 수 있다. 한국의 리눅스 통신 동호회에도 많은 질문과 답이 올라와 있다. 거의 기초적인 설치에 관한 것이지만 그 중에서 쓸모있는 답변도 많다. 특별한 문제의 근원적인 해결은 볼 수 없지만 다른 정보를 찾아 갈 수 있는 정보는 얻을 수 있다. 통신에서 lt 명령을 적극 활용하기 바란다. 번역글이나 강좌등이 통신에 먼저 올라오는 경우가 많기 때문에 강좌란은 늘 검색해 볼 필요가 있다. 리눅스와 관련된 정보들은 리눅스의 성격에 영향을 받아서 거의 공개로 제공하고 있고 답변을 올려 주는 사람들도 댓가를 바라지 않는다. 인터넷의 수많은 웹사이트에서 자신이 알고 있는 팁을 올려 놓은 사이트가 엄청나게 많다. 이들은 방문 카운트가 증가되는 것을 기뻐할 뿐 여기서 어떤 이익을 얻으려고 하지는 않는다. 정보를 유용하게 사용했다면 감사 편지를 보내는 것은 기본 예의일 것이다. 개인 홈페이지로 한국에서 유명한 사이트는 프로그램 한글화의 최전방에 서 있는 최준호씨(http://jazz.snu.ac.kr/ junker), 적수라는 별명으로 더 알려진 김병찬씨(http://www.linux.sarang.net), 한글 프로그래밍의 원칙을 세우고 있는 신정식씨(http://pantheon.yale.edu/ jsin), 센드메일과 한글 메일에 대한 완벽한 해결책을 제시하는 이상로씨(http://suny.mutli.co.kr/ leesl)등이 있다. 여기서도 문제를 해결할 방법을 찾지 못했다면 인터넷 검색사이트를 이용해도 된다. 아마 검색어가 포함된 수많은 사이트를 모두 방문하지도 못할 것이다. 수많은 리눅스 관련 정보는 인터넷의 거의 대부분을 차지하고 있다. 그러나 이런 정보들은 거의 프로그램 사용법이나 활용에 대한 것들이다. 문제는 가장 기본적인 지식을 가져야 활용 정보를 사용할 수 있다는 것이다. 당면한 긴급한 문제만을 해결하기만 하면 그만이라면 이런 정보들만을 이용해도 좋다. 그러나 네트웍 프로그래밍을 하면서, 게가 그려진 책을, 센드메일 프로그램을 이용해서 대규모 메일을 관리하면서 박쥐가 그려진 책을 한 번도 읽어 보지 않았다면, 언젠가는 무너질 모래성을 쌓는 것이다. 수많은 정보가 널려 있어도 가장 원칙적인 것은 기본서를 숙독하는 것이다. 가이드, 설명서, 뉴스그룹에서 결국 마지막 레프런스로 참조하라고 하는 책을 사지 않고는 버틸 수 없다. 오늘 퇴근 후에 서점에 들러 보는 것은 어떨까? 어떤 것을 읽어야 하는가? 리눅서가 되려면 메뉴얼을 읽으라는 말을 듣고 그러고 싶어서 문서들을 뒤져보아도 아직 막막할 것이다. 설명들을 하나도 이해할 수 없고 이 책에서는 저 책을 참조하라고 하고 저 책은 다른 것을 참조하라고 하고 그 책은 다시... 초보자에게 메뉴얼을 읽으라는 말은 사전을 통채로 모두 읽으라는 말과 같이 들린다. 언제 사전을 모두 다 읽는단 말인가? 사전을 모두 읽는다고 그 언어를 자유자재로 구사할 수 있는가? 초보 리눅서들에게 필요한 것은 이런 메뉴얼을 관통하는 기본 원리에 대한 설명이다. 리눅스의 기본 원리는 무엇인가? 리눅스는 유닉스다. 그러므로 리눅스의 기본 원리는 유닉스의 기본 원리와 같다. 그렇다면 유닉스의 기본원리는 무엇인가? 그 것은 멀티유저 멀티타스킹 운영체제란 사실이다. 여기서 다시 지루한 유닉스의 특징을 나열하지는 않겠다. 유닉스 개론서 앞부분에 잘 정리되어 있는 내용을 읽어 볼 것. 멀티유저 시스템이란 사용자와 관리자란 계층이 있음을 뜻한다. 멀티유저 시스템을 유지하기 위해서는 관리자가 필요하다. 사용자들의 권한을 제어하고 서비스 해야 할 프로그램들을 정리하는 관리자는 유닉스에 대한 전반적 지식을 가진 사람이 할 수 있는 일이다. 과거 대부분의 유닉스 사용자들은 단말기 앞에서 자기 계정을 가지고 허락된 작업만을 할 수 있었다. 그 때는 유닉스 프로그램 설명서 정도만 가지고 있으면 유닉스를 쉽게 이해할 수 있었다. 복잡한 관리는 할 필요도 할 권한도 주어지지 않았기 때문에 그런 부분은 생각하지 않아도 되었기 때문이다. 그러나 PC에 직접 인스톨 할 수 있는 유닉스 클론들이 나타나면서 유닉스에 전혀 문외한인 사람들에게 유닉스 프로그램 사용부터 시스템 관리까지 모든 것을 한꺼번에 하도록 요구함으로써 아무 것도 할 수 없도록 만들어 버렸다. 리눅스가 더 어려워진 것이다. 유닉스의 경험은 사용자 계정으로 로그인하여 cp,rm등의 명령을 익히는데서 부터 출발한다. 센드메일 설정등의 복잡한 일은 차후로 미루고 가장 기본적인 명령어들에 대한 이해를 먼저 시작하자. I&GSG와 LUG를 들고 ls, cp, vi 명령을 익히자. 시스템 관리는 지금 할 일이 아니다. I&GSG가 너무 단순하다면 유닉스 사용자 설명서를 한 권 구해서 읽으면서 설명되어 있는 프로그램을 직접 실행해 보는 것이 좋을 것이다. 요즘은 자신이 무슨 내용을 쓰고 있는지 확실히 알면서 쓴 책들이 많다. 유닉스 로그인, 셸에 대한 설명, 메뉴얼 페이지 사용법, 모든 명령어가 따르는 일반 형식, 네트웍 관련 사용자 프로그램들, 파이프와 필터, 파일의 처리, vi 사용법, 파일 시스템에 대한 이해, 유저넷과 뉴스그룹등등.. 유닉스 사용자 권한으로 할 수 있는 것이 많고 이 것을 제대로 익히면 시스템 관리도 어려운 것이 아니다. 시스템 관리를 위해서는 LSAG가 필요하다. 이제 /etc 디렉토리를 관리해야 한다. 또한 리눅스 파일 시스템 표준(FSSTND)에 대한 이해를 해야 할 때이다. 모든 관리자용 프로그램은 /bin, /sbin, /usr/sbin, /usr/bin에 있고, 설정 파일은 /etc에, 로그는 /var/log에, 각 개인별 설정파일은 /.xxxrc 형태로 두는 것, 비표준 패키지는 /usr/local 아래에 인스톨 된다는 것, /var, /tmp, /usr, /etc, /lib 등의 디렉토리가 왜 만들어져 있고 어떻게 이용되는지 이해하게 될 것이다. 특정 프로그램이 실행되면서 어떤 파일을 참고하는지 알고 싶으면 다음과 같이 실행해 볼 것. 프로그램이 리눅스 시스템 안에서 어떤 함수를 호출하고 어떤 파일들을 열고 읽는지 한 눈에 볼 수 있다.     # strace vi 2>a     # less a 파일 시스템 표준과 필터 프로그램에 대해 익히고 기본 에디터를 제대로 사용할 수 있다면 이제 설정 변경을 할 수 있다. /etc/hosts, /etc/exports 파일등을 다룰 수 있을 것이다. /etc 아래의 파일들은 메뉴얼 페이지가 있다. "man exports"라고 하면 그 파일의 형식을 자세히 보여 줄 것이다. 물론 이 파일이 어디에 쓰이는지는 파악을 해야 한다. 메뉴얼 등에서 이 파일이 쓰이는 곳을 찾아 보던지 "rpm -qf /etc/exports"라고 쳐서 이 파일이 어느 패키지에 속하는지 확인하고 그 패키지가 하는 일은 무엇인지 파악해도 된다. 많은 설정파일에 있듯이 "당신이 무슨 일을 하고 있는지 알지 못한다면 손대지 말것". 이제 본격적으로 /etc/rc.d 아래의 파일을 손보자. 이 디렉토리에는 리눅스가 기동 되면서 필요한 작업을 하도록 되어 있는 곳이다. 지금 "ps axf"라고 실행해 보면 알 수 없는 프로그램들이 떠 있을 것이다. 쓰지도 않는 nfs, autofs, gpm등의 데몬이 떠 있다면 이들은 모두 /etc/rc.d/init.d 아래에서 찾을 수 있다. 어떤 데몬인지 확인하고 필요한지 여부를 판단한 다음 필요없다면 지워도 된다. 각 데몬들은 도스의 램상주 프로그램처럼 메모리를 낭비하고 있으므로 이 데몬들을 정리하면 컴퓨터의 반응이 훨씬 빨라질 것이다. 필자가 만난 한 유닉스 관리자는 인디고를 관리하고 있었는데 사용자가 컴퓨터가 잘 작동하지 않는다고 하면 6개짜리 인스톨 CD를 모두 재설치하는 것을 본 적이 있다. 256M의 메인메모리를 쓸데 없는 데몬이 모두 점유해서 정작 사용자가 띄운 그래픽 프로그램은 쓸 수 없을 정도로 느리게 실행되었다. 사용자는 컴퓨터가 후지다고 본체를 발로 차며 사용하고 있었다. /etc/rc.d/ 디렉토리를 마음대로 고칠 수 있다면 이제 스스로 리눅서라고 생각해도 좋다. 웬만한 설정을 할 수 있고 감을 잡았다면 구체적 문제를 위해서 HOWTO 문서를 읽으면서튜닝을 하자. 백여개의 HOWTO 문서를 참고한다면 못할 일이 없다. 고정된 IP를 할당 받을 수 있다면 웹서버와 네임서버를 설치해서 사용해 보고 센드메일을 사용해서 메일을 내 컴퓨터에서 받아보기도 하자. 학생이라면 이제 프로그래밍에 눈을 돌릴 때이다. 커널부터 라이브러리 소스까지 가능하면 이들을 뒤져 볼 것. 버그를 발견했거나 성능을 향상시킬 방법을 알았다면 오픈소스 프로젝트에 참가해도 좋다. 어떻게 읽어야 하는가? 다시 처음으로 돌아가자. 유닉스 개론서를 읽고 가이드를 보고 HOWTO를 보면 리눅서가 될 수 있다. 참 좋은 말이다. 그런데 여기에도 문제가 있다. 예를 들어 ipfwadm이라는 프로그램을 이용해서 IP-Masquerade를 하고 싶다. HOWTO 문서도 있지만 모든 것을 설명하고 있지는 않다. 그래서 스스로 "man ipfwadm"으로 사용법을 익히려고 한다. 슈퍼 레드헷에는 한글로 된 메뉴얼 페이지가 나온다. 그러나 각각의 옵션에 대해서만 설명하고 있으며 이 설명도 잘 이해되지 않고 옵션들간의 연관관계에 대한 정확한 지침이 없다. IP-Masquerade mini HOWTO에는 다음과 같이 사용하라고 나와 있다.     #ipfwadm -F -a m -S yyy.yyy.yyy.yyy/x -D 0.0.0.0/0 yyy..에서 출발한 패킷을 x로 마스크해서 문제가 없으면 모든 주소(-D)로 masquerade해서 보내라는 옵션이다. 그런데 메뉴얼페이지 어디에도 -a 다음에 m을 사용하는 이유를 설명해 놓지 않고 있다. 그러므로 ipfwadm을 사용해서 masquerade를 할 수 있다는 것을 알아내고 메뉴얼페이지를 아무리 읽어도 이 것을 할 수 없는 것이다. 이 문제를 어떻게 해결할 것인가? 마찬가지로 셸프로그래밍을 하면서 이 셸스크립트가 600초 후에는 스스로 끝내게 하는 기능을 넣고 싶다. 셸 스크립트 언어에는 전역변수로 SECONDS가 있다. 셸스크립트가 기동하면서 이 것을 0으로 초기화 시키면 그 때부터 1초마다 값이 증가한다. 이 값을 저장한 후에 나중에 비교해 보면 600초 후에 셸스크립트를 끝낼 수 있다. 그런데 bash 의 메뉴얼 페이지는 3960줄이다. 언제 이 설명서를 다 읽는단 말인가? 그리고 읽더라도 이 변수를 이런 용도로 사용할 수 있음을 어떻게 안단 말인가? bash 메뉴얼의 SECONDS 부분의 설명은 다음과 같다.     SECONDS     Each time this parameter is referenced, the number     of seconds since shell invocation is returned. If     a value is assigned to SECONDS, the value returned     upon subsequent references is the number of seconds     since the assignment plus the value assigned. If     SECONDS is unset, it loses its special properties,        even if it is subsequently reset. 영어를 모국어로 사용하는 사람들도 이해하기 힘든 이런 설명을 보고 어떻게 이 변수의 용도를 짐작할 수 있을까? 그러므로 아무리 설명서를 읽어도 조금도 이해되지 않고 읽을 수록 머리만 복잡해질 뿐 리눅스를 사용하거나 관리하는데 도움이 되지 않는다. 셸프로그래밍에 대한 책도 나와 있지만 간단한 작업을 하기 위해 이런 책을 사서 읽는 다는 것은 낭비일 뿐이다. 셸프로그래밍 책을 보면 셸스크립트 언어만을 설명한 것이 아니라 필터 프로그램의 조합에 대한 설명이 더 많다. 또다시 필터 프로그램의 메뉴얼페이지를 읽어야 한다. 셸프로그래밍 책에서 셸스크립트의 한계를 지적하며 궁극적으로는 perl을 사용하라고 권한다. 공식 perl사이트인 http://www.perl.com에서 제공하는 perldoc 문서는 1256페이지에 달한다. perl 문서를 읽는다고 perl에 대해서 정통해 질 수 없다. perl로 짠 암호화 같은 스크립트 파일들은 그 내부를 들여다보고 한 줄 한 줄 분석해야 무슨 일을 하는지 알 수 있다. 원하는 일을 위해 perl로 스스로 프로그램을 짜는 것은 또다른 문제이다. 이렇게 얼키고 설켜있는 문서와 문서사이에서 중심을 잡고 개념을 파악하려면 어떻게 해야 할까? --- 중요 정보가 있는 곳을 기록해 놓자. 문서들을 읽는다고 모두 알 수는 없다. 읽을 때는 별 소용이 없어 보이지만 나중에 꼭 필요한 경우가 많다. 스스로 중요하다는 생각이 드는 내용이 있다면 표시해 놓거나 북마크에 넣어 두기 바란다. 유저넷에서 읽은 글이라면 다운 받아 저장해 놓거나 프린트 해두어도 된다. 흘러 지나간 정보에 대해서 KNOW WHERE를 기억할 수 있는 단서만 만들어 두면 나중에 쓸모 있는 정보가 된다. 기록해 놓지 못했지만 메뉴얼 페이지에서 본 기억이 있다면 find, grep 명령을 활용할 것. --- 중요한 것과 중요하지 않은 것을 구분하자. 프로그래밍을 위해서 프로그래밍 언어에 관심을 가지면 C가 유일하지만 홈페이지등에 쓰기 위한 CGI를 만들려면 사용할 수 있는 언어는 여러가지가 있다. perl, tcl, java, php3등등 각자 성능과 범용성, 다양한 라이브러리등으로 무장하고 우리를 유혹한다. 모두다 사용해 보고 싶은 욕심에 이것 저것 건들다 보면 아무 것도 할 수 없다. 언어는 나름의 장단점이 있으므로 한가지만을 선택해서 깊이 익히는 것이 낫다. 마찬가지로 리눅스 한글화, 커널 프로그래밍, 프로그램 포팅, 엑스윈도우 프로그래밍등등 모든 부분에 힘을 쏟을 수는 없다. 자기의 전공 분야를 만들고 여기에 집중할 필요가 있다. 메뉴얼 페이지를 볼 때도 ls 명령의 다양한 옵션을 모두 살펴볼 필요는 없다. HOWTO등에서 특별한 옵션을 사용해야만 필요한 일을 할 수 있도록 되어 있다면 모르지만 한 번 읽어 보는 정도로 그치고 이런 것에 신경을 쓸 필요는 없다. ls 명령은 -NFlai 정도만 알고 있어도 전혀 지장이 없다. --- HOWTO 등을 볼 때 옵션에 대해서 메뉴얼을 참고 하자. 가이드와 설명서에는 프로그램의 사용법만은 보여 준다. 그대로 따라만 해서는 언제나 실력이 그 상태에서 변하지 않는다. 응용을 할 수 없는 것이다. 설명서에 쓰이는 프로그램의 옵션 중에서 이해할 수 없는 것이 있다면 꼭 메뉴얼 페이지를 살펴볼 것. 위에서 말한 ipfwadm의 -a m 옵션은 메뉴얼에도 없으므로 원한다면 ipfwadm 프로그램 소스를 구해서 사용법을 알아 두는 것이 단순히 -a 다음에 m 을 쓰면 된다고 외우는 것보다 훨씬 도움이 된다. -a 다음에 쓸 수 있는 옵션이 m 뿐일까? --- 다른 사람의 글을 읽을 때 추가 정보에 주목하자. 유저넷이나 통신에서 다른 사람의 글을 읽을 때 꼭 질문/답변한 부분에만 관심을 가질 필요는 없다. 이런 글에서 나오는 프로그램 설명은 또다른 좋은 예가 되기 때문에 차분히 뜯어 볼 필요가 있다. ________________________________________ 하이텔 linux 9번란 #19994 박종채 (누리단비) [답변] ls명령의 색깔지정=> .bashrc 1998-11-24 09:52 14 line ls명령어의 컬러 정의 지우기 각자의 홈 디렉토리에 있는 .bashrc파일의 # alias 정의 alias ls 'ls -NF --color=auto' 라고 되있는 부분을 # alias 정의 # alias ls 'ls -NF --color=none' 와 같이 막는다 ________________________________________ 이 글은 통신에서 답변으로 올라온 글이다. ls 명령을 사용했을 때 파일명을 종류에 따라 다른 색으로 보이게 하는 방법에 대한 설명이다. 이 글을 읽고 .bashrc 파일을 고치기만 해서는 실력이 늘지 않는다. 여기서는 여러가지 정보를 가르쳐 주고 있다. .bashrc 파일이 왜 ls와 연관이 있는가? 이 파일이 하는 일은 무엇인가? alias 라는 명령은 무엇인가? ls의 -N, -F, --color=none 옵션이 각각 뜻하는 것은 무엇인가? 이런 것들을 생각하고 조사해 보아야 스스로 이 파일을 조작해서 pp라고 치면 "cd .." 명령이 수행되도록 만들고 이 것이 늘 그렇게 되도록 할 수 있게 된다. 메뉴얼페이지의 나열식 설명을 하나하나 읽는 것보다는 다른 사람의 글에서 프로그램의 활용예를 볼 때마다 이를 역으로 조사해 보는 것이 훨씬 효율이 좋다. --- 자기 만의 방법을 사용하자. 모든 프로그램의 사용법을 알 수는 없다. /usr/bin 아래의 프로그램들을 보면 모르는 것이 대부분이다. 많은 것들이 필터 역할을 하는 프로그램들이다. 셸스크립트의 필터로 사용할 목적으로 이 것들을 모두 알고 있을 필요는 없다. sed, awk, grep, cut, find 등 대표적인 것들만 조사해 보자. 그리고 이들도 서로 사용법이 겹친다. 그러므로 한가지 프로그램을 확실히 사용할 줄 알면 다른 것들을 몰라도 버틸 수 있다. perl을 알고 있다면 이들 필터까지도 무시해도 된다. /usr/src/linux 아래에서 SCSI_LUN 이라는 문자를 가진 파일을 알아보고 싶다면 어떻게 할 수 있을까? 필자는 아래처럼 한다. /usr/src/linux# grep "SCSI_LUN" *.[ch] */*.[ch] */*/*.[ch] 멋있고 세련된 방법을 들라면 다음과 같이 할 수 있을 것이다. /usr/src/linux# grep "SCSI_LUN" `find . -name '*.[ch]' -print ` 물론 위의 find 정도는 알고 있어야 하겠지만 몰라도 상관없다. grep 하나로 버틸 수 있으니까. 자신만의 방법이 있다면 이 것을 버리지 말것. 복잡한 프로그램의 사용법을 열심히 익혀도 정작 필요할 때에는 생각이 나지 않고 틀리게 쓸 경우가 많기 때문에 그렇게 쓸 수 있다는 것을 알고만 있으면 된다. 유닉스의 기본 원칙은 "작고 단순한 것이 아름다운 것"이다. --- 목표를 가지자. 운영체계 수집을 취미로 하는 사람들이 있다. 몇 기가씩 되는 하드 디스크를 여러 개 붙이고 여러 운영체계를 깔아 놓고 쓰는 사람들이 많다. 생산적인 일을 하거나 운영체계 공부를 하는 것이 아니라 그 자체가 취미인 사람들이다. 이런 사람들에게는 리눅스가 별 필요가 없고 도움도 되지 않는다. 윈도우가 마음에 들지 않는다면 요즘 뜨고 있는 BeOS나 깔아서 쓰는 것이 좋을 것이다. 현장에서 지금 웹서버를 돌려야 하는 사람이라면 당연히 취사선택할 부분이 눈에 들어오겠지만 이제 리눅스에 대해서 관심을 가진 시간있는 사람들은 어떤 것을 먼저 해야할지 막막할 뿐일 것이다. 필자는 10년 전 PC에서 엑스윈도우를 돌리고 싶다는 생각에 유닉스를 구하러 다녔다. BSD 계열과 SYSV 계열의 여러 유닉스를 인스톨 했지만 모두 실패하고 리눅스를 만나서 소원을 이룰 수 있었다. 남들에게 쓸모 없어 보이는 생각을 품고 있거나 황당해 보이는 목표를 가지고 덤벼들어도 상관없다. 그 목표를 위해서 리눅스를 뒤지다 보면 어느 새 리눅스 해커가 되어 있는 자신을 발견할 수 있을 것이다. 결국에는 스스로 해야 한다. 리눅서가 되기 위해서 읽어야 할 문서와 그런 문서를 읽는 방법과 자세에 대해서 설명 했다. 웬만한 일은 훑어 본 문서를 다시 참고하면 해결할 수있다. 그러나 정작 필요한 부분에서는 문서들이 크게 도움을 주지 않는다. 박스기사에 예를 든 eql에 대한 것도 유저넷에 질문만 넘쳐 날 뿐 쓸만한 답변은 없다. 혼자서 eql을 세팅할 수 있었다고 해도 크게 쓸모가 없다. 왜냐하면 결정적으로 eql 디바이스가 한 개만 제공된다는 것이다. 전용선 업체에서 여러 가입자에게 서비스 할 수 없는 일에 신경을 쓸 이유가 없기 때문에 실제로 사용해 보기는 힘들 것이다. 전용선 업체에서 이 기능을 사용하여 가입자 수를 늘이고 싶으면 커널 디바이스 드라이버를 고쳐야 한다. drivers/net/eql.c를 고치면 되지만 누가 해 주겠는가? 당신 밖에 없다. 외국에서는 이미 사장된 디바이스가 되었기 때문에 아무도 손을 대지 않을 것이다. 이 것을 고쳐서 동작하게만 한다면 경쟁업체보다 훨씬 기술적 우위를 점할 수 있으니까 한 번 도전해 보기 바란다. 리눅스는 이렇게 스스로 하는 사람들이 만들어 왔다. 커널-메일링-리스트 FAQ에 보면 아직 만들어지지 않은 디바이스 드라이버를 어떻게 만들어야 하는가에 대한 답변이 있다. ? 질문 : TW-345C(가상의 디바이스)를 위한 드라이버를 만들려면 어떻게 시작하나요? 답변 : 우선 하드웨어 명세서를 구하라. 본사에 요청을 했을 때 명세서를 주기를 거부한다면 대리점등에 요청하라. 대리점은 아무 생각없이 명세서를 주는 경우가 많다. 대리점에서 명세서를 넘겨 받았으면 그 사람의 이름은 비밀에 부쳐라. 어디에서도 명세를 구하지 못했다면 윈도우/도스 디바이스 드라이버를 역엔지니어링하라. 많은 정보를 얻을 수 있을 것이다. 드라이버가 어떤 방식으로 하드웨어를 접근하는지 알 수 없으면 dosemu 위에서 실행해 보라. log에 많은 정보가 쌓일 것이다. 문서에 없다고 포기하면 안된다. 방법을 몰라도 포기하지 말것. 커널 디바이스는 여태까지 이런 비참한 방법으로 만들어져 왔다. 해결해야할 문제를 위해서는 스스로 나서야 한다. 아무리 힘들어도 가능성만 있다면 도전해야 하고 리눅스가 자라는 바탕이 바로 그 것이다. EQL을 설정하자 야간정액제, co-lan, ISDN, 호스트접속 방식랜등이 있지만 시간제한과 비용 때문에 별 소용이 없고 케이블 통신, ADSL등의 미래지향적인 서비스는 지역적 한계로 이용할 수 없는 경우가 많고 아직 활성화 되어 있지도 않다. 현재 개인 사용자가 사용할 수 있는 네트웍으로는 TT라고 불리는 전화급 전용선이 최선의 선택이다. TT의 문제는 전화국의 교환기가 음성정보만을 다루도록 필터링을 하기 때문에 서버쪽에 고가의 모뎀을 설치하지 않으면 33.6K 이상의 접속은 이루어지지 않는다. 33.6K 속도로는 원활한 네트웍 작업을 하기에는 무리가 있다. 그래서 나온 대안이 EQL이다. EQL은 ppp로 접속된 TT선을 두 개 이상 붙여서 속도를 증가시키는 목적으로 사용할 수 있다. 그러나 리눅스 커널에 이 기능이 포함되어 있음에도 관련 문서가 거의 없다. EQL에 대한 문서는 NET-3-HOWTO, /usr/src/linux/drivers/net/[README.eql,eql.c], ftp://ftp.kreonet.re.kr/.1/Linux/sunsite/system/network/eql-1.2.tar.gz 뿐이다. 뉴스그룹과 서치엔진에서 eql을 넣어 보았지만 여기서 제시하는 문서 이상의 내용이 있는 것은 보기 힘들다. 이 문서에서는 뭐라고 얘기하고 있을까? ppp,slip으로 연결된 회선을 두개 이상 붙이고 eql을 사용하면 1개 선로 보다 89% 정도의 속도 증가를 가져올 수 있다. 서버쪽에 멀티링크를 지원하는 하드웨어를 사용하거나 리눅스 박스가 있으면 된다. TT선을 사용하는 사람들에게는 아주 매력적인 것이지만 문제는 외국에서는 이미 개인 전용선들이 충분히 빨라졌는지 95년 이후로 더 이상의 정보는 나오지 않고 있다. 또한 설명서에 있는 대로 해도 로드 밸런싱이 되지 않는다는 문제가 있다. 마지막으로 서버 쪽은 리눅스가 아닌 멀티링크 지원 하드웨어를 가정하고 있다는 것이다. 이 문제를 해결해 보자. eql은 다음과 같이 구성된다.                     - server ppp0(slave) --tt-- client ppp0(slave) -                         server eql               { }       client eql 168.126.153.3 - server ppp1(slave) --tt-- client ppp1(slave) - 168.126.153.112 서버에서는 접속을 받아 들일 때 패킷의 경로를 재설정할 수 있도록 헤더 압축기능을 제거하고 ppp 연결을 시킨다.(novj 옵션 사용) 서버측에서는 접속을 받아 들인 후에 다음 스크립트를 crontab에 넣고 실행시켜 주도록 하면 된다. ________________________________________ #!/bin/sh export PATH="/bin:/usr/bin:/sbin:/usr/sbin" # route table에 eql이 없으면 추가한다. if [ `cat /proc/net/route |grep "70997EA8" |grep -c "eql"` -eq 0 ]; then ifconfig eql down ifconfig eql 168.126.153.3 mtu 1500 route add -host 168.126.153.112 eql fi # 70997ea8 IP가 없으면 ppp 가 처리되었거나 아직 ppp가 접속을 # 하지 않은 것이므로 끝낸다. if [ `route |grep "168\.126\.153\.112" |grep -c "ppp"` -eq 0 ]; then exit fi # 새로 ppp 접속이 만들어졌다. 이를 slave 로 바꾸고 route 테이블에서 # 제거한다. for i in `route |grep "168\.126\.153\.112" |grep "ppp" | awk '{print $8}'` do /root/bin/eql_enslave eql $i 33600 route del 168.126.153.112 dev $i done ________________________________________ 168.126.153.112를 할당받은 ppp[0,1] 디바이스를 eql의 슬레이브 장치로 만든 후에 라우트 테이블에서 제거하고 eql에 host ip를 할당하면 168.126.153.112로 오는 패킷은 모두 eql이 받아서 ppp0과 ppp1 에 적절히 할당한다. 지금 설명은 쉽게 보이지만 서버에서 "route add default eql" 명령을 내리는 순간 TT서버로 접속한 모든 사용자가 외부로 나갈 수 없었다. 사용자의 항의로 전화통에 불이 나는 순간이었다. 설명서에는 eql을 호스트로 만들라는 설명이 없었고 자동으로 eql을 사용하는 ppp 디바이스를 찾아 줄 방법을 연구하느라 서버 관리자와 머리를 싸매야 했다. 수 십개의 전용선이 접속되어 있는 서버의 루트권한을 쓸 수 있도록 해 준 소사벌넷의 손정현씨에게 감사할 뿐이다. 클라이언트 쪽에서는 다음과 같이 하면 된다. # ifconfig eql 168.126.153.112 mtu 1500 # route add -host 168.126.153.3 eql # eql_enslave eql ppp0 33600 # route del 168.126.153.3 ppp0 # eql_enslave eql ppp1 33600 # route del 168.126.153.3 ppp1 서버와 클라이언트 모두 eql이 두 개의 ppp 라인을 감추고 자신이 호스트인 것처럼 위장한 다음 주고 받는 모든 패킷에 대해서 경로 설정을 새로해서 로드 밸런싱이 제대로 되었다. 다음 명령으로 양쪽 모두 패킷을 분리해서 주고 받는 것을 확인할 수 있다. # cat /proc/net/dev Inter-| Receive | Transmit face |packets errs drop fifo frame|packets errs drop fifo colls carrier eql: 0 0 0 0 0 11744 0 292 0 0 0 ppp0: 2042 0 0 0 0 2277 0 0 0 0 0 ppp1: 1519 0 0 0 0 2822 0 0 0 0 0 메뉴얼에도 없고 유저넷에도 사용해 본 사람들의 경험담이나 설명서가 없는 상황에서는 된다는 가능성을 믿고 스스로 해야 한다. 위에서  /proc/net/dev, /proc/net/route,를 이용하는 방법, eql을 게이트웨이가 아닌 호스트로 만들어 보는 시도, crontab의 사용, 셸스크립트 만들기등은 모두 조각난 지식이다. 이들을 엮어 내는 방법을 생각해 낼 수 있는 것은 당장 필요하지 않더라도 평소에 이들 프로그램의 설명서를 한 번 쯤 읽어 본 적이있고 가능성이 있다면 어떻게든 되게 해야 한다는 필요성이 있었기 때문이다. 이래도 안된다면 어떻게 하겠는가? 뭐가 문제란 말인가? 로드밸런싱에 대한 개념이 존재하고 TCP/IP 자체에서 패킷 경로 변경을 지원하고 eql.c 소스가 있지 않은가? 바로 당신이 이 것을 뜯어 고쳐서 한국적 상황에서 가장 효율적으로 네트웍을 사용할 수 있도록 기여하면 되지 않는가? 문제는 마음자세와 실력일 뿐이다. 리눅서가 되자. 필자가 본 리눅서들은 거의 해커기질이 있었다. 윈도우에서 자주 사용하는 프로그램의 기능을 고쳐쓰거나 스스로 만들어 쓰는 프로그램을 가지고 있었다. 그런 프로그램의 질을 따질 필요는 없다. 컴퓨터를 만지면서 문제의식을 가지고 스스로 해결해보고자 하는 자세가 중요하다. 리눅스 박스를 만들고 도전해 보자. 문제를 자신이 해결할 수 있기까지 얼마나 걸릴까? 리눅스만 하루 종일 한다면 2년 정도면 될 것이다. 조급하게 생각하지 말 것. 여유를 가지고 도전하자. 오픈소스 공동체에 참가하여 리눅스를 즐기다보면 어느새 시간이 지나고 당신은 실력있는 리눅서가 되어 있을 것이다. 리눅서는 어떻게 크는가? 현 상태에 안주하지 않고 스스로 문제의식을 가지며, 업체에서 기능을 추가해 줄 때까지 기다리지 않고 자신이 기능을 추가하며, 다른 리눅서가 만든 문서를 완전히 소화한 후 스스로 또 다른 문서를 만들어 내며, 불가능해 보이는 것을 현실로 구현해 내면서 큰다. 김인성.