이전 - 다음

11. 시스템 관리

이장에서는 레드햇 리눅스 시스템에 대해 개괄적으로 설명한다. 시스템에 대해 알아야 할 사항과 다른 유닉스 시스템과의 차이점을 예를 들어가며 설명할 것이다.

11.1 파일 시스템 구조

레드햇 리눅스는 여러 파일과 디렉토리 이름과 위치를 정해 놓은 통합 문서인 리눅스 파일 시스템 표준을 준수하고 있다. 레드햇 리눅스 5.2를 유연하게 관리하기 위하여 계속해서 표준을 따를 것이다.

표준을 따른다는 것은 많은 것을 의미하는데, 가장 중요한 두 가지 사항을 들어보자. 하나는 다른 시스템과 호환성을 유지할 수 있다는 점이고, 다른 하나는 /usr 분할 영역을 읽기 전용으로 마운트할 수 있는 능력을 제공한다는 것이다. /usr 분할 영역은 사용자에 의해 변경될 수 있음을 의미하는 것이 아니라 시스템에서 공유하는 실행 파일을 담고 있다. 따라서 /usr 분할 영역은 시디롬이나 읽기 전용 NFS를 통해 다른 기계로 마운트할 수 있다. 현재의 리눅스 파일 시스템 표준(FSSTND) 문서는 어떠한 FSSTND를 따르는 파일 시스템에 대해서도 믿을 만한 참고 자료가 될 수 있지만, 표준이라 해도 정의되지 않은 부분이 있거나 확장할 수 있는 부분이 있다. 이 절에서는 표준에 대한 개관과 표준에서 언급되지 않은 부분에 대해 설명하고자 한다.

완전한 표준에 대한 사항은

http://www.pathname.com/fhs/

에서 볼 수 있다.

11.1.1 FSSTND의 개관

여기서 사용되는 디렉토리와 파일은 FSSTND 문서에 명시된 내용의 일부이다. 가장 최신의 완벽한 정보를 원한다면 최신의 FSSTND 문서를 확인해 보기 바란다.

/etc 디렉토리

/etc 디렉토리는 기계에 국한되는 설정 파일들을 담고 있다. 바이너리 파일을 /etc 디렉토리에 두지 않는다. 과거에 /etc 디렉토리에 있던 파일은 이제 /sbin 디렉토리나 가능하다면 /bin 디렉토리에 위치시켜야 한다.

X11과 skel 디렉토리는 /etc 디렉토리 밑에 위치시켜야 한다.

/etc

|-X11

+-skel

X11 디렉토리는 XF86Config 같은 X11 설정 파일을 위한 디렉토리이다. skel 디렉토리는 사용자를 생성할 경우, 홈 디렉토리를 만들 때 사용되는 사용자의 기본 설정 파일 골격이다.

/lib 디렉토리

/lib 디렉토리는 /bin 과 /sbin 디렉토리에 있는 바이너리를 실행할 때 필요한 라이브러리를 가지고 있어야 한다.

/sbin 디렉토리

/sbin 디렉토리는 root에 의해 사용되는 실행 파일을 위한 디렉토리이며, 부팅과 /usr 디렉토리 마운트, 시스템 복구 작업을 하는데 필요한 실행 파일이 있는 디렉토리이다. FSSTND에는 다음과 같은 내용이 있다.

"/sbin 디렉토리는 일반적으로 /bin에 있는 바이너리 외에 시스템을 부팅하는데 필수적인 파일을 담고 있다. /usr 디렉토리가 마운트된 후에 실행되는 파일들은 /usr/sbin 디렉토리에 위치해야 한다. 시스템 고유의 시스템 관리 바이너리는 /usr/local/sbin에 위치해야 한다."

최소한 다음 프로그램들은 /sbin에 위치해야 한다.

clock, getty, init, update, mkswap, swapon, swapoff, halt, reboot

shutdown, fdisk, fsck.*, mkfs.*, lilo, arp, ifconfig, route

/usr 디렉토리

/usr 디렉토리는 시스템 전체에 걸쳐 공유되는 파일을 위한 디렉토리이다. /usr 디렉토리는 보통 자신만의 분할 영역을 갖으며, 읽기 전용으로 마운트되어야 한다. 다음의 디렉토리가 /usr의 하위 디렉토리가 되어야 한다.

/usr

|-X11R6

|-bin

|-dict

|-doc

|-etc

|-games

|-include

|-info

|-lib

|-local

|-man

|-sbin

|-share

+-src

X11R6은 X 윈도우 시스템(레드햇 리눅스의 XFree86), bin은 실행파일, doc는 man-page가 아닌 임의의 문서, etc는 시스템 전체에 걸친 설정 파일, include는 C 헤더 파일, info는 GNU info 파일, lib는 라이브러리, man은 매뉴얼 페이지, sbin은 시스템 관리에 사용되는 (/sbin 디렉토리에 없는) 바이너리, src는 소스 코드를 위한 디렉토리이다.

/usr/local 디렉토리

FSSTND에는 다음과 같은 내용이 있다.

"/usr/local 체계는 시스템 관리자가 시스템 고유의 소프트웨어를 설치할 때 사용하기 위한 것이다. 시스템 소프트웨어가 판올림될 때 덮어쓰기로부터 안전하게 유지될 필요가 있다. 이 디렉토리는 기계 내 그룹간에 공유할 수 있으면서 /usr 디렉토리에서 찾을 수 없는 프로그램과 자료를 위해 사용할 수 있다."

/usr/local 디렉토리는 구조적으로 /usr 디렉토리와 비슷하다. 이 디렉토리는 /usr의 하위 디렉토리들의 용도와 비슷한 목적을 가지는 하위 디렉토리 구조를 갖는다.

/usr/local

|-bin

|-doc

|-etc

|-games

|-include

|-info

|-lib

|-man

|-sbin

+-src

/var 디렉토리

FSSTND는 /usr 디렉토리를 읽기 전용으로 마운트하도록 권고하고 있기 때문에, 기록 파일을 작성하거나 스풀 디렉토리나 lock 디렉토리를 필요로 하는 프로그램은 /var 디렉토리를 사용해야 한다. FSSTND는 다음과 같이 적고 있다.

"...변할 수 있는 자료 파일. 이 디렉토리에는 스풀 디렉토리 및 파일, 관리 및 접속기록 자료와 임시로 생성되는 파일이 포함하고 있다."

다음의 디렉토리는 /var의 하위 디렉토리 구조이다 :

/var

|-log

|-catman

|-lib

|-local

|-named

|-nis

|-preserve

|-run

|-lock

|-tmp

+-spool

|-at

|-cron

|-lpd

|-mail

|-mqeue

|-rwho

|-smail

|-uucp

+-news

wtmp와 lastlog와 같은 시스템 기록 파일들은 /var/log 디렉토리에 위치한다. 또한 /var/lib 디렉토리는 RPM 시스템 데이터베이스를 포함하고 있다. 형식화된 매뉴얼 페이지는 /var/catman에 위치하게 되고, lock 파일은 /var/lock 디렉토리에 위치한다. /var/spool 디렉토리는 자료 파일을 저장할 필요가 있는 다양한 시스템을 위한 하위 디렉토리를 가지고 있다.

11.1.2 레드햇 리눅스에서의 /usr/local

레드햇 리눅스에서는 /usr/local 디렉토리의 계획적인 사용은 FSSTND에 명시된 내용과는 약간 다르다. FSSTND에는 /usr/local 디렉토리에는 시스템 소프트웨어 판올림할 때 상업용 소프트웨어의 안전을 위한 것이다. 레드햇 소프트웨어 사의 시스템 판올림 방식은 RPM 시스템과 Glint로 안전하게 수행하므로 상업용 소프트웨어를 보호하기 위해 /usr/local에 위치시킬 필요가 없다. 대신에, 시스템 고유의 소프트웨어를 /usr/local에 위치시킬 것을 권장한다.

예를 들어, beavis라는 시스템으로부터 읽기 전용 NFS로 /usr 디렉토리를 마운트했다고 하자. 만일 설치하고 싶은 패키지나 프로그램이 있는데 beavis에 쓰기가 금지되어 있다면, 그 프로그램들을 /usr/local 디렉토리에 설치해야 한다. 그리고 나중에 beavis의 시스템 관리자에게 /usr 디렉토리에 프로그램을 설치할 것을 납득시키게 된다면, /usr/local 디렉토리에서 제거할 수 있다.

11.2 레드햇 리눅스 파일의 특별한 위치

/var/lib/rpm에 위치한 RPM과 관련된 파일 외에, 레드햇 리눅스의 설정과 작동을 위한 두 가지 다른 특별한 위치가 있다.

control-panel과 그에 관련된 도구들은 /usr/lib/rhs에 위치한다. 여기에 있는 파일은 사용자가 편집할 것이 없다. 대부분 작은 크기의 스크립트, 비트맵, 텍스트 파일이다.

또 다른 위치인 /etc/sysconfig 디렉토리는 설정 정보를 저장하고 있다. 부팅할 때 실행되는 스크립트에서 이 파일을 주로 사용한다. 이 파일은 편집을 할 수 있지만, 적당한 control-panel 도구를 이용하는 것이 좋다.

11.3 사용자, 그룹, 사용자-개별 그룹

사용자와 그룹을 관리하는 것은 지루한 작업으로 인식되어 왔다. 레드햇 리눅스는 사용자와 그룹을 좀 더 쉽게 관리하기 위한 도구와 규정을 지원하기 때문에 보다 유용하다.

