FreeBSD 구성 및 조정

12.1. 개요

FreeBSD의 중요한 측면 중 하나는 적절한 시스템 구성입니다. 이 장에서는 FreeBSD 시스템을 조정하기 위해 설정할 수있는 몇 가지 매개 변수를 포함하여 FreeBSD 설정 과정의 많은 부분을 설명합니다.

이 장을 읽고 나면 다음을 알 수 있습니다.

rc.conf 구성 및 /usr/local/etc/rc.d 시작 스크립트 의 기본 사항 .
네트워크 카드를 구성하고 테스트하는 방법.
네트워크 장치에서 가상 호스트를 구성하는 방법.
/ etc 에서 다양한 구성 파일을 사용하는 방법 .
sysctl (8) 변수를 사용하여 FreeBSD를 조정하는 방법 .
디스크 성능을 조정하고 커널 제한을 수정하는 방법.

이 장을 읽기 전에 다음을 수행해야합니다.

UNIX® 및 FreeBSD 기본 ( FreeBSD 기본 )을 이해 합니다.
커널 구성 및 컴파일의 기본 사항에 익숙해 져야 합니다 (FreeBSD 커널 구성 ).

12.2. 서비스 시작

많은 사용자가 Ports Collection에서 FreeBSD에 타사 소프트웨어를 설치하고 시스템 초기화시 설치된 서비스를 시작해야합니다. mail / postfix 또는 www / apache22 와 같은 서비스 는 시스템 초기화 중에 시작될 수있는 많은 소프트웨어 패키지 중 두 가지에 불과합니다. 이 섹션에서는 타사 소프트웨어를 시작하는 데 사용할 수있는 절차에 대해 설명합니다.

FreeBSD에서 cron (8) 과 같이 포함 된 대부분의 서비스 는 시스템 시작 스크립트를 통해 시작됩니다.

12.2.1. 확장 된 애플리케이션 구성

이제 FreeBSD에 rc.d가 포함되어 있으므로 응용 프로그램 시작 구성이 더 쉽고 더 많은 기능을 제공합니다. FreeBSD의 서비스 관리 에서 논의 된 키워드를 사용하면 특정 다른 서비스 이후에 시작하도록 응용 프로그램을 설정할 수 있으며 시작 스크립트의 하드 코딩 된 플래그 대신 /etc/rc.conf 를 통해 추가 플래그를 전달할 수 있습니다 . 기본 스크립트는 다음과 유사 할 수 있습니다.

#! / bin / sh # # 제공 : 유틸리티 # 필수 : 데몬 # 키워드 : 종료 . /etc/rc.subr 이름 = 유틸리티 rcvar = utility_enable 명령 = "/ usr / local / sbin / utility" load_rc_config $ name # # 여기에서 이러한 기본값을 변경하지 마십시오. # /etc/rc.conf 파일에 설정 # utility_enable = $ {utility_enable- "NO"} pidfile = $ {utility_pidfile- "/ var / run / utility.pid"} run_rc_command "$ 1"

이 스크립트는 제공된 서비스 utility가 DAEMON의사 서비스 이후에 시작 되도록합니다 . 또한 프로세스 ID (PID)를 설정하고 추적하는 방법을 제공합니다.

이 응용 프로그램은 /etc/rc.conf에 다음 줄을 배치 할 수 있습니다 .

utility_enable = "예"

이 방법을 사용하면 명령 줄 인수를 더 쉽게 조작하고, /etc/rc.subr에 제공된 기본 함수를 포함하고, rcorder (8) 과의 호환성을 제공하고, rc.conf 를 통해 더 쉽게 구성 할 수 있습니다 .

12.2.2. 서비스를 사용하여 서비스 시작

다른 서비스는 inetd (8)를 사용하여 시작할 수 있습니다 . 작업 inetd에 (8) 와 구성에서 자세히 설명 는 "inetd를 슈퍼 서버" .

어떤 경우에는 cron (8) 을 사용 하여 시스템 서비스를 시작 하는 것이 더 합리적 일 수 있습니다. 이 접근 방식은 cron (8) 이 crontab (5) 의 소유자로 이러한 프로세스를 실행 하므로 많은 이점 이 있습니다 . 이를 통해 일반 사용자는 자신의 응용 프로그램을 시작하고 유지 관리 할 수 있습니다.

시간 사양 대신 cron (8) 의 @reboot기능을 사용할 수 있습니다. 이렇게하면 일반적으로 시스템 초기화 중에 cron (8) 이 시작될 때 작업이 실행됩니다 .

12.3. cron (8) 구성

FreeBSD에서 가장 유용한 유틸리티 중 하나는 cron입니다. 이 유틸리티는 백그라운드에서 실행되며 정기적으로 / etc / crontab 에서 실행할 작업을 확인하고 / var / cron / tabs 에서 사용자 정의 crontab 파일을 검색 합니다. 이 파일은 cron이 지정된 시간에 실행되는 작업을 예약하는 데 사용됩니다. crontab의 각 항목은 실행할 작업을 정의하며이를 cron 작업이라고 합니다.

두 가지 다른 유형의 구성 파일이 사용됩니다. 수정해서는 안되는 시스템 crontab과 필요에 따라 만들고 편집 할 수있는 사용자 crontab입니다. 이 파일에서 사용되는 형식은 crontab (5)에 문서화되어 있습니다. 시스템 crontab, / etc / crontab 의 형식 에는 who사용자 crontab에 존재하지 않는 열이 포함됩니다 . 시스템 crontab에서 cron은이 열에 지정된 사용자로 명령을 실행합니다. 사용자 crontab에서 모든 명령은 crontab을 만든 사용자로 실행됩니다.

사용자 크론 탭을 사용하면 개별 사용자가 자신의 작업을 예약 할 수 있습니다. root사용자는 사용자 수 의 crontab 시스템에 존재하지 않는 작업을 예약하는 데 사용할 수 의 crontab을 .

다음은 시스템 crontab, / etc / crontab 의 샘플 항목입니다 .

# / etc / crontab-FreeBSD를위한 루트의 crontab # # $ FreeBSD $ 쉘 = / bin / sh 경로 = / etc : / bin : / sbin : / usr / bin : / usr / sbin # # 분시 mday 월 wday 누가 명령 # * / 5 * * * * 루트 / usr / libexec / atrun

	#문자로 시작하는 줄 은 주석입니다. 원하는 작업이 수행되는 내용과 이유를 알려주는 주석을 파일에 넣을 수 있습니다. 주석은 명령과 같은 줄에있을 수 없으며 그렇지 않으면 명령의 일부로 해석됩니다. 새 줄에 있어야합니다. 빈 줄은 무시됩니다.
	등호 ( =) 문자는 환경 설정을 정의하는 데 사용됩니다. 이 예에서,는를 정의하는데 사용 SHELL하고 PATH. 이 경우 SHELL생략 cron은 기본 Bourne 쉘을 사용합니다. PATH이 생략 된 경우 실행할 명령 또는 스크립트에 전체 경로를 제공해야합니다.
	이 라인은 시스템의 crontab에 사용 된 일곱 개 필드를 정의 : minute, hour, mday, month, wday, who,와 command. minute필드는 지정된 명령이 실행될 때이 분의 시간이 hour지정된 명령이 실행됩니다 시간에서,이 mday, 달의 날 month월, wday요일입니다. 이러한 필드는 24 시간 시계를 나타내는 숫자 값이거나 *해당 필드의 모든 값을 나타내는 a 여야 합니다. 이 who필드는 시스템 crontab에만 존재하며 명령을 실행할 사용자를 지정합니다. 마지막 필드는 실행할 명령입니다.
	이 항목은이 크론 작업의 값을 정의합니다. /5, 몇 가지 더 다음에 문자를 지정 /usr/libexec/atrun하여 호출 root스위치의 수를 포함 할 수있는 모든 month.Commands의, 주중 매일 하루의 모든 시간의 5 분마다. 그러나 여러 줄로 확장되는 명령은 백 슬래시 "\"연속 문자로 구분해야합니다.

12.3.1. 사용자 Crontab 생성

사용자 crontab을 작성하려면 crontab편집기 모드에서 호출 하십시오.

% crontab -e

그러면 기본 텍스트 편집기를 사용하여 사용자의 crontab이 열립니다. 사용자가이 명령을 처음 실행하면 빈 파일이 열립니다. 사용자가 crontab을 생성하면이 명령은 편집을 위해 해당 파일을 엽니 다.

환경 변수를 설정하고 crontab에있는 필드의 의미를 기억하려면 crontab 파일의 맨 위에 다음 행을 추가하는 것이 유용합니다.

쉘 = / bin / sh 경로 = / etc : / bin : / sbin : / usr / bin : / usr / sbin # crontab 필드의 순서 # 분시 mday 월 wday 명령

그런 다음 실행할 각 명령 또는 스크립트에 대한 행을 추가하여 명령을 실행할 시간을 지정합니다. 이 예에서는 매일 오후 2시에 지정된 사용자 지정 Bourne 셸 스크립트를 실행합니다. 스크립트에 대한 경로가에 지정되지 않았으므로 스크립트 PATH에 대한 전체 경로가 제공됩니다.

0 14 * * * /usr/home/dru/bin/mycustomscript.sh

사용자 정의 스크립트를 사용하기 전에 실행 가능한지 확인하고 cron에서 설정 한 제한된 환경 변수 세트로 테스트하십시오. 위의 cron 항목을 실행하는 데 사용될 환경을 복제하려면 다음을 사용하십시오.

cron이 설정 한 환경은 crontab (5) 에서 설명 합니다. 스크립트가 와일드 카드를 사용하여 파일을 삭제하는 명령을 포함하는 경우 cron 환경에서 올바르게 작동하는지 확인하는 것이 특히 중요합니다.

crontab 편집이 끝나면 파일을 저장합니다. 자동으로 설치되고 cron은 crontab을 읽고 지정된 시간에 cron 작업을 실행합니다. crontab에서 cron 작업을 나열하려면 다음 명령을 사용하십시오.

% crontab -l 0 14 * * * /usr/home/dru/bin/mycustomscript.sh

사용자 crontab에서 모든 cron 작업을 제거하려면 다음을 수행하십시오.

% crontab -r remove crontab for dru? y

12.4. FreeBSD에서 서비스 관리

FreeBSD는 시스템 초기화와 서비스 관리를 위해 rc (8) 시작 스크립트 시스템을 사용합니다. 에 나와있는 스크립트 /etc/rc.d와는 기본적인 제어 할 수있는 서비스 제공 start, stop,과 restart에 옵션 서비스 (8) . 예를 들어 sshd (8) 는 다음 명령으로 다시 시작할 수 있습니다.

# service sshd restart

이 절차를 사용하여 실행중인 시스템에서 서비스를 시작할 수 있습니다. 서비스는 rc.conf (5)에 지정된대로 부팅시 자동으로 시작됩니다 . 예를 들어, 시스템 시작시 natd (8) 을 활성화 하려면 다음 행을 /etc/rc.conf에 추가하십시오 .

natd_enable = "예"

경우 natd_enable="NO"라인이 이미 존재의 변경 NO에 YES. RC (8) 아래에 설명 된대로 스크립트는 자동으로 다음 부팅 중에 종속 서비스를로드합니다.

이후 RC (8) 시스템은 주로 시작하고 시스템 시작 및 종료시 스톱 서비스의 의도 start, stop그리고 restart적절한 경우 옵션은 자신의 작업을 수행합니다 /etc/rc.conf 파일의 변수가 설정됩니다. 예를 들어 는 /etc/rc.conf에로 설정된 sshd restart경우에만 작동합니다 . 에 , 또는 관계의 설정의 서비스 /etc/rc.conf에 ,이 명령은 "하나"로 시작해야합니다. 예를 들어, 현재 /etc/rc.conf 설정에 관계없이 sshd (8) 를 다시 시작 하려면 다음 명령을 실행하십시오.sshd_enableYESstartstoprestart

# service sshd onerestart

서비스가 활성화되어 있는지 확인하려면 /etc/rc.conf에 적절한 실행 (8) RC를 가진 스크립트 rcvar. 이 예제는 /etc/rc.conf 에서 sshd (8) 가 활성화되어 있는지 확인합니다 .

# service sshd rcvar # sshd # sshd_enable="YES" # (default: "")

이 # sshd행은 root콘솔이 아닌 위 명령의 출력입니다 .

서비스가 실행 중인지 확인하려면을 사용하십시오 status. 예를 들어 sshd (8) 가 실행 중인지 확인하려면 다음을 수행하십시오.

# service sshd status sshd is running as pid 433.

경우에 reload따라 서비스 도 가능합니다 . 이렇게하면 개별 서비스에 신호를 보내 서비스가 구성 파일을 다시로드하게됩니다. 대부분의 경우 이는 서비스에 SIGHUP신호를 보내는 것을 의미합니다 . 이 기능에 대한 지원은 모든 서비스에 포함되지 않습니다.

RC (8) 시스템은 네트워크 서비스에 사용되며, 또한 시스템 초기화의 대부분에 기여한다. 예를 들어, /etc/rc.d/bgfsck 스크립트가 실행되면 다음 메시지가 출력됩니다.

Starting background file system checks in 60 seconds.

이 스크립트는 시스템 초기화 중에 만 발생하는 백그라운드 파일 시스템 검사에 사용됩니다.

많은 시스템 서비스가 제대로 작동하려면 다른 서비스에 의존합니다. 예를 들어 yp (8) 및 기타 RPC 기반 서비스는 rpcbind (8) 서비스가 시작될 때까지 시작되지 않을 수 있습니다 . 이 문제를 해결하기 위해 각 시작 스크립트의 맨 위에있는 주석에 종속성 및 기타 메타 데이터에 대한 정보가 포함됩니다. rcorder (8) 프로그램은 시스템 서비스가 종속 관계를 만족시키기 위해 호출해야하는 순서를 결정하는 시스템을 초기화하는 동안 이러한 의견을 구문 분석하는 데 사용됩니다.

다음 키워드는 rc.subr (8) 에서 시작 스크립트를 "활성화"하는 데 필요하므로 모든 시작 스크립트에 포함되어야합니다 .

PROVIDE:이 파일이 제공하는 서비스를 지정합니다.

각 시작 스크립트의 맨 위에 다음 키워드가 포함될 수 있습니다. 꼭 필요한 것은 아니지만 rcorder (8)에 대한 힌트로 유용합니다 .

REQUIRE:이 서비스에 필요한 서비스를 나열합니다. 이 키워드를 포함하는 스크립트 는 지정된 서비스 이후 에 실행 됩니다.
BEFORE:이 서비스에 의존하는 서비스를 나열합니다. 이 키워드를 포함하는 스크립트 는 지정된 서비스 보다 먼저 실행 됩니다.

