11장. Debian GNU/Linux 시스템 커스터마이징

# 11장. Debian GNU/Linux 시스템 커스터마이징

## 11.1. 모든 프로그램이 같은 종이 크기를 쓰는지 어떻게 보장하나요?

`libpaper1` 패키지를 설치하면, 시스템 전체기본 종이 크기를 물어볼 겁니다. 이 설정은 `/etc/papersize` 파일에 저장됩니다.

사용자는 종이 크기 설정을 `PAPERSIZE` 환경변수를 써서 무시할 수 있습니다. 자세한 것은 매뉴얼 페이지 papersize(5) 참조.

## 11.2. 보안을 깨지 않고 하드웨어 주변 장치에 대한 액세스를 제공하려면 어떻게 하나요?

`/dev` 디렉터리에 있는 많은 장치 파일은 미리 정의된 그룹에 들어 있습니다. 예로, `/dev/sr0`는 `cdrom` 그룹.

특정 사용자가 이러한 장치 중 하나에 액세스할 수 있도록 하려면 장치가 속한 그룹에 사용자를 추가하기만 하면 됩니다. 즉. 아래와 같이 하십시오:

    adduser user group

이렇게 하면 장치에 대한 파일 권한을 바꿀 필요가 없습니다.

사용자의 셸이나 GUI 환경에서 이 작업을 하면 로그아웃한 후 다시 로그인해야 해당 그룹의 유효한 구성원이 됩니다. 자신이 속한 그룹이 어떤 그룹인지 확인하려면 `groups` 실행하십시오.

하드웨어 주변 장치의 사용 권한을 바꾸면 `udev`가 도입되었으므로 시스템을 시작할 때 일부 장치에 대해 해당 장치가 조정될 수 있습니다. 관심 있는 하드웨어 주변 장치는 `/etc/udev`에서 규칙을 조정해야 합니다.

## 11.3. 데비안 시작할 때 콘솔 글꼴을 어떻게 로드하나요?

`kbd` 패키지가 이것을 지원하니, `/etc/kbd/config` 파일을 편집하십시오.

## 11.4. X11 프로그램의 응용프로그램 기본값은 어떻게 설정하나요?

데비안의 X 프로그램은 `/etc/X11/app-defaults/` 디렉터리에 응용프로그램 리소스 데이터를 설치합니다. X 응용프로그램을 전역적으로 사용자 정의하려면 해당 파일에 사용자 정의를 넣으십시오. 구성 파일로 표시되므로 업그레이드 중에 내용이 보존됩니다.

## 11.5. 데비안 시스템은 어떻게 부팅하나요?

모든 유닉스와 마찬가지로 데비안은 `init` 프로그램 을 실행하여 부팅합니다. 대부분의 리눅스 배포판과 마찬가지로 기본 데비안 시스템은 `systemd`를 `init`의 구현으로 사용 합니다. 기존 System-V 스타일 init 및 기타 방법도 지원됩니다. [6]

서비스 시작 순서를 제어하려면, 고전 System-V 형식 유닉스 시스템은 runlevel을 씁니다. 이것은 systemd 아래에 target으로 바뀝니다. systemd가 시스템에 가져올 기본 대상을 표시하려면 실행할 명령

    systemctl get-default

부팅하는 동안 systemd는 기본 대상 `/lib/systemd/system/default.target` 파일에 나열된 서비스 또는 기타 대상을 시작합니다. 이러한 서비스 및 대상에 대한 파일이 설치되고 데비안 패키지 설치 중에 서비스가 활성화 됩니다. 부팅하는 동안 서비스를 시작하지 않으려면 해당 패키지를 제거하는 대신 실행할 수 있는 명령

    systemctl disable service.service

`/lib/systemd/system`에 설치된 서비스 파일 이름 사용 (일반적으로 패키지 이름 기반)

서비스 파일 `/lib/systemd/system/rc-local.service`은 부팅 후 커스터마이즈 된 스크립트를 `/etc/rc.local` 파일에서 실행하는 쉬운 방법을 제공하며, 데비안 시스템이 제공하는 것은 시스템-V 스타일 init와 비슷합니다. 주의: 이 스크립트는 콘솔과 상호작용(사용자 암호를 묻거나 화면을 지우려고 하는 것 등) 하려고 시도하면 실패합니다.