사용자와 그룹을 관리하는 가장 쉬운 방법은 제어판의 사용자와 그룹 모듈을 이용하는 것이다(제어판에 대한 것은 9장을 참조하고, 사용자와 그룹 모듈에 대한 것은 9.1절을 참고한다).

또한 명령행에서 사용자를 추가하는데 adduser 명령을 사용할 수 있다.

11.3.1 표준 사용자(기본 사용자)

그림 11.1은 설치 과정에서 설정되는 표준 사용자(기본 사용자)를 나열한 것이다(이들은 /etc/passwd 파일에 필수적인 요소들이다). 이 표의 그룹 ID(GID)는 사용자를 위한 초기 그룹(primary group)이다. 그룹이 어떻게 사용되는지에 대한 자세한 내용은 11.3.3절을 보자.

11.3.2 표준 그룹(기본 그룹)

그림 11.2는 설치 과정에서 설정되는 표준 그룹(기본 그룹)을 나열한 것이다(이 그룹은 /etc/group 파일의 필수적인 요소이다).

11.3.3 사용자-개별 그룹

레드햇 리눅스는 유닉스의 그룹을 더 쉽게 이용하기 위해 사용자 개별 그룹(UPG)을 사용한다. UPG는 표준 유닉스의 그룹을 다루는 방식으로 그룹을 추가하거나 변경하지 않는다. 그룹을 관리하기 위하여 단순히 새로운 그룹을 제공한다. 새로운 사용자를 생성할 때 기본적으로 사용자는 자신만의 유일한 그룹을 가지게 된다. 그 유형은 다음과 같다.

사용자 개별 그룹

각각의 사용자는 자신이 그 구성원이 되는 초기 그룹을 갖는다.

umask=002

기존의 유닉스 umask 값은 다른 사용자나 user 초기 그룹의 구성원이 사용자의 파일을 변경하지 못하도록 022로 설정되어 있다. 모든 사용자는 자신만의 개별적인 그룹을 갖고 있기 때문에 기존 유닉스의 "그룹 보호" 기능은 필요 없다. 002의 umask값은 사용자들이 다른 사용자의 파일들을 변경할 수 없도록 할 것이다. umask 값은 /etc/profile에 설정되어 있다.

SGID bit on 디렉토리

만일 디렉토리에 (chmod g+s directory로) SGID를 설정한다면, 그 디렉토리에서 생성되는 파일은 그룹이 디렉토리의 그룹에 맞춰진다.

대부분의 사이트들은 각각의 프로젝트에 따라 그룹을 생성해 사람을 필요한 그룹에 넣고 싶어할 것이다. 파일이 생성되면 사용자가 속한 초기 그룹에 의해 소유되기 때문에 파일 관리가 어려웠다. 한 사람이 여러 프로젝트를 수행한다면, 그 프로젝트와 관련된, 그룹에 의해 소유되는 파일을 만드는 것은 어렵게 된다. 그룹 관리를 매우 간단하게 해주는 UPG 체제에서는 프로젝트에 관련된 파일을 자동으로 그룹에 할당한다

많은 사람들이 devel 디렉토리에서 파일들을 편집하는 devel이라는 큰 프로젝트가 있다고 하자. devel 그룹을 만들고, devel이라는 chgrp를 이용해 그룹 권한을 주고, 모든 devel 사용자들을 devel 그룹에 추가해보자. 이제 모든 devel 사용자들은 그 디렉토리에서 그룹에 속한 파일을 편집하고 새 파일을 생성할 수 있고, 이들 파일은 항상 devel 그룹을 유지하게 될 것이다. 따라서 파일들은 devel 사용자들에 의해 언제나 편집 가능하다.

만일 예로 든 devel처럼 여러 가지 프로젝트를 수행하고, 그 프로젝트를 수행하는 사용자들이 시스템에 있다면, 이 사용자들은 프로젝트를 옮겨갈 때마다 결코 그들의 umask값이나 그룹을 변경하려 하지 않을 것이다. 각각의 주요 프로젝트 디렉토리에 설정된 SGID 비트는 적절한 그룹을 "선택"할 것이다.

사용자의 홈 디렉토리는 사용자와 사용자-개별 그룹에 소유권이 있으므로 홈 디렉토리에 SGID 비트를 설정하는 것이 안전하다. 그러나 파일은 기본적으로 사용자의 초기 그룹의 소유권한을 갖게 생성되므로 SGID 비트는 없어도 좋을 것이다.

사용자-개별 그룹의 원리

UPG 체제는 새로운 기능이기 때문에, 많은 사람들이 궁금해하고 왜 필요한 것인지 알고 싶어한다. 다음은 UPG의 원리이다.

둁 /usr/lib/emacs/site-lisp 디렉토리에서 작업하는 사람들의 그룹을 만들고자 한다면 그 디렉토리에서 작업하는 사람들 중에 몇몇 사람들은 믿을 수가 있겠지만, 모든 사람을 신뢰할 수는 없다.

둁 그러므로 다음과 같이 입력할 것이다:

chown -R root.emacs /usr/lib/emacs/site-lisp

그리고 적당한 사용자들을 그룹에 추가하면 된다.

둁 사용자들에게 파일을 생성할 수 있도록 다음과 같이 권한을 줄 것이다:

chmod 775 /usr/lib/emacs/site-lisp

둁 사용자가 새 파일을 생성할 때 그 파일은 사용자의 기본 그룹(보통 users)에 포함된 다. 그렇게 되지 않게 하기 위해 다음과 같이 한다.

chmod 2775 /usr/lib/emacs/site-lisp

위의 입력은 디렉토리의 모든 것을 "emacs" 그룹에 속하도록 만든다.

둁 하지만 emacs 그룹의 다른 사용자들이 파일을 편집하려면 664 모드가 되어야 한다. 그렇게 하기 위해서 기본 umask 값을 002로 한다. 기본 그룹이 "user"인 것을 제외하고는 모든 것이 순조롭게 되었다. 당신의 홈 디렉토리에 생성되는 모든 파일은 "users" 그룹에 속한 모든 사용자(보통 전부가 users에 속해 있다)에 의해 쓰기가 허용된다.

둁 위의 문제점을 해결하기 위해서는, 개개의 사용자가 독자적인 그룹을 기본 그룹으로 갖도록 만들어야 한다.

이런 점에서 umask를 002로 맞추고, 모든 사용자에게 개인 기본그룹을 설정함으로써 어떤 비결 없이 쉽게 사용자에게 그룹을 설정할 수 있다. 그룹을 만들고 사용자를 더하고, 그 그룹의 디렉토리에 대해서 소유권과 실행 모드를 설정하기만 하면 된다.

11.4 PAM을 이용한 사용자 인증

사용자에게 특정 권한을 사용할 수 있도록 하는 종류의 프로그램은 사용자 인증 기능을 필요로 한다. 시스템에 로그인할 때 사용자 ID와 암호를 입력하면, 로그인 프로세스는 입력한 사용자 ID에 대해 실제 사용자가 맞는지를 확인하기 위해 로그인을 인증하기 위한 것을 사용한다. 암호 외의 다른 형식의 인증도 가능하다. 그리고 일반적인 유닉스에서 사용하는 암호저장 방식이 아닌 다른 암호 저장방식에 대한 것도 가능하다.

교체가능 인증 모듈을 의미하는 PAM은 인증에 대한 프로그램에 대해 새로운 버전이 나올 때마다 컴파일 할 필요 없이 인증 방식에 대한 정책을 바꿀 수 있는 기능을 시스템 관리자에게 제공한다. PAM을 사용하면 설정파일을 변경하여 필요한 인증 모듈을 프로그램에 삽입함으로써 인증 방식을 바꿀 수 있다.

대부분의 일반 사용자들은 이 설정 파일을 건드릴 필요가 없다. 인증을 필요로 하는 프로그램을 설치하기 위해서 RPM을 사용하면, 이 프로그램들은 기본적으로 일반적인 암호 인증 방식을 사용하도록 설정된다. 그러나 이 설정을 변경하고 싶으면 설정파일에 대한 이해가 필요하다.

11.4.1 모듈

PAM 표준에 의해 정의된 4종류의 모듈이 있다. 인증 모듈(auth module)은 인증을 수행하기 위한 암호 요청이나, 그룹의 구성원이나, 커베로스 티켓 등과 같은 자격 인증을 설정하는 기능을 수행한다. 계정 모듈(account module)은 사용자 계정의 유효 사용기간, 로그인 가능 시간 등을 검사한다. 암호 모듈(password module)은 암호를 설정하거나 변경하는데 사용된다. 세션 모듈(session module)은 일단 인증된 사용자가 사용자 계정에서 일을 수행하기 위해 하는 모든 세션들이 가능한 것인지 확인하는데 사용된다. 예를 들어 사용자의 홈 디렉토리를 만들거나 전자우편 상자를 만드는 일 같은 것을 말한다.

이러한 모듈은 중첩해서 사용할 수 있다. 그래서 보통 다중 모듈에 사용된다. 예를 들어 rlogin은 보통 적어도 두 가지의 인증 방법을 사용한다. rhosts 인증이 성공하면, 그것으로 연결을 허가한다. 만약 이것이 실패하면 표준 암호 인증이 다시 한번 인증을 시도한다.

새로운 모듈이 언제라도 추가될 수 있다. PAM을 사용하는 응용 프로그램은 이러한 것을 사용하는 것인 가능하다. 예를 들어 일회용 암호 인증 시스템을 가지고 있다고 하면, 이것을 지원하는 모듈을 만들 수 있다( 모듈을 만들기 위한 문서 파일이 시스템에 포함되어 있다). PAM을 지원하는 프로그램은 이러한 새로운 모듈을 사용할 수 있다. 그리고 새로 컴파일 하거나 어떤 방법으로든 프로그램을 변경할 필요 없이 사용이 가능하다.