각 시작 스크립트에 대해 이러한 키워드를 신중하게 설정함으로써 관리자는 일부 UNIX® 운영 체제에서 사용하는 "실행 수준"없이도 스크립트의 시작 순서를 세밀하게 제어 할 수 있습니다.

추가 정보는 rc (8) 및 rc.subr (8) 에서 찾을 수 있습니다 . 사용자 지정 rc (8) 스크립트 를 만드는 방법에 대한 지침은 이 문서 를 참조하십시오 .

12.4.1. 시스템 별 구성 관리

시스템 구성 정보의 주요 위치는 /etc/rc.conf 입니다. 이 파일은 광범위한 구성 정보를 포함하며 시스템을 구성하기 위해 시스템 시작시 읽습니다. rc * 파일에 대한 구성 정보를 제공 합니다.

/etc/rc.conf 의 항목은 /etc/defaults/rc.conf 의 기본 설정을 재정의합니다 . 기본 설정이 포함 된 파일은 편집하지 않아야합니다. 대신 모든 시스템 별 변경 사항은 /etc/rc.conf에서 이루어져야합니다 .

관리 오버 헤드를 줄이기 위해 여러 가지 전략을 클러스터 된 응용 프로그램에 적용하여 사이트 전체 구성을 시스템 별 구성과 분리 할 수 있습니다. 권장되는 접근 방식은 시스템 별 구성을 /etc/rc.conf.local에 배치하는 것 입니다. 예를 들어, /etc/rc.conf의 다음 항목은 모든 시스템에 적용됩니다.

sshd_enable = "예" keyrate = "빠른" defaultrouter = "10.1.1.254"

/etc/rc.conf.local의 이러한 항목은 이 시스템에만 적용됩니다.

hostname = "node1.example.org" ifconfig_fxp0 = "inet 10.1.1.1/8"

rsync 또는 puppet과 같은 응용 프로그램을 사용하는 모든 시스템에 /etc/rc.conf 를 배포 하고 /etc/rc.conf.local 은 고유하게 유지합니다.

시스템을 업그레이드해도 /etc/rc.conf를 덮어 쓰지 않으므로 시스템 구성 정보가 손실되지 않습니다.

/etc/rc.conf 및 /etc/rc.conf.local 모두 sh (1)에 의해 구문 분석됩니다 . 이를 통해 시스템 운영자는 복잡한 구성 시나리오를 만들 수 있습니다. 이 주제에 대한 자세한 정보는 rc.conf (5) 를 참조하십시오 .

12.5. 네트워크 인터페이스 카드 설정

네트워크 인터페이스 카드 (NIC)를 추가하고 설정하는 것은 FreeBSD 관리자의 일반적인 작업입니다.

12.5.1. 올바른 드라이버 찾기

먼저 NIC의 모델과 사용하는 칩을 확인합니다. FreeBSD는 다양한 NIC를 지원합니다. NIC가 지원되는지 알아 보려면 FreeBSD 릴리스의 하드웨어 호환성 목록을 확인하십시오.

NIC가 지원되는 경우 NIC 용 FreeBSD 드라이버의 이름을 확인합니다. 참고로 는 / usr / src / sys / conf의 / NOTES 하고 는 / usr / src / sys / 아치 / conf의 / NOTES 지원되는 칩셋에 대한 정보와 NIC 드라이버의 목록. 확실하지 않은 경우 지원되는 하드웨어 및 드라이버의 알려진 제한 사항에 대한 자세한 정보를 제공하므로 드라이버 설명서 페이지를 읽으십시오.

일반 NIC 용 드라이버는 이미 GENERIC 커널에 있으므로 부팅 중에 NIC를 검색해야합니다. more /var/run/dmesg.boot텍스트를 스크롤하려면 스페이스 바를 입력 하고 사용하여 시스템의 부팅 메시지를 볼 수 있습니다 . 이 예에서는 dc (4) 드라이버를 사용하는 두 개의 이더넷 NIC 가 시스템에 있습니다.

dc0: <82c169 PNIC 10/100BaseTX> port 0xa000-0xa0ff mem 0xd3800000-0xd38 000ff irq 15 at device 11.0 on pci0 miibus0: <MII bus> on dc0 bmtphy0: <BCM5201 10/100baseTX PHY> PHY 1 on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:a0:cc:da:da:da dc0: [ITHREAD] dc1: <82c169 PNIC 10/100BaseTX> port 0x9800-0x98ff mem 0xd3000000-0xd30 000ff irq 11 at device 12.0 on pci0 miibus1: <MII bus> on dc1 bmtphy1: <BCM5201 10/100baseTX PHY> PHY 1 on miibus1 bmtphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: Ethernet address: 00:a0:cc:da:da:db dc1: [ITHREAD]

NIC 용 드라이버가 GENERIC 에 없지만 드라이버를 사용할 수있는 경우 NIC를 구성하고 사용하기 전에 드라이버를로드해야합니다. 이는 다음 두 가지 방법 중 하나로 수행 할 수 있습니다.

가장 쉬운 방법은 kldload (8)를 사용하여 NIC 용 커널 모듈을로드하는 것 입니다. 부팅 할 때 자동으로 드라이버를로드하려면 /boot/loader.conf에 적절한 행을 추가하십시오 . 모든 NIC 드라이버를 모듈로 사용할 수있는 것은 아닙니다.
또는 NIC에 대한 지원을 사용자 지정 커널로 정적으로 컴파일합니다. 사용자 정의 커널 구성 파일에 추가 할 행을 결정 하려면 / usr / src / sys / conf / NOTES , / usr / src / sys / arch / conf / NOTES 및 드라이버의 매뉴얼 페이지를 참조하십시오. 커널 재 컴파일에 대한 자세한 내용은 FreeBSD 커널 구성을 참조하십시오 . 부팅시 NIC가 감지되면 커널을 다시 컴파일 할 필요가 없습니다.

12.5.1.1. Windows® NDIS 드라이버 사용

불행히도, 그러한 정보를 영업 비밀로 간주하기 때문에 오픈 소스 커뮤니티에 드라이버에 대한 회로도를 제공하지 않는 공급 업체가 여전히 많이 있습니다. 결과적으로 FreeBSD 및 기타 운영 체제의 개발자는 두 가지 선택을 할 수 있습니다. 길고 힘든 리버스 엔지니어링 프로세스를 통해 드라이버를 개발하거나 Microsoft® Windows® 플랫폼에서 사용할 수있는 기존 드라이버 바이너리를 사용하는 것입니다.

FreeBSD는 NDIS (Network Driver Interface Specification)에 대한 "기본"지원을 제공합니다. 여기에는 Windows® XP 드라이버를 FreeBSD에서 사용할 수있는 형식으로 변환하는 데 사용할 수있는 ndisgen (8) 이 포함되어 있습니다. 는 AS NDIS (4) 드라이버가 윈도우 XP 바이너리를 사용, 그것은 단지 I386 ™ 및 AMD64 시스템에서 실행됩니다. PCI, CardBus, PCMCIA 및 USB 장치가 지원됩니다.

ndisgen (8) 을 사용하려면 세 가지가 필요합니다.

FreeBSD 커널 소스.
확장자 가 .SYS 인 Windows® XP 드라이버 바이너리 .
확장자 가 .INF 인 Windows® XP 드라이버 구성 파일 .

특정 NIC에 대한 .SYS 및 .INF 파일을 다운로드합니다 . 일반적으로 드라이버 CD 또는 공급 업체의 웹 사이트에서 찾을 수 있습니다. 다음 예제에서는 W32DRIVER.SYS 및 W32DRIVER.INF를 사용 합니다.

드라이버 비트 폭은 FreeBSD 버전과 일치해야합니다. FreeBSD / i386의 경우 Windows® 32 비트 드라이버를 사용하십시오. FreeBSD / amd64의 경우 Windows® 64 비트 드라이버가 필요합니다.

다음 단계는 드라이버 바이너리를로드 가능한 커널 모듈로 컴파일하는 것입니다. 로 root, 사용 ndisgen (8) :

# ndisgen /path/to/W32DRIVER.INF /path/to/W32DRIVER.SYS

이 명령은 대화 형이며 필요한 추가 정보를 입력하라는 메시지를 표시합니다. 현재 디렉토리에 새 커널 모듈이 생성됩니다. 사용 kldload (8) 새 모듈을로드합니다 :

# kldload ./W32DRIVER_SYS.ko

생성 된 커널 모듈 외에도 ndis.ko 및 if_ndis.ko 모듈을로드해야합니다. 이는 ndis (4) 에 의존하는 모듈 이로드 될 때 자동으로 발생합니다 . 그렇지 않은 경우 다음 명령을 사용하여 수동으로로드하십시오.

# kldload ndis # kldload if_ndis

첫 번째 명령은 ndis (4) 미니 포트 드라이버 래퍼를 로드하고 두 번째 명령 은 생성 된 NIC 드라이버를로드합니다.

로드 오류가 있는지 확인하려면 dmesg (8) 를 확인하십시오. 모든 것이 순조롭게 진행 되었다면 출력은 다음과 유사해야합니다.

ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1 ndis0: NDIS API version: 5.0 ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5 ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps

여기에서 ndis0 은 다른 NIC처럼 구성 할 수 있습니다.

부팅시 ndis (4) 모듈 을로드하도록 시스템을 구성하려면 생성 된 모듈 W32DRIVER_SYS.ko 를 / boot / modules에 복사합니다 . 그런 다음 /boot/loader.conf에 다음 행을 추가하십시오 .

W32DRIVER_SYS_load = "예"

12.5.2. 네트워크 카드 구성

NIC에 적합한 드라이버가로드되면 카드를 구성해야합니다. bsdinstall (8)에 의해 설치시 구성되었을 수 있습니다 .

NIC 구성을 표시하려면 다음 명령을 입력하십시오.

% ifconfig dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> ether 00:a0:cc:da:da:da inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX <full-duplex>) status: active dc1: flags=8802<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> ether 00:a0:cc:da:da:db inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet 10baseT/UTP status: no carrier lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=3<RXCSUM,TXCSUM> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nd6 options=3<PERFORMNUD,ACCEPT_RTADV>

이 예에서는 다음 장치가 표시되었습니다.

dc0 : 첫 번째 이더넷 인터페이스입니다.
dc1 : 두 번째 이더넷 인터페이스입니다.
lo0 : 루프백 장치.

FreeBSD는 드라이버 이름과 부팅시 카드가 감지되는 순서를 사용하여 NIC의 이름을 지정합니다. 예를 들어, sis2 는 sis (4) 드라이버를 사용하는 시스템의 세 번째 NIC입니다 .

이 예에서 dc0 은 실행 중입니다. 주요 지표는 다음과 같습니다.

UP 카드가 구성되고 준비되었음을 의미합니다.
카드에 인터넷 ( inet) 주소가 192.168.1.3있습니다.
유효한 서브넷 마스크 ( netmask) 0xffffff00가 있습니다. 여기서은 255.255.255.0.
유효한 브로드 캐스트 주소가 192.168.1.255있습니다.
카드 ( ether) 의 MAC 주소 는 00:a0:cc:da:da:da입니다.
물리적 미디어 선택은 자동 선택 모드 ( media: Ethernet autoselect (100baseTX <full-duplex>))입니다. 이 예에서 dc1 은 10baseT/UTP미디어 와 함께 실행되도록 구성됩니다 . 드라이버에 사용할 수있는 미디어 유형에 대한 자세한 내용은 해당 설명서 페이지를 참조하십시오.
링크 상태 ( status)는 active반송파 신호가 감지되었음을 나타냅니다. 들어 DC1 의 status: no carrier이더넷 케이블이 카드에 연결되지 않은 경우 상태는 정상입니다.

는 IF 은 ifconfig (8) 출력이 비슷한에게 표시했다 :

dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> ether 00:a0:cc:da:da:da media: Ethernet autoselect (100baseTX <full-duplex>) status: active

카드가 구성되지 않았 음을 나타냅니다.

카드는 root. NIC 구성은 ifconfig (8) 을 사용하여 명령 줄에서 수행 할 수 있지만 구성이 /etc/rc.conf에 추가되지 않는 한 재부팅 후에도 유지되지 않습니다 . LAN에 DHCP 서버가있는 경우 다음 행을 추가하십시오.

ifconfig_dc0 = "DHCP"

교체 DC0 시스템에 대한 올바른 값으로.

추가 된 줄은 테스트 및 문제 해결에 제공된 지침을 따릅니다 .

설치 중에 네트워크가 구성된 경우 NIC에 대한 일부 항목이 이미있을 수 있습니다. 행을 추가하기 전에 /etc/rc.conf 를 다시 확인하십시오 .

DHCP 서버가 없으면 NIC를 수동으로 구성해야합니다. 다음 예와 같이 시스템에있는 각 NIC에 대한 행을 추가합니다.

ifconfig_dc0 = "inet 192.168.1.3 넷 마스크 255.255.255.0" ifconfig_dc1 = "inet 10.0.0.1 넷 마스크 255.255.255.0 미디어 10baseT / UTP"

dc0 및 dc1 과 IP 주소 정보를 시스템에 대한 올바른 값으로 바꿉니다 . 허용되는 옵션 및 /etc/rc.conf 구문에 대한 자세한 내용은 드라이버, ifconfig (8) 및 rc.conf (5) 매뉴얼 페이지를 참조하십시오 .

네트워크에서 DNS를 사용하지 않는 경우 / etc / hosts 를 편집 하여 LAN에있는 호스트의 이름과 IP 주소를 추가합니다 (아직없는 경우). 자세한 내용은 hosts (5) 및 / usr / share / examples / etc / hosts를 참조하십시오 .

DHCP 서버가없고 인터넷에 액세스해야하는 경우 기본 게이트웨이와 이름 서버를 수동으로 구성합니다.

12.5.3. 테스트 및 문제 해결

/etc/rc.conf에 필요한 변경 사항 이 저장되면 재부팅을 사용하여 네트워크 구성을 테스트하고 구성 오류없이 시스템이 다시 시작되는지 확인할 수 있습니다. 또는 다음 명령을 사용하여 네트워킹 시스템에 설정을 적용합니다.

# service netif restart

기본 게이트웨이가 /etc/rc.conf 에 설정된 경우 다음 명령도 실행하십시오.

네트워킹 시스템이 다시 시작되면 NIC를 테스트합니다.

12.5.3.1. 이더넷 카드 테스트

이더넷 카드가 올바르게 구성되어 있는지 확인하려면 핑 (8) 인터페이스 자체, 다음 핑 (8) LAN상의 다른 컴퓨터를 :