서비스 상태를 체크하려면 실행할 명령은

    service 패키지 status

입니다. 서비스를 시작하거나 멈추려면, 실행하기를

    service 패키지 start

그리고

    service 패키지 stop

. `service` 명령어는 systemd 뿐만 아니라 데비안 시스템에서 지원되는 모든 init 시스템과 함께 동작합니다. 그러나 systemd 지원 리눅스 시스템에서 동일한 명령을 사용하여 상태 실행을 확인하려면 실행하기를

    systemctl status 패키지.service

로 같은 정보를 얻습니다.

데비안에서 systemd 관련 더 많은 정보는 https://wiki.debian.org/systemd 참조.

## 11.6. 데비안과 전통적 system V init는 어떤가요?

데비안은 sysvinit-core 패키지를 통해 전통적인 System V init를 사용한 부팅을 지원합니다. System V `init`의 구성 파일 init(즉)은 `/etc/inittab` 실행할 첫 번째 스크립트가 `/etc/init.d/rcS`. 이 스크립트는 `/etc/init.d/rcS` 파일 시스템을 확인하고 마운트하고, 모듈을 로드하고, 네트워크 서비스를 시작하고, 시계를 설정하고, 기타 초기화를 수행하는 것과 같은 초기화를 수행하는 하위 프로세스를 분기하여 모든 스크립트를 실행합니다 .

부팅 프로세스 완료 후, `init`는 기본 런레벨에서 지정한 디렉터리 안의 모든 시작 스크립트를 실행합니다 (이 런레벨은 `/etc/inittab` 안의 `id` 항목에서 주어집니다). 대부분의 System V 호환 유닉스처럼, 리눅스는 7개 런레벨이 있습니다:

- 0 (시스템 종료),

- 1 (단일 사용자 모드),

- 2부터 5까지 (다양한 멀티유저 모드), 및

- 6 (시스템 리부트)

데비안 시스템은 id=2를 갖고 오며, 이는 멀티 유저 상태가 되면 기본 런레벨이 '2'가 될 것을 나타내며, `/etc/rc2.d/` 안의 스크립트가 실행될 겁니다.

데비안은 insserv를 통해 종속성 기반 부팅 순서를 사용하고, `/etc/init.d/` 아래에 있는 각 스크립트 안에서 LSB 헤더를 사용하고, startpar를 사용하여 병렬 동시 부팅을 사용 하여 부팅 프로세스의 속도를 높입니다.

`/etc/rcN.d/` 디렉터리에 있는 모든 스크립트는 실제로는 `/etc/init.d/`에 있는 스크립트를 가리키는 심볼릭 링크입니다. 그러나, `/etc/rcN.d/`각 디렉터리에 있는 파일들의 이름은 `/etc/rcN.d/`에 있는 스크립트가 실행되는 방식을 나타내도록 지정됩니다. 구체적으로 살펴보면, 특정 런레벨(Runlevel)에 진입하기 전, 'K' 로 시작하는 모든 스크립트가 먼저 실행되어 서비스를 죽입니다. 그 다음으로 'S'로 시작하는 모든 스크립트가 실행되어 서비스를 시작합니다. 'K' 또는 'S' 다음에 오는 두 자리 숫자는 스크립트의 실행 순서를 뜻합니다. 낮은 숫자 스크립트가 먼저 실행됩니다.

이 접근 방식은 동작하는데, 왜냐면 `/etc/init.d/` 안의 스크립트 모두 "start", "stop", "reload", "restart" or "force-reload" 중 하나일 수 있는 인수를 사용하고 인수를 갖고 지시된 작업을 수행하기 때문입니다. 이러한 스크립트는 시스템이 부팅된 후에도 다양한 프로세스를 제어하는 데 사용할 수 있습니다.

예를 들어, "reload" 인수 가진 명령어

    /etc/init.d/sendmail reload

는 sendmail 데몬에게 설정파일을 다시 읽으라는 신호를 보냅니다.

주의. invoke-rc.d는 `/etc/init.d/` 스크립트를 부를 때 쓸 수 없으며, 그 대신 service를 사용할 수 있습니다.

## 11.7. 데비안 시스템을 부팅하는 또 다른 방법이 있나요?