11.4.2 서비스

PAM을 사용하는 프로그램들은 각각 그 자신만의 서비스 이름을 정의한다. 예를 들어 로그인 프로그램은 서비스 종류를 login이라고 정의하고, ftpd는 서비스 종류를 ftp로 정의한다. 보통 서비스 종류는 서비스에 접근하는데 사용되는 프로그램의 이름이다, 아니면 서비스를 제공하는 프로그램의 이름이 쓰이기도 한다.

11.4.3 설정 파일

/etc/pam.d 디렉토리는 모든 PAM을 사용하는 프로그램을 설정하는데 사용된다 (이전의 PAM 버전에서는 /etc/pam.conf 파일을 사용했다. /etc/pam.d 디렉토리에 해당 파일이 없다면 이전 방식처럼, /etc/pam.conf가 읽혀진다. 이것은 지금은 사용하지 말자는 쪽으로 바뀌었다). 각각의 프로그램은 자신의 설정 파일을 가진다. 이러한 설정 파일의 예를 보면 다음과 같다.

#%PAM-1.0

auth required /lib/security/pam_securetty.so

auth required /lib/security/pam_pwdb.so shadow nullok

auth required /lib/security/pam_nologin.so

account required /lib/security/pam_pwdb.so

password required /lib/security/pam_cracklib.so

password required /lib/security/pam_pwdb.so shadow nullok use_authtok

session required /lib/security/pam_pwdb.so

첫 번째 줄은 설명문이다. #로 시작되는 줄은 모두 설명문이다. 그 다음의 세 줄은 로그인 인증에 대해 사용하는 모듈을 쌓아 놓은 것이다. 그 중 첫 줄은 사용자가 root로 로그인을 시도한다면 /etc/security파일이 있을 경우 이 파일에 기록된 tty 장치를 사용하는지를 검사한다. 그 다음 줄은 로그인하는 사용자에게 암호를 요청하고 이것을 검사하는 부분이다. 세 번째 줄은 /etc/nologin 파일이 있을 경우 이 내용을 참고하여 파일 내에 기록된 사용자는 root를 제외하고 로그인을 거부한다.

만약 첫 번째 모듈이 실패하더라도 세 가지 모듈이 모두 작동하여 검사한다는 사실에 주의하라. 이것은 사용자의 인증이 거부당했을 때 어디서 인증이 실패했는지를 알려주지 않도록 고안된 보안 정책이다. 왜냐하면 거부된 이유를 알려주는 것은 인증을 보다 쉽게 깨뜨릴 수 있게 만들어 주기 때문이다. 이렇게 required로 설정된 것을 requisite로 바꿀 수도 있다. 이 설정은 어떤 인증 모듈이 인증에 실패하면 다른 모듈을 동작시키지 않고 바로 인증 실패를 되돌려준다.

5번째 줄은 사용자 계정 관리에 관계된 것이다. 예를 들어 쉐도우 암호를 사용하도록 설정한 경우, pam_pwdb.so 모듈은 사용자의 사용기간과 사용자의 암호의 유효기간을 검사할 것이다.

여섯 번째 줄은 로그인 프로그램이 암호를 교체할 때(예를 들어 쉐도우 암호의 유효기간이 지나서 인증 모듈이 암호를 교체를 결정했을 경우) pam_pwdb.so를 사용하도록 설정한 것이다.

마지막 줄은 세션을 관리하는 경우에 사용하는 모듈을 pam_pwdb.so로 설정한 것이다. 현재 설정은 아무런 동작을 하지 않는다. 이것은 다중모듈로 설정하거나 새로운 모듈을 쓰도록 설정할 수 있다.

각각의 설정파일에 있는 줄의 위치에 따른 순서에 주의할 필요가 있다. required로 설정된 모듈의 경우는 각 모듈간에 우선 순위가 차이가 없다. 여러 개의 required로 설정된 모듈은 각 모듈 중 어느 하나가 인증에 실패하더라도 다른 모듈이 인증과정을 계속 수행한다. 그러나, 단 하나의 모듈만 실패해도 전체의 인증 과정이 실패한 것으로 간주된다. optional로 설정하는 경우는 거의 드물며 기본 설정으로는 절대로 쓰지 않는 설정이다. sufficient나 requisite의 경우 줄의 위치에 따른 순서가 중요하다.

rlogin을 위한 PAM인증 설정 파일을 보자.

auth required /lib/security/pam_securetty.so

auth sufficient /lib/security/pam_rhosts_auth.so

auth required /lib/security/pam_pwdb.so shadow nullok

auth required /lib/security/pam_nologin.so

로그인 인증 설정파일과 비슷해 보인다. 그러나 추가적인 모듈이 에 대한 설정이 추가되어있고, 인증 모듈의 순서가 좀 다르게 설정되어 있다.

첫 줄의 pam_securitty.so는 보안상 안전하지 못한 터미널로부터의 root 로그인을 차단한다. 이것은 root 로 rlogin을 시도하는 것을 효과적으로 차단한다. 만약 이것을 가능하게 하고 싶으면 이 줄을 지워 버리기만 하면 된다. 그러나 이러한 설정은 인트라넷으로만 되어 있는 네트워크나 좋은 방화벽 시스템이 없으면 권하고 싶지 않은 설정이다.

두 번째 둘의 pam_nologin.so 모듈은 위에서 설명했듯이 /etc/nologin파일을 검사한다.

세 번째 줄은 pam_rhosts_auth.so 모듈이 사용자에 대한 인증이 성공한 경우 PAM은 PAM을 호출한 프로그램에 다른 모듈의 추가적인 인증 과정 없이 인증 성공을 반환한다. 이 모듈이 sufficient로 설정되어 있어서 인증에 실패한 경우 이 모듈의 실패가 전체 인증과정에는 영향을 미치지 않는다.

마지막 줄은 pam_rhosts_auth.so 모듈이 실패한 경우에 그 다음 순서로 동작하는 인증 모듈로 일반적인 암호 인증과정을 수행한다.

11.4.4 쉐도우 암호

레드햇 리눅스에서는 쉐도우 암호에 대한 지원이 많이 변화했다. 이 부분은 레드햇 리눅스 사용 설명서 11.5절에 자세히 설명이 되어있다.

pam_pwdb.so 모듈은 자동적으로 사용자가 쉐도우 암호로 설정된 것을 인식하며 필요한 조작을 수행한다.

11.4.5 추가적인 정보

지금까지의 설명은 PAM에 대한 간단한 소개정도에 지나지 않는다. 좀더 자세한 정보는 시스템의 /usr/doc/pam*디렉토리에 있는데 여기에는 관리자 설명서, 모듈 개발자 설명서. 응용 프로그램 개발자 설명서, PAM 표준 기술 문서인 DCE-RFC 86.0 등이 포함되어 있다. 추가적으로 레드햇 웹사이트의 다음의 URL에서 정보를 얻을 수 있다.

http://www.redhat.com/linux-info/pam/

11.5 쉐도우 프로그램

쉐도우 암호에 대한 지원이 레드햇 리눅스 5.2에서는 크게 개선되었다. 쉐도우 암호는 암호화된 암호를 다른 파일(/etc/passwd 에서 보통 찾을 수 있다)에 옮기는 방법을 사용하여 암호에 대한 접근을 제한함으로써 시스템의 보안성을 향상시키는 방법이다. shadow-utils 패키지 안에 이를 지원하는 프로그램들이 포함되어 있다.

둁 일반 암호와 쉐도우 암호간의 변환 기능( pwconv, pwunconv )

둁 쉐도우 파일과 관련된 암호, 그룹에 대한 인증 ( pwck, grpch )

둁 사용자 계정을 추가하거나 삭제 변경시키는 유닉스 업계 표준적인 방법의 지원

( useradd, usermod, userdel )

둁 사용자 그룹을 추가하거나 삭제 변경시키는 유닉스 업계 표준적인 방법의 지원

( groupadd, groupmod, groupdel )

둁 /etc/passwd 파일을 관리하는 유닉스 업계 표준적인 방법의 지원( gpasswd )

※주의 사항: 이 프로그램들과 관련해서 몇 가지 알아두어야 할 사항이 있다.

둁 이 프로그램은 대부분 쉐도우 암호 사용 여부에 관계없이 잘 동작한다.

둁 이 프로그램들은 레드햇 리눅스 시스템의 사용자-개별 그룹 정책을 지원하기 위해 조금씩 변경되었다. 변경사항은 useradd 매뉴얼 페이지를 참고하기 바란다. 사용자-개별 그룹에 대한 보다 자세한 설명은 11.3.3장을 참고하기 바란다.

둁 adduser 스크립트는 /usr/sbin/useradd에 대한 심볼릭 링크로 대체되었다.

11.6 맞춤 커널 컴파일하기

리눅스 커널 2.0.x에서 모듈 기능은 커널을 컴파일 하는 데 있어서 중대한 변화를 가져왔다. 이전에는 사용자가 필요로 하는 하드웨어 지원이나 파일 시스템 지원 같은 요소들을 원한다면 커널이 이것을 지원하도록 컴파일을 해야만 했다. 어떤 하드웨어 사양의 설정에서는 커널의 크기가 빨리 상황에 꼭 맞는 상태가 될 수 가 있었다. 그러나 그리 자주 사용하지 않는 구성요소에 대한 지원을 하도록 컴파일 하면 이것은 시스템 자원을 낭비하는 결과를 가져왔다. 커널 2.0.x의 편리한 기능은 어떤 하드웨어 구동기 구성 요소와 파일 시스템이 그리 자주 쓰이지 않는 경우라면 구동기 모듈을 필요한 때에만 시스템 주 기억 장치에 적재할 수 있다는 것이다. 커널 모듈을 다루는 데에 대한 자세한 설명은 8.2절을 참고하기 바란다.