% ping -c5 192.168.1.3 PING 192.168.1.3 (192.168.1.3): 56 data bytes 64 bytes from 192.168.1.3: icmp_seq=0 ttl=64 time=0.082 ms 64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.074 ms 64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.076 ms 64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.108 ms 64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.076 ms --- 192.168.1.3 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.074/0.083/0.108/0.013 ms

% ping -c5 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.726 ms 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.766 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.700 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.747 ms 64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.704 ms --- 192.168.1.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms

네트워크 확인을 테스트하려면 IP 주소 대신 호스트 이름을 사용하십시오. 네트워크에 DNS 서버가 없으면 먼저 / etc / hosts 를 구성해야합니다. 이를 위해 / etc / hosts 를 편집 하여 LAN에있는 호스트의 이름과 IP 주소 (아직없는 경우)를 추가합니다. 자세한 내용은 hosts (5) 및 / usr / share / examples / etc / hosts를 참조하십시오 .

12.5.3.2. 문제 해결

하드웨어 및 소프트웨어 구성 문제를 해결할 때 먼저 간단한 사항을 확인하십시오. 네트워크 케이블이 연결되어 있습니까? 네트워크 서비스가 올바르게 구성되어 있습니까? 방화벽이 올바르게 구성되어 있습니까? FreeBSD에서 NIC를 지원합니까? 버그 보고서를 보내기 전에 항상 하드웨어 노트를 확인하고 FreeBSD 버전을 최신 STABLE 버전으로 업데이트하고 메일 링리스트 아카이브를 확인하고 인터넷을 검색하십시오.

카드는 작동하지만 성능이 좋지 않으면 tuning (7)을 읽어보십시오 . 또한 잘못된 네트워크 설정으로 인해 연결 속도가 느려질 수 있으므로 네트워크 구성을 확인하십시오.

일부 사용자는 하나 또는 두 개의 device timeout메시지를 경험 하는데, 이는 일부 카드의 경우 정상입니다. 계속되거나 성가신 경우 장치가 다른 장치와 충돌하는지 확인하십시오. 케이블 연결을 다시 확인하십시오. 다른 카드를 사용해보십시오.

watchdog timeout오류 를 해결하려면 먼저 네트워크 케이블을 확인하십시오. 많은 카드에는 버스 마스터 링을 지원하는 PCI 슬롯이 필요합니다. 일부 오래된 마더 보드에서는 하나의 PCI 슬롯 (일반적으로 슬롯 0) 만 허용합니다. NIC 및 마더 보드 설명서를 확인하여 문제인지 확인하십시오.

No route to host시스템이 패킷을 대상 호스트로 라우팅 할 수없는 경우 메시지가 발생합니다. 이는 기본 경로가 지정되지 않았거나 케이블이 분리 된 경우 발생할 수 있습니다. 의 출력을 netstat -rn확인하고 호스트에 대한 유효한 경로가 있는지 확인하십시오. 없는 경우 "게이트웨이 및 경로"를 읽으십시오 .

ping: sendto: Permission denied오류 메시지는 종종 잘못 구성된 방화벽으로 인해 발생합니다. 방화벽이 FreeBSD에서 활성화되었지만 규칙이 정의되지 않은 경우 기본 정책은 모든 트래픽을 거부하는 것 입니다. ping (8) 조차도 거부합니다 . 자세한 내용은 방화벽 을 참조하십시오.

때때로 카드의 성능이 나쁘거나 평균 이하입니다. 이러한 경우 미디어 선택 모드 autoselect를에서 올바른 미디어 선택으로 설정해보십시오 . 대부분의 하드웨어에서 작동하지만 문제가 해결 될 수도 있고 해결되지 않을 수도 있습니다. 다시 모든 네트워크 설정을 확인하고 tuning (7)을 참조하십시오 .

12.6. 가상 호스트

FreeBSD의 일반적인 용도는 가상 사이트 호스팅으로, 하나의 서버가 네트워크에 여러 서버로 나타납니다. 이는 단일 인터페이스에 여러 네트워크 주소를 할당하여 수행됩니다.

주어진 네트워크 인터페이스에는 하나의 "실제"주소가 있으며 "별칭"주소는 얼마든지 가질 수 있습니다. 이러한 별칭은 일반적 으로이 예제에서 볼 수 있듯이 /etc/rc.conf에 별칭 항목을 배치하여 추가됩니다 .

ifconfig_fxp0_alias0 = "inet xxx.xxx.xxx.xxx 넷 마스크 xxx.xxx.xxx.xxx"

별칭 항목은 , 등의 순차 번호 를 사용하여 시작해야합니다 . 구성 프로세스는 첫 번째 누락 된 번호에서 중지됩니다.alias0alias0alias1

별칭 넷 마스크 계산은 중요합니다. 주어진 인터페이스에 대해 네트워크의 넷 마스크를 올바르게 나타내는 하나의 주소가 있어야합니다. 이 네트워크에 속하는 다른 주소 1에는 255.255.255.255또는 로 표시되는 모든 의 넷 마스크가 있어야합니다 0xffffffff.

예를 들어, 경우에 고려 fxp0에서 : 인터페이스는 두 네트워크에 접속된다 10.1.1.0의 넷 마스크 255.255.255.0와 202.0.75.16의 넷 마스크를 255.255.255.240. 시스템이 범위에 나타나도록 구성 될 10.1.1.1통해 10.1.1.5및 202.0.75.17통해서 202.0.75.20. 주어진 네트워크 범위의 첫 번째 주소에만 실제 넷 마스크가 있어야합니다. 모든 나머지는 ( 10.1.1.2통해 10.1.1.5과 202.0.75.18를 통해 202.0.75.20)의 넷 마스크로 구성되어야합니다 255.255.255.255.

다음 /etc/rc.conf 항목은이 시나리오에 맞게 어댑터를 올바르게 구성합니다.

ifconfig_fxp0 = "inet 10.1.1.1 넷 마스크 255.255.255.0" ifconfig_fxp0_alias0 = "inet 10.1.1.2 넷 마스크 255.255.255.255" ifconfig_fxp0_alias1 = "inet 10.1.1.3 넷 마스크 255.255.255.255" ifconfig_fxp0_alias2 = "inet 10.1.1.4 넷 마스크 255.255.255.255" ifconfig_fxp0_alias3 = "inet 10.1.1.5 넷 마스크 255.255.255.255" ifconfig_fxp0_alias4 = "inet 202.0.75.17 넷 마스크 255.255.255.240" ifconfig_fxp0_alias5 = "inet 202.0.75.18 넷 마스크 255.255.255.255" ifconfig_fxp0_alias6 = "inet 202.0.75.19 넷 마스크 255.255.255.255" ifconfig_fxp0_alias7 = "inet 202.0.75.20 넷 마스크 255.255.255.255"

이를 표현하는 더 간단한 방법은 공백으로 구분 된 IP 주소 범위 목록을 사용하는 것입니다. 첫 번째 주소에는 표시된 서브넷 마스크가 지정되고 추가 주소에는의 서브넷 마스크가 255.255.255.255있습니다.

ifconfig_fxp0_aliases = "inet 10.1.1.1-5 / 24 inet 202.0.75.17-20 / 28"

12.7. 시스템 로깅 구성

시스템 로그를 생성하고 읽는 것은 시스템 관리의 중요한 측면입니다. 시스템 로그의 정보는 하드웨어 및 소프트웨어 문제는 물론 응용 프로그램 및 시스템 구성 오류를 감지하는 데 사용할 수 있습니다. 이 정보는 보안 감사 및 사고 대응에도 중요한 역할을합니다. 대부분의 시스템 데몬 및 응용 프로그램은 로그 항목을 생성합니다.

FreeBSD는 로깅을 관리하기 위해 시스템 로거 syslogd를 제공합니다. 기본적으로 syslogd는 시스템이 부팅 될 때 시작됩니다. 이것은 /etc/rc.conf 의 변수 syslogd_enable에 의해 제어됩니다 . 사용하여 설정할 수 있습니다 수많은 응용 프로그램 인수가 있습니다 에 /etc/rc.conf에가 . 를 참조 하여 syslogd (8) 가능한 인수에 대한 자세한 내용은.syslogd_flags

이 섹션에서는 로컬 및 원격 로깅을 위해 FreeBSD 시스템 로거를 구성하는 방법과 로그 회전 및 로그 관리를 수행하는 방법에 대해 설명합니다.

12.7.1. 로컬 로깅 구성

구성 파일 /etc/syslog.conf 는 수신 된 로그 항목으로 syslogd가 수행하는 작업을 제어 합니다 . 수신 이벤트 처리를 제어하는 여러 매개 변수가 있습니다. 이 기능 은 커널 또는 데몬과 같은 메시지를 생성 한 하위 시스템을 설명하고 레벨 은 발생한 이벤트의 심각도를 설명합니다. 이를 통해 시설 및 수준에 따라 로그 메시지를 기록할지 여부와 위치를 구성 할 수 있습니다. 메시지를 보낸 애플리케이션과 원격 로깅의 경우 로깅 이벤트를 생성하는 머신의 호스트 이름에 따라 조치를 취하는 것도 가능합니다.

이 구성 파일에는 작업 당 한 줄이 포함되어 있습니다. 각 줄의 구문은 선택기 필드와 작업 필드입니다. 선택기 필드의 구문은 시설 수준 이상 에서 시설의 로그 메시지와 일치하는 시설 수준 입니다. 로깅되는 내용을보다 정확하게 지정하기 위해 레벨 앞에 선택적 비교 플래그를 추가 할 수도 있습니다. 동일한 작업에 여러 선택기 필드를 사용할 수 있으며 세미콜론 ( ) 으로 구분 됩니다. 사용 하면 모든 것이 일치합니다. 작업 필드는 파일 또는 원격 로그 호스트와 같은 로그 메시지를 보낼 위치를 나타냅니다. 예를 들어, 다음은 FreeBSD 의 기본 syslog.conf 입니다.;*

# $ FreeBSD $ # # 공백은이 파일에서 유효한 필드 구분 기호입니다. 하나, # 다른 * nix와 유사한 시스템은 여전히 탭을 필드로 사용하도록 고집합니다. # 구분자. 시스템간에이 파일을 공유하는 경우 # 여기서는 탭만 필드 구분자로 사용할 수 있습니다. # syslog.conf (5) 맨 페이지를 참조하십시오. * .err; kern.warning; auth.notice; mail.crit / dev / console * .notice; authpriv.none; kern.debug; lpr.info; mail.crit; news.err / var / log / messages 보안. * / var / log / security auth.info; authpriv.info /var/log/auth.log mail.info / var / log / maillog lpr.info / var / log / lpd-errs ftp.info / var / log / xferlog cron. * / var / log / cron ! -devd *. = debug /var/log/debug.log * .emerg * # 주석을 제거하여 / dev / console에 대한 모든 쓰기를 /var/log/console.log에 기록합니다. # console.info /var/log/console.log # 모든 로그 메시지를 /var/log/all.log에 기록하려면 주석을 제거하십시오. # /var/log/all.log를 터치하고 작동하기 전에 모드 600으로 chmod합니다. # *. * /var/log/all.log # loghost라는 원격 로그 호스트에 로깅을 활성화하려면 주석을 제거하십시오. # *. * @loghost # inn을 실행하는 경우 주석을 제거하십시오. # news.crit /var/log/news/news.crit # news.err /var/log/news/news.err # news.notice /var/log/news/news.notice # devd가 생성 한 메시지를보고 싶다면 주석을 제거하십시오. #! devd # *.> = 정보 ! ppp *. * /var/log/ppp.log ! *

이 예에서 :

8 행의 수준으로 모든 메시지를 일치 err뿐만 아니라, 이상 kern.warning, auth.notice그리고 mail.crit, 콘솔 (이러한 로그 메시지를 보낸다 는 / dev / 콘솔 ).
12 행 mail은 레벨 info이상의 시설에서 보낸 모든 메시지와 일치 하고 메시지를 / var / log / maillog에 기록 합니다.
17 행은 비교 플래그 ( =)를 사용하여 수준의 메시지 만 일치 debug시키고 /var/log/debug.log에 기록합니다 .
33 행은 프로그램 사양의 사용 예입니다. 이렇게하면 다음 규칙이 지정된 프로그램에 대해서만 유효합니다. 이 경우 ppp에 의해 생성 된 메시지 만 /var/log/ppp.log에 기록됩니다 .

적어도 가장에서 순서대로 가능한 수준, 중요하다 emerg, alert, crit, err, warning, notice, info,와 debug.

시설, 특별한 순서없이,있는 auth, authpriv, console, cron, daemon, ftp, kern, lpr, mail, mark, news, security, syslog, user, uucp,과 local0를 통해 local7. 다른 운영 체제에는 다른 기능이있을 수 있습니다.

레벨 notice이상의 모든 것을 /var/log/daemon.log에 기록하려면 다음 항목을 추가하십시오.

daemon.notice /var/log/daemon.log

다양한 레벨 및 기능에 대한 자세한 내용은 syslog (3) 및 syslogd (8)를 참조하십시오 . /etc/syslog.conf , 구문 및 고급 사용 예제 에 대한 자세한 내용 은 syslog.conf (5)를 참조하십시오 .

12.7.2. 로그 관리 및 회전

로그 파일은 빠르게 증가하여 디스크 공간을 차지하고 유용한 정보를 찾기가 더 어려워 질 수 있습니다. 로그 관리는이를 완화하려고합니다. FreeBSD에서 newsyslog는 로그 파일을 관리하는 데 사용됩니다. 이 내장 프로그램은 로그 파일을 주기적으로 회전 및 압축하고 선택적으로 누락 된 로그 파일을 생성하고 로그 파일이 이동 될 때 프로그램에 신호를 보냅니다. 로그 파일은 syslogd 또는 로그 파일을 생성하는 다른 프로그램에 의해 생성 될 수 있습니다. newsyslog는 일반적으로 cron (8) 에서 실행되지만 시스템 데몬이 아닙니다. 기본 구성에서는 매시간 실행됩니다.

취할 조치를 알기 위해 newsyslog는 구성 파일 /etc/newsyslog.conf를 읽습니다 . 이 파일은 newsyslog가 관리하는 각 로그 파일에 대해 한 줄을 포함합니다. 각 줄에는 파일 소유자, 권한, 해당 파일을 회전 할시기, 압축과 같은 로그 회전에 영향을주는 선택적 플래그, 로그가 회전 될 때 신호를 보내는 프로그램이 나와 있습니다. 다음은 FreeBSD의 기본 구성입니다.