System V init는 좋아하지만 /etc/rc?.d/* 링크가 마음에 들지 않으면 `file-rc` 를 설치할 수 있습니다. 그러면, 링크가 대신 하나의 단일 구성 파일 /etc/runlevel.conf로 변환됩니다.

System V도 systemd도 안 좋아한다면, `openrc` 또는 `runit` 또는 `daemontools`.

## 11.8. 패키지 관리 시스템은 다른 패키지에 대한 구성 파일이 들어간 패키지를 어떻게 처리하나요?

일부 사용자는 예를 들어 데비안 패키지 그룹과 구성 파일로 구성된 로컬에서 만든 패키지를 설치하여 새 서버를 만들고 싶어합니다. 이것은 일반적으로 좋은 생각이 아닙니다. dpkg는 구성 파일이 다른 패키지에 있으면 해당 파일에 대해 알지 못하고 패키지의 초기 "그룹" 중 하나가 업그레이드될 때 충돌하는 구성을 작성할 수 있기 때문 입니다.

대신, 관심 있는 데비안 패키지 "그룹"의 구성 파일을 수정하는 로컬 패키지를 만드십시오. 그러면 dpkg 및 나머지 패키지 관리 시스템은 파일이 로컬 "sysadmin"이 수정했음을 확인하고, 해당 패키지가 업그레이드될 때 덮어쓰지 않습니다.

## 11.9. 패키지가 설치한 파일을 대신하여 다른 버전을 사용하려면 어떻게 하나요?

시스템 관리자 또는 지역 사용자가 "login-local" 프로그램을 데비안 `login` 패키지가 제공하는 "login" 프로그램 대신 쓰길 바란다고 가정합시다.

아래와 같이 하면 안 됩니다:

- 기존 `/bin/login`에 `login-local`로 겹쳐쓰기.

패키지 관리 시스템은 이렇게 바뀐 것을 모르고, `login`(또는 `login`을 제공하는 모든 패키지)이 설치되거나 업데이트 될 때마다 사용자 정의 `/bin/login`를 덮어씁니다.

대신 할 것은

- 실행하기:

      dpkg-divert --divert /bin/login.debian /bin/login

  그러면, 데비안 미래 설치에서 `login` 패키지가 `/bin/login` 파일을 `/bin/login.debian` 로 씁니다.

- 다음 실행하기:

      cp login-local /bin/login

  그러면, 로컬에서 만든 프로그램을 제자리로 옮길 수 있습니다.

현재 시스템에서 어떤 전환이 활성화되어 있는지 확인하려면, `dpkg-divert --list` 실행하십시오.

자세한 것은 매뉴얼 페이지 dpkg-divert(8)에 있습니다.

## 11.10. 로컬 빌드 패키지를 패키지 관리 시스템이 알고 있는 사용 가능한 패키지 목록에 넣으려면 어떻게 하나요?

실행할 명령:

    dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > my_Packages

여기서:

- BIN-DIR은 데비안 아카이브 파일(보통 ".deb"의 확장자를 가짐)이 저장되는 디렉터리.

- OVERRIDE_FILE은 배포 관리자가 편집하는 파일이며 일반적으로 "메인" 배포판 안의 데비안 패키지용 `indices/override.main.gz`에 있는 데비안 아카이브에 저장됩니다. 로컬 패키지에서는 이를 무시할 수 있습니다.

- PATHPREFIX는 생성 되는 `my_Packages`파일 앞에 추가할 수 있는 옵션 문자열.

한번 `my_Packages` 파일을 만든 다음, 패키지 관리 시스템에 알립니다. 다음 명령 사용:

    dpkg --merge-avail my_Packages

만약 APT를 쓴다면, 지역 저장소를 여러분의 sources.list(5) 파일에도 더하십시오.

## 11.11. 어떤 사용자는 mawk를 좋아하고, 다른 사람은 gawk를 좋아합니다. 어떤 사람은 vim을 다른 사람은 elvis를 좋아합니다. 어떤 사람은 trn을 다른 사람은 tin을 좋아합니다. 데비안은 다양성을 어떻게 지원하나요?

두 패키지가 동일한 핵심 기능을 제공하는 두 가지 버전의 프로그램을 제공하는 경우가 있습니다. 사용자는 습관적으로 또는 한 패키지의 사용자 인터페이스가 다른 패키지 인터페이스보다 다소 더 만족스럽기 때문에 둘 중 하나를 선호할 수 있습니다. 같은 시스템에서 다른 사용자가 다른 선택을 할 수 있습니다.

데비안은 "가상" 패키지 시스템을 사용하여, 동일한 기본 기능을 제공하지만 특정 패키지를 지정하지 않고 패키지 종속성 요구 사항을 충족하는 두 개 이상의 도구가 있으면 시스템 관리자가 선호하는 도구를 선택(하거나 사용자가 선택)할 수 있도록 합니다.

예를 들어, 한 시스템에 두 가지 서로 다른 버전의 뉴스리더가 존재할 수 있습니다. 뉴스 서버 패키지는 시스템에 어떤 뉴스리더가 존재하기를 '권장'할 수 있지만, `tin` 또는 `trn` 중 무엇을 사용할지는 개별 사용자의 선택에 맡깁니다. 이러한 요구 사항은 `tin` 과 `trn` 패키지 모두가 `news-reader` 라는 가상 패키지를 제공함으로써 충족됩니다. 어떤 프로그램이 호출될지는 가상 패키지 이름 `/etc/alternatives/news-reader` 파일에서 실제 선택된 파일(예: `/usr/bin/trn`)로 연결된 링크에 의해 결정됩니다.

하나의 링크만으로는 대체 프로그램의 전체 사용을 지원하기에 불충분합니다. 일반적으로 매뉴얼 페이지 및 기타 지원 파일도 선택해야 합니다. Perl 스크립트 `update-alternatives`는 지정된 패키지와 관련된 모든 파일이 시스템 기본값으로 선택되게 하는 방법을 제공합니다.

예를 들어, 무슨 실행파일이 "x-window-manager"를 제공하는지 보려면, 실행할 것:

    update-alternatives --display x-window-manager

그것을 바꾸려면, 실행하기:

    update-alternatives --config x-window-manager

그리고 화면의 지시를 따르십시오(기본적으로 더 나은 항목 옆에 있는 숫자를 누르십시오).

패키지가 어떤 이유로 창 관리자로 등록되지 않으면(오류가 있으면 버그 신고하세요) 또는 /usr/local 디렉터리에서 창 관리자를 사용하는 경우 화면의 선택 항목에 원하는 항목이 들어있지 않습니다. 명령줄 옵션을 통해 링크를 업데이트할 수 있습니다. 다음과 같이:

    update-alternatives --install /usr/bin/x-window-manager \
      x-window-manager /usr/local/bin/wmaker-cvs 50

"--install" 옵션에 대한 첫 번째 인수는 /etc/alternatives/NAME을 가리키는 심볼릭 링크이며, 여기서 NAME은 두 번째 인수입니다. 세 번째 인수는 /etc/alternatives/NAME이 가리킬 프로그램이고, 네 번째 인수는 우선순위입니다(값이 클수록 대안이 자동으로 선택될 가능성이 더 높음).

당신이 더한 대안을 지우려면, 단순히 실행하기:

    update-alternatives --remove x-window-manager /usr/local/bin/wmaker-cvs

[6] 2014년에 데비안은 기본 초기화 시스템을 System V init에서 systemd로 바꾸었습니다. 2015년 4월 데비안 8 "jessie"는 기본 초기화로 systemd를 제공하는 첫 번째 릴리스였습니다. 데비안 기술 위원회의 4가지 결정이 관련되었습니다: Bug #727708 2014-02-11: "위원회는 jessie의 리눅스 아키텍처에 대한 기본 초기화 시스템이 시스템화 되어야 한다고 결정" Bug #746715 2014-08-01: "위원회는 jessie의 Linux 아키텍처에 대한 기본 초기화 시스템이 시스템화 되어야 한다고 결정", 그리고 합당한 기여를 병합. Bug #746578 2014-11-15: "위원회는 systemd-shim이 systemd-sysv 대신 libpam-systemd의 첫 번째 대체 종속성을 나열해야 한다고 결정". 이 결정으로 비시스템 데비안 시스템을 계속 실행하는 것이 더 쉬워졌습니다. Bug #762194 2017-11-04: "업그레이드 시 자동 초기화 시스템 전환"

10장. 데비안 및 커널 |  | 12장. Debian GNU/Linux에서 지원 받기