리눅스에 새로 접하는 많은 사람들이 자주 질문하는 것 중의 하나가 "왜 내 시스템 상황에 맞는 커널을 만들어야 하는가?" 하는 것이다. 커널 모듈 사용에 있어서의 장점 때문에 이 질문에 대한 정확한 대답은 "자신의 시스템에 맞는 커널을 만들어야 할 이유를 모른다면 그렇게 하지 않으면 된다." 자신의 시스템에 맞는 커널을 만들어야 할 특별한 이유를 가지고 있지 않으면 11.7장으로 건너뛴다.

11.6.1 모듈화된 커널 컴파일하기

여기서는 커널 모듈을 통하여 유연성과 기능성의 장점을 활용하기 위해 필요한 지식을 설명한다. 모듈화의 장점을 활용할 필요가 없다면 11.6.3절에서 설명하는 단일 집적 커널로 만드는 경우와의 차이점을 읽어보기 바란다. 여기서는 커널 소스와 헤더 패키지가 미리 설치되어 있다고 가정하며 다음에 설명하는 명령들은 /usr/src/linux 디렉토리에서 실행되는 것으로 가정한다.

소스에서 커널을 만드는데 있어서 시스템의 사양에 맞도록 하는 조건에서 시작하는 것이 중요하다. 그래서 make mrproper 명령으로 시작하는 것이 필요하다. 이것은 커널 소스 디렉토리 곳곳에 흩어져 있는 이전에 커널을 만들 때 남아 있던 설정파일을 지워버린다. 사용하는 시스템에 포함시킬 구성요소가 무엇인지를 지정하는 설정파일을 만들어야 한다. 이것은 시스템 상황과 개인 취향에 따라 커널을 설정하는 방법을 다음 세 가지 중에 하나를 선택할 수 있다.

둁 make config - 텍스트 방식의 상호 대화형 프로그램으로 구성요소에 대해서 Y(yes), N(no), M(module)의 세 가지로 답할 수 있다.

둁 make menuconfig - 텍스트 메뉴 방식의 프로그램으로 구성요소는 메뉴의 종류에 따라 분류되어 나타난다. 레드햇 리눅스의 설치방식과 비슷한 방법으로 구성요소를 선택할 수 있다. 포함하기를 원하는 구성요소를 Y(yes), N(no), M(module)의 세 가지 중의 하나로 토글시킬 수 있다.

둁 make xconfig - X 윈도우용 프로그램으로 구성 요소를 각각의 단계에 따라 나타나서 나열되며 마우스를 사용하여 선택할 수 있다. 역시 Y(yes), N(no), M(module)의 세 가지 중의 하나로 토글시킬 수 있다.

※참고사항: 커널 모듈과 kerneld를 사용하기 위해서는 kerneld support 항목과 module version (CONFIG_MODVERSIONS) support 항목에서 Yes를 선택해야 한다.

※참고사항: Cyrix나 AMD에서 만들어진 Intel 프로세서 호환 칩의 경우 설정에 있어서 프로세서 종류를 386으로 선택해야 한다.

이전에 위에서 설명한 세 가지 설정 방법으로 만들어진 설정 파일(/usr/sr/linux/.config)이 있을 경우 다시 커널을 만들 때 이 설정 파일을 그대로 사용한다고 한다면 make mrproper과 make config 명령을 생략할 수 있다. 그 다음에 필요한 명령은 make dep와 make clean인데 이것으로 소스로부터 커널을 컴파일할 준비 작업이 모두 끝났다고 할 수 있다.

둁 make boot 명령으로 커널을 만든다.

둁 make modules 명령으로 설정한 모듈을 만든다.

둁 다음의 명령으로 이전에 사용하던 커널에서 사용하던 모듈들을 백업을 받는다.

rm -rf /lib/modules/2.0.29-old

mv /lib/modules/2.0.29 /lib/modules/2.0.29-old

물론 커널 버전이 판올림 됐다면 2.0.29의 번호는 현재 사용하는 커널 번호로 대체된다는 것을 잊지 말자.

둁 make modules_install 명령으로 새로운 모듈을 설치한다.

만약 SCSI가 장착된 상황에서 SCSI 하드웨어 구동기를 모듈로 만든다면 새로운 initrd 이미지를 만들어야 한다 ( 11.6.2절 참고. 몇 가지 이유에서 맞춤 커널을 만들 때 SCSI 구동기를 모듈로 만들어야 할 때가 생긴다).

새로운 커널에서 발생할 지 모르는 오류를 대비하여 이전 커널을 보관하고 있어야 한다. 커널을 LILO 메뉴에 추가하는 것은 /boot 디렉토리에서 원래의 커널을 새로운 이름으로 바꾸는 것만큼 쉽다. 새로운 커널을 /boot 디렉토리에 복사를 하고 /etc/lilo.conf에서 추가 설정을 몇 줄 추가한 다음 /sbin/lilo를 실행시키면 된다. 아래의 내용을 레드햇 리눅스가 설치될 때 기본적으로 생기는 /etc/lilo.conf의 내용이다.

boot=/dev/hda

map=/boot/map

install=/boot/boot.b

prompt

timeout=100

image=/boot/vmlinuz

label=linux

root=/dev/hda1

read-only

이제는 /etc/lilo.conf의 내용을 바꾸어야 한다. 새로운 initrd 이미지를 만들었다면 LILO에게 이것을 사용한다고 알려줘야 한다. 아래의 예에서 /etc/lilo.conf의 내용에 네 줄을 마지막에 추가하였다. 이제 원래의 커널을 다음과 같이 /boot/vmlinuz을 /boot/vmlinuz.old로 이름을 바꾼다. 그리고 initrd 이미지에 관계된 설정을 새로운 커널에 대해서 추가한다.

boot=/dev/hda

map=/boot/map

install=/boot/boot.b

prompt

timeout=100

image=/boot/vmlinuz

label=linux

initrd=/boot/initrd

root=/dev/hda1

read-only

image=/boot/vmlinuz.old

label=old

root=/dev/hda1

read-only

이제 시스템을 부팅하고 나타나는 LILO boot:에서 (Tab)를 누르면 두 가지 선택할 수 있는 목록이 나타날 것이다.

LILO boot:

linux old

새로운 커널로 부팅하기 위해서는 간단히 Enter 글쇠를 누르거나 LILO가 대기 시간을 종료할 때까지 기다린다. 이전의 old 커널로 부팅하려면 old라고 입력하고 Enter 글쇠를 누른다.

이 과정들을 요약해 보면

둁 mv /boot/vmlinuz boot/vmlinuz.old

둁 cp /usr/src/linux/arch/i386/boot/zImage /boot/vmlinuz

둁 edit /etc/lilo.conf

둁 /sbin/lilo를 실행한다.

이 과정을 마치고 컴퓨터를 다시 부팅해서 새로운 커널을 시험해 볼 수 있다. 그리고 부팅 시에 나타나는 메시지를 검사하여 하드웨어를 제대로 인식했는지 확인할 수 있다.

11.6.2 initrd 이미지를 만들기

부팅할 경우에 SCSI 모듈을 주 기억 장치에 적재하기 위해서는 initrd 이미지가 필요하다. /sbin/mkinitrd 라는 쉘 스크립트가 다음의 조건이 만족할 때 새로운 커널에 맞는 initrd 이미지를 만들 수 있다.

둁 루프백 블록 장치가 커널에서 사용 가능하도록 컴파일이 되어야 한다.

둁 /etc/conf.modules 파일에 SCSI 어댑터 모듈에 대한 설정이 필요하다. 예를 들면 다음과 같다.

alias scsi_hostadatper BusLogic

새로운 initrd 이미지를 만들기 위해서는 /sbin/mkinitrd 명령을 다음과 같은 인자를 주어 실행한다.

/sbin/mkinitrd /boot/newinitrd-image 2.0.12

여기서 /boot/newinitrd-image는 새로운 이미지에서 사용될 파일이다. 그리고 2.0.12는 initrd 이미지에서 사용되는 커널의 모듈 버전이다. ( /lib/modules에 있는 ) 이 버전은 현재 커널 버전일 필요는 없다.

11.6.3 단일 집적 커널 만들기

단일 집적 커널을 만들기 위해서는 모듈 커널을 만드는 경우와 몇 가지 사항을 제외하고는 동일한 과정을 거친다.

둁 커널을 설정할 때 구성요소에 대한 선택은 Yes 이거나 No 둘 중에 하나로만 선택해야 한다 ( Module로 선택하면 되지 않는다).

둁 다음의 과정을 생략한다.

make modules

make modules_install

둁 /etc/rc.d/rc.sysinit파일에서 depmod -a 라고 되어있는 줄의 맨 앞에 #을 붙여 주석문으로 만든다.

11.7 Sendmail

sendmail의 기본 설정 파일인 sendmail.cf는 /etc 에 설치된다. 기본적으로 설치되는 설정파일은 대부분의 SMTP 전자우편 프로토콜을 사용하는 네트워크 호스트에서만 동작하도록 설정되어 있다. UUCP 전자우편 프로토콜을 사용하는 경우에는 동작하지 않는다. UUCP전자우편 프로토콜로 동작하도록 하기 위해서는 새로운 sendmail.cf가 필요하다. 새로운 sendmail.cf를 만들기 위해선 m4 패키지와 sendmail 소스 패키지가 필요하다. sendmail 설정파일에 대한 자세한 정보는 sendmail 소스 패키지 안에 있는 README 파일을 읽어보기 바란다. 또 다른 참고 자료로는 오렐리 출판사가 발간하고 Bryan Costales가 저술한 sendmail이라는 서적을 참고하기 바란다.