# newsyslog 용 구성 파일 # $ FreeBSD $ # # '/ pid_file'필드를 지정하지 않은 항목은 # 로그 파일이 회전 될 때 신호를받을 syslogd 프로세스. 이 # 작업은 사용자가 작성한 로그 파일에만 적합합니다. # syslogd 프로세스 (즉, /etc/syslog.conf에 나열된 파일). 만약 거기에 # 주어진 로그 파일이있을 때 신호를 보내야하는 프로세스가 없습니다. # 회전하면 해당 파일의 항목에 'N'플래그가 포함되어야합니다. # # 'flags'필드는 BCDGJNUXZ 또는 '-'문자 중 하나 이상입니다. # # 참고 : 일부 사이트는 # 기본값. 특히 많은 644를 전환하는 것이 바람직 할 수 있습니다. # 항목은 640 또는 600입니다. 예를 들어 일부 사이트에서는 # 메일 로그, 메시지 및 lpd-errs의 내용은 기밀로 유지됩니다. 에서 # 앞으로 이러한 기본값은보다 보수적 인 기본값으로 변경 될 수 있습니다. # # logfilename [owner : group] 모드 카운트 크기, 플래그 [/ pid_file] [sig_num] /var/log/all.log 600 7 * @ T00 J /var/log/amd.log 644 7100 * J /var/log/auth.log 600 7100 @ 0101T JC /var/log/console.log 600 5100 * J / var / log / cron 600 3100 * JC /var/log/daily.log 640 7 * @ T00 JN /var/log/debug.log 600 7100 * JC /var/log/kerberos.log 600 7100 * J / var / log / lpd-errs 644 7100 * JC / var / log / maillog 640 7 * @ T00 JC / var / log / messages 644 5100 @ 0101T JC /var/log/monthly.log 640 12 * $ M1D0 JN / var / log / pflog 600 3100 * JB /var/run/pflogd.pid /var/log/ppp.log root : network 640 3100 * JC /var/log/devd.log 644 3100 * JC / var / log / security 600 10100 * JC /var/log/sendmail.st 640 10 * 168 B /var/log/utx.log 644 3 * @ 01T05 B /var/log/weekly.log 640 5 1 $ W6D0 JN / var / log / xferlog 600 7100 * JC

각 행은 회전 할 로그의 이름으로 시작하며, 선택적으로 회전 된 파일과 새로 작성된 파일 모두에 대한 소유자 및 그룹이 뒤 따릅니다. 이 mode필드는 로그 파일에 대한 권한을 설정하고 count보관해야하는 회전 된 로그 파일 수를 나타냅니다. size및 when파일을 회전 할 때 필드는 newsyslog 말한다. 로그 파일은 크기가 size필드 보다 크거나 필드의 시간 when이 지나면 회전됩니다 . 별표 ( *)는이 필드가 무시됨을 의미합니다. 플래그필드는 회전 된 파일을 압축하는 방법이나 누락 된 경우 로그 파일을 만드는 방법과 같은 추가 지침을 제공합니다. 마지막 두 필드는 선택 사항이며 프로세스의 PID (Process ID) 파일 이름과 파일이 회전 될 때 해당 프로세스로 보낼 신호 번호를 지정합니다.

모든 필드, 유효한 플래그 및 회전 시간 지정 방법에 대한 자세한 내용은 newsyslog.conf (5)를 참조하십시오 . newsyslog가에서 실행되기 때문에 크론 (8) , 그것은 더 자주가에서 실행되도록 예약 된 것보다 회전하지 파일을 할 수 크론 (8) .

12.7.3. 원격 로깅 구성

여러 호스트의 로그 파일을 모니터링하는 것은 시스템 수가 증가함에 따라 다루기 어려울 수 있습니다. 중앙 집중식 로깅을 구성하면 로그 파일 관리의 일부 관리 부담을 줄일 수 있습니다.

FreeBSD에서는 syslogd 및 newsyslog를 사용하여 중앙 집중식 로그 파일 집계, 병합 및 회전을 구성 할 수 있습니다. 이 섹션에서는 구성 예를 보여줍니다. 여기서 host A라는 이름 logserv.example.com은 로컬 네트워크에 대한 로깅 정보를 수집합니다. B이름이 logclient.example.com인 호스트 는 로깅 정보를 로깅 서버에 전달하도록 구성됩니다.

12.7.3.1. 로그 서버 구성

로그 서버는 다른 호스트의 로깅 정보를 허용하도록 구성된 시스템입니다. 로그 서버를 구성하기 전에 다음을 확인하십시오.

로깅 서버와 로깅 클라이언트 사이에 방화벽이있는 경우 방화벽 규칙 집합이 클라이언트와 서버 모두에 대해 UDP 포트 514를 허용하는지 확인합니다.
로깅 서버와 모든 클라이언트 컴퓨터에는 로컬 DNS에 정방향 및 역방향 항목이 있어야합니다. 네트워크에 DNS 서버가없는 경우 각 시스템의 / etc / hosts에 항목을 만듭니다 . 로그 항목이 로깅 서버에서 거부되지 않도록 적절한 이름 확인이 필요합니다.

로그 서버에서 /etc/syslog.conf 를 편집 하여 로그 항목을 수신 할 클라이언트 이름, 사용할 로깅 기능 및 호스트의 로그 항목을 저장할 로그 이름을 지정하십시오. 이 예에서는의 호스트 이름을 추가하고 B모든 시설을 기록하며 로그 항목을 /var/log/logclient.log에 저장합니다 .

예 1. 샘플 로그 서버 구성

+ logclient.example.com *. * /var/log/logclient.log

여러 로그 클라이언트를 추가 할 때 각 클라이언트에 대해 유사한 두 줄 항목을 추가하십시오. 사용 가능한 기능에 대한 자세한 정보는 syslog.conf (5) 에서 찾을 수 있습니다 .

다음으로 /etc/rc.conf를 구성하십시오 .

syslogd_enable = "예" syslogd_flags = "-a logclient.example.com -v -v"

첫 번째 항목은 시스템 부팅시 syslogd를 시작합니다. 두 번째 항목은 지정된 클라이언트의 로그 항목을 허용합니다. 는 -v -v로그 메시지의 상세를 증가시킨다. 이것은 관리자가 각 시설에서 어떤 유형의 메시지가 기록되고 있는지 볼 수 있기 때문에 시설을 조정하는 데 유용합니다.

-a여러 클라이언트에서 로깅을 허용하기 위해 여러 옵션을 지정할 수 있습니다. IP 주소와 전체 넷 블록도 지정할 수 있습니다. 가능한 옵션의 전체 목록은 syslogd (8) 를 참조하십시오 .

마지막으로 로그 파일을 만듭니다.

# touch /var/log/logclient.log

이 시점에서 syslogd를 다시 시작하고 확인해야합니다.

# service syslogd restart # pgrep syslog

PID가 반환되면 서버가 성공적으로 다시 시작되고 클라이언트 구성을 시작할 수 있습니다. 서버가 다시 시작되지 않은 경우 / var / log / messages 에서 오류를 참조하십시오 .

12.7.3.2. 로그 클라이언트 구성

로깅 클라이언트는 로그 항목을 네트워크의 로깅 서버로 보냅니다. 클라이언트는 또한 자체 로그의 로컬 사본을 유지합니다.

로깅 서버가 구성되면 로깅 클라이언트에서 /etc/rc.conf 를 편집 합니다.

syslogd_enable = "예" syslogd_flags = "-s -v -v"

첫 번째 항목은 부팅시 syslogd를 활성화합니다. 두 번째 항목은이 클라이언트가 다른 호스트 ( -s) 에서 로그를 수락하는 것을 방지 하고 로깅 된 메시지의 상세도를 높입니다.

다음으로 클라이언트의 /etc/syslog.conf 에 로깅 서버를 정의하십시오 . 이 예에서 기록 된 모든 기능은 @지정된 호스트 이름과 함께 기호 로 표시된 원격 시스템으로 전송됩니다 .

*. * @ logserv.example.com

편집 내용을 저장 한 후 syslogd를 다시 시작하여 변경 사항을 적용하십시오.

# service syslogd restart

로그 메시지가 네트워크를 통해 전송되는지 테스트하려면 클라이언트에서 logger (1) 을 사용 하여 syslogd에 메시지를 보냅니다.

# logger "Test message from logclient"

이 메시지는 이제 클라이언트의 / var / log / messages 와 로그 서버의 /var/log/logclient.log 에 모두 존재해야 합니다.

12.7.3.3. 로그 서버 디버깅

로그 서버에서 메시지가 수신되지 않는 경우 원인은 네트워크 연결 문제, 호스트 이름 확인 문제 또는 구성 파일의 오타 일 가능성이 높습니다. 원인을 분리하려면 로깅 서버와 로깅 클라이언트가 모두 /etc/rc.conf에ping 지정된 호스트 이름을 사용하여 서로를 사용할 수 있는지 확인하십시오 . 이것이 실패하면 네트워크 케이블, 방화벽 규칙 세트 및 DNS 서버의 호스트 이름 항목 또는 로깅 서버와 클라이언트 모두의 / etc / hosts 를 확인하십시오. 두 호스트에서 성공할 때까지 반복 합니다.ping

ping두 호스트 모두 에서 성공했지만 로그 메시지가 여전히 수신되지 않는 경우 일시적으로 로깅 세부 정보를 늘려 구성 문제를 좁 힙니다. 다음 예 에서 로깅 서버의 /var/log/logclient.log 는 비어 있고 로깅 클라이언트의 / var / log / messages 는 실패 이유를 나타내지 않습니다. 디버깅 출력을 늘리려면 syslogd_flags로깅 서버 의 항목을 편집하고 다시 시작하십시오.

syslogd_flags = "-d -a logclient.example.com -v -v"

# service syslogd restart

다음과 유사한 디버깅 데이터는 재시작 직후 콘솔에서 깜박입니다.

logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel Logging to FILE /var/log/messages syslogd: kernel boot file is /boot/kernel/kernel cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; rejected in rule 0 due to name mismatch.

이 예에서는 호스트 이름이 일치하지 않는 오타로 인해 로그 메시지가 거부됩니다. 클라이언트의 호스트 이름은해야 logclient하지 logclien. 오타를 수정하고 다시 시작하고 결과를 확인합니다.

# service syslogd restart logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel syslogd: kernel boot file is /boot/kernel/kernel logmsg: pri 166, flags 17, from logserv.example.com, msg Dec 10 20:55:02 <syslog.err> logserv.example.com syslogd: exiting on signal 2 cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; accepted in rule 0. logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2 Logging to FILE /var/log/logclient.log Logging to FILE /var/log/messages

이 시점에서 메시지가 제대로 수신되고 올바른 파일에 배치됩니다.

12.7.3.4. 보안 고려 사항

다른 네트워크 서비스와 마찬가지로 로깅 서버를 구현하기 전에 보안 요구 사항을 고려해야합니다. 로그 파일에는 로컬 호스트에서 활성화 된 서비스, 사용자 계정 및 구성 데이터에 대한 중요한 데이터가 포함될 수 있습니다. 클라이언트에서 서버로 전송 된 네트워크 데이터는 암호화되거나 암호로 보호되지 않습니다. 암호화가 필요한 경우 보안 / stunnel 사용을 고려하여 암호화 된 터널을 통해 로깅 데이터를 전송합니다.

로컬 보안도 문제입니다. 로그 파일은 사용 중 또는 로그 회전 후에 암호화되지 않습니다. 로컬 사용자는 로그 파일에 액세스하여 시스템 구성에 대한 추가 정보를 얻을 수 있습니다. 로그 파일에 대한 적절한 권한을 설정하는 것이 중요합니다. 내장 된 로그 로테이터 인 newsyslog는 새로 생성되고 교체 된 로그 파일에 대한 권한 설정을 지원합니다. 로그 파일을 모드로 설정하면 600로컬 사용자의 원치 않는 액세스를 방지 할 수 있습니다. 추가 정보는 newsyslog.conf (5) 를 참조하십시오 .

12.8. 구성 파일

12.8.1. / etc 레이아웃

구성 정보가 보관되는 여러 디렉토리가 있습니다. 여기에는 다음이 포함됩니다.

/기타	일반 시스템 특정 구성 정보.
/ etc / defaults	시스템 구성 파일의 기본 버전.
/ etc / mail	추가 sendmail (8) 구성 및 기타 MTA 구성 파일.
/ etc / ppp	사용자 및 커널 PPP 프로그램 모두에 대한 구성.
/ usr / local / etc	설치된 애플리케이션에 대한 구성 파일. 응용 프로그램 별 하위 디렉터리를 포함 할 수 있습니다.
/usr/local/etc/rc.d	설치된 응용 프로그램에 대한 rc (8) 스크립트.
/ var / db	자동으로 생성 된 시스템 별 데이터베이스 파일 (예 : 패키지 데이터베이스 및 Locate (1) 데이터베이스).

12.8.2. 호스트 이름

12.8.2.1. /etc/resolv.conf

FreeBSD 시스템이 인터넷 DNS (Domain Name System)에 액세스하는 방법은 resolv.conf (5)에 의해 제어됩니다 .

/etc/resolv.conf에 대한 가장 일반적인 항목 은 다음과 같습니다.

nameserver	확인자가 쿼리해야하는 이름 서버의 IP 주소입니다. 서버는 최대 3 개까지 나열된 순서대로 쿼리됩니다.
search	호스트 이름 조회를위한 검색 목록입니다. 이것은 일반적으로 로컬 호스트 이름의 도메인에 의해 결정됩니다.
domain	로컬 도메인 이름입니다.

일반적인 /etc/resolv.conf 는 다음과 같습니다.

example.com 검색 네임 서버 147.11.1.11 네임 서버 147.11.100.30

search및 domain옵션 중 하나만 사용해야합니다.

DHCP를 사용할 때 dhclient (8)는 일반적으로 DHCP 서버에서받은 정보로 /etc/resolv.conf 를 다시 작성 합니다.

12.8.2.2. / etc / hosts

/ etc / hosts 는 IP 주소 매핑에 호스트 이름을 제공하기 위해 DNS 및 NIS와 함께 작동하는 간단한 텍스트 데이터베이스입니다. LAN을 통해 연결된 로컬 컴퓨터에 대한 항목을 명명 된 (8) 서버 를 설정하는 대신 간단한 명명 목적으로이 파일에 추가 할 수 있습니다 . 또한 / etc / hosts 를 사용하여 인터넷 이름의 로컬 레코드를 제공 할 수 있으므로 일반적으로 액세스하는 이름에 대해 외부 DNS 서버를 쿼리 할 필요성을 줄일 수 있습니다.

# $ FreeBSD $ # # # 호스트 데이터베이스 # #이 파일은 다음과 같은 로컬 호스트의 주소와 별칭을 포함해야합니다. #이 파일을 공유합니다. 아래의 'my.domain'을 귀하의 도메인 이름으로 바꿉니다. # 기계. # # 도메인 이름 서비스 또는 NIS가있는 경우이 파일은 # 전혀 상담하지 않습니다. 해결 순서는 /etc/nsswitch.conf를 참조하십시오. # # :: 1 localhost localhost.my.domain 127.0.0.1 localhost localhost.my.domain # # 가상 네트워크. # 10.0.0.2 myname.my.domain myname # 10.0.0.3 myfriend.my.domain myfriend # # RFC 1918에 따르면 다음과 같은 IP 네트워크를 사용할 수 있습니다. # 인터넷에 연결되지 않는 개인 네트워크 : # # 10.0.0.0-10.255.255.255 # 172.16.0.0-172.31.255.255 # 192.168.0.0-192.168.255.255 # # 인터넷에 연결하려면 # 실제 공식 할당 번호. 자신의 네트워크를 만들려고하지 마십시오 # 번호 대신 네트워크 제공 업체 (있는 경우)에서 가져 오거나 지역 레지스트리 (ARIN, APNIC, LACNIC, RIPE NCC 또는 AfriNIC)에서 # #

/ etc / hosts 의 형식은 다음과 같습니다.

[인터넷 주소] [공식 호스트 이름] [별칭 1] [별칭 2] ...

예를 들면 다음과 같습니다.

10.0.0.1 myRealHostname.example.com myRealHostname foobar1 foobar2

자세한 내용은 hosts (5) 에 문의하십시오.

12.9. sysctl (8)을 사용한 튜닝

sysctl (8) 은 실행중인 FreeBSD 시스템을 변경하는 데 사용됩니다. 여기에는 숙련 된 시스템 관리자의 성능을 크게 향상시킬 수있는 TCP / IP 스택 및 가상 메모리 시스템의 많은 고급 옵션이 포함됩니다. sysctl (8)을 사용하여 500 개 이상의 시스템 변수를 읽고 설정할 수 있습니다 .

핵심에서 sysctl (8) 은 시스템 설정을 읽고 수정하는 두 가지 기능을 제공합니다.

읽을 수있는 모든 변수를 보려면 :

% sysctl -a

특정 변수를 읽으려면 이름을 지정하십시오.

% sysctl kern.maxproc kern.maxproc: 1044

특정 변수를 설정하려면 variable = value 구문을 사용하십시오 .

# sysctl kern.maxfiles=5000 kern.maxfiles: 2088 -> 5000

sysctl 변수의 설정은 일반적으로 문자열, 숫자 또는 부울이며, 여기서 부울은 1예 또는 0아니오입니다.

머신이 부팅 될 때마다 일부 변수를 자동으로 설정하려면 /etc/sysctl.conf에 추가하십시오 . 자세한 내용은 sysctl.conf (5) 및 sysctl.conf를 참조하십시오 .

12.9.1. sysctl.conf

sysctl (8) , /etc/sysctl.conf 의 구성 파일은 /etc/rc.conf 와 매우 유사 합니다. 값은 variable=value형식 으로 설정됩니다 . 지정된 값은 시스템이 다중 사용자 모드로 전환 된 후에 설정됩니다. 이 모드에서 모든 변수를 설정할 수있는 것은 아닙니다.

예를 들어 치명적인 신호 종료의 로깅을 끄고 사용자가 다른 사용자가 시작한 프로세스를 보지 못하도록하려면 /etc/sysctl.conf에 다음 튜너 블을 설정할 수 있습니다 .

# 치명적인 신호 종료를 기록하지 않습니다 (예 : sig 11). kern.logsigexit = 0 # 사용자가 프로세스에 대한 정보를 보지 못하도록 방지 # 다른 UID에서 실행되고 있습니다. security.bsd.see_other_uids = 0

12.9.2. sysctl (8) 읽기 전용

어떤 경우 에는 시스템을 재부팅해야하는 읽기 전용 sysctl (8) 값 을 수정하는 것이 바람직 할 수 있습니다 .

예를 들어, 일부 랩톱 모델에서 cardbus (4) 장치는 메모리 범위를 검색하지 않고 다음과 유사한 오류와 함께 실패합니다.

cbb0: Could not map register memory device_probe_and_attach: cbb0 attach returned 12

수정을 위해서는 읽기 전용 sysctl (8) 설정을 수정해야합니다 . 추가 hw.pci.allow_unsupported_io_range=1로 /boot/loader.conf에 재부팅. 이제 cardbus (4) 가 제대로 작동합니다.

12.10. 디스크 튜닝

다음 섹션에서는 디스크 장치에 적용될 수있는 다양한 조정 메커니즘 및 옵션에 대해 설명합니다. 대부분의 경우 SCSI 드라이브와 같은 기계 부품이있는 디스크는 전체 시스템 성능을 저하시키는 병목 현상이됩니다. 해결책은 솔리드 스테이트 드라이브와 같은 기계 부품없이 드라이브를 설치하는 것이지만 기계 드라이브는 가까운 장래에 없어지지 않습니다. 디스크를 조정할 때 iostat (8) 명령 의 기능을 사용 하여 시스템의 다양한 변경 사항을 테스트 하는 것이 좋습니다 . 이 명령을 사용하면 사용자가 시스템 IO에 대한 중요한 정보를 얻을 수 있습니다.

12.10.1. Sysctl 변수

12.10.1.1. vfs.vmiodirenable

vfs.vmiodirenable sysctl을 (8) 변수로 설정 될 수있다 0(OFF) 또는 1(ON). 1기본적으로 로 설정되어 있습니다. 이 변수는 시스템이 디렉토리를 캐시하는 방법을 제어합니다. 대부분의 디렉토리는 파일 시스템에서 단일 조각 (일반적으로 1K) 만 사용하고 일반적으로 버퍼 캐시에서 512 바이트를 사용하여 작습니다. 이 변수를 끄면 시스템에 엄청난 양의 메모리가 있더라도 버퍼 캐시는 고정 된 수의 디렉토리 만 캐시합니다. 켜면이 sysctl (8)버퍼 캐시가 VM 페이지 캐시를 사용하여 디렉토리를 캐시 할 수 있도록하여 모든 메모리를 캐시 디렉토리에 사용할 수 있도록합니다. 그러나 디렉토리를 캐시하는 데 사용되는 최소 인 코어 메모리는 512 바이트가 아닌 실제 페이지 크기 (일반적으로 4K)입니다. 시스템이 많은 수의 파일을 조작하는 서비스를 실행하는 경우이 옵션을 활성화 된 상태로 유지하는 것이 좋습니다. 이러한 서비스에는 웹 캐시, 대용량 메일 시스템 및 뉴스 시스템이 포함될 수 있습니다. 이 옵션을 켜두면 메모리가 낭비 되더라도 일반적으로 성능이 저하되지는 않지만 알아 내기 위해 실험해야합니다.

12.10.1.2. vfs.write_behind

vfs.write_behind sysctl을 (8) 에 변수 기본값 1(에). 이는 전체 클러스터가 수집 될 때 미디어 쓰기를 실행하도록 파일 시스템에 지시합니다. 이는 일반적으로 큰 순차 파일을 쓸 때 발생합니다. 이렇게하면 I / O 성능에 도움이되지 않을 때 더티 버퍼로 버퍼 캐시가 포화되는 것을 방지 할 수 있습니다. 그러나 이로 인해 프로세스가 중단 될 수 있으며 특정 상황에서는 꺼야합니다.

12.10.1.3. vfs.hirunningspace

vfs.hirunningspace sysctl을 (8) 변수는 훨씬 뛰어난 쓰기 I / O가 주어진 예에서 시스템 전체 디스크 컨트롤러에 대기 할 수있는 방법을 결정합니다. 일반적으로 기본값이면 충분하지만 디스크가 많은 시스템에서는 최대 4 ~ 5MB 까지 확장 해보세요 . 버퍼 캐시의 쓰기 임계 값을 초과하는 값을 너무 높게 설정하면 클러스터링 성능이 저하 될 수 있습니다. 쓰기 값이 높을수록 동시에 발생하는 읽기에 대기 시간이 추가 될 수 있으므로이 값을 임의로 높게 설정하지 마십시오.

다른 다양한 버퍼 캐시 및 VM 페이지 캐시 관련 sysctl (8) 값이 있습니다. 이러한 값을 수정하는 것은 VM 시스템이 자동으로 조정되는 좋은 작업을 수행하므로 권장되지 않습니다.

12.10.1.4. vm.swap_idle_enabled

vm.swap_idle_enabled sysctl을 (8) 변수가 많은 활성 로그인 사용자와 유휴 프로세스의 많은 대규모 다중 사용자 시스템에 유용하다. 이러한 시스템은 여유 메모리 예약에 지속적으로 압력을 가하는 경향이 있습니다. 이 기능을 켜고 통해 (유휴 초) swapout의 이력을 조정 vm.swap_idle_threshold1하고vm.swap_idle_threshold2유휴 프로세스와 관련된 메모리 페이지의 우선 순위를 일반 페이지 아웃 알고리즘보다 더 빠르게 낮 춥니 다. 이것은 pageout 데몬에 도움을줍니다. 필요한 경우에만이 옵션을 켜십시오. 기본적으로 더 많은 스왑 및 디스크 대역폭을 차지하는 나중에 메모리를 미리 페이지에 저장하는 것이 중요하기 때문입니다. 소규모 시스템에서이 옵션은 결정 가능한 효과를 갖지만 이미 중간 수준의 페이징을 수행하고있는 대규모 시스템에서는이 옵션을 사용하여 VM 시스템이 전체 프로세스를 메모리 안팎으로 쉽게 스테이징 할 수 있습니다.

12.10.1.5. hw.ata.wc

IDE 쓰기 캐싱을 끄면 IDE 디스크에 대한 쓰기 대역폭이 줄어들지 만 때때로 하드 드라이브 공급 업체에서 도입 한 데이터 일관성 문제로 인해 필요할 수 있습니다. 문제는 쓰기가 완료 될 때 일부 IDE 드라이브가 거짓말을한다는 것입니다. IDE 쓰기 캐싱이 켜져 있으면 IDE 하드 드라이브는 순서에 상관없이 디스크에 데이터를 쓰고 디스크로드가 많을 때 일부 블록 쓰기를 무기한 지연시키는 경우가 있습니다. 충돌 또는 전원 장애로 인해 심각한 파일 시스템 손상이 발생할 수 있습니다. ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ hw.ata.wc sysctl (8) 변수를 관찰하여 시스템의 기본값을 확인하십시오 . IDE 쓰기 캐싱이 꺼져있는 경우, 하나는이 읽기 전용 변수를 설정할 수 있습니다 1에 /boot/loader.conf에 부팅시 활성화하기 위해.

자세한 내용은 ata (4)를 참조하십시오 .

12.10.1.6. SCSI_DELAY( kern.cam.scsi_delay)

SCSI_DELAY커널 설정 옵션은 시스템 부팅 시간을 단축하기 위해 사용될 수있다. 기본값은 상당히 높으며 15부팅 프로세스에서 몇 초간 지연 될 수 있습니다 . 5초 단위로 줄이는 것은 일반적으로 최신 드라이브에서 작동합니다. kern.cam.scsi_delay부팅 시간 조정을 사용해야합니다. 튜너 블 커널 구성 옵션의 측면에서 값을 허용 밀리 초 와 없는 초 .

12.10.2. 소프트 업데이트

파일 시스템을 미세 조정하려면 tunefs (8)를 사용하십시오 . 이 프로그램에는 다양한 옵션이 있습니다. 소프트 업데이트를 켜고 끄려면 다음을 사용하십시오.

# tunefs -n enable /filesystem # tunefs -n disable /filesystem

파일 시스템 은 마운트 된 동안에는 tunefs (8) 로 수정할 수 없습니다 . 소프트 업데이트를 활성화하는 좋은시기는 단일 사용자 모드에서 파티션이 마운트되기 전입니다.

소프트 업데이트는 메모리 캐시를 사용하여 주로 파일 생성 및 삭제와 같은 메타 데이터 성능을 대폭 향상 시키므로 UFS 파일 시스템에 권장됩니다. 소프트 업데이트에는 두 가지 단점이 있습니다. 첫째, 소프트 업데이트는 충돌시 파일 시스템 일관성을 보장하지만 물리적 디스크 업데이트보다 몇 초 또는 1 분 늦을 수 있습니다. 시스템이 충돌하면 기록되지 않은 데이터가 손실 될 수 있습니다. 둘째, 소프트 업데이트는 파일 시스템 블록 해제를 지연시킵니다. 루트 파일 시스템이 거의 가득 찬 경우과 같은 주요 업데이트를 수행 make installworld하면 파일 시스템의 공간이 부족하여 업데이트가 실패 할 수 있습니다.

12.10.2.1. 소프트 업데이트에 대한 자세한 정보

메타 데이터 업데이트는 inode 또는 디렉토리와 같은 콘텐츠가 아닌 데이터에 대한 업데이트입니다. 파일 시스템의 메타 데이터를 디스크에 다시 쓰는 데는 두 가지 전통적인 접근 방식이 있습니다.

역사적으로 기본 동작은 메타 데이터 업데이트를 동 기적으로 작성하는 것이 었습니다. 디렉토리가 변경되면 시스템은 변경 사항이 실제로 디스크에 기록 될 때까지 기다렸습니다. 파일 데이터 버퍼 (파일 내용)는 버퍼 캐시를 통해 전달되고 나중에 비동기식으로 디스크에 백업됩니다. 이 구현의 장점은 안전하게 작동한다는 것입니다. 업데이트 중에 오류가 발생하면 메타 데이터는 항상 일관된 상태에 있습니다. 파일은 완전히 생성되거나 전혀 생성되지 않습니다. 충돌 시점까지 파일의 데이터 블록이 버퍼 캐시에서 디스크로가는 길을 찾지 못한 경우 fsck (8) 는이를 인식하고 파일 길이를 다음과 같이 설정하여 파일 시스템을 복구합니다.0. 또한 구현이 명확하고 간단합니다. 단점은 메타 데이터 변경이 느리다는 것입니다. 예를 들어 rm -r는 디렉토리의 모든 파일을 순차적으로 터치하지만 각 디렉토리 변경 사항은 디스크에 동 기적으로 기록됩니다. 여기에는 디렉토리 자체, inode 테이블 및 파일에 의해 할당 된 간접 블록에 대한 업데이트가 포함됩니다. .NET을 사용하여 대규모 계층 구조를 풀 때에도 유사한 고려 사항이 적용됩니다 tar -x.