sendmail에 대한 가장 일반적인 설정은 하나의 로컬 LAN상에 연결된 모든 컴퓨터에 대한 전자우편 게이트웨이로 하나의 컴퓨터를 동작시키는 것이다. 예를 들어 레드햇 소프트웨어의 경우 레드햇 사 내부의 모든 전자우편을 처리하는 mail.redhat.com이라는 호스트를 가지고 있다. 이 전자우편 서버에서는 네트워크에 대한 전자우편을 다루기 위해 /etc/sendmail.cw라는 설정 파일에 다음과 같은 설정이 필요하다.

# sendmail.cw - include all aliases for your machine

# here.

torgo.redhat.com

poodle.redhat.com

devel.redhat.com

그리고 여기에 나열된 torgo, poodle, devel의 컴퓨터에서는 자신들의 시스템에서 보낸 전자우편을 mail.redhat.com에서 보낸 것처럼 가장하기 위한 설정이 필요하다. 그리고 redhat.com으로 외부에서 보낸 전자우편을 자신들을 시스템에서 받아보기 위한 설정이 필요한데 그 설정은 다음과 같다. 이 내용들은 /etc/sendmail.cf 설정파일에서 설정한다.

# who I send unqualified names to

# (null means deliver locally)

DRmail.redhat.com

# who gets all local email traffic

DHmail.redhat.com

# who I masquerade as (null for no masquerading)

DMredhat.com

이러한 종류의 설정에서는 보내는 전자 우편은 redhat.com으로부터 보낸 것처럼 나타나며 torgo.redhat.com이나 같은 도메인의 다른 시스템으로 가는 전자 우편은 모두 mail.redhat.com으로 배달 된다.

지금 사용하는 시스템에서 보내는 전자 우편을 다른 시스템에서 보낸 전자 우편에서 보낸 것처럼 가장 하도록 설정했다면 자신의 시스템에서 보내지는 모든 전자 우편이 가장되도록 만들어진 시스템으로 보내진다. 예를 들면 다음과 같은 방식이 된다. 위에서 설명한 대로 cron 데몬에 의해 root@poodle.redhat.com으로 보내지는 주기적인 기록파일은 root@mail.redhat.com로 보내진다.

11.8 네트워크 서비스에 대한 접근 제어

보안 측면에서 모든 네트워크 서비스는 TCP wrapper라고 불리는 보안 프로그램에 의해 관리된다. 보호를 받는 서비스는 /etc/inet.conf 파일에 /usr/sbin/tcpd로 지정되어 나열된다. tcpd는 요청한 쪽의 위치와 /etc/hosts.allow파일과 /etc/hosts.deny 설정에 기초해서 서비스를 접근하는 것을 거부하거나, 허가한다. 레드햇 리눅스는 기본을 설정하는 것이 모든 서비스 요청을 허가한다. 서비스를 불가능하게 하거나 제한하려면 /etc/hosts.allow를 편집하면 된다. 다음의 /etc/hosts.allow의 예제이다.

ALL: redhat.com .redhat.com

in.talkd: ALL

in.ntalkd: ALL

in.fingerd: ALL

in.ftpd: ALL

이 설정은 redhat.com과 *.redhat.com으로부터 오는 모든 서비스 요청을 허가한다. 이것은 또한 talk, finger, ftp에 대해서 모든 컴퓨터로부터 오는 서비스를 허가한다.

tcpd는 /etc/hosts.allow와 /etc/hosts.deny의 조합을 사용하여 보다 지능적인 접근 제어를 할 수 있다. 좀더 자세한 내용은 tcpd(8)과 hosts_access(5)에 대한 맨 페이지를 참고하기 바란다.

11.9 익명 ftp

익명 ftp를 설정하는 것은 간단하다. 설정하는 데 필요한 사항은 anon-ftp rpm 패키지를 설치하면 된다 (이 패키지는 레드햇 리눅스를 설치할 때 설치하면 된다). 일단 설치가 끝나면 동작시키는 데 필요한 작업을 모두 끝내고 동작시킨다.

다음의 몇 개의 파일은 ftp 서버를 설정하는 데 필요한 파일들이다.

둁 /etc/ftpaccess : 이 파일은 사용자의 FTP 서버에 대한 접근제어를 정의하는 것이다. 여기에서 정의해야할 사항 중 몇 가지는 서로 다른 호스트로부터의 접근제어를 하는 논리적인 그룹을 설정하는 것, 동시 FTP 연결의 숫자를 제한하는 것, 로그인 전환의 설정 등이 있다. ftpaccess에 대한 매뉴얼 페이지를 보면 자세한 사항이 나와있다.

둁 /etc/ftphosts : 이 파일은 다양한 네트워크상의 호스트로부터 연결에 대한 접근 제어를 하는 경우에 대한 설정 파일이다.

둁 /etc/ftpusers : 이 파일은 시스템에 대해 ftp로 접속이 거부되는 사용자들의 목록이다. 예를 들어 root는 /etc/ftpusers에서 기본적으로 기록되어 있다. 이것은 ftp로는 root 권한으로 접속할 수 없다는 것을 의미한다. 이것은 아주 좋은 보안 수단이다. 그러나 어떤 관리자들을 이 파일에서 root를 삭제하기를 좋아한다.

11.10 NFS 설정

NFS는 네트워크 파일 시스템을 의미한다. 그리고 이것은 네트워크를 통해 다른 네트워크에 연결된 시스템의 파일 시스템을 현재 사용자가 사용하는 시스템의 파일 시스템에 접근하듯이 네트워크를 통해서 공유하는 방법이다. 리눅스는 NFS 서버로서도 NFS 클라이언트로 사용할 수 있다. 이것은 네트워크 상의 다른 시스템에 대해 사용자가 사용하고 있는 시스템의 자료를 공개할 수 있고 다른 시스템의 공개된 자료를 마운트할 수 있다는 것을 의미한다.

11.10.1 NFS 파일 시스템 마운트

다른 시스템의 공개된 NFS 파일 시스템을 마운트하기 위해서는 mount 명령을 사용한다.

mkdir /mnt/local # 이 부분은 /mnt/local이 존재하지 않을 때만 필요한 명령이다.

mount bigdog:/mnt/export /mnt/local

이 명령에서 bigdog은 NFS를 서비스해 주는 호스트이다. /mnt/export는 bigdog이 공개한 파일 시스템 부분이다. /mnt/local은 사용자가 마운트하려는 내용에 대한 사용자 시스템의 마운트 지점이다. mount 명령을 사용한 다음에는 (물론 bigdog에 대한 올바른 허가권한이 있어야 한다) ls /mnt/local 명령을 통해 bigdog상의 /mnt/export 에 있는 파일의 목록을 얻게 된다.

11.10.2 NFS 파일 시스템 공개하기

NFS서버로 동작시킬 때 전체 파일 시스템 중 어느 부분을 공개할 것인가에 대해 설정하는 파일이 /etc/exports 파일이다. 이 파일의 형식은

디렉토리 호스트이름(선택 사항)

(선택 사항) 안에 들어가는 내용은 추가적인 선택 사항으로 생략해도 무관하다. 예를 들면

/mnt/export speedy.redhat.com

이런 설정은 speedy.redhat.com의 /mnt/export 에 있는 내용을 마운트할 수 있다는 의미이다.

하지만

/mnt/export speedy.redhat.com(ro)

이 설정 역시 위와 동일하게 마운트가 가능하지만 차이점은 /mnt/export의 내용을 읽기 전용으로 마운트할 수 있다는 점이다.

위의 설정 파일을 바꿔줄 때마다. NFS 데몬에게 새로운 설정 정보를 알려줄 필요가 있다. 간단한 방법 중에 하나는 데몬을 정지 시켰다가 다시 실행시키는 것이다.

/etc/rc.d/init.d/nfs stop

/etc/rc.d/init.d/nfs start

또 다른 방법은

killall -HUP rpc.nfsd rpc.mountd

좀더 자세한 정보는 nfsd(8), mountd(8), exports(5)에 대한 맨 페이지를 살펴보기 바란다. 또 오렐리 출판사에서 출판된 Hal stern이 쓴 managing NFS and NIS Service를 참고하기 바란다.

11.11 부팅 과정, 초기화, 시스템 종료

이 장의 내용은 레드햇 리눅스 시스템이 부팅하거나 시스템을 종료할 때 어떤 일이 일어나는지에 대한 정보의 설명이다. 우선 /etc/sysconfig 디렉토리에 있는 내용부터 살펴보자.

11.11.1 Sysconfig 정보

지금부터 설명하는 내용은 /etc/sysconfig 디렉토리에 있는 다양한 파일에 대한 개략적인 정보와 기능, 내용 등의 정보이다.

/etc/sysconfig에 있는 파일들

/etc/sysconfig에서 있는 파일들은 다음과 같다.

둁 /etc/sysconfig/clock

둁 /etc/sysconfig/keyboard

둁 /etc/sysconfig/mouse

둁 /etc/sysconfig/network

둁 /etc/sysconfig/pcmcia

둁 /etc/sysconfig/amd

둁 /etc/sysconfig/tape

각각의 파일을 살펴보면

/etc/sysconfig/clock - 이 파일은 시스템의 하드웨어 시계로부터 자료를 읽어들여 이것을 어떤 식으로 변환해서 시스템에서 사용할 것이냐를 설정한다. 이전 버전의 레드햇 리눅스에서는 다음과 같은 값이 사용된다 (이것은 평이 그리 좋지 않았다).