두 번째 방법은 비동기 메타 데이터 업데이트를 사용하는 것입니다. 다음으로 마운트 된 UFS 파일 시스템의 기본값입니다.mount -o async. 모든 메타 데이터 업데이트도 버퍼 캐시를 통해 전달되기 때문에 파일 콘텐츠 데이터의 업데이트와 혼합됩니다. 이 구현의 장점은 각 메타 데이터 업데이트가 디스크에 기록 될 때까지 기다릴 필요가 없으므로 엄청난 양의 메타 데이터 업데이트를 유발하는 모든 작업이 동기식 경우보다 훨씬 빠르게 작동한다는 것입니다. 이 구현은 여전히 명확하고 간단하므로 코드에 버그가 발생할 위험이 적습니다. 단점은 파일 시스템의 일관된 상태에 대한 보장이 없다는 것입니다. 정전 또는 누군가가 재설정 버튼을 누르는 것과 같이 많은 양의 메타 데이터를 업데이트하는 작업 중에 오류가 발생하면 파일 시스템은 예측할 수없는 상태가됩니다. 파일의 데이터 블록이 이미 디스크에 기록되었을 수 있지만 inode 테이블이나 관련 디렉토리의 업데이트는 기록되지 않았기 때문에 시스템이 다시 시작될 때 파일 시스템의 상태를 검사 할 기회가 없습니다. 구현하는 것은 불가능합니다fsck (8) 는 디스크에서 필요한 정보를 사용할 수 없기 때문에 발생하는 혼돈을 정리할 수 있습니다. 파일 시스템이 복구 할 수 없을 정도로 손상된 경우 유일한 방법은 파일 시스템을 다시 포맷하고 백업에서 복원하는 것입니다.

이 문제에 대한 일반적인 해결책은 저널링 이라고도하는 더티 영역 로깅 을 구현 하는 것입니다.. 메타 데이터 업데이트는 여전히 동 기적으로 기록되지만 디스크의 작은 영역에만 기록됩니다. 나중에 적절한 위치로 이동합니다. 로깅 영역은 디스크에서 작고 연속적인 영역이므로 무거운 작업 중에도 디스크 헤드가 이동할 거리가 멀지 않으므로 이러한 작업이 동기 업데이트보다 빠릅니다. 또한 구현의 복잡성이 제한되어 버그가 발생할 위험이 낮습니다. 단점은 모든 메타 데이터가 로깅 영역에 한 번, 적절한 위치에 한 번씩 두 번 기록되므로 성능 "비 시화"가 발생할 수 있다는 것입니다. 반면에 충돌이 발생한 경우 모든 보류중인 메타 데이터 작업을 신속하게 롤백하거나 시스템이 다시 시작된 후 로깅 영역에서 완료 될 수 있으므로 파일 시스템이 빠르게 시작됩니다.

Berkeley FFS의 개발자 인 Kirk McKusick은 Soft Updates로이 문제를 해결했습니다. 모든 보류중인 메타 데이터 업데이트는 메모리에 보관되고 정렬 된 순서로 디스크에 기록됩니다 ( "정렬 된 메타 데이터 업데이트"). 이는 메타 데이터 작업이 많은 경우 나중에 항목에 대한 업데이트가 아직 메모리에 있고 디스크에 아직 기록되지 않은 이전 항목을 "잡는"효과가 있습니다. 모든 작업은 일반적으로 업데이트가 디스크에 기록되기 전에 메모리에서 수행되며 데이터 블록은 위치에 따라 정렬되어 메타 데이터보다 앞선 디스크에 있지 않습니다. 시스템이 충돌하면 암시 적 "로그 되감기"로 인해 디스크에 기록되지 않은 모든 작업이 발생하지 않은 것처럼 나타납니다. 일관된 파일 시스템 상태가 유지되며 30 초에서 60 초 이전에 해당하는 것처럼 보입니다. 사용 된 알고리즘은 사용중인 모든 리소스가 해당 블록 및 inode에 표시되도록 보장합니다. 충돌 후 발생하는 유일한 리소스 할당 오류는 리소스가 실제로 "사용 가능"인 "사용됨"으로 표시된다는 것입니다.fsck (8) 은이 상황을 인식하고 더 이상 사용되지 않는 리소스를 해제합니다. 을 사용하여 강제로 마운트하여 충돌 후 파일 시스템의 더티 상태를 무시하는 것이 안전합니다 mount -f. 사용하지 않을 수있는 리소스를 해제하려면 fsck (8) 을 나중에 실행해야합니다. 이것이 바로 백그라운드 fsck (8) 의 아이디어입니다 . 시스템 시작시 파일 시스템 의 스냅 샷 만 기록되고 fsck (8) 이 나중에 실행됩니다. 그런 다음 모든 파일 시스템을 "더티"로 마운트 할 수 있으므로 시스템 시작은 다중 사용자 모드에서 진행됩니다. 그런 다음 배경 fsck (8)사용하지 않을 수있는 리소스를 해제하기 위해 필요한 모든 파일 시스템에 대해 예약됩니다. 소프트 업데이트를 사용하지 않는 파일 시스템에는 여전히 일반적인 포 그라운드 fsck (8)이 필요합니다 .

장점은 메타 데이터 작업이 비동기 업데이트만큼 빠르며 메타 데이터를 두 번 써야하는 logging 보다 빠르다는 것 입니다. 단점은 코드의 복잡성, 더 높은 메모리 소비 및 약간의 특이성입니다. 충돌 후 파일 시스템의 상태는 다소 "오래된"것으로 보입니다. 표준 동기 방식으로 인해 길이가 0 인 파일이 fsck (8) 이후에 남아있는 상황에서 이러한 파일은 메타 데이터 나 파일 내용이 디스크에 기록되지 않았기 때문에 소프트 업데이트에 전혀 존재하지 않습니다. 업데이트가 디스크에 기록 될 때까지 디스크 공간이 해제되지 않습니다. 이는 rm (1)을 실행 한 후 얼마 동안 발생할 수 있습니다.. 이로 인해 모든 파일을 두 번 저장할 수있는 충분한 여유 공간이없는 파일 시스템에 많은 양의 데이터를 설치할 때 문제가 발생할 수 있습니다.

12.11. 커널 제한 조정

12.11.1. 파일 / 프로세스 제한

12.11.1.1. kern.maxfiles

kern.maxfiles sysctl을 (8) 변수가 발생 될 수 있거나 또는 시스템 요구 사항에 기초 낮췄다. 이 변수는 시스템의 최대 파일 설명자 수를 나타냅니다. 파일 설명자 테이블이 가득 차면 file: table is full시스템 메시지 버퍼에 반복적으로 표시되며 dmesg (8)를 사용하여 볼 수 있습니다 .

각 열린 파일, 소켓 또는 fifo는 하나의 파일 설명자를 사용합니다. 대규모 프로덕션 서버에는 동시에 실행되는 서비스의 종류와 수에 따라 수천 개의 파일 설명자가 쉽게 필요할 수 있습니다.

이전 FreeBSD 릴리스에서의 기본값 은 커널 구성 파일에서 kern.maxfiles파생되었습니다 maxusers. kern.maxfiles의 값에 비례하여 증가합니다 maxusers. 사용자 정의 커널을 컴파일 할 때 시스템 사용에 따라이 커널 구성 옵션을 설정하는 것을 고려하십시오. 이 숫자에서 커널에 미리 정의 된 제한의 대부분이 제공됩니다. 프로덕션 시스템에는 256 명의 동시 사용자가 없을 수 있지만 필요한 리소스는 대규모 웹 서버와 유사 할 수 있습니다.

읽기 전용 sysctl (8) 변수 kern.maxusers는 시스템에서 사용 가능한 메모리 양을 기준으로 부팅시 자동으로 크기가 조정되며 kern.maxusers. 일부 시스템은 크거나 작은 값이 필요 kern.maxusers하고 값을 64, 128그리고 256드물지 않다. 256많은 수의 파일 설명자가 필요한 경우가 아니면 위의 내용 은 권장되지 않습니다. 기본값으로 설정된 많은 튜너 블 값 kern.maxusers은 부팅시 또는 /boot/loader.conf 에서 런타임에 개별적으로 재정의 될 수 있습니다 . 를 참조하십시오 loader.conf (5) 와 /boot/defaults/loader.conf 자세한 내용과 몇 가지 힌트.

이전 릴리스에서는 maxusers로 설정되어 있으면 시스템이 자동 조정 됩니다 0. [ 1 ] . 이 옵션을 설정할 때 , 특히 시스템이 Xorg를 실행하거나 소프트웨어를 컴파일하는 데 사용되는 경우 maxusers이상으로 설정하십시오 4. 에서 설정하는 가장 중요한 테이블은로 설정된 maxusers최대 프로세스 수입니다 20 + 16 * maxusers. 이로 maxusers설정되어 있으면 부팅시 시스템이 시작 되도록하거나 Xorg에서 사용 하는 방식을 포함하여 동시 프로세스 1만있을 수 있습니다 . 매뉴얼 페이지를 읽는 것과 같은 간단한 작업조차도이를 필터링하고 압축을 풀고 볼 수있는 9 개의 프로세스를 시작합니다. 설정 하기 까지 허용361815maxusers641044거의 모든 용도에 충분해야합니다. 그러나 다른 프로그램을 시작하려고 할 때 오류가 표시되거나 서버가 많은 동시 사용자로 실행 중이면 수를 늘리고 다시 빌드하십시오.

maxusers기기에 로그인 할 수있는 사용자 수를 제한 하지 않습니다 . 대신 시스템의 최대 사용자 수와 각 사용자가 실행할 프로세스 수를 고려하여 다양한 테이블 크기를 적절한 값으로 설정합니다.

12.11.1.2. kern.ipc.soacceptqueue

kern.ipc.soacceptqueue sysctl을 (8) 변수는 새로운 수용하기위한 큐를 청취의 크기 제한 TCP연결. 기본값 128은 일반적으로로드가 많은 웹 서버에서 새 연결을 강력하게 처리하기에는 너무 낮습니다. 이러한 환경에서는이 값을 1024이상 으로 늘리는 것이 좋습니다 . sendmail (8) 또는 Apache 와 같은 서비스 는 자체적으로 수신 대기열 크기를 제한 할 수 있지만 종종 대기열 크기를 조정하기 위해 구성 파일에 지시문이 있습니다. 큰 수신 대기열은 서비스 거부 (DoS) 공격을 방지하는 데 더 효과적입니다.

12.11.2. 네트워크 제한

NMBCLUSTERS커널 설정 옵션은 시스템에 사용 가능한 네트워크 mbuf를의 양을 지시한다. Mbufs 수가 적고 트래픽이 많은 서버는 성능을 저하시킵니다. 각 클러스터는 약 2K의 메모리를 1024나타내 므로의 값은 2네트워크 버퍼 용으로 예약 된 메가 바이트의 커널 메모리 를 나타냅니다 . 필요한 수를 파악하기 위해 간단한 계산을 수행 할 수 있습니다. 1000각 연결 이 6K 수신 및 16K 전송 버퍼를 사용하는 동시 연결에서 최대치를 초과하는 웹 서버는 웹 서버를 처리 하기 위해 약 32MB의 네트워크 버퍼가 필요합니다. 좋은 경험 법칙은 곱하는 2것이므로 2x32 MB / 2 KB = 64 MB / 2 kB = 32768. 사이의 값 4096및32768더 많은 양의 메모리가있는 시스템에 권장됩니다. 부팅 시간이 중단 될 수 있으므로이 매개 변수에 대해 임의로 높은 값을 지정하지 마십시오. 네트워크 클러스터 사용량을 관찰하려면 netstat (1)-m 과 함께 사용하십시오 .

kern.ipc.nmbclusters로더 조정은 부팅시에 조정이 사용되어야한다. 이전 버전의 FreeBSD 만 NMBCLUSTERS커널 config (8) 옵션을 사용해야합니다 .

sendfile (2) 시스템 호출 을 광범위하게 사용하는 사용량이 많은 서버의 경우 커널 구성 옵션을 통해 또는 /boot/loader.conf 에서 해당 값을 설정하여 sendfile (2) 버퍼 수를 늘려야 할 수 있습니다 ( 로더 참조). 자세한 내용은 (8) 참조). 이 매개 변수를 조정해야하는 일반적인 지표는 프로세스가 해당 상태 에있을 때 입니다. sysctl에은 (8) 변수가 읽기 전용이다. 이 매개 변수는 명목상으로 확장 되지만 그에 따라 조정해야 할 수도 있습니다.NSFBUFSsfbufakern.ipc.nsfbufskern.maxusers

소켓이로 표시되어 있지만 호출 비 차단 에 sendfile (2) 발생할 수 비 블로킹 소켓 (2) sendfile을 충분히까지 차단 호출 struct sf_buf의가 사용할 수 있습니다.

12.11.2.1. net.inet.ip.portrange.*

net.inet.ip.portrange.* sysctl을 (8) 변수가 자동으로 결합 포트 번호 범위 제어 TCP및 UDP소켓. 낮은 범위, 기본 범위 및 높은 범위의 세 가지 범위가 있습니다. 대부분의 네트워크 프로그램은 기본에 의해 제어되는 범위 사용 net.inet.ip.portrange.first과 net.inet.ip.portrange.last에있는 기본 1024및5000, 각각. 바운드 포트 범위는 나가는 연결에 사용되며 특정 상황에서 포트에서 시스템을 실행할 수 있습니다. 이것은로드가 많은 웹 프록시를 실행할 때 가장 일반적으로 발생합니다. 포트 범위는 웹 서버와 같이 주로 들어오는 연결을 처리하거나 메일 릴레이와 같이 나가는 연결 수가 제한된 서버를 실행할 때 문제가되지 않습니다. 포트가 부족한 상황에서는 net.inet.ip.portrange.last적당히 늘리는 것이 좋습니다 . 값 10000, 20000또는30000합리적 일 수 있습니다. 포트 범위를 변경할 때 방화벽 효과를 고려하십시오. 일부 방화벽은 넓은 범위의 포트 (일반적으로 번호가 낮은 포트)를 차단할 수 있으며 시스템이 나가는 연결에 더 높은 범위의 포트를 사용할 것으로 예상합니다. 따라서의 값을 net.inet.ip.portrange.first낮추지 않는 것이 좋습니다 .

12.11.2.2. TCP대역폭 지연 제품

TCP대역폭 지연 제품 제한은 net.inet.tcp.inflight.enable sysctl (8) 변수를 로 설정하여 활성화 할 수 있습니다 1. 이렇게하면 시스템이 각 연결에 대한 대역폭 지연 제품을 계산하고 네트워크에 대기중인 데이터의 양을 최적의 처리량을 유지하는 데 필요한 양으로 제한하도록 지시합니다.

이 기능은 모뎀, 기가비트 이더넷, 고속 WAN링크 또는 고 대역폭 지연 제품이있는 기타 링크를 통해 데이터를 제공 할 때 유용합니다 . 특히 창 크기 조정을 사용하거나 큰 전송 창이 구성된 경우에 유용합니다. 이 옵션을 사용하면,도 설정 net.inet.tcp.inflight.debug을 0해제 디버깅. 프로덕션 용도의 경우 net.inet.tcp.inflight.min적어도로 설정 하면 6144도움이 될 수 있습니다. 높은 최소값을 설정하면 링크에 따라 대역폭 제한을 효과적으로 비활성화 할 수 있습니다. 제한 기능은 중간 경로 및 스위치 패킷 대기열에 구축 된 데이터의 양을 줄이고 로컬 호스트의 인터페이스 대기열에 구축 된 데이터의 양을 줄입니다. 대기열에있는 패킷 수가 적을 때 특히 느린 모뎀을 통한 대화 형 연결은 더 낮은 왕복 시간으로 작동합니다.. 이 기능은 업로드와 같은 서버 측 데이터 전송에만 영향을줍니다. 데이터 수신 또는 다운로드에는 영향을 미치지 않습니다.

조정 net.inet.tcp.inflight.stab은 권장 하지 않습니다. 이 매개 변수의 기본값은 20이며 대역폭 지연 제품 창 계산에 추가 된 최대 2 개의 패킷을 나타냅니다. 추가 창은 알고리즘을 안정화하고 변화하는 조건에 대한 응답 성을 개선하는 데 필요하지만 , 기내 알고리즘이없는 경우보다 훨씬 낮지 만 느린 링크 에서 더 높은 ping (8) 시간을 초래할 수도 있습니다 . 이러한 경우,이 매개 변수를 줄여보십시오 15, 10또는 5및 감소 net.inet.tcp.inflight.min와 같은 값으로하면 3500원하는 효과를 얻을 수 있습니다. 이러한 매개 변수를 줄이는 것은 최후의 수단으로 만 수행해야합니다.

12.11.3. 가상 메모리

12.11.3.1. kern.maxvnodes

vnode는 파일 또는 디렉토리의 내부 표현입니다. 운영 체제에서 사용할 수있는 vnode 수를 늘리면 디스크 I / O가 줄어 듭니다. 일반적으로 이것은 운영 체제에서 처리하며 변경할 필요가 없습니다. 디스크 I / O가 병목 상태이고 시스템에 vnode가 부족한 경우이 설정을 늘려야합니다. 비활성 및 여유 RAM의 양을 고려해야합니다.

현재 사용중인 vnode 수를 보려면 다음을 수행하십시오.

# sysctl vfs.numvnodes vfs.numvnodes: 91349

최대 vnode를 보려면 다음을 수행하십시오.

# sysctl kern.maxvnodes kern.maxvnodes: 100000

현재 vnode 사용량이 최대 kern.maxvnodes값에 가까우면 값만큼 늘려보십시오 1000. 의 수를 주시하십시오 vfs.numvnodes. 다시 최대치까지 올라가면 kern.maxvnodes더 증가해야합니다. 그렇지 않으면 top (1)에서 보고 한 메모리 사용량의 변화 가 표시되고 더 많은 메모리가 활성화되어야합니다.

12.12. 스왑 공간 추가

때로는 시스템에 더 많은 스왑 공간이 필요합니다. 이 섹션에서는 스왑 공간을 늘리는 두 가지 방법, 즉 기존 파티션이나 새 하드 드라이브에 스왑을 추가하는 방법과 기존 파티션에 스왑 파일을 만드는 방법에 대해 설명합니다.

스왑 공간을 암호화하는 방법, 존재하는 옵션 및 수행해야하는 이유에 대한 자세한 내용은 "스왑 암호화"를 참조하십시오 .

12.12.1. 새 하드 드라이브 또는 기존 파티션으로 교체

스왑을 위해 새 하드 드라이브를 추가하면 기존 드라이브의 파티션을 사용하는 것보다 성능이 향상됩니다. 설정 파티션과 하드 드라이브에 설명되어 있습니다 "추가 디스크" 동안 "파티션 레이아웃 디자인" 에 나와있는 파티션 레이아웃과 스왑 파티션 크기 고려 사항.

swapon시스템에 스왑 파티션을 추가하는 데 사용 합니다. 예를 들면 다음과 같습니다.

# swapon /dev/ada1s1b

이미 데이터가 포함되어 있어도 현재 마운트되지 않은 파티션을 사용할 수 있습니다. swapon데이터가 포함 된 파티션에서 사용하면 해당 데이터를 덮어 쓰고 삭제합니다. 실행하기 전에 스왑으로 추가 할 파티션이 실제로 의도 한 파티션인지 확인하십시오 swapon.

부팅시이 스왑 파티션을 자동으로 추가하려면 / etc / fstab에 항목을 추가하십시오 .

/ dev / ada1s1b 없음 스왑 sw 00

/ etc / fstab 의 항목에 대한 설명은 fstab (5) 를 참조하십시오 . 자세한 내용은 swapon (8) 에서 찾을 수 있습니다 .swapon

12.12.2. 스왑 파일 만들기

이 예 에서는 파티션을 사용하는 대신 / usr / swap0 이라는 512M 스왑 파일을 만듭니다 .

스왑 파일을 사용하려면 md (4)에 필요한 모듈 이 커널에 빌드되었거나 스왑이 활성화되기 전에로드되어야합니다. 사용자 정의 커널 빌드에 대한 정보 는 FreeBSD 커널 구성을 참조하십시오 .

예 2. 스왑 파일 만들기

스왑 파일을 만듭니다.

# dd if=/dev/zero of=/usr/swap0 bs=1m count=512
새 파일에 대한 적절한 권한을 설정하십시오.

# chmod 0600 /usr/swap0
/ etc / fstab에 줄을 추가하여 스왑 파일에 대해 시스템에 알립니다 .

md99 없음 sw, file = / usr / swap0, late 00

MD (4) 장치 md99는 대화 형 사용할 수있는 낮은 장치 번호를 떠나, 사용된다.
시스템 시작시 스왑 공간이 추가됩니다. 스왑 공간을 즉시 추가하려면 swapon (8)을 사용하십시오 .

# swapon -aL

12.13. 전력 및 자원 관리

효율적인 방식으로 하드웨어 리소스를 활용하는 것이 중요합니다. 전원 및 리소스 관리를 통해 운영 체제는 시스템 제한을 모니터링하고 시스템 온도가 예기치 않게 상승 할 경우 경고를 제공 할 수 있습니다. 전원 관리를 제공하기위한 초기 사양은 APM (Advanced Power Management) 시설이었습니다. APM은 활동을 기반으로 시스템의 전력 사용량을 제어합니다. 그러나 운영 체제가 시스템의 전력 사용량과 열 속성을 관리하는 것은 어렵고 유연하지 않았습니다. 하드웨어는 BIOS에 의해 관리되었으며 사용자는 구성 가능성과 전원 관리 설정에 대한 가시성을 제한했습니다. APMBIOS는 공급 업체에서 제공하며 하드웨어 플랫폼에 따라 다릅니다. 운영 체제의 APM 드라이버는 APM 소프트웨어 인터페이스에 대한 액세스를 중재합니다.

APM에는 네 가지 주요 문제가 있습니다. 첫째, 전원 관리는 운영 체제와 별도로 공급 업체별 BIOS에 의해 수행됩니다. 예를 들어, 사용자는 APMBIOS에서 하드 드라이브에 대한 유휴 시간 값을 설정할 수 있습니다.이를 초과하면 BIOS가 운영 체제의 동의없이 하드 드라이브를 스핀 다운 할 수 있습니다. 둘째, APM 로직은 BIOS에 내장되어 있으며 운영 체제 범위 밖에서 작동합니다. 이것은 사용자가 새로운 것을 ROM에 플래시하여 APMBIOS의 문제를 해결할 수 있다는 것을 의미합니다. 이는 시스템이 실패 할 경우 시스템을 복구 할 수없는 상태로 남겨 둘 수있는 위험한 절차입니다. 셋째, APM은 공급 업체별 기술이므로 한 공급 업체의 BIOS에서 발견 된 많은 노력과 버그가 다른 공급 업체에서 해결되지 않을 수 있음을 의미합니다. 마지막으로

플러그 앤 플레이 BIOS (PNPBIOS)는 많은 상황에서 신뢰할 수 없었습니다. PNPBIOS는 16 비트 기술이므로 운영 체제는 PNPBIOS 방법과 인터페이스하기 위해 16 비트 에뮬레이션을 사용해야합니다. FreeBSD는 APM 드라이버를 제공합니다. APM은 2000 년 이전에 제조 된 시스템에 계속 사용해야합니다. 드라이버는 apm (4)에 문서화되어 있습니다.

APM의 후속 제품은 고급 구성 및 전원 인터페이스 (ACPI)입니다. ACPI는 하드웨어 리소스 및 전원 관리를위한 인터페이스를 제공하기 위해 공급 업체 연합에서 작성한 표준입니다. 운영 체제에 더 많은 제어와 유연성을 제공하므로 운영 체제 지향 구성 및 전원 관리 의 핵심 요소입니다 .

이 장은 FreeBSD에서 ACPI를 설정하는 방법을 보여줍니다. 그런 다음 개발자가 ACPI 문제를 진단하고 수정할 수 있도록 ACPI를 디버깅하는 방법과 디버깅 정보가 포함 된 문제 보고서를 제출하는 방법에 대한 몇 가지 팁을 제공합니다.

12.13.1. ACPI 구성

FreeBSD에서 acpi (4) 드라이버는 기본적으로 시스템 부팅시로드되며 커널로 컴파일 되지 않아야합니다. 이 드라이버는 시스템 버스가 다양한 하드웨어 상호 작용에 사용하기 때문에 부팅 후 언로드 할 수 없습니다. 그러나 시스템에 문제가있는 경우 /boot/loader.confhint.acpi.0.disabled="1" 에서 설정 한 후 재부팅 하거나 "3 단계"에 설명 된대로 로더 프롬프트에서이 변수를 설정 하여 ACPI를 완전히 비활성화 할 수 있습니다 .

ACPI와 APM은 공존 할 수 없으며 별도로 사용해야합니다. 로드 할 마지막 하나는 드라이버가 다른 하나가 실행 중임을 감지하면 종료됩니다.

ACPI를 사용하여 acpiconf, -s플래그 및에서 1까지 의 숫자를 사용하여 시스템을 절전 모드로 전환 할 수 있습니다 5. 대부분의 사용자는 1(RAM에 대한 빠른 일시 중지) 또는 3( RAM에 일시 중지) 만 필요합니다 . 옵션 5은 실행과 동일한 소프트 오프를 수행합니다 halt -p.

를 사용하여 다른 옵션을 사용할 수 있습니다 sysctl. 자세한 내용은 acpi (4) 및 acpiconf (8) 를 참조하십시오.

12.13.2. 일반적인 문제

ACPI는 ia32 (x86) 및 amd64 (AMD) 아키텍처를 준수하는 모든 최신 컴퓨터에 있습니다. 전체 표준에는 CPU 성능 관리, 전원 플레인 제어, 열 영역, 다양한 배터리 시스템, 임베디드 컨트롤러 및 버스 열거를 포함한 많은 기능이 있습니다. 대부분의 시스템은 전체 표준보다 덜 구현합니다. 예를 들어, 데스크톱 시스템은 일반적으로 버스 열거 만 구현하는 반면 랩톱에는 냉각 및 배터리 관리도 지원할 수 있습니다. 랩톱에는 자체 복잡성과 함께 일시 중지 및 재개 기능이 있습니다.

ACPI 호환 시스템에는 다양한 구성 요소가 있습니다. BIOS 및 칩셋 공급 업체는 APIC 맵 (SMP에 사용됨), 구성 레지스터 및 간단한 구성 값과 같은 항목을 지정하는 FADT와 같은 다양한 고정 테이블을 메모리에 제공합니다. 또한 바이트 코드 테이블 인 차별화 된 시스템 설명 테이블 DSDT는 장치 및 메서드의 트리와 같은 이름 공간을 지정합니다.

ACPI 드라이버는 고정 테이블을 구문 분석하고 바이트 코드에 대한 인터프리터를 구현하고 장치 드라이버와 커널을 수정하여 ACPI 하위 시스템의 정보를 받아야합니다. FreeBSD의 경우 인텔 ®은 Linux® 및 NetBSD와 공유되는 인터프리터 (ACPI-CA)를 제공했습니다. ACPI-CA 소스 코드의 경로는 src / sys / contrib / dev / acpica 입니다. ACPI-CA가 FreeBSD에서 작동하도록하는 글루 코드는 src / sys / dev / acpica / Osd에 있습니다. 마지막으로 다양한 ACPI 장치를 구현하는 드라이버는 src / sys / dev / acpica에 있습니다.

ACPI가 올바르게 작동하려면 모든 부품이 올바르게 작동해야합니다. 다음은 몇 가지 일반적인 문제 (표시 빈도 순)와 가능한 해결 방법 또는 수정 사항입니다. 수정으로 문제가 해결되지 않으면 버그 보고서 제출 방법에 대한 지침은 디버깅 정보 가져 오기 및 제출을 참조하십시오 .

12.13.2.1. 마우스 문제

경우에 따라 일시 중지 작업에서 다시 시작하면 마우스가 작동하지 않을 수 있습니다. 알려진 해결 방법은 /boot/loader.conf 에 추가 hint.psm.0.flags="0x3000"하는 것 입니다.

12.13.2.2. 일시 중지 / 재개

ACPI에는 3 개의 STR (suspend to RAM) 상태, S1- S3및 하나의 suspend to disk state (STD)가 S4있습니다. STD는 두 가지 방법으로 구현할 수 있습니다. S4BIOS는 BIOS를 이용한 A가 디스크에 일시 중단입니다 S4OS 운영 체제에서 완전히 구현됩니다. 전원이 연결되어 있지만 전원이 켜지지 않았을 때 시스템이 켜져있는 정상 상태는 "소프트 오프"( S5)입니다.

sysctl hw.acpi일시 중지 관련 항목을 확인하는 데 사용 합니다. 다음 예제 결과는 Thinkpad에서 가져온 것입니다.

hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.s4bios: 0

사용 acpiconf -s테스트 S3, S4및 S5. s4bios하나 (의는 1) 표시 S4대신 BIOS 지원 S4운영 체제 지원.

일시 중지 / 재개를 테스트 할 때 S1지원되는 경우로 시작 합니다. 이 상태는 많은 드라이버 지원이 필요하지 않기 때문에 작동 할 가능성이 가장 높습니다. S2과 유사한 구현 한 사람이 없습니다 S1. 다음으로 S3. 이것은 가장 깊은 STR 상태이며 하드웨어를 올바르게 다시 초기화하려면 많은 드라이버 지원이 필요합니다.

일시 중지 / 다시 시작의 일반적인 문제는 많은 장치 드라이버가 펌웨어, 레지스터 또는 장치 메모리를 제대로 저장, 복원 또는 다시 초기화하지 않는다는 것입니다. 문제를 디버깅하는 첫 번째 시도로 다음을 시도하십시오.