둁 CLOCKMODE=mode, mode에 쓰일 수 있는 값은 다음과 같다.

GMT - 시스템 시간이 그리니치 시간을 기준으로 하는 UTC로 설정된 것으로 인식한다.

ARC - 알파 CPU를 가진 시스템에서만 유효한 설정으로 ARC 콘솔의 42년 단위로 색인하여 시간을 변환하는 방법이다.

현재의 설정 값은 다음과 같다.

둁 UTC=boolean, boolean에 들어 갈 수 있는 값은 다음과 같다.

true - 시스템 시계가 UTC로 설정된 것으로 인식한다. 다른 값의 경우 지역시간으로 설정된 것으로 인식한다.

둁 ARC=boolean, boolean에 들어 갈 수 있는 값은 다음과 같다.

true - 알파 CPU를 가진 시스템에서만 유효한 설정으로 ARC 콘솔의 42년 단위로 색인하여 시간을 변환하는 방법이다. 다른 값으로 설정된 경우 유닉스 일반적인 시간 설정 방식으로 인식한다.

/etc/sysconfig/keyboard - 이 파일은 키보드에 대한 설정을 제어하는 파일이다. 다음과 같은 값이 사용된다.

둁 KEYTABLE=file, 여기서 file에 들어갈 수 있는 내용은 예를 들면 다음과 같다.

KEYTABLE="/usr/lib/kbd/keytables/us.map"

/etc/sysconfig/mouse - 사용할 수 있는 마우스에 대한 정보를 지정하는데 사용되는 파일이다. 다음과 같은 값이 사용된다.

둁 MOUSETYPE=type, type은 다음과 같은 값이 사용된다.

- microsoft -- 마이크로소프트 마우스

- mouseman -- 마우스맨 마우스

- mousesystems -- 마우스 시스템 마우스

- ps/2 -- PS/2 마우스

- msbm -- 마이크로소프트 버스 마우스

- logibm -- 로지텍 버스 마우스

- atibm -- ATI 버스 마우스

- logitech -- 로지텍 마우스

- mmseries -- 구형 마우스맨 마우스

- mmhittab -- mmhittab 마우스

둁 XEMU3=emulation, emulation은 다음과 같은 값 중에 하나가 사용된다.

- yes -- 세 단추 에뮬레이션을 사용한다.

- no -- 마우스에서 세 단추를 지원한다.

추가적으로 /dev/mouse는 실제로 동작하는 마우스 장치에 심볼릭 링크되어 있다.

/etc/sysconfig/network - 원하는 네트워크 설정에 대한 정보를 지정하는 파일이다. 다음과 같은 값들이 사용된다.

둁 NETWORKING=answer, answer에 사용된 값은 다음과 같다.

- yes -- 네트워크 사용가능으로 설정

- no -- 네트워크 사용하지 않는 것으로 설정

둁 HOSTNAME=hostname, 호스트 이름은 정식으로 형식을 갖추어서 입력해야 한다. 내용은 상관이 없다.

※참고사항 : 옛날의 구형 소프트웨어는 /etc/HOSTNAME에서 호스트 이름에 관한 자료를 읽어들여 참고한다. 호환성을 위해 /etc/HOSTNME에도 같은 내용이 저장된다.

둁 FORWARD_IPV4=answer, answer에 사용된 값은 다음과 같다.

- yes -- IP 패킷 전달기능을 수행한다.

- no -- IP 패킷 전달기능을 꺼놓는다.

(현재의 레드햇 리눅스 시스템 설치 시에는 기본적으로 no 값이 설정이 된다. 하지만 레드햇 4.2 버전 이전에서는 이 값을 no로 설정해도 IP 패킷 전달기능이 동작했었다.)

둁 GATEWAY=gw-ip, gw-ip는 네트워크의 게이트웨이 장치의 IP 주소로 사용한다.

둁 GATEWAYDEV=gw-dev, gw-dev는 게이트웨이 장치를 써준다(예를 들면 eth0).

둁 NISDOMAIN=dom-name, dom-name은 NIS 도메인 이름을 의미한다.

/etc/sysconfig/pcmcia - 이 파일은 PCMCIA 설정정보를 지정하는 파일이다. 다음과 같은 값을 포함하고 있다.

둁 PCMCIA=answer, answer에 쓰일 수 있는 값은 다음과 같다.

- yes -- PCMCIA를 지원하여 사용한다.

- no -- PCMCIA를 사용하지 않는다.

둁 PCIC=pcic-type, pcic-type에 쓰일 수 있는 값은 다음과 같다.

- i82365 -- i82365-종류의 PCMCIA 소켓 칩셋을 가진 컴퓨터를 의미

- tcic -- tcic-종류의 PCMCIA 소켓 칩셋을 가진 컴퓨터를 의미

둁 PCIC_OPTS=option, option은 소켓 구동기의 타이밍 인자 값을 써준다.

둁 CORE_OPTS=option, option은 pcmcia_core의 선택 사항 목록을 써준다.

둁 CARDMGR_OPTS=option, option은 PCMCIA 카드 관리자의 선택 사항 목록을 써준다.

/etc/sysconfig/amd - 이 파일은 amd를 위한 추가적인 선택 사항 인자를 지정하는 데 쓰인다.

둁 ADIR=path, path는 amd 디렉토리이다. 이것은 ``/.automount''가 되어야 하며 일반적으로 바뀌지 않는다.

둁 MOUNTPTS=mountpts, mountpts는 예를 들어 ``/net /etc/amd.conf''

둁 AMDOPTS=options, options는 AMD를 위한 추가적인 설정이다.

/etc/sysconfig/tape - 이 파일은 테이프 백업 장치에 관련된 설정정보를 지정하는 파일이다.

둁 DEV=devnam, devnam는 테이프 장치를 의미한다( 예를 들어``/dev/nst0"). 이 설정 파일에 관련된 스크립트에서 되감지 않는 장치를 사용한다.

SCSI 테이프 드라이브의 경우는 장치 이름으로 ``/dev/nst#''를 사용한다. 여기서 ``#''는 테이프 드라이브의 숫자를 뜻한다. 만약 하나의 테이프 드라이브를 가지고 있다면 "/dev/nst0" 가 된다.

IDE 테이프 드라이브의 경우는 장치 이름으로 ``/dev/ht#''를 사용한다. 여기서 ``#''는 테이프 드라이브의 숫자를 뜻한다. 만약 하나의 테이프 드라이브를 가지고 있다면 "/dev/ht0"가 된다. 플로피 테이프 드라이브의 경우에는 "/dev/ftape"를 사용한다.

둁 ADMIN=account, account는 어떤 이유로든 백업이 실패했을 경우 이것을 전자우편으로 알려줄 사용자 계정을 말한다. 보통 root로 설정되어 있다.

둁 SLEEP=time, time은 테이프 조작 사이에 사이사이 쉬는 횟수를 말한다. 어떤 테이프 드라이브는 다른 것들보다 조금더 많이 필요하기도 한다. 일반적으로 8mm, 4mm 그리고 DLT의 경우 5가 많이 쓰인다.

둁 BLOCKSIZE=size, size는 테이프 드라이브의 최적화된 블록 크기를 말한다. 8mm, 4mm, DLT의 경우 32768로 설정하면 잘 동작한다. 그러나 최적화된 설정은 한번에 테이프 드라이브에 얼마나 많은 자료를 쓸 수 있느냐 하는 것이다.

둁 SHORTDATE=date, date는 백업 기록 파일 이름에 사용되는 간단한 형식의 날짜 문자열을 평가하는 문자열이다. 기본 설정은 ``$(date +log-%y:%m:%d)''이다.

둁 DAY=date, date는 로그 파일 디렉토리를 만들 때 쓰는 이름에 사용되는 날짜 문자열을 나타내는 문자열이다. 이것의 기본 설정은 ``$(date +log-%y:%m:%d)''이다.

둁 DATE=date, date는 로그 파일 이름에 사용되는 날짜 문자열을 표현하는 문자열이다. 이것의 기본 설정은 ``$(date)''이다.

둁 LOGROOT=path, path는 로그 파일을 남기는 디렉토리의 최상위 디렉토리 경로를 의미한다.

둁 LIST=file, file은 백업을 한꺼번에 하지 않고 조금씩 조금씩 수행할 때 그 순서를 지정한 목록이 들어 있는 파일이다. 이것은 안에 각 디렉토리나 파일에 순서가 따라 붙는다.

둁 DOTCOUNT=count, count는 위의 점진적인 백업을 수행할 때 위의 목록에서 얼마까지를 수행하고 있는가를 저장하는 파일이다.

둁 COUNTER=count-file, count-file은 백업이 완료되었을 때 되감을 때 사용되는 파일이다. 보통 쓰이지 않는다.

둁 BACKUPTAB=file, file은 시스템에서 만들고자 하는 백업의 목록을 가지고 있는 파일의 이름이다.

/etc/sysconfig/network-scripts/에 있는 파일

다음의 파일들은 /etc/sysconfig/network-scripts/ 디렉토리에 있는 파일들이다.

둁 /etc/sysconfig/network-scripts/ifup

둁 /etc/sysconfig/network-scripts/ifdown

둁 /etc/sysconfig/network-scripts/network-functions

둁 /etc/sysconfig/network-scripts/ifcfg-<interface-name>

둁 /etc/sysconfig/network-scripts/ifcfg-<interface-name>-<clone-name>

둁 /etc/sysconfig/network-scripts/chat-<interface-name>

둁 /etc/sysconfig/network-scripts/dip-<interface-name>

둁 /etc/sysconfig/network-scripts/ifup-post

둁 /etc/sysconfig/network-scripts/ifdhcpc-done

각각의 파일을 살펴보면

/etc/sysconfig/network-scripts/ifup, /etc/sysconfig/network-scripts/ifdown - /sbin/ifup과 /sbin/ifdown에 심볼릭 링크되어 있다. 각각 이 두 개의 파일만이 이 디렉토리 안에서 직접적으로 실행되는 스크립트 파일이다. 이 스크립트가 필요한 다른 스크립트 파일을 호출하게 된다. 새로운 버전이 나올 경우에 이 설정 파일은 사라질 수도 있다 그러나 이 두 파일의 원래위치인 /sbin에 그대로 남아 있게 된다. 그리고 이 두 파일만이 필요하게 된다.

이 스크립트들은 보통 하나의 인자만을 필요로 한다. 예) "eth0"

부팅하는 동안에는 이 스크립트들이 boot라는 인자를 두 번째로 취하면서 호출이 된다. 그래서 각 장치에 해당하는 (ONBOOT=no)라고 설정되어 있는 파일들은 무시하고 이렇게 설정되어 있지 않는 장치만을 활성화시킨다.

/etc/sysconfig/network-scripts/network-functions - 이 파일은 실제적으로 설정되는 파일은 아니다. 이 파일은 네트워크 장치 인터페이스를 활성화시키고 비활성화 시키는데 사용하는 함수들을 포함하여 다른 스크립트들이 이 기능을 활용하도록 되어 있는 스크립트 라이브러리 파일과 같은 것이다.

/etc/sysconfig/network-scripts/ifcfg-<interface-name>,

/etc/sysconfig/network-scripts/ifcfg-<interface-name>-<clone-name> - 첫 번째 파일은 인터페이스에 대한 정의 파일이다. 반면 두 번째 파일은 clone 인터페이스와 다른 정의를 가지고 있는 파일로 이것은 같은 인터페이스에 대한 두 가지 설정을 가지고 서로 번갈아 가면서 설정을 바꿔 사용할 수 있다. 예를 들면, 노트북에서 랜 카드를 사용하는 경우 이동하면서 연결할 수 있는 네트워크가 여러 군데가 될 수 있다. 이 각각의 네트워크에 대한 설정을 매번 바꿀 필요 없이 부팅하고 나서 네트워크에 따라 설정에 맞는 인터페이스를 활성화시킬 수 있게 된다.

ifcfg 파일 안에서 정의되는 내용은 인터페이스 종류에 따라 달라진다.

다음과 같은 값들이 모든 기본 파일에서 공통적으로 설정되는 항목들이다.

둁 DEVICE=name, name은 실제적인 하드웨어 장치 이름이다(단 동적으로 할당되는 PPP 장치는 논리적 이름을 사용한다).

둁 IPADDR=addr, addr는 IP 주소를 말한다.

둁 NETMASK=mask, mask는 넷 마스크 값이다.

둁 NETWORK=addr, addr는 네트워크 주소이다.

둁 BROADCAST=addr, addr는 브로드캐스트 주소이다.

둁 GATEWAY=addr, addr는 게이트웨이의 주소이다.

둁 ONBOOT=answer, answer에 쓰일 수 있는 값은 다음과 같다.

- yes -- yes로 설정하면 부팅하는 과정 중에 인터페이스가 활성화된다.

- no -- 이렇게 설정하면 부팅하는 도중에 활성화되지 않는다.

둁 USERCTL=answer, answer에 쓰일 수 있는 값은 다음과 같다.

- yes -- root 가 아닌 사용자도 이 장치를 제어할 수 있도록 허가한다.

- no -- root 가 아닌 사용자는 이 장치를 제어할 수 있도록 허가하지 않는다.

둁 BOOTPROTO=proto, proto에 쓰일 수 있는 값은 다음과 같다.

- none -- 부팅할 때 동적 IP할당에 사용하는 프로토콜을 사용하지 않는다.

- bootp -- bootp 프로토콜을 사용한다.

- dhcp -- dhcp 프로토콜을 사용한다.

다음의 내용은 모든 PPP나 SLIP파일에서 공통적으로 설정하는 아이템이다.

둁 PERSIST=answer, answer에 쓰일 수 있는 값은 다음과 같다.

- yes -- 이 장치를 언제나 활성인 상태를 유지한다. 심지어 모뎀이 끊어졌을 때도.

- no -- 이 장치를 언제나 활성인 상태로 유지한지는 않는다.

둁 MODEMPORT=port, 여기서 port는 모뎀 포트의 장치 이름 ( 예를 들어 ``/dev/modem'')

둁 LINESPEED=baud, baud는 모뎀의 전화선 속도(예를 들어, ``115200'').

둁 DEFABORT=answer, answer에 쓰일 수 있는 값은 다음과 같다

- yes -- 이 인터페이스를 위한 스크립트를 생성하고 편집할 때 abort 문자열을 삽입한다.

- no -- 이 인터페이스를 위한 스크립트를 생성하고 편집할 때 abort 문자열을 삽입하지 않는다.

다음의 설정 항목들은 모든 PPP 파일에서 공통적으로 사용된다.

둁 DEFROUTE=answer, answer에 쓰일 수 있는 값은 다음과 같다

- yes -- 이 장치를 기본 라우팅 장치로 설정한다.

- no -- 이 장치를 기본 라우팅 장치로 설정하지 않음

둁 ESCAPECHARS=answer, answer에 쓰일 수 있는 값은 다음과 같다

- yes -- 미리 정의된 asyncmap을 사용한다.

- no -- 미리 정의된 asyncmap을 사용하지 않는다.

둁 HARDFLOWCTL=answer, answer에 쓰일 수 있는 값은 다음과 같다

- yes -- 하드웨어 흐름 제어를 사용한다.

- no -- 하드웨어 흐름 제어를 사용하지 않는다.

둁 PPPOPTIONS=options, options는 모든 선택 사항 문자열이다 일반적인 pppd 명령에 추가되는 나머지 선택 사항들이 여기에 추가된다..

둁 PAPNAME=name, name는 pppd 명령행 선택 사항 중 "name $PAPNAME" 에 사용된다.

remotename 선택 사항은 ppp0 같은 논리적인 ppp 장치로 지정된다는 사실에 주의할 것 (다른 ppp 장치가 이미 활성화되었다면 이것은 ppp1같은 실제 하드웨어 장치의 이름을 사용할 수도 있다). 이러한 논리적인 장치 이름은 pap/chap 같은 파일을 관리하기가 쉬워진다. -- 이름과 암호에 관련된 논리적인 장치 이름으로 관리할 수 있다.

원칙적으로는 논리적인 ppp 장치 이름은 ppp0 - pppN 대신에 worldnet이나 myISP같은 이름을 써도 상관없다.

둁 REMIP=addr, addr는 원격 IP 주소로 보통 지정하지 않는다.

둁 MTU=value, MTU 설정 값을 여기에 써준다.

둁 MRU=value, MRU 설정 값을 여기에 써준다.

둁 DISCONNECTTIMEOUT=value, 연결이 이루어진 이후에 재 연결을 시도하기 전에 신호검출 대기 시간

둁 RETRYTIMEOUT=value, 연결을 시도했을 때 연결이 실패한 후 다시 연결을 시도하기 전까지 대가하는 시간

/etc/sysconfig/network-scripts/chat-<interface-name> - 이 파일은 PPP또는 SLIP 연결을 실제적으로 수행하기 위한 chat 스크립트 파일이다. SLIP 연결을 위해서는 chat 스크립트 안에서 DIP스크립트를 호출한다. PPP 장치를 위해서는 chat 스크립트자신이 직접 동작한다.

/etc/sysconfig/network-scripts/dip-<interface-name> - 이 스크립트는 netcfg에 의해 만들어지는 쓰기만 가능한 스크립트이다. 이 파일은 변경하지 말 것. 앞으로는 이 파일이 필요 없어지고 대신에 chat 스크립트에서 모든 것을 처리할 것이다

/etc/sysconfig/network-scripts/ifup-post - 이 파일은 SLIP 장치를 제외한 네트워크 장치가 활성화 됐을 때 호출된다. /etc/sysconfig/network-scripts/ifup-routes를 호출해서 해당 네트워크 장치에 정적 라우팅을 설정하고, alias를 설정하고 만약 설정되지 않았다면 호스트이름을 설정하고, 해당 장치에 할당된 IP로 호스트 이름을 찾을 수 있도록 만들고 네트워크 이벤트를 인식하는 모든 프로그램에 대해 새로운 네트워크 설정이 됐다는 것을 SIGIO 시그널을 보내서 알린다.

이 파일은 필요하다면 네임 서버 설정 다른 스크립트의 기타 설정 파일을 사용하기 위해 확장될 수 있다.

11.11.2 System V Init

여기에서는 부팅과정의 내부에 대해 짧게 설명한다. SysV Init를 사용하여 부팅이 어떻게 이루어지는지를 다루며 옛날 버전의 리눅스에서 사용된 초기 고유의 초기화 과정과의 차이점을 다룬다.

Init는 부팅이 될 때 커널이 동작시키는 프로그램이다. 이것은 부팅이 될 때 돌아가야 할 일반적인 프로세스들을 모두 동작시키도록 하는 역할을 맡고 있다. 이러한 것은 로그인 할 때 사용되는 getty, NFS 데몬, FTP 데몬 등이 포함된다. 그리고 사용자가 시스템이 부팅할 때 실행하고자 하는 프로그램도 포함된다.