# sysctl debug.bootverbose=1 # sysctl debug.acpi.suspend_bounce=1 # acpiconf -s 3

이 테스트는 실제로 S3상태가 되지 않고 모든 장치 드라이버의 일시 중지 / 재개주기를 에뮬레이트합니다 . 경우에 따라 펌웨어 상태 손실, 장치 감시 시간 초과 및 영구 재시 도와 같은 문제를이 방법으로 캡처 할 수 있습니다. 시스템이 실제로 S3상태로 들어 가지 않으므로 장치의 전원이 꺼지지 않을 수 있으며 실제 S3상태 와 달리 일시 중지 / 재개 방법이 완전히 누락 된 경우에도 대부분 제대로 작동합니다 .

더 어려운 경우에는 직렬 콘솔을 통한 디버깅을위한 직렬 포트 및 케이블 , dcons (4) 사용을위한 Firewire 포트 및 케이블 , 커널 디버깅 기술과 같은 추가 하드웨어가 필요 합니다.

문제를 격리하려면 가능한 한 많은 드라이버를 언로드하십시오. 작동하는 경우 다시 실패 할 때까지 드라이버를로드하여 문제가있는 드라이버의 범위를 좁 힙니다. 일반적으로 nvidia.ko , 디스플레이 드라이버 및 USB와 같은 바이너리 드라이버는 이더넷 인터페이스가 일반적으로 잘 작동하는 반면 가장 많은 문제가 있습니다. 드라이버를 적절하게로드 및 언로드 할 수있는 경우 /etc/rc.suspend 및 /etc/rc.resume 에 적절한 명령을 입력하여이를 자동화하십시오 . 설정 시도 hw.acpi.reset_video에 1디스플레이가 다시 시작한 후 엉망이됩니다. 더 길거나 더 짧은 값을 설정 hw.acpi.sleep_delay하여 도움이되는지 확인하십시오.

최신 Linux® 배포를로드하여 일시 중지 / 재개가 동일한 하드웨어에서 작동하는지 확인하십시오. Linux®에서 작동한다면 FreeBSD 드라이버 문제 일 가능성이 높습니다. 문제를 일으키는 드라이버를 좁 히면 개발자가 문제를 해결하는 데 도움이됩니다. ACPI 관리자는 사운드 나 ATA와 같은 다른 드라이버를 거의 유지하지 않기 때문에 모든 드라이버 문제는 FreeBSD-CURRENT 메일 링리스트에 게시 하고 드라이버 관리자에게 메일 로 보내야 합니다. 고급 사용자는 문제가있는 드라이버에 printf (3) 디버깅을 포함 하여 재개 기능에서 중단되는 위치를 추적 할 수 있습니다.

마지막으로 ACPI를 비활성화하고 대신 APM을 활성화하십시오. 일시 중지 / 재개가 APM에서 작동하는 경우 APM, 특히 구형 하드웨어 (2000 년 이전)에서 APM을 고수하십시오. 공급 업체가 ACPI 지원을 올바르게받는 데 시간이 걸렸으며 구형 하드웨어는 ACPI에 BIOS 문제가있을 가능성이 더 큽니다.

12.13.2.3. 시스템 중단

대부분의 시스템 정지는 인터럽트 손실 또는 인터럽트 폭풍의 결과입니다. 칩셋은 부팅, APIC (MADT) 테이블의 수정 전에 BIOS가 인터럽트를 구성하는 방법 및 시스템 제어 인터럽트 (SCI)의 라우팅에 따라 문제가있을 수 있습니다.

인터럽트 스톰은의 출력을 확인하고 vmstat -i가있는 라인을 살펴봄 으로써 손실 된 인터럽트와 구별 할 수 있습니다 acpi0. 카운터가 초당 몇 개 이상 증가하면 인터럽트 폭풍이 있습니다. 시스템이 중단 된 것처럼 보이면 DDB ( 콘솔의 CTRL+ ALT+)로ESC 중단 하고를 입력 show interrupts합니다.

인터럽트 문제를 처리 할 때 /boot/loader.confhint.apic.0.disabled="1" 에서 APIC 지원을 비활성화하십시오 .

12.13.2.4. 패닉

ACPI의 경우 패닉은 비교적 드물며 해결해야 할 최우선 순위입니다. 첫 번째 단계는 가능한 경우 패닉을 재현하는 단계를 분리하고 역 추적을 얻는 것입니다. "직렬 라인에서 DDB 디버거 입력" 또는 덤프 파티션 설정 options DDB의 직렬 콘솔 활성화 및 설정에 대한 조언을 따르십시오 . DDB에서 역 추적을 얻으려면 . 역 추적을 필기 할 때 추적에서 적어도 마지막 5 개와 상위 5 개 줄을 가져옵니다.tr

그런 다음 ACPI를 비활성화 한 상태에서 부팅하여 문제를 격리 해보십시오. 작동하는 경우 다양한 값을 사용하여 ACPI 하위 시스템을 격리하십시오 debug.acpi.disable. 몇 가지 예는 acpi (4) 를 참조하십시오 .

12.13.2.5. 일시 중지 또는 종료 후 시스템 전원이 켜짐

먼저 /boot/loader.confhw.acpi.disable_on_poweroff="0" 에서 설정해보십시오 . 이렇게하면 ACPI가 종료 프로세스 동안 다양한 이벤트를 비활성화하지 못하도록합니다. 일부 시스템 에서는 같은 이유로이 값을 (기본값)로 설정해야합니다 . 이는 일반적으로 일시 중지 또는 전원 끄기 후 시스템 전원이 자발적으로 켜지는 문제를 해결합니다.1

12.13.2.6. BIOS에 버기 바이트 코드가 포함됨

일부 BIOS 공급 업체는 올바르지 않거나 버그가있는 바이트 코드를 제공합니다. 이것은 일반적으로 다음과 같은 커널 콘솔 메시지에 의해 나타납니다.

ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\ (Node 0xc3f6d160), AE_NOT_FOUND

종종 이러한 문제는 BIOS를 최신 버전으로 업데이트하여 해결할 수 있습니다. 대부분의 콘솔 메시지는 무해하지만 배터리 상태가 작동하지 않는 것과 같은 다른 문제가있는 경우 이러한 메시지는 문제를 찾기 시작하기에 좋은 곳입니다.

12.13.3. 기본 AML 재정의

ACPI Machine Language (AML)로 알려진 BIOS 바이트 코드는 ACPI Source Language (ASL)라는 소스 언어에서 컴파일됩니다. AML은 DSDT (Differentiated System Description Table)로 알려진 테이블에서 찾을 수 있습니다.

FreeBSD의 목표는 모든 사람이 사용자 개입없이 ACPI를 작동하는 것입니다. BIOS 공급 업체의 일반적인 실수에 대한 해결 방법은 여전히 개발 중입니다. Microsoft® 인터프리터 ( acpi.sys 및 acpiec.sys )는 표준 준수 여부를 엄격하게 확인하지 않으므로 Windows®에서 ACPI 만 테스트하는 많은 BIOS 공급 업체는 ASL을 수정하지 않습니다. FreeBSD 개발자는 Microsoft®의 인터프리터가 허용하는 비표준 동작을 계속 식별하고 문서화하고이를 복제하여 사용자가 ASL을 수정하지 않고도 FreeBSD가 작동 할 수 있도록합니다.

버그가있는 동작을 식별하고 수동으로 수정할 수 있도록 시스템의 ASL로 복사본을 만들 수 있습니다. 시스템의 ASL을 지정된 파일 이름에 복사하려면 acpidumpwith를 사용 -t하여 고정 테이블의 내용을 표시 -d하고을 사용하여 AML을 디스 어셈블합니다.

# acpidump -td > my.asl

일부 AML 버전은 사용자가 Windows®를 실행하고 있다고 가정합니다. 이를 무시하려면, 설정 에 /boot/loader.conf에 ASL의에 나와있는 가장 최근의 윈도우 버전을 사용.hw.acpi.osname="Windows 2009"

다른 해결 방법을 사용하려면 my.asl 을 사용자 지정 해야 할 수 있습니다. 이 파일이 편집 된 경우 다음 명령을 사용하여 새 ASL을 컴파일합니다. 경고는 일반적으로 무시할 수 있지만 오류는 일반적으로 ACPI가 올바르게 작동하지 못하게하는 버그입니다.

# iasl -f my.asl

포함 -f하면 컴파일 중에 오류가 있어도 AML을 강제로 생성합니다. 반환 문 누락과 같은 일부 오류는 FreeBSD 인터프리터에 의해 자동으로 해결됩니다.

의 기본 출력 파일 이름 iasl은 DSDT.aml 입니다. 다음과 같이 /boot/loader.conf 를 편집 하여 플래시 메모리에 여전히 존재하는 BIOS의 버그가있는 복사본 대신이 파일을로드 합니다.

acpi_dsdt_load = "예" acpi_dsdt_name = "/ boot / DSDT.aml"

DSDT.aml 을 / boot 에 복사 한 다음 시스템을 재부팅하십시오. 이 방법으로 문제가 해결되면 개발자가 acpica 에서 버그가있는 동작을 해결할 수 있도록 이전 및 새 ASL 의 diff (1) 를 FreeBSD ACPI 메일 링리스트 에 보냅니다 .

12.13.4. 디버깅 정보 가져 오기 및 제출

ACPI 드라이버에는 유연한 디버깅 기능이 있습니다. 서브 시스템 세트와 자세한 정도를 지정할 수 있습니다. 디버깅 할 하위 시스템은 계층으로 지정되며 구성 요소 ( ACPI_ALL_COMPONENTS) 및 ACPI 하드웨어 지원 ( ACPI_ALL_DRIVERS)으로 구분됩니다. 디버깅 출력의 자세한 정도는 수준으로 지정되며 오류보고 ( ACPI_LV_ERROR)에서 모든 것 ( ACPI_LV_VERBOSE) 까지의 범위입니다 . 레벨은 비트 마스크이므로 공백으로 구분하여 한 번에 여러 옵션을 설정할 수 있습니다. 실제로 직렬 콘솔을 사용하여 출력을 기록해야 콘솔 메시지 버퍼가 플러시 될 때 손실되지 않습니다. 개별 레이어 및 레벨의 전체 목록은 acpi (4)에 있습니다.

디버깅 출력은 기본적으로 활성화되어 있지 않습니다. 활성화하려면 options ACPI_DEBUGACPI가 커널로 컴파일 된 경우 사용자 정의 커널 구성 파일에 추가하십시오 . /etc/make.conf 에 추가 ACPI_DEBUG=1하여 전역 적으로 활성화하십시오. 사용자 지정 커널 대신 모듈을 사용하는 경우 다음과 같이 acpi.ko 모듈 만 다시 컴파일 합니다.

# cd /sys/modules/acpi/acpi && make clean && make ACPI_DEBUG=1

컴파일 된 acpi.ko 를 / boot / kernel에 복사하고 원하는 레벨과 레이어를 /boot/loader.conf에 추가합니다 . 이 예제의 항목은 모든 ACPI 구성 요소 및 하드웨어 드라이버에 대한 디버그 메시지를 활성화하고 최소한 자세한 수준의 오류 메시지를 출력합니다.

debug.acpi.layer = "ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" debug.acpi.level = "ACPI_LV_ERROR"

일시 중지 및 재개와 같은 특정 이벤트에 의해 필요한 정보가 트리거되는 경우 /boot/loader.conf를 수정하지 마십시오 . 대신을 사용 sysctl하여 특정 이벤트에 대해 시스템을 부팅하고 준비한 후 계층 및 수준을 지정합니다. 를 사용하여 설정할 수있는 변수 sysctl는 /boot/loader.conf 의 튜너 블과 동일한 이름으로 지정 됩니다.

디버깅 정보가 수집되면 FreeBSD ACPI 메일 링리스트 로 보내어 FreeBSD ACPI 관리자가 문제의 근본 원인을 식별하고 솔루션을 개발하는 데 사용할 수 있습니다.

이 메일 링리스트에 디버깅 정보를 제출하기 전에 최신 BIOS 버전이 설치되어 있는지 확인하고, 가능한 경우 임베디드 컨트롤러 펌웨어 버전을 확인하십시오.

문제 보고서를 제출할 때 다음 정보를 포함하십시오.

시스템 유형, 모델 및 버그를 유발하는 모든 것을 포함하여 버그가있는 동작에 대한 설명입니다. 새로운 버그 인 경우 언제부터 버그가 발생하기 시작했는지 가능한 한 정확하게 기록하십시오.
버그로 인해 생성 된 오류 메시지를 포함한 dmesgafter running 의 출력입니다 boot -v.
ACPI를 비활성화하면 ACPI가 비활성화 된 dmesg출력 boot -v이 문제 해결에 도움이됩니다.
의 출력 sysctl hw.acpi. 여기에는 시스템이 제공하는 기능이 나열됩니다.
시스템 ASL의 붙여 넣은 버전에 대한 URL입니다. 마십시오 하지 가 매우 클 수로 목록에 직접 ASL을 보낼 수 있습니다. 다음 명령을 실행하여 ASL의 복사본을 생성합니다.

# acpidump -dt > name-system.asl

의 로그인 이름으로 대체 이름 과에 대한 제조 업체 / 모델 시스템 . 예를 들어 njl-FooCo6000.asl을 사용하십시오 .

대부분의 FreeBSD 개발자는 FreeBSD-CURRENT 메일 링리스트를 봅니다. 그러나 문제 가 있는지 확인 하려면 FreeBSD ACPI 메일 링리스트 에 문제를 제출 해야합니다. 응답을 기다릴 때 인내심을 가지십시오. 버그가 즉시 드러나지 않으면 버그 보고서를 제출하십시오. PR을 입력 할 때 위에서 요청한 것과 동일한 정보를 포함하십시오. 이는 개발자가 문제를 추적하고 해결하는 데 도움이됩니다. 문제가 이전에보고되었을 가능성이 있으므로 FreeBSD ACPI 메일 링리스트를 먼저 이메일로 보내지 않고 PR을 보내지 마십시오 .

12.13.5. 참고 문헌

ACPI에 대한 자세한 정보는 다음 위치에서 찾을 수 있습니다.

FreeBSD ACPI 메일 링리스트 아카이브 ( https://lists.freebsd.org/pipermail/freebsd-acpi/ )
ACPI 2.0 사양 ( http://acpi.info/spec.htm )
acpi (4) , acpi_thermal (4) , acpidump (8) , iasl (8) 및 acpidb (8)

1 . 자동 조정 알고리즘은 maxusers를 시스템의 메모리 양과 동일하게 설정하며 최소 32 개, 최대 384 개로 설정합니다.