SysV Init는 부팅할 때 시동되는 프로그램을 제어하는데 있어서 표준으로 아주 빨리 리눅스 사회에서 정착되었다. 그것은 전통적인 BSD 초기화 프로그램 보다 많은 기능과 활용성을 가지고 있으며 훨씬 더 사용하기 쉽다.

SysV Init는 설정파일이 /etc 디렉토리에 따로 디렉토리를 만들어 저장이 된다는 점에서 BSD init 와 다른 점이다. 이 디렉토리는 rc.d인데 여기에는 rc.sysinit파일과 다음과 같은 디렉토리가 있다.

init.d

rc0.d

rc1.d

rc2.d

rc3.d

rc4.d

rc5.d

rc6.d

init.d에는 많은 수의 스크립트 파일이 들어있다. 기본적으로 부팅할 때 동작시키고자 하는 서비스는 각각의 서비스에 대해 하나씩의 스크립트가 필요하다. 이러한 서비스들은 네트워킹이나 nfs 센드메일, 웹서버 등과 같은 것이다. 서비스 중에는 한 번 실행되고 끝나는 setserial 같은 프로그램은 포함되지 않는다. 이러한 사항은 rc.local 이나 rc.serial 파일에서 처리한다.

rc.local 파일은 /etc/rc.d 디렉토리에 위치해야 한다. 이 파일이 많은 일을 하지 않는다고 해도 대부분의 시스템이 이 파일을 가지고 있다. 추가적으로 부팅할 때 직렬 포트에 대한 설정이 필요하다고 하면 /etc/rc.d 디렉토리에 rc.serial 파일을 가지고 설정할 수 있다.

초기화의 일련의 순서는 다음과 같다.

커널은 몇 군데에서 초기화 과정을 수행하는 데 필요한 파일을 찾는다. 그리고 첫 번째 수행해야 할 일을 가지고 있는 /etc/rc.d/rc.sysinit를 실행시킨다. rc.sysinit는 일련의 필요한 일을 실행하고 rc.serial 파일이 있으면 이것을 실행한다.

그 후 init는 기본 설정된 실행수준에 있는 모든 서비스 구동 스크립트를 실행하고 마지막으로 rc.local을 실행한다.

기본 실행수준은 /etc/inittab에서 결정된다. 이 파일의 앞부분에는 다음과 같은 내용의 줄을 포함하고 있다.

id:3:initdefault:

여기에서 두 번째 항목에 기본 실행수준 설정이 3으로 되어있는 것을 볼 수 있다. 대부분의 시스템은 기본 설정을 3으로 맞추어 놓고 있다. 만약 이것을 바꾸기를 원한다면 이 파일을 직접 편집한다. 그러나 이 inittab 파일에 손을 대는 것은 세심한 주의가 필요하다. 만약 이 내용을 변경해서 무엇인가 잘못됐다면 이것을 고치기 위해 다시 부팅을 하고 boot 입력 대기 상태가 되었을 때 다음과 같이 명령을 내린다.

LILO boot: linux single

이것은 단일 사용자 모드로 부팅하는 방법이다. 그리고 단일 사용자 모드에서 inittab을 변경할 수 있다.

적당한 스크립트를 어떻게 구동되는 지 알고 싶다면 rc3.d 디렉토리에서 ls -l 명령을 입력한다.

lrwxrwxrwx 1 root root 17 3:11 S10network -> ../init.d/network

lrwxrwxrwx 1 root root 16 3:11 S30syslog -> ../init.d/syslog

lrwxrwxrwx 1 root root 14 3:32 S40cron -> ../init.d/cron

lrwxrwxrwx 1 root root 14 3:11 S50inet -> ../init.d/inet

lrwxrwxrwx 1 root root 13 3:11 S60nfs -> ../init.d/nfs

lrwxrwxrwx 1 root root 15 3:11 S70nfsfs -> ../init.d/nfsfs

lrwxrwxrwx 1 root root 18 3:11 S90lpd -> ../init.d/lpd.init

lrwxrwxrwx 1 root root 11 3:11 S99local -> ../rc.local

이 디렉토리에는 실제 파일들이 하나도 없다는 것을 주의해야한다. 모든 것은 init.d디렉토리에 있는 파일에 링크가 되어있을 뿐이다. 이 심볼릭 링크는 "S"와 숫자로 시작한다. "S"는 이 스크립트가 시작 스크립트 파일임을 의미한다. 그리고 "K"로 시작되는 링크들은 서비스를 중단시키는 스크립트 파일이다. 숫자는 구동되는 순서를 나타낸다. Init는 모든 서비스를 이 링크에 나타난 숫자 순서대로 구동시키거나 정지시킨다. 동일한 숫자의 구동 스크립트를 설정할 수도 있는데, 이것은 관리자에게 혼란을 주기만 할뿐이다. 이 구동 순서는 "S"나 "K" 문자 뒤에 두 자리 숫자로만 설정이 가능하다.

Init가 서비스를 구동시키거나 정지시키는 방법은 간단하다. /etc/rc.d/init.d 디렉토리에 있는 해당 서비스 스크립트는 start나 stop 인자를 받아들이도록 되어있다. 이것을 직접 명령행 상에서 다음과 같이 실행시킬 수 있다.

/etc/rc.d/init.d/httpd.init stop

이것은 웹서버 운영을 중단시키는 명령이다. Init는 해당 실행수준 디렉토리에 있는 스크립트의 이름을 읽어 들여 "S"로 시작하면 start인자를 주어 실행시키고, "K"로 시작하면 stop인자를 주어 실행시킨다. 이러한 다양한 실행수준을 지원하도록 한 이유는 사용자들이 다양한 용도로 컴퓨터를 설정하기 쉬운 방법을 원했기 때문이다. 상황에 따라 httpd나 sendmail 네트워킹 같은 것만 구동시키는 server 실행수준을 설정하기도 하고, xdm, 네트워킹 등을 구동시키는 user 실행수준을 설정할 수 있다.

11.11.3 Init 실행수준

일반적으로 레드햇 리눅스는 기본 실행수준 3번을 동작시킨다. 이 실행수준은 다중 사용자 모드이다. 다음은 레드햇 리눅스에서 사용되는 실행수준이다.

0 정지

1 단일 사용자 모드

2 NFS를 사용하지 않는 다중 사용자 모드

3 전 기능 다중 사용자 모드

4 사용하지 않음

5 전 기능 다중 사용자 모드 (X 기반 로그인 화면이 나타남)

6 재부팅

만약 시스템이 부팅이 되지 않는 상태가 되는 경우 이것은 /etc/inittab이 잘못 설정되어 있는 경우이다. 또는 시스템에 로그인 할 수 없는 경우 이것은 /etc/passwd 파일이 잘못되었거나 암호를 잃어 버렸을 경우이다. 이러한 상황이 되면 LILO boot 입력 대기 상태에서 "linux 1"를 입력하여 단일 사용자 모드로 부팅한다. 이 단일 사용자 모드는 대단히 취약한 보안상태를 지니고 로그인 입력 대기 상태도 없이 명령쉘 상태로 떨어지게 된다. 이 상태에서 잘못된 부분을 바로잡고 다시 부팅한다.

11.11.6 시스템 종료

레드햇 시스템을 종료하기 위해서 shutdown 명령을 사용한다. shutdown에 대한 자세한 설명은 "man shutdown"을 입력해서 자세한 선택 사항 등을 알 수 있지만 일반적으로 쓰이는 두 가지 사용법은 다음과 같다.

shutdown -h now

shutdown -r now

양쪽 다 시스템을 안전하게 종료시킨다. 양쪽이 모두 시스템을 종료시킨다. 그리고, 첫 번째 명령은 정지상태로 시스템 전원이 꺼지기를 기다리게 되고, 두 번째는 다시 부팅한다.

직접 reboot나 halt명령으로 시스템을 종료하거나 재시동 시키지 말기 바란다. 이 명령은 파일 시스템에 손상을 입힐 수 있다.

11.12 복구 모드

시스템 동작에 문제가 있을 경우 이것을 복구하기 위한 몇 가지 방법이 있다. 그러나 이러한 방법은 시스템에 대해서 아주 잘 이해하고 있어야 한다. 이 매뉴얼은 시스템 복구를 위해 무엇을 해야하는지를 설명할 수는 없다. 여기서는 관리자가 어느 정도 시스템에 대한 지식을 가지고 있을 경우, 이것을 이용해 시스템을 복구하기 위해 복구 모드로 들어가는 방법을 설명한다.

11.12.1 LILO를 통해 복구모드 들어가기

시스템이 완전한 부팅 과정을 마치고 난 후에 사용자가 올바른 ID와 암호를 가지고 로그인을 할 수 없는 경우 단일 사용자 모드로 부팅하거나 비상 부팅 선택 사항을 사용해야 한다. LILO boot: 입력 대기 상태에서 linux single을 입력하면 단일 사용자 모드로 부팅이 된다. 단일 사용자 모드에서는 현재 시스템에 장착된 하드디스크가 마운트될 것이다. 그러나 네트워크 서비스는 시동이 되지 않을 것이다. 비상 복구 모드에서는 거의 모든 서비스가 설정이 되지 않은 상태로 부팅이 될 것이다. 오직 기본 파일 시스템이 마운트가 된 상태이고 이것도 읽기 가능한 상태로 마운트 될 것이다.

11.12.2 비상 부팅 디스켓

설치 디스켓 두 장을 비상 복구 디스크 세트로 사용할 수 있다. 보다 자세한 정보는, 레드햇 리눅스 5.2 시디롬의 /doc 디렉토리에 있는 rescue.txt 파일을 읽어보기 바란다.

이전 - 다음