시스템 관리자 가이드
RHEL 7 배포, 구성 및 관리
초록
I 부. 기본 시스템 구성
이 부분에서는 기본적인 설치 후 작업 및 키보드 구성, 날짜 및 시간 구성, 사용자 및 그룹 관리 및 권한 얻기와 같은 기본 시스템 관리 작업에 대해 다룹니다.
1장. 시작하기
이 장에서는 Red Hat Enterprise Linux 7을 설치한 직후 수행해야 하는 기본 작업에 대해 설명합니다.
이러한 항목에는 설치 프로세스 중에 일반적으로 이미 수행되는 작업이 포함될 수 있지만 시스템 등록과 같이 반드시 수행해야 할 필요는 없습니다. 이러한 작업을 다루는 하위 관리자는 설치 및 특수 섹션의 관련 문서에 대한 링크에 대한 간략한 요약을 제공합니다.
Red Hat Enterprise Linux 7 설치에 대한 자세한 내용은 Red Hat Enterprise Linux 7 설치 가이드 를 참조하십시오.
이 장에서는 수행할 몇 가지 명령을 설명합니다. root
사용자가 입력해야 하는 명령에는 프롬프트에 #
이 있고 일반 사용자가 수행할 수 있는 명령에는 $
가 있습니다.
일반적인 설치 후 작업에 대한 자세한 내용은 Red Hat Enterprise Linux 7 설치 가이드 를 참조하십시오.
명령줄을 통해 모든 설치 후 작업을 수행할 수 있지만 웹 콘솔 툴을 사용하여 일부 작업을 수행할 수도 있습니다.
What web console Is and Which Tasks it can be Used For
웹 콘솔 은 웹 브라우저를 통해 서버를 모니터링하고 관리하기 위한 사용자 인터페이스를 제공하는 시스템 관리 툴입니다.
웹 콘솔 을 사용하여 다음 작업을 수행할 수 있습니다.
- 하드웨어, 인터넷 연결 또는 성능 특성과 같은 기본 시스템 기능 모니터링
- 시스템 로그 파일의 내용 분석
- 인터페이스, 네트워크 로그, 패킷 크기와 같은 기본 네트워킹 기능 구성
- 사용자 계정 관리
- 시스템 서비스 모니터링 및 구성
- 진단 보고서 생성
- 커널 덤프 구성 설정
- SELinux 구성
- 시스템 서브스크립션 관리
- 터미널 액세스
웹 콘솔 설치 및 사용에 대한 자세한 내용은 RHEL 7 웹 콘솔 을 사용한 시스템 관리를 참조하십시오.
1.1. 환경의 기본 설정
환경의 기본 구성은 다음과 같습니다.
- 날짜 및 시간
- 시스템 지역
- 키보드 레이아웃
이러한 항목 설정은 일반적으로 설치 프로세스의 일부입니다.
자세한 내용은 설치 방법에 따라 적절한 소스를 참조하십시오.
Anaconda 설치 프로그램으로 설치할 때 다음을 참조하십시오.
Kickstart 파일로 설치하는 경우 다음을 참조하십시오.
Red Hat Enterprise Linux 7 설치 가이드의 Kickstart 명령 및 옵션 .
설치 후 환경의 기본 특성을 재구성해야 하는 경우 이 섹션의 지침을 따르십시오.
1.1.1. 날짜 및 시간 구성 소개
정확한 시간은 여러 가지 이유로 중요합니다. Red Hat Enterprise Linux 7에서 시간 유지는 NTP
프로토콜에 의해 확인되며, 이는 사용자 공간에서 실행되는 데몬에 의해 구현됩니다. 사용자 공간 데몬은 커널에서 실행되는 시스템 클럭을 업데이트합니다. 시스템 클럭은 다양한 클럭 소스를 사용하여 시간을 유지할 수 있습니다.
Red Hat Enterprise Linux 7은 다음 데몬을 사용하여 NTP
를 구현합니다.
chronyd
chronyd
데몬은 기본적으로 사용됩니다. chrony 패키지에서 사용할 수 있습니다.chronyd
에서NTP
를 구성하고 사용하는 방법에 대한 자세한 내용은 18장. chrony Suite를 사용하여 NTP 설정 을 참조하십시오.ntpd
ntpd
데몬은 ntp 패키지에서 사용할 수 있습니다.ntpd
에서NTP
설정 및 사용에 대한 자세한 내용은 19장. ntpd를 사용하여 NTP 설정 을 참조하십시오.
기본 chronyd
대신 ntpd
를 사용하려면 19장. ntpd를 사용하여 NTP 설정 에 표시된 대로 chronyd
, install, enable 및 configure ntpd
를 비활성화해야 합니다.
현재 날짜 및 시간 표시
현재 날짜와 시간을 표시하려면 다음 명령 중 하나를 사용합니다.
~]$ date
~]$ timedatectl
timedatectl
명령은 현재 사용된 표준 시간대, NTP(Network Time Protocol) 구성 상태 및 몇 가지 추가 정보를 포함하여 보다 자세한 출력을 제공합니다.
날짜 및 시간 구성에 대한 자세한 내용은 3장. 날짜 및 시간 구성 을 참조하십시오.
1.1.2. 시스템 로컬 구성 소개
시스템 전체 로케일 설정은 systemd
데몬에서 초기 부팅 시 읽는 /etc/locale.conf
파일에 저장됩니다. /etc/locale.conf
에 구성된 로케일 설정은 개별 프로그램 또는 개별 사용자가 재정의하지 않는 한 모든 서비스 또는 사용자에 의해 상속됩니다.
시스템 로케일을 처리하는 기본 작업:
사용 가능한 시스템 로케일 설정 나열:
~]$
localectl list-locales
시스템 로케일 설정의 현재 상태 표시:
~]$
localectl status
기본 시스템 로케일 설정 또는 변경:
~]# localectl set-locale LANG=locale
시스템 로케일 구성에 대한 자세한 내용은 2장. System Locale 및 keyboard Configuration 을 참조하십시오.
1.1.3. keyboard 레이아웃 구성 소개
키보드 레이아웃 설정은 텍스트 콘솔 및 그래픽 사용자 인터페이스에서 사용되는 레이아웃을 제어합니다.
키보드 레이아웃을 처리하는 기본 작업은 다음과 같습니다.
사용 가능한 키맵 나열:
~]$
localectl list-keymaps
키 맵 설정의 현재 상태 표시:
~]$
localectl status
기본 시스템 키맵 설정 또는 변경:
~]# localectl set-keymap
키보드 레이아웃 구성에 대한 자세한 내용은 2장. System Locale 및 keyboard Configuration 을 참조하십시오.
1.2. 네트워크 액세스 구성 및 검사
네트워크 액세스는 일반적으로 설치 프로세스 중에 구성됩니다. 그러나 설치 프로세스에서는 일부 일반적인 설치 경로에서 네트워크 인터페이스를 구성하라는 메시지를 표시하지 않습니다. 따라서 설치 후 네트워크 액세스가 구성되지 않을 수 있습니다. 이 경우 설치 후 네트워크 액세스를 구성할 수 있습니다.
설치 중에 네트워크 액세스를 구성하는 빠른 시작 방법은 1.2.1절. “설치 프로세스 중 네트워크 액세스 구성” 을 참조하십시오. 설치 후 네트워크 액세스를 구성하려면 Red Hat Enterprise Linux 7 네트워킹 가이드 또는 Red Hat Enterprise Linux 7 네트워킹 가이드에 설명된 nmtui 텍스트 사용자 인터페이스 유틸리티에 설명된 nmcli 명령줄 유틸리티를 사용할 수 있습니다.
nmcli 및 nmtui 유틸리티에서는 하나 이상의 새 네트워크 연결을 추가하고 기존 연결을 수정 및 검사할 수 있습니다. nmcli 를 사용하여 네트워크 연결을 만들고 관리하려면 1.2.2절. “nmcli를 사용하여 설치 프로세스 후 네트워크 연결 관리” 을 참조하십시오. nmtui 를 사용하여 네트워크 연결을 생성 및 관리하려면 1.2.3절. “nmtui를 사용하여 설치 프로세스 후 네트워크 연결 관리” 을 참조하십시오.
1.2.1. 설치 프로세스 중 네트워크 액세스 구성
설치 프로세스 중에 네트워크 액세스를 구성하는 방법은 다음과 같습니다.
- Anaconda 설치 프로그램의 그래픽 사용자 인터페이스에 있는 설치 요약 화면에 있는 메뉴
- Anaconda 설치 프로그램의 텍스트 모드에 있는 옵션
- Kickstart 파일
설치가 완료된 후 시스템이 부팅되면 설치 중에 구성한 네트워크 인터페이스가 자동으로 활성화됩니다.
설치 프로세스 중 네트워크 액세스 구성에 대한 자세한 내용은 Red Hat Enterprise Linux 7 설치 가이드 를 참조하십시오.
1.2.2. nmcli를 사용하여 설치 프로세스 후 네트워크 연결 관리
nmcli 유틸리티를 사용하여 네트워크 연결을 관리하려면 root
사용자로 다음 명령을 실행합니다.
새 연결을 생성하려면 다음을 수행합니다.
~]# nmcli con add type type of the connection "con-name" connection name ifname ifname interface-name the name of the interface ipv4 address ipv4 address gw4 address gateway address
기존 연결을 수정하려면 다음을 수행합니다.
~]# nmcli con mod "con-name"
모든 연결을 표시하려면 다음을 수행하십시오.
~]# nmcli con show
활성 연결을 표시하려면 다음을 수행합니다.
~]# nmcli con show --active
특정 연결의 모든 구성 설정을 표시하려면 다음을 수행합니다.
~]# nmcli con show "con-name"
nmcli 명령줄 유틸리티에 대한 자세한 내용은 Red Hat Enterprise Linux 7 네트워킹 가이드 를 참조하십시오.
1.2.3. nmtui를 사용하여 설치 프로세스 후 네트워크 연결 관리
NetworkManager 텍스트 사용자 인터페이스(TUI) 유틸리티인 nmtui 는 NetworkManager 를 제어하여 네트워킹을 구성하는 텍스트 인터페이스를 제공합니다.
nmtui 텍스트 인터페이스 툴 설치 및 사용에 대한 자세한 내용은 Red Hat Enterprise Linux 7 네트워킹 가이드 를 참조하십시오.
1.2.4. 웹 콘솔에서 네트워킹 관리
웹 콘솔에서 메뉴를 사용하면 됩니다.
- 현재 수신 및 전송된 패킷을 표시하려면 다음을 수행합니다.
- 사용 가능한 네트워크 인터페이스의 가장 중요한 특성 표시
- 네트워킹 로그의 콘텐츠를 표시하려면 다음을 수행합니다.
- 다양한 유형의 네트워크 인터페이스 추가 (bond, team, bridge, VLAN)
그림 1.1. 웹 콘솔에서 네트워킹 관리
1.3. 시스템 등록 및 서브스크립션 관리의 기본 사항
1.3.1. Red Hat 서브스크립션을 사용할 수 있는 작업은 무엇입니까?
운영 체제 자체를 포함하여 Red Hat Enterprise Linux 7에 설치된 제품은 서브스크립션을 통해 지원됩니다.
Red Hat Content Delivery Network에 대한 서브스크립션을 추적하는 데 사용됩니다.
- 등록된 시스템
- 해당 시스템에 설치된 제품
- 해당 제품에 연결된 서브스크립션
1.3.2. 설치 중 시스템 등록
이 섹션에서는 설치 프로세스 중 Red Hat Enterprise Linux 7 등록에 대한 간략한 요약을 제공합니다. 설치 후 운영 체제를 등록하지 않으면 이 섹션을 통해 설치 중에 누락된 내용을 확인할 수 있습니다. 자세한 내용은 Red Hat Enterprise Linux 7 설치 가이드 를 참조하십시오.
기본적으로 설치 중에 시스템을 등록하는 방법에는 두 가지가 있습니다.
- 일반적으로 등록은 초기 설정 구성 프로세스의 일부입니다. 자세한 내용은 Red Hat Enterprise Linux 7 설치 가이드 를 참조하십시오.
- 또 다른 옵션은 설치 후 스크립트 를 실행하는 것입니다. 이 스크립트는 설치가 완료되면 자동 등록을 수행하고 시스템을 처음 재부팅하기 전에 자동으로 등록합니다. 이를 위해 Kickstart 파일의 %post 섹션을 수정합니다. 설치 후 스크립트로 서브스크립션 관리자를 실행하는 방법에 대한 자세한 내용은 Red Hat Enterprise Linux 7 설치 가이드 를 참조하십시오.
1.3.3. 설치 후 시스템 등록
설치 과정에서 시스템을 등록하지 않은 경우 다음 절차를 적용하여 나중에 수행할 수 있습니다. 이 절차의 모든 명령은 root
사용자로 수행해야 합니다.
시스템 등록 및 등록
시스템을 등록합니다.
~]# subscription-manager register
이 명령은 Red Hat Customer Portal 사용자 이름과 암호를 입력하라는 메시지를 표시합니다.
필요한 서브스크립션의 풀 ID를 확인합니다.
~]# subscription-manager list --available
이 명령은 Red Hat 계정에 사용 가능한 모든 서브스크립션을 표시합니다. 모든 서브스크립션에 대해 풀 ID를 포함하여 다양한 특성이 표시됩니다.
pool_id 를 이전 단계에서 확인한 풀 ID로 교체하여 시스템에 적절한 서브스크립션을 연결합니다.
~]# subscription-manager attach --pool=pool_id
시스템 등록 및 Red Hat Content Delivery Network 서브스크립션 첨부에 대한 자세한 내용은 7장. 시스템 등록 및 서브스크립션 관리 을 참조하십시오.
1.3.4. EUS 콘텐츠에 시스템 등록
EUS (Extended Update Support) 콘텐츠에 액세스하려면 다음과 같이 시스템을 등록합니다.
EUS 인타이틀먼트를 사용할 수 있는지 확인합니다.
~]# subscription-manager list --available --matches="*Extended Update Support"
+-------------------------------------------+ Available Subscriptions +-------------------------------------------+ Subscription Name: Extended Update Support Provides: Red Hat Enterprise Linux High Availability for x86_64 - Extended Update Support Red Hat Enterprise Linux Resilient Storage for x86_64 - Extended Update Support Red Hat Enterprise Linux for x86_64 - Extended Update Support Red Hat EUCJP Support (for RHEL Server) - Extended Update Support RHEL for SAP - Extended Update Support Red Hat Enterprise Linux Load Balancer (for RHEL Server) - Extended Update Support Red Hat Enterprise Linux Scalable File System (for RHEL Server) - Extended Update Support Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support RHEL for SAP HANA - Extended Update Support Red Hat Enterprise Linux High Performance Networking (for RHEL Server) - Extended Update Support Oracle Java (for RHEL Server) - Extended Update Support Red Hat S-JIS Support (for RHEL Server) - Extended Update Support SKU: RH00030 Contract: 12069074 Pool ID: 8a99f9ac7238188b01723d9c8a8a06a9 Provides Management: No Available: 8 Suggested: 0 Service Level: Layered Service Type: L1-L3 Subscription Type: Instance Based Starts: 05/22/2020 Ends: 05/21/2021 System Type: Physical
Pool ID를 사용하여 해당 서브스크립션을 연결합니다.
~]# subscription-manager attach --pool 8a99f9ac7238188b01723d9c8a8a06a9
시스템에 활성화된 기본 리포지토리를 EUS 변형으로 바꿉니다.
~]# subscription-manager repos --disable \*
사용 중인 RHEL 버전에 설정된 EUS 콘텐츠를 나타내는 리포지토리를 활성화합니다.
~]# subscription-manager repos --enable rhel-7-server-eus-rpms
최종 시스템에 필요한 릴리스 및 지원되는 릴리스를 선택합니다.
~]# subscription-manager release --set 7.6
현재 지원되는 EUS 릴리스는 연장 업데이트 지원 애드온 을 참조하십시오.
1.3.5. E4S 콘텐츠에 시스템 등록
다음 절차에서는 시스템을 등록하고 E4S 콘텐츠를 사용하는 방법을 설명합니다.
다음 명령을 사용하여 시스템을 등록합니다.
~]# subscription-manager register
E4S 인타이틀먼트를 사용할 수 있는지 확인합니다.
~]# subscription-manager list --available --matches="*Update Services for SAP Solutions*"
+-------------------------------------------+ Available Subscriptions +-------------------------------------------+ Subscription Name: Red Hat Enterprise Linux for SAP Solutions, Standard (Physical or Virtual Nodes) Provides: dotNET on RHEL Beta (for RHEL Server) Red Hat CodeReady Linux Builder for x86_64 Red Hat Enterprise Linux for SAP HANA for x86_64 Red Hat Ansible Engine RHEL for SAP HANA - Update Services for SAP Solutions Red Hat Enterprise Linux Scalable File System (for RHEL Server) - Extended Update Support RHEL for SAP HANA - Extended Update Support Red Hat Enterprise Linux Atomic Host Beta Red Hat Beta Red Hat EUCJP Support (for RHEL Server) - Extended Update Support Red Hat Enterprise Linux High Availability for x86_64 Red Hat Enterprise Linux Load Balancer (for RHEL Server) - Extended Update Support dotNET on RHEL (for RHEL Server) Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support Red Hat Enterprise Linux High Availability - Update Services for SAP Solutions Red Hat Enterprise Linux Resilient Storage for x86_64 - Extended Update Support Red Hat Enterprise Linux High Availability for x86_64 - Extended Update Support Oracle Java (for RHEL Server) Red Hat Enterprise Linux Server - Update Services for SAP Solutions Red Hat Software Collections (for RHEL Server) Red Hat Enterprise Linux Scalable File System (for RHEL Server) Red Hat Enterprise Linux High Performance Networking (for RHEL Server) - Extended Update Support RHEL for SAP - Update Services for SAP Solutions Oracle Java (for RHEL Server) - Extended Update Support Red Hat Enterprise Linux Atomic Host Red Hat Developer Tools (for RHEL Server) Red Hat Software Collections Beta (for RHEL Server) Red Hat Enterprise Linux Server Red Hat Enterprise Linux for SAP Applications for x86_64 Red Hat Developer Tools Beta (for RHEL Server) Red Hat Enterprise Linux for x86_64 Red Hat Enterprise Linux for x86_64 - Extended Update Support RHEL for SAP - Extended Update Support Red Hat Developer Toolset (for RHEL Server) Red Hat S-JIS Support (for RHEL Server) - Extended Update Support SKU: RH00764 Contract: 11977725 Pool ID: 8a85f99c6c4825eb016c4a30d3493064 Provides Management: Yes Available: 18 Suggested: 0 Service Level: Standard Service Type: L1-L3 Subscription Type: Instance Based Starts: 03/29/2020 Ends: 12/31/2021 System Type: Physical
Pool ID를 사용하여 해당 서브스크립션을 연결합니다.
~]# subscription-manager attach --pool=#################
시스템에 활성화된 기본 리포지토리를 EUS 변형으로 바꿉니다.
~]# subscription-manager repos --disable="*"
사용 중인 RHEL 버전에 설정된 E4S 콘텐츠를 나타내는 리포지토리를 활성화합니다.
~]# subscription-manager --enable=rhel-7-server-e4s-rpms
리포지토리 캐시 및 릴리스 잠금을 SAP 애플리케이션을 지원하는 E4S의 유효한 릴리스로 지웁니다.
~]# yum clean all && subscription-manager release --set=7.7
1.4. 소프트웨어 설치
이 섹션에서는 Red Hat Enterprise Linux 7 시스템에서 소프트웨어 설치의 기본 사항을 안내하는 정보를 제공합니다. 1.4.1절. “소프트웨어 설치를 위한 사전 요구 사항” 에 소프트웨어를 설치하기 위해 수행해야 하는 전제 조건을 언급하고, 1.4.2절. “소프트웨어 패키징 및 소프트웨어 리포지토리 시스템 소개” 의 소프트웨어 패키지 및 소프트웨어 리포지토리에 대한 기본 정보를 제공하고, 1.4.3절. “서브스크립션 관리자 및 YUM을 사용하여 기본 소프트웨어 설치 작업 관리” 의 소프트웨어 설치와 관련된 기본 작업을 수행하는 방법을 참조합니다.
1.4.1. 소프트웨어 설치를 위한 사전 요구 사항
Red Hat Content Delivery Network 서브스크립션 서비스는 Red Hat 소프트웨어 인벤토리를 처리하고 추가 소프트웨어 또는 이미 설치된 패키지를 설치할 수 있는 메커니즘을 제공합니다. 시스템을 등록하고 서브스크립션을 연결한 후 1.3절. “시스템 등록 및 서브스크립션 관리의 기본 사항” 에 설명된 대로 소프트웨어 설치를 시작할 수 있습니다.
1.4.2. 소프트웨어 패키징 및 소프트웨어 리포지토리 시스템 소개
Red Hat Enterprise Linux 시스템의 모든 소프트웨어는 특정 리포지토리에 저장된 RPM 패키지로 나뉩니다. Red Hat Content Delivery Network를 시스템이 서브스크립션하면 /etc/yum.repos.d/
디렉토리에 리포지토리 파일이 생성됩니다.
yum
유틸리티를 사용하여 패키지 작업을 관리합니다.
- 패키지에 대한 정보 검색
- 패키지 설치
- 패키지 업데이트
- 패키지 제거
- 현재 사용 가능한 리포지토리 목록 확인
- 리포지토리 추가 또는 제거
- 리포지토리 활성화 또는 비활성화
소프트웨어 설치와 관련된 기본 작업에 대한 자세한 내용은 1.4.3절. “서브스크립션 관리자 및 YUM을 사용하여 기본 소프트웨어 설치 작업 관리” 을 참조하십시오. 소프트웨어 리포지토리 관리에 대한 자세한 내용은 7.2절. “소프트웨어 리포지토리 관리” 을 참조하십시오. yum
유틸리티 사용에 대한 자세한 내용은 9장. yum 을 참조하십시오.
1.4.3. 서브스크립션 관리자 및 YUM을 사용하여 기본 소프트웨어 설치 작업 관리
운영 체제를 설치한 후 필요할 수 있는 가장 기본적인 소프트웨어 설치 작업은 다음과 같습니다.
사용 가능한 모든 리포지토리 나열:
~]# subscription-manager repos --list
현재 활성화된 리포지토리를 모두 나열합니다.
~]$
yum repolist
리포지토리 활성화 또는 비활성화:
~]# subscription-manager repos --enable repository
~]# subscription-manager repos --disable repository
특정 문자열과 일치하는 패키지 검색:
~]$
yum search
string패키지 설치:
~]# yum install package_name
모든 패키지 및 해당 종속 항목을 업데이트합니다.
~]# yum update
패키지를 업데이트합니다.
~]# yum update package_name
패키지 및 패키지에 종속된 패키지 설치 제거:
~]# yum remove package_name
설치 및 사용 가능한 모든 패키지에 대한 정보 나열:
~]$
yum list all
설치된 모든 패키지에 대한 정보 나열:
~]$
yum list installed
1.5. 부팅 시 systemd 서비스 시작
systemd는 systemd 단위의 개념을 소개하는 Linux 운영 체제용 시스템 및 서비스 관리자입니다. systemd에 대한 자세한 내용은 10.1절. “systemd 소개” 을 참조하십시오.
이 섹션에서는 부팅 시 서비스가 활성화 또는 비활성화되었는지 확인하는 방법에 대한 정보를 제공합니다. 또한 웹 콘솔 을 통해 서비스를 관리하는 방법을 설명합니다.
1.5.1. 서비스 활성화 또는 비활성화
설치 프로세스 중에 이미 부팅 시 활성화되거나 비활성화된 서비스를 확인하거나 설치된 운영 체제에서 서비스를 활성화하거나 비활성화할 수 있습니다.
설치 프로세스 중에 부팅 시 활성화되거나 비활성화되는 서비스 목록을 생성하려면 Kickstart 파일에서 services
옵션을 사용합니다.
services [--disabled=list] [--enabled=list]
비활성화된 서비스 목록은 활성화된 서비스 목록보다 먼저 처리됩니다. 따라서 두 목록에 서비스가 모두 표시되면 활성화됩니다. 서비스 목록은 쉼표로 구분된 형식으로 제공해야 합니다. 서비스 목록에 공백을 포함하지 마십시오. 자세한 내용은 Red Hat Enterprise Linux 7 설치 가이드를 참조하십시오.
이미 설치된 운영 체제에서 서비스를 활성화하거나 비활성화하려면 다음을 수행합니다.
~]# systemctl enableservice_name
~]# systemctl disableservice_name
자세한 내용은 10.2절. “시스템 서비스 관리”의 내용을 참조하십시오.
1.5.2. 웹 콘솔에서 서비스 관리
웹 콘솔에서 를 선택하여 systemd 대상, 서비스, 소켓, 타이머 및 경로를 관리합니다. 여기에서 자신의 상태를 확인, 시작 또는 중지, 활성화 또는 비활성화할 수 있습니다.
그림 1.2. 웹 콘솔에서 서비스 관리
1.5.3. systemd 서비스의 추가 리소스
systemd에 대한 자세한 내용은 10장. systemd를 사용하여 서비스 관리 을 참조하십시오.
1.6. 방화벽, SELinux 및 SSH 로그인으로 시스템 보안 강화
컴퓨터 보안은 컴퓨터 시스템을 하드웨어, 소프트웨어 또는 정보에 대한 도용 또는 손상으로부터 보호하는 것뿐 아니라 서비스 중단 또는 잘못된 방향을 보호하는 것입니다. 따라서 컴퓨터 보안을 보장하는 것은 기업이 민감한 데이터를 처리하거나 일부 비즈니스 트랜잭션을 처리하는 데 필요한 작업뿐만 아니라 필수 작업입니다.
컴퓨터 보안은 다양한 기능 및 도구를 포함합니다. 이 섹션에서는 운영 체제를 설치한 후 구성해야 하는 기본 보안 기능만 다룹니다. Red Hat Enterprise Linux 7 보안에 대한 자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드 를 참조하십시오.
1.6.1. 방화벽 활성화 및 실행 확인
1.6.1.1. 방화벽의 취약점 및 시스템 보안 강화 방법
방화벽은 사전 결정된 보안 규칙을 기반으로 들어오고 나가는 네트워크 트래픽을 모니터링하고 제어하는 네트워크 보안 시스템입니다. 방화벽은 일반적으로 신뢰할 수 있고 안전한 내부 네트워크와 외부 네트워크 간의 장벽을 설정합니다.
Red Hat Enterprise Linux 7에서 방화벽은 Red Hat Enterprise Linux를 설치하는 동안 자동으로 활성화되는 firewalld
서비스에서 제공합니다. 그러나 Kickstart 구성과 같이 서비스를 명시적으로 비활성화한 경우 1.6.1.2절. “firewalld 서비스 다시 활성화” 에 설명된 대로 다시 활성화할 수 있습니다. Kickstart 파일의 방화벽 설정 옵션에 대한 개요는 Red Hat Enterprise Linux 7 설치 가이드 를 참조하십시오.
1.6.1.2. firewalld 서비스 다시 활성화
설치 후 firewalld
서비스가 비활성화되어 있는 경우 Red Hat은 이를 다시 활성화하는 것을 권장합니다.
일반 사용자로도 firewalld
의 현재 상태를 표시할 수 있습니다.
~]$ systemctl status firewalld
firewalld
가 활성화되어 실행되지 않으면 root
사용자로 전환하고 해당 상태를 변경합니다.
~]# systemctl start firewalld
~]# systemctl enable firewalld
firewalld
와 관련된 설치 후 절차에 대한 자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드 를 참조하십시오. 방화벽 설정 및 사용에 대한 자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드를 참조하십시오.
1.6.2. SELinux 적용 상태 확인
1.6.2.1. SELinux의 정의 및 시스템 보안 강화 방법
SELinux(Security Enhanced Linux) 는 시스템 보안 계층을 통해 어떤 프로세스가 어떤 파일, 디렉터리 및 포트에 액세스할 수 있는지 결정합니다.
SELinux 상태
SELinux 에는 다음 두 가지 상태가 있습니다.
- enabled
- disabled
SELinux 가 비활성화된 경우 DC(Discretionary Access Control) 규칙만 사용됩니다.
SELinux 모드
SELinux 가 활성화되면 다음 모드 중 하나에서 실행할 수 있습니다.
- enforcing
- 허용
강제 모드는 SELinux 정책이 적용됨을 의미합니다. SELinux 는 SELinux 정책 규칙에 따라 액세스를 거부하고, 특히 허용되는 상호 작용만 활성화합니다. 강제 모드는 설치 후 기본 모드이며 가장 안전한 SELinux 모드이기도 합니다.
허용 모드는 SELinux 정책이 적용되지 않음을 의미합니다. SELinux 는 액세스를 거부하지 않지만 강제 모드에서 실행하는 경우 거부가 거부된 작업에 대해 기록됩니다. 허용 모드는 설치 중에 기본 모드입니다. 허용 모드에서는 문제를 해결할 때 AVC(Access Vector Cache) 거부에 액세스해야 하는 경우와 같이 특정 경우에 유용합니다.
Red Hat Enterprise Linux 7 의 SELinux 에 대한 자세한 내용은 Red Hat Enterprise Linux 7 SELinux 사용자 및 관리자 가이드 를 참조하십시오.
1.6.2.2. SELinux의 필수 상태 확인
기본적으로 SELinux 는 설치 중에 허용 모드로 작동하며 설치가 완료되면 강제 모드로 작동합니다.
그러나 일부 특정 상황에서는 SELinux 를 허용 모드로 명시적으로 설정하거나 설치된 운영 체제에서 비활성화할 수도 있습니다. 예를 들어 Kickstart 구성에서 이 값을 설정할 수 있습니다. Kickstart 파일의 SELinux 설정 옵션에 대한 개요는 Red Hat Enterprise Linux 7 설치 가이드 를 참조하십시오.
Red Hat은 시스템을 강제 모드로 유지할 것을 권장합니다.
현재 SELinux 모드를 표시하고 필요에 따라 모드를 설정하려면 다음을 수행합니다.
SELinux의 필수 상태 확인
현재 적용된 SELinux 모드를 표시합니다.
~]$
getenforce
필요한 경우 SELinux 모드를 전환합니다.
스위치는 일시적이거나 영구적일 수 있습니다. 영구 스위치는 재부팅 시 지속되지 않지만 임시 스위치는 재부팅 시 지속되지 않습니다.
강제 또는 허용 모드로 임시로 전환하려면 다음을 수행합니다.
~]# setenforce Enforcing
~]# setenforce Permissive
SELinux 모드를 영구적으로 설정하려면
/etc/selinux/config
구성 파일에서 SELINUX 변수를 수정합니다.예를 들어 SELinux 를 강제 모드로 전환하려면 다음을 수행합니다.
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing
1.6.2.3. 웹 콘솔에서 SELinux 관리
웹 콘솔에서 강제 정책을 설정하거나 해제하려면 SELinux 옵션을 사용합니다.
기본적으로 웹 콘솔 의 SELinux 강제 정책은 설정되어 있으며 SELinux 는 강제 모드로 작동합니다. 이 모드를 해제하면 SELinux 를 허용 모드로 전환할 수 있습니다. /etc/sysconfig/selinux 파일의 기본 구성에서 이러한 비교는 다음 부팅 시 자동으로 되돌아갑니다.
그림 1.3. 웹 콘솔에서 SELinux 관리
1.6.3. SSH 기반 인증 사용
1.6.3.1. SSH 기반 인증 및 시스템 보안을 조정하는 방법
다른 컴퓨터와의 통신을 보호하려면 SSH 기반 인증을 사용할 수 있습니다.
SSH(Secure Shell)는 클라이언트-서버 통신을 용이하게 하고 사용자가 SSH를 원격으로 실행하는 모든 호스트 시스템에 로그인할 수 있는 프로토콜입니다. SSH가 연결을 암호화합니다. 클라이언트는 암호화를 사용하여 인증 정보를 서버로 전송하며 세션 중에 전송되고 수신되는 모든 데이터는 암호화로 전송됩니다.
SSH를 사용하면 사용자가 암호 없이 인증할 수 있습니다. 이를 위해 SSH는 개인-공개 키 스키마를 사용합니다.
SSH 보호 장치에 대한 자세한 내용은 12.1.2절. “주요 기능” 을 참조하십시오.
1.6.3.2. SSH 연결 설정
SSH 연결을 사용할 수 있으려면 공개 키와 개인 키로 구성된 두 개의 키 쌍을 만듭니다.
키 파일 생성 및 서버에 Them 복사
공개 및 개인 키를 생성합니다.
~]$
ssh-keygen
두 키는 모두
~/.ssh/
디렉터리에 저장됩니다.-
~/.ssh/id_rsa.pub
- public key ~/.SSH/id_rsa
- 개인 키공개 키는 시크릿일 필요가 없습니다. 개인 키를 확인하는 데 사용됩니다. 개인 키는 시크릿입니다. 키 생성 프로세스 중에 지정한 암호로 개인 키를 보호하도록 선택할 수 있습니다. 암호를 사용하면 인증은 더 안전하지만 더 이상 암호가 제공되지 않습니다.
ssh-agent
명령을 사용하여 이를 방지할 수 있습니다. 이 경우 세션이 시작될 때 한 번만 암호를 입력합니다.ssh-agent
구성에 대한 자세한 내용은 12.2.4절. “키 기반 인증 사용” 을 참조하십시오.
-
가장 최근에 수정된 공개 키를 로그인하려는 원격 머신에 복사합니다.
~]# ssh-copy-id USER@hostname
따라서 이제 안전한 방법으로 시스템을 입력할 수 있지만 암호를 입력하지 않아도 됩니다.
1.6.3.3. SSH 루트 로그인 비활성화
시스템 보안을 강화하기 위해 기본적으로 활성화되어 있는 root
사용자의 SSH 액세스를 비활성화할 수 있습니다.
이 항목에 대한 자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드 를 참조하십시오.
SSH 루트 로그인 비활성화
/etc/ssh/sshd_config
파일에 액세스합니다.~]# vi /etc/ssh/sshd_config
#PermitRootLogin yes
를 다음과 같이 읽는 행을 변경합니다.PermitRootLogin no
sshd
서비스를 다시 시작합니다.~]# systemctl restart sshd
1.7. 사용자 계정 관리의 기본 사항
Red Hat Enterprise Linux 7은 다중 사용자 운영 체제로, 다른 컴퓨터에서 여러 사용자가 한 컴퓨터에 설치된 단일 시스템에 액세스할 수 있습니다. 모든 사용자는 자체 계정으로 운영되며 사용자 계정을 관리하여 Red Hat Enterprise Linux 시스템 관리의 핵심 요소를 나타냅니다.
일반 및 시스템 계정
특정 시스템의 사용자를 위해 일반 계정이 생성됩니다. 이러한 계정은 일반 시스템 관리 중에 추가, 제거 및 수정할 수 있습니다.
시스템 계정은 시스템의 특정 애플리케이션 식별자를 나타냅니다. 이러한 계정은 일반적으로 소프트웨어 설치 시에만 추가되거나 조작되며 나중에 수정되지 않습니다.
시스템에서 로컬로 시스템 계정을 사용할 수 있다고 가정합니다. LDAP 구성 인스턴스에서와 같이 이러한 계정이 원격으로 구성되고 제공되는 경우 시스템 중단 및 서비스 시작 오류가 발생할 수 있습니다.
시스템 계정의 경우 1000 미만의 사용자 ID가 예약됩니다. 일반 계정의 경우 1000부터 시작하는 ID를 사용할 수 있습니다. 그러나 권장 사례는 5000에서 시작하는 ID를 할당하는 것입니다. 자세한 내용은 4.1절. “사용자 및 그룹 소개”를 참조하십시오. ID 할당 지침은 /etc/login.defs
파일에서 확인할 수 있습니다.
# Min/max values for automatic uid selection in useradd # UID_MIN 1000 UID_MAX 60000 # System accounts SYS_UID_MIN 201 SYS_UID_MAX 999
어떤 그룹들이 있고, 어떤 용도로 사용됩니까?
그룹은 특정 파일에 대한 액세스 권한 부여와 같은 공통 목적을 위해 여러 사용자 계정을 함께 연결하는 엔티티입니다.
1.7.1. 사용자 계정 및 그룹을 관리하는 가장 기본적인 명령줄 도구
사용자 계정 및 그룹을 관리하는 가장 기본적인 작업과 적절한 명령줄 툴은 다음과 같습니다.
사용자 및 그룹 ID 표시:
~]$
id
새 사용자 계정 생성:
~]# useradd [options] user_name
사용자 이름에 속하는 사용자 계정에 새 암호를 할당합니다.
~]# passwd user_name
그룹에 사용자 추가:
~]# usermod -a -G group_name user_name
사용자 및 그룹 관리에 대한 자세한 내용은 4장. 사용자 및 그룹 관리 을 참조하십시오.
그래픽 사용자 인터페이스를 사용하여 사용자 및 그룹을 관리하려면 4.2절. “그래픽 환경에서 사용자 관리” 을 참조하십시오.
1.7.2. 웹 콘솔에서 사용자 계정 관리
웹 콘솔 에서 계정을 관리하려면 메뉴를 선택합니다.
그림 1.4. 웹 콘솔에서 사용자 계정 관리
1.8. kdump 메커니즘을 사용하여 Crashed 커널 덤프
이 섹션에서는 kdump 라고도 하는 커널 크래시 덤프 메커니즘을 소개하고 1.8.1절. “사용할 수 있는 kdump Is 및 Which 작업” 에서 사용하는 kdump 를 간략하게 설명합니다.
kdump
서비스 활성화는 설치 프로세스의 일부이며, 설치 중에 kdump 가 기본적으로 활성화되었습니다. 이 섹션에서는 1.8.2절. “설치 프로세스 중 kdump 활성화 및 활성화” 에 설치하는 동안 kdump 를 활성화하는 방법과 1.8.3절. “설치 프로세스 후 kdump가 설치 및 활성화되었는지 확인” 의 설치 후 비활성화된 경우 kdump
서비스를 수동으로 활성화하는 방법에 대해 설명합니다.
웹 콘솔 을 사용하여 kdump 를 구성할 수도 있습니다. 자세한 내용은 1.8.4절. “웹 콘솔에서 kdump 구성”를 참조하십시오.
1.8.1. 사용할 수 있는 kdump Is 및 Which 작업
시스템 충돌의 경우 kdump 라는 커널 크래시 덤프 메커니즘을 사용하면 나중에 분석할 수 있도록 시스템 메모리의 내용을 저장할 수 있습니다. kdump 메커니즘은 kexec 시스템 호출을 사용합니다. 이 호출은 다른 커널의 컨텍스트에서 Linux 커널을 부팅하고, BIOS를 우회하고, 손실되는 첫 번째 커널 메모리의 내용을 보존하는 데 사용할 수 있습니다.
커널이 발생하면 kdump 는 kexec를 사용하여 두 번째 커널( capture kernel)으로 부팅합니다. 이 커널은 첫 번째 커널에 액세스할 수 없는 시스템 메모리의 예약된 부분에 있습니다. 두 번째 커널은 충돌한 커널의 메모리(감시 덤프)의 내용을 캡처하여 저장합니다.
1.8.2. 설치 프로세스 중 kdump 활성화 및 활성화
설치 중에 kdump 활성화 및 활성화는 Anaconda 설치 프로그램에서 수행하거나 Kickstart 파일에서 %addon com_redhat_kdump
명령을 사용하여 수행할 수 있습니다.
자세한 내용은 설치 방법에 따라 적절한 소스를 참조하십시오.
Anaconda 설치 프로그램으로 설치할 때 다음을 참조하십시오.
Red Hat Enterprise Linux 7 설치 가이드에서 Anaconda를 사용하여 설치.
Kickstart 파일로 설치하는 경우 다음을 참조하십시오.
Red Hat Enterprise Linux 7 설치 가이드의 Kickstart 명령 및 옵션.
1.8.3. 설치 프로세스 후 kdump가 설치 및 활성화되었는지 확인
kdump 가 설치되었는지 확인하고 구성하려면 다음을 수행합니다.
kdump 설치 및 kdump 구성 확인
kdump 가 시스템에 설치되어 있는지 확인하려면 다음을 수행하십시오.
~]$
rpm -q kexec-tools
설치되지 않은 경우 kdump 를 설치하려면
root
사용자로 입력합니다.~]# yum install kexec-tools
kdump 를 구성하려면 다음을 수행합니다.
명령줄 또는 그래픽 사용자 인터페이스를 사용합니다.
두 옵션 모두 Red Hat Enterprise Linux 7 Kernel Crash Dump Guide에 자세히 설명되어 있습니다.
그래픽 구성 도구를 설치해야 하는 경우:
~]# yum install system-config-kdump
1.8.4. 웹 콘솔에서 kdump 구성
웹 콘솔에서 를 선택하여 확인합니다.
- kdump 상태
- kdump용으로 예약된 메모리 양
- 크래시 덤프 파일의 위치
그림 1.5. 웹 콘솔에서 kdump 구성
1.8.5. kdump의 추가 리소스
kdump 에 대한 자세한 내용은 Red Hat Enterprise Linux 7 Kernel Crash Dump Guide를 참조하십시오.
1.9. ReaR을 사용하여 시스템 복구 수행 및 시스템 백업 생성
소프트웨어 또는 하드웨어 장애가 운영 체제를 중단하면 시스템을 복구하기 위한 메커니즘이 필요합니다. 또한 시스템 백업을 저장해야 하는 것도 유용합니다. Red Hat은 Relax-and-Recover(ReaR) 도구를 사용하여 이러한 두 가지 요구 사항을 모두 충족할 것을 권장합니다.
1.9.1. ReaR Is 및 Which 작업은 사용할 수 있습니다.
Rear는 재해 복구 및 시스템 마이그레이션 유틸리티로 전체 복구 시스템을 만들 수 있습니다. 기본적으로 이 복구 시스템은 스토리지 레이아웃과 부트 로더만 복원하지만 실제 사용자 및 시스템 파일은 복원되지 않습니다.
또한 특정 백업 소프트웨어를 사용하면 재해 복구를 위해 ReaR을 통합할 수 있습니다.
을 다시 사용하여 다음 작업을 수행할 수 있습니다.
- 새 하드웨어에서 복구 시스템 부팅
- 원래 스토리지 레이아웃 복제
- 사용자 및 시스템 파일 복원
1.9.2. ReaR 설치 및 구성 빠른 시작
ReaR을 설치하려면 root
사용자로 를 입력합니다.
~]# yum install rear
/etc/rear/local.conf
파일의 설정을 사용하여 ReaR을 구성합니다.
자세한 내용은 27.1절. “기본 ReaR 사용” 에서 참조하십시오.
1.9.3. ReaR을 사용하여 복구 시스템 생성에 대한 빠른 시작
- 복구 시스템을 생성하려면
root
사용자로 다음 명령을 실행하십시오.
~]# rear mkrescue
ReaR을 사용하여 구조 시스템 생성에 대한 자세한 내용은 27.1.3절. “복구 시스템 생성” 를 참조하십시오.
1.9.4. 백업 소프트웨어를 사용하여 ReaR 구성 빠른 시작
rear에는 NETFS라는 완전히 통합된 내장형 또는 내부 백업 방법이 포함되어 있습니다.
ReaR이 내부 백업 방법을 사용하도록 하려면 다음 행을 /etc/rear/local.conf
파일에 추가하십시오.
BACKUP=NETFS BACKUP_URL=backup location
/etc/rear/local.conf
에 다음 행을 추가하여 새 백업 아카이브를 만들 때 이전 백업 아카이브를 유지하도록 ReaR을 구성할 수도 있습니다.
NETFS_KEEP_OLD_BACKUP_COPY=y
백업을 증분적으로 만들려면 각 실행 시 변경된 파일만 백업됩니다. /etc/rear/local.conf
에 이 행을 추가합니다.
BACKUP_TYPE=incremental
ReaR NETFS 내부 백업 방법 사용에 대한 자세한 내용은 27.2.1절. “Built-in Backup 방법” 을 참조하십시오.
지원되는 외부 백업 방법 및 지원되지 않는 백업 방법에 대한 자세한 내용은 27.2.2절. “지원되는 백업 방법” 및 27.2.3절. “지원되지 않는 백업 방법” 을 참조하십시오.
1.10. 로그 파일을 사용하여 문제 해결
문제를 해결할 때 운영 체제에 대한 다른 정보와 메시지가 포함된 로그 파일을 감사할 수 있습니다. Red Hat Enterprise Linux 7의 로깅 시스템은 내장 syslog 프로토콜을 기반으로 합니다. 특정 프로그램은 이 시스템을 사용하여 이벤트를 기록하고 이를 로그 파일로 구성하며 운영 체제를 감사하고 다양한 문제를 해결할 때 유용합니다.
로그 파일에 대한 자세한 내용은 23장. 로그 파일 보기 및 관리 을 참조하십시오.
1.10.1. services Handling the syslog messages
syslog 메시지는 두 서비스에서 처리됩니다.
-
systemd-journald
데몬 - 커널에서 메시지 수집, 부팅 프로세스의 초기 단계, 데몬이 시작되어 실행될 때의 표준 출력 및 오류, syslog, 추가 처리를 위해 메시지를rsyslog
서비스로 전달합니다. -
rsyslog
서비스 - syslog 메시지를 유형 및 우선 순위에 따라 정렬하고/var/log
디렉터리의 파일에 기록하며 로그가 지속적으로 저장됩니다.
1.10.2. 하위 디렉터리 저장 syslog 메시지 저장
syslog 메시지는 포함된 메시지 및 로그에 따라 /var/log
디렉터리의 다양한 하위 디렉터리에 저장됩니다.
-
var/log/inspector
- 아래에 언급된 syslog 메시지를 제외한 모든 syslog 메시지 -
var/log/secure
- 보안 및 인증 관련 메시지 및 오류 -
var/log/maillog
- 메일 서버 관련 메시지 및 오류 -
var/log/cron
- 주기적으로 실행되는 작업과 관련된 로그 파일 -
var/log/boot.log
- 시스템 시작과 관련된 로그 파일
1.11. Red Hat 지원 액세스
Red Hat의 지원을 받으려면 서브스크립션과 함께 제공되는 모든 항목에 액세스할 수 있는 Red Hat 고객 포털 을 사용하십시오.
이 섹션에서는 다음을 설명합니다.
- Red Hat 지원 받기 참조 1.11.1절. “Red Hat 고객 포털을 통해 Red Hat 지원 요청”
- SOS 보고서를 사용하여 문제 해결을 참조하십시오. 1.11.2절. “문제 해결을 위해 SOS 보고서 사용”
1.11.1. Red Hat 고객 포털을 통해 Red Hat 지원 요청
Red Hat 고객 포털 을 사용하면 다음을 수행할 수 있습니다.
- 새 지원 케이스 만들기
- Red Hat 전문가와의 실시간 채팅 시작
- 전화하거나 이메일을 보내 Red Hat 전문가에게 문의하십시오.
Red Hat 고객 포털에 액세스하려면 https://access.redhat.com 로 이동하십시오.
Red Hat 지원과 관련된 Red Hat 고객 포털 서비스를 사용하려면 다음을 사용할 수 있습니다.
- 웹 브라우저
- Red Hat 지원 도구
1.11.1.1. Red Hat 지원 도구 Is 및 Which 작업이란 무엇입니까?
Red Hat 지원 도구는 서브스크립션 기반 Red Hat 액세스 서비스에 대한 텍스트 콘솔 인터페이스를 제공하는 명령줄 기반 도구입니다. 이 툴은 redhat-support-tool 패키지에 포함되어 있습니다.
Red Hat 지원 도구를 사용하면 다음과 같은 지원 관련 작업을 수행할 수 있습니다.
- 지원 케이스 공개 또는 업데이트
- Red Hat 지식 기반 솔루션 검색
- Python 및 Java 오류 분석
대화형 모드에서 툴을 시작하려면 다음을 수행합니다.
~]$ redhat-support-tool
Welcome to the Red Hat Support Tool.
Command (? for help):
대화형 모드에서 ?를
사용 가능한 명령을 표시합니다.Command (? for help): ?
Red Hat 지원 툴 설치 및 사용에 대한 자세한 내용은 8장. Red Hat 지원 도구를 사용하여 지원에 액세스 및 Red Hat 지식베이스 문서 Red Hat Access를 참조하십시오. Red Hat 지원 도구.
1.11.2. 문제 해결을 위해 SOS 보고서 사용
SOS 보고서는 Red Hat Enterprise Linux 시스템에서 구성 세부 정보, 시스템 정보 및 진단 정보를 수집합니다. 지원 케이스를 열 때 보고서를 첨부합니다.
SOS 보고서는 Red Hat Enterprise Linux 7의 기본 최소 설치로 설치되지 않는 sos 패키지에 제공됩니다.
sos 패키지를 설치하려면 다음을 수행합니다.
~]# yum install sos
SOS 보고서를 생성하려면 다음을 수행합니다.
~]# sosreport
지원 사례에 보고서를 첨부하려면 Red Hat 지식베이스 문서 How can I attach a file to a Red Hat 지원 케이스 에서 참조하십시오. sos 보고서를 연결할 때 지원 케이스 수를 입력하라는 메시지가 표시됩니다.
SOS 보고서에 대한 자세한 내용은 Red Hat 지식베이스 문서 What is a sosreport and how to create one in Red Hat Enterprise Linux 4.6 이상에서 참조하십시오.
2장. System Locale 및 keyboard Configuration
시스템 로케일 은 시스템 서비스 및 사용자 인터페이스의 언어 설정을 지정합니다. 키보드 레이아웃 설정은 텍스트 콘솔 및 그래픽 사용자 인터페이스에서 사용되는 레이아웃을 제어합니다.
이러한 설정은 /etc/locale.conf
구성 파일을 수정하거나 localectl 유틸리티를 사용하여 설정할 수 있습니다. 또한 그래픽 사용자 인터페이스를 사용하여 작업을 수행할 수 있습니다. 이 방법에 대한 설명은 Red Hat Enterprise Linux 7 설치 가이드 를 참조하십시오.
2.1. 시스템 위치 설정
시스템 전체 로케일 설정은 systemd
데몬에서 초기 부팅 시 읽는 /etc/locale.conf
파일에 저장됩니다. /etc/locale.conf
에 구성된 로케일 설정은 개별 프로그램 또는 개별 사용자가 재정의하지 않는 한 모든 서비스 또는 사용자에 의해 상속됩니다.
/etc/locale.conf
의 기본 파일 형식은 줄로 구분된 변수 할당 목록입니다. 예를 들어, /etc/locale.conf
에 영어 메시지가 있는 독일어 로케일은 다음과 같습니다.
LANG=de_DE.UTF-8 LC_MESSAGES=C
여기에서 LC_MESSAGES 옵션은 표준 오류 출력에 기록된 진단 메시지에 사용되는 로케일을 결정합니다. /etc/locale.conf
에서 로케일 설정을 추가로 지정하려면 다른 여러 옵션을 사용할 수 있으므로 가장 관련된 옵션은 표 2.1. “/etc/locale.conf에서 설정 가능한 옵션” 에 요약되어 있습니다. 이러한 옵션에 대한 자세한 내용은 locale(7)
매뉴얼 페이지를 참조하십시오. 가능한 모든 옵션을 나타내는 LC_ALL 옵션은 /etc/locale.conf
에서 구성해서는 안 됩니다.
옵션 | 설명 |
---|---|
ANG | 시스템 로케일의 기본값을 제공합니다. |
LC_COLLATE | 로컬 알파벳의 문자열을 비교하는 함수의 동작을 변경합니다.Changes the behavior of functions that compare strings in the local alphabet. |
LC_CTYPE | 문자 처리 및 분류 함수 및 멀티바이트 문자 함수의 동작을 변경합니다.Changes the behavior of the character handling and classification functions and the multibyte character functions. |
LC_NUMERIC | 소수점과 10진수 쉼표와 같은 세부 정보를 사용하여 숫자를 일반적으로 출력하는 방법을 설명합니다.Describes the way numbers are usually printed, with details such as decimal point and decimal comma. |
LC_TIME | 현재 시간 표시를 24시간과 12시간로 변경합니다. |
LC_MESSAGES | 표준 오류 출력에 기록된 진단 메시지에 사용되는 로케일을 결정합니다. |
2.1.1. 현재 상태 표시
localectl
명령을 사용하여 시스템 로케일 및 키보드 레이아웃 설정을 쿼리하고 변경할 수 있습니다. 현재 설정을 표시하려면 status
옵션을 사용합니다.
localectl
status
예 2.1. 현재 상태 표시
이전 명령의 출력에는 현재 설정된 로케일과 콘솔에 구성된 키보드 레이아웃과 X11 창 시스템이 나열됩니다.
~]$ localectl status System Locale: LANG=en_US.UTF-8 VC Keymap: us X11 Layout: n/a
2.1.2. 사용 가능한 로컬 나열
시스템에 사용 가능한 모든 로케일을 나열하려면 다음을 입력합니다.
localectl
list-locales
예 2.2. 로컬 나열
특정 영어 로케일을 선택한다고 가정하지만 시스템에서 사용할 수 있는지 확실하지 않습니다. 다음 명령으로 모든 영어 로케일을 나열하여 확인할 수 있습니다.
~]$ localectl list-locales | grep en_
en_AG
en_AG.utf8
en_AU
en_AU.iso88591
en_AU.utf8
en_BW
en_BW.iso88591
en_BW.utf8
output truncated
2.1.3. 로컬 설정
기본 시스템 로케일을 설정하려면 다음 명령을 root
로 사용하십시오.
localectl
set-locale
LANG
=locale
locale 을 localectl
list-locales
명령을 사용하여 찾은 로케일 이름으로 바꿉니다. 위의 구문을 사용하여 표 2.1. “/etc/locale.conf에서 설정 가능한 옵션” 에서 매개 변수를 구성할 수도 있습니다.
예 2.3. 기본 지역 변경
예를 들어, English English를 기본 로케일로 설정하려는 경우 먼저 list-locales
를 사용하여 이 로케일의 이름을 찾습니다. 그런 다음 루트
로서 다음 형식으로 명령을 입력합니다.
~]# localectl set-locale LANG=en_GB.utf8
2.1.4. Kickstart로 설치할 때 시스템 로컬 설정 허용
Red Hat Enterprise Linux를 Red Hat Kickstart 설치 방법을 사용하여 설치하는 경우 운영 체제를 업그레이드한 후에는 시스템 로케일 설정이 유지되지 않을 수 있습니다.
Kickstart 파일의 %packages
섹션에 --instLang
옵션이 포함된 경우 _install_langs
RPM 매크로는 이 설치의 특정 값으로 설정되고 설치된 로케일 세트가 적절하게 조정됩니다. 그러나 이러한 조정은 후속 업그레이드가 아닌 이 설치에만 영향을 미칩니다. 업그레이드가 glibc 패키지를 다시 설치하는 경우 설치 중에 요청한 로케일 대신 전체 로케일 집합이 업그레이드됩니다.
이를 방지하려면 영구적으로 로캘을 선택합니다. 이러한 옵션이 있습니다.
- Kickstart 설치를 시작하지 않은 경우 다음 절차를 적용하여 전역적으로 RPM 매크로를 설정하는 지침을 포함하도록 Kickstart 파일을 수정하십시오. Kickstart 설치 중 RPM 매크로 설정
- 이미 시스템을 설치한 경우 다음 절차를 적용하여 시스템에서 RPM 매크로를 전역적으로 설정합니다. 전역적으로 RPM 매크로 설정
Kickstart 설치 중 RPM 매크로 설정
Kickstart 파일의
%post
섹션을 수정합니다.LANG=en_US echo "%_install_langs $LANG" > /etc/rpm/macros.language-conf yum-config-manager --setopt=override_install_langs=$LANG --save
Kickstart 파일의
%packages
섹션을 수정합니다.%packages yum-utils* %end
전역적으로 RPM 매크로 설정
다음 콘텐츠를 사용하여
/etc/rpm/macros. language-conf
에 RPM 구성 파일을 만듭니다.%_install_langs LANG
LANG 는
instLang
옵션의 값입니다./etc/yum.conf
파일을 다음으로 업데이트합니다.override_install_langs=LANG
2.2. keyboard Layout 변경
키보드 레이아웃 설정을 사용하면 텍스트 콘솔 및 그래픽 사용자 인터페이스에서 사용되는 레이아웃을 제어할 수 있습니다.
2.2.1. 현재 설정 표시
이전에 언급했듯이 다음 명령을 사용하여 현재 키보드 레이아웃 구성을 확인할 수 있습니다.
localectl
status
예 2.4. keyboard 설정 표시
다음 출력에서는 가상 콘솔과 X11 창 시스템에 대해 구성된 키보드 레이아웃을 확인할 수 있습니다.
~]$ localectl status System Locale: LANG=en_US.utf8 VC Keymap: us X11 Layout: us
2.2.2. 사용 가능한 키 맵 나열
시스템에서 구성할 수 있는 사용 가능한 모든 키보드 레이아웃을 나열하려면 다음을 입력합니다.
localectl
list-keymaps
예 2.5. Particular Keymap 검색
grep
을 사용하여 이전 명령의 출력을 특정 키맵 이름으로 검색할 수 있습니다. 현재 설정된 로케일과 호환되는 여러 keymap이 종종 있습니다. 예를 들어 사용 가능한 체코 키보드 레이아웃을 찾으려면 다음을 입력합니다.
~]$localectl
list-keymaps
|grep
cz
cz cz-cp1250 cz-lat2 cz-lat2-prog cz-qwerty cz-us-qwertz sunt5-cz-us sunt5-us-cz
2.2.3. Keymap 설정
시스템의 기본 키보드 레이아웃을 설정하려면 root
로 다음 명령을 사용하십시오.
localectl
set-keymap
map
map 을 localectl
list-keymaps
명령의 출력에서 가져온 keymap의 이름으로 바꿉니다. no -convert
옵션이 전달되지 않으면 선택한 설정이 X11 창 시스템의 기본 키보드 매핑에도 적용되며 X11 키보드 매핑은 가장 가까운 X11 키보드 매핑으로 변환됩니다. 이는 역방향에도 적용됩니다. root
로 다음 명령을 사용하여 두 keymaps를 지정할 수 있습니다.
localectl
set-x11-keymap
map
X11 레이아웃이 콘솔 레이아웃과 다르도록 하려면 --no-convert
옵션을 사용합니다.
localectl
--no-convert
set-x11-keymap
map
이 옵션을 사용하면 이전 콘솔 레이아웃 설정을 변경하지 않고 X11 keymap을 지정합니다.
예 2.6. X11 Keymap 분리
그래픽 인터페이스에서 독일어 키보드 레이아웃을 사용하고 있다고 가정하지만 미국 키맵을 유지하려면 콘솔 작업을 사용합니다. 이 작업을 수행하려면 root
로 입력합니다.
~]# localectl --no-convert set-x11-keymap de
그런 다음 현재 상태를 확인하여 설정이 성공했는지 확인할 수 있습니다.
~]$ localectl status System Locale: LANG=de_DE.UTF-8 VC Keymap: us X11 Layout: de
키보드 레이아웃 (맵) 외에도 세 가지 다른 옵션을 지정할 수 있습니다.
localectl
set-x11-keymap
map model variant options
모델을 키보드 모델 이름, 변형 및 옵션으로 키보드 변형 및 옵션 구성 요소로 교체합니다. 이 구성 요소는 키보드 동작을 향상시키는 데 사용할 수 있습니다. 이러한 옵션은 기본적으로 설정되어 있지 않습니다. X11 모델, X11 Variant 및 X11 옵션에 대한 자세한 내용은 kbd(4)
도움말 페이지를 참조하십시오.
2.3. 추가 리소스
Red Hat Enterprise Linux에서 키보드 레이아웃을 구성하는 방법에 대한 자세한 내용은 아래 나열된 리소스를 참조하십시오.
설치된 문서
-
localectl
(1) -localectl
명령줄 유틸리티 문서의 도움말 페이지는 이 툴을 사용하여 시스템 로케일 및 키보드 레이아웃을 구성하는 방법을 설명합니다. -
loadkeys
(1) -loadkeys
명령의 도움말 페이지는 이 도구를 사용하여 가상 콘솔의 키보드 레이아웃을 변경하는 방법에 대한 자세한 정보를 제공합니다.
예를 들면 다음과 같습니다.
-
6장. 권한 확보
su
및sudo
명령을 사용하여 관리 권한을 얻는 방법에 대해 설명합니다. -
10장. systemd를 사용하여 서비스 관리
systemctl
명령을 사용하여 시스템 서비스를 관리하는 방법에 대한systemd
및 문서에 대한 자세한 정보를 제공합니다.
3장. 날짜 및 시간 구성
최신 운영 체제는 다음 두 가지 유형의 시계를 구분합니다.
- 실시간 클럭 (RTC)은 일반적으로 하드웨어 클럭 (일반적으로 시스템 보드의 통합 회로)으로 알려져 있으며 컴퓨터가 종료될 때 실행되는 운영 체제의 현재 상태와 완전히 독립적입니다.
- 커널에 의해 유지 관리되고 초기 값은 실시간 시계를 기반으로하는 시스템 클럭 (소프트웨어 클럭)입니다. 시스템이 부팅되고 시스템 시계가 초기화되면 시스템 클럭은 실시간 시계와 완전히 독립적입니다.
시스템 시간은 항상UTC( 협정 세계시 )로 유지되며 필요에 따라 애플리케이션에서 현지 시간으로 변환됩니다. 현지 시간은 일광 절약 시간 (DST)을 고려하여 현재 표준 시간대의 실제 시간입니다. 실시간 시계는 UTC 또는 현지 시간을 사용할 수 있습니다. UTC가 권장됩니다.
Red Hat Enterprise Linux 7은 시스템 날짜 및 시간에 대한 정보를 구성하고 표시하는 데 사용할 수 있는 세 가지 명령줄 툴을 제공합니다.
-
timedatectl
유틸리티는 Red Hat Enterprise Linux 7의 새로운 기능이며systemd
의 일부입니다. -
기존
date
명령입니다. -
하드웨어 시계에 액세스하기 위한
hwclock
유틸리티입니다.
3.1. timedatectl
명령 사용
timedatectl 유틸리티는 systemd
시스템 및 서비스 관리자의 일부로 배포되며 시스템 클럭의 구성을 검토하고 변경할 수 있습니다. 이 도구를 사용하여 현재 날짜와 시간을 변경하거나 시간대를 설정하거나 원격 서버와 시스템 클럭의 자동 동기화를 활성화할 수 있습니다.
현재 날짜 및 시간을 사용자 지정 형식으로 표시하는 방법에 대한 자세한 내용은 3.2절. “날짜 명령 사용” 도 참조하십시오.
3.1.1. 현재 날짜 및 시간 표시
시스템 및 하드웨어 시계 구성에 대한 자세한 정보와 함께 현재 날짜와 시간을 표시하려면 추가 명령줄 옵션 없이 timedatectl
명령을 실행합니다.
timedatectl
그러면 로컬 및 범용 시간, 현재 사용되는 표준 시간대,NTP
(Network Time Protocol) 구성의 상태, DST와 관련된 추가 정보가 표시됩니다.
예 3.1. 현재 날짜 및 시간 표시
다음은 NTP
를 사용하여 시스템 클럭을 원격 서버와 동기화하는 시스템에서 timedatectl
명령의 출력 예입니다.
~]$ timedatectl Local time: Mon 2016-09-16 19:30:24 CEST Universal time: Mon 2016-09-16 17:30:24 UTC Timezone: Europe/Prague (CEST, +0200) NTP enabled: no NTP synchronized: no RTC in local TZ: no DST active: yes Last DST change: DST began at Sun 2016-03-31 01:59:59 CET Sun 2016-03-31 03:00:00 CEST Next DST change: DST ends (the clock jumps one hour backwards) at Sun 2016-10-27 02:59:59 CEST Sun 2016-10-27 02:00:00 CET
chrony
또는 ntpd
의 상태에 대한 변경 사항은 timedatectl
로 즉시 알 수 없습니다. 이러한 툴의 구성 또는 상태가 변경되면 다음 명령을 입력합니다.
~]# systemctl restart systemd-timedated.service
3.1.2. 현재 시간 변경
현재 시간을 변경하려면 쉘 프롬프트에 root
로 다음을 입력합니다.
timedatectl
set-time
HH:MM:SS
HH 를 1시간, MM 을 1분으로 바꾸고, SS 를 1초로 바꾸면 모두 두 자리형으로 입력됩니다.
이 명령은 시스템 시간과 하드웨어 클럭을 모두 업데이트합니다. 그 결과 date --set
및 hwclock --systohc
명령을 모두 사용하는 것과 유사합니다.
NTP
서비스가 활성화되면 명령이 실패합니다. 서비스를 일시적으로 비활성화하려면 3.1.5절. “원격 서버와 시스템 Clock 동기화” 을 참조하십시오.
예 3.2. 현재 시간 변경
현재 시간을 11:26 p.m.로 변경하려면 root
로 다음 명령을 실행하십시오.
~]# timedatectl set-time 23:26:00
기본적으로 시스템은 UTC를 사용하도록 구성됩니다. 로컬 시간에 클럭을 유지하도록 시스템을 구성하려면 set-local-rtc
옵션을 root
로 timedatectl
명령을 실행합니다.
timedatectl
set-local-rtc
boolean
로컬 시간에 클럭을 유지하도록 시스템을 구성하려면 부울 을 yes
(또는, y
,true
,t
또는 1
)로 바꿉니다. UTC를 사용하도록 시스템을 구성하려면 부울 을 no
(또는, alternatively, n
,false
,f
또는 0
)로 바꿉니다. 기본 옵션은 없습니다
.
3.1.3. 현재 날짜 변경
현재 날짜를 변경하려면 쉘 프롬프트에 root
로 다음을 입력합니다.
timedatectl
set-time
YYYY-MM-DD
octets을 4자리 연도로 바꾸고, MM 을 두 자리 월 한 달로, DD 를 월의 두 자리 날짜로 바꿉니다.
현재 시간을 지정하지 않고 날짜를 변경하면 시간을 00:00:00으로 설정합니다.
예 3.3. 현재 날짜 변경
현재 날짜를 2017년 6월 2일로 변경하고 현재 시간(11:26 p.m.)을 유지하려면 root
로 다음 명령을 실행합니다.
~]# timedatectl set-time "2017-06-02 23:26:00"
3.1.4. 시간대 변경
사용 가능한 모든 시간대를 나열하려면 쉘 프롬프트에서 다음을 입력합니다.
timedatectl
list-timezones
현재 사용된 시간대를 변경하려면 root
로 입력합니다.
timedatectl set-timezone time_zone
time_zone 을 timedatectl list-timezones
명령으로 나열된 값으로 교체합니다.
예 3.4. 시간대 변경
현재 위치와 가장 가까운 시간대를 식별하려면 list-timezones
명령줄 옵션과 함께 timedatectl
명령을 사용합니다. 예를 들어 유럽의 사용 가능한 모든 시간대를 나열하려면 다음을 입력합니다.
~]# timedatectl list-timezones | grep Europe
Europe/Amsterdam
Europe/Andorra
Europe/Athens
Europe/Belgrade
Europe/Berlin
Europe/Bratislava
…
시간대를 유럽/
파그로 변경하려면 root
로 입력합니다.
~]# timedatectl set-timezone Europe/Prague
3.1.5. 원격 서버와 시스템 Clock 동기화
이전 섹션에서 설명하는 수동 조정과 달리, timedatectl
명령을 사용하면 NTP
프로토콜을 사용하여 원격 서버 그룹과 시스템 클럭의 자동 동기화를 활성화할 수도 있습니다. NTP를 활성화하면 설치된 서비스에 따라 chronyd
또는 ntpd
서비스를 활성화합니다.
NTP
서비스는 다음과 같이 명령을 사용하여 활성화 및 비활성화할 수 있습니다.
timedatectl
set-ntp
boolean
시스템에서 시스템 클럭을 원격 NTP
서버와 동기화하도록 활성화하려면 부울 을 yes
(기본값)로 교체합니다. 이 기능을 비활성화하려면 부울 을 no
로 바꿉니다.
예 3.5. 원격 서버와 시스템 Clock 동기화
원격 서버를 사용하여 시스템 클럭의 자동 동기화를 활성화하려면 다음을 입력합니다.
~]# timedatectl set-ntp yes
NTP
서비스가 설치되지 않은 경우 명령이 실패합니다. 자세한 내용은 18.3.1절. “chrony 설치”를 참조하십시오.
3.2. 날짜 명령 사용
날짜
유틸리티는 모든 Linux 시스템에서 사용할 수 있으며 현재 날짜와 시간을 표시하고 구성할 수 있습니다. 스크립트가 사용자 지정 형식으로 시스템 시계에 대한 자세한 정보를 표시하는 데 자주 사용됩니다.
시간대를 변경하거나 원격 서버와 시스템 클럭의 자동 동기화를 활성화하는 방법에 대한 자세한 내용은 3.1절. “timedatectl
명령 사용” 을 참조하십시오.
3.2.1. 현재 날짜 및 시간 표시
현재 날짜 및 시간을 표시하려면 추가 명령줄 옵션 없이 date
명령을 실행합니다.
date
그러면 요일, 현재 날짜, 현지 시간, 축약된 시간대 및 연도가 표시됩니다.
기본적으로 date
명령은 로컬 시간을 표시합니다. 시간을 UTC로 표시하려면 --utc
또는 -u
명령줄 옵션을 사용하여 명령을 실행합니다.
date
--utc
명령줄에서 +" 형식 " 옵션을 제공하여 표시되는 정보의형식
을 사용자 지정할 수도 있습니다.
date +"format"
형식은 예 3.6. “현재 날짜 및 시간 표시” 에 설명된 대로 하나 이상의 지원되는 제어 시퀀스로 바꿉니다. 이러한 옵션의 전체 목록은 표 3.1. “일반적으로 사용되는 제어 순서” 에서 가장 자주 사용되는 포맷 옵션 목록 또는 날짜
(1) 매뉴얼 페이지를 참조하십시오.
제어 순서 | 설명 |
---|---|
|
HH 형식의 시간(예: |
|
MM 형식의 분(예: |
|
두 번째는 SS 형식의 두 번째 형식(예: |
|
DD 형식의 월의 일(예: |
|
MM 형식의 월(예: |
|
octets 형식(예: |
|
표준 시간대 약어(예: |
|
전체 날짜 (예: |
|
HH:MM:SS 형식의 전체 시간(예: 17:30:24)입니다. 이 옵션은 |
예 3.6. 현재 날짜 및 시간 표시
현재 날짜 및 로컬 시간을 표시하려면 쉘 프롬프트에서 다음을 입력합니다.
~]$ date
Mon Sep 16 17:30:24 CEST 2016
현재 날짜 및 시간을 UTC로 표시하려면 쉘 프롬프트에서 다음을 입력합니다.
~]$ date --utc
Mon Sep 16 15:30:34 UTC 2016
date
명령의 출력을 사용자 지정하려면 다음을 입력합니다.
~]$ date +"%Y-%m-%d %H:%M" 2016-09-16 17:30
3.2.2. 현재 시간 변경
현재 시간을 변경하려면 --set
또는 -s
옵션과 함께 date
명령을 root
로 실행합니다.
date
--set
HH:MM:SS
HH 를 1시간, MM 을 1분으로 바꾸고, SS 를 1초로 바꾸면 모두 두 자리형으로 입력됩니다.
기본적으로 date
명령은 시스템 클럭을 로컬 시간으로 설정합니다. UTC로 시스템 시계를 설정하려면 --utc
또는 -u
명령줄 옵션을 사용하여 명령을 실행합니다.
date
--set
HH:MM:SS--utc
예 3.7. 현재 시간 변경
현재 시간을 11:26 p.m.로 변경하려면 root
로 다음 명령을 실행하십시오.
~]# date --set 23:26:00
3.2.3. 현재 날짜 변경
현재 날짜를 변경하려면 --set
또는 -s
옵션과 함께 date
명령을 root
로 실행합니다.
date
--set
YYYY-MM-DD
octets을 4자리 연도로 바꾸고, MM 을 두 자리 월 한 달로, DD 를 월의 두 자리 날짜로 바꿉니다.
현재 시간을 지정하지 않고 날짜를 변경하면 시간을 00:00:00으로 설정합니다.
예 3.8. 현재 날짜 변경
현재 날짜를 2017년 6월 2일로 변경하고 현재 시간(11:26 p.m.)을 유지하려면 root
로 다음 명령을 실행합니다.
~]# date --set "2017-06-02 23:26:00"
3.3. hwclock
명령 사용
H
hwclock은 하드웨어 시계에 액세스하기 위한 유틸리티이며 RTC(Real Time Clock)라고도 합니다. 하드웨어 클럭은 사용하는 운영 체제와 독립적이며 머신이 종료된 경우에도 작동합니다. 이 유틸리티는 하드웨어 클럭에서 시간을 표시하는 데 사용됩니다. hwclock
에는 하드웨어 시계의 체계적인 변동을 보완하기 위한 시설도 포함되어 있습니다.
하드웨어 클럭은 연도, 월, 일, 시간, 분 및 초 값을 저장합니다. 시간 표준, 현지 시간 또는 UTC(협정 세계시)를 저장할 수 없으며 Daylight Saving Time(DST)을 설정할 수 없습니다.
hwclock
유틸리티는 /etc/adjtime
파일에 설정을 저장합니다. 예를 들어 시간을 수동으로 설정하거나 하드웨어 클럭을 시스템 시간과 동기화할 때 첫 번째 변경 사항을 사용하여 생성됩니다.
Red Hat Enterprise Linux 버전 6 및 7 간의 hwclock
동작 변경 사항은 Red Hat Enterprise Linux 7 마이그레이션 플래닝 가이드 를 참조하십시오.
3.3.1. 현재 날짜 및 시간 표시
root
사용자로 명령줄 옵션이 없는 hwclock
을 실행하면 로컬 시간으로의 날짜와 시간을 표준 출력으로 반환합니다.
hwclock
hwclock
명령에 --utc
또는 --localtime
옵션을 사용하면 하드웨어 클럭 시간을 UTC 또는 현지 시간으로 표시하는 것은 아닙니다. 이러한 옵션은 하드웨어 시계를 설정하여 시간 중 하나를 유지하는 데 사용됩니다. 시간은 항상 현지 시간에 표시됩니다. 또한 hwclock --utc
또는 hwclock --local
명령을 사용하면 /etc/adjtime
파일의 레코드가 변경되지 않습니다. 이 명령은 /etc/adjtime
에 저장된 설정이 올바르지만 설정을 변경하지 않으려는 경우 유용할 수 있습니다. 반면 명령을 잘못된 방법으로 사용하면 잘못된 정보가 표시될 수 있습니다. 자세한 내용은 hwclock
(8) 매뉴얼 페이지를 참조하십시오.
예 3.9. 현재 날짜 및 시간 표시
하드웨어 시계에서 현재 날짜와 현재 로컬 시간을 표시하려면 root
로 실행합니다.
~]# hwclock Tue 15 Apr 2017 04:23:46 PM CEST -0.329272 seconds
CEST는 표준 시간대 약어이며 Central Europe Summer Time을 의미합니다.
시간대를 변경하는 방법에 대한 자세한 내용은 3.1.4절. “시간대 변경” 을 참조하십시오.
3.3.2. 날짜 및 시간 설정
날짜 및 시간을 표시하는 것 외에도 하드웨어 시계를 특정 시간으로 수동으로 설정할 수 있습니다.
하드웨어 클럭 날짜와 시간을 변경해야 하는 경우 사양과 함께 --set
및 --date
옵션을 추가하여 이를 수행할 수 있습니다.
hwclock --set --date "dd mmm yyyy HH:MM"
dd 를 하루(두 자리 숫자)로, mmm 를 한 달(3자 약어), yyyy y를 1년(4자리 숫자)으로 바꿉니다. HH 는 1시간(두 자리 숫자)으로 MM 을 1분(두 자리 숫자)으로 바꿉니다.
동시에 --utc
또는 --localtime
옵션을 추가하여 시간을 UTC 또는 현지 시간으로 유지하도록 하드웨어 시계를 설정할 수도 있습니다. 이 경우 UTC
또는 LOCAL
이 /etc/adjtime
파일에 기록됩니다.
예 3.10. 하드웨어 시계를 특정 날짜 및 시간으로 설정
날짜 및 시간을 특정 값 (예: "21:17, 2016년 10월 21일)로 설정하고 하드웨어 시계를 UTC로 유지하려면 다음 형식으로 명령을 실행합니다.
~]# hwclock --set --date "21 Oct 2016 21:17" --utc
3.3.3. 날짜 및 시간 동기화
하드웨어 클럭과 현재 시스템 시간을 두 방향으로 동기화할 수 있습니다.
다음 명령을 사용하여 하드웨어 시계를 현재 시스템 시간으로 설정할 수 있습니다.
hwclock --systohc
NTP를 사용하는 경우 하드웨어 클럭은 11분마다 시스템 클럭에 자동으로 동기화되며 이 명령은 적절한 초기 시스템 시간을 가져오는 데 부팅 시에만 유용합니다.
또는 다음 명령을 사용하여 하드웨어 클럭에서 시스템 시간을 설정할 수 있습니다.
hwclock --hctosys
하드웨어 클럭과 시스템 시간을 동기화할 때 --utc
또는 --localtime
옵션을 추가하여 하드웨어 시계를 로컬 시간 또는 UTC에 유지할지 여부를 지정할 수도 있습니다. --set
,UTC
또는 LOCAL
을 사용하는 것과 유사하게 /etc/adjtime
파일에 기록됩니다.
hwclock --systohc --utc
명령은 timedatectl set-local-rtc false
와 기능적으로 유사하며, hwclock --systohc --local
명령은 timedatectl set-local-rtc true
의 대안입니다.
예 3.11. 시스템 시간과 하드웨어 시계 동기화
하드웨어 시계를 현재 시스템 시간으로 설정하고 하드웨어 시계를 로컬 시간에 유지하려면 다음 명령을 root
로 실행하십시오.
~]# hwclock --systohc --localtime
표준 시간대 및 DST 전환의 문제를 방지하려면 하드웨어 시계를 UTC로 유지하는 것이 좋습니다. 표시된 예 3.11. “시스템 시간과 하드웨어 시계 동기화” 은 예를 들어 기본적으로 하드웨어 클럭이 로컬 시간에 실행되는 것으로 가정하고 다른 모든 시스템은 로컬 시간을 사용하여 수용해야하는 Windows 시스템으로의 경우 유용합니다. 가상 시스템에도 필요할 수 있습니다. 호스트에서 제공하는 가상 하드웨어 시계가 로컬 시간에 실행되는 경우 게스트 시스템도 로컬 시간을 사용하도록 구성해야 합니다.
3.4. 추가 리소스
Red Hat Enterprise Linux 7에서 날짜 및 시간을 구성하는 방법에 대한 자세한 내용은 아래 나열된 리소스를 참조하십시오.
설치된 문서
-
timedatectl
(1) - 이 도구를 사용하여 시스템 클럭 및 해당 설정을 쿼리하고 변경하는 방법에 대한timedatectl
명령줄 유틸리티 문서입니다. -
date
(1) -date
명령의 도움말 페이지는 지원되는 명령줄 옵션의 전체 목록을 제공합니다. -
hwclock
(8) -hwclock
명령의 도움말 페이지는 지원되는 명령줄 옵션의 전체 목록을 제공합니다.
예를 들면 다음과 같습니다.
- 2장. System Locale 및 keyboard Configuration 키보드 레이아웃을 구성하는 방법
-
6장. 권한 확보
su
및sudo
명령을 사용하여 관리 권한을 얻는 방법에 대해 설명합니다. -
10장. systemd를 사용하여 서비스 관리
systemctl
명령을 사용하여 시스템 서비스를 관리하는 방법에 대한 systemd 및 문서에 대한 자세한 정보를 제공합니다.
4장. 사용자 및 그룹 관리
사용자 및 그룹 제어는 Red Hat Enterprise Linux 시스템 관리의 핵심 요소입니다. 이 장에서는 그래픽 사용자 인터페이스 및 명령줄의 사용자와 그룹을 추가, 관리 및 삭제하는 방법을 설명하고, 그룹 디렉터리 만들기와 같은 고급 주제를 다룹니다.
4.1. 사용자 및 그룹 소개
사용자는 (물리적 사용자와 연결된 계정) 또는 특정 애플리케이션을 위해 존재하는 계정일 수 있지만, 그룹은 공통 목적을 위해 사용자를 다루는 논리적 표현입니다. 그룹 내의 사용자는 해당 그룹이 소유한 파일을 읽기, 쓰기 또는 실행할 수 있는 동일한 권한을 공유합니다.
각 사용자는 사용자 ID(UID)라는 고유한 숫자 ID 번호와 연결됩니다. 마찬가지로 각 그룹은 그룹 ID (GID)와 연결됩니다. 파일을 생성하는 사용자도 해당 파일의 소유자와 그룹 소유자입니다. 파일에는 소유자, 그룹 및 기타 모든 사용자에 대한 별도의 읽기, 쓰기, 실행 권한이 할당됩니다. 파일 소유자는 루트 에서만 변경할 수 있으며
사용자와 파일 소유자 모두 액세스 권한을 변경할 수 있습니다.
root
또한 Red Hat Enterprise Linux는 소유자 이외의 특정 사용자에 대한 권한을 허용하는 파일 및 디렉토리에 대해ACL( 액세스 제어 목록 )을 지원합니다. 이 기능에 대한 자세한 내용은 5장. 액세스 제어 목록 을 참조하십시오.
예약된 사용자 및 그룹 ID
Red Hat Enterprise Linux는 시스템 사용자 및 그룹에 대해 1000 미만의 사용자 및 그룹 ID를 예약합니다. 기본적으로 사용자 관리자 는 시스템 사용자를 표시하지 않습니다. 예약된 사용자 및 그룹 ID는 설정 패키지에 설명되어 있습니다. 문서를 보려면 다음 명령을 사용하십시오.
cat /usr/share/doc/setup*/uidgid
예약된 범위가 나중에 증가할 수 있으므로 아직 예약되지 않은 5,000에서 시작하는 ID를 할당하는 것이 좋습니다. 기본적으로 새 사용자에게 ID를 할당하도록 하려면 /etc/login.defs
파일에서 UID_MIN
및 GID_MIN
지시문을 변경합니다.
[file contents truncated] UID_MIN 5000 [file contents truncated] GID_MIN 5000 [file contents truncated]
UID_MIN
및 GID_MIN
지시문을 변경하기 전에 생성된 사용자의 경우 UID는 여전히 기본값 1000에서 시작합니다.
5,000으로 시작하는 새 사용자 및 그룹 ID를 사용하더라도 1000개 이상의 시스템에 의해 예약된 ID를 확보하지 않는 것이 1000개의 제한을 유지하는 시스템과 충돌하지 않도록 하는 것이 좋습니다.
4.1.1. 사용자 개인 그룹
Red Hat Enterprise Linux는UPG( 사용자 개인 그룹 ) 체계를 사용하므로 UNIX 그룹을 보다 쉽게 관리할 수 있습니다. 새 사용자가 시스템에 추가될 때마다 사용자 개인 그룹이 생성됩니다. 이 명령은 생성된 사용자와 동일한 이름을 가지며, 해당 사용자는 사용자 개인 그룹의 유일한 멤버입니다.
사용자 개인 그룹을 사용하면 새로 생성된 파일 또는 디렉토리에 대한 기본 권한을 설정하여 해당 사용자의 사용자 및 그룹을 모두 파일 또는 디렉토리를 수정할 수 있습니다.
새로 생성된 파일 또는 디렉터리에 적용되는 권한을 permissions라고 결정하는 설정은 /etc/bashrc
파일에 구성됩니다. 일반적으로 UNIX 기반 시스템에서는 파일 또는 디렉토리를 생성한 사용자만 수정할 수 있는 permissions가 022
로 설정됩니다. 이 체계 하에서, 크리에이터 그룹의 멤버를 포함한 다른 모든 사용자는 수정할 수 없습니다. 그러나 UPG 스키마에서는 모든 사용자에게 고유한 개인 그룹이 있으므로 이 "그룹 보호"가 필요하지 않습니다. 자세한 내용은 4.3.5절. “프롬프트를 사용하여 새 파일에 대한 기본 권한 설정
”를 참조하십시오.
모든 그룹 목록은 /etc/group
구성 파일에 저장됩니다.
4.1.2. 섀도우 암호
여러 사용자가 있는 환경에서는 shadow-utils 패키지에서 시스템 인증 파일의 보안을 강화할 수 있는 섀도우 암호를 사용하는 것이 매우 중요합니다. 이러한 이유로 설치 프로그램은 기본적으로 shadow 암호를 활성화합니다.
다음은 섀도우 암호가 UNIX 기반 시스템에 암호를 저장하는 기존 방법에 비해 다음과 같은 이점 목록입니다.
-
shadow 암호는 암호화된 암호 해시를 world-readable
/etc/passwd
파일에서/etc/shadow
로 이동하여 시스템 보안을 향상시킵니다.root
사용자만 읽을 수 있습니다. - shadow 암호는 암호 변경에 대한 정보를 저장합니다.
-
shadow 암호를 사용하면
/etc/login.defs
파일에 설정된 일부 보안 정책을 적용할 수 있습니다.
shadow-utils 패키지에서 제공하는 대부분의 유틸리티는 섀도우 암호 활성화 여부에 관계없이 제대로 작동합니다. 그러나 암호 변경 정보는 /etc/shadow
파일에만 저장되므로 먼저 섀도우 암호를 활성화하지 않고 일부 유틸리티 및 명령이 작동하지 않습니다.
-
chage
유틸리티는 암호 사용 기간 매개 변수를 설정합니다. 자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드의 암호 보안 섹션을 참조하십시오. -
/etc/group
파일을 관리하는gpasswd
유틸리티입니다. -
-e, --expiredate
또는-f, --inactive
옵션을 사용하는usermod
명령. -
-e, --expiredate
또는-f, --inactive
옵션을 사용하는useradd
명령.
4.2. 그래픽 환경에서 사용자 관리
Users 유틸리티를 사용하면 그래픽 사용자 인터페이스에서 로컬 사용자를 확인, 수정, 추가 및 삭제할 수 있습니다.
4.2.1. 사용자 설정 도구 사용
Super 키를 눌러 활동 개요를 입력하고 사용자를
입력한 다음 Enter 를 누릅니다. 사용자 설정 도구가 나타납니다. Super 키는 키보드와 기타 하드웨어에 따라 다양한 길잡이에 표시되지만 일반적으로 공간 표시줄의 왼쪽에 Windows 또는 Command 키로 나타납니다. 또는 화면 오른쪽 상단에 있는 사용자 이름을 클릭한 후 Settings 메뉴에서 Users 유틸리티를 열 수 있습니다.
사용자 계정을 변경하려면 먼저 root
로 인증하라는 메시지를 표시합니다. 사용자를 추가하고 제거하려면 각각 및 버튼을 선택합니다. 관리 그룹 wheel
에 사용자를 추가하려면 계정 유형을 Standard
에서 Administrator
로 변경합니다. 사용자 언어 설정을 편집하려면 언어 및 드롭다운 메뉴가 표시됩니다.
그림 4.1. 사용자 설정 도구
새 사용자가 생성되면 암호가 설정될 때까지 계정이 비활성화됩니다. 그림 4.2. “비밀번호 메뉴” 에 표시된 암호 드롭다운 메뉴에는 관리자가 즉시 암호를 설정하거나, 처음 로그인할 때 사용자가 암호를 선택하거나, 로그인에 필요한 암호 없이 게스트 계정을 생성합니다. 이 메뉴에서 계정을 비활성화하거나 활성화할 수도 있습니다.
그림 4.2. 비밀번호 메뉴
4.3. 명령줄 툴 사용
4.2절. “그래픽 환경에서 사용자 관리” 에 설명된 사용자 설정 도구 외에도 표 4.1. “사용자 및 그룹을 관리하기 위한 명령줄 유틸리티” 에 설명된 사용자 및 그룹 관리를 위해 명령줄 툴을 사용할 수 있습니다.
유틸리티 | 설명 |
---|---|
| 사용자 및 그룹 ID를 표시합니다. |
| 사용자 계정을 추가, 수정 및 삭제하는 표준 유틸리티입니다. |
| 그룹을 추가, 수정 및 삭제하는 표준 유틸리티입니다. |
|
유틸리티는 주로 |
| 암호, 그룹 및 관련 shadow 파일을 확인하는 데 사용할 수 있는 유틸리티입니다. |
| 암호를 섀도우 암호로 변환하거나 섀도 암호에서 표준 암호로 전환하는 데 사용할 수 있는 유틸리티입니다. |
| 이전과 유사하게 이러한 유틸리티를 사용하여 그룹 계정에 대한 shadowed 정보를 변환할 수 있습니다. |
4.3.1. 새 사용자 추가
새 사용자를 시스템에 추가하려면 쉘 프롬프트에서 root
로 다음을 입력합니다.
useradd
options username
여기서 옵션 은 표 4.2. “일반 useradd 명령줄 옵션” 에 설명된 대로 명령줄 옵션입니다.
기본적으로 useradd
명령은 잠긴 사용자 계정을 생성합니다. 계정 잠금을 해제하려면 root
로 다음 명령을 실행하여 암호를 할당합니다.
passwd
username
필요한 경우 암호 사용 기간 정책을 설정할 수 있습니다. Red Hat Enterprise Linux 7 보안 가이드의 암호 보안 섹션을 참조하십시오.
옵션 | |
---|---|
| 주석은 임의의 문자열로 교체할 수 있습니다. 이 옵션은 일반적으로 사용자의 전체 이름을 지정하는 데 사용됩니다. |
|
기본 |
| octets-MM-DD 형식으로 계정을 비활성화하는 날짜입니다. |
|
암호가 만료된 후 계정이 비활성화될 때까지 일 수입니다. |
| 사용자 default( primary) 그룹의 그룹 이름 또는 그룹 번호입니다. 그룹은 여기에 지정되기 전에 존재해야 합니다. |
| 사용자가 멤버인 쉼표로 구분된 추가(기본값 이외의) 그룹 이름 또는 그룹 번호 목록입니다. 그룹은 여기에 지정되기 전에 존재해야 합니다. |
| 홈 디렉터리가 없는 경우 해당 디렉터리를 생성합니다. |
| 홈 디렉터리를 생성하지 마십시오. |
| 사용자에 대한 사용자 개인 그룹을 생성하지 마십시오. |
|
|
| 홈 디렉터리없이 1000 미만의 UID가 있는 시스템 계정을 생성합니다. |
|
기본값은 |
| 사용자의 사용자 ID는 unique이고 unique여야 합니다. |
시스템 및 일반 사용자의 기본 ID 범위는 Red Hat Enterprise Linux 7에서 이전 릴리스에서 변경되었습니다. 이전에는 일반 사용자에 대해 위의 시스템 사용자 및 값에 UID 1-499가 사용되었습니다. 시스템 사용자의 기본 범위는 이제 1-999입니다. 이러한 변경으로 인해 기존 사용자가 500~900 사이의 UID와 GID가 있는 Red Hat Enterprise Linux 7로 마이그레이션할 때 문제가 발생할 수 있습니다. UID 및 GID의 기본 범위는 /etc/login.defs
파일에서 변경할 수 있습니다.
프로세스 설명
다음 단계는 useradd juan
명령이 섀도가 활성화된 시스템에서 실행된 경우 어떤 일이 발생하는지를 보여줍니다.
/etc/passwd에
대한
새 행이/etc/passwd
에 생성됩니다.juan:x:1001:1001::/home/juan:/bin/bash
라인에는 다음과 같은 특징이 있습니다.
-
사용자 이름으로
시작합니다
. -
시스템에서 섀도우 암호를 사용하고 있음을 나타내는
x
(암호) 필드에는 x가 있습니다. - 6443보다 큰 UID가 생성됩니다. Red Hat Enterprise Linux 7에서 1000 미만의 UID는 시스템 사용을 위해 예약되어 있으며 사용자에게 할당해서는 안 됩니다.
- 6443보다 큰 GID가 생성됩니다. Red Hat Enterprise Linux 7에서 1000 미만의 GID는 시스템 사용을 위해 예약되어 있으며 사용자에게 할당해서는 안 됩니다.
- 선택적 GECOS 정보는 비어 있습니다. GECOS 필드는 사용자의 전체 이름 또는 전화 번호와 같은 추가 정보를 제공하는 데 사용할 수 있습니다.
-
juan
의 홈 디렉토리는/home/juan/
로 설정됩니다. -
기본 쉘은
/bin/bash
로 설정됩니다.
-
사용자 이름으로
/etc/shadow에
대한
새 행이/etc/shadow
에 생성됩니다.juan:!!:14798:0:99999:7:::
라인에는 다음과 같은 특징이 있습니다.
-
사용자 이름으로
시작합니다
. 두 개의 느낌표(
!!
)가 계정을 잠그는/etc/shadow
파일의 password 필드에 나타납니다.참고암호화된 암호가
-p
플래그를 사용하여 전달되면 사용자의 새 줄의/etc/shadow
파일에 배치됩니다.- 암호는 만료되지 않음으로 설정됩니다.
-
사용자 이름으로
jan이라는 그룹의 새 행이
/etc/group
에 생성됩니다.juan:x:1001:
사용자와 동일한 이름을 가진 그룹을 사용자 개인 그룹 이라고 합니다. 사용자 개인 그룹에 대한 자세한 내용은 4.1.1절. “사용자 개인 그룹” 을 참조하십시오.
/etc/group
에서 생성된 행은 다음과 같은 특징이 있습니다.-
그룹 이름으로
시작합니다
. -
시스템이 섀도우 그룹 암호를 사용하고 있음을 나타내는
x
가 password 필드에 나타납니다. -
GID는
/etc/passwd
에 있는juan
의 기본 그룹에 대해 나열된 항목과 일치합니다.
-
그룹 이름으로
jan이라는 그룹의 새 행이
/etc/gshadow
에 생성됩니다.juan:!::
라인에는 다음과 같은 특징이 있습니다.
-
그룹 이름으로
시작합니다
. -
느낌표(!
/etc/gshadow
파일의 password 필드에 나타납니다. - 다른 모든 필드는 비어 있습니다.
-
그룹 이름으로
/home
디렉토리에 사용자juan
의 디렉터리가 생성됩니다.~]# ls -ld /home/juan drwx------. 4 juan juan 4096 Mar 3 18:23 /home/juan
이 디렉토리는 사용자
juan
및 groupjuan
이 소유합니다. 이 명령은 사용자(Jenan)에 대해서만 읽기,쓰기, 실행 권한을보유합니다
. 기타 모든 권한은 거부됩니다./etc/skel/
디렉터리 내의 파일(기본 사용자 설정이 포함된)은 새/home/juan/
디렉토리에 복사됩니다.~]# ls -la /home/juan total 28 drwx------. 4 juan juan 4096 Mar 3 18:23 . drwxr-xr-x. 5 root root 4096 Mar 3 18:23 .. -rw-r--r--. 1 juan juan 18 Jun 22 2010 .bash_logout -rw-r--r--. 1 juan juan 176 Jun 22 2010 .bash_profile -rw-r--r--. 1 juan juan 124 Jun 22 2010 .bashrc drwxr-xr-x. 4 juan juan 4096 Nov 23 15:09 .mozilla
이 시점에서 'Udan'이라는 잠긴
계정이 시스템에 있습니다. 이를 활성화하려면 다음으로는 passwd
명령을 사용하여 계정에 암호를 할당하고 선택적으로 암호 사용 지침을 설정합니다(자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드의 암호 보안 섹션 참조).
4.3.2. 새 그룹 추가
새 그룹을 시스템에 추가하려면 쉘 프롬프트에서 root
로 다음을 입력합니다.
groupadd options group_name
여기서 옵션 은 표 4.3. “공통 groupadd 명령줄 옵션” 에 설명된 대로 명령줄 옵션입니다.
옵션 | 설명 |
---|---|
|
|
| 그룹의 그룹 ID는 unique이고 unique여야 합니다. |
|
|
| 중복된 GID를 사용하여 그룹을 생성할 수 있습니다. |
| 이 암호화된 암호를 새 그룹에 사용합니다. |
| GID가 1000 미만인 시스템 그룹을 만듭니다. |
4.3.3. 기존 그룹에 기존 사용자 추가
usermod
유틸리티를 사용하여 기존 사용자를 기존 그룹에 추가합니다.
usermod
의 다양한 옵션은 사용자의 기본 그룹과 해당 보조 그룹에 다른 영향을 미칩니다.
사용자의 기본 그룹을 재정의하려면 root
로 다음 명령을 실행합니다.
~]# usermod -g group_name user_name
사용자의 보조 그룹을 재정의하려면 root
로 다음 명령을 실행합니다.
~]# usermod -G group_name1,group_name2,... user_name
이 경우 사용자의 이전의 모든 보조 그룹이 새 그룹 또는 여러 개의 새 그룹으로 교체됩니다.
사용자 보조 그룹에 하나 이상의 그룹을 추가하려면 root
로 다음 명령 중 하나를 실행합니다.
~]# usermod -aG group_name1,group_name2,... user_name
~]# usermod --append -G group_name1,group_name2,... user_name
이 경우 새 그룹이 사용자의 현재 보조 그룹에 추가됩니다.
4.3.4. 그룹 디렉터리 생성
시스템 관리자는 일반적으로 각 주요 프로젝트에 대한 그룹을 만들고 해당 프로젝트의 파일에 액세스해야 할 때 그룹에 사용자를 할당하는 것을 선호합니다. 이 기존 스키마를 사용하면 파일 관리가 어렵습니다. 사용자가 파일을 만들 때 해당 파일이 속한 기본 그룹과 연결됩니다. 한 사람이 여러 프로젝트에서 작업하면 올바른 파일을 올바른 그룹과 연결하는 것이 어려워집니다. 그러나 UPG 스키마를 사용하면 groups가 setgid 비트가 설정된 디렉터리 내에 생성된 파일에 자동으로 할당됩니다. setgid 비트는 디렉터리 내에 있는 사용자가 디렉터리를 소유한 그룹이 소유하므로 공통 디렉터리를 공유하는 그룹 프로젝트를 매우 간단하게 관리할 수 있습니다.
예를 들어, 사용자 그룹은 /opt/myproject/
디렉토리의 파일에서 작업해야 합니다. 일부 사용자는 이 디렉터리의 내용을 수정할 수 있지만 모든 사람이 수정할 수는 없습니다.
루트
로서 쉘 프롬프트에서 다음을 입력하여/opt/myproject/
디렉터리를 만듭니다.mkdir /opt/myproject
myproject
그룹을 시스템에 추가합니다.groupadd myproject
/opt/myproject/
디렉터리의 콘텐츠를myproject
그룹과 연결합니다.chown root:myproject /opt/myproject
그룹의 사용자가 디렉터리 내에 파일을 생성하고 setgid 비트를 설정할 수 있도록 허용합니다.
chmod 2775 /opt/myproject
이 시점에서
myproject
그룹의 모든 멤버는 사용자가 새 파일을 쓸 때마다 파일 권한을 변경하지 않고도/opt/myproject/
디렉토리에서 파일을 만들고 편집할 수 있습니다. 권한이 올바르게 설정되었는지 확인하려면 다음 명령을 실행합니다.~]# ls -ld /opt/myproject drwxrwsr-x. 3 root myproject 4096 Mar 3 18:31 /opt/myproject
myproject
그룹에 사용자를 추가합니다.usermod -aG myproject username
4.3.5. 프롬프트를 사용하여 새 파일에 대한 기본 권한 설정
프로세스에서 파일을 생성할 때 파일에는 특정 기본 권한(예: -rw-rw-r--
)이 있습니다. 이러한 초기 권한은 파일 권한 마스크 또는 umask 라고도 하는 파일 모드 생성 마스크 로 부분적으로 정의됩니다. 예를 들어, bash 에는 기본적으로 모든 프로세스에 자체 imagestreamtag 가
있습니다. 프로세스 imagestreamtag 는 변경될 수 있습니다.
다음로 구성된 imagestreamtag
jaeger 는 표준 파일 권한에 해당하는 비트로 구성됩니다. 예를 들어 dependencies 0 137
의 경우 숫자는 다음과 같습니다.
-
0
= no meaning, it is always0
(umask does not affect special bits) -
1
= 소유자 권한의 경우 실행 비트가 설정됩니다. -
3
= 그룹 권한의 경우 실행 및 쓰기 비트가 설정됩니다. -
7
= 기타 권한의 경우 실행, 쓰기 및 읽기 비트가 설정됩니다.
U마스크는 바이너리, 8진수 또는 심볼릭 표기법으로 표현할 수 있습니다. 예를 들어 8진수 표현 0137
은 심볼릭 표현 u=rw-,g=r-,o=-- 입니다
. 기호 표기법 사양은 8진수 표기법 사양과 반대됩니다. 금지된 권한이 아니라 허용되는 권한이 표시됩니다.
imagestreamtag 작동 방식
jaeger 는 파일에 대한 권한을 설정하지 못하도록 합니다.
- syslog에 비트가 설정되어 있으면 파일에 설정되지 않습니다.
- messages에 비트가 설정되지 않은 경우 다른 요인에 따라 파일에서 설정할 수 있습니다.
다음 그림은 alerts 0137
이 새 파일 생성에 미치는 영향을 보여줍니다.
그림 4.3. 파일을 생성할 때 alerts 적용
보안상의 이유로 일반 파일은 기본적으로 실행 권한을 가질 수 없습니다. 따라서 credentials 가 권한을 금지하지 않는 0000
이지만 새 일반 파일에는 여전히 실행 권한이 없습니다. 그러나 실행 권한을 사용하여 디렉터리를 생성할 수 있습니다.
[john@server tmp]$ umask 0000 [john@server tmp]$ touch file [john@server tmp]$ mkdir directory [john@server tmp]$ ls -lh . total 0 drwxrwxrwx. 2 john john 40 Nov 2 13:17 directory -rw-rw-rw-. 1 john john 0 Nov 2 13:17 file
4.3.5.1. 쉘에서 imagestreamtag 관리
bash
,ksh
,zsh
및 tcsh
와 같은 인기 있는 쉘의 경우 umask
쉘 내장
. 쉘에서 시작된 프로세스는 dependencies를 상속합니다.
현재 마스크를 표시
현재 umask 를 8진수 표기법으로 표시하려면 다음을 수행합니다.
~]$ umask
0022
현재 mTLS를 심볼릭 표기법으로 표시하려면 다음을 수행합니다.
~]$ umask -S
u=rwx,g=rx,o=rx
syslog를 사용하여 쉘에 마스크 설정
8진수 표기법을 사용하여 현재 쉘 세션에 대해 mTLS를 설정하려면 다음을 실행합니다.
~]$ umask octal_mask
8 진수_마스크 를 0
에서 7
까지 4자리 이하로 대체합니다. 세 자리 이하가 제공되면 명령에 선행 0이 포함된 것처럼 권한이 설정됩니다. 예를 들어, dependencies 7
은 0007
로 변환됩니다.
예 4.1. 10월al Notation을 사용하여 imagestreamtag 설정
새 파일에 소유자 및 그룹에 대한 쓰기 및 실행 권한이 없도록 하고 다른 사용자에 대한 권한이 없도록 하려면 다음을 수행합니다.
~]$ umask 0337
또는 간단히:
~]$ umask 337
심볼릭 표기법을 사용하여 현재 쉘 세션에 대해 mTLS를 설정하려면 다음을 수행합니다.
~]$ umask -S symbolic_mask
예 4.2. Symbolic Notation을 사용하여 receiver 설정
심볼릭 표기법을 사용하여 receiver 0337
을 설정하려면 다음을 수행합니다.
~]$ umask -S u=r,g=r,o=
기본 쉘 dependencies로 작업
쉘에는 일반적으로 기본 mTLS가 설정된 설정 파일이 있습니다. bash
의 경우 /etc/bashrc
입니다. 기본 bash
umask를 표시하려면 다음을 수행합니다.
~]$ grep -i -B 1 umask /etc/bashrc
출력 결과에서 dependencies 명령 또는 UMASK
변수를
사용하는 경우 output이 표시됩니다. 다음 예에서 umask
는 permissions 명령을 사용하여 022
로 설정됩니다.
~]$ grep -i -B 1 umask /etc/bashrc # By default, we want umask to get set. This sets it for non-login shell. -- if [ $UID -gt 199 ] && [ “id -gn” = “id -un” ]; then umask 002 else umask 022
bash
에 대한 기본 umask
를 변경하려면 /etc/bashrc
.org에서 permissions 명령 호출 또는 UMASK
변수 할당을 변경합니다. 이 예에서는 기본 umask 를 0227
로 변경합니다.
if [ $UID -gt 199 ] && [ “id -gn” = “id -un” ]; then
umask 002
else
umask 227
특정 사용자의 기본 쉘 messages로 작업
기본적으로 새 사용자의 bash
umask 는 /etc/bashrc
에 정의된 기본값으로 설정됩니다.
특정 사용자에 대해 bash
umask
를 변경하려면 해당 사용자의 $HOME/.bashrc
파일에 있는 dependencies 명령에 대한 호출을 추가합니다. 예를 들어 사용자 john
의 bash
umask 를 0227
로 변경하려면 다음을 수행합니다.
john@server ~]$ echo 'umask 227' >> /home/john/.bashrc
새로 생성된 홈 디렉터리에 대한 기본 권한 설정
생성된 사용자 홈 디렉터리의 권한을 변경하려면 /etc/login.defs
파일에서 UMASK
변수를 변경합니다.
# The permission mask is initialized to this value. If not specified,
# the permission mask will be initialized to 022.
UMASK 077
4.4. 추가 리소스
Red Hat Enterprise Linux에서 사용자 및 그룹을 관리하는 방법에 대한 자세한 내용은 아래 나열된 리소스를 참조하십시오.
설치된 문서
사용자 및 그룹 관리를 위한 다양한 유틸리티에 대한 자세한 내용은 다음 매뉴얼 페이지를 참조하십시오.
-
useradd
(8) -useradd
명령 문서의 수동 페이지에서 새 사용자를 만드는 방법을 설명합니다. -
userdel
(8) -userdel
명령의 수동 페이지는 사용자를 삭제하는 데 사용하는 방법에 대해 설명합니다. -
usermod
(8) -usermod
명령의 도움말 페이지에서 사용자를 수정하는 방법을 설명합니다. -
groupadd
(8) -groupadd
명령 문서의 도움말 페이지에서 새 그룹을 생성하는 방법을 설명합니다. -
groupdel
(8) -groupdel
명령의 도움말 페이지에서 그룹을 삭제하는 방법을 설명합니다. -
groupmod
(8) -groupmod
명령의 도움말 페이지에서 그룹 멤버십을 수정하는 방법을 설명합니다. -
gpasswd
(1) -gpasswd
명령 문서의 수동 페이지/etc/group
파일 관리 방법입니다. -
grpck
(8) -grpck
명령의 수동 페이지 사용 방법을 사용하여/etc/group
파일의 무결성을 확인합니다. -
pwck
(8) -pwck
명령의 수동 페이지는 이를 사용하여/etc/passwd
및/etc/shadow
파일의 무결성을 확인하는 방법을 설명합니다. -
pwconv
pwunconv
,grpconv
,grpunconv
명령의 수동 페이지, 암호 및 그룹의 섀도우 정보를 변환하는 방법을 설명합니다. -
ID (1) -
id
-
imagestreamtag
(2) - 파일 모드 생성 마스크를 사용하는 방법에 대한 permissions 명령의 수동 페이지입니다.
관련 구성 파일에 대한 자세한 내용은 다음을 참조하십시오.
-
그룹
(5) -/etc/group
파일 문서의 도움말 페이지는 이 파일을 사용하여 시스템 그룹을 정의하는 방법을 설명합니다. -
passwd
(5) - 이 파일을 사용하여 사용자 정보를 정의하는 방법을/etc/passwd
파일의 도움말 페이지. -
shadow
(5) - 이 파일을 사용하여 시스템에 대한 암호 및 계정 만료 정보를 설정하는 방법을 설명합니다.
온라인 문서
- Red Hat Enterprise Linux 7 보안 가이드 - Red Hat Enterprise Linux 7의 보안 가이드에서 는 암호 사용 기간 및 사용자 계정 잠금을 활성화하여 암호 보안과 워크스테이션을 보호하는 방법에 대한 추가 정보를 제공합니다.
예를 들면 다음과 같습니다.
-
6장. 권한 확보
su
및sudo
명령을 사용하여 관리 권한을 얻는 방법에 대해 설명합니다.
5장. 액세스 제어 목록
파일 및 디렉터리에는 파일 소유자, 파일과 연결된 그룹, 시스템의 기타 모든 사용자에 대한 권한 세트가 있습니다. 그러나 이러한 권한 세트에는 제한 사항이 있습니다. 예를 들어 다른 사용자에 대해 다른 권한을 구성할 수 없습니다. 따라서 ACL( 액세스 제어 목록 )이 구현되었습니다.
Red Hat Enterprise Linux 커널은 ext3 파일 시스템과 NFS 내보내기 파일 시스템에 대한 ACL 지원을 제공합니다. ACL은 Samba를 통해 액세스하는 ext3 파일 시스템에서도 인식됩니다.
커널의 지원과 함께 ACL을 구현하려면 acl
패키지가 필요합니다. 여기에는 ACL 정보를 추가, 수정, 제거 및 검색하는 데 사용되는 유틸리티가 포함되어 있습니다.
cp
및 mv
명령은 파일 및 디렉터리와 관련된 모든 ACL을 복사하거나 이동합니다.
5.1. 파일 시스템 마운트
파일 또는 디렉토리에 ACL을 사용하기 전에 파일 또는 디렉터리의 파티션을 ACL 지원으로 마운트해야 합니다. 로컬 ext3 파일 시스템인 경우 다음 명령을 사용하여 마운트할 수 있습니다.
mount -t ext3 -o acl device-name 파티션
예를 들면 다음과 같습니다.
mount -t ext3 -o acl /dev/VolGroup00/LogVol02 /work
또는 /etc/fstab
파일에 파티션이 나열된 경우 파티션에 대한 항목에 acl
옵션이 포함될 수 있습니다.
LABEL=/work /work ext3 acl 1 2
Samba를 통해 ext3 파일 시스템에 액세스하고 ACL이 활성화되어 있는 경우 Samba가 --with-acl-support
옵션으로 컴파일되었기 때문에 ACL이 인식됩니다. Samba 공유에 액세스하거나 마운트할 때는 특별한 플래그가 필요하지 않습니다.
5.1.1. NFS
기본적으로 NFS 서버에서 내보내는 파일 시스템이 ACL을 지원하고 NFS 클라이언트가 ACL을 읽을 수 있는 경우 클라이언트 시스템에서 ACL을 사용합니다.
서버를 구성할 때 NFS 공유에서 ACL을 비활성화하려면 /etc/exports
파일에 no_acl
옵션을 포함합니다. 클라이언트에 마운트할 때 NFS 공유에서 ACL을 비활성화하려면 명령줄 또는 /etc/fstab
파일을 통해 no_acl
옵션으로 마운트합니다.
5.2. 액세스 ACL 설정
ACL에는 액세스 ACL과 기본 ACL 의 두 가지 유형이 있습니다. 액세스 ACL은 특정 파일 또는 디렉터리의 액세스 제어 목록입니다. 기본 ACL은 디렉터리와만 연결할 수 있습니다. 디렉터리 내의 파일에 액세스 ACL이 없는 경우 디렉터리에 대한 기본 ACL의 규칙을 사용합니다. 기본 ACL은 선택 사항입니다.
ACL을 구성할 수 있습니다.
- 사용자당
- 그룹당
- 효과적인 권한 마스크를 통해
- 파일의 사용자 그룹에 없는 사용자의 경우
setfacl
유틸리티는 파일 및 디렉터리에 대한 ACL을 설정합니다. m 옵션을 사용하여 파일 또는 디렉터리의 ACL을 추가하거나 수정합니다.
# setfacl -m rules files
규칙(규칙)은 다음 형식으로 지정해야 합니다. 동일한 명령에서 쉼표로 구분된 경우 여러 규칙을 지정할 수 있습니다.
u:uid:perms
- 사용자의 액세스 ACL을 설정합니다. 사용자 이름 또는 UID를 지정할 수 있습니다. 사용자는 시스템에서 유효한 사용자일 수 있습니다.
g:gid:perms
- 그룹에 대한 액세스 ACL을 설정합니다. 그룹 이름 또는 GID를 지정할 수 있습니다. 그룹은 시스템에서 유효한 그룹일 수 있습니다.
m:perms
- 효과적인 권한 마스크를 설정합니다. 마스크는 소유 그룹의 모든 권한과 모든 사용자 및 그룹 항목을 통합합니다.
o:perms
- 파일에 대해 그룹에 있는 그룹 이외의 사용자에 대해 액세스 ACL을 설정합니다.
권한(ms)은 읽기, 쓰기, 실행의 경우 r
,w
, x
의 조합이어야 합니다.
파일 또는 디렉터리에 이미 ACL이 있고 setfacl
명령이 사용되는 경우 기존 ACL에 추가 규칙이 추가되거나 기존 규칙이 수정됩니다.
예 5.1. 읽기 및 쓰기 권한 제공
예를 들어 사용자 및rius에 읽기 및 쓰기 권한을 제공하려면 다음을 수행합니다.
# setfacl -m u:andrius:rw /project/somefile
사용자, 그룹 또는 기타 기타에 대한 모든 권한을 제거하려면 -x
옵션을 사용하고 권한을 지정하지 마십시오.
# setfacl -x rules files
예 5.2. 모든 권한 제거
예를 들어 UID가 500인 사용자의 모든 권한을 제거하려면 다음을 실행합니다.
# setfacl -x u:500 /project/somefile
5.3. 기본 ACL 설정
기본 ACL을 설정하려면 규칙 앞에 d:
를 추가하고 파일 이름 대신 디렉터리를 지정합니다.
예 5.3. 기본 ACL 설정
예를 들어 /share/
디렉터리의 기본 ACL을 사용자 그룹이 아닌 사용자에 대해 읽고 실행되도록 설정하려면 개별 파일의 액세스 ACL은 재정의할 수 있습니다.
# setfacl -m d:o:rx /share
5.4. ACL 검색
파일 또는 디렉토리에 대한 기존 ACL을 확인하려면 getfacl
명령을 사용합니다. 아래 예제에서 getfacl
은 파일의 기존 ACL을 결정하는 데 사용됩니다.
예 5.4. ACL 검색
# getfacl home/john/picture.png
위의 명령은 다음 출력을 반환합니다.
# file: home/john/picture.png # owner: john # group: john user::rw- group::r-- other::r--
기본 ACL이 있는 디렉터리가 지정된 경우 다음과 같이 기본 ACL도 표시됩니다. 예를 들어, getfacl home/ sales/
는 유사한 출력을 표시합니다.
# file: home/sales/ # owner: john # group: john user::rw- user:barryg:r-- group::r-- mask::r-- other::r-- default:user::rwx default:user:john:rwx default:group::r-x default:mask::rwx default:other::r-x
5.5. ACL을 사용하여 파일 시스템 아카이브
기본적으로 dump
명령은 백업 작업 중에 ACL을 보존합니다. tar
로 파일 또는 파일 시스템을 보관하는 경우 --acls
옵션을 사용하여 ACL을 보존합니다. 마찬가지로 cp
를 사용하여 ACL이 포함된 파일을 복사할 때 --preserve=mode
옵션을 포함하여 ACL도 복사됩니다. 또한 cp
의 -a
옵션( -dR --preserve=all
)은 타임스탬프, SELinux 컨텍스트 등과 같은 기타 정보와 함께 백업 중에 ACL도 유지합니다. 덤프
,tar
또는 cp
에 대한 자세한 내용은 해당 도움말
페이지를 참조하십시오.
star
유틸리티는 파일의 아카이브를 생성하는 데 사용할 수 있다는 점에서 tar
유틸리티와 유사하지만 일부 옵션은 다릅니다. 보다 일반적으로 사용되는 옵션 목록은 표 5.1. “별표
를 위한 명령줄 옵션” 을 참조하십시오. 사용 가능한 모든 옵션에 대해서는 man star
를 참조하십시오. 이 유틸리티를 사용하려면 star
패키지가 필요합니다.
옵션 | 설명 |
---|---|
| 아카이브 파일을 생성합니다. |
|
파일을 추출하지 마십시오. |
| 아카이브의 파일을 대체합니다. 파일은 아카이브 파일의 끝에 작성되어 모든 파일을 동일한 경로와 파일 이름으로 바꿉니다. |
| 아카이브 파일의 내용을 표시합니다. |
| 아카이브 파일을 업데이트합니다. 아카이브가 없는 경우 또는 파일이 아카이브에서 동일한 이름의 파일보다 최신인 경우 아카이브의 끝에 파일이 작성됩니다. 이 옵션은 아카이브가 파일이거나 백페이스일 수 있는 차단되지 않은 테이프인 경우에만 작동합니다. |
|
아카이브에서 파일을 추출합니다. 아카이브의 |
| 가장 중요한 옵션을 표시합니다. |
| 가장 중요한 옵션을 표시합니다. |
| 아카이브에서 파일을 추출할 때 파일 이름에서 슬래시를 스트라이핑하지 마십시오. 기본적으로 파일을 추출할 때 제거됩니다. |
| 생성 또는 추출 시 파일 및 디렉터리와 관련된 모든 ACL을 아카이브하거나 복원합니다. |
5.6. 이전 시스템과의 호환성
지정된 파일 시스템의 모든 파일에 ACL이 설정된 경우 해당 파일 시스템에는 ext_attr
속성이 있습니다. 이 속성은 다음 명령을 사용하여 확인할 수 있습니다.
# tune2fs -l filesystem-device
ext_attr
특성을 획득한 파일 시스템은 이전 커널과 함께 마운트할 수 있지만, 이러한 커널은 설정된 ACL을 적용하지 않습니다.
e2fsck
유틸리티 버전 1.22 이상 e2fsprogs
패키지 (Red Hat Enterprise Linux 2.1 및 4의 버전 포함)는 ext_attr
특성을 사용하여 파일 시스템을 확인할 수 있습니다. 이전 버전은 확인을 거부합니다.
5.7. ACL 참조
자세한 내용은 다음 도움말 페이지를 참조하십시오.
-
man acl
- ACL에 대한 설명 -
man getfacl
- 파일 액세스 제어 목록을 얻는 방법에 대해 설명합니다. -
man setfacl
- 파일 액세스 제어 목록을 설정하는 방법 설명 -
man star
-star
유틸리티 및 해당 많은 옵션에 대해 더 알아보기
6장. 권한 확보
시스템 관리자 및 경우에 따라 관리 권한으로 특정 작업을 수행해야 합니다. root
사용자로 시스템에 액세스하는 것은 잠재적으로 위험하며 시스템과 데이터를 광범위하게 손상시킬 수 있습니다. 이 장에서는 su
및 sudo
와 같은 setuid
프로그램을 사용하여 관리 권한을 얻는 방법에 대해 설명합니다. 이러한 프로그램을 통해 특정 사용자는 높은 수준의 제어 및 시스템 보안을 유지하면서 일반적으로 root
사용자만 사용할 수 있는 작업을 수행할 수 있습니다.
관리 제어, 잠재적인 위험 및 권한있는 액세스의 부적절한 사용으로 인한 데이터 손실을 방지하는 방법에 대한 자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드 를 참조하십시오.
6.1. su utility를 사용하여 관리 액세스 구성
사용자가 su
명령을 실행하면 루트
암호를 입력하라는 메시지가 표시되고 인증 후에 루트
쉘 프롬프트가 표시됩니다.
su
명령을 사용하여 로그인하면 사용자는 root
사용자 이며 시스템에 대한 절대 관리 액세스 권한이 있습니다. 이 액세스에는 SELinux가 활성화된 경우 적용되는 제한 사항이 계속 적용됩니다. 또한 사용자가 root
가 되면 su
명령을 사용하여 암호를 입력하라는 메시지가 표시되지 않고 시스템의 다른 사용자로 변경할 수 있습니다.
이 프로그램은 매우 강력하기 때문에 조직 내 관리자는 명령에 대한 액세스 권한이 있는 사람을 제한해야 할 수 있습니다.
이 작업을 수행하는 가장 간단한 방법 중 하나는 wheel 이라는 특수 관리 그룹에 사용자를 추가하는 것입니다. 이렇게 하려면 root
로 다음 명령을 입력합니다.
~]# usermod -a -G wheel username
이전 명령에서 사용자 이름을 wheel
그룹에 추가하려는 사용자 이름으로 교체합니다.
사용자 설정 툴을 사용하여 다음과 같이 그룹 멤버십을 수정할 수도 있습니다. 이 절차를 수행하려면 관리자 권한이 필요합니다.
-
Super 키를 눌러 활동 개요를 입력하고
사용자를
입력한 다음 Enter 를 누릅니다. 사용자 설정 도구가 나타납니다. Super 키는 키보드와 기타 하드웨어에 따라 다양한 길잡이에 표시되지만 일반적으로 스페이스바 왼쪽에 있는 Windows 또는 Command 키로 나타납니다. - 변경을 활성화하려면 버튼을 클릭하고 유효한 관리자 암호를 입력합니다.
- 왼쪽 열에서 사용자 아이콘을 클릭하여 오른쪽 창에 사용자의 속성을 표시합니다.
-
계정 유형을
Standard
에서Administrator
로 변경합니다. 이렇게 하면 사용자를wheel
그룹에 추가합니다.
사용자 도구에 대한 자세한 내용은 4.2절. “그래픽 환경에서 사용자 관리” 을 참조하십시오.
원하는 사용자를 wheel
그룹에 추가한 후 이러한 특정 사용자만 su
명령을 사용하도록 허용하는 것이 좋습니다. 이렇게 하려면 su
,/etc/pam.d/su
에 대한 Pluggable Authentication Module (PAM) 구성 파일을 편집합니다. 텍스트 편집기에서 이 파일을 열고 #
문자를 제거하여 다음 행의 주석을 제거합니다.
#auth required pam_wheel.so use_uid
이 변경으로 인해 관리 그룹 where의 멤버만 su
명령을 사용하여 다른 사용자로 전환할 수 있습니다.
6.2. sudo utility를 사용하여 관리 액세스 구성
sudo
명령은 사용자에게 관리 액세스 권한을 부여하는 다른 방법을 제공합니다. 신뢰할 수 있는 사용자가 관리자 명령 앞에 sudo
를 입력하면 자신의 암호를 입력하라는 메시지가 표시됩니다. 그런 다음 인증되고 명령이 허용된다고 가정하면 root
사용자인 것처럼 관리 명령이 실행됩니다.
sudo
명령의 기본 형식은 다음과 같습니다.
sudo
command
위의 예에서 명령은 일반적으로 root
사용자(예: mount
)에 예약된 명령으로 교체됩니다.
sudo
명령을 사용하면 높은 수준의 유연성을 제공합니다. 예를 들어 /etc/sudoers
구성 파일에 나열된 사용자만 sudo
명령을 사용할 수 있으며 루트
쉘이 아닌 사용자 쉘에서 명령이 실행됩니다. 즉, Red Hat Enterprise Linux 7 보안 가이드에 표시된 대로 루트
쉘을 완전히 비활성화할 수 있습니다.
sudo
명령을 사용하여 인증에 성공하면 /var/log/
message 파일에 기록되고 발행자의 사용자 이름과 함께 실행된 명령은 /var/log/secure
파일에 기록됩니다. 추가 로깅이 필요한 경우, /etc/pam.d/system-auth
파일에 다음 행을 추가하여 지정된 사용자에 대해 TTY 감사를 활성화하려면 pam_tty_audit
모듈을 사용합니다.
session required pam_tty_audit.so disable=pattern enable=pattern
여기서 패턴은 glob를 선택적 용도로 사용하는 사용자의 쉼표로 구분된 목록을 나타냅니다. 예를 들어 다음 구성은 root
사용자에 대해 TTY 감사를 활성화하고 다른 모든 사용자에 대해 비활성화합니다.
session required pam_tty_audit.so disable=* enable=root
TTY 감사 레코드에 대한 pam_tty_audit
PAM 모듈을 TTY 입력만 구성합니다. 즉, 감사된 사용자가 로그인할 때 interval _tty_audit
는 사용자가 /var/log/audit/audit.log
파일에 만드는 정확한 키 입력을 기록합니다. 자세한 내용은 pam_tty_audit(8) 매뉴얼 페이지를 참조하십시오.
sudo
명령의 또 다른 장점은 관리자가 필요에 따라 특정 명령에 다른 사용자가 액세스할 수 있다는 점입니다.
sudo
구성 파일 /etc/sudoers
를 편집하려는 관리자는 visudo
명령을 사용해야 합니다.
사용자에게 전체 관리 권한을 제공하려면 visudo
를 입력하고 사용자 권한 사양 섹션에서 다음과 유사한 행을 추가합니다.
juan ALL=(ALL) ALL
이 예에서는 사용자(Subjan ) 가
모든 호스트에서 sudo
를 사용하고 모든 명령을 실행할 수 있다고 명시되어 있습니다.
아래 예제에서는 sudo
를 설정할 때 가능한 세분성을 보여줍니다.
%users localhost=/usr/sbin/shutdown -h now
이 예에서는 사용자
시스템 그룹의 모든 멤버가 콘솔에서 발행되는 한 이제 /sbin/shutdown -h
명령을 실행할 수 있다고 명시되어 있습니다.
sudoers
의 man 페이지에는 이 파일에 대한 자세한 옵션 목록이 있습니다.
/etc/sudoers
파일에서 NO
tekton 옵션을 사용하여 암호를 제공하지 않아도 되는 sudo 사용자를 구성할 수도 있습니다.
user_name ALL=(ALL) NOPASSWD: ALL
그러나 이러한 사용자에게도 sudo
는 PAM 모듈에 의해 설정된 제한을 인증 단계 외부에서 확인할 수 있는PAM(Plugable Authentication Module) 계정 관리 모듈을 실행합니다. 이렇게 하면 PAM 모듈이 올바르게 작동합니다. 예를 들어, pam_time
모듈의 경우 시간 기반 계정 제한이 실패하지 않습니다.
항상 모든 PAM 기반 액세스 제어 규칙의 허용된 서비스 목록에 sudo
를 포함합니다. 그렇지 않으면 sudo
에 액세스하려고 할 때 "permission denied" 오류 메시지가 표시되지만 현재 액세스 제어 규칙에 따라 액세스가 금지됩니다.
자세한 내용은 Red Hat Knowledgebase 문서 Red Hat Enterprise Linux 7.6에 패치된 후 sudo에서 권한 거부 오류를 제공합니다.
sudo
명령을 사용할 때 고려해야 할 몇 가지 위험이 있습니다. 위에서 설명한 대로 visudo
를 사용하여 /etc/sudoers
구성 파일을 편집하여 방지할 수 있습니다. /etc/sudoers
파일을 기본 상태로 유지하면 wheel
그룹의 모든 사용자에게 무제한 루트
액세스 권한이 부여됩니다.
기본적으로
sudo
는 5분 제한 기간 동안 암호를 저장합니다. 이 기간 동안 명령을 나중에 사용하면 사용자에게 암호를 입력하라는 메시지가 표시되지 않습니다. 이 취약점은 사용자가 워크스테이션이 아직 로그인되어 있는 동안 워크스테이션을 자동으로 잠금 해제하고 잠금 해제하는 경우 공격자가 악용될 수 있습니다. 이 동작은/etc/sudoers
파일에 다음 행을 추가하여 변경할 수 있습니다.Defaults timestamp_timeout=value
여기서 value 는 원하는 시간 제한 길이(분)입니다. 값을 0으로 설정하면
sudo
에서 암호를 매번 필요로 합니다.계정이 손상된 경우 공격자는
sudo
를 사용하여 관리자 권한으로 새 쉘을 열 수 있습니다.sudo /bin/bash
이 또는 유사한 방식으로
root
로 새 쉘을 열면 공격자가 이론적으로 무제한으로 제한된 시간 동안 관리 액세스 권한을 부여하고/etc/sudoers
파일에 지정된 제한 시간을 무시하고 공격자가 새로 열린 세션이 종료될 때까지sudo
에 대한 암호를 다시 입력하지 않아도 됩니다.
6.3. 추가 리소스
사용자가 관리 권한을 얻을 수 있는 프로그램은 잠재적인 보안 위험이지만 보안 자체는 이 특정 책의 범위를 벗어납니다. 따라서 보안 및 권한 있는 액세스에 대한 자세한 내용은 아래 나열된 리소스를 참조해야 합니다.
설치된 문서
-
Su (1) -
su
의 도움말 페이지는 이 명령으로 사용 가능한 옵션에 대한 정보를 제공합니다. -
sudo
(8) -sudo
의 도움말 페이지에는 이 명령에 대한 자세한 설명과 해당 동작을 사용자 정의할 수 있는 옵션이 나열됩니다. -
PAM
(8) - Linux용 Pluggable Authentication Modules (PAM) 사용을 설명하는 수동 페이지.
온라인 문서
-
Red Hat Enterprise Linux 7 보안 가이드 - Red Hat Enterprise Linux 7의 보안 가이드에서는
setuid
프로그램과 관련된 잠재적인 보안 문제와 이러한 위험을 완화하는 데 사용되는 기술을 자세히 설명합니다.
예를 들면 다음과 같습니다.
- 4장. 사용자 및 그룹 관리 그래픽 사용자 인터페이스 및 명령줄에서 시스템 사용자 및 그룹을 관리하는 방법을 설명합니다.
II 부. 서브스크립션 및 지원
Red Hat Enterprise Linux 시스템에서 소프트웨어 업데이트를 받으려면 Red HatCDN( Content Delivery Network ) 및 적절한 리포지토리를 활성화해야 합니다. 이 부분에서는 시스템을 Red Hat Content Delivery Network에 등록하는 방법을 설명합니다.
Red Hat은 고객 포털 을 통해 지원을 제공하며 Red Hat 지원 도구를 사용하여 명령줄에서 직접 이 지원에 액세스할 수 있습니다. 이 부분에서는 이 명령줄 툴의 사용에 대해 설명합니다.
7장. 시스템 등록 및 서브스크립션 관리
서브스크립션 서비스는 Red Hat 소프트웨어 인벤토리를 처리하는 메커니즘을 제공하며 yum 패키지 관리자를 사용하여 이미 설치된 프로그램을 최신 버전에 추가로 설치할 수 있습니다. Red Hat Enterprise Linux 7에서 시스템을 등록하고 서브스크립션을 첨부하는 것이 Red Hat 서브스크립션 관리를 사용하는 것이 좋습니다.
7.1. 시스템 및 연결 서브스크립션 등록
시스템을 등록하고 Red Hat 서브스크립션 관리를 사용하여 서브스크립션을 하나 이상 연결하려면 다음 단계를 완료합니다. 모든 subscription-manager
명령은 root
로 실행되어야 합니다.
다음 명령을 실행하여 시스템을 등록합니다. 사용자 이름과 암호를 입력하라는 메시지가 표시됩니다. 사용자 이름과 암호는 Red Hat Customer Portal의 로그인 자격 증명과 동일합니다.
subscription-manager register
필요한 서브스크립션의 풀 ID를 확인합니다. 이렇게 하려면 쉘 프롬프트에서 다음을 입력하여 시스템에 사용 가능한 모든 서브스크립션 목록을 표시합니다.
subscription-manager list --available
사용 가능한 서브스크립션마다 이 명령은 서브스크립션과 관련된 이름, 고유 식별자, 만료일 및 기타 세부 정보를 표시합니다. 모든 아키텍처의 서브스크립션을 나열하려면
--all
옵션을 추가합니다. 풀 ID는풀 ID
로 시작하는 줄에 나열됩니다.다음과 같이 명령을 입력하여 시스템에 적절한 서브스크립션을 연결합니다.
subscription-manager attach --pool=pool_id
pool_id 를 이전 단계에서 결정한 풀 ID로 교체합니다.
언제든지 시스템이 현재 연결된 서브스크립션 목록을 확인하려면 다음을 실행합니다.
subscription-manager list --consumed
Red Hat Subscription Management를 사용하여 시스템을 등록하고 서브스크립션과 연결하는 방법에 대한 자세한 내용은 지정된 솔루션 문서를 참조하십시오. 서브스크립션에 대한 자세한 내용은 Red Hat Subscription Management 가이드 컬렉션을 참조하십시오.
7.2. 소프트웨어 리포지토리 관리
Red Hat Content Delivery Network를 시스템이 서브스크립션하면 /etc/yum.repos.d/
디렉토리에 리포지토리 파일이 생성됩니다. 이를 확인하려면 yum 을 사용하여 활성화된 모든 리포지토리를 나열합니다.
yum repolist
Red Hat 서브스크립션 관리를 사용하면 Red Hat에서 제공하는 소프트웨어 리포지토리를 수동으로 활성화 또는 비활성화할 수 있습니다. 사용 가능한 리포지토리를 모두 나열하려면 다음 명령을 사용하십시오.
subscription-manager repos --list
리포지토리 이름은 사용 중인 특정 Red Hat Enterprise Linux 버전에 따라 다르며 형식은 다음과 같습니다.
rhel-version-variant-rpms rhel-version-variant-debug-rpms rhel-version-variant-source-rpms
여기서 버전은 Red Hat Enterprise Linux 시스템 버전(6
또는 7
)이며, 변형 은 Red Hat Enterprise Linux 시스템 변형(서버
또는 워크스테이션
)입니다. 예를 들면 다음과 같습니다.
rhel-7-server-rpms rhel-7-server-debug-rpms rhel-7-server-source-rpms
리포지토리를 활성화하려면 다음과 같이 명령을 입력합니다.
subscription-manager repos --enable repository
리포지토리를 활성화할 리포지토리 이름으로 교체합니다.
마찬가지로 리포지토리를 비활성화하려면 다음 명령을 사용합니다.
subscription-manager repos --disable repository
9.5절. “YUM 및 YUM 리포지토리 구성” yum 을 사용하여 소프트웨어 리포지토리 관리에 대한 자세한 정보를 제공합니다.
리포지토리를 자동으로 업데이트하려면 yum-cron
서비스를 사용할 수 있습니다. 자세한 내용은 9.7절. “YUM-cron을 사용하여 패키지 데이터베이스 자동 새로 고침 및 업데이트 다운로드”의 내용을 참조하십시오.
7.3. 서브스크립션 제거
특정 서브스크립션을 제거하려면 다음 단계를 완료하십시오.
이미 연결된 서브스크립션에 대한 정보를 나열하여 제거할 서브스크립션의 일련 번호를 결정합니다.
subscription-manager list --consumed
일련 번호는
serial
으로 나열된 번호입니다. 예를 들어 아래 예제에서744993814251016831
은 다음과 같습니다.SKU: ES0113909 Contract: 01234567 Account: 1234567 Serial: 744993814251016831 Pool ID: 8a85f9894bba16dc014bccdd905a5e23 Active: False Quantity Used: 1 Service Level: SELF-SUPPORT Service Type: L1-L3 Status Details: Subscription Type: Standard Starts: 02/27/2015 Ends: 02/27/2016 System Type: Virtual
다음과 같이 명령을 입력하여 선택한 서브스크립션을 제거합니다.
subscription-manager remove --serial=serial_number
serial_number 를 이전 단계에서 결정한 일련 번호로 바꿉니다.
시스템에 연결된 모든 서브스크립션을 제거하려면 다음 명령을 실행합니다.
subscription-manager remove --all
7.4. 추가 리소스
Red Hat Subscription Management를 사용하여 시스템을 등록하고 서브스크립션과 연결하는 방법에 대한 자세한 내용은 아래 나열된 리소스를 참조하십시오.
설치된 문서
-
subscription-manager
(8) - Red Hat 서브스크립션 관리에 대한 도움말 페이지는 지원되는 옵션 및 명령의 전체 목록을 제공합니다.
관련 도서
- Red Hat Subscription Management 가이드 수집 - 이 안내서에는 Red Hat 서브스크립션 관리 사용 방법에 대한 자세한 정보가 포함되어 있습니다.
- 설치 가이드 - 초기 설정 프로세스 중에 등록하는 방법에 대한 자세한 내용은 초기 설정 장을 참조하십시오.
예를 들면 다음과 같습니다.
8장. Red Hat 지원 도구를 사용하여 지원에 액세스
redhat-support-tool 패키지의 Red Hat 지원 툴 은 대화형 쉘과 단일 실행 프로그램으로 기능할 수 있습니다. SSH
를 통해 실행하거나 모든 터미널에서 실행할 수 있습니다. 예를 들어 명령줄에서 Red Hat 지식 베이스를 검색하고 명령줄에 직접 솔루션을 복사하고, 지원 케이스를 열고 업데이트하고, 분석을 위해 Red Hat으로 파일을 전송할 수 있습니다.
8.1. Red Hat 지원 도구 설치
Red Hat 지원 도구는 기본적으로 Red Hat Enterprise Linux에 설치됩니다. 필요한 경우 root
로 다음 명령을 입력합니다.
~]# yum install redhat-support-tool
8.2. 명령줄을 사용하여 Red Hat 지원 도구 등록
명령줄을 사용하여 Red Hat 지원 도구를 고객 포털에 등록하려면 다음 명령을 실행합니다.
~]# redhat-support-tool config user username
여기서 username 은 Red Hat 고객 포털 계정의 사용자 이름입니다.
~]# redhat-support-tool config password
Please enter the password for username:
8.3. Interactive Shell 모드에서 Red Hat 지원 도구 사용
대화형 모드에서 도구를 시작하려면 다음 명령을 입력합니다.
~]$ redhat-support-tool
Welcome to the Red Hat Support Tool.
Command (? for help):
툴은 권한이 없는 사용자로 실행되어 결과적으로 명령 세트를 줄이거나 root
로 실행할 수 있습니다.
?
문자를 입력하여 명령을 나열할 수 있습니다. q
또는 e
문자를 입력하여 프로그램 또는 메뉴 선택을 종료할 수 있습니다. 지식 베이스 또는 지원 케이스를 처음 검색할 때 Red Hat Customer Portal 사용자 이름과 암호를 입력하라는 메시지가 표시됩니다. 또는 대화형 모드를 사용하여 Red Hat Customer Portal 계정의 사용자 이름과 암호를 설정하고 선택적으로 구성 파일에 저장합니다.
8.4. Red Hat 지원 도구 구성
대화형 모드에서는 config --help
명령을 입력하여 구성 옵션을 나열할 수 있습니다.
~]# redhat-support-tool Welcome to the Red Hat Support Tool. Command (? for help): config --help Usage: config [options] config.option <new option value> Use the 'config' command to set or get configuration file values. Options: -h, --help show this help message and exit -g, --global Save configuration option in /etc/redhat-support-tool.conf. -u, --unset Unset configuration option. The configuration file options which can be set are: user : The Red Hat Customer Portal user. password : The Red Hat Customer Portal password. debug : CRITICAL, ERROR, WARNING, INFO, or DEBUG url : The support services URL. Default=https://api.access.redhat.com proxy_url : A proxy server URL. proxy_user: A proxy server user. proxy_password: A password for the proxy server user. ssl_ca : Path to certificate authorities to trust during communication. kern_debug_dir: Path to the directory where kernel debug symbols should be downloaded and cached. Default=/var/lib/redhat-support-tool/debugkernels Examples: - config user - config user my-rhn-username - config --unset user
Interactive 모드를 사용하여 Red Hat 지원 도구 등록
대화형 모드를 사용하여 Red Hat 지원 도구를 고객 포털에 등록하려면 다음과 같이 진행하십시오.
다음 명령을 입력하여 툴을 시작합니다.
~]# redhat-support-tool
Red Hat Customer Portal 사용자 이름을 입력합니다.
Command (? for help):
config user username
사용자 이름을 글로벌 구성 파일에 저장하려면
-g
옵션을 추가합니다.Red Hat 고객 포털 암호를 입력합니다.
Command (? for help):
config password
Please enter the password for username:
8.4.1. 설정 파일에 설정 저장
달리 지시하지 않는 한 Red Hat 지원 도구는 ~/.redhat-support-tool/redhat-support-tool.conf
구성 파일을 사용하여 현재 사용자의 홈 디렉터리에 값 및 옵션을 로컬에 저장합니다. 필요한 경우 특정 사용자만 읽을 수 있으므로 이 파일에 암호를 저장하는 것이 좋습니다. 도구가 시작되면 글로벌 구성 파일 /etc/redhat-support-tool.conf
및 로컬 구성 파일에서 값을 읽습니다. 로컬에 저장된 값 및 옵션은 전역에 저장된 설정보다 우선합니다.
암호가 base64
로 인코딩되고 쉽게 디코딩될 수 있기 때문에 글로벌 /etc/redhat-support-tool.conf
구성 파일에 암호를 저장하지 않는 것이 좋습니다. 또한 이 파일은 쉽게 읽을 수 있습니다.
전역 구성 파일에 값 또는 옵션을 저장하려면 다음과 같이 -g, --global
옵션을 추가합니다.
Command (? for help): config setting -g value
-g, --global
옵션을 사용하여 설정을 전역적으로 저장하려면 일반 사용자가 /etc/redhat-support-tool.conf
에 쓰는 데 필요한 권한이 없으므로 Red Hat 지원 도구를 루트로
실행해야 합니다.
로컬 구성 파일에서 값 또는 옵션을 제거하려면 다음과 같이 -u, --unset
옵션을 추가합니다.
Command (? for help): config setting -u value
이렇게 하면 사용 가능한 경우 도구에서 매개 변수를 지우고 설정 해제하고 글로벌 구성 파일에서 동등한 설정으로 돌아갑니다.
권한이 없는 사용자로 실행하는 경우 -u, --unset 옵션에 저장된 값은 -u, --unset
옵션을 사용하여 제거할 수 없지만 -g, --global
옵션과 동시에 -u, --unset
옵션을 사용하여 툴의 현재 실행 중인 인스턴스에서 선택을 해제할 수 있습니다. 루트
로 실행하는 경우 -g, --global
를 -u, --unset
옵션과 동시에 사용하여 전역 구성 파일에서 값 및 옵션을 제거할 수 있습니다.
8.5. Interactive 모드를 사용하여 지원 케이스 열기 및 업데이트
Interactive 모드를 사용하여 새 지원 케이스 열기
대화형 모드를 사용하여 새 지원 케이스를 시작하려면 다음과 같이 진행하십시오.
다음 명령을 입력하여 툴을 시작합니다.
~]# redhat-support-tool
opencase
명령을 입력합니다.Command (? for help):
opencase
- 화면에 표시되는 메시지에 따라 제품을 선택한 다음 버전을 선택합니다.
- 케이스 요약을 입력합니다.
- 케이스에 대한 설명을 입력하고 완료되면 빈 행에서 Ctrl+D 를 누릅니다.
- 케이스의 심각도를 선택합니다.
- 필요한 경우 지원 케이스를 열기 전에 이 문제에 대한 해결 방법이 있는지 확인하기로 결정했습니다.
지원 케이스를 계속 열고 있는지 확인합니다.
Support case 0123456789 has successfully been opened
- 선택적으로 SOS 보고서를 첨부하도록 선택합니다.
- 선택적으로 파일을 첨부하도록 선택합니다.
Interactive 모드를 사용하여 기존 지원 케이스 보기 및 업데이트
대화형 모드를 사용하여 기존 지원 케이스를 보고 업데이트하려면 다음과 같이 진행하십시오.
다음 명령을 입력하여 툴을 시작합니다.
~]# redhat-support-tool
getcase
명령을 입력합니다.Command (? for help):
getcase case-number
여기서 case-number 는 보고 업데이트하려는 케이스의 수입니다.
- 화면의 지침에 따라 케이스를 보거나, 주석을 수정하거나 추가하고, 첨부 파일을 가져오거나 추가합니다.
Interactive 모드를 사용하여 기존 지원 케이스 수정
대화형 모드를 사용하여 기존 지원 케이스의 속성을 수정하려면 다음과 같이 진행하십시오.
다음 명령을 입력하여 툴을 시작합니다.
~]# redhat-support-tool
수정 케이스
명령을 입력합니다.Command (? for help):
modifycase case-number
여기서 case-number 는 보고 업데이트하려는 케이스의 수입니다.
수정 선택 목록이 나타납니다.
Type the number of the attribute to modify or 'e' to return to the previous menu. 1 Modify Type 2 Modify Severity 3 Modify Status 4 Modify Alternative-ID 5 Modify Product 6 Modify Version End of options.
화면의 메시지에 따라 하나 이상의 옵션을 수정합니다.
예를 들어 상태를 수정하려면
3
을 입력합니다.Selection: 3 1 Waiting on Customer 2 Waiting on Red Hat 3 Closed Please select a status (or 'q' to exit):
8.6. 명령줄에서 기술 지원 케이스 보기
명령줄에서 케이스 내용을 보면 명령줄에서 솔루션을 빠르고 쉽게 적용할 수 있습니다.
명령줄에서 기존 지원 케이스를 보려면 다음과 같이 명령을 입력합니다.
~]# redhat-support-tool getcase case-number
여기서 case-number 는 다운로드하려는 케이스의 수입니다.
8.7. 추가 리소스
Red Hat 지식베이스 문서 Red Hat 지원 도구에는 추가 정보, 예제 및 비디오 튜토리얼이 있습니다.
III 부. 소프트웨어 설치 및 관리
Red Hat Enterprise Linux 시스템의 모든 소프트웨어는 RPM 패키지로 구분되어 설치, 업그레이드 또는 제거할 수 있습니다. 이 부분에서는 YUM 을 사용하여 Red Hat Enterprise Linux에서 패키지를 관리하는 방법을 설명합니다.
9장. yum
yum 은 사용 가능한 패키지에 대한 정보를 쿼리하고, 리포지토리에서 패키지를 가져와 설치 및 제거한 다음 전체 시스템을 사용 가능한 최신 버전으로 업데이트할 수 있는 Red Hat 패키지 관리자입니다. yum은 패키지를 업데이트, 설치 또는 제거할 때 자동 종속성 확인을 수행하므로 사용 가능한 모든 종속 패키지를 자동으로 확인, 가져오기 및 설치할 수 있습니다.
yum은 새로운 추가 리포지토리 또는 패키지 소스를 사용하여 구성할 수 있으며 기능을 강화하고 확장하는 많은 플러그인도 제공합니다. yum은 RPM 과 동일한 많은 작업을 수행할 수 있습니다. 또한 많은 명령줄 옵션이 비슷합니다. yum은 단일 시스템 또는 그 그룹의 그룹에서 쉽고 간단한 패키지 관리를 활성화합니다.
다음 섹션에서는 Red Hat Enterprise Linux 7 설치 가이드에 설명된 대로 설치 중에 시스템이 Red Hat 서브스크립션 관리에 등록되어 있다고 가정합니다. 시스템이 서브스크립션되지 않은 경우 7장. 시스템 등록 및 서브스크립션 관리 를 참조하십시오.
yum은 모든 패키지 리포지토리(패키지 소스) 또는 개별 리포지토리에 대해 GPG(Gnu 개인 정보 보호 가드) 서명 확인 (GnuPG) 서명 확인 기능을 활성화하여 보안 패키지 관리를 제공합니다. 서명 확인이 활성화되면 yum은 해당 리포지토리의 올바른 키로 GPG가 서명되지 않은 패키지 설치를 거부합니다. 즉, 시스템에서 다운로드하고 설치하는 RPM 패키지가 Red Hat과 같은 신뢰할 수 있는 소스에서 가져온다는 것을 신뢰할 수 있으며 전송 중에 수정되지 않았음을 신뢰할 수 있습니다. yum을 사용하여 서명 확인 활성화에 대한 자세한 내용은 9.5절. “YUM 및 YUM 리포지토리 구성” 를 참조하십시오.
또한 yum을 사용하면 다른 시스템에서 다운로드 및 설치를 위해 자체 RPM 패키지 리포지토리를 쉽게 설정할 수 있습니다. 가능한 경우 yum은 여러 패키지 및 메타데이터의 병렬 다운로드를 사용하여 다운로드 속도를 높입니다.
yum을 학습하는 것은 종종 시스템 관리 작업을 수행하는 가장 빠른 방법이며 PackageKit 그래픽 패키지 관리 도구에서 제공하는 기능 외에도 기능을 제공합니다.
yum을 사용하여 시스템에서 패키지를 설치, 업데이트 또는 제거하려면 수퍼유저 권한이 있어야 합니다. 이 장의 모든 예제에서는 su
또는 sudo
명령을 사용하여 이미 수퍼유저 권한을 얻은 것으로 가정합니다.
9.1. 패키지 확인 및 업데이트
yum을 사용하면 시스템에 적용 대기 중인 업데이트가 있는지 확인할 수 있습니다. 업데이트해야 하는 패키지를 나열하고 전체적으로 업데이트하거나 선택한 개별 패키지를 업데이트할 수 있습니다.
9.1.1. 업데이트 확인
사용 가능한 업데이트가 있는 설치된 패키지를 보려면 다음 명령을 사용하십시오.
yum
check-update
예 9.1. yum check-update 명령의 출력 예
yum
check-update
의 출력은 다음과 같습니다.
~]# yum check-update Loaded plugins: product-id, search-disabled-repos, subscription-manager dracut.x86_64 033-360.el7_2 rhel-7-server-rpms dracut-config-rescue.x86_64 033-360.el7_2 rhel-7-server-rpms kernel.x86_64 3.10.0-327.el7 rhel-7-server-rpms rpm.x86_64 4.11.3-17.el7 rhel-7-server-rpms rpm-libs.x86_64 4.11.3-17.el7 rhel-7-server-rpms rpm-python.x86_64 4.11.3-17.el7 rhel-7-server-rpms yum.noarch 3.4.3-132.el7 rhel-7-server-rpms
위의 출력의 패키지는 업데이트를 사용할 수 있는 상태로 나열됩니다. 목록의 첫 번째 패키지는 dracut 입니다. 예제 출력의 각 행은 dracut 의 경우 여러 행으로 구성됩니다.
-
dracut
- 패키지 이름 -
x86_64
- 패키지가용으로 빌드된 CPU 아키텍처 -
033
- 설치할 업데이트된 패키지의 버전입니다. -
360.el7
- 업데이트된 패키지 릴리스 -
_2
- z-stream 업데이트의 일부로 추가된 빌드 버전입니다. -
rhel-7-server-rpms
- 업데이트된 패키지가 있는 리포지토리입니다.
출력은 또한 커널(커널 패키지), yum 및 RPM 자체( yum
및 rpm 패키지) 및 종속 항목(예: rpm-libs, rpm-python 패키지)을 업데이트할 수 있음을 보여줍니다.
9.1.2. 패키지 업데이트
한 번에 하나의 패키지, 여러 패키지 또는 모든 패키지를 업데이트하도록 선택할 수 있습니다. 업데이트하는 패키지 또는 패키지의 종속 항목에 자체적으로 사용 가능한 업데이트가 있는 경우 해당 패키지도 업데이트됩니다.
단일 패키지 업데이트
단일 패키지를 업데이트하려면 root
로 다음 명령을 실행합니다.
yum update package_name
예 9.2. rpm 패키지 업데이트
rpm 패키지를 업데이트하려면 다음을 입력합니다.
~]# yum update rpm Loaded plugins: langpacks, product-id, subscription-manager Updating Red Hat repositories. INFO:rhsm-app.repolib:repos updated: 0 Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package rpm.x86_64 0:4.11.1-3.el7 will be updated --> Processing Dependency: rpm = 4.11.1-3.el7 for package: rpm-libs-4.11.1-3.el7.x86_64 --> Processing Dependency: rpm = 4.11.1-3.el7 for package: rpm-python-4.11.1-3.el7.x86_64 --> Processing Dependency: rpm = 4.11.1-3.el7 for package: rpm-build-4.11.1-3.el7.x86_64 ---> Package rpm.x86_64 0:4.11.2-2.el7 will be an update --> Running transaction check ... --> Finished Dependency Resolution Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: rpm x86_64 4.11.2-2.el7 rhel 1.1 M Updating for dependencies: rpm-build x86_64 4.11.2-2.el7 rhel 139 k rpm-build-libs x86_64 4.11.2-2.el7 rhel 98 k rpm-libs x86_64 4.11.2-2.el7 rhel 261 k rpm-python x86_64 4.11.2-2.el7 rhel 74 k Transaction Summary ============================================================================= Upgrade 1 Package (+4 Dependent packages) Total size: 1.7 M Is this ok [y/d/N]:
이 출력에는 관심 있는 몇 가지 항목이 포함되어 있습니다.
-
로드된 플러그인: langpack, product-id, subscription-manager
- YUM은 항상 설치 및 활성화되는 yum 플러그인을 알려줍니다. 특정 플러그인에 대한 설명은 9.6절. “yum 플러그인” 에서 yum 플러그인에 대한 일반 정보는 9.6.3절. “YUM 플러그인 작업” 을 참조하십시오. -
rpm.x86_64
- 새 rpm 패키지와 해당 종속 항목을 다운로드하여 설치할 수 있습니다. 트랜잭션 검사는 이러한 각 패키지에 대해 수행됩니다. yum은 업데이트 정보를 표시하고 업데이트 확인을 요청하는 메시지를 표시합니다. yum은 기본적으로 대화식으로 실행됩니다.
yum
명령이 수행하려는 트랜잭션을 이미 알고 있는 경우-y
옵션을 사용하여 yum에서 요청하는 질문에yes
로 자동으로 응답할 수 있습니다(대화형이 아닌 경우 실행됨). 그러나 발생할 수 있는 문제를 쉽게 해결할 수 있도록 yum 계획을 시스템에 적용할 변경 사항을 항상 확인해야 합니다. 패키지를 설치하지 않고 다운로드하도록 선택할 수도 있습니다. 이렇게 하려면 다운로드 프롬프트에서d
옵션을 선택합니다. 그러면 선택한 패키지의 백그라운드 다운로드가 시작됩니다.트랜잭션이 실패하면 9.4절. “트랜잭션 내역 작업” 에 설명된 대로
yum history
명령을 사용하여 yum 트랜잭션 기록을 볼 수 있습니다.
yum은 yum update
또는 yum install
명령을 사용 중인지에 관계없이 항상 새 커널을 설치합니다.
RPM 을 사용하는 경우 현재 커널을 대체하는 rpm - u 커널 대신 새 커널을 설치하는
명령을 사용하는 것이 중요합니다.
rpm -i kernel
마찬가지로 패키지 그룹을 업데이트할 수 있습니다. root
로 다음을 입력합니다.
yum group update group_name
여기서 group_name 을 업데이트하려는 패키지 그룹의 이름으로 바꿉니다. 패키지 그룹에 대한 자세한 내용은 9.3절. “패키지 그룹 작업” 을 참조하십시오.
또한 yum은 더 이상 사용되지 않는
구성 옵션을 사용하여 update
와 동일한 업그레이드
명령을 제공합니다( 9.5.1절. “[main] 옵션 설정”참조). 기본적으로 사용되지 않는
것은 /etc/yum.conf
에서 설정되어 이 두 명령을 동일하게 만듭니다.
모든 패키지 업데이트 및 해당 종속 항목 업데이트
모든 패키지 및 종속 항목을 업데이트하려면 인수 없이 yum update
명령을 사용하십시오.
yum update
보안 관련 패키지 업데이트
패키지에 보안 업데이트를 사용할 수 있는 경우 이러한 패키지만 최신 버전으로 업데이트할 수 있습니다. root
로 다음을 입력합니다.
yum update --security
최신 보안 업데이트가 포함된 버전으로만 패키지를 업데이트할 수도 있습니다. root
로 다음을 입력합니다.
yum update-minimal --security
예를 들면 다음과 같습니다.
- kernel-3.10.0-1 패키지가 시스템에 설치되어 있습니다.
- kernel-3.10.0-2 패키지는 보안 업데이트로 릴리스되었습니다.
- kernel-3.10.0-3 패키지는 버그 수정 업데이트로 릴리스되었습니다.
그런 다음 yum update-minimal --security
가 패키지를 kernel-3.10.0-2 로 업데이트하고 yum update --security
는 패키지를 kernel-3.10.0-3 으로 업데이트합니다.
패키지 업데이트 자동화
패키지 데이터베이스를 자동으로 새로 고치고 자동으로 업데이트하려면 yum-cron
서비스를 사용할 수 있습니다. 자세한 내용은 9.7절. “YUM-cron을 사용하여 패키지 데이터베이스 자동 새로 고침 및 업데이트 다운로드”의 내용을 참조하십시오.
9.1.3. ISO 및 YUM을 사용하여 시스템 오프 라인 업그레이드
인터넷 또는 Red Hat Network에서 연결이 끊긴 시스템의 경우 Red Hat Enterprise Linux 설치 ISO 이미지와 함께 yum update
명령을 사용하면 시스템을 최신 마이너 버전으로 빠르게 업그레이드할 수 있습니다. 다음 단계는 업그레이드 프로세스를 보여줍니다.
ISO 이미지를 마운트할 대상 디렉터리를 생성합니다. 이 디렉터리는 마운트 시 자동으로 생성되지 않으므로 다음 단계를 진행하기 전에 생성합니다.
루트
로서 다음을 입력합니다.mkdir mount_dir
mount_dir 을 마운트 디렉터리의 경로로 바꿉니다. 일반적으로 사용자는
/media
디렉터리에 하위 디렉터리를 생성합니다.Red Hat Enterprise Linux 7 설치 ISO 이미지를 이전에 생성한 대상 디렉터리에 마운트합니다.
루트
로서 다음을 입력합니다.mount -o loop iso_name mount_dir
iso_name 을 ISO 이미지의 경로로 바꾸고 mount_dir 을 대상 디렉터리의 경로로 바꿉니다. 여기서는 파일을 블록 장치로 마운트하려면
-o
loop
옵션이 필요합니다.마운트 디렉토리에서
media.repo
파일을/etc/yum.repos.d/
디렉토리에 복사합니다. 이 디렉터리의 설정 파일에는 제대로 작동하려면 .repo 확장자가 있어야 합니다.cp
mount_dir/media.repo
/etc/yum.repos.d/new.repo
이렇게 하면 yum 리포지토리의 구성 파일이 생성됩니다. new.repo 를 파일 이름으로 교체합니다(예: rhel7.repo ).
Red Hat Enterprise Linux 설치 ISO를 가리키도록 새 구성 파일을 편집합니다.
/etc/yum.repos.d/new.repo파일에 다음 행을 추가합니다.
baseurl=file:///mount_dir
mount_dir 을 마운트 지점의 경로로 바꿉니다.
이전 단계에서 만든
/etc/yum.repos.d/new.repo
를 포함한 모든 yum 리포지토리를 업데이트합니다.루트
로서 다음을 입력합니다.yum
update
이렇게 하면 마운트된 ISO 이미지에서 제공하는 버전으로 시스템이 업그레이드됩니다.
성공적으로 업그레이드되면 ISO 이미지를 마운트 해제할 수 있습니다.
루트
로서 다음을 입력합니다.umount mount_dir
여기서 mount_dir 은 마운트 디렉터리의 경로입니다. 또한 첫 번째 단계에서 생성된 마운트 디렉토리를 제거할 수 있습니다.
루트
로서 다음을 입력합니다.rmdir mount_dir
이전에 생성된 구성 파일을 다른 설치 또는 업데이트에 사용하지 않는 경우 제거할 수 있습니다.
루트
로서 다음을 입력합니다.rm
/etc/yum.repos.d/new.repo
예 9.3. Red Hat Enterprise Linux 7.0에서 7.1으로 업그레이드
시스템의 최신 버전(예: rhel-server-7.1-x86_64-dvd.iso
)을 사용하여 ISO 이미지를 사용하여 시스템을 업그레이드해야 하는 경우 /media/rhel7/
와 같은 마운트 대상 디렉터리를 만듭니다. 루트
로서 ISO 이미지를 사용하여 디렉터리로 변경하고 다음을 입력합니다.
~]# mount -o looprhel-server-7.1-x86_64-dvd.iso
/media/rhel7/
그런 다음 마운트 디렉토리에서 media.repo
파일을 복사하여 이미지의 yum 리포지토리를 설정합니다.
~]# cp/media/rhel7/media.repo
/etc/yum.repos.d/rhel7.repo
yum이 마운트 지점을 리포지토리로 인식하도록 하려면 이전 단계에서 복사한 /etc/yum.repos.d/rhel7.repo
에 다음 행을 추가합니다.
baseurl=file:///media/rhel7/
이제 yum 리포지토리를 업데이트하면 rhel-server-7.1-x86_64-dvd.iso
에서 제공하는 버전으로 시스템이 업그레이드됩니다. root
로서 다음을 실행합니다.
~]# yum update
시스템이 성공적으로 업그레이드되면 이미지를 마운트 해제하고 대상 디렉터리 및 구성 파일을 제거할 수 있습니다.
~]# umount /media/rhel7/
~]# rmdir /media/rhel7/
~]# rm
/etc/yum.repos.d/rhel7.repo
9.2. 패키지 작업
yum을 사용하면 패키지 검색, 정보 보기, 설치 및 제거를 비롯하여 소프트웨어 패키지로 전체 작업 세트를 수행할 수 있습니다.
9.2.1. 패키지 검색
다음 명령을 사용하여 모든 RPM 패키지 이름, 설명 및 요약을 검색할 수 있습니다.
yum
search
term…
검색할 패키지 이름으로 용어를 바꿉니다.
예 9.4. 특정 문자열과 일치하는 패키지 검색
"vim", "gvim" 또는 "emacs"와 일치하는 모든 패키지를 나열하려면 다음을 입력합니다.
~]$ yum search vim gvim emacs Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager ============================= N/S matched: vim ============================== vim-X11.x86_64 : The VIM version of the vi editor for the X Window System vim-common.x86_64 : The common files needed by any version of the VIM editor [output truncated] ============================ N/S matched: emacs ============================= emacs.x86_64 : GNU Emacs text editor emacs-auctex.noarch : Enhanced TeX modes for Emacs [output truncated] Name and summary matches mostly, use "search all" for everything. Warning: No matches found for: gvim
yum search
명령은 이름을 모르는 패키지를 검색하는 데 유용하지만 관련 용어를 알고 있는 경우 유용합니다. 기본적으로 yum search
는 패키지 이름과 요약의 일치를 반환하므로 검색이 더 빨라집니다. yum search all
명령을 사용하여 더 완전하지만 느린 검색을 사용합니다.
결과 필터링
yum의 모든 list 명령을 사용하면 하나 이상의 glob 표현식 을 인수로 추가하여 결과를 필터링할 수 있습니다. glob 표현식은 와일드카드 문자 *
(모든 문자 하위 집합과 일치하도록 확장됨)과 (단일 문자와 일치하도록 확장됨) 중 하나 이상의 문자를 포함하는 일반적인 문자 문자열입니다.
glob 표현식을 yum
명령에 인수로 전달할 때 이스케이프해야 합니다. 그러지 않으면 Bash 쉘은 이러한 표현식을 경로 이름 확장 으로 해석하고 현재 디렉터리의 모든 파일을 yum
에 전달할 가능성이 있습니다. glob 표현식이 의도한 대로 yum
에 전달되도록 하려면 다음 방법 중 하나를 사용합니다.
- 뒤에 백슬래시 문자를 사용하여 와일드카드 문자 이스케이프
- 전체 글러그 표현식을 두 번 따옴표로 묶거나 한 번 따옴표로 묶습니다.
다음 섹션의 예제에서는 이 두 방법을 모두 사용하는 방법을 보여줍니다.
9.2.2. 패키지 나열
설치 및 사용 가능한 모든 패키지에 대한 정보를 나열하려면 쉘 프롬프트에서 다음을 입력합니다.
yum
list
all
삽입된 glob 표현식 과 일치하는 설치 및 사용 가능한 패키지를 나열하려면 다음 명령을 사용합니다.
yum list glob_expression…
예 9.5. ABRT 관련 패키지 나열
다양한 ABRT 애드온과 플러그인이 있는 패키지는 "abrt-addon-" 또는 "abrt-plugin-"로 시작합니다. 이러한 패키지를 나열하려면 쉘 프롬프트에서 다음 명령을 입력합니다. 와일드카드 문자를 백슬래시 문자로 이스케이프하는 방법에 유의하십시오.
~]$ yum list abrt-addon\* abrt-plugin\* Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager Installed Packages abrt-addon-ccpp.x86_64 2.1.11-35.el7 @rhel-7-server-rpms abrt-addon-kerneloops.x86_64 2.1.11-35.el7 @rhel-7-server-rpms abrt-addon-pstoreoops.x86_64 2.1.11-35.el7 @rhel-7-server-rpms abrt-addon-python.x86_64 2.1.11-35.el7 @rhel-7-server-rpms abrt-addon-vmcore.x86_64 2.1.11-35.el7 @rhel-7-server-rpms abrt-addon-xorg.x86_64 2.1.11-35.el7 @rhel-7-server-rpms
시스템에 설치된 모든 패키지를 나열하려면 installed
키워드를 사용합니다. 출력의 오른쪽 열에는 패키지가 검색된 리포지토리가 나열됩니다.
yum list installed glob_expression…
예 9.6. 설치된 모든 versions of theoctets 패키지 나열
다음 예제에서는 "krb"로 시작하고 정확히 하나의 문자와 하이픈으로 시작하는 설치된 모든 패키지를 나열하는 방법을 보여줍니다. 이는 특정 구성 요소의 모든 버전을 숫자로 구분하므로 나열하려는 경우에 유용합니다. 적절한 처리를 위해 전체 글러그 표현식이 인용됩니다.
~]$ yum list installed "krb?-*" Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager Installed Packages krb5-libs.x86_64 1.13.2-10.el7 @rhel-7-server-rpms
설치할 수 있는 활성화된 모든 리포지토리의 패키지를 모두 나열하려면 다음 형식으로 명령을 사용합니다.
yum list available glob_expression…
예 9.7. 사용 가능한 gstreamer 플러그인 나열
예를 들어 "gstreamer"가 포함된 이름이 있는 사용 가능한 패키지를 모두 나열한 다음 "plugin"을 실행하려면 다음 명령을 실행합니다.
~]$ yum list available gstreamer*plugin\* Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager Available Packages gstreamer-plugins-bad-free.i686 0.10.23-20.el7 rhel-7-server-rpms gstreamer-plugins-base.i686 0.10.36-10.el7 rhel-7-server-rpms gstreamer-plugins-good.i686 0.10.31-11.el7 rhel-7-server-rpms gstreamer1-plugins-bad-free.i686 1.4.5-3.el7 rhel-7-server-rpms gstreamer1-plugins-base.i686 1.4.5-2.el7 rhel-7-server-rpms gstreamer1-plugins-base-devel.i686 1.4.5-2.el7 rhel-7-server-rpms gstreamer1-plugins-base-devel.x86_64 1.4.5-2.el7 rhel-7-server-rpms gstreamer1-plugins-good.i686 1.4.5-2.el7 rhel-7-server-rpms
리포지토리 나열
시스템에서 활성화된 각 리포지토리의 리포지토리 ID, 이름 및 수를 나열하려면 다음 명령을 사용하십시오.
yum
repolist
이러한 리포지토리에 대한 자세한 정보를 나열하려면 -v
옵션을 추가합니다. 이 옵션을 활성화하면 파일 이름, 전체 크기, 마지막 업데이트의 날짜, 나열된 각 리포지토리에 대한 기본 URL을 포함한 정보가 표시됩니다. 또는 동일한 출력을 생성하는 repoinfo
명령을 사용할 수 있습니다.
yum
repolist
-v
yum
repoinfo
활성화된 리포지토리와 비활성화된 리포지토리를 모두 나열하려면 다음 명령을 사용합니다. 사용 가능한 리포지토리를 표시하도록 출력 목록에 상태 열이 추가됩니다.
yum
repolist
all
비활성화
를 첫 번째 인수로 전달하면 명령 출력을 비활성화 리포지토리로 줄일 수 있습니다. 추가 사양의 경우 ID 또는 리포지토리 이름 또는 관련 glob_expressions를 인수로 전달할 수 있습니다. 리포지토리 ID 또는 이름과 삽입된 인수 사이에 정확히 일치하는 경우 이 리포지토리는 활성화 또는 비활성화 필터를 전달하지 않는 경우에도 나열됩니다.
9.2.3. 패키지 정보 표시
하나 이상의 패키지에 대한 정보를 표시하려면 다음 명령을 사용합니다(glob 표현식은 여기에서도 유효합니다).
yum info package_name…
package_name 을 패키지 이름으로 바꿉니다.
예 9.8. abrt 패키지에 대한 정보 표시
abrt 패키지에 대한 정보를 표시하려면 다음을 입력합니다.
~]$ yum info abrt Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager Installed Packages Name : abrt Arch : x86_64 Version : 2.1.11 Release : 35.el7 Size : 2.3 M Repo : installed From repo : rhel-7-server-rpms Summary : Automatic bug detection and reporting tool URL : https://fedorahosted.org/abrt/ License : GPLv2+ Description : abrt is a tool to help users to detect defects in applications and : to create a bug report with all information needed by maintainer to fix : it. It uses plugin system to extend its functionality.
yum info package_name
명령은 rpm -q --info package_name
명령과 유사하지만 RPM 패키지가 설치된 yum 리포지토리의 이름(출력에서 리포지토리 :
줄 검색)을 추가로 제공합니다.
yumdb 사용
다음 명령을 사용하여 패키지에 대한 대체 및 유용한 정보를 위해 yum 데이터베이스를 쿼리할 수도 있습니다.
yumdb info package_name
이 명령은 패키지의 검사 합계(및 SHA-256 등 이를 생성하는 데 사용되는 알고리즘), 패키지를 설치하기 위해 호출된 명령줄에 제공된 명령(있는 경우) 및 시스템에 패키지가 설치된 이유를 나타내는 이유(사용자가 사용자가
설치되었음을 나타내고 depp는 종속성으로 제공됨)를 포함하여 패키지에 대한 추가 정보를 제공합니다.
예 9.9. yum package에 대한 정보를 위해 yumdb 쿼리
yum 패키지에 대한 추가 정보를 표시하려면 다음을 입력합니다.
~]$ yumdb info yum Loaded plugins: langpacks, product-id yum-3.4.3-132.el7.noarch changed_by = 1000 checksum_data = a9d0510e2ff0d04d04476c693c0313a11379053928efd29561f9a837b3d9eb02 checksum_type = sha256 command_line = upgrade from_repo = rhel-7-server-rpms from_repo_revision = 1449144806 from_repo_timestamp = 1449144805 installed_by = 4294967295 origin_url = https://cdn.redhat.com/content/dist/rhel/server/7/7Server/x86_64/os/Packages/yum-3.4.3-132.el7.noarch.rpm reason = user releasever = 7Server var_uuid = 147a7d49-b60a-429f-8d8f-3edb6ce6f4a1
yumdb
명령에 대한 자세한 내용은 yumdb(8) 매뉴얼 페이지를 참조하십시오.
9.2.4. 패키지 설치
단일 패키지 및 모든 패키지가 설치되지 않은 종속 항목을 설치하려면 root
로 다음 형식으로 명령을 입력합니다.
yum install package_name
해당 이름을 인수로 추가하여 여러 패키지를 동시에 설치할 수도 있습니다. 이 작업을 수행하려면 root
로 입력합니다.
yum install package_name package_name…
AMD64 또는 Intel 64 시스템과 같은 멀티lib 시스템에 패키지를 설치하는 경우 패키지 이름에 .arch 를 추가하여 패키지의 아키텍처를 지정할 수 있습니다.
yum install package_name.arch
예 9.10. multilib 시스템에 패키지 설치
i686
아키텍처에 대한 sqlite 패키지를 설치하려면 다음을 입력합니다.
~]# yum install sqlite.i686
glob 표현식을 사용하여 유사한 여러 개의 이름이 지정된 패키지를 빠르게 설치할 수 있습니다. root
로 실행:
yum install glob_expression…
예 9.11. 모든 무의식 플러그인 설치
전역 표현식은 비슷한 이름으로 여러 패키지를 설치하려는 경우에 유용합니다. 모든 무의식 플러그인을 설치하려면 다음 형식으로 명령을 사용합니다.
~]# yum install audacious-plugins-\*
패키지 이름 및 와일드카드 식 외에도 yum install
에 파일 이름을 제공할 수도 있습니다. 설치하려는 바이너리의 이름을 알고 있지만 패키지 이름은 아닌 경우 yum install
경로 이름을 지정할 수 있습니다. 루트
로서 다음을 입력합니다.
yum install /usr/sbin/named
그런 다음 yum은 패키지 목록을 검색하고 /usr/sbin/named
(있는 경우)를 제공하고 설치 여부를 묻는 메시지를 표시합니다.
위의 예에서 볼 수 있듯이 yum install
명령에는 엄격하게 정의된 인수가 필요하지 않습니다. 이를 통해 다양한 패키지 이름 및 글러그 표현식을 처리할 수 있으므로 사용자가 더 쉽게 설치할 수 있습니다. 반면 yum은 특히 많은 수의 패키지를 지정하는 경우 yum 이 입력을 올바르게 구문 분석할 때까지 약간의 시간이 걸립니다. 패키지 검색을 최적화하려면 다음 명령을 사용하여 인수를 구문 분석하는 방법을 명시적으로 정의할 수 있습니다.
yum install-n
name
yum install-na
name.architecture
yum install-nevra
name-epoch:version-release.architecture
install-n
를 사용하여yum 은 이름을 패키지의 정확한 이름으로 해석합니다. install-na
명령은 yum 에 패키지 이름과 아키텍처가 점 문자로 구분되어 있음을 알려줍니다. install-nevra
를 사용하면yum 은 name-epoch:version-release.architecture 형식의 인수를 예상합니다. 마찬가지로 제거할 패키지를 검색할 때 yum remove-n
,yum remove-na
, yum remove-nevra
를 사용할 수 있습니다.
이름이 지정된
바이너리가 포함된 패키지를 설치하려고 하지만 파일이 설치된 bin/
또는 sbin/
디렉터리에 대해서는 yum provides
명령을 glob 표현식과 함께 사용하십시오.
~]# yum provides "*bin/named" Loaded plugins: langpacks, product-id, search-disabled-repos, subscription- : manager 32:bind-9.9.4-14.el7.x86_64 : The Berkeley Internet Name Domain (BIND) DNS : (Domain Name System) server Repo : rhel-7-server-rpms Matched from: Filename : /usr/sbin/named
yum은 "*/file_name"
은 file_name 이 포함된 패키지를 찾는 데 유용한 방법입니다.
예 9.12. 설치 프로세스
다음 예제는 yum 을 사용하여 설치 개요를 보여줍니다. 최신 버전의 httpd 패키지를 다운로드하여 설치하려면 root
로 실행합니다.
~]# yum install httpd Loaded plugins: langpacks, product-id, subscription-manager Resolving Dependencies --> Running transaction check ---> Package httpd.x86_64 0:2.4.6-12.el7 will be updated ---> Package httpd.x86_64 0:2.4.6-13.el7 will be an update --> Processing Dependency: 2.4.6-13.el7 for package: httpd-2.4.6-13.el7.x86_64 --> Running transaction check ---> Package httpd-tools.x86_64 0:2.4.6-12.el7 will be updated ---> Package httpd-tools.x86_64 0:2.4.6-13.el7 will be an update --> Finished Dependency Resolution Dependencies Resolved
위의 명령을 실행한 후 yum 은 필요한 플러그인을 로드하고 트랜잭션 검사를 실행합니다. 이 경우 httpd 가 이미 설치되어 있습니다. 설치된 패키지가 현재 사용 가능한 최신 버전보다 오래되었으므로 업데이트됩니다. httpd가 사용하는 httpd-tools 패키지에도 동일하게 적용됩니다. 그러면 트랜잭션 요약이 표시됩니다.
================================================================================ Package Arch Version Repository Size ================================================================================ Updating: httpd x86_64 2.4.6-13.el7 rhel-x86_64-server-7 1.2 M Updating for dependencies: httpd-tools x86_64 2.4.6-13.el7 rhel-x86_64-server-7 77 k Transaction Summary ================================================================================ Upgrade 1 Package (+1 Dependent package) Total size: 1.2 M Is this ok [y/d/N]:
이 단계에서 yum 은 설치를 확인하라는 메시지를 표시합니다. y
(yes) 및 N
(no) 옵션 외에도 d
(download only)를 선택하여 패키지를 다운로드하지만 직접 설치할 수는 없습니다. y
를 선택하면 설치가 성공적으로 완료될 때까지 다음 메시지로 진행됩니다.
Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction Updating : httpd-tools-2.4.6-13.el7.x86_64 1/4 Updating : httpd-2.4.6-13.el7.x86_64 2/4 Cleanup : httpd-2.4.6-12.el7.x86_64 3/4 Cleanup : httpd-tools-2.4.6-12.el7.x86_64 4/4 Verifying : httpd-2.4.6-13.el7.x86_64 1/4 Verifying : httpd-tools-2.4.6-13.el7.x86_64 2/4 Verifying : httpd-tools-2.4.6-12.el7.x86_64 3/4 Verifying : httpd-2.4.6-12.el7.x86_64 4/4 Updated: httpd.x86_64 0:2.4.6-13.el7 Dependency Updated: httpd-tools.x86_64 0:2.4.6-13.el7 Complete!
시스템에서 로컬 디렉터리에서 이전에 다운로드한 패키지를 설치하려면 다음 명령을 사용합니다.
yum localinstall
path
경로를 설치하려는 패키지의 경로로 바꿉니다.
9.2.5. 패키지 다운로드
예 9.12. “설치 프로세스” 에 표시된 대로 설치 프로세스의 특정 시점에서 다음 메시지와 함께 설치를 확인하라는 메시지가 표시됩니다.
... Total size: 1.2 M Is this ok [y/d/N]: ...
d
옵션을 사용하면 yum이 패키지를 즉시 설치하지 않고 다운로드합니다. yum localinstall
명령을 사용하여 나중에 오프라인에서 이러한 패키지를 설치하거나 다른 장치와 공유할 수 있습니다. 다운로드한 패키지는 기본적으로 /var/cache/yum/$basearch/$releasever/packages/
.에 의해 캐시 디렉터리의 하위 디렉터리 중 하나에 저장됩니다. 다운로드는 다른 작업에 병렬로 yum 을 사용할 수 있도록 백그라운드 모드로 진행됩니다.
9.2.6. 패키지 제거
패키지 설치와 마찬가지로 yum을 사용하면 해당 패키지를 제거할 수 있습니다. 특정 패키지와 종속된 패키지를 제거하려면 root
로 다음 명령을 실행합니다.
yum remove package_name…
여러 패키지를 설치할 때 명령에 패키지 이름을 추가하여 한 번에 여러 패키지를 제거할 수 있습니다.
예 9.13. 여러 패키지 제거
totem 을 제거하려면 쉘 프롬프트에서 다음을 입력합니다.
~]# yum remove totem
install
과 유사하게remove
는 다음 인수를 사용할 수 있습니다.
- 패키지 이름
- glob 표현식
- 파일 목록
- 패키지는 제공
yum은 패키지가 종속된 패키지도 제거하지 않고 패키지를 제거할 수 없습니다. RPM 에서만 수행할 수 있는 이러한 유형의 작업은 권장되지 않으며 시스템이 작동하지 않거나 애플리케이션이 제대로 작동하지 않거나 중단될 수 있습니다.
9.3. 패키지 그룹 작업
패키지 그룹은 시스템 도구 또는 sound 및 video과 같은 공통 목적을 제공하는 패키지 컬렉션입니다. 패키지 그룹을 설치하면 시간이 크게 절약되는 종속 패키지 세트를 가져옵니다. yum groups
명령은 yum의 패키지 그룹에서 작동하는 모든 작업을 다루는 최상위 명령입니다.
9.3.1. 패키지 그룹 나열
요약
옵션은 설치된 그룹, 사용 가능한 그룹, 사용 가능한 환경 그룹 및 설치 및 사용 가능한 언어 그룹의 수를 확인하는 데 사용됩니다.
yum groups
summary
예 9.14. yum groups summary의 출력 예
~]$yum
groups
summary
Loaded plugins: langpacks, product-id, subscription-manager Available Environment Groups: 12 Installed Groups: 10 Available Groups: 12
yum 리포지토리의 모든 패키지 그룹을 나열하려면 list
옵션을 추가합니다. 그룹 이름으로 명령 출력을 필터링할 수 있습니다.
yum group list glob_expression…
표시되지 않는 사용자 표시로 표시되지 않는 그룹도 나열하도록 숨겨진
, 그룹 ID를 나열하는 ID를 포함하여 이 명령에 몇 가지 선택적 인수를 전달할 수 있습니다.
언어
,환경
,설치
또는 사용 가능한
옵션을 추가하여 명령 출력을 특정 그룹 유형으로 줄일 수 있습니다.
특정 그룹에 포함된 필수 및 선택적 패키지를 나열하려면 다음 명령을 사용합니다.
yum group info glob_expression…
예 9.15. LibreOffice 패키지 그룹에 대한 정보 보기
~]$ yum group info LibreOffice
Loaded plugins: langpacks, product-id, subscription-manager
Group: LibreOffice
Group-Id: libreoffice
Description: LibreOffice Productivity Suite
Mandatory Packages:
=libreoffice-calc
libreoffice-draw
-libreoffice-emailmerge
libreoffice-graphicfilter
=libreoffice-impress
=libreoffice-math
=libreoffice-writer
+libreoffice-xsltfilter
Optional Packages:
libreoffice-base
libreoffice-pyuno
위의 예에서 볼 수 있듯이 패키지 그룹에 포함된 패키지는 다음 기호로 표시된 것과 다른 상태를 가질 수 있습니다.
-
"
-
" - 패키지가 설치되지 않으며 패키지 그룹의 일부로 설치되지 않습니다. -
"
+ " - 패키지가 설치되지 않지만 다음yum upgrade
또는yum group 업그레이드에
설치됩니다. -
"
=
" - 패키지가 설치되고 패키지 그룹의 일부로 설치되었습니다. -
기호 없음 - 패키지가 설치되어 있지만 패키지 그룹 외부에 설치되었습니다. 즉,
yum group remove
는 이러한 패키지를 제거하지 않습니다.
이러한 차이점은 group_command
구성 매개변수가 기본 설정인 오브젝트
로 설정된 경우에만 수행됩니다. yum에서 패키지가 그룹의 일부로 설치된 경우 추적하지 않도록 하려면 이 매개변수를 다른 값으로 설정합니다. 그러면 "="패키지와 동등한기호 없음" 패키지가 없습니다.
yum group mark
명령을 사용하여 위의 패키지 상태를 변경할 수 있습니다. 예를 들어 yum group mark 패키지
는 지정된 패키지를 지정된 그룹의 멤버로 표시합니다. 그룹 업데이트에 새 패키지가 설치되지 않도록 하려면 yum group mark blacklist
를 사용합니다.
의 기능에 대한 자세한 내용은 yum(8) man 페이지를 참조하십시오.
yum
group mark
@^ 접두사를 사용하는 환경 그룹을 식별할 수 있으며 패키지 그룹은 @ 으로 표시할 수 있습니다. yum
group
list
,info
,install
, install , pass @group_name 을 전달하여 둘 다 포함할 환경 그룹을 지정하는 @^group_name 또는 group_name 을 지정합니다.
9.3.2. 패키지 그룹 설치
각 패키지 그룹에는 이름과 그룹 ID(groupid)가 있습니다. 모든 패키지 그룹의 이름과 괄호에 표시되는 그룹 ID를 나열하려면 다음을 입력합니다.
yum group list ids
예 9.16. 패키지 그룹의 이름 및 groupid 찾기
패키지 그룹의 이름 또는 ID를 찾으려면 다음을 입력합니다.
~]$ yum group list ids kde\* Available environment groups: KDE Plasma Workspaces (kde-desktop-environment) Done
일부 그룹은 구성된 리포지토리의 설정으로 숨겨져 있습니다. 예를 들어 서버에서 숨겨진 명령 옵션을 사용하여 숨겨진
그룹을 나열하십시오.
~]$ yum group list hidden ids kde\* Loaded plugins: product-id, subscription-manager Available Groups: KDE (kde-desktop) Done
groupid 부분이 없는 전체 그룹 이름을 그룹 install 명령에 전달하여 패키지 그룹을 설치할
수 있습니다. 루트
로서 다음을 입력합니다.
yum
group install
"group name"
groupid도 설치할 수 있습니다. root
로서 다음 명령을 실행합니다.
yum
group install
groupid
@ 기호로 앞에 @ 기호를 추가하면 groupid 또는 quoted 그룹 이름을 install
명령에 전달할 수 있습니다.이 명령을 사용하면 yum
에 그룹 install
임을 알 수 있습니다. 루트
로서 다음을 입력합니다.
yum
install
@group
group 을 groupid 또는 quoted 그룹 이름으로 바꿉니다. 환경 그룹에도 동일한 논리가 적용됩니다.
yum install @^group
예 9.17. managers 데스크탑 그룹 설치의 4가지와 동일한 방법
앞에서 언급했듯이 네 가지 대안을 사용할 수 있지만 패키지 그룹을 설치하는 것과 동등한 방법을 사용할 수 있습니다. rhcos Desktop의 경우 명령은 다음과 같습니다.
~]# yum group install "KDE Desktop" ~]# yum group install kde-desktop ~]# yum install @"KDE Desktop" ~]# yum install @kde-desktop
9.3.3. 패키지 그룹 제거
패키지 그룹 이름 또는 해당 id를 사용하여 install
구문과 유사한 구문을 사용하여 패키지 그룹을 제거할 수 있습니다. 루트
로서 다음을 입력합니다.
yum group remove group_name
yum
group remove
groupid
또한 @-symbol로 앞에 붙은 경우 groupid 또는 quoted name을 remove
명령에 전달할 수 있습니다. 이 명령은 yum에 그룹 remove
임을 알립니다. 루트
로서 다음을 입력합니다.
yum
remove
@group
group 을 groupid 또는 quoted 그룹 이름으로 바꿉니다. 또한 환경 그룹을 교체할 수 있습니다.
yum remove @^group
예 9.18. EgressIP Desktop
그룹을 제거하는 4 가지 동일한 방법
install과 마찬가지로 4 개의 대안을 사용할 수 있지만 패키지 그룹을 제거하는 것과 동등한 방법을 사용할 수 있습니다. rhcos Desktop의 경우 명령은 다음과 같습니다.
~]# yum group remove "KDE Desktop" ~]# yum group remove kde-desktop ~]# yum remove @"KDE Desktop" ~]# yum remove @kde-desktop
9.4. 트랜잭션 내역 작업
yum history
명령을 사용하면 사용자가 yum 트랜잭션의 타임라인, 날짜 및 시간, 이러한 트랜잭션이 성공 또는 중단되었는지 여부, 트랜잭션 간에 RPM 데이터베이스가 변경되었는지 여부를 확인할 수 있습니다. 또한 이 명령을 사용하여 특정 트랜잭션을 취소하거나 다시 실행할 수 있습니다. 모든 기록 데이터는 /var/lib/yum/history/
디렉터리 의 기록 DB에 저장됩니다.
9.4.1. 트랜잭션 나열
20개의 최근 트랜잭션 목록을 root
로 표시하려면 추가 인수 없이 yum history
를 실행하거나 쉘 프롬프트에서 다음을 입력합니다.
yum
history
list
모든 트랜잭션을 표시하려면 all
키워드를 추가합니다.
yum
history
list
all
지정된 범위의 트랜잭션만 표시하려면 다음 양식에서 명령을 사용합니다.
yum history list start_id..end_id
특정 패키지 또는 패키지와 관련된 트랜잭션만 나열할 수도 있습니다. 이렇게 하려면 패키지 이름 또는 glob 표현식과 함께 명령을 사용합니다.
yum history list glob_expression…
예 9.19. 가장 오래된 5개의 트랜잭션 나열
yum history list
의 출력에서 가장 최근 트랜잭션은 목록 상단에 표시됩니다. 기록 데이터 베이스에 저장된 5개의 가장 오래된 트랜잭션에 대한 정보를 표시하려면 다음을 입력합니다.
~]# yum history list 1..5 Loaded plugins: langpacks, product-id, subscription-manager ID | Login user | Date and time | Action(s) | Altered ------------------------------------------------------------------------------- 5 | User <user> | 2013-07-29 15:33 | Install | 1 4 | User <user> | 2013-07-21 15:10 | Install | 1 3 | User <user> | 2013-07-16 15:27 | I, U | 73 2 | System <unset> | 2013-07-16 15:19 | Update | 1 1 | System <unset> | 2013-07-16 14:38 | Install | 1106 history list
모든 형태의 yum history list
명령은 다음 열로 구성된 각 행이 있는 테이블 형식 출력을 생성합니다.
-
특정
트랜잭션을 식별하는 정수 값입니다.An integer value that identifies a particular transaction. -
login
사용자
- 트랜잭션을 시작하는 데 로그인 세션이 사용된 사용자의 이름입니다. 이 정보는 일반적으로전체 이름 <username>
형식으로 제공됩니다. 사용자가 발행하지 않은 트랜잭션(예: 자동 시스템 업데이트)의 경우시스템 <unset>
이 대신 사용됩니다. -
날짜 및 시간
- 트랜잭션이 실행된 날짜 및 시간입니다. -
작업 - 표 9.1. “Action(s) 필드의 가능한 값” 에
설명된 대로 트랜잭션 중에 수행된 작업 목록입니다. -
변경된
사항 - 트랜잭션의 영향을 받는 패키지 수, 표 9.2. “대체 필드의 가능한 값” 에 설명된 대로 추가 정보가 올 수 있습니다.
동작 | 약어 | 설명 |
---|---|---|
|
| 하나 이상의 패키지가 이전 버전으로 다운그레이드되었습니다. |
|
| 하나 이상의 패키지가 제거되었습니다. |
|
| 새 패키지가 하나 이상 설치되어 있어야 합니다. |
|
| 하나 이상의 패키지가 더 이상 사용되지 않음으로 표시되었습니다. |
|
| 하나 이상의 패키지가 다시 설치되어 있어야 합니다. |
|
| 하나 이상의 패키지가 최신 버전으로 업데이트되었습니다. |
symbol | 설명 |
---|---|
|
트랜잭션이 완료되기 전에 |
|
트랜잭션이 완료되면 |
| 트랜잭션이 완료되지 못했습니다. |
| 트랜잭션이 성공적으로 완료되었지만 yum은 0이 아닌 종료 코드를 반환했습니다. |
| 트랜잭션이 성공적으로 완료되었지만 오류 또는 경고가 표시되었습니다. |
|
트랜잭션이 성공적으로 완료되었지만 |
|
트랜잭션이 성공적으로 완료되었지만 |
현재 사용된 rpmdb
또는 yumdb
데이터베이스와 설치된 패키지의 rpmdb
또는 yumdb
데이터베이스 내용을 동기화하려면 다음을 입력합니다.
yum
history
sync
현재 사용된 기록 데이터베이스에 대한 몇 가지 전체 통계를 표시하려면 다음 명령을 사용합니다.
yum
history
stats
예 9.20. yum 기록 통계의 출력 예
~]# yum history stats Loaded plugins: langpacks, product-id, subscription-manager File : //var/lib/yum/history/history-2012-08-15.sqlite Size : 2,766,848 Transactions: 41 Begin time : Wed Aug 15 16:18:25 2012 End time : Wed Feb 27 14:52:30 2013 Counts : NEVRAC : 2,204 NEVRA : 2,204 NA : 1,759 NEVR : 2,204 rpm DB : 2,204 yum DB : 2,204 history stats
또한 yum을 사용하면 모든 과거의 트랜잭션에 대한 요약을 표시할 수 있습니다. 이렇게 하려면 root
로 다음 형태로 명령을 실행합니다.
yum
history
summary
지정된 범위의 트랜잭션만 표시하려면 다음을 입력합니다.
yum history summary start_id..end_id
yum history list
명령과 마찬가지로 패키지 이름 또는 glob 표현식을 제공하여 특정 패키지 또는 패키지와 관련된 트랜잭션 요약을 표시할 수도 있습니다.
yum history summary glob_expression…
예 9.21. 최신 5개의 트랜잭션 요약
~]# yum history summary 1..5 Loaded plugins: langpacks, product-id, subscription-manager Login user | Time | Action(s) | Altered ------------------------------------------------------------------------------- Jaromir ... <jhradilek> | Last day | Install | 1 Jaromir ... <jhradilek> | Last week | Install | 1 Jaromir ... <jhradilek> | Last 2 weeks | I, U | 73 System <unset> | Last 2 weeks | I, U | 1107 history summary
모든 형태의 yum history summary
명령은 yum history list
의 출력과 유사한 단순화된 테이블 출력을 생성합니다.
위에 표시된 대로 yum history list
및 yum history summary
은 모두 트랜잭션을 지향하지만 지정된 패키지 또는 패키지와 관련된 트랜잭션만 표시할 수 있지만 패키지 버전과 같은 중요한 세부 사항은 표시되지 않습니다. 패키지 관점에서 트랜잭션을 나열하려면 root
로 다음 명령을 실행합니다.
yum history package-list glob_expression…
예 9.22. 패키지 기록 추적
예를 들어 subscription-manager 및 관련 패키지의 기록을 추적하려면 쉘 프롬프트에서 다음을 입력합니다.
~]# yum history package-list subscription-manager\* Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager ID | Action(s) | Package ------------------------------------------------------------------------------- 2 | Updated | subscription-manager-1.13.22-1.el7.x86_64 EE 2 | Update | 1.15.9-15.el7.x86_64 EE 2 | Obsoleted | subscription-manager-firstboot-1.13.22-1.el7.x86_64 EE 2 | Updated | subscription-manager-gui-1.13.22-1.el7.x86_64 EE 2 | Update | 1.15.9-15.el7.x86_64 EE 2 | Obsoleting | subscription-manager-initial-setup-addon-1.15.9-15.el7.x86_64 EE 1 | Install | subscription-manager-1.13.22-1.el7.x86_64 1 | Install | subscription-manager-firstboot-1.13.22-1.el7.x86_64 1 | Install | subscription-manager-gui-1.13.22-1.el7.x86_64 history package-list
이 예에서는 초기 시스템 설치 중에 3개의 패키지( subscription-manager , subscription-manager -firstboot , subscription-manager-firstboot, subscription-manager-gui )가 설치되었습니다. 세 번째 트랜잭션에서는 이러한 패키지가 1.10.11 버전에서 1.10.17 버전으로 업데이트되었습니다.
9.4.2. 트랜잭션 검사
단일 트랜잭션 요약을 root
로 표시하려면 다음 형식으로 yum history summary
명령을 사용합니다.
yum
history
summary
id
여기서 id 는 트랜잭션의 ID입니다.
특정 트랜잭션 또는 트랜잭션을 보다 자세히 검사하려면 root
로 다음 명령을 실행하십시오.
yum
history
info
id…
id 인수는 선택 사항이며 생략하면 yum은 마지막 트랜잭션을 자동으로 사용합니다. 둘 이상의 트랜잭션을 지정할 때 범위를 사용할 수도 있습니다.
yum history info start_id..end_id
예 9.23. yum history info의 출력 예
다음은 두 개의 트랜잭션에 대한 샘플 출력이며 각각 하나의 새 패키지를 설치합니다.
~]# yum history info 4..5 Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager Transaction ID : 4..5 Begin time : Mon Dec 7 16:51:07 2015 Begin rpmdb : 1252:d2b62b7b5768e855723954852fd7e55f641fbad9 End time : 17:18:49 2015 (27 minutes) End rpmdb : 1253:cf8449dc4c53fc0cbc0a4c48e496a6c50f3d43c5 User : Maxim Svistunov <msvistun> Return-Code : Success Command Line : install tigervnc-server.x86_64 Command Line : reinstall tigervnc-server Transaction performed with: Installed rpm-4.11.3-17.el7.x86_64 @rhel-7-server-rpms Installed subscription-manager-1.15.9-15.el7.x86_64 @rhel-7-server-rpms Installed yum-3.4.3-132.el7.noarch @rhel-7-server-rpms Packages Altered: Reinstall tigervnc-server-1.3.1-3.el7.x86_64 @rhel-7-server-rpms history info
트랜잭션 시 사용된 구성 옵션 또는 리포지토리 및 특정 패키지가 설치된 이유와 같은 추가 정보를 볼 수도 있습니다. 특정 트랜잭션에 사용할 수 있는 추가 정보를 확인하려면 루트로
쉘 프롬프트에 다음을 입력합니다.
yum
history
addon-info
id
yum history info
와 유사하게 id 가 제공되지 않으면 yum은 latest 트랜잭션을 자동으로 사용합니다. 최신 트랜잭션을 참조하는 또 다른 방법은 마지막
키워드를 사용하는 것입니다.
yum
history
addon-info
last
예 9.24. yum
history
addon-info
의 출력 예
기록의 네 번째 트랜잭션의 경우 yum history addon-info
명령은 다음 출력을 제공합니다.
~]# yum history addon-info 4 Loaded plugins: langpacks, product-id, subscription-manager Transaction ID: 4 Available additional history information: config-main config-repos saved_tx history addon-info
yum
history
addon-info
명령의 출력에서 다음 세 가지 유형의 정보를 사용할 수 있습니다.
-
config-main
- 트랜잭션 중에 사용 중인 글로벌 yum 옵션. 글로벌 옵션을 변경하는 방법에 대한 자세한 내용은 9.5.1절. “[main] 옵션 설정” 을 참조하십시오. -
config-repos
- 개별 yum 리포지토리에 대한 옵션 개별 리포지토리의 옵션을 변경하는 방법에 대한 자세한 내용은 9.5.2절. “[repository] 옵션 설정” 을 참조하십시오. -
saved_tx
- 다른 시스템에서 트랜잭션을 반복하기 위해yum load-
hiera 명령에서 사용할 수 있는 데이터입니다(아래 참조).
선택한 유형의 추가 정보를 표시하려면 root
로 다음 명령을 실행합니다.
yum
history
addon-info
id information
9.4.3. 트랜잭션 복원 및 종료
트랜잭션 내역을 검토하는 것 외에도 yum history
명령은 선택한 트랜잭션을 되돌리거나 반복할 수 있는 수단을 제공합니다. 트랜잭션을 되돌리려면 쉘 프롬프트에서 root
로 다음을 입력합니다.
yum
history
undo
id
특정 트랜잭션을 root
로 반복하려면 다음 명령을 실행합니다.
yum
history
redo
id
두 명령 모두 마지막
키워드를 수락하여 최신 트랜잭션을 취소하거나 반복합니다.
yum history undo
및 yum history 명령을
둘 다 트랜잭션 중에 수행된 단계를 되돌리거나 반복합니다. 트랜잭션이 새 패키지를 설치한 경우 yum history undo
명령에서 해당 패키지를 제거하고 트랜잭션이 패키지를 제거한 경우 명령이 다시 설치합니다. 또한 이 명령은 이러한 이전 패키지를 계속 사용할 수 있는 경우 업데이트된 모든 패키지를 이전 버전으로 다운그레이드하려고 합니다.
동일한 시스템을 여러 개 관리할 때 yum을 사용하면 해당 시스템에서 트랜잭션을 수행하여 트랜잭션 세부 사항을 파일에 저장하고 테스트 기간 후에 나머지 시스템에서 동일한 트랜잭션을 반복할 수 있습니다. 트랜잭션 세부 정보를 파일에 저장하려면 쉘 프롬프트에서 root
로 다음을 입력합니다.
yum -q history addon-info id saved_tx > file_name
이 파일을 대상 시스템에 복사하면 root
로 다음 명령을 사용하여 트랜잭션을 반복할 수 있습니다.
yum load-transaction file_name
누락된 패키지 또는 rpmdb 버전 을 무시하도록 로드 비트랜젝션
을 구성할 수 있습니다. 이러한 구성 옵션에 대한 자세한 내용은 yum.conf
(5) 매뉴얼 페이지를 참조하십시오.
9.4.4. 새 트랜잭션 내역 시작
yum은 트랜잭션 기록을 단일 SQLite 데이터베이스 파일에 저장합니다. 새 트랜잭션 기록을 시작하려면 root
로 다음 명령을 실행합니다.
yum
history
new
그러면 /var/lib/yum/history/
디렉토리에 비어 있는 새 데이터베이스 파일이 생성됩니다. 이전 트랜잭션 기록은 유지되지만 최신 데이터베이스 파일이 디렉터리에 있는 동안에는 액세스할 수 없습니다.
9.5. YUM 및 YUM 리포지토리 구성
전문 지식을 확장하려면 Red Hat System Administration III(RH254) 및 RHCSASECRET Track(RH199) 교육 과정에도 관심이 있을 수 있습니다.
yum 및 관련 유틸리티의 구성 정보는 /etc/yum.conf
에 있습니다. 이 파일에는 전역 효과가 있는 yum 옵션을 설정할 수 있는 필수 [main]
섹션이 하나 이상 포함되어 있으며 리포지토리별 옵션을 설정할 수 있는 하나 이상의 [repository]
섹션도 포함할 수 있습니다. 그러나 /etc/yum
파일에 정의하는 것이 좋습니다. .repo
s.d/ 디렉토리에 개별 리포지토리를 new 또는 기존 .repo/etc/yum.conf
파일의 개별 [repository]
섹션에 정의된 값은 [main]
섹션에 설정된 값을 재정의합니다.
이 섹션에서는 다음을 수행하는 방법을 보여줍니다.
-
/etc/yum.conf
설정 파일의[main]
섹션을 편집하여 글로벌 yum 옵션을 설정합니다. -
/etc/yum.conf
의[repository]
섹션 및 /etc/yum.repo
s.d/ 디렉토리에 있는 .repo 파일을 편집하여 개별 리포지토리에 대한 옵션을 설정합니다.
-
동적 버전 및 아키텍처 값이 올바르게 처리되도록
/etc/yum.conf
의 yum 변수와/etc/yum.repos.d/
디렉토리에 있는 파일을 사용합니다. - 명령줄에서 yum 리포지토리를 추가, 활성화 및 비활성화합니다.
- 사용자 지정 yum 리포지토리를 설정합니다.
9.5.1. [main] 옵션 설정
/etc/yum.conf
설정 파일에는 정확히 하나의 [main]
섹션이 포함되어 있으며 이 섹션의 일부 키-값 쌍은 yum의 작동 방식에 영향을 미치므로 yum이 리포지토리를 처리하는 방식에 영향을 미칩니다.
/etc/yum.conf
의 [main]
섹션 제목 아래에 많은 추가 옵션을 추가할 수 있습니다.
샘플 /etc/yum.conf
설정 파일은 다음과 같습니다.
[main] cachedir=/var/cache/yum/$basearch/$releasever keepcache=0 debuglevel=2 logfile=/var/log/yum.log exactarch=1 obsoletes=1 gpgcheck=1 plugins=1 installonly_limit=3 [comments abridged] # PUT YOUR REPOS HERE OR IN separate files named file.repo # in /etc/yum.repos.d
다음은 [main]
섹션에서 가장 일반적으로 사용되는 옵션입니다.
assumeyes
=valueassumeyes
옵션은 yum이 중요 작업의 확인을 요청하는지 여부를 결정합니다. 값을 다음 중 하나로 바꿉니다.0
(기본값) - yum은 수행하는 중요한 작업을 확인하라는 메시지를 표시합니다.1
- 중요한yum
작업을 확인하라는 메시지가 표시되지 마십시오.yes=1
이 설정된 경우 yum은 명령줄 옵션-y
및--assumeyes
와 동일한 방식으로 작동합니다.cachedir
=directoryyum이 캐시 및 데이터베이스 파일을 저장하는 디렉터리를 설정하려면 이 옵션을 사용합니다. 디렉터리 를 디렉터리의 절대 경로로 바꿉니다. 기본적으로 yum의 캐시 디렉토리는
/var/cache/yum/$basearch/$releasever/
입니다.$basearch
및$releasever
yum 변수에 대한 설명은 9.5.3절. “YUM 변수 사용” 을 참조하십시오.debuglevel
=value-
이 옵션은 yum에서 생성한 디버깅 출력에 대한 세부 정보를 지정합니다. 여기서 value 는
1
에서10
사이의 정수입니다. 더 높은debuglevel
값을 설정하면 yum은 더 자세한 디버깅 출력을 표시합니다.debuglevel=2
는 기본값이지만debuglevel=0
은 디버깅 출력을 비활성화합니다. exactarch
=value이 옵션을 사용하면 이미 설치된 패키지를 업데이트할 때 정확한 아키텍처를 고려하도록 yum을 설정할 수 있습니다. 값을 다음과 같이 바꿉니다.
0
- 패키지를 업데이트할 때 정확한 아키텍처를 고려하지 마십시오.1
(기본값) - 패키지를 업데이트할 때 정확한 아키텍처를 고려하십시오. 이 설정을 사용하면 yum은 64비트 아키텍처가 있는 시스템에 이미 설치된 패키지를 업데이트하기 위해 32비트 아키텍처용 패키지를 설치하지 않습니다.exclude
=package_name more_package_names-
exclude
옵션을 사용하면 설치 또는 시스템 업데이트 중에 키워드로 패키지를 제외할 수 있습니다. 제외에 대한 여러 패키지를 나열하면 공백으로 구분된 패키지 목록을 인용하여 수행할 수 있습니다. 와일드카드를 사용하는 쉘 와일드카드 표현식(예:*
및?
)이 허용됩니다. gpgcheck
=valuegpgcheck
옵션을 사용하여 yum이 패키지에서 GPG 서명 검사를 수행해야 하는지 지정합니다. 값을 다음과 같이 바꿉니다.0
- 로컬 패키지 설치를 포함하여 모든 리포지토리의 패키지에서 GPG 서명 확인을 비활성화합니다.1
(기본값) - 로컬 패키지 설치를 포함하여 모든 리포지토리의 모든 패키지에서 GPG 서명을 확인할 수 있습니다.gpgcheck
가 활성화되면 모든 패키지의 서명이 확인됩니다.이 옵션이
/etc/yum.conf
파일의[main]
섹션에 설정된 경우 모든 리포지토리에 대해 GPG-checking 규칙을 설정합니다. 그러나 개별 리포지토리에 대해gpgcheck=값을
설정할 수도 있습니다. 즉, 다른 리포지토리에서 비활성화하는 동안 한 리포지토리에서 GPG 검사를 활성화할 수 있습니다. 해당.repo
파일에 개별 리포지토리에 대한gpgcheck=값을
설정하면/etc/yum.conf
에 있는 경우 기본값이 재정의됩니다.group_command
=valuegroup_command
옵션을 사용하여yum group install
,yum group upgrade
,yum group remove
명령이 패키지 그룹을 처리하는 방법을 지정합니다. 값을 의 값으로 바꿉니다.단순
- 패키지 그룹의 모든 멤버를 설치합니다. 이전에 설치한 패키지만 업그레이드하지만 그동안 그룹에 추가된 패키지를 설치하지 마십시오.compat
-단순하지만
yum upgrade
는 이전 업그레이드 이후 그룹에 추가된 패키지도 설치합니다.개체
- (기본값.) 이 옵션을 사용하면 yum은 이전에 설치한 그룹을 추적하고 별도로 설치된 그룹 및 패키지의 일부로 설치된 패키지를 구분합니다. 보기 예 9.15. “LibreOffice 패키지 그룹에 대한 정보 보기”group_package_types
=package_type more_package_types-
여기에서
yum
group
install
명령을 호출할 때 설치된 패키지 유형(선택 사항,기본 또는 필수)을 지정할 수 있습니다. 기본 패키지 유형 및 필수 패키지 유형은 기본적으로 선택됩니다. history_record
=value이 옵션을 사용하면 yum을 설정하여 트랜잭션 기록을 기록할 수 있습니다. 값을 다음 중 하나로 바꿉니다.
0
- yum은 트랜잭션의 기록 항목을 기록하지 않아야 합니다.1
(기본값) - yum은 트랜잭션의 기록 항목을 기록합니다. 이 작업은 특정 디스크 공간을 차지하며 트랜잭션에는 약간의 추가 시간이 걸리지만, 이전 작업에 대한 많은 정보를 제공합니다. 이 정보는yum
history
명령으로 표시할 수 있습니다.history_ record=1
은 기본값입니다.yum
history
명령에 대한 자세한 내용은 9.4절. “트랜잭션 내역 작업” 을 참조하십시오.참고yum은 기록 레코드를 사용하여 yum 외부에서 수행된
rpmdb
데이터 베이스의 수정 사항을 탐지합니다. 이러한 경우 yum은 경고를 표시하고rpmdb
변경으로 인한 가능한 문제를 자동으로 검색합니다.history_ record
가 꺼지면 yum은 이러한 변경 사항을 감지할 수 없으며 자동 검사가 수행되지 않습니다.installonlypkgs
=space separated list of packages여기에서 yum을 설치할 수 있는 패키지 목록을 공백으로 구분하여 제공할 수 있지만 업데이트되지 않습니다. 기본적으로 설치 전용 패키지 목록은
yum.conf
(5) 매뉴얼 페이지를 참조하십시오.installonlypkgs
/etc/yum.conf
에 추가하는 경우yum.conf
(5)의 installonly(설치 전용) 섹션에 나열된 패키지를 모두 나열해야 합니다. 특히 커널 패키지가 항상installonlypkgs
에 나열되어 있고installonly_limit
는 항상2
보다 큰 값으로 설정되어 있으므로 기본 패키지를 부팅하지 못하는 경우 백업 커널을 항상 사용할 수 있습니다.
installonly_limit
=value이 옵션은
installonlypkgs
지시문에 나열된 패키지 수를 동시에 설치할 수 있도록 설정합니다.installonlypkgs
에 나열된 단일 패키지에 대해 동시에 설치할 수 있는 최대 버전 수를 나타내는 정수로 값을 바꿉니다.installonlypkgs
지시문의 기본값에는 여러 가지 커널 패키지가 포함되어 있으므로installonly_limit
값을 변경하면 단일 커널 패키지의 최대 버전 수에도 영향을 미칩니다./etc/yum.conf
에 나열된 기본값은installonly_limit=3
이며 가능한 최소 값은installonly_limit=2
입니다.yum이 실행 중인 커널을 제거하므로
installonly_limit=1
을 설정할 수 없습니다.installonly_limit=1
을 사용하면 yum이 실패합니다.installonly_limit=2
를 사용하면 하나의 백업 커널을 사용할 수 있습니다. 그러나 두 개의 백업 커널을 사용할 수 있도록 기본 설정installonly_limit=3
를 유지하는 것이 좋습니다.keepcache
=valuekeepcache
옵션은 yum이 설치 후 헤더 및 패키지의 캐시를 유지할지 여부를 결정합니다. 여기서 value 는 다음 중 하나입니다.0
(기본값) - 설치 후 헤더 및 패키지의 캐시를 유지하지 마십시오.1
- 설치 후 캐시를 유지합니다.logfile
=file_name-
로깅 출력 위치를 지정하려면 file_name 을 yum이 로깅 출력을 써야 하는 파일의 절대 경로로 바꿉니다. 기본적으로 yum은
/var/log/yum.log
에 로그합니다. max_connenctions
=number- 여기서 값은 최대 동시 연결 수이며 기본값은 5입니다.
multilib_policy
=valuemultilib_policy
옵션은 패키지 설치에 여러 아키텍처 버전을 사용할 수 있는 경우 설치 동작을 설정합니다. 여기서 값은 다음과 같습니다.best
- 이 시스템에 가장 적합한 아키텍처 설치. 예를 들어, AMD64 시스템에multilib_policy=best
를 설정하면 yum이 모든 패키지의 64비트 버전을 설치합니다.all
- 항상 모든 패키지에 대해 가능한 모든 아키텍처를 설치합니다. 예를 들어multilib_policy
가 AMD64 시스템에모두
설정된 경우 yum은 둘 다 사용할 수 있는 경우 패키지의 i686 및 AMD64 버전을 둘 다 설치합니다.obsoletes
=valueobsoletes
옵션을 사용하면 업데이트 중에 더 이상 사용되지 않는 프로세스 논리를 사용할 수 있습니다. 한 패키지가 다른 패키지를 더 이상 사용하지 않는 사양 파일에서 선언하면 이전 패키지가 설치된 이전 패키지로 교체됩니다. 예를 들어 패키지의 이름이 변경된 경우 obsoletes가 선언됩니다. 값을 다음 중 하나로 바꿉니다.0
- 업데이트를 수행할 때 yum의 더 이상 사용되지 않는 처리 논리를 비활성화합니다.1
(기본) - 업데이트를 수행할 때 yum이 더 이상 사용되지 않는 처리 논리를 사용하도록 설정합니다.plugins
=valueyum 플러그인을 활성화 또는 비활성화하기 위한 글로벌 스위치이며 값은 다음 중 하나입니다.
0
- 모든 yum 플러그인을 전역적으로 비활성화합니다.중요특정 플러그인이 중요한 yum 서비스를 제공하므로 모든 플러그인을 비활성화하는 것은 권장되지 않습니다. 특히 product-id 및 subscription-manager 플러그인은 인증서 기반CDN(
Content Delivery Network
)을 지원합니다. 전역적으로 플러그인을 비활성화하는 것은 편리함으로 제공되며 일반적으로 yum을 사용하여 잠재적인 문제를 진단할 때만 권장됩니다.1
(기본값) - 전역에서 모든 yum 플러그인을 활성화합니다.plugins=1
을 사용하면 해당 플러그인의 구성 파일에서enabled=0
을 설정하여 특정 yum 플러그인을 비활성화할 수 있습니다.다양한 yum 플러그인에 대한 자세한 내용은 9.6절. “yum 플러그인” 을 참조하십시오. 플러그인 제어에 대한 자세한 내용은 9.6.1절. “YUM 플러그인 활성화, 구성 및 비활성화” 을 참조하십시오.
reposdir
=directory-
여기에서 디렉터리 는
.repo
파일이 있는 디렉터리의 절대 경로입니다. 모든.repo
파일에는 저장소 정보(/etc/yum.conf
의[repository]
섹션과 유사합니다. yum은 트랜잭션에 사용할 리포지토리의 마스터 목록을 생성하기 위해/etc/yum.conf
파일의.repo
파일과[repository]
섹션에서 모든 리포지토리 정보를 수집합니다.reposdir
이 설정되지 않은 경우 yum은 기본 디렉토리/etc/yum.repos.d/
를 사용합니다. retries
=value-
이 옵션은 오류를 반환하기 전에 yum이 파일을 검색하려는 횟수를 설정합니다. 값은 정수
0
이상입니다. 값을0
으로 설정하면 yum이 영구적으로 다시 시도합니다. 기본값은10
입니다.
사용 가능한 [main]
옵션의 전체 목록은 yum.conf(5) 매뉴얼 페이지의 [main] OPTIONS
섹션을 참조하십시오.
9.5.2. [repository] 옵션 설정
[repository]
섹션은 repository 가 my_personal_repo
(공백이 허용되지 않음)와 같은 고유한 리포지토리 ID로 개별 yum 리포지토리를 정의할 수 있도록 합니다. 충돌을 방지하려면 사용자 정의 리포지토리가 Red Hat 리포지토리에서 사용하는 이름을 사용해서는 안 됩니다.
다음은 [리포지토리]
섹션의 최소 예는 다음과 같습니다.
[repository] name=repository_name baseurl=repository_url
모든 [repository]
섹션에는 다음 지시문이 포함되어야 합니다.
name
=repository_name- 여기서 repository_name 은 리포지토리를 설명하는 사람이 읽을 수 있는 문자열입니다.
baseurl
=repository_urlrepository_url 을 리포지토리의 repodata 디렉터리가 있는 디렉터리의 URL로 바꿉니다.
-
HTTP를 통해 리포지터리를 사용할 수 있는 경우
http://path/to/repo
을 사용합니다. -
FTP를 통해 리포지토리를 사용할 수 있는 경우
ftp://path/to/repo
을 사용합니다. -
리포지토리가 머신에 로컬인 경우
file:///path/to/local/repo
를 사용합니다. 특정 온라인 리포지토리에 기본 HTTP 인증이 필요한 경우 사용자 이름 및 암호를 사용자 이름
:password@link
로 URL 앞에 추가하여 지정할 수 있습니다. 예를 들어 http://www.example.com/repo/ 의 리포지토리에 "user"의 사용자 이름과 "password"의 암호가 필요한 경우baseurl
링크를 http://user:/repo/ 로 지정할 수 있습니다.일반적으로 이 URL은 다음과 같은 HTTP 링크입니다.
baseurl=http://path/to/repo/releases/$releasever/server/$basearch/os/
yum은 항상 URL에서
$releasever
,$arch
,$basearch
변수를 확장합니다. yum 변수에 대한 자세한 내용은 9.5.3절. “YUM 변수 사용” 을 참조하십시오.
-
HTTP를 통해 리포지터리를 사용할 수 있는 경우
기타 유용한 [repository]
지시문은 다음과 같습니다.
enabled
=value이 방법은 yum에 특정 리포지토리를 사용하거나 무시하도록 하는 간단한 방법입니다. 값은 다음 중 하나입니다.
0
- 업데이트 및 설치를 수행할 때 이 리포지토리를 패키지 소스로 포함하지 마십시오. 이는 리포지토리를 설정하고 해제하는 쉬운 방법입니다. 이 방법은 업데이트 또는 설치를 활성화하지 않으려는 저장소에서 단일 패키지를 원할 때 유용합니다.1
- 이 리포지토리를 패키지 소스로 포함합니다.리포지토리를 켜거나 꺼짐은
--enablerepo=repo_name또는
옵션을--disablerepo=repo_name
yum
에 전달하거나 PackageKit 유틸리티의소프트웨어 추가/제거
창을 통해 수행할 수도 있습니다.async
=value리포지토리 패키지의 병렬 다운로드를 제어합니다. 여기서 value 는 다음 중 하나입니다.
자동
(기본) - 병렬 다운로드가 가능하면 사용되므로 yum 은 오류가 발생하지 않도록 플러그인에서 생성한 리포지토리에 대해 자동으로 비활성화합니다.On
- 리포지토리에 대해 병렬 다운로드가 활성화됩니다.off
- 리포지토리에 대해 병렬 다운로드가 비활성화되어 있습니다.
더 많은 [저장소]
옵션이 있으며, 그 중 일부는 특정 [기본]
옵션과 동일한 형식을 갖습니다. 전체 목록은 yum.conf(5) 매뉴얼 페이지의 [repository] OPTIONS
섹션을 참조하십시오.
예 9.25. 샘플 /etc/yum.repos.d/redhat.repo 파일
다음은 샘플 /etc/yum.repos.d/redhat.repo
파일입니다.
# # Red Hat Repositories # Managed by (rhsm) subscription-manager # [red-hat-enterprise-linux-scalable-file-system-for-rhel-6-entitlement-rpms] name = Red Hat Enterprise Linux Scalable File System (for RHEL 6 Entitlement) (RPMs) baseurl = https://cdn.redhat.com/content/dist/rhel/entitlement-6/releases/$releasever/$basearch/scalablefilesystem/os enabled = 1 gpgcheck = 1 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release sslverify = 1 sslcacert = /etc/rhsm/ca/redhat-uep.pem sslclientkey = /etc/pki/entitlement/key.pem sslclientcert = /etc/pki/entitlement/11300387955690106.pem [red-hat-enterprise-linux-scalable-file-system-for-rhel-6-entitlement-source-rpms] name = Red Hat Enterprise Linux Scalable File System (for RHEL 6 Entitlement) (Source RPMs) baseurl = https://cdn.redhat.com/content/dist/rhel/entitlement-6/releases/$releasever/$basearch/scalablefilesystem/source/SRPMS enabled = 0 gpgcheck = 1 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release sslverify = 1 sslcacert = /etc/rhsm/ca/redhat-uep.pem sslclientkey = /etc/pki/entitlement/key.pem sslclientcert = /etc/pki/entitlement/11300387955690106.pem [red-hat-enterprise-linux-scalable-file-system-for-rhel-6-entitlement-debug-rpms] name = Red Hat Enterprise Linux Scalable File System (for RHEL 6 Entitlement) (Debug RPMs) baseurl = https://cdn.redhat.com/content/dist/rhel/entitlement-6/releases/$releasever/$basearch/scalablefilesystem/debug enabled = 0 gpgcheck = 1 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release sslverify = 1 sslcacert = /etc/rhsm/ca/redhat-uep.pem sslclientkey = /etc/pki/entitlement/key.pem sslclientcert = /etc/pki/entitlement/11300387955690106.pem
9.5.3. YUM 변수 사용
yum
명령과 모든 yum 구성 파일 (즉, /etc/yum.conf
및 /etc/yum .repo
s.d/ 디렉토리에 있는 모든 .repo 파일)에서 다음 기본 제공 변수를 사용하고 참조할 수 있습니다.
$releaseVer
-
이 변수를 사용하여 Red Hat Enterprise Linux 릴리스 버전을 참조할 수 있습니다. yum은
/etc/yum.conf
구성 파일의distroverpkg=value
line에서$releasever
값을 가져옵니다./etc/yum.conf
에 이러한 행이 없는 경우 yum은redhat-release
파일을 제공하는redhat-release제품
패키지에서 버전 번호를 파생하여 올바른 값을 유추합니다. $Arch
-
이 변수를 사용하여 Python의
os.uname()
함수를 호출할 때 반환된 시스템의 CPU 아키텍처를 참조할 수 있습니다.$arch
에 유효한 값에는i586
,i686
및x86_64
가 포함됩니다. $basearch
-
basearch
를 사용하여 시스템의
기본 아키텍처를 참조할 수 있습니다. 예를 들어 i686 및 i586 시스템의 기본 아키텍처는 모두i386
이며 AMD64 및 Intel 64 시스템의 기본 아키텍처는x86_64
여야 합니다. $YUM0-9
-
이러한 10개의 변수는 각각 동일한 이름의 쉘 환경 변수 값으로 교체됩니다. 이러한 변수 중 하나를 참조하고(예:
/etc/yum.conf
) 동일한 이름의 쉘 환경 변수가 없으면 구성 파일 변수가 교체되지 않습니다.
사용자 지정 변수를 정의하거나 기존 변수의 값을 재정의하려면 /etc/yum/vars/
디렉터리에서 변수와 동일한 이름으로 파일을 생성하고 첫 번째 줄에 원하는 값을 추가합니다.
예를 들어, 리포지토리 설명에는 운영 체제 이름이 자주 포함됩니다. $osname
이라는 새 변수를 정의하려면 첫 번째 줄에 "Red Hat Enterprise Linux"를 사용하여 새 파일을 만들고 /etc/yum/vars/osname
으로 저장합니다.
~]# echo "Red Hat Enterprise Linux 7" > /etc/yum/vars/osname
"Red Hat Enterprise Linux 7" 대신 .repo
파일에서 다음을 사용할 수 있습니다.
name=$osname $releasever
9.5.4. 현재 구성 보기
글로벌 yum 옵션의 현재 값(즉, /etc/yum.conf
파일의 [main]
섹션에 지정된 옵션)을 표시하려면 명령줄 옵션 없이 yum-config-manager
명령을 실행합니다.
yum-config-manager
다른 구성 섹션 또는 섹션의 내용을 나열하려면 다음 양식에서 명령을 사용합니다.
yum-config-manager
section…
glob 표현식을 사용하여 일치하는 모든 섹션의 구성을 표시할 수도 있습니다.
yum-config-manager glob_expression…
예 9.26. 주요 섹션의 구성 보기
기본 섹션의 모든 구성 옵션 및 해당 값을 나열하려면 쉘 프롬프트에서 다음을 입력합니다.
~]$ yum-config-manager main \* Loaded plugins: langpacks, product-id, subscription-manager ================================== main =================================== [main] alwaysprompt = True assumeyes = False bandwith = 0 bugtracker_url = https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%206&component=yum cache = 0 [output truncated]
9.5.5. YUM 리포지토리 추가, 활성화 및 비활성화
전문 지식을 확장하려면 Red Hat System Administration III(RH254) 교육 과정에도 관심이 있을 수 있습니다.
9.5.2절. “[repository] 옵션 설정” yum 리포지토리를 정의하는 데 사용할 수 있는 다양한 옵션을 설명합니다. 이 섹션에서는 yum-config-manager
명령을 사용하여 리포지토리를 추가, 활성화 및 비활성화하는 방법을 설명합니다.
시스템이 Red Hat Subscription Management에 등록된 경우 인증서 기반CDN( Content Delivery Network
)에 등록된 경우 Red Hat Subscription Manager 툴을 사용하여 /etc/yum.repos.d/redhat.repo
파일의 리포지토리를 관리합니다.
YUM 리포지토리 추가
새 리포지토리를 정의하려면 [repository]
섹션을 /etc/yum.conf
파일에 추가하거나 /etc/yum .repo
s.d/ 디렉터리의 .repo
파일에 추가할 수 있습니다. 이 디렉토리에 .repo
파일 확장자가 있는 모든 파일은 yum에서 읽고 있으며, 여기에서 /etc/yum.conf
대신 리포지토리를 정의하는 것이 좋습니다.
Red Hat의 인증서 기반CDN( Content Delivery Network
) 이외의 확인되지 않았거나 신뢰할 수 없는 소프트웨어 소스에서 소프트웨어 패키지를 취득 및 설치하면 잠재적인 보안 위험이 있으며 보안, 안정성, 호환성 및 유지 관리 문제가 발생할 수 있습니다.
yum 리포지토리는 일반적으로 자체 .repo
파일을 제공합니다. 이러한 저장소를 시스템에 추가하고 활성화하려면 root
로 다음 명령을 실행하십시오.
yum-config-manager --add-repo repository_url
여기서 repository_url 은 . repo 파일에
대한 링크입니다.
예 9.27. example.repo 추가
http://www.example.com/example.repo 에 있는 리포지터리를 추가하려면 쉘 프롬프트에서 다음을 입력합니다.
~]# yum-config-manager --add-repo http://www.example.com/example.repo Loaded plugins: langpacks, product-id, subscription-manager adding repo from: http://www.example.com/example.repo grabbing file http://www.example.com/example.repo to /etc/yum.repos.d/example.repo example.repo | 413 B 00:00 repo saved to /etc/yum.repos.d/example.repo
YUM 리포지토리 활성화
특정 리포지토리 또는 리포지토리를 활성화하려면 쉘 프롬프트에서 root
로 다음을 입력합니다.
yum-config-manager
--enable
repository…
리포지토리가 고유한 리포지토리 ID입니다( yum repolist all
을 사용하여 사용 가능한 리포지토리 ID 나열). 또는 glob 표현식을 사용하여 일치하는 모든 리포지토리를 활성화할 수 있습니다.
yum-config-manager --enable glob_expression…
예 9.28. /etc/yum.conf의 사용자 지정 섹션에 정의된 리포지토리 활성화.
[example]
, [example-debuginfo]
, [example-source]
섹션에 정의된 리포지토리를 활성화하려면 다음을 입력합니다.
~]# yum-config-manager --enable example\* Loaded plugins: langpacks, product-id, subscription-manager ============================== repo: example ============================== [example] bandwidth = 0 base_persistdir = /var/lib/yum/repos/x86_64/7Server baseurl = http://www.example.com/repo/7Server/x86_64/ cache = 0 cachedir = /var/cache/yum/x86_64/7Server/example [output truncated]
예 9.29. 모든 리포지토리 활성화
/etc/yum.conf
파일과 /etc/yum.repos.d/
디렉토리에 모두 정의된 모든 리포지토리를 활성화하려면 다음을 입력합니다.
~]# yum-config-manager --enable \* Loaded plugins: langpacks, product-id, subscription-manager ============================== repo: example ============================== [example] bandwidth = 0 base_persistdir = /var/lib/yum/repos/x86_64/7Server baseurl = http://www.example.com/repo/7Server/x86_64/ cache = 0 cachedir = /var/cache/yum/x86_64/7Server/example [output truncated]
성공하면 yum-config-manager --enable
명령은 현재 리포지토리 구성을 표시합니다.
YUM 리포지토리 비활성화
yum 리포지토리를 비활성화하려면 root
로 다음 명령을 실행합니다.
yum-config-manager
--disable
repository…
리포지토리가 고유한 리포지토리 ID입니다( yum repolist all
을 사용하여 사용 가능한 리포지토리 ID 나열). yum-config-manager --enable
도 마찬가지로 glob 표현식을 사용하여 일치하는 모든 리포지토리를 동시에 비활성화할 수 있습니다.
yum-config-manager --disable glob_expression…
예 9.30. 모든 리포지토리 비활성화
/etc/yum.conf
파일과 /etc/yum.repos.d/
디렉토리에 모두 정의된 모든 리포지토리를 비활성화하려면 다음을 입력합니다.
~]# yum-config-manager --disable \* Loaded plugins: langpacks, product-id, subscription-manager ============================== repo: example ============================== [example] bandwidth = 0 base_persistdir = /var/lib/yum/repos/x86_64/7Server baseurl = http://www.example.com/repo/7Server/x86_64/ cache = 0 cachedir = /var/cache/yum/x86_64/7Server/example [output truncated]
성공하면 yum-config-manager --disable
명령을 실행하면 현재 구성이 표시됩니다.
9.5.6. YUM 리포지토리 생성
yum 리포지토리를 설정하려면 다음을 수행합니다.
createrepo 패키지를 설치합니다.
# yum install createrepo
새 리포지토리의 모든 패키지를
/tmp/local_repo/
와 같은 하나의 디렉터리에 복사합니다.cp /your/packages/*.rpm /tmp/local_repo/
리포지토리를 생성하려면 다음을 실행합니다.
createrepo /tmp/local_repo/
이렇게 하면 yum 리포지토리에 필요한 메타데이터가 생성되고 새로 생성된 하위 디렉터리
repodata
에 메타데이터를 배치합니다.이제 yum에서 리포지토리를 사용할 준비가 되었습니다. 이 리포지토리는 HTTP 또는 FTP 프로토콜을 통해 공유하거나 로컬 머신에서 직접 참조할 수 있습니다. yum 리포지토리를 구성하는 방법에 대한 자세한 내용은 9.5.2절. “[repository] 옵션 설정” 섹션을 참조하십시오.
참고리포지토리에 대한 URL을 구성할 때 이 디렉터리에는 메타데이터만 포함되어 있으므로
/mnt/local_repo
/repodata/mnt/local_repo
에 있습니다.
9.5.6.1. 이미 생성된 yum 리포지토리에 패키지 추가
이미 생성된 yum 리포지토리에 패키지를 추가하려면 다음을 수행합니다.
새 패키지를 리포지토리 디렉터리(예:
/tmp/local_repo/
)에 복사합니다.cp /your/packages/*.rpm /tmp/local_repo/
메타데이터에 새로 추가된 패키지를 반영하려면 다음을 실행합니다.
createrepo --update /tmp/local_repo/
선택 사항: 새로 업데이트된 리포지토리와 함께 yum 명령을 이미 사용한 경우 다음을 실행합니다.
yum clean expire-cache
9.5.7. 선택적 리포지토리 추가
선택적 및 추가 서브스크립션 채널은 오픈 소스 라이센스 소프트웨어 (선택 채널) 및 독점 라이센스 소프트웨어 (애드라이브 채널의 경우)를 포함하는 Red Hat Enterprise Linux용 추가 소프트웨어 패키지를 제공합니다.
선택적 및 추가 채널에 가입하기 전에 지원 범위 세부 정보를 참조하십시오. 이러한 채널에서 패키지를 설치하려면 How to access Optional and Supplementary channel, and -devel packages using Red Hat Subscription Manager (RHSM)를 사용하여 Red Hat Customer Portal에 설명된 단계를 따르십시오.
9.6. yum 플러그인
yum은 작업을 확장하고 개선하는 플러그인을 제공합니다. 기본적으로 특정 플러그인이 설치되어 있습니다. yum은 yum
명령을 호출할 때마다 로드 및 활성 상태인 플러그인(있는 경우)을 항상 알려줍니다. 예를 들면 다음과 같습니다.
~]# yum info yum Loaded plugins: langpacks, product-id, subscription-manager [output truncated]
로드된 플러그인을 따르는 플러그인
이름은 --disableplugin=plugin_name
옵션에 제공할 수 있는 이름입니다.
9.6.1. YUM 플러그인 활성화, 구성 및 비활성화
yum 플러그인을 활성화하려면 plugins=
로 시작하는 행이 /etc/yum.conf
의 [main]
섹션에 있고 해당 값이 1
인지 확인합니다.
plugins=1
이 행을 plugins=0
으로 변경하여 모든 플러그인을 비활성화할 수 있습니다.
특정 플러그인이 중요한 yum 서비스를 제공하므로 모든 플러그인을 비활성화하는 것은 권장되지 않습니다. 특히 product-id 및 subscription-manager 플러그인은 인증서 기반CDN( Content Delivery Network
)을 지원합니다. 전역적으로 플러그인을 비활성화하는 것은 편리함으로 제공되며 일반적으로 yum을 사용하여 잠재적인 문제를 진단할 때만 권장됩니다.
설치된 모든 플러그인에는 /etc/yum/pluginconf.d/
디렉토리에 자체 구성 파일이 있습니다. 이러한 파일에서 플러그인 특정 옵션을 설정할 수 있습니다. 예를 들어 별칭 플러그인의 aliases.conf 구성 파일은 다음과 같습니다.
[main] enabled=1
/etc/yum.conf
파일과 유사하게 플러그인 구성 파일에는 항상 enabled=
옵션이 yum
명령을 실행할 때 플러그인이 활성화되는지 여부를 제어하는 [main]
섹션이 포함되어 있습니다. 이 옵션이 없는 경우 파일에 수동으로 추가할 수 있습니다.
/etc/yum.conf
에서 enabled=0
을 설정하여 모든 플러그인을 비활성화하면 개별 구성 파일에서 활성화되었는지 여부와 관계없이 모든 플러그인이 비활성화됩니다.
단일 yum
명령에 대해 모든 yum 플러그인을 비활성화하려는 경우 --noplugins
옵션을 사용합니다.
단일 yum
명령에 대해 하나 이상의 yum 플러그인을 비활성화하려면 --disableplugin=plugin_name
옵션을 명령에 추가합니다. 예를 들어 시스템을 업데이트하는 동안 aliases 플러그인을 비활성화하려면 다음을 입력합니다.
~]# yum update --disableplugin=aliases
--disableplugin=
옵션에 제공하는 플러그인 이름은 yum
명령의 출력에서 로드된 플러그인
행 뒤에 나열된 이름과 동일합니다. 해당 이름을 쉼표로 구분하여 여러 플러그인을 비활성화할 수 있습니다. 또한 여러 플러그인 이름과 일치하거나 glob 표현식을 사용하여 긴 이름을 단축할 수 있습니다.
~]# yum update --disableplugin=aliases,lang*
9.6.2. 추가 YUM 플러그인 설치
yum 플러그인은 일반적으로 yum-plugin-plugin_name
package-naming 규칙을 준수하지만 항상 그렇지는 않습니다. 예를 들어 kabi 플러그인의 이름을 kabi-yum-plugins
라고 합니다. 다른 패키지를 설치하는 것과 동일한 방식으로 yum 플러그인을 설치할 수 있습니다. 예를 들어 yum-aliases 플러그인을 설치하려면 쉘 프롬프트에서 다음을 입력합니다.
~]# yum install yum-plugin-aliases
9.6.3. YUM 플러그인 작업
다음 목록은 몇 가지 유용한 yum 플러그인에 대한 설명 및 사용 지침을 제공합니다. 플러그인은 이름으로 나열되며, 대괄호에는 패키지 이름이 포함됩니다.
- search-disabled-repos (subscription-manager)
search-disabled-repos 플러그인을 사용하면 종속 항목을 해결하기 위해 일시적으로 또는 영구적으로 비활성화된 리포지토리를 활성화할 수 있습니다. 이 플러그인을 활성화하면 YUM이 종속성 확인 실패로 인해 패키지를 설치하지 못하면 일시적으로 비활성화된 리포지토리를 활성화하고 다시 시도하십시오. 설치에 성공하면 YUM은 사용된 리포지토리를 영구적으로 활성화하도록 제공합니다. 플러그인은 subscription-manager 에서 관리하며 사용자 지정 리포지토리가 아닌 리포지토리에서만 작동합니다.
중요yum
이--
또는assumeyes
-y
옵션으로 실행되거나/etc/yum.conf
에서yes 지시문이 활성화된 경우 플러그인은 확인 메시지를 표시하지 않고 일시적으로 및 영구적으로 비활성화된 리포지토리를 활성화합니다. 이로 인해 문제가 발생할 수 있습니다(예: 활성화하지 않는 리포지토리 활성화).search-disabled-repos 플러그인을 구성하려면
/etc/yum/pluginconf.d/search-disabled-repos.conf
에 있는 구성 파일을 편집합니다.[main]
섹션에서 사용할 수 있는 지시문 목록은 아래 표를 참조하십시오.표 9.3. 지원되는 search-disabled-repos.conf 지시문 directive 설명 enabled
=value플러그인을 활성화하거나 비활성화할 수 있습니다. 값은
1
(enabled) 또는0
(비활성화)이어야 합니다. 이 플러그인은 기본적으로 활성화되어 있습니다.notify_only
=value플러그인의 동작을 알림으로 제한할 수 있습니다. 값은
1
(YUM의 동작을 변경하지 않고만 해당) 또는0
(YUM의 동작 수정)이어야 합니다. 기본적으로 플러그인은 사용자에게만 알립니다.ignored_repos
=repositories플러그인을 통해 활성화하지 않는 리포지토리를 지정할 수 있습니다.
- Kabi (kabi-yum-plugins)
kabi 플러그인은 드라이버 업데이트 패키지가 공식 Red Hat 커널 Application Binary Interface (kABI)를 준수하는지 확인합니다. 이 플러그인을 활성화하면 사용자가 화이트리스트에 없는 커널 기호를 사용하는 패키지를 설치하려고 하면 시스템 로그에 경고 메시지가 기록됩니다. 또한 강제 모드로 실행되도록 플러그인을 구성하면 이러한 패키지가 전혀 설치되지 않습니다.
kabi 플러그인을 구성하려면
/etc/yum/pluginconf.d/kabi.conf
에 있는 구성 파일을 편집합니다.[main]
섹션에서 사용할 수 있는 지시문 목록은 아래 표에 표시되어 있습니다.표 9.4. 지원되는 kabi.conf 지시문 directive 설명 enabled
=value플러그인을 활성화하거나 비활성화할 수 있습니다. 값은
1
(enabled) 또는0
(비활성화)이어야 합니다. 설치가 완료되면 플러그인이 기본적으로 활성화됩니다.whitelists
=directory지원되는 커널 기호가 있는 파일을 지정할 수 있는 디렉터리 를 지정할 수 있습니다. 기본적으로 kabi 플러그인은 kernel-abi-whitelists 패키지(즉,
/usr/lib/modules/kabi-rhel70/
디렉터리)에서 제공하는 파일을 사용합니다.enforce
=value강제 모드를 활성화 또는 비활성화할 수 있습니다. 값은
1
(enabled) 또는0
(비활성화)이어야 합니다. 기본적으로 이 옵션은 주석 처리되며 kabi 플러그인은 경고 메시지만 표시합니다.- product-id (subscription-manager)
- product-id 플러그인은 Content Delivery Network에서 설치된 제품의 제품 ID 인증서를 관리합니다. product-id 플러그인은 기본적으로 설치됩니다.
- langpacks (yum-langpacks)
- langpacks 플러그인은 설치된 모든 패키지에 대해 선택한 언어의 로케일 패키지를 검색하는 데 사용됩니다. langpacks 플러그인은 기본적으로 설치됩니다.
- 별칭 (yum-plugin-aliases)
-
aliases 플러그인은
yum
명령에 대한별칭
을 구성하고 사용할 수 있는 alias 명령줄 옵션을 추가합니다. - yum-changelog (yum-plugin-changelog)
-
yum-changelog 플러그인은 업데이트 전후에 패키지 변경 로그를 볼 수 있는
--changelog
명령줄 옵션을 추가합니다. - yum-tmprepo (yum-plugin-tmprepo)
-
yum-tmprepo 플러그인은 리포지토리 파일의 URL을 가져와 하나의 트랜잭션에 대해서만 다운로드하고 활성화하는
--tmprepo
명령줄 옵션을 추가합니다. 이 플러그인은 안전한 리포지토리 사용을 보장합니다. 기본적으로 gpg 확인을 비활성화하는 것을 허용하지 않습니다. - yum-verify (yum-plugin-verify)
-
yum-
verify
플러그인은 시스템에서 확인 데이터를 보기 위한 검증 ,verify-rpm
및verify-all
명령줄 옵션을 추가합니다. - yum-versionlock (yum-plugin-versionlock)
-
yum-versionlock 플러그인은 선택된 패키지의 다른 버전을 제외하여 패키지를 최신 버전으로 업데이트하지 못하게 합니다.
versionlock
명령줄 옵션을 사용하면 잠긴 패키지 목록을 보고 편집할 수 있습니다.
9.7. YUM-cron을 사용하여 패키지 데이터베이스 자동 새로 고침 및 업데이트 다운로드
yum-cron
서비스는 패키지 업데이트를 자동으로 확인하고 다운로드합니다. yum-cron
서비스에서 제공하는 cron 작업은 yum-cron 패키지를 설치한 직후 활성화됩니다. yum-cron
서비스는 다운로드한 업데이트를 자동으로 설치할 수도 있습니다.
기본 설정에서 yum-cron
서비스는 다음과 같습니다.
- 시간당 한 번 yum 캐시의 메타데이터를 업데이트합니다.
- 보류 중인 패키지 업데이트를 하루에 한 번 yum 캐시로 다운로드합니다. 리포지토리에서 새 패키지를 사용할 수 있는 경우 이메일이 전송됩니다. 자세한 내용은 9.7.2절. “선택적 이메일 알림 설정” 장을 참조하십시오.
yum-cron
서비스에는 다음 두 가지 구성 파일이 있습니다.
/etc/yum/yum-cron.conf
- 일별 작업을 위한 것입니다.
/etc/yum/yum-cron-hourly.conf
- 시간별 작업의 경우.
9.7.1. 자동 업데이트 설치 활성화
다운로드한 업데이트의 자동 설치를 활성화하려면 apply_updates
옵션을 다음과 같이 설정하여 일일 설치 또는 시간별 설치의 시간별 구성 파일을 편집합니다.
apply_updates = yes
9.7.2. 선택적 이메일 알림 설정
기본적으로 yum-cron
서비스는 cron
을 사용하여 실행된 명령의 출력이 포함된 이메일을 보냅니다. 이 이메일은 cron
구성에 따라 전송되며 일반적으로 로컬 수퍼유저로 전송되며 /var/spool/mail/root
파일에 저장됩니다.
모든 cron
작업에 영향을 미치는 설정과 다른 특정 이메일 구성을 사용할 수 있습니다. 그러나 이 이메일 구성은 TLS를 지원하지 않으며 전체 이메일 내장 논리는 매우 기본적인 것입니다.
yum-cron
기본 제공 이메일 알림을 활성화하려면 다음을 수행합니다.
선택된
yum-cron
구성 파일을 엽니다./etc/yum/yum-cron.conf
- 일별 작업을 위한 것입니다.
/etc/yum/yum-cron-hourly.conf
- 시간별 작업의 경우.
[emitters]
섹션에서 다음 옵션을 설정합니다.emit_via = email
-
필요에 따라
email_from
,email_to
,email_host
옵션을 설정합니다.
9.7.3. 특정 리포지토리 활성화 또는 비활성화
yum-cron
은 리포지토리의 특정 구성을 지원하지 않습니다. yum-cron
에 대한 특정 리포지토리를 활성화 또는 비활성화하는 해결 방법으로는 일반적으로 yum
의 경우 해당 단계를 수행하지 않습니다.
- 시스템의 어디에서나 빈 리포지토리 구성 디렉터리를 생성합니다.
-
/etc/yum.repos.d/
디렉토리의 모든 설정 파일을 새로 생성된 이 디렉토리에 복사합니다. /etc/yum
구성 파일에서 다음과 같이.repo
s.d/에 있는 각 .repo활성화된
옵션을 설정합니다.enabled = 1
- 리포지토리를 활성화하려면 다음을 수행합니다.
enabled = 0
- 리포지토리를 비활성화하려면 다음을 수행합니다.
선택한
yum-cron
구성 파일의 끝에 새로 생성된 리포지토리 디렉토리를 가리키는 다음 옵션을 추가합니다.reposdir=/path/to/new/reposdir
9.7.4. YUM-cron 설정 테스트
예약된 yum-cron
작업을 기다리지 않고 yum-cron
설정을 테스트하려면 다음을 수행합니다.
선택된
yum-cron
구성 파일을 엽니다./etc/yum/yum-cron.conf
- 일별 작업을 위한 것입니다.
/etc/yum/yum-cron-hourly.conf
- 시간별 작업의 경우.
선택한 구성 파일에서
random_sleep
옵션을 다음과 같이 설정합니다.random_sleep = 0
구성 파일을 실행합니다.
# yum-cron /etc/yum/yum-cron.conf # yum-cron /etc/yum/yum-cron-hourly.conf
9.7.5. YUM-cron 메시지 비활성화
yum-cron
메시지는 완전히 비활성화할 수 없지만 우선 순위가 중요한 메시지로만 제한할 수 있습니다. 메시지를 제한하려면 다음을 수행합니다.
선택된
yum-cron
구성 파일을 엽니다./etc/yum/yum-cron.conf
- 일별 작업을 위한 것입니다.
/etc/yum/yum-cron-hourly.conf
- 시간별 작업의 경우.
구성 파일의
[base]
섹션에 다음 옵션을 설정합니다.debuglevel = -4
9.7.6. 패키지 자동 정리
yum-cron
서비스는 yum clean all
명령과 유사한 패키지를 제거하는 데 구성 옵션을 지원하지 않습니다. 패키지를 자동으로 정리하려면 실행 가능한 쉘 스크립트로 cron 작업을 생성할 수 있습니다.
다음을 포함하는
/etc/cron.daily/
디렉터리에 쉘 스크립트를 생성합니다.#!/bin/sh yum clean all
스크립트를 실행 가능하게 만듭니다.
# chmod +x /etc/cron.daily/script-name.sh
9.8. 추가 리소스
Red Hat Enterprise Linux에서 소프트웨어 패키지를 관리하는 방법에 대한 자세한 내용은 아래 나열된 리소스를 참조하십시오.
설치된 문서
-
yum
(8) - yum 명령줄 유틸리티의 도움말 페이지는 지원되는 옵션 및 명령의 전체 목록을 제공합니다. -
yumdb
(8) -yumdb
명령 줄 유틸리티 문서의 도움말 페이지에서 이 도구를 사용하여 쿼리하고 필요한 경우 yum 데이터베이스를 변경하는 방법을 설명합니다. -
yum.conf
(5) -yum.conf
문서의 수동 페이지 사용 가능 -
yum-utils
(1) -yum-utils
목록이라는 수동 페이지 및 yum 구성 관리, 리포지토리 조작 및 yum 데이터베이스 작업을 위한 추가 유틸리티를 간략하게 설명합니다.
온라인 리소스
- yum Guides - 프로젝트 홈 페이지의 YUM 가이드 페이지에서 추가 설명서에 대한 링크를 제공합니다.
- Red Hat 고객 포털 랩 - Red Hat 고객 포털 랩에는 "Yum Repository Configuration Helper"가 포함되어 있습니다.
예를 들면 다음과 같습니다.
-
6장. 권한 확보
su
및sudo
명령을 사용하여 관리 권한을 얻는 방법에 대해 설명합니다.
IV 부. 인프라 서비스
이 부분에서는 서비스 및 데몬을 구성하고 Red Hat Enterprise Linux 머신에 대한 원격 액세스를 활성화하는 방법에 대한 정보를 제공합니다.
10장. systemd를 사용하여 서비스 관리
10.1. systemd 소개
systemd 는 Linux 운영 체제용 시스템 및 서비스 관리자입니다. 이는 SysV init 스크립트와 역호환되도록 설계되었으며 부팅 시 시스템 서비스의 병렬 시작, 필요에 따라 데몬 활성화 또는 종속성 기반 서비스 제어 논리와 같은 여러 기능을 제공합니다. Red Hat Enterprise Linux 7에서 systemd는 Upstart를 기본 init 시스템으로 대체합니다.
systemd에는 systemd 단위 의 개념이 도입되었습니다. 이러한 단위는 표 10.2. “systemd 장치 파일 위치” 에 나열된 디렉터리 중 하나에 있는 단위 구성 파일로 표현되며 시스템 서비스, 수신 대기 소켓 및 init 시스템과 관련된 기타 오브젝트에 대한 정보를 캡슐화합니다. 사용 가능한 systemd 장치 유형 전체 목록은 표 10.1. “사용 가능한 systemd 장치 유형” 을 참조하십시오.
단위 유형 | 파일 확장자 | 설명 |
---|---|---|
서비스 단위 |
| 시스템 서비스. |
대상 단위 |
| systemd 장치 그룹입니다. |
자동 마운트 단위 |
| 파일 시스템 자동 마운트 지점. |
장치 단위 |
| 커널에서 인식한 장치 파일입니다. |
마운트 단위 |
| 파일 시스템 마운트 지점. |
경로 단위 |
| 파일 시스템의 파일 또는 디렉터리. |
범위 단위 |
| 외부에서 생성된 프로세스. |
슬라이스 단위 |
| 시스템 프로세스를 관리하는 계층적으로 구성된 단위 그룹입니다. |
스냅샷 단위 |
| 저장된 systemd 관리자 상태입니다. |
소켓 단위 |
| 프로세스 간 통신 소켓입니다. |
스왑 장치 |
| 스왑 장치 또는 스왑 파일. |
타이머 장치 |
| systemd 타이머. |
디렉터리 | 설명 |
---|---|
| 설치된 RPM 패키지와 함께 배포되는 systemd 장치 파일입니다. |
| 런타임에 생성된 systemd 장치 파일입니다. 이 디렉터리는 설치된 서비스 장치 파일이 있는 디렉터리보다 우선합니다. |
|
|
system.conf를 사용하여 기본 systemd 구성 덮어쓰기
systemd의 기본 구성은 컴파일 중에 정의되고 /etc/systemd/system.conf
의 systemd 구성 파일에서 찾을 수 있습니다. 이러한 기본값에서 벗어나지 않도록 하려면 이 파일을 사용하여 systemd 단위에 대해 선택된 기본값을 전역적으로 덮어씁니다.
예를 들어 90초로 설정된 제한 시간 제한의 기본값을 재정의하려면 DefaultTimeoutStartSec
매개변수를 사용하여 필요한 값을 초 단위로 입력합니다.
DefaultTimeoutStartSec=required value
자세한 내용은 예 10.21. “제한 시간 제한 변경” 참조하십시오.
10.1.1. 주요 기능
Red Hat Enterprise Linux 7에서 systemd 시스템 및 서비스 관리자는 다음과 같은 주요 기능을 제공합니다.
소켓 기반 활성화 - 부팅 시 systemd는 이러한 유형의 활성화를 지원하는 모든 시스템 서비스에 대해 수신 대기 소켓을 생성하고 시작된 즉시 소켓을 이러한 서비스에 전달합니다. 이를 통해 systemd는 병렬로 서비스를 시작할 수 있을 뿐만 아니라 서비스를 시작할 수 있을 뿐만 아니라 사용할 수 없는 동안 전송된 메시지를 손실하지 않고도 서비스를 다시 시작할 수 있습니다. 해당 소켓은 액세스 가능하며 모든 메시지가 큐에 추가됩니다.
systemd는 소켓 기반 활성화에 소켓 유닛 을 사용합니다.
- 버스 기반 활성화 - 프로세스 간 통신에 D-Bus를 사용하는 시스템 서비스는 클라이언트 애플리케이션이 해당 애플리케이션과 통신을 시도할 때 처음으로 요청 시 시작할 수 있습니다. systemd는 버스 기반 활성화를 위해 D-Bus 서비스 파일을 사용합니다.
- 장치 기반 활성화 - 특정 유형의 하드웨어가 연결되거나 사용 가능하게 되면 장치 기반 활성화를 지원하는 시스템 서비스를 필요에 따라 시작할 수 있습니다. systemd는 장치 기반 활성화를 위해 장치 장치를 사용합니다.
- 경로 기반 활성화 - 특정 파일 또는 디렉터리가 해당 상태를 변경할 때 경로 기반 활성화를 지원하는 시스템 서비스를 요청 시 시작할 수 있습니다. systemd는 경로 기반 활성화에 경로 유닛 을 사용합니다.
- 마운트 및 자동 마운트 지점 관리 - Systemd 모니터 및 마운트 및 자동 마운트를 관리합니다. systemd는 마운트 지점에 마운트 장치를 사용하고 자동 마운트 지점에 자동 마운트 장치를 사용합니다.
- 공격적 병렬화 - 소켓 기반 활성화를 사용하기 때문에 systemd는 모든 청취 소켓이 제자리에 있는 즉시 시스템 서비스를 병렬로 시작할 수 있습니다. 온 디맨드 활성화를 지원하는 시스템 서비스와 함께 병렬 활성화는 시스템 부팅에 필요한 시간을 크게 줄입니다.
- 트랜잭션 단위 활성화 논리 - 단위를 활성화 또는 비활성화하기 전에 systemd는 종속성을 계산하고, 임시 트랜잭션을 생성하며, 이 트랜잭션이 일관되게 적용되는지 확인합니다. 트랜잭션이 일관성이 없는 경우 systemd는 오류를 보고하기 전에 자동으로 해당 트랜잭션을 수정하고 필수가 아닌 작업을 제거합니다.
- SysV init과 이전 버전과의 호환성 - Systemd는 Linux 표준 기본 코어 사양에 설명된 대로 SysV init 스크립트를 지원하므로 systemd 서비스 유닛으로의 업그레이드 경로가 쉬워집니다.
10.1.2. 호환성 변경
systemd 시스템 및 서비스 관리자는 SysV init 및 Upstart와 대부분 호환되도록 설계되었습니다. 다음은 Red Hat Enterprise Linux 시스템의 이전 주요 릴리스와 관련하여 가장 주목할 만한 호환성 변경 사항입니다.
systemd는 실행 수준을 제한적으로 지원합니다. 이러한 실행 수준으로 직접 매핑할 수 있는 여러 대상 장치를 제공합니다. 호환성을 위해 이전
실행 수준
명령도 함께 배포됩니다. 그러나 모든 systemd 대상을 실행 수준 수준에 직접 매핑할 수 있는 것은 아니며, 결과적으로 이 명령은N
을 반환하여 알 수 없는 실행 수준을 나타낼 수 있습니다. 가능하면level 명령을 사용하지 않는 것이 좋습니다.systemd 대상 및 실행 수준 수준 비교에 대한 자세한 내용은 10.3절. “systemd 대상 작업” 을 참조하십시오.
systemctl
유틸리티는 사용자 지정 명령을 지원하지 않습니다.start
,stop
및status
와 같은 표준 명령 외에도 SysV init 스크립트 작성자는 추가 기능을 제공하기 위해 다수의 임의 명령에 대한 지원을 구현할 수 있었습니다. 예를 들어 Red Hat Enterprise Linux 6에서iptables
에 대한 init 스크립트를panic
명령으로 실행할 수 있으므로 패닉 모드를 즉시 활성화하고 시스템을 재구성하여 들어오는 모든 패킷을 삭제할 수 있습니다. systemd에서 지원되지 않으며systemctl
은 문서화된 명령만 허용합니다.systemctl
유틸리티 및 이전서비스
유틸리티와의 비교에 대한 자세한 내용은 10.2절. “시스템 서비스 관리” 을 참조하십시오.-
systemctl
유틸리티는 systemd에서 시작하지 않은 서비스와 통신하지 않습니다. systemd는 시스템 서비스를 시작할 때 기본 프로세스의 ID를 저장하여 해당 서비스를 추적합니다. 그런 다음systemctl
유틸리티는 이 PID를 사용하여 서비스를 쿼리하고 관리합니다. 결과적으로 사용자가 명령줄에서 직접 특정 데몬을 시작하면systemctl
은 현재 상태를 확인하거나 중지할 수 없습니다. -
systemd는 실행 중인 서비스만 중지합니다. 이전 버전에서는 종료 시퀀스가 시작될 때 Red Hat Enterprise Linux 6 및 시스템의 이전 릴리스에서는
/etc/rc0.d/
디렉터리에 있는 심볼릭 링크를 사용하여 상태와 관계없이 사용 가능한 모든 시스템 서비스를 중지했습니다. systemd에서는 실행 중인 서비스만 종료 시 중지됩니다. -
시스템 서비스는 표준 입력 스트림에서 읽을 수 없습니다. systemd가 서비스를 시작할 때 표준 입력을
/dev/null
에 연결하여 사용자와의 상호 작용을 방지합니다. -
시스템 서비스는 호출된 사용자 및 해당 세션에서 어떠한 컨텍스트(예:
HOME
및PATH
환경 변수)를 상속하지 않습니다. 각 서비스는 명확한 실행 컨텍스트에서 실행됩니다. - SysV init 스크립트를 로드할 때 systemd는 Linux 표준 기본(LSB) 헤더로 인코딩된 종속성 정보를 읽고 런타임에 해석합니다.
- 서비스 유닛에 대한 모든 작업에는 기본 시간 초과가 5분으로 되어 시스템이 중단되는 것을 방지할 수 있습니다. 이 값은 initscripts에서 생성된 서비스에 하드 코딩되며 변경할 수 없습니다. 그러나 개별 구성 파일을 사용하여 서비스당 시간 초과 값을 지정할 수 있습니다. 예 10.21. “제한 시간 제한 변경”
systemd와 함께 도입된 호환성 변경 사항의 자세한 목록은 Red Hat Enterprise Linux 7 마이그레이션 플래닝 가이드 를 참조하십시오.
10.2. 시스템 서비스 관리
전문 지식을 확장하려면 Red Hat System Administration II(RH 442) 교육 과정에도 관심이 있을 수 있습니다.
SysV init 또는 Upstart와 함께 배포된 이전 버전의 Red Hat Enterprise Linux는 /etc/rc.d/init.d/
디렉터리에 있는 init 스크립트 를 사용했습니다. 이러한 init 스크립트는 일반적으로 Bash로 작성되었으며 시스템 관리자가 시스템의 서비스 및 데몬 상태를 제어할 수 있습니다. Red Hat Enterprise Linux 7에서는 이러한 init 스크립트가 서비스 단위로 교체되었습니다.
서비스 단위는 .service
파일 확장자로 종료되고 init 스크립트와 유사한 목적을 제공합니다. 시스템 서비스를 확인, 시작, 중지, 다시 시작, 활성화 또는 비활성화하려면 이 섹션의 표 10.3. “systemctl과 서비스 utility 비교”, 표 10.4. “systemctl과 chkconfig utility 비교” 및 기타에 설명된 대로 systemctl
명령을 사용합니다. service
및 chkconfig
명령은 계속 시스템에서 사용할 수 있으며 예상대로 작동하지만 호환성상의 이유로만 포함되어 피해야 합니다.
service | systemctl | 설명 |
---|---|---|
|
| 서비스를 시작합니다. |
|
| 서비스를 중지합니다. |
|
| 서비스를 다시 시작합니다. |
|
| 실행 중인 경우에만 서비스를 다시 시작합니다. |
|
| 구성을 다시 로드합니다. |
|
| 서비스가 실행 중인지 확인합니다. |
|
| 모든 서비스의 상태를 표시합니다. |
chkconfig | systemctl | 설명 |
---|---|---|
|
| 서비스를 활성화합니다. |
|
| 서비스를 비활성화합니다. |
|
| 서비스가 활성화되어 있는지 확인합니다. |
|
| 모든 서비스를 나열하고 활성화되어 있는지 확인합니다. |
|
| 지정된 유닛 전에 시작하도록 정렬된 서비스를 나열합니다. |
|
| 지정된 유닛 후에 시작하도록 정렬된 서비스를 나열합니다. |
서비스 단위 지정
명확성을 위해 이 섹션의 모든 명령 예제는 .service
파일 확장자와 함께 전체 단위 이름을 사용합니다. 예를 들면 다음과 같습니다.
~]# systemctl stop nfs-server.service
그러나 파일 확장자는 생략할 수 있습니다. 이 경우 systemctl
유틸리티는 인수가 서비스 단위라고 가정합니다. 다음 명령은 위의 명령과 동일합니다.
~]# systemctl stop nfs-server
또한 일부 유닛에는 별칭 이름이 있습니다. 이러한 이름은 실제 장치 이름 대신 사용할 수 있는 유닛보다 짧은 이름을 가질 수 있습니다. 특정 유닛에 사용할 수 있는 모든 별칭을 찾으려면 다음을 사용합니다.
~]# systemctl show nfs-server.service -p Names
chroot 환경에서 systemctl 동작
chroot
명령을 사용하여 루트 디렉터리를 변경하는 경우 대부분의 systemctl
명령은 모든 작업 수행을 거부합니다. 그 이유는 systemd
프로세스와 chroot
명령을 사용한 사용자에게 파일 시스템에 대한 동일한 보기가 없기 때문입니다. 예를 들어 Kickstart
파일에서 systemctl
을 호출할 때 이러한 상황이 발생합니다.
이 예외는 systemctl enable
및 systemctl disable
명령과 같은 단위 파일 명령입니다. 이러한 명령은 실행 중인 시스템이 필요하지 않으며 실행 중인 프로세스에는 영향을 미치지 않지만 장치 파일에 영향을 미칩니다. 따라서 chroot
환경에서도 이러한 명령을 실행할 수 있습니다. 예를 들어 /srv/website1/
디렉터리의 시스템에서 httpd
서비스를 활성화하려면 다음을 수행합니다.
~]# chroot /srv/website1 ~]# systemctl enable httpd.service Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service, pointing to /usr/lib/systemd/system/httpd.service.
10.2.1. 서비스 나열
현재 로드된 서비스 유닛을 모두 나열하려면 쉘 프롬프트에서 다음을 입력합니다.
systemctl list-units --type service
각 서비스 유닛 파일에 대해 이 명령은 전체 이름(UNIT
)을 표시하고 단위 파일이 로드되었는지 여부(LOAD
), 높은 수준의( started ) 및 하위 수준(SUB
) 단위 파일 활성화 상태, 짧은 설명(DESCRIPTION
)을 표시합니다.
기본적으로 systemctl list-units
명령은 활성 유닛만 표시합니다. 상태에 관계없이 로드된 유닛을 모두 나열하려면 --all
또는 -a
명령줄 옵션을 사용하여 이 명령을 실행하십시오.
systemctl list-units --type service --all
사용 가능한 모든 서비스 유닛을 나열하여 활성화되어 있는지 확인할 수도 있습니다. 이렇게 하려면 다음을 입력합니다.
systemctl list-unit-files --type service
각 서비스 유닛에 대해 이 명령은 전체 이름(UNIT FILE
)을 표시하고 서비스 유닛이 활성화되었는지 여부(STATE
)가 있는지 여부가 표시됩니다. 개별 서비스 유닛의 상태를 결정하는 방법에 대한 자세한 내용은 10.2.2절. “서비스 상태 표시” 을 참조하십시오.
예 10.1. 서비스 나열
현재 로드된 서비스 유닛을 모두 나열하려면 다음 명령을 실행합니다.
~]$ systemctl list-units --type service
UNIT LOAD ACTIVE SUB DESCRIPTION
abrt-ccpp.service loaded active exited Install ABRT coredump hook
abrt-oops.service loaded active running ABRT kernel log watcher
abrt-vmcore.service loaded active exited Harvest vmcores for ABRT
abrt-xorg.service loaded active running ABRT Xorg log watcher
abrtd.service loaded active running ABRT Automated Bug Reporting Tool
...
systemd-vconsole-setup.service loaded active exited Setup Virtual Console
tog-pegasus.service loaded active running OpenPegasus CIM Server
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
46 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'
설치된 모든 서비스 장치 파일을 나열하여 활성화되어 있는지 확인하려면 다음을 입력합니다.
~]$ systemctl list-unit-files --type service UNIT FILE STATE abrt-ccpp.service enabled abrt-oops.service enabled abrt-vmcore.service enabled abrt-xorg.service enabled abrtd.service enabled ... wpa_supplicant.service disabled ypbind.service disabled 208 unit files listed.
10.2.2. 서비스 상태 표시
시스템 서비스에 해당하는 서비스 유닛에 대한 자세한 정보를 표시하려면 쉘 프롬프트에서 다음을 입력합니다.
systemctl status name.service
name 을 검사할 서비스 유닛의 이름으로 바꿉니다(예: gdm
). 이 명령은 선택한 서비스 단위의 이름, 간단한 설명, 표 10.5. “사용 가능한 서비스 단위 정보” 에 설명된 하나 이상의 필드, root
사용자가 실행하는 경우 가장 최근 로그 항목도 표시합니다.
필드 | 설명 |
---|---|
| 서비스 유닛이 로드되었는지 여부, 단위 파일의 절대 경로 및 장치가 활성화되었는지 여부를 나타냅니다. |
| 서비스 유닛이 실행 중인지 여부 및 타임스탬프를 제공합니다. |
| 해당 시스템 서비스의 PID와 해당 이름. |
| 해당 시스템 서비스에 대한 추가 정보입니다. |
| 관련 프로세스에 대한 추가 정보. |
| 관련 제어 그룹(cgroups)에 대한 추가 정보. |
특정 서비스 장치가 실행 중인지 확인하려면 다음 명령을 실행합니다.
systemctl is-active name.service
마찬가지로 특정 서비스 장치가 활성화되어 있는지 여부를 확인하려면 다음을 입력합니다.
systemctl is-enabled name.service
systemctl is-active
및 systemctl is-enabled
는 모두 지정된 서비스 장치가 실행 중이거나 활성화되어 있는 경우 종료 상태 0
을 반환합니다. 현재 로드된 모든 서비스 단위를 나열하는 방법에 대한 자세한 내용은 10.2.1절. “서비스 나열” 을 참조하십시오.
예 10.2. 서비스 상태 표시
GNOME Display Manager의 서비스 단위는 gdm.service
라고 합니다. 이 서비스 장치의 현재 상태를 확인하려면 쉘 프롬프트에서 다음을 입력합니다.
~]# systemctl status gdm.service gdm.service - GNOME Display Manager Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled) Active: active (running) since Thu 2013-10-17 17:31:23 CEST; 5min ago Main PID: 1029 (gdm) CGroup: /system.slice/gdm.service ├─1029 /usr/sbin/gdm ├─1037 /usr/libexec/gdm-simple-slave --display-id /org/gno... └─1047 /usr/bin/Xorg :0 -background none -verbose -auth /r... Oct 17 17:31:23 localhost systemd[1]: Started GNOME Display Manager.
예 10.3. 서비스 시작하기 전에 주문된 서비스 표시
지정된 서비스 이전에 정렬된 서비스를 확인하려면 쉘 프롬프트에서 다음을 입력합니다.
~]# systemctl list-dependencies --after gdm.service gdm.service ├─dbus.socket ├─getty@tty1.service ├─livesys.service ├─plymouth-quit.service ├─system.slice ├─systemd-journald.socket ├─systemd-user-sessions.service └─basic.target [output truncated]
예 10.4. 서비스 종료 후 서비스에 주문한 서비스 표시
지정된 서비스 후에 시작하도록 정렬된 서비스를 확인하려면 쉘 프롬프트에서 다음을 입력합니다.
~]# systemctl list-dependencies --before gdm.service gdm.service ├─dracut-shutdown.service ├─graphical.target │ ├─systemd-readahead-done.service │ ├─systemd-readahead-done.timer │ └─systemd-update-utmp-runlevel.service └─shutdown.target ├─systemd-reboot.service └─final.target └─systemd-reboot.service
10.2.3. 서비스 시작
시스템 서비스에 해당하는 서비스 장치를 시작하려면 root
로 쉘 프롬프트에 다음을 입력합니다.
systemctl start name.service
시작할 서비스 유닛의 이름으로 이름을 바꿉니다(예: gdm
). 이 명령은 현재 세션에서 선택한 서비스 유닛을 시작합니다. 부팅 시 서비스 유닛을 시작하는 방법에 대한 자세한 내용은 10.2.6절. “서비스 활성화” 을 참조하십시오. 특정 서비스 유닛의 상태를 결정하는 방법에 대한 자세한 내용은 10.2.2절. “서비스 상태 표시” 을 참조하십시오.
예 10.5. 서비스 시작
Apache HTTP 서버의 서비스 단위는 httpd.service
라고 합니다. 이 서비스 장치를 활성화하고 현재 세션에서 httpd
데몬을 시작하려면 root
로 다음 명령을 실행합니다.
~]# systemctl start httpd.service
10.2.4. 서비스 중지
시스템 서비스에 해당하는 서비스 장치를 중지하려면 쉘 프롬프트에 root
로 다음을 입력합니다.
systemctl stop name.service
중지하려는 서비스 유닛의 이름으로 이름을 바꿉니다(예: bluetooth
). 이 명령은 현재 세션에서 선택한 서비스 유닛을 중지합니다. 서비스 유닛을 비활성화하고 부팅 시 시작되지 않게 하는 방법에 대한 자세한 내용은 10.2.7절. “서비스 비활성화” 을 참조하십시오. 특정 서비스 유닛의 상태를 결정하는 방법에 대한 자세한 내용은 10.2.2절. “서비스 상태 표시” 을 참조하십시오.
예 10.6. 서비스 중지
bluetoothd
데몬의 서비스 단위 이름은 bluetooth.service
입니다. 이 서비스 유닛을 비활성화하고 현재 세션에서 bluetoothd
데몬을 중지하려면 root
로 다음 명령을 실행합니다.
~]# systemctl stop bluetooth.service
10.2.5. 서비스 다시 시작
시스템 서비스에 해당하는 서비스 장치를 다시 시작하려면 root
로 쉘 프롬프트에 다음을 입력합니다.
systemctl restart name.service
이름을 재시작할 서비스 유닛의 이름으로 바꿉니다(예: httpd
). 이 명령은 현재 세션에서 선택한 서비스 장치를 중지하고 즉시 다시 시작합니다. 중요한 점은 선택한 서비스 장치가 실행되고 있지 않으면 이 명령도 시작합니다. 해당 서비스가 이미 실행 중인 경우에만 서비스 장치를 재시작하도록 systemd에 지시하려면 root
로 다음 명령을 실행합니다.
systemctl try-restart name.service
또한 특정 시스템 서비스를 사용하면 실행을 중단하지 않고 구성을 다시 로드할 수 있습니다. 이 작업을 수행하려면 root
로 입력합니다.
systemctl reload name.service
이 기능을 지원하지 않는 시스템 서비스는 이 명령을 모두 무시합니다. 편의를 위해 systemctl
명령은 서비스를 다시 시작하는 reload-or-restart
및 reload-or-try-restart
명령도 지원합니다. 특정 서비스 유닛의 상태를 결정하는 방법에 대한 자세한 내용은 10.2.2절. “서비스 상태 표시” 을 참조하십시오.
예 10.7. 서비스 다시 시작
사용자가 불필요한 오류 메시지나 부분적으로 렌더링된 웹 페이지가 발생하지 않도록 하려면 Apache HTTP Server를 사용하여 구성을 다시 시작하고 적극적으로 처리된 요청을 중단하지 않고도 해당 구성을 편집하고 다시 로드할 수 있습니다. 이렇게 하려면 쉘 프롬프트에서 root
로 다음을 입력합니다.
~]# systemctl reload httpd.service
10.2.6. 서비스 활성화
부팅 시 자동으로 시스템 서비스에 해당하는 서비스 장치를 구성하려면 쉘 프롬프트에서 root
로 다음을 입력합니다.
systemctl enable name.service
name 을 활성화할 서비스 유닛의 이름으로 바꿉니다(예: httpd
). 이 명령은 선택한 서비스 장치의 [Install]
섹션을 읽고 /etc/systemd/system
파일에 대한 적절한 심볼릭 링크를 생성합니다. 그러나 이 명령은 이미 존재하는 링크를 다시 작성하지 않습니다. 심볼릭 링크가 다시 생성되었는지 확인하려면 /
디렉터리에 있는 /usr/lib/systemd/system/name.serviceroot
로 다음 명령을 사용하십시오.
systemctl reenable name.service
이 명령은 선택한 서비스 장치를 비활성화하고 즉시 다시 활성화합니다. 특정 서비스 유닛이 부팅 시 시작되도록 활성화되었는지 확인하는 방법에 대한 자세한 내용은 10.2.2절. “서비스 상태 표시” 을 참조하십시오. 현재 세션에서 서비스를 시작하는 방법에 대한 자세한 내용은 10.2.3절. “서비스 시작” 을 참조하십시오.
예 10.8. 서비스 활성화
부팅 시 자동으로 시작하도록 Apache HTTP Server를 구성하려면 root
로 다음 명령을 실행합니다.
~]# systemctl enable httpd.service Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
10.2.7. 서비스 비활성화
부팅 시 시스템 서비스에 해당하는 서비스 장치가 자동으로 시작되지 않도록 하려면 쉘 프롬프트에서 root
로 다음을 입력합니다.
systemctl disable name.service
비활성화하려는 서비스 유닛의 이름으로 이름을 바꿉니다(예: bluetooth
). 이 명령은 선택한 서비스 장치의 [Install]
섹션을 읽고 /etc/systemd/system
파일에 대한 적절한 심볼릭 링크를 제거합니다. 또한 서비스 유닛을 마스킹하여 수동으로 또는 다른 서비스에 의해 시작되지 않도록 할 수 있습니다. 이렇게 하려면 /
디렉터리 및 하위 디렉터리의 /usr/lib/systemd/system/name.serviceroot
로 다음 명령을 실행하십시오.
systemctl mask name.service
이 명령은 /etc/systemd/system/name.service
파일을 /dev/null
에 대한 심볼릭 링크로 대체하여 systemd에 액세스할 수 없는 실제 장치 파일을 렌더링합니다. 이 작업을 취소하고 서비스 유닛을 마스크 해제하려면 root
로 를 입력합니다.
systemctl unmask name.service
특정 서비스 유닛이 부팅 시 시작되도록 활성화되었는지 확인하는 방법에 대한 자세한 내용은 10.2.2절. “서비스 상태 표시” 을 참조하십시오. 현재 세션에서 서비스를 중지하는 방법에 대한 자세한 내용은 10.2.4절. “서비스 중지” 을 참조하십시오.
예 10.9. 서비스 비활성화
예 10.6. “서비스 중지” 현재 세션에서 bluetooth.service
유닛을 중지하는 방법을 보여줍니다. 이 서비스 장치가 부팅 시 시작되지 않도록 하려면 쉘 프롬프트에 root
로 다음을 입력합니다.
~]# systemctl disable bluetooth.service Removed symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service. Removed symlink /etc/systemd/system/dbus-org.bluez.service.
10.2.8. 서비스 충돌 시작
systemd 에서 서비스 간 양수 및 음수 종속성이 있습니다. 특정 서비스를 시작하려면 하나 이상의 다른 서비스(positive dependency)를 시작하거나 하나 이상의 서비스(negative 종속성)를 중지해야 할 수 있습니다.
새 서비스를 시작하려고 하면 systemd 는 모든 종속성을 자동으로 해결합니다. 이 작업은 사용자에게 명시적인 알림 없이 수행됩니다. 이미 서비스를 실행하고 음수 종속성으로 다른 서비스를 시작하려고 하면 첫 번째 서비스가 자동으로 중지됩니다.
예를 들어 postfix
서비스를 실행 중이고 sendmail
서비스를 시작하려고 하면 systemd 는 먼저 postfix
를 자동으로 중지합니다. 이러한 두 서비스가 충돌하며 동일한 포트에서 실행할 수 없기 때문입니다.
10.3. systemd 대상 작업
SysV init 또는 Upstart와 함께 배포된 이전 버전의 Red Hat Enterprise Linux는 특정 작업 모드를 나타내는 사전 정의된 실행 수준을 구현했습니다. 이러한 실행 수준으로 인해 0에서 6까지 번호가 지정되었으며 시스템 관리자가 특정 실행 수준을 사용하도록 설정한 경우 실행할 시스템 서비스에 의해 정의되었습니다. Red Hat Enterprise Linux 7에서는 실행 수준이라는 개념이 systemd 대상으로 교체되었습니다.
systemd 대상은 대상 유닛으로 표시됩니다. 대상 단위는 . target 파일
확장자로 종료되고 유일한 목적은 종속 항목 체인을 통해 다른 systemd 유닛을 함께 그룹화하는 것입니다. 예를 들어 그래픽 세션을 시작하는 데 사용되는 graphical.target
장치는 GNOME Display Manager(gdm.service ) 또는 계정 서비스(accounts-daemon
)와 같은 시스템 서비스를 시작하고, .service
다중 사용자.target
유닛을 활성화합니다. 마찬가지로 multi-user.target
장치는 NetworkManager(NetworkManager.service
) 또는 D-Bus(dbus.service
)와 같은 다른 필수 시스템 서비스를 시작하고 basic.target
이라는 다른 대상 장치를 활성화합니다.
Red Hat Enterprise Linux 7은 이 시스템의 이전 릴리스의 표준 실행 수준 세트와 비슷하거나 더 적은 사전 정의된 대상과 함께 배포됩니다. 호환성의 이유로 SysV 실행 수준을 직접 매핑하는 이러한 대상에 대한 별칭도 제공합니다. 표 10.6. “systemd 대상과 SysV Runlevels 비교” 에서는 SysV 실행 수준 및 해당 systemd 대상의 전체 목록을 제공합니다.
실행 수준 | 대상 단위 | 설명 |
---|---|---|
|
| 시스템을 종료하고 전원을 끕니다. |
|
| 복구 쉘을 설정합니다. |
|
| 그래픽이 아닌 다중 사용자 시스템을 설정합니다. |
|
| 그래픽이 아닌 다중 사용자 시스템을 설정합니다. |
|
| 그래픽이 아닌 다중 사용자 시스템을 설정합니다. |
|
| 그래픽 다중 사용자 시스템을 설정합니다. |
|
| 시스템을 종료하고 재부팅합니다. |
systemd 대상을 확인, 변경 또는 구성하려면 표 10.7. “systemctl과 SysV init 명령 비교” 및 아래 섹션에서 systemctl
유틸리티를 사용합니다. 실행 수준
및 telinit
명령은 계속 시스템에서 사용할 수 있으며 예상대로 작동하지만 호환성상의 이유로만 포함되어 있어야 합니다.
이전 명령 | 새 명령 | 설명 |
---|---|---|
|
| 현재 로드된 대상 유닛을 나열합니다. |
|
| 현재 대상을 변경합니다. |
10.3.1. 기본 대상 보기
기본적으로 사용되는 대상 장치를 확인하려면 다음 명령을 실행합니다.
systemctl get-default
이 명령은 /etc/systemd/system/default.target
에 있는 심볼릭 링크를 확인하고 결과를 표시합니다. 기본 대상을 변경하는 방법에 대한 자세한 내용은 10.3.3절. “기본 대상 변경” 을 참조하십시오. 현재 로드된 모든 대상 장치를 나열하는 방법에 대한 자세한 내용은 10.3.2절. “현재 대상 보기” 을 참조하십시오.
예 10.10. 기본 대상 보기
기본 대상 장치를 표시하려면 다음을 입력합니다.
~]$ systemctl get-default
graphical.target
10.3.2. 현재 대상 보기
현재 로드된 모든 대상 장치를 나열하려면 쉘 프롬프트에서 다음 명령을 입력합니다.
systemctl list-units --type target
각 대상 유닛에 대해 이 명령은 전체 이름(UNIT
)을 표시하고, 유닛이 로드되었는지 여부(LOAD
), 높은 레벨( started) 및 하위 수준(SUB
) 단위 활성화 상태, 짧은 설명 (DESCRIPTION
)을 표시합니다.
기본적으로 systemctl list-units
명령은 활성 유닛만 표시합니다. 상태에 관계없이 로드된 유닛을 모두 나열하려면 --all
또는 -a
명령줄 옵션을 사용하여 이 명령을 실행하십시오.
systemctl list-units --type target --all
기본 대상을 표시하는 방법에 대한 자세한 내용은 10.3.1절. “기본 대상 보기” 을 참조하십시오. 현재 대상을 변경하는 방법에 대한 자세한 내용은 10.3.4절. “현재 대상 변경” 을 참조하십시오.
예 10.11. 현재 대상 보기
현재 로드된 모든 대상 장치를 나열하려면 다음 명령을 실행합니다.
~]$ systemctl list-units --type target
UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
cryptsetup.target loaded active active Encrypted Volumes
getty.target loaded active active Login Prompts
graphical.target loaded active active Graphical Interface
local-fs-pre.target loaded active active Local File Systems (Pre)
local-fs.target loaded active active Local File Systems
multi-user.target loaded active active Multi-User System
network.target loaded active active Network
paths.target loaded active active Paths
remote-fs.target loaded active active Remote File Systems
sockets.target loaded active active Sockets
sound.target loaded active active Sound Card
spice-vdagentd.target loaded active active Agent daemon for Spice guests
swap.target loaded active active Swap
sysinit.target loaded active active System Initialization
time-sync.target loaded active active System Time Synchronized
timers.target loaded active active Timers
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
17 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
10.3.3. 기본 대상 변경
기본적으로 다른 대상 장치를 사용하도록 시스템을 구성하려면 쉘 프롬프트에 root
로 다음을 입력합니다.
systemctl set-default name.target
기본적으로 사용할 대상 유닛의 이름으로 이름을 바꿉니다(예: 다중 사용자
). 이 명령은 /etc/systemd/system/default.target
파일을 /usr/lib/systemd/system/name.target
에 대한 심볼릭 링크로 교체합니다. 여기서 name 은 사용하려는 대상 장치의 이름입니다. 현재 대상을 변경하는 방법에 대한 자세한 내용은 10.3.4절. “현재 대상 변경” 을 참조하십시오. 현재 로드된 모든 대상 장치를 나열하는 방법에 대한 자세한 내용은 10.3.2절. “현재 대상 보기” 을 참조하십시오.
예 10.12. 기본 대상 변경
기본적으로 multi-user.target
장치를 사용하도록 시스템을 구성하려면 root
로 다음 명령을 실행합니다.
~]# systemctl set-default multi-user.target rm '/etc/systemd/system/default.target' ln -s '/usr/lib/systemd/system/multi-user.target' '/etc/systemd/system/default.target'
10.3.4. 현재 대상 변경
현재 세션에서 다른 대상 단위로 변경하려면 쉘 프롬프트에 root
로 다음을 입력합니다.
systemctl isolate name.target
name 을 사용하려는 대상 유닛의 이름으로 바꿉니다(예: 다중 사용자
). 이 명령은 name 및 모든 종속 유닛이라는 대상 유닛을 시작하고 다른 모든 장치를 즉시 중지합니다. 기본 대상을 변경하는 방법에 대한 자세한 내용은 10.3.3절. “기본 대상 변경” 을 참조하십시오. 현재 로드된 모든 대상 장치를 나열하는 방법에 대한 자세한 내용은 10.3.2절. “현재 대상 보기” 을 참조하십시오.
예 10.13. 현재 대상 변경
그래픽 사용자 인터페이스를 끄고 현재 세션의 multi-user.target
장치로 변경하려면 root
로 다음 명령을 실행합니다.
~]# systemctl isolate multi-user.target
10.3.5. 복구 모드로 변경
복구 모드는 편리한 단일 사용자 환경을 제공하며 일반적인 부팅 프로세스를 완료할 수 없는 상황에서 시스템을 복구할 수 있습니다. 복구 모드에서는 시스템이 모든 로컬 파일 시스템을 마운트하고 일부 중요한 시스템 서비스를 시작하려고 하지만 네트워크 인터페이스를 활성화하지 않거나 더 많은 사용자가 시스템에 로그인할 수 있도록 합니다. Red Hat Enterprise Linux 7에서 복구 모드는 단일 사용자 모드 와 동일하며 root 암호가 필요합니다.
현재 대상을 변경하고 현재 세션에서 복구 모드로 들어가려면 쉘 프롬프트에 root
로 다음을 입력합니다.
systemctl rescue
이 명령은 systemctl isolate rescue.target
과 유사하지만 현재 시스템에 로그인한 모든 사용자에게 정보 메시지를 보냅니다. systemd가 이 메시지를 전송하지 못하도록 하려면 --no-wall
명령줄 옵션을 사용하여 이 명령을 실행하십시오.
systemctl --no-wall rescue
긴급 모드로 전환하는 방법에 대한 자세한 내용은 10.3.6절. “긴급 모드로 변경” 을 참조하십시오.
예 10.14. 복구 모드로 변경
현재 세션에서 복구 모드로 들어가려면 root
로 다음 명령을 실행합니다.
~]# systemctl rescue Broadcast message from root@localhost on pts/0 (Fri 2013-10-25 18:23:15 CEST): The system is going down to rescue mode NOW!
10.3.6. 긴급 모드로 변경
긴급 모드는 가능한 가장 최소한의 환경을 제공하며 시스템이 복구 모드로 전환되지 않은 경우에도 시스템을 복구할 수 있습니다. 긴급 모드에서는 읽기용으로만 루트 파일 시스템을 마운트하고 다른 로컬 파일 시스템을 마운트하지 않고 네트워크 인터페이스를 활성화하지 않으며 몇 가지 필수 서비스만 시작합니다. Red Hat Enterprise Linux 7의 긴급 모드에서는 루트 암호가 필요합니다.
현재 대상을 변경하고 긴급 모드로 전환하려면 쉘 프롬프트에서 root
로 다음을 입력합니다.
systemctl emergency
이 명령은 systemctl isolate emergency.target
과 유사하지만 현재 시스템에 로그인한 모든 사용자에게 정보 메시지를 보냅니다. systemd가 이 메시지를 전송하지 못하도록 하려면 --no-wall
명령줄 옵션을 사용하여 이 명령을 실행하십시오.
systemctl --no-wall emergency
복구 모드로 전환하는 방법에 대한 자세한 내용은 10.3.5절. “복구 모드로 변경” 을 참조하십시오.
예 10.15. 긴급 모드로 변경
현재 시스템에 로그인한 모든 사용자에게 메시지를 보내지 않고 긴급 모드로 전환하려면 root
로 다음 명령을 실행합니다.
~]# systemctl --no-wall emergency
10.4. 시스템 종료, 일시 중지 및 중단
Red Hat Enterprise Linux 7에서 systemctl
유틸리티는 이전 버전의 Red Hat Enterprise Linux 시스템에서 사용된 여러 전원 관리 명령을 대체합니다. 표 10.8. “systemctl과 Power Management Commands 비교” 에 나열된 명령은 호환성 이유로 시스템에서 계속 사용할 수 있지만 가능한 경우 systemctl
을 사용하는 것이 좋습니다.
이전 명령 | 새 명령 | 설명 |
---|---|---|
|
| 시스템을 중지합니다. |
|
| 시스템의 전원을 끕니다. |
|
| 시스템을 다시 시작합니다. |
|
| 시스템을 일시 중지합니다. |
|
| Hibernates the system을 실행합니다. |
|
| Hibernates를 사용하여 시스템을 일시중지합니다. |
10.4.1. 시스템 종료
systemctl
유틸리티는 시스템 종료 명령을 제공하지만 기존 shutdown
명령도 지원됩니다. shutdown
명령은 systemctl
유틸리티를 호출하여 종료를 수행하지만 시간 인수도 지원한다는 장점이 있습니다. 이는 예약된 유지 관리에 특히 유용하며 사용자가 시스템 종료가 예정된 경고에 반응할 수 있도록 더 많은 시간을 허용합니다. 종료를 취소하는 옵션도 장점이 될 수 있습니다.
systemctl 명령 사용
시스템을 종료하고 머신 전원을 끄려면 쉘 프롬프트에 root
로 다음을 입력합니다.
systemctl poweroff
머신 전원을 끄지 않고 시스템을 종료하고 중지하려면 root
로 다음 명령을 실행합니다.
systemctl halt
기본적으로 이러한 명령 중 하나를 실행하면 systemd에서 현재 시스템에 로그인한 모든 사용자에게 정보 메시지를 보냅니다. systemd가 이 메시지를 전송하지 못하도록 하려면 --no-wall
명령줄 옵션을 사용하여 선택한 명령을 실행합니다. 예를 들면 다음과 같습니다.
systemctl --no-wall poweroff
종료 명령 사용
시스템을 종료하고 특정 시간에 머신을 끄려면 다음 형식으로 root
로 명령을 사용합니다.
shutdown --poweroff hh:mm
여기서 hh:mm 는 24시간 시계 형식의 시간입니다. 새 로그인을 방지하기 위해 시스템을 종료하기 전에 /run/nologin
파일이 5분 후에 생성됩니다. 시간 인수를 사용하면 옵션 메시지인 wall 메시지를 명령에 추가할 수 있습니다.
머신 전원을 끄지 않고 잠시 후 시스템을 종료하고 중지하려면 다음 형식으로 root
로 명령을 사용합니다.
shutdown --halt +m
여기서 +m 은 지연 시간(분)입니다. now
키워드는 +0
의 별칭입니다.
보류 중인 종료는 다음과 같이 root
사용자가 취소할 수 있습니다.
shutdown -c
추가 명령 옵션은 shutdown(8)
매뉴얼 페이지를 참조하십시오.
10.4.2. 시스템 다시 시작
시스템을 다시 시작하려면 root
로 다음 명령을 실행하십시오.
systemctl reboot
기본적으로 이 명령을 실행하면 systemd에서 현재 시스템에 로그인한 모든 사용자에게 정보 메시지를 보냅니다. systemd가 이 메시지를 전송하지 못하도록 하려면 --no-wall
명령줄 옵션을 사용하여 이 명령을 실행하십시오.
systemctl --no-wall reboot
10.4.3. 시스템 일시 중단
시스템을 일시 중지하려면 쉘 프롬프트에 root
로 다음을 입력합니다.
systemctl suspend
이 명령은 시스템 상태를 RAM에 저장하고 RAM 모듈을 제외하고 시스템의 대부분의 장치의 전원을 끕니다. 시스템을 다시 켜면 시스템을 다시 부팅할 필요 없이 RAM에서 해당 상태를 복원합니다. 시스템 상태가 하드 디스크가 아닌 RAM에 저장되기 때문에 시스템을 일시 중지 모드로 복원하는 것은 절전 모드에서 복원하는 것보다 훨씬 빠르지만 결과적으로 시스템 정지 상태도 전원 중단에 취약합니다.
시스템 활성화 방법에 대한 자세한 내용은 10.4.4절. “시스템 장애 조치” 을 참조하십시오.
10.4.4. 시스템 장애 조치
시스템에서 root
로 쉘 프롬프트에서 다음을 입력합니다.
systemctl hibernate
이 명령은 시스템 상태를 하드 디스크 드라이브에 저장하고 시스템의 전원을 끕니다. 시스템을 다시 켜면 시스템을 다시 부팅하지 않고도 저장된 데이터에서 해당 상태를 복원합니다. 시스템 상태가 하드 디스크가 아니라 RAM 디스크에 저장되기 때문에 시스템은 RAM 모듈에 전력을 유지해야 할 필요가 없지만 결과적으로 절전 모드에서 시스템을 복원하는 것은 일시 중지 모드에서 복원하는 것보다 훨씬 느려집니다.
RuntimeClass로 시스템을 일시 중단하려면 root
로 다음 명령을 실행합니다.
systemctl hybrid-sleep
시스템을 일시 중지하는 방법에 대한 자세한 내용은 10.4.3절. “시스템 일시 중단” 을 참조하십시오.
10.5. 원격 시스템에서 systemd 제어
systemd 시스템 및 서비스 관리자를 로컬에서 제어하는 것 외에도 systemctl
유틸리티를 사용하면 SSH 프로토콜을 통해 원격 시스템에서 실행되는 systemd와 상호 작용할 수 있습니다. 원격 시스템의 sshd
서비스가 실행 중인 경우 --host
또는 -H
명령줄 옵션을 사용하여 systemctl
명령을 실행하여 이 머신에 연결할 수 있습니다.
systemctl --host user_name@host_name command
user_name 을 원격 사용자의 이름으로, host_name 을 시스템의 호스트 이름으로, 명령을
위에서 설명한 systemctl
명령 중 하나로 바꿉니다. 선택한 사용자가 SSH 프로토콜을 통해 원격 액세스를 허용하도록 원격 시스템을 구성해야 합니다. SSH 서버를 구성하는 방법에 대한 자세한 내용은 12장. OpenSSH 을 참조하십시오.
예 10.16. 원격 관리
server-01.example.com
이라는 원격 시스템에 root
사용자로 로그인하고 httpd.service
유닛의 현재 상태를 확인하려면 쉘 프롬프트에서 다음을 입력합니다.
~]$ systemctl -H root@server-01.example.com status httpd.service
>>>>>>> systemd unit files -- update
root@server-01.example.com's password:
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled)
Active: active (running) since Fri 2013-11-01 13:58:56 CET; 2h 48min ago
Main PID: 649
Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec"
CGroup: /system.slice/httpd.service
10.6. systemd 장치 파일 생성 및 수정
유닛 파일에는 단위를 설명하고 해당 동작을 정의하는 구성 지시문이 포함되어 있습니다. 백그라운드에서 여러 개의 systemctl
명령이 유닛 파일을 사용하여 작동합니다. 보다 세밀하게 조정하려면 시스템 관리자가 수동으로 장치 파일을 편집하거나 생성해야 합니다. 표 10.2. “systemd 장치 파일 위치” 은 시스템에 장치 파일이 저장되는 세 가지 기본 디렉토리를 나열하며, /etc/systemd/system/
디렉터리는 시스템 관리자가 만들거나 사용자 지정할 수 있도록 /etc/systemd/system/ 디렉터리가 예약되어 있습니다.
단위 파일 이름은 다음과 같습니다.
unit_name.type_extension
여기서 unit_name 은 단위 이름을 나타내고 type_extension 은 단위 유형을 식별하며, 전체 단위 유형 목록은 표 10.1. “사용 가능한 systemd 장치 유형” 을 참조하십시오. 예를 들어 일반적으로 시스템에 sshd.service
및 sshd.socket
장치가 있습니다.
추가 구성 파일을 위해 디렉터리로 장치 파일을 추가할 수 있습니다. 예를 들어 sshd.service
에 사용자 지정 구성 옵션을 추가하려면 sshd.service.d/custom.conf
파일을 생성하고 추가 지시문을 삽입합니다. 구성 디렉터리에 대한 자세한 내용은 10.6.4절. “기존 장치 파일 수정” 을 참조하십시오.
또한 sshd.service.wants/
및 sshd.service.requires/
디렉터리를 생성할 수 있습니다. 이러한 디렉터리에는 sshd
서비스의 종속 항목인 단위 파일에 대한 심볼릭 링크가 포함되어 있습니다. 심볼릭 링크는 [Install] 유닛 파일 옵션 또는 [Unit] 옵션 기반 런타임에 따라 설치 중에 자동으로 생성됩니다( 표 10.11. “중요 [설치] 섹션 옵션”참조하십시오. 표 10.9. “중요 [Unit] 섹션 옵션” 이러한 디렉터리와 심볼릭 링크를 수동으로 생성할 수도 있습니다.
많은 단위 파일 옵션은 장치 파일이 로드될 때 장치 매개 변수로 동적으로 대체되는 와일드카드 문자열이라는 so called 단위 쿼리자를 사용하여 설정할 수 있습니다. 이렇게 하면 인스턴스화된 단위를 생성하기 위한 템플릿으로 사용되는 일반 장치 파일을 생성할 수 있습니다. 자세한 내용은 10.6.5절. “인스턴스화된 유닛으로 작업” 을 참조하십시오.
10.6.1. 단위 파일 구조 이해
단위 파일은 일반적으로 다음 세 섹션으로 구성됩니다.
- [unit] - 단위 유형에 의존하지 않는 일반 옵션이 포함되어 있습니다. 이러한 옵션은 단위 설명을 제공하고, 단위의 동작을 지정하고, 종속성을 다른 단위로 설정합니다. 가장 자주 사용되는 [Unit] 옵션의 목록은 표 10.9. “중요 [Unit] 섹션 옵션” 을 참조하십시오.
- [단위 유형] - 단위에 유형별 지시문이 있는 경우 단위 유형 뒤에 이름이 지정된 섹션 아래에 그룹화됩니다. 예를 들어, 서비스 유닛 파일에 [Service] 섹션이 포함되어 있으며, 가장 자주 사용되는 [Service] 옵션은 표 10.10. “중요 [Service] 섹션 옵션” 을 참조하십시오.
-
[install] -
systemctl enable
및disable
명령에 사용되는 유닛 설치에 대한 정보가 포함되어 있습니다. [Install] 옵션 목록은 표 10.11. “중요 [설치] 섹션 옵션” 을 참조하십시오.
옵션[a] 섹션은 systemd.unit(5) 매뉴얼 페이지를 참조하십시오. | 설명 |
---|---|
|
단위에 대한 의미 있는 설명입니다. 이 텍스트는 예를 들어 |
| 단위에 대한 URI 참조 설명서 목록을 제공합니다. |
|
유닛이 시작되는 순서를 정의합니다. 이 단위는 |
|
다른 유닛에 대한 종속성을 구성합니다. |
|
|
|
|
[a]
[Unit]에서 설정할 수 있는 전체 옵션 목록을 보려면
[b]
대부분의 경우 After 및 Before 단위 파일 옵션을 사용하여 순서가 지정된 종속성만 설정하는 것으로 충분합니다. 또한 Wants (recommended) 또는 Requires 를 사용하여 요구 종속성을 설정하는 경우에도 순서 종속성을 지정해야 합니다. 이는 순서 및 요구 사항 종속성이 서로 독립적으로 작동하기 때문입니다.
|
옵션[a] 섹션은 systemd.service(5) 매뉴얼 페이지를 참조하십시오.] | 설명 |
---|---|
|
*
*
*
*
* |
|
단위가 시작될 때 실행할 명령 또는 스크립트를 지정합니다. |
| 장치가 중지될 때 실행할 명령 또는 스크립트를 지정합니다. |
| 장치가 다시 로드될 때 실행할 명령 또는 스크립트를 지정합니다. |
|
이 옵션을 활성화하면 |
|
True로 설정하면 모든 프로세스가 종료된 경우에도 서비스가 활성 상태로 간주됩니다. 기본값은 False입니다. 이 옵션은 |
[a]
[Service에서 구성 가능한 전체 옵션 목록을 보려면
|
옵션[a] 섹션은 systemd.unit(5) 매뉴얼 페이지를 참조하십시오. | 설명 |
---|---|
|
은 단원에 대해 공백으로 구분된 추가 이름 목록을 제공합니다. |
|
단위에 종속된 유닛 목록입니다. 이 유닛을 활성화하면 |
|
장치가 약하게 의존하는 단위 목록입니다. 이 유닛을 활성화하면 |
| 유닛을 설치하거나 제거할 유닛 목록을 지정합니다. |
| 인스턴스화 단위로 제한되는 이 옵션은 장치가 활성화된 기본 인스턴스를 지정합니다. 보기 10.6.5절. “인스턴스화된 유닛으로 작업” |
[a]
[Install에서 구성 가능한 전체 옵션 목록을 보려면
|
단위 구성을 미세 조정하는 데 사용할 수 있는 전체 옵션인 예 10.17. “redfish.service 단위 파일” 은 시스템에 설치된 서비스 단위의 예를 보여줍니다. 또한 단위 파일 옵션은 10.6.5절. “인스턴스화된 유닛으로 작업” 에 설명된 대로 장치를 동적으로 생성하는 방식으로 정의할 수 있습니다.
예 10.17. redfish.service 단위 파일
다음은 postfix 패키지에서 현재 제공하는 /usr/lib/systemd/system/hiera.service
유닛 파일의 내용입니다.
[Unit] Description=Postfix Mail Transport Agent After=syslog.target network.target Conflicts=sendmail.service exim.service [Service] Type=forking PIDFile=/var/spool/postfix/pid/master.pid EnvironmentFile=-/etc/sysconfig/network ExecStartPre=-/usr/libexec/postfix/aliasesdb ExecStartPre=-/usr/libexec/postfix/chroot-update ExecStart=/usr/sbin/postfix start ExecReload=/usr/sbin/postfix reload ExecStop=/usr/sbin/postfix stop [Install] WantedBy=multi-user.target
[Unit] 섹션은 서비스를 설명하고, 정렬 종속성과 충돌하는 단위를 지정합니다. [Service]에서 사용자 지정 스크립트의 순서는 장치 활성화, 중지 및 다시 로드 중에 실행되도록 지정됩니다. EnvironmentFile
은 서비스의 환경 변수가 정의된 위치를 가리킵니다. PIDFile
은 서비스의 기본 프로세스에 대한 안정적인 PID를 지정합니다. 마지막으로 [Install] 섹션에는 서비스를 사용하는 장치가 나열됩니다.
10.6.2. 사용자 지정 유닛 파일 생성
장치 파일을 처음부터 생성하는 몇 가지 사용 사례가 있습니다. 사용자 정의 데몬을 실행하거나, 기존 서비스의 두 번째 인스턴스를 생성( 예 10.19. “sshd 서비스의 두 번째 인스턴스 생성”), SysV init 스크립트( 10.6.3절. “SysV Init 스크립트를 유닛 파일로 변환”참조)를 가져올 수 있습니다. 반면 기존 유닛의 동작을 수정하거나 확장하려는 경우 10.6.4절. “기존 장치 파일 수정” 의 지침을 사용합니다. 다음 절차에서는 사용자 지정 서비스를 생성하는 일반적인 프로세스를 설명합니다.
-
사용자 지정 서비스로 실행 파일을 준비합니다. 사용자 지정 스크립트 또는 소프트웨어 공급자가 제공하는 실행 파일일 수 있습니다. 필요한 경우 사용자 지정 서비스의 기본 프로세스에 대해 상수 PID를 유지하도록 PID 파일을 준비합니다. 서비스에 대한 쉘 변수를 저장할 환경 파일을 포함할 수도 있습니다. 소스 스크립트가 실행 가능하고(
chmod a+x
) 대화형이 아닌지 확인합니다. /etc/systemd/system/
디렉터리에 유닛 파일을 만들고 올바른 파일 권한이 있는지 확인합니다.root
로 실행:touch /etc/systemd/system/name.service
chmod 664 /etc/systemd/system/name.service
name 을 생성할 서비스 이름으로 바꿉니다. 파일은 실행 파일일 필요가 없습니다.
이전 단계에서
만든이름.service
파일을 열고 서비스 구성 옵션을 추가합니다. 생성하려는 서비스 유형에 따라 사용할 수 있는 다양한 옵션이 있습니다. 10.6.1절. “단위 파일 구조 이해” 다음은 네트워크 관련 서비스의 유닛 구성 예입니다.[Unit] Description=service_description After=network.target [Service] ExecStart=path_to_executable Type=forking PIDFile=path_to_pidfile [Install] WantedBy=default.target
다음과 같습니다.
-
service_description 은 저널 로그 파일과
systemctl status
명령의 출력에 표시되는 정보적 설명입니다. -
after
설정
은 네트워크가 실행된 후에만 서비스가 시작되는지 확인합니다. 다른 관련 서비스 또는 대상의 공백으로 구분된 목록을 추가합니다. - path_to_executable 은 실제 실행 파일의 경로를 나타냅니다.
-
type=forking
은 fork 시스템 호출을 수행하는 데몬에 사용됩니다. 서비스의 기본 프로세스는 path_to_pidfile 에 지정된 PID를 사용하여 생성됩니다. 표 10.10. “중요 [Service] 섹션 옵션” 에서 다른 시작 유형을 찾습니다. -
WantedBy
는 서비스를 시작해야 하는 대상 또는 대상을 지정합니다. 이러한 대상을 실행 수준의 이전 개념을 대체하는 대상으로 간주하면 자세한 내용은 10.3절. “systemd 대상 작업” 을 참조하십시오.
-
service_description 은 저널 로그 파일과
root
로 다음 명령을 실행하여새이름.service
파일이 있음을 systemd에 알립니다.systemctl daemon-reload
systemctl start name.service
주의새 장치 파일을 생성하거나 기존 유닛 파일을 수정한 후 항상
systemctl daemon-reload
명령을 실행합니다. 그렇지 않으면 디스크의 systemd 및 실제 서비스 유닛 파일의 상태가 일치하지 않아systemctl start
또는systemctl enable
명령이 실패할 수 있었습니다.이제 10.2절. “시스템 서비스 관리” 에 설명된 명령을 사용하여 다른 시스템 서비스로 .service 이름을 관리할 수 있습니다.
예 10.18. emacs.service 파일 생성
EgressIP 텍스트 편집기를 사용할 때 파일을 편집할 때마다 프로그램의 새 인스턴스를 시작하는 대신 백그라운드에서 실행하는 것이 더 빠르고 편리합니다. 다음 단계는 서비스처럼 처리할 수 있도록 SMT용 유닛 파일을 생성하는 방법을 보여줍니다.
/etc/systemd/system/
디렉터리에 유닛 파일을 만들고 올바른 파일 권한이 있는지 확인합니다.root
로 실행:~]# touch /etc/systemd/system/emacs.service ~]# chmod 664 /etc/systemd/system/emacs.service
파일에 다음 내용을 추가합니다.
[Unit] Description=Emacs: the extensible, self-documenting text editor [Service] Type=forking ExecStart=/usr/bin/emacs --daemon ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)" Environment=SSH_AUTH_SOCK=%t/keyring/ssh Restart=always [Install] WantedBy=default.target
위의 구성을 사용하면 서비스 시작 시
/usr/bin/emacs
실행 파일이 데몬 모드에서 시작됩니다. SSH_AUTH_SOCK 환경 변수는 런타임 디렉터리를 나타내는 "%t" 장치 지정자를 사용하여 설정됩니다. 또한 이 서비스는 예기치 않게 종료되면 emacs 프로세스를 다시 시작합니다.다음 명령을 실행하여 구성을 다시 로드하고 사용자 지정 서비스를 시작합니다.
~]# systemctl daemon-reload ~]# systemctl start emacs.service
편집기가 이제 systemd 서비스로 등록되었으므로 모든 표준 systemctl
명령을 사용할 수 있습니다. 예를 들어 systemctl status emacs
를 실행하여 편집기의 상태를 표시하거나 systemctl enable emacs
를 실행하여 시스템 부팅 시 편집기가 자동으로 시작되도록 합니다.
예 10.19. sshd 서비스의 두 번째 인스턴스 생성
시스템 관리자는 서비스 인스턴스를 여러 개 구성하고 실행해야 하는 경우가 많습니다. 이 작업은 원래 서비스 구성 파일의 사본을 생성하고 서비스의 기본 인스턴스와 충돌하지 않도록 특정 매개 변수를 수정하여 수행됩니다. 다음 절차에서는 sshd
서비스의 두 번째 인스턴스를 생성하는 방법을 보여줍니다.
두 번째 데몬에서 사용할
sshd_config
파일의 사본을 만듭니다.~]# cp /etc/ssh/sshd{,-second}_config
이전 단계에서 생성한
sshd-second_config
파일을 편집하여 다른 포트 번호 및 PID 파일을 두 번째 데몬에 할당합니다.Port 22220 PidFile /var/run/sshd-second.pid
Port
및PidFile
옵션에 대한 자세한 내용은sshd_config
(5) 매뉴얼 페이지를 참조하십시오. 선택한 포트가 다른 서비스에서 사용되지 않는지 확인합니다. PID 파일은 서비스를 실행하기 전에 존재할 필요가 없으며, 서비스 시작 시 자동으로 생성됩니다.sshd
서비스에 대한 systemd 장치 파일의 사본을 생성합니다.~]# cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service
이전 단계에서 생성한
sshd-second.service
를 다음과 같이 변경합니다.Description
옵션을 수정합니다.Description=OpenSSH server second instance daemon
첫 번째 인스턴스가 이미 시작된 후에만 시작하도록
After
옵션에 지정된 서비스에 sshd.service를 추가합니다.After=syslog.target network.target auditd.service sshd.service
- sshd의 첫 번째 인스턴스에는 키 생성이 포함되어 있으므로 ExecStartPre=/usr/sbin/sshd-keygen 행을 제거합니다.
대체 구성 파일을 사용하도록
-f /etc/ssh/sshd-second_config
매개변수를sshd
명령에 추가합니다.ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
위의 수정 후 sshd-second.service는 다음과 같이 표시됩니다.
[Unit] Description=OpenSSH server second instance daemon After=syslog.target network.target auditd.service sshd.service [Service] EnvironmentFile=/etc/sysconfig/sshd ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartSec=42s [Install] WantedBy=multi-user.target
SELinux를 사용하는 경우 sshd의 두 번째 인스턴스에 대한 포트를 SSH 포트에 추가합니다. 그렇지 않으면 sshd의 두 번째 인스턴스가 포트에 바인딩하도록 거부됩니다.
~]# semanage port -a -t ssh_port_t -p tcp 22220
부팅 시 자동으로 시작되도록 sshd-second.service를 활성화합니다.
~]# systemctl enable sshd-second.service
systemctl status
명령을 사용하여 sshd-second.service가 실행 중인지 확인합니다. 또한 서비스에 연결하여 포트가 올바르게 활성화되어 있는지 확인합니다.~]$
ssh -p 22220 user@server
방화벽이 사용 중인 경우 sshd의 두 번째 인스턴스에 대한 연결을 허용하도록 적절하게 구성되었는지 확인합니다.
- 사용자 지정 단위 파일의 순서 및 종속 항목에 대한 대상을 선택하는 방법을 알아보려면 다음 문서를 참조하십시오.
단위 파일의 순서 및 종속 항목에 의해 트리거되는 몇 가지 실제 사례 예제가 있는 추가 정보는 다음 문서에서 확인할 수 있습니다. 유닛 파일 작성에 대한 유용한 정보가 있습니까?
systemd
에 의해 시작된 서비스에 대한 제한을 설정하려면 RHEL 7 및 systemd에서 서비스 제한을 설정하는 방법을 참조하십시오. 이러한 제한은 서비스의 유닛 파일에 설정해야 합니다. systemd
는 /etc/security/limits.conf
및 /etc/security/limits.d/*.conf
구성 파일에 설정된 제한을 무시합니다. 이러한 파일에 정의된 제한은 로그인 세션을 시작할 때 PAM에 의해 설정되지만 systemd
에서 시작한 데몬은 PAM 로그인 세션을 사용하지 않습니다.
10.6.3. SysV Init 스크립트를 유닛 파일로 변환
SysV init 스크립트를 유닛 파일로 변환하는 데 시간이 걸리기 전에 변환이 아직 다른 곳에서 수행되지 않았는지 확인하십시오. Red Hat Enterprise Linux 7에 설치된 모든 핵심 서비스는 기본 장치 파일과 함께 제공되며 여러 타사 소프트웨어 패키지에 동일하게 적용됩니다.
init 스크립트를 유닛 파일로 변환하려면 스크립트를 분석하고 필요한 정보를 추출해야 합니다. 이 데이터를 기반으로 10.6.2절. “사용자 지정 유닛 파일 생성” 에 설명된 대로 단위 파일을 생성할 수 있습니다. init 스크립트는 서비스 유형에 따라 크게 달라질 수 있으므로 이 장에 설명된 것보다 번역에 더 많은 구성 옵션을 사용해야 할 수 있습니다. init 스크립트에서 사용할 수 있는 일부 수준의 사용자 지정은 더 이상 systemd 장치에서 지원되지 않습니다. 10.1.2절. “호환성 변경”
변환에 필요한 대부분의 정보는 스크립트의 헤더에 제공됩니다. 다음 예제에서는 Red Hat Enterprise Linux 6에서 postfix
서비스를 시작하는 데 사용되는 init 스크립트의 열기 섹션을 보여줍니다.
#!/bin/bash # # postfix Postfix Mail Transfer Agent # # chkconfig: 2345 80 30 # description: Postfix is a Mail Transport Agent, which is the program \ # that moves mail from one machine to another. # processname: master # pidfile: /var/spool/postfix/pid/master.pid # config: /etc/postfix/main.cf # config: /etc/postfix/master.cf ### BEGIN INIT INFO # Provides: postfix MTA # Required-Start: $local_fs $network $remote_fs # Required-Stop: $local_fs $network $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start and stop postfix # Description: Postfix is a Mail Transport Agent, which is the program that # moves mail from one machine to another. ### END INIT INFO
위의 예에서 # chkconfig 및 # 설명으로 시작하는 행만 필수이므로 다른 init 파일에서 나머지를 찾지 못할 수 있습니다. # BEGIN INIT INFO 및 # END INIT INFO 행 사이에 있는 텍스트는 Linux Standard Base(LSB) 헤더 라고 합니다. 지정된 경우 LSB 헤더에는 서비스 설명, 종속 항목 및 기본 실행 수준을 정의하는 지시문이 포함됩니다. 다음은 새 단위 파일에 필요한 데이터를 수집하는 분석 작업의 개요입니다. postfix init 스크립트는 예제로 사용되며 예 10.17. “redfish.service 단위 파일” 에서 결과 postfix 단위 파일을 참조하십시오.
서비스 설명 찾기
#description.로 시작하는 줄에서 스크립트에 대한 설명 정보를 찾을 수 있습니다. 이 설명은 단위 파일의 [Unit] 섹션에 있는 Description
옵션에 있는 서비스 이름과 함께 사용합니다. LSB 헤더는 #Short-Description 및 #Description 행에 유사한 데이터를 포함할 수 있습니다.
서비스 종속성 검색
LSB 헤더에는 서비스 간 종속성을 형성하는 여러 지시문이 포함될 수 있습니다. 대부분의 systemd 장치 옵션은 다음과 같습니다. 표 10.12. “LSB 헤더의 종속성 옵션”
LSB 옵션 | 설명 | 단위 파일 Equivalent |
---|---|---|
| 다른 init 스크립트 ($" 접두사 사용)에서 참조할 수 있는 서비스의 부팅 기능 이름을 지정합니다. 유닛 파일이 파일 이름별로 다른 유닛을 참조하면 이 작업이 더 이상 필요하지 않습니다. | – |
|
필요한 서비스의 부팅 기능 이름이 포함되어 있습니다. 이는 순서 종속성으로 변환되며 부팅 기능 이름은 해당 서비스 또는 해당 서비스의 유닛 파일 이름으로 교체됩니다. 예를 들어 |
|
| Required-Start보다 약한 종속성을 구성합니다. Should-Start 종속성은 서비스 시작에 영향을 미치지 않습니다. |
|
| 음수 종속성을 구성합니다. |
|
서비스의 기본 대상 검색
#chkconfig 로 시작하는 줄에는 세 개의 숫자 값이 포함되어 있습니다. 가장 중요한 것은 서비스가 시작되는 기본 실행 수준을 나타내는 첫 번째 번호입니다. 표 10.6. “systemd 대상과 SysV Runlevels 비교” 을 사용하여 이러한 실행 수준을 동등한 systemd 대상에 매핑합니다. 그런 다음 장치 파일의 [Install] 섹션에 있는 WantedBy
옵션에 이러한 대상을 나열합니다. 예를 들어 postfix
는 이전에 Red Hat Enterprise Linux 7의 multi-user.target 및 graphical.target으로 변환되는 실행 수준 2, 3, 4 및 5에서 시작되었습니다. graphical.target은 drives.target에 따라 달라지므로 예 10.17. “redfish.service 단위 파일” 에서와 같이 둘 다 지정할 필요는 없습니다. 또한 LSB 헤더에서 #Default-Start 및 #Default-Stop 행에 default 및 금지된 실행 수준 정보에 대한 정보를 찾을 수 있습니다.
#chkconfig 행에 지정된 다른 두 값은 init 스크립트의 시작 및 종료 우선 순위를 나타냅니다. 이러한 값은 init 스크립트를 로드하는 경우 systemd에 의해 해석되지만, 이와 동등한 유닛 파일은 없습니다.
서비스에서 사용하는 파일 찾기
init 스크립트는 전용 디렉터리에서 함수 라이브러리를 로드해야 하며 구성, 환경 및 PID 파일을 가져올 수 있습니다. 환경 변수는 init 스크립트 헤더에서 #config 로 시작하는 행에서 지정되며 EnvironmentFile
장치 파일 옵션으로 변환됩니다. #pidfile init 스크립트 행에 지정된 PID 파일은 PIDFile
옵션을 사용하여 유닛 파일로 가져옵니다.
init 스크립트 헤더에 포함되지 않은 주요 정보는 서비스 실행 파일의 경로이며 서비스에 필요할 가능성이 있는 기타 파일입니다. 이전 버전의 Red Hat Enterprise Linux에서 init 스크립트는 Bash case 문을 사용하여 start,stop, 또는 restart 와 같은 기본 작업에서 서비스 동작을 정의했습니다. postfix
init 스크립트에서 발췌한 내용은 service start에서 실행할 코드 블록을 보여줍니다.
conf_check() { [ -x /usr/sbin/postfix ] || exit 5 [ -d /etc/postfix ] || exit 6 [ -d /var/spool/postfix ] || exit 5 } make_aliasesdb() { if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ] then # /etc/aliases.db might be used by other MTA, make sure nothing # has touched it since our last newaliases call [ /etc/aliases -nt /etc/aliases.db ] || [ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] || [ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return /usr/bin/newaliases touch -r /etc/aliases.db "$ALIASESDB_STAMP" else /usr/bin/newaliases fi } start() { [ "$EUID" != "0" ] && exit 4 # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 1 conf_check # Start daemons. echo -n $"Starting postfix: " make_aliasesdb >/dev/null 2>&1 [ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE /usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start" RETVAL=$? [ $RETVAL -eq 0 ] && touch $lockfile echo return $RETVAL }
init 스크립트의 확장성을 통해 start()
함수에서 호출되는 conf_check()
및 make_aliasesdb()
를 지정할 수 있습니다. 더 자세히 살펴보면 기본 서비스 실행 /usr/sbin/journal , /
디렉토리 등 여러 외부 파일과 디렉터리가 언급됩니다.
etc/journal/ and /
구성 디렉토리 및 var/
spool/ avoided//usr/sbin/
postconf/
systemd는 사전 정의된 작업만 지원하지만 ExecStart ,ExecStartPre
,
,ExecStart
PostExecStop
및 ExecReload
옵션을 사용하여 사용자 지정 실행 파일을 실행할 수 있습니다. Red Hat Enterprise Linux 7에서 postfix
의 경우 /usr/sbin/
hiera와 지원 스크립트가 함께 서비스 시작 시 실행됩니다. 예 10.17. “redfish.service 단위 파일” 에서 postfix
유닛 파일을 참조하십시오.
복잡한 init 스크립트를 변환하려면 스크립트의 모든 문 용도를 이해해야 합니다. 일부 설명은 운영 체제 버전에 고유하므로 번역할 필요가 없습니다. 반면, 새로운 환경에서는 물론 서비스 실행 파일 및 지원 파일에서도 일부 조정이 필요할 수 있습니다.
10.6.4. 기존 장치 파일 수정
시스템에 설치된 서비스는 /usr/lib/systemd/system/
디렉터리에 저장된 기본 장치 파일과 함께 제공됩니다. 시스템 관리자는 이러한 파일을 직접 수정하지 않아야 하므로 사용자 지정을 /etc/systemd/system/
디렉터리의 구성 파일로 제한해야 합니다. 필요한 변경의 범위에 따라 다음 방법 중 하나를 선택합니다.
-
/etc/systemd/system/단위.d/
에 보조 구성 파일의 디렉터리를 만듭니다. 이 방법은 대부분의 사용 사례에 권장됩니다. 원래 장치 파일을 참조하는 동안 추가 기능을 사용하여 기본 구성을 확장할 수 있습니다. 따라서 패키지 업그레이드에 도입된 기본 단위의 변경 사항은 자동으로 적용됩니다. 자세한 내용은 “기본 장치 구성 확장”를 참조하십시오. -
/etc/systemd/system/
에서 원래 장치 파일/usr/lib/systemd/system/
의 복사본을 만들고 변경합니다. 복사는 원본 파일을 덮어쓰므로 패키지 업데이트로 인한 변경 사항은 적용되지 않습니다. 이 방법은 패키지 업데이트에 관계없이 유지되어야 하는 중요한 단위 변경을 수행하는 데 유용합니다. 자세한 내용은 “기본 장치 구성 덮어쓰기” 을 참조하십시오.
단위의 기본 구성으로 돌아가려면 /etc/systemd/system/
.에서 사용자 지정 생성 구성 파일을 삭제하면 됩니다. 시스템을 재부팅하지 않고 장치 파일에 변경 사항을 적용하려면 다음을 실행합니다.
systemctl daemon-reload
daemon-reload
옵션은 모든 유닛 파일을 다시 로드하고 전체 종속성 트리를 다시 생성합니다. 이 트리는 유닛 파일에 변경 사항을 즉시 적용하는 데 필요합니다. 또는 다음 명령을 사용하여 동일한 결과를 얻을 수 있습니다.
init q
또한 수정된 유닛 파일이 실행 중인 서비스에 속하는 경우 새 설정을 수락하려면 이 서비스를 다시 시작해야 합니다.
systemctl restart name.service
SysV initscript에서 처리하는 서비스의 종속성 또는 시간 초과와 같은 속성을 수정하려면 initscript 자체를 수정하지 마십시오. 대신 “기본 장치 구성 확장” 및 “기본 장치 구성 덮어쓰기” 에 설명된 대로 서비스에 대한 systemd
드롭인 구성 파일을 생성합니다. 그런 다음 일반 systemd
서비스와 동일한 방식으로 이 서비스를 관리합니다.
예를 들어 네트워크
서비스 구성을 확장하려면 /etc/rc.d/init.d/network
initscript 파일을 수정하지 마십시오. 대신 새 디렉토리 /etc/systemd/system/network.service.d/
및 systemd
드롭인 파일 /etc/systemd/system/network.service.d/my_config.conf
를 생성합니다. 그런 다음 수정된 값을 드롭인 파일에 배치합니다. 참고: systemd
는
로 네트워크 서비스를 알고 있으므로 생성된 디렉토리를 network
.servicenetwork.service.d
라고 지정해야 합니다.
기본 장치 구성 확장
추가 구성 옵션을 사용하여 기본 유닛 파일을 확장하려면 먼저 /etc/systemd/system/
.에 구성 디렉터리를 만듭니다. 서비스 장치를 확장하는 경우 root
로 다음 명령을 실행합니다.
mkdir /etc/systemd/system/name.service.d/
name 을 확장할 서비스의 이름으로 변경합니다. 위의 구문은 모든 유닛 유형에 적용됩니다.
이전 단계에서 만든 디렉터리에 구성 파일을 생성합니다. 파일 이름은 .conf 접미사로 끝나야 합니다. 유형:
touch /etc/systemd/system/name.service.d/config_name.conf
config_name 을 구성 파일의 이름으로 바꿉니다. 이 파일은 일반 단위 파일 구조를 준수하므로 모든 지시문을 해당 섹션에서 지정해야 합니다. 10.6.1절. “단위 파일 구조 이해”
예를 들어 사용자 지정 종속성을 추가하려면 다음 콘텐츠를 사용하여 구성 파일을 생성합니다.
[Unit] Requires=new_dependency After=new_dependency
여기서 new_dependency 는 유닛이 종속성으로 표시됨을 나타냅니다. 또 다른 예로는 기본 프로세스가 종료된 후 서비스를 다시 시작하는 구성 파일이 30초로 지연됩니다.
[Service] Restart=always RestartSec=30
하나의 작업에만 중점을 둔 작은 구성 파일을 생성하는 것이 좋습니다. 이러한 파일은 쉽게 이동하거나 다른 서비스의 구성 디렉토리에 연결할 수 있습니다.
단위에 대한 변경 사항을 적용하려면 root
로 실행합니다.
systemctl daemon-reload
systemctl restart name.service
예 10.20. httpd.service 구성 확장
Apache 서비스를 시작할 때 사용자 정의 쉘 스크립트가 자동으로 실행되도록 httpd.service 유닛을 수정하려면 다음 단계를 수행합니다. 먼저 디렉터리와 사용자 지정 구성 파일을 생성합니다.
~]# mkdir /etc/systemd/system/httpd.service.d/ ~]# touch /etc/systemd/system/httpd.service.d/custom_script.conf
Apache를 사용하여 자동으로 시작하려는 스크립트가 /usr/local/bin/custom.sh
에 있는 경우 custom_script.conf
파일에 다음 텍스트를 삽입합니다.
[Service] ExecStartPost=/usr/local/bin/custom.sh
단위 변경 사항을 적용하려면 다음을 실행합니다.
~]# systemctl daemon-reload ~]# systemctl restart httpd.service
/etc/systemd/system/
의 구성 파일은 /usr/lib/systemd/system/
의 장치 파일보다 우선합니다. 따라서 구성 파일에 Description
또는 ExecStart
와 같이 한 번만 지정할 수 있는 옵션이 포함된 경우 이 옵션의 기본값이 재정의됩니다. “Monitoring Overriden Units” 에 설명된 systemd-delta
명령의 출력에서는 합계에 있어도 특정 옵션이 실제로 재정의되어도 항상 [EXTENDED]로 표시됩니다.
기본 장치 구성 덮어쓰기
장치 파일을 제공하는 패키지를 업데이트한 후 계속 변경하려면 먼저 파일을 /etc/systemd/system/
디렉터리에 복사합니다. 이렇게 하려면 root
로 다음 명령을 실행하십시오.
cp /usr/lib/systemd/system/name.service /etc/systemd/system/name.service
여기서 name 은 수정할 서비스 유닛의 이름을 나타냅니다. 위의 구문은 모든 유닛 유형에 적용됩니다.
텍스트 편집기로 복사된 파일을 열고 원하는 대로 변경합니다. 단위 변경 사항을 적용하려면 root
로 실행합니다.
systemctl daemon-reload
systemctl restart name.service
예 10.21. 제한 시간 제한 변경
서비스당 시간 제한 값을 지정하여 시스템 중단 서비스가 중단되는 것을 방지할 수 있습니다. 그렇지 않으면 표준 서비스의 경우 시간 초과가 기본적으로 90초로 설정되고 SysV 호환 서비스의 경우 300초로 설정됩니다.
예를 들어 httpd
서비스의 시간 제한 제한을 확장하려면 다음을 수행합니다.
httpd
장치 파일을/etc/systemd/system/
디렉터리에 복사합니다.cp /usr/lib/systemd/system/httpd.service /etc/systemd/system/httpd.service
/etc/systemd/system/httpd.service
파일을 열고[Service]
섹션에서TimeoutStartSec
값을 지정합니다.... [Service] ... PrivateTmp=true TimeoutStartSec=10 [Install] WantedBy=multi-user.target ...
systemd
데몬을 다시 로드합니다.systemctl daemon-reload
선택 사항: 새 시간 초과 값을 확인합니다.
systemctl show httpd -p TimeoutStartUSec
제한 시간 제한을 전역적으로 변경하려면 /etc/systemd/system.conf
파일에 DefaultTimeoutStartSec
를 입력합니다. 10.1절. “systemd 소개”을 참조하십시오.
Monitoring Overriden Units
재정의 또는 수정된 단위 파일의 개요를 표시하려면 다음 명령을 사용합니다.
systemd-delta
예를 들어 위 명령의 출력은 다음과 같습니다.
[EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target [OVERRIDDEN] /etc/systemd/system/autofs.service → /usr/lib/systemd/system/autofs.service --- /usr/lib/systemd/system/autofs.service 2014-10-16 21:30:39.000000000 -0400 +++ /etc/systemd/system/autofs.service 2014-11-21 10:00:58.513568275 -0500 @@ -8,7 +8,8 @@ EnvironmentFile=-/etc/sysconfig/autofs ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid ExecReload=/usr/bin/kill -HUP $MAINPID -TimeoutSec=180 +TimeoutSec=240 +Restart=Always [Install] WantedBy=multi-user.target [MASKED] /etc/systemd/system/cups.service → /usr/lib/systemd/system/cups.service [EXTENDED] /usr/lib/systemd/system/sssd.service → /etc/systemd/system/sssd.service.d/journal.conf 4 overridden configuration files found.
표 10.13. “systemd-delta Difference Types” systemd-delta
의 출력에 표시될 수 있는 덮어쓰기 유형을 나열합니다. 파일을 재정의하는 경우 기본적으로 systemd-delta
는 diff
명령의 출력과 유사한 변경 사항에 대한 요약을 표시합니다.
유형 | 설명 |
---|---|
[MASKED] | 마스킹된 유닛 파일, 단위 마스킹에 대한 설명은 10.2.7절. “서비스 비활성화” 을 참조하십시오. |
[EQUIVALENT] | 원본 파일을 재정의하지만 콘텐츠, 일반적으로 심볼릭 링크와 일치하지 않는 수정되지 않은 복사본입니다. |
[DIRECTED] | 다른 파일로 리디렉션되는 파일 |
[OVERRIDEN] | 재정의 및 변경된 파일. |
[EXTENDED] |
|
[UNCHANGED] |
수정되지 않은 파일은 |
시스템 업데이트 후에 systemd-delta
를 실행하여 현재 사용자 지정 구성으로 재정의된 기본 유닛에 대한 업데이트가 있는지 확인하는 것이 좋습니다. 출력을 특정 차이 유형으로만 제한할 수도 있습니다. 예를 들어 재정의된 장치만 보려면 다음을 실행합니다.
systemd-delta --type=overridden
10.6.5. 인스턴스화된 유닛으로 작업
런타임 시 단일 템플릿 구성 파일에서 여러 단위를 인스턴스화할 수 있습니다. "@" 문자는 템플릿을 표시하고 장치와 장치를 연결하는 데 사용됩니다. 인스턴스화된 단위는 다른 유닛 파일( Requires
또는 Wants
옵션 사용) 또는 systemctl start
명령으로 시작할 수 있습니다. 인스턴스화된 서비스 유닛의 이름은 다음과 같습니다.
template_name@instance_name.service
여기서 template_name 은 템플릿 구성 파일의 이름을 나타냅니다. instance_name 을 유닛 인스턴스의 이름으로 바꿉니다. 여러 인스턴스는 장치의 모든 인스턴스에 공통된 구성 옵션을 사용하여 동일한 템플릿 파일을 가리킬 수 있습니다. 템플릿 단위 이름에는 다음과 같은 형식이 있습니다.
unit_name@.service
예를 들어, 단위 파일의 다음 Wants
설정:
Wants=getty@ttyA.service,getty@ttyB.service
먼저 systemd가 지정된 서비스 장치를 검색합니다. 이러한 유닛을 찾을 수 없는 경우 "@"과 유형 접미사 사이의 일부가 무시되고, systemd는 getty@.service
파일을 검색하고, 해당 파일에서 구성을 읽고, 서비스를 시작합니다.
단위 지정자 라고 하는 와일드카드 문자를 모든 단위 구성 파일에 사용할 수 있습니다. 단위 지정자는 특정 단위 매개 변수를 대체하고 런타임 시 해석됩니다. 표 10.14. “중요 단위 지정기” 템플릿 단위에 특히 유용한 단위 연산자를 나열합니다.
단위 지정기 | meaning | 설명 |
---|---|---|
| 전체 단위 이름 |
은 유형 접미사를 포함하여 전체 단위 이름을 나타냅니다. |
| 접두사 이름 | 은 유형 접미사가 제거된 단위 이름입니다. 인스턴스화된 단위 %p는 "@" 문자 앞에 있는 단위 이름의 일부를 나타냅니다. |
| 인스턴스 이름 |
"@" 문자와 유형 접미사 사이의 인스턴스화된 단위 이름의 일부입니다. |
| 호스트 이름 | 는 장치 구성이 로드될 때 실행 중인 시스템의 호스트 이름을 나타냅니다. |
| 런타임 디렉터리 |
|
단위 연산자의 전체 목록은 systemd.unit(5)
매뉴얼 페이지를 참조하십시오.
예를 들어 getty@.service
템플릿에는 다음 지시문이 포함되어 있습니다.
[Unit] Description=Getty on %I ... [Service] ExecStart=-/sbin/agetty --noclear %I $TERM ...
getty@ttyA.service 및 getty@ttyB.service가 인스턴스화되면 위의 템플릿이 Description
=은 ttyA 및 Getty on tty B 로 확인됩니다.
10.7. 서비스 관리 중 추가 고려 사항
정상적인 작업 중에 systemd는 시스템에서 활성 상태의 단위 추상화와 기본 프로세스 간의 연결을 유지합니다.
from: man systemd
Processes systemd spawns are placed in individual Linux control groups named after the unit which they belong to in the private systemd hierarchy. (see cgroups.txt[1] for more information about control groups, or short "cgroups"). systemd uses this to effectively keep track of processes. Control group information is maintained in the kernel, and is accessible via the file system hierarchy (beneath /sys/fs/cgroup/systemd/), or in tools such as ps(1) (ps xawf -eo pid,user,cgroup,args is particularly useful to list all processes and the systemd units they belong to).
cgroup 계층 구조는 systemd의 프로세스 및 서비스 상태에 매우 중요합니다. 프로세스가 호출되면 생성 프로세스의 cgroup을 상속합니다. 이 경우 다음과 같은 해당 cgroup.procs 파일의 내용을 읽고 지정된 유닛과 연결된 모든 프로세스를 확인할 수 있습니다.
~]# cat /sys/fs/cgroup/systemd/system.slice/httpd.service/cgroup.procs 11854 11855 11856 11857 11858 11859
출력은 systemctl status unit
작업 중에 반환된 CGroup 정보와 일치합니다.
~]# systemctl status httpd ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2019-05-29 12:08:16 EDT; 45s ago Docs: man:httpd(8) man:apachectl(8) Main PID: 11854 (httpd) Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec" CGroup: /system.slice/httpd.service ├─11854 /usr/sbin/httpd -DFOREGROUND ├─11855 /usr/sbin/httpd -DFOREGROUND ├─11856 /usr/sbin/httpd -DFOREGROUND ├─11857 /usr/sbin/httpd -DFOREGROUND ├─11858 /usr/sbin/httpd -DFOREGROUND └─11859 /usr/sbin/httpd -DFOREGROUND May 29 12:08:16 localhost systemd[1]: Starting The Apache HTTP Server... May 29 12:08:16 localhost systemd[1]: Started The Apache HTTP Server.
이러한 프로세스 그룹을 시스템 전체에서 직접 보려면 systemd-cgls
유틸리티를 사용할 수 있습니다.
~]# systemd-cgls | head -17 ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22 ├─user.slice │ └─user-0.slice │ └─session-168.scope │ ├─ 3049 login -- root │ ├─11884 -bash │ ├─11943 systemd-cgls │ └─11944 head -17 └─system.slice ├─httpd.service │ ├─11854 /usr/sbin/httpd -DFOREGROUND │ ├─11855 /usr/sbin/httpd -DFOREGROUND │ ├─11856 /usr/sbin/httpd -DFOREGROUND │ ├─11857 /usr/sbin/httpd -DFOREGROUND │ ├─11858 /usr/sbin/httpd -DFOREGROUND │ └─11859 /usr/sbin/httpd -DFOREGROUND ├─rhnsd.service
systemd가 제대로 작동하려면 서비스를 시작하거나 systemd 시스템을 통해 중지하여 단위 그룹화에 대한 올바른 프로세스를 유지해야 합니다. 외부 작업을 수행하는 모든 작업을 수행하면 필요한 cgroup 구조가 생성되지 않습니다. 이는 systemd가 시작되는 프로세스의 특수 특성을 인식하지 못하기 때문에 발생합니다.
위의 제약 조건의 예로 httpd
서비스를 중지한 다음 /usr/sbin/httpd
를 실행하면 다음과 같은 결과가 나타납니다.
~]# systemctl stop httpd ~]# /usr/sbin/httpd # systemd-cgls | head -17 ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22 ├─user.slice │ └─user-0.slice │ └─session-168.scope │ ├─ 3049 login -- root │ ├─11884 -bash │ ├─11957 /usr/sbin/httpd │ ├─11958 /usr/sbin/httpd │ ├─11959 /usr/sbin/httpd │ ├─11960 /usr/sbin/httpd │ ├─11961 /usr/sbin/httpd │ ├─11962 /usr/sbin/httpd │ ├─11963 systemd-cgls │ └─11964 head -17 └─system.slice ├─rhnsd.service │ └─3261 rhnsd
이제 httpd
프로세스가 user-0.slice 및 session-168.scope 아래에 표시됩니다. 이 서비스는 시스템 서비스와 달리 사용자가 시작한 프로세스로 취급되며, 해당 systemd는 직접 모니터링하고 관리해야 합니다. 이 잘못 정렬으로 인해 발생할 수 있는 일부 오류는 다음과 같습니다.
- 서비스는 시스템 종료 또는 재시작 이벤트 중에 제대로 종료되지 않습니다.
- 예기치 않은 신호는 SIGHUP 및 SIGTERM과 같은 로그 아웃 중에 제공됩니다.
-
실패한 프로세스는
Restart=
지시문을 사용하여 자동으로 재시작되지 않습니다.
비정상적인 애플리케이션 종료 이벤트는 클라이언트 측 오류, 데이터 손실 및 디스크상의 손상과 같은 많은 후속 애플리케이션 오류가 발생할 수 있습니다.
10.8. 추가 리소스
systemd 및 Red Hat Enterprise Linux 7의 사용법에 대한 자세한 내용은 아래 나열된 리소스를 참조하십시오.
설치된 문서
-
systemctl
(1) -systemctl
명령줄 유틸리티의 도움말 페이지는 지원되는 옵션 및 명령의 전체 목록을 제공합니다. -
systemd
(1) -systemd
시스템 및 서비스 관리자의 도움말 페이지는 사용 가능한 개념 및 문서 사용 가능한 명령줄 옵션 및 환경 변수, 지원되는 구성 파일 및 디렉터리, 인식 신호, 사용 가능한 커널 옵션에 대한 자세한 정보를 제공합니다. -
systemd-delta
(1) - 확장 및 재정의된 구성 파일을 찾을 수 있는systemd-delta
유틸리티의 설명서 페이지. -
systemd.unit
(5) -systemd.unit
이라는 수동 페이지는 systemd 장치 파일 및 사용 가능한 모든 구성 옵션에 대한 자세한 정보를 제공합니다. -
systemd.service
(5) - 이름이systemd.service
인 도움말 페이지는 서비스 장치 파일의 형식을 문서화합니다. -
systemd.target
(5) - 이름이systemd.target
인 도움말 페이지는 대상 장치 파일의 형식을 문서화합니다. -
systemd.kill
온라인 문서
-
Red Hat Enterprise Linux 7 네트워킹 가이드 - 이 시스템의 네트워크 인터페이스, 네트워크 및 네트워크 서비스의 구성 및 관리와 관련된 Red Hat Enterprise Linux 7의 네트워킹 가이드.
hostnamectl
유틸리티를 소개하고, 이를 사용하여 로컬 및 원격으로 명령줄에서 호스트 이름을 보고 설정하는 방법을 설명하고, 호스트 이름과 도메인 이름 선택에 대한 중요한 정보를 제공합니다. -
Red Hat Enterprise Linux 7 데스크탑 마이그레이션 및 관리 가이드 - Red Hat Enterprise Linux 7 용 데스크탑 마이그레이션 및 관리 가이드, 이 시스템의 GNOME 3 데스크탑 마이그레이션, 구성 및 관리 가이드.
로그인된
서비스가 도입되고, 가장 중요한 기능을 열거하고,loginctl
유틸리티를 사용하여 활성 세션을 나열하고 다방적 지원을 활성화하는 방법을 설명합니다. - Red Hat Enterprise Linux 7 SELinux 사용자 및 관리자 가이드 - Red Hat Enterprise Linux 7 의 SELinux 사용자 및 관리자 안내서는 Apache HTTP Server, Postgres, PostgreSQL 또는 OpenShift와 같은 다양한 서비스로 SELinux 및 문서의 기본 원칙을 자세히 설명합니다. systemd에서 관리하는 시스템 서비스에 대한 SELinux 액세스 권한을 구성하는 방법에 대해 설명합니다.
- Red Hat Enterprise Linux 7 설치 가이드 - Red Hat Enterprise Linux 7의 설치 가이드 인 AMD64 및 Intel 64 시스템에 시스템을 설치하는 방법, 64비트 IBM Power Systems 서버 및 IBM Z에 대한 설치 가이드도 설명합니다. VNC 프로토콜을 통한 Kickstart 설치, PXE 설치 및 설치 등의 고급 설치 방법도 다룹니다. 또한 일반적인 설치 후 작업을 설명하고 복구 모드로 부팅하거나 루트 암호를 복구하는 방법에 대한 자세한 지침을 포함하여 설치 문제를 해결하는 방법을 설명합니다.
- Red Hat Enterprise Linux 7 보안 가이드 - Red Hat Enterprise Linux 7의 보안 가이드는 로컬 및 원격 침입, 악용 및 악의적인 활동을 위해 워크스테이션 및 서버를 보호하는 프로세스와 관행을 학습하는 데 도움이 됩니다. 또한 중요한 시스템 서비스를 보호하는 방법도 설명합니다.
- systemd 홈 페이지 - 프로젝트 홈 페이지는 systemd에 대한 자세한 정보를 제공합니다.
예를 들면 다음과 같습니다.
-
2장. System Locale 및 keyboard Configuration 시스템 로케일 및 키보드 레이아웃을 관리하는 방법에 대해 설명합니다.
localectl
유틸리티를 사용하여 현재 로케일을 보고, 사용 가능한 로케일을 나열하고, 명령줄에서 시스템 로케일을 설정하고, 현재 키보드 레이아웃을 보고, 사용 가능한 키맵 목록을 나열하고, 명령줄에서 특정 키보드 레이아웃을 활성화하는 방법을 설명합니다. -
3장. 날짜 및 시간 구성 시스템 날짜 및 시간을 관리하는 방법을 설명합니다. 실시간 클럭과 시스템 클럭의 차이를 설명하고
timedatectl
유틸리티를 사용하여 시스템 시계의 현재 설정을 표시하는 방법을 설명하고, 날짜와 시간을 구성하고, 시간대를 변경하고, 시스템 클럭을 원격 서버와 동기화하는 방법을 설명합니다. -
6장. 권한 확보
su
및sudo
명령을 사용하여 관리 권한을 얻는 방법에 대해 설명합니다. -
12장. OpenSSH SSH 서버 및
ssh
,scp
,sftp
클라이언트 유틸리티를 사용하여 액세스하는 방법에 대해 설명합니다. -
23장. 로그 파일 보기 및 관리
journald
에 대한 소개를 제공합니다. 저널에 대해 설명하고journald
서비스를 소개하고journalctl
유틸리티를 사용하여 로그 항목을 보고, 실시간 보기 모드를 입력하고 로그 항목을 필터링하는 방법을 설명합니다. 또한 루트가 아닌 사용자에게 시스템 로그에 대한 액세스 권한을 부여하고 로그 파일에 영구 스토리지를 활성화하는 방법을 설명합니다.
11장. 접근성을 위한 시스템 구성
Red Hat Enterprise Linux 7의 접근성은 운영 체제의 기본 설치에 포함된 Orca 화면 리더에 의해 보장됩니다. 이 장에서는 시스템 관리자가 시각적 장애가 있는 사용자를 지원하도록 시스템을 구성하는 방법에 대해 설명합니다.
orca 는 화면에서 정보를 읽고 다음을 사용하여 사용자에게 전달합니다.
- 음성 출력을 제공하는 음성 합성기
- 트레일 출력을 제공하는 braille 디스플레이
orca 설정에 대한 자세한 내용은 도움말 페이지를 참조하십시오.
orca의통신 출력이 제대로 작동하려면 시스템 관리자가 다음을 수행해야 합니다.
-
에 설명된 대로
brltty
서비스를 구성합니다. 11.1절. “brltty
서비스 구성” -
에 설명된 대로
Always Show Universal Access
메뉴로 전환 11.2절. “Always Show Universal Access 메뉴
” - 에 설명된 대로 페스티벌 음성 합성기 사용 11.3절. “Boost Synthesis System활성화”
11.1. brltty
서비스 구성
Braille 디스플레이는 brltty
서비스를 사용하여 시각적으로 장애가 있는 사용자에게 짝수한 출력을 제공합니다.
brltty 서비스 활성화
brltty
가 실행되고 있지 않으면 braille 디스플레이가 작동할 수 없습니다. 기본적으로 brltty
는 비활성화되어 있습니다. brltty
가 부팅 시 시작되도록 활성화합니다.
~]# systemctl enable brltty.service
사용자가 Braille 디스플레이를 사용하도록 권한 부여
braille 디스플레이를 사용할 권한이 있는 사용자를 설정하려면 동일한 효과가 있는 다음 절차 중 하나를 선택합니다. /etc/brltty.conf
파일을 사용하는 절차는 사용자 또는 그룹을 파일에 할당할 수 없는 파일 시스템에도 적합합니다. /etc/brlapi.key
파일을 사용하는 절차는 사용자 또는 그룹을 파일에 할당할 수 있는 파일 시스템에만 적합합니다.
/etc/brltty.conf
를 사용하여 Braille 디스플레이로 액세스 설정
-
/etc/brltty.conf
파일을 열고 애플리케이션 프로그래밍 인터페이스 매개 변수 라는 섹션을 찾습니다. 사용자를 지정합니다.
하나 이상의 개별 사용자를 지정하려면 다음 줄에 사용자를 나열합니다.
api-parameters Auth=user:
user_1, user_2, ...
# Allow some local user사용자 그룹을 지정하려면 다음 줄에 이름을 입력합니다.
api-parameters Auth=group:
group
# Allow some local group
/etc/brlapi.key
를 사용하여 Braille 디스플레이로 액세스 설정
/etc/brlapi.key
파일을 만듭니다.~]# mcookie > /etc/brlapi.key
/etc/brlapi.key
의 소유권을 특정 사용자 또는 그룹으로 변경합니다.개별 사용자를 지정하려면 다음을 수행합니다.
~]# chown user_1 /etc/brlapi.key
그룹을 지정하려면 다음을 수행합니다.
~]# chown group_1 /etc/brlapi.key
다음을 포함하도록
/etc/brltty.conf
의 내용을 조정합니다.api-parameters Auth=keyfile:
/etc/brlapi.key
Braille 드라이버 설정
/etc/brltty.conf
의 braille-driver
지시문은 braille 디스플레이에 대한 드라이버의 2자 드라이버 식별 코드를 지정합니다.
Braille 드라이버 설정
적절한 braille 드라이버를 찾기 위해 자동 감지를 사용할지 여부를 결정합니다.
자동 감지를 사용하려면 기본 옵션인
auto
에 지정된braille 드라이버를
남겨 둡니다.braille-driver
auto
# autodetect주의자동 감지는 모든 드라이버를 시도합니다. 따라서 시간이 오래 걸리거나 실패할 수도 있습니다. 따라서 특정 braille 드라이버를 설정하는 것이 좋습니다.
자동 감지를 사용하지 않으려면
braille-driver
지시문에 필요한 braille 드라이버의 식별 코드를 지정합니다./etc/brltty.conf
에 제공된 목록에서 필요한 braille 드라이버의 식별 코드를 선택합니다. 예를 들면 다음과 같습니다.braille-driver
xw
# XWindow쉼표로 구분된 여러 드라이버를 설정하고 해당 드라이버 중에서 자동 감지를 수행할 수도 있습니다.
Braille 장치 설정
/etc/brltty.conf
의 braille-device
지시문은 braille 디스플레이가 연결된 장치를 지정합니다. 다음 장치 유형이 지원됩니다( 표 11.1. “Braille 장치 유형 및 Corresponding Syntax”참조).
Braille 장치 유형 | 유형의 구문 |
---|---|
직렬 장치 | serial:path [a] |
USB 장치 | [serial-number] [b] |
Bluetooth 장치 | bluetooth:address |
[a]
상대 경로는 /dev 에 있습니다.
[b]
여기서 대괄호는 선택 사항을 나타냅니다.
|
특정 장치에 대한 설정의 예는 다음과 같습니다.
braille-deviceserial:ttyS0
# First serial device braille-deviceusb:
# First USB device matching braille driver braille-deviceusb:nnnnn
# Specific USB device by serial number braille-devicebluetooth:xx:xx:xx:xx:xx:xx
# Specific Bluetooth device by address
쉼표로 구분된 여러 장치를 설정할 수도 있으며 각 장치는 차례로 검색됩니다.
장치가 직렬로 USB 어댑터로 연결된 경우 braille-device
를 usb:
로 설정하면 작동하지 않습니다. 이 경우 커널이 어댑터용으로 만든 가상 직렬 장치를 식별합니다. 가상 직렬 장치는 다음과 같을 수 있습니다.
serial:ttyUSB0
You can find the actual device name in the kernel messages on the device plug with the following command:
~]# dmesg | fgrep ttyUSB0
Particular Braille 디스플레이에 대한 특정 매개 변수 설정
특정 braille 디스플레이에 대한 특정 매개변수를 설정해야하는 경우 /etc/brltty.conf
에서 braille-parameters
지시문을 사용하십시오. braille-parameters
지시어는 일반적이지 않은 매개변수를 통해 braille 드라이버로 전달합니다. /etc/brltty.conf
의 목록에서 필요한 매개 변수를 선택합니다.
텍스트 테이블 설정
/etc/brltty.conf
의 text-table
지시문은 기호를 인코딩하는 데 사용되는 텍스트 테이블을 지정합니다. 텍스트 테이블에 대한 상대 경로는 /etc/brltty/text/
디렉터리에 있습니다.
텍스트 테이블 설정
- 적절한 텍스트 테이블을 찾기 위해 autoselection을 사용할지 여부를 결정합니다.
자동 선택을 사용하려면
을 그대로 둡니다(기본 옵션인).auto
에 지정된 텍스트 테이블text-table
auto
# locale-based autoselection이렇게 하면
en-nabcc
에 대체되는 로컬 기반 자동 선택이 수행됩니다.자동 선택을 사용하지 않으려면
/etc/brltty.conf
의 목록에서 필요한텍스트 테이블
을 선택합니다.예를 들어 미국 영어의 텍스트 테이블을 사용하려면 다음을 수행합니다.
text-table
en_US
# English (United States)
계약 테이블 설정
/etc/brltty.conf
의 contraction-table
지시문은 약어를 인코딩하는 데 사용되는 테이블을 지정합니다. 특정 계약 테이블에 대한 상대 경로는 /etc/brltty/Contraction/
디렉토리에 있습니다.
/etc/brltty.conf
의 목록에서 필요한 contraction-table
을 선택합니다.
예를 들어, 미국 영어에 대한 계약 표를 사용하려면 등급 2입니다.
contraction-table en-us-g2
# English (US, grade 2)
지정하지 않으면 contraction 테이블이 사용되지 않습니다.
11.2. Always Show Universal Access 메뉴
orca 화면 리더에서 전환하려면 Super+Alt+S 키 조합을 누릅니다. 결과적으로 Universal Access Menu 아이콘이 상단 표시줄에 표시됩니다.
사용자가 Universal Access 메뉴에서 제공된 모든 옵션을 해제하는 경우 아이콘이 사라집니다. 누락된 아이콘은 시각적 장애가 있는 사용자에게 어려움을 초래할 수 있습니다. 시스템 관리자는 Always Show Universal Access Menu
를 전환하여 아이콘의 액세스 가능성을 방지할 수 있습니다. Always Show Universal Access Menu
가 설정되어 있으면 이 메뉴의 모든 옵션이 꺼진 경우에도 아이콘이 상단 표시줄에 표시됩니다.
항상 전환 시 Universal Access 메뉴 표시
- Gnome 설정 메뉴를 열고 를 클릭합니다.
Always Show Universal Access 메뉴로 전환합니다
.선택 사항: 이 메뉴의 모든 옵션이 꺼진 경우에도 상단 표시줄에 Universal Access Menu 아이콘이 표시되는지 확인합니다.
11.3. Boost Synthesis System활성화
기본적으로 orca 는 eSpeak voice synthesizer를 사용하지만 페스티벌 Synthesis System 을 지원합니다. eSpeak 및 페스티벌 help Synthesis System (Festival)의 합성기 둘 다 다르게 인식합니다. 일부 사용자는 기본 eSpeak synthesizer에 대한 페스티벌을 선호할 수 있습니다. 페스티벌을 사용하려면 다음 단계를 따르십시오:
페스티벌 설치 및 부팅에서 실행 중
마비축 설치:
~]# yum install festival festival-freebsoft-utils
부팅 시 페스티벌을 실행합니다.
새
systemd
장치 파일을 생성합니다./etc/systemd/system/
디렉터리에 파일을 만들고 실행 가능하게 만듭니다.~]# touch /etc/systemd/system/festival.service ~]# chmod 664 /etc/systemd/system/festival.service
/usr/bin/festival_server
파일의 스크립트가 페스티벌을 실행하는 데 사용되는지 확인합니다./etc/systemd/system/festival.service
파일에 다음 내용을 추가합니다.[Unit] Description=Festival speech synthesis server [Service] ExecStart=/usr/bin/festival_server Type=simple
새
페스티벌.service
파일이 있음을systemd
에 알립니다.~]# systemctl daemon-reload ~]# systemctl start festival.service
페스티벌.service
를 활성화합니다.~]# systemctl enable festival.service
페스티벌을 위한 보이스 선택
페스티벌 은 여러 가지 음성을 제공합니다.
음성을 사용할 수 있도록 하려면 다음 목록에서 관련 패키지를 설치합니다.
- festvox-awb-arctic-hts
- festvox-bdl-arctic-hts
- festvox-clb-arctic-hts
- festvox-kal-diphone
- festvox-ked-diphone
- festvox-rms-arctic-hts
- festvox-slt-arctic-hts
- hispavoces-pal-diphone
- hispavoces-sfl-diphone
특정 음성에 대한 자세한 정보를 보려면 다음을 수행합니다.
~]# yum info package_name
필요한 음성을 사용할 수 있도록 하려면 이 음성으로 패키지를 설치한 다음 재부팅합니다.
~]# yum install package_name ~]# reboot
12장. OpenSSH
SSH
(Secure Shell)는 클라이언트-서버 아키텍처를 사용하여 두 시스템 간 보안 통신을 용이하게 하고 사용자가 서버 호스트 시스템에 원격으로 로그인할 수 있도록 하는 프로토콜입니다. FTP
또는 Telnet
과 같은 다른 원격 통신 프로토콜과 달리 SSH는 로그인 세션을 암호화하여 침입자가 암호화되지 않은 암호를 수집하는 것을 어렵게 만듭니다.
ssh 프로그램은 telnet
또는 rsh
와 같은 원격 호스트에 로그인하는 데 사용되는 더 오래되고 안전하지 않은 터미널 애플리케이션을 대체하도록 설계되었습니다. scp
라는 관련 프로그램은 rcp
와 같은 호스트 간에 파일을 복사하도록 설계된 이전 프로그램을 대체합니다. 이러한 이전 애플리케이션은 클라이언트와 서버 간에 전송된 암호를 암호화하지 않으므로 가능하면 사용하지 마십시오. 보안 방법을 사용하여 원격 시스템에 로그인하면 클라이언트 시스템과 원격 호스트의 위험이 줄어듭니다.
Red Hat Enterprise Linux에는 일반 OpenSSH 패키지인 openssh, OpenSSH 서버, openssh-server, 클라이언트, openssh-clients 가 포함됩니다. OpenSSH 패키지에는 몇 가지 중요한 암호화 라이브러리를 설치하여 OpenSSH가 암호화된 통신을 제공할 수 있도록 하는 OpenSSL 패키지 openssl-libs 가 필요합니다.
12.1. SSH 프로토콜
12.1.1. SSH를 사용하는 이유는 무엇입니까?
잠재적인 침입자는 시스템에 액세스하기 위해 네트워크 트래픽을 중단, 인터셉트하고 다시 라우팅할 수 있도록 다양한 도구를 폐기하고, 가로채고, 다시 라우팅할 수 있도록 합니다. 일반적으로 이러한 위협은 다음과 같이 분류될 수 있습니다:
- 두 시스템 간의 통신 차단
공격자는 통신 당사자 간의 네트워크에 있을 수 있으며, 그 사이에 전달된 정보를 복사하십시오. 그는 정보를 가로채거나 보관하거나 정보를 변경하고 의도된 수신자에게 보낼 수 있습니다.
이 공격은 일반적으로 패킷 스니퍼 (Sniffer)를 사용하여 수행되며, 네트워크를 통해 이동하는 각 패킷을 캡처하고 콘텐츠를 분석하는 다소 일반적인 네트워크 유틸리티입니다.
- 특정 호스트 가장
공격자의 시스템은 의도된 전송 수신자로서 발생하도록 구성되어 있습니다. 이 전략이 작동하는 경우 사용자의 시스템은 잘못된 호스트와 통신하는 것을 인식하지 못합니다.
이 공격은 DNS 중독 이라는 기술을 사용하거나 IP 스푸핑 을 통해 수행 할 수 있습니다. 첫 번째 경우, 침입자는 분산된 DNS 서버를 사용하여 클라이언트 시스템을 악의적인 중복 호스트를 가리킵니다. 두 번째 경우, 침입자는 신뢰할 수 있는 호스트에서 나타나는 falsified 네트워크 패킷을 보냅니다.
두 기술 모두 잠재적으로 민감한 정보를 인터셉트하고, 적대적인 이유로 가로채기된 경우, 결과는 해체될 수 있습니다. SSH가 원격 쉘 로그인 및 파일 복사에 사용되는 경우 이러한 보안 위협은 크게 저하될 수 있습니다. 이는 SSH 클라이언트와 서버가 디지털 서명을 사용하여 ID를 확인하기 때문입니다. 또한 클라이언트와 서버 시스템 간의 모든 통신이 암호화됩니다. 각 패킷은 로컬 및 원격 시스템에서 알려진 키를 사용하여 암호화되므로 통신 양쪽의 ID를 스푸핑하려고 합니다.
12.1.2. 주요 기능
SSH 프로토콜은 다음과 같은 보안 장치를 제공합니다.
- 원하는 서버를 지정할 수 없습니다.
- 초기 연결 후 클라이언트는 이전에 연결된 동일한 서버에 연결되어 있는지 확인할 수 있습니다.
- 아무도 인증 정보를 캡처할 수 없습니다.
- 클라이언트는 강력한 128비트 암호화를 사용하여 인증 정보를 서버로 전송합니다.
- 아무도 통신을 가로 둘 수 없습니다.
- 세션 중에 전송 및 수신되는 모든 데이터는 128비트 암호화를 사용하여 전송되므로 가로채기된 전송은 암호 해독 및 읽기가 매우 어렵습니다.
또한 다음 옵션을 제공합니다.
- 네트워크를 통해 그래픽 애플리케이션을 사용할 수 있는 안전한 방법을 제공합니다.
- X11 전달 이라는 기술을 사용하여 클라이언트는 서버에서 X11 (X Window System) 애플리케이션을 전달할 수 있습니다.
- 다른 안전하지 않은 프로토콜을 보호하는 방법을 제공합니다.
- SSH 프로토콜은 전송하는 모든 것을 암호화합니다. 포트 전달 이라는 기술을 사용하여 SSH 서버는 POP 와 같은 안전하지 않은 프로토콜을 보호하고 전체 시스템 및 데이터 보안을 늘리는 데 도움이 될 수 있습니다.
- 보안 채널을 생성하는 데 사용할 수 있습니다.
- OpenSSH 서버와 클라이언트는 서버와 클라이언트 시스템 간의 트래픽에 대해 가상 사설 네트워크와 유사한 터널을 생성하도록 구성할 수 있습니다.
- Kerberos 인증을 지원합니다.
- OpenSSH 서버 및 클라이언트는 Kerberos 네트워크 인증 프로토콜의 GSSAPI (Generic Security Services Application Program Interface) 구현을 사용하여 인증할 수 있습니다.
12.1.3. 프로토콜 버전
현재 SSH의 두 가지 유형이 있습니다: 버전 1 및 최신 버전 2. Red Hat Enterprise Linux 7의 OpenSSH 제품군은 SSH 버전 2를 사용하며, 버전 1의 알려진 취약점에는 영향을 받지 않는 향상된 키 교환 알고리즘이 있습니다. Red Hat Enterprise Linux 7에서 OpenSSH 제품군은 버전 1 연결을 지원하지 않습니다.
12.1.4. SSH 연결의 이벤트 순서
다음 일련의 이벤트는 두 호스트 간의 SSH 통신 무결성을 보호하는 데 도움이 됩니다.
- 클라이언트가 올바른 서버와 통신하는지 확인할 수 있도록 암호화 핸드셰이크를 만듭니다.
- 클라이언트와 원격 호스트 간 연결 전송 계층은 대칭 암호를 사용하여 암호화됩니다.
- 클라이언트는 서버에 대해 자체적으로 인증합니다.
- 클라이언트는 암호화된 연결을 통해 원격 호스트와 상호 작용합니다.
12.1.4.1. 전송 계층
전송 계층의 주요 역할은 인증 시점과 후속 통신 중에 두 호스트 간의 안전하고 안전한 통신을 용이하게 하는 것입니다. 전송 계층은 데이터의 암호화 및 암호 해독을 처리하고 전송 및 수신 시 데이터 패킷의 무결성 보호 기능을 제공하여 이를 수행합니다. 전송 계층은 또한 압축을 제공하여 정보 전송 속도를 높입니다.
SSH 클라이언트가 서버에 접속하면 두 시스템이 전송 계층을 올바르게 구성할 수 있도록 키 정보가 교환됩니다. 이 교환 중에 다음 단계가 수행됩니다.
- 키가 교환됩니다.
- 공개 키 암호화 알고리즘이 결정됨
- 대칭 암호화 알고리즘이 결정됩니다.
- 메시지 인증 알고리즘이 결정됨
- 해시 알고리즘이 결정됩니다.
키 교환 중에 서버는 고유한 호스트 키가 있는 클라이언트 자체를 식별합니다. 클라이언트가 이전에 이 특정 서버와 통신하지 않은 경우 서버의 호스트 키는 클라이언트에 알 수 없으며 연결되지 않습니다. OpenSSH는 서버의 호스트 키를 수락하여 이 문제를 해결합니다. 이는 사용자에게 알림을 받은 후 수행되며 새 호스트 키를 승인하고 검증했습니다. 후속 연결에서 서버의 호스트 키가 클라이언트의 저장된 버전과 비교하여 클라이언트가 실제로 의도된 서버와 통신한다는 확신을 제공합니다. 나중에 호스트 키가 더 이상 일치하지 않으면 연결이 이루어지기 전에 사용자가 클라이언트의 저장된 버전을 제거해야 합니다.
공격자는 로컬 시스템이 의도한 서버와 공격자가 설정한 거짓 서버 간의 차이점을 알지 못하기 때문에 초기 연결 중에 SSH 서버로 가장할 수 있습니다. 이 문제를 방지하려면 호스트 키가 일치하지 않는 경우 처음으로 연결되기 전에 서버 관리자에게 문의하여 새 SSH 서버의 무결성을 확인합니다.
SSH는 거의 모든 종류의 공개 키 알고리즘 또는 인코딩 형식으로 작동하도록 설계되었습니다. 초기 키 교환이 교환 및 공유 비밀 값에 사용되는 해시 값을 생성한 후 두 시스템은 연결을 통해 전송된 인증 및 향후 데이터를 보호하기 위해 새 키와 알고리즘을 즉시 계산하기 시작합니다.
지정된 키와 알고리즘을 사용하여 특정 양의 데이터를 전송한 후( 정확하게는 SSH 구현에 따라 다름) 다른 키 교환이 발생하고 다른 해시 값 세트와 새 공유 시크릿 값을 생성합니다. 공격자가 해시 및 공유 비밀 값을 결정할 수 있더라도 이 정보는 제한된 기간 동안만 유용합니다.
12.1.4.2. 인증
전송 계층에서 두 시스템 간에 정보를 전달하도록 보안 터널을 구성하면 서버는 개인 키 인코딩 서명을 사용하거나 암호 입력과 같은 다양한 인증 방법을 클라이언트에 알립니다. 그런 다음 클라이언트는 지원되는 방법 중 하나를 사용하여 서버에 자신을 인증하려고 합니다.
SSH 서버와 클라이언트는 다양한 유형의 인증을 허용하도록 구성할 수 있으므로 각 측에서 최적의 제어 용량을 제공합니다. 서버는 보안 모델에 따라 지원되는 암호화 방법을 결정할 수 있으며 클라이언트는 사용 가능한 옵션에서 시도할 인증 방법 순서를 선택할 수 있습니다.
12.1.4.3. 채널
SSH 전송 계층을 성공적으로 인증한 후 멀티플렉싱이라는 기술을 통해 여러 채널을 열 수 있습니다.[1]. 이러한 각 채널은 서로 다른 터미널 세션에 대한 통신과 전달된 X11 세션의 통신을 처리합니다.
클라이언트와 서버 모두 새 채널을 생성할 수 있습니다. 그런 다음 각 채널에 연결 끝에 다른 번호가 할당됩니다. 클라이언트가 새 채널을 열려고 하면 클라이언트는 요청과 함께 채널 번호를 보냅니다. 이러한 정보는 서버에 의해 저장되고, 그 채널로 통신할 때 사용됩니다. 이는 다른 유형의 세션이 서로 영향을 미치지 않도록 하기 때문에 지정된 세션이 종료될 때 기본 SSH 연결을 중단하지 않고 채널을 닫을 수 있습니다.
채널은 또한 흐름 제어 기능을 지원하므로 데이터를 순서대로 전송하고 받을 수 있습니다. 이러한 방식으로 클라이언트는 채널이 열려 있는 메시지를 수신할 때까지 데이터를 채널을 통해 전송되지 않습니다.
클라이언트 및 서버는 클라이언트가 요청하는 서비스 유형과 사용자가 네트워크에 연결된 방식에 따라 각 채널의 특성을 자동으로 협상합니다. 따라서 프로토콜의 기본 인프라를 변경하지 않고도 다양한 유형의 원격 연결을 유연하게 처리할 수 있습니다.
12.2. OpenSSH 구성
12.2.1. 구성 파일
클라이언트 프로그램(즉, ssh
,scp
, sftp
)과 서버( sshd
데몬)의 두 가지 구성 파일 세트가 있습니다.
시스템 전체 SSH 구성 정보는 표 12.1. “시스템 전체 구성 파일” 에 설명된 대로 /etc/ssh/
디렉토리에 저장됩니다. 사용자별 SSH 구성 정보는 표 12.2. “사용자별 구성 파일” 에 설명된 대로 사용자의 홈 디렉터리 내의 ~/.ssh/
에 저장됩니다.
파일 | 설명 |
---|---|
| 보안 전송 계층을 구성하는 데 중요한 Diffie-Hellman 키 교환에 사용되는 Diffie-Hellman 그룹이 포함되어 있습니다. SSH 세션이 시작될 때 키를 교환하는 경우 공유 비밀 값이 생성되어 어느 당사자만 단독으로 확인할 수 없습니다. 그러면 이 값이 호스트 인증을 제공하는 데 사용됩니다. |
|
기본 SSH 클라이언트 구성 파일. |
|
|
|
|
|
|
|
SSH 프로토콜의 버전 2에 대해 |
|
SSH 프로토콜의 버전 2에 대해 |
|
|
|
|
파일 | 설명 |
---|---|
| 서버에 대해 인증된 공개 키 목록이 있습니다. 클라이언트가 서버에 연결하면 서버는 이 파일 내에 저장된 서명된 공개 키를 확인하여 클라이언트를 인증합니다. |
| 사용자의 ECDSA 개인 키를 포함합니다. |
| ECDSA 사용자의 공개 키입니다. |
|
SSH 프로토콜의 버전 2에 대해 |
|
SSH 프로토콜의 버전 2에 대해 |
| 사용자가 액세스하는 SSH 서버의 호스트 키가 포함되어 있습니다. 이 파일은 SSH 클라이언트가 올바른 SSH 서버에 연결되어 있는지 확인하는 데 매우 중요합니다. |
SSH 서버를 설정하는 경우 /etc/ssh/sshd_config
파일에서 UsePrivilegeSeparation no 지시문을 사용하여 Privilege Separation
기능을 해제하지 마십시오. Privilege Separation
을 사용하면 많은 보안 기능을 비활성화하고 서버가 잠재적인 보안 취약점 및 대상 공격에 노출됩니다. UsePrivilegeSeparation 에 대한 자세한 내용은 sshd_config
(5) 매뉴얼 페이지 또는 /etc/ssh/sshd_config 파일에서 UsePrivilegeSeparation 지시문의 중요도 및 테스트 방법을참조하십시오. Red Hat 지식베이스 문서.
SSH 구성 파일에서 사용할 수 있는 다양한 지시문에 대한 자세한 내용은 ssh_config
(5) 및 sshd_config
(5) 매뉴얼 페이지를 참조하십시오.
12.2.2. OpenSSH 서버 시작
OpenSSH 서버를 실행하려면 openssh-server 패키지가 설치되어 있어야 합니다. 새 패키지를 설치하는 방법에 대한 자세한 내용은 9.2.4절. “패키지 설치” 을 참조하십시오.
현재 세션에서 sshd
데몬을 시작하려면 쉘 프롬프트에 root
로 다음을 입력합니다.
~]# systemctl start sshd.service
현재 세션에서 실행 중인 sshd
데몬을 중지하려면 root
로 다음 명령을 사용합니다.
~]# systemctl stop sshd.service
데몬이 부팅 시 자동으로 시작되도록 하려면 root
로 다음을 입력합니다.
~]# systemctl enable sshd.service Created symlink from /etc/systemd/system/multi-user.target.wants/sshd.service to /usr/lib/systemd/system/sshd.service.
sshd
데몬은 정적 구성된 네트워크 인터페이스 및 기본 ListenAddress
0.0.0.0
옵션에는 충분한 network.target
대상 유닛에 따라 다릅니다. ListenAddress
지시문에서 다른 주소를 지정하고 느린 동적 네트워크 구성을 사용하려면 network-online.target
대상 유닛에 대한 종속성을 sshd.service
유닛 파일에 추가합니다. 이를 위해 다음 옵션을 사용하여 /etc/systemd/system/sshd.service.d/local.conf
파일을 만듭니다.
[Unit] Wants=network-online.target
After=network-online.target
이 후 다음 명령을 사용하여 systemd
관리자 구성을 다시 로드합니다.
~]# systemctl daemon-reload
Red Hat Enterprise Linux에서 시스템 서비스를 관리하는 방법에 대한 자세한 내용은 10장. systemd를 사용하여 서비스 관리 를 참조하십시오.
시스템을 다시 설치하면 새로운 식별 키 세트가 생성됩니다. 그 결과 다시 설치하기 전에 OpenSSH 도구를 사용하여 시스템에 연결한 클라이언트는 다음 메시지가 표시됩니다.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed.
이를 방지하려면 /etc/ssh/
디렉토리에서 관련 파일을 백업할 수 있습니다. 전체 목록은 표 12.1. “시스템 전체 구성 파일” 을 참조하고 시스템을 다시 설치할 때마다 파일을 복원하십시오.
12.2.3. 원격 연결에 SSH 필요
SSH가 실제로 효과적이기 위해서는 안전하지 않은 연결 프로토콜을 사용하는 것은 금지되어야 합니다. 그렇지 않으면 사용자 암호는 한 세션에 대해 SSH를 사용하여 보호할 수 있으며, Telnet을 사용하여 로그인하는 동안 나중에 캡처할 수 있습니다. 비활성화하는 일부 서비스에는 telnet
, rsh,
rlogin
, rootfs 등이 있습니다
.
vsftpd
서비스를 구성하는 방법에 대한 자세한 내용은 16.2절. “FTP” 을 참조하십시오. Red Hat Enterprise Linux 7에서 시스템 서비스를 관리하는 방법을 알아보려면 10장. systemd를 사용하여 서비스 관리 를 참조하십시오.
12.2.4. 키 기반 인증 사용
시스템 보안을 더욱 개선하려면 SSH 키 쌍을 생성한 다음 암호 인증을 비활성화하여 키 기반 인증을 적용합니다. 이렇게 하려면 vi 또는 nano 와 같은 텍스트 편집기에서 /etc/ssh/sshd_config
구성 파일을 열고 PasswordAuthentication
옵션을 다음과 같이 변경합니다.
PasswordAuthentication no
새 기본 설치 이외의 시스템에서 작업하는 경우 PubkeyAuthentication no
가 설정되지 않았는지 확인합니다. 콘솔 또는 대역 외 액세스를 사용하지 않는 원격으로 연결된 경우 암호 인증을 비활성화하기 전에 키 기반 로그인 프로세스를 테스트하는 것이 좋습니다.
ssh
,scp
또는 sftp
를 사용하여 클라이언트 시스템에서 서버에 연결하려면 아래 단계에 따라 권한 부여 키 쌍을 생성합니다. 각 사용자에 대해 키를 개별적으로 생성해야 합니다.
NFS가 마운트된 홈 디렉터리에 키 기반 인증을 사용하려면 use_nfs_home_dirs
SELinux 부울을 먼저 활성화합니다.
~]# setsebool -P use_nfs_home_dirs 1
Red Hat Enterprise Linux 7은 기본적으로 SSH 프로토콜 2 및 RSA 키를 사용합니다(자세한 내용은 12.1.3절. “프로토콜 버전” 참조).
단계를 root
로 완료하면 root
만 키를 사용할 수 있습니다.
시스템을 다시 설치하고 이전에 생성된 키 쌍을 유지하려면 ~/.ssh/
디렉터리를 백업합니다. 다시 설치한 후 홈 디렉터리로 복사합니다. 이 프로세스는 root
를 포함하여 시스템의 모든 사용자에 대해 수행할 수 있습니다.
12.2.4.1. 키 쌍 생성
SSH 프로토콜 버전 2에 대한 RSA 키 쌍을 생성하려면 다음 단계를 따르십시오.
쉘 프롬프트에서 다음을 입력하여 RSA 키 쌍을 생성합니다.
~]$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/USER/.ssh/id_rsa):
-
새로 생성된 키에 대해 Enter 를 눌러 기본 위치인
~/.ssh/id_rsa
를 확인합니다. 암호를 입력하고 암호를 입력하라는 메시지가 표시되면 다시 입력하여 확인합니다. 보안상의 이유로, 계정에 로그인하는 데 사용하는 것과 동일한 비밀번호를 사용하지 마십시오.
그러면 다음과 같은 메시지가 표시됩니다.
Your identification has been saved in /home/USER/.ssh/id_rsa. Your public key has been saved in /home/USER/.ssh/id_rsa.pub. The key fingerprint is: SHA256:UNIgIT4wfhdQH/K7yqmjsbZnnyGDKiDviv492U5z78Y \USER@penguin.example.com The key's randomart image is: +---[RSA 2048]----+ |o ..==o+. | |.+ . .=oo | | .o. ..o | | ... .. | | .S | |o . . | |o+ o .o+ .. | |+.++=o*.o .E | |BBBo+Bo. oo | +----[SHA256]-----+
참고이전 버전의 기본 지문인 MD5 키 지문을 가져오려면
-E md5
옵션과 함께ssh-keygen
명령을 사용합니다.기본적으로
~/.ssh/
디렉터리의 권한은 8진수 표기법으로 표시된rwx
----또는
700으로 설정됩니다. 이는 USER 만 콘텐츠를 볼 수 있도록 하기 위한 것입니다. 필요한 경우 다음 명령을 사용하여 확인할 수 있습니다.~]$
ls -ld ~/.ssh
drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/공개 키를 원격 머신에 복사하려면 다음 형식으로 명령을 실행합니다.
ssh-copy-id user@hostname
이렇게 하면 가장 최근에 수정된
~/.ssh/id*.pub
공개 키가 아직 설치되지 않은 경우 복사됩니다. 또는 다음과 같이 공개 키의 파일 이름을 지정합니다.ssh-copy-id -i ~/.ssh/id_rsa.pub user@hostname
그러면
~/.ssh/id_rsa.pub
의 콘텐츠가 연결하려는 머신의~/.ssh/authorized_keys
파일에 복사됩니다. 파일이 이미 있는 경우 키는 해당 끝에 추가됩니다.
SSH 프로토콜 버전 2에 대한 ECDSA 키 쌍을 생성하려면 다음 단계를 따르십시오.
쉘 프롬프트에서 다음을 입력하여 ECDSA 키 쌍을 생성합니다.
~]$ ssh-keygen -t ecdsa Generating public/private ecdsa key pair. Enter file in which to save the key (/home/USER/.ssh/id_ecdsa):
-
Enter 를 눌러 새로 생성된 키에 대한 기본 위치
~/.ssh/id_ecdsa
를 확인합니다. 암호를 입력하고 암호를 입력하라는 메시지가 표시되면 다시 입력하여 확인합니다. 보안상의 이유로, 계정에 로그인하는 데 사용하는 것과 동일한 비밀번호를 사용하지 마십시오.
그러면 다음과 같은 메시지가 표시됩니다.
Your identification has been saved in /home/USER/.ssh/id_ecdsa. Your public key has been saved in /home/USER/.ssh/id_ecdsa.pub. The key fingerprint is: SHA256:8BhZageKrLXM99z5f/AM9aPo/KAUd8ZZFPcPFWqK6+M \USER@penguin.example.com The key's randomart image is: +---[ECDSA 256]---+ | . . +=| | . . . = o.o| | + . * . o...| | = . . * . + +..| |. + . . So o * ..| | . o . .+ = ..| | o oo ..=. .| | ooo...+ | | .E++oo | +----[SHA256]-----+
기본적으로
~/.ssh/
디렉터리의 권한은 8진수 표기법으로 표시된rwx
----또는
700으로 설정됩니다. 이는 USER 만 콘텐츠를 볼 수 있도록 하기 위한 것입니다. 필요한 경우 다음 명령을 사용하여 확인할 수 있습니다.~]$
ls -ld ~/.ssh
~]$ ls -ld ~/.ssh/ drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/공개 키를 원격 머신에 복사하려면 다음 형식으로 명령을 실행합니다.
ssh-copy-id USER@hostname
이렇게 하면 가장 최근에 수정된
~/.ssh/id*.pub
공개 키가 아직 설치되지 않은 경우 복사됩니다. 또는 다음과 같이 공개 키의 파일 이름을 지정합니다.ssh-copy-id -i ~/.ssh/id_ecdsa.pub USER@hostname
그러면
~/.ssh/id_ecdsa.pub
의 콘텐츠가 연결하려는 머신의~/.ssh/authorized_keys
에 복사됩니다. 파일이 이미 있는 경우 키는 해당 끝에 추가됩니다.
암호를 기억하도록 시스템을 설정하는 방법에 대한 자세한 내용은 12.2.4.2절. “ssh-agent 구성” 을 참조하십시오.
개인 키는 개인 용도로만 사용되며, 절대 사용자에게 제공하지 않는 것이 중요합니다.
12.2.4.2. ssh-agent 구성
원격 시스템과의 연결을 시작할 때마다 암호를 입력하지 않도록 암호를 저장하려면 ssh-agent
인증 에이전트를 사용할 수 있습니다. GNOME을 실행하는 경우 로그인할 때마다 암호를 묻는 메시지를 표시하고 전체 세션 중에 이를 기억하도록 구성할 수 있습니다. 그렇지 않으면 특정 쉘 프롬프트에 대해 암호를 저장할 수 있습니다.
GNOME 세션 중에 암호를 저장하려면 다음 단계를 따르십시오.
- openssh-askpass 패키지가 설치되어 있는지 확인합니다. 그렇지 않은 경우 Red Hat Enterprise Linux에 새 패키지를 설치하는 방법에 대한 자세한 내용은 9.2.4절. “패키지 설치” 를 참조하십시오.
Super 키를 눌러 활동 개요를 입력하고
시작 애플리케이션을
입력한 다음 Enter 를 누릅니다. 시작 애플리케이션 환경 설정 도구가 표시됩니다. 사용 가능한 시작 프로그램 목록이 포함된 탭에는 기본적으로 표시됩니다. Super 키는 키보드와 기타 하드웨어에 따라 다양한 길잡이에 표시되지만 일반적으로 공간 표시줄의 왼쪽에 Windows 또는 Command 키로 나타납니다.그림 12.1. 시작 애플리케이션 기본 설정
오른쪽에 있는
버튼을 클릭하고Command
필드에/usr/bin/ssh-add
를 입력합니다.그림 12.2. 새 애플리케이션 추가
그림 12.3. 애플리케이션 활성화
로그아웃한 다음 다시 로그인합니다. 암호를 묻는 대화 상자가 나타납니다. 이 시점에서
ssh
,scp
또는sftp
를 통해 암호를 입력하라는 메시지가 표시되지 않아야 합니다.그림 12.4. 암호를 입력
특정 쉘 프롬프트에 대한 암호를 저장하려면 다음 명령을 사용하십시오.
~]$ ssh-add Enter passphrase for /home/USER/.ssh/id_rsa:
로그아웃하면 암호가 잊혀집니다. 가상 콘솔 또는 터미널 창에 로그인할 때마다 명령을 실행해야 합니다.
12.3. OpenSSH 클라이언트
클라이언트 머신에서 OpenSSH 서버에 연결하려면 openssh-clients 패키지가 설치되어 있어야 합니다( 9.2.4절. “패키지 설치” Red Hat Enterprise Linux에 새 패키지를 설치하는 방법에 대한 자세한 내용은 를 참조하십시오.
12.3.1. ssh utility 사용
ssh
유틸리티를 사용하면 원격 시스템에 로그인하고 명령을 실행할 수 있습니다. rlogin
, rsh,
telnet
프로그램을 대체합니다.
telnet
명령과 마찬가지로 다음 명령을 사용하여 원격 머신에 로그인합니다.
ssh
hostname
예를 들어 이름이 Penguin .example.com
인 원격 시스템에 로그인하려면 쉘 프롬프트에서 다음을 입력합니다.
~]$ ssh penguin.example.com
그러면 로컬 시스템에서 사용하는 것과 동일한 사용자 이름으로 로그인합니다. 다른 사용자 이름을 지정하려면 다음 양식에서 명령을 사용합니다.
ssh
username@hostname
예를 들어, Penguin .example.com
에 USER
로 로그인하려면 다음을 입력합니다.
~]$ ssh USER@penguin.example.com
연결을 처음 시작하면 다음과 유사한 메시지가 표시됩니다.
The authenticity of host 'penguin.example.com' can't be established. ECDSA key fingerprint is SHA256:vuGKK9dsW34zrZzwjl5g+vOE6EZQvHRQ8zObKYO2mW4. ECDSA key fingerprint is MD5:7e:15:c3:03:4d:e1:dd:ee:99:dc:3e:f4:b9:67:6b:62. Are you sure you want to continue connecting (yes/no)?
사용자는 이 대화 상자의 질문에 대답하기 전에 지문이 올바른지 항상 확인해야 합니다. 사용자는 서버 관리자에게 키가 올바른지 확인하도록 요청할 수 있습니다. 이는 안전하고 이전에 동의한 방식으로 수행되어야 합니다. 사용자가 서버의 호스트 키에 액세스할 수 있는 경우 다음과 같이 ssh-keygen
명령을 사용하여 지문을 확인할 수 있습니다.
~]# ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub SHA256:vuGKK9dsW34zrZzwjl5g+vOE6EZQvHRQ8zObKYO2mW4
이전 버전의 기본 지문인 MD5 키 지문을 가져오려면 -E md5
옵션과 함께 ssh-keygen
명령을 사용합니다.
~]# ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub -EM md5 MD5:7e:15:c3:03:4d:e1:dd:ee:99:dc:3e:f4:b9:67:6b:62
yes
를 입력하여 키를 승인하고 연결을 확인합니다. 서버가 알려진 호스트 목록에 추가되었으며 암호를 묻는 프롬프트가 표시됩니다.
Warning: Permanently added 'penguin.example.com' (ECDSA) to the list of known hosts. \USER@penguin.example.com's password:
SSH 서버의 호스트 키가 변경되면 클라이언트는 서버의 호스트 키가 ~/.ssh/known_hosts
파일에서 삭제될 때까지 연결을 진행할 수 없음을 사용자에게 알립니다. 그러나 이 작업을 수행하기 전에 SSH 서버의 시스템 관리자에게 문의하여 서버가 손상되지 않았는지 확인합니다.
~/.ssh/known_hosts
파일에서 키를 제거하려면 다음과 같이 명령을 실행합니다.
~]# ssh-keygen -R penguin.example.com
# Host penguin.example.com found: line 15 type ECDSA
/home/USER/.ssh/known_hosts updated.
Original contents retained as /home/USER/.ssh/known_hosts.old
암호를 입력하면 원격 시스템에 대한 쉘 프롬프트가 제공됩니다.
또는 ssh
프로그램을 사용하여 쉘 프롬프트에 로그인하지 않고 원격 시스템에서 명령을 실행할 수 있습니다.
ssh
username@hostname command
예를 들어 /etc/redhat-release
파일은 Red Hat Enterprise Linux 버전에 대한 정보를 제공합니다. Penguin .example.com 에서 이 파일의 내용을 보려면 다음을 입력합니다.
~]$ ssh USER@penguin.example.com cat /etc/redhat-release
USER@penguin.example.com's password:
Red Hat Enterprise Linux Server release 7.0 (Maipo)
올바른 암호를 입력하면 사용자 이름이 표시되고 로컬 쉘 프롬프트로 돌아갑니다.
12.3.2. scp
utility 사용
SCP
는 안전하고 암호화된 연결을 통해 컴퓨터 간에 파일을 전송하는 데 사용할 수 있습니다. 그 설계에서는 rcp
와 매우 유사합니다.
로컬 파일을 원격 시스템으로 전송하려면 다음 형식으로 명령을 사용합니다.
scp localfile username@hostname:remotefile
예를 들어 taglist.vim
을 Penguin. example.com
이라는 원격 시스템으로 전송하려면 쉘 프롬프트에서 다음을 입력합니다.
~]$ scp taglist.vim USER@penguin.example.com:.vim/plugin/taglist.vim
USER@penguin.example.com's password:
taglist.vim 100% 144KB 144.5KB/s 00:00
여러 파일을 한 번에 지정할 수 있습니다. .vim/plugin/
의 콘텐츠를 원격 시스템 Penguin .example.com
의 동일한 디렉터리에 전송하려면 다음 명령을 입력합니다.
~]$ scp .vim/plugin/* \USER@penguin.example.com:.vim/plugin/ \USER@penguin.example.com's password: closetag.vim 100% 13KB 12.6KB/s 00:00 snippetsEmu.vim 100% 33KB 33.1KB/s 00:00 taglist.vim 100% 144KB 144.5KB/s 00:00
원격 파일을 로컬 시스템으로 전송하려면 다음 구문을 사용합니다.
scp username@hostname:remotefile localfile
예를 들어 원격 머신에서 .vimrc
구성 파일을 다운로드하려면 다음을 입력합니다.
~]$ scp USER@penguin.example.com:.vimrc .vimrc
USER@penguin.example.com's password:
.vimrc 100% 2233 2.2KB/s 00:00
12.3.3. sftp
유틸리티 사용
sftp
유틸리티를 사용하여 안전하고 대화형 FTP 세션을 열 수 있습니다. 그 설계에서는 안전한 암호화된 연결을 사용하는 것을 제외하고는 ftp
와 유사합니다.
원격 시스템에 연결하려면 다음 형식으로 명령을 사용합니다.
sftp username@hostname
예를 들어 USER
를 사용자 이름으로 사용하여 이름이 Penguin .example.com
인 원격 시스템에 로그인하려면 다음을 입력합니다.
~]$ sftp USER@penguin.example.com
USER@penguin.example.com's password:
Connected to penguin.example.com.
sftp>
올바른 암호를 입력하면 프롬프트가 표시됩니다. sftp
유틸리티는 ftp
에서 사용하는 것과 유사한 명령 집합을 허용합니다( 표 12.3. “사용 가능한 sftp 명령 선택”참조).
명령 | 설명 |
---|---|
| 원격 디렉터리 의 내용을 나열합니다. 제공되지 않으면 기본적으로 현재 작업 디렉터리가 사용됩니다. |
| 원격 작업 디렉터리를 디렉터리로 변경합니다. |
| 원격 디렉터리 를 만듭니다. |
| 원격 디렉터리 를 제거합니다. |
localfile [remotefile] | localfile 을 원격 시스템으로 전송합니다. |
| 원격 시스템에서 remotefile 을 전송합니다. |
사용 가능한 명령의 전체 목록은 sftp
(1) 매뉴얼 페이지를 참조하십시오.
12.4. 더 많은 Than a Secure Shell
보안 명령줄 인터페이스는 SSH를 사용하는 여러 방법의 시작일 뿐입니다. 적절한 대역폭을 고려하여 X11 세션을 SSH 채널을 통해 전달할 수 있습니다. 또는 TCP/IP 전달을 사용하여 이전에 시스템 간 비보안 포트 연결을 특정 SSH 채널에 매핑할 수 있습니다.
12.4.1. X11 전달
SSH 연결을 통해 X11 세션을 시작하려면 다음 양식에서 명령을 사용합니다.
ssh -Y username@hostname
예를 들어 USER
를 사용자 이름으로 사용하여 이름이 Penguin .example.com
인 원격 시스템에 로그인하려면 다음을 입력합니다.
~]$ ssh -Y USER@penguin.example.com
USER@penguin.example.com's password:
X 프로그램이 보안 쉘 프롬프트에서 실행되면 SSH 클라이언트와 서버는 새 보안 채널을 생성하고 X 프로그램 데이터가 해당 채널을 통해 클라이언트 시스템으로 투명하게 전송됩니다.
X11 전송이 수행되기 전에 X Window 시스템을 원격 시스템에 설치해야 합니다. 다음 명령을 root
로 입력하여 X11 패키지 그룹을 설치합니다.
~]# yum group install "X Window System"
패키지 그룹에 대한 자세한 내용은 9.3절. “패키지 그룹 작업” 을 참조하십시오.
X11 전송은 매우 유용할 수 있습니다. 예를 들어 X11 전달을 사용하여 인쇄 설정 유틸리티의 안전하고 대화형 세션을 만들 수 있습니다. 이렇게 하려면 ssh 를 사용하여 서버에 연결하고 다음을 입력합니다.
~]$ system-config-printer &
인쇄 설정 도구가 표시되므로 원격 사용자가 원격 시스템에서 안전하게 인쇄를 설정할 수 있습니다.
12.4.2. 포트 전달
SSH는 포트 전달을 통해 안전하지 않은 TCP/IP
프로토콜을 보호할 수 있습니다. 이 기술을 사용하는 경우 SSH 서버는 SSH 클라이언트에 대한 암호화된 컨덕션이 됩니다.
포트 전달은 클라이언트의 로컬 포트를 서버의 원격 포트에 매핑하여 작동합니다. SSH는 서버의 모든 포트를 클라이언트의 모든 포트에 매핑할 수 있습니다. 포트 번호는 이 기술이 작동하기 위해 일치할 필요가 없습니다.
1024 미만의 포트에서 수신 대기하도록 포트 전달을 설정하려면 루트
수준 액세스가 필요합니다.
localhost
에서 연결을 수신 대기하는 TCP/IP 포트 전달 채널을 생성하려면 다음 양식에서 명령을 사용합니다.
ssh -L local-port:remote-hostname:remote-port username@hostname
예를 들어 암호화된 연결을 통해 POP3
을 사용하여 mail.example.com
이라는 서버의 이메일을 확인하려면 다음 명령을 사용합니다.
~]$ ssh -L 1100:mail.example.com:110 mail.example.com
클라이언트 시스템과 메일 서버 간에 포트 전달 채널이 배치되면 POP3 메일 클라이언트에 localhost
에서 포트 1100
을 사용하여 새 이메일을 확인합니다. 클라이언트 시스템의 포트 1100
으로 전송된 모든 요청은 mail.example.com
서버로 안전하게 전달됩니다.
mail.example.com
이 SSH 서버를 실행하지 않지만 동일한 네트워크의 다른 시스템이 있는 경우 SSH를 사용하여 연결의 일부를 보호할 수 있습니다. 그러나 약간 다른 명령이 필요합니다.
~]$ ssh -L 1100:mail.example.com:110 other.example.com
이 예에서 클라이언트 머신의 포트 1100
의 POP3 요청은 포트 22
에서 SSH 서버인 other.example.com
으로의 SSH 연결을 통해 전달됩니다. 그런 다음 other.example.com
은 mail.example.com
의 포트 110
에 연결하여 새 이메일을 확인합니다. 이 기술을 사용하는 경우 클라이언트 시스템과 other.example.com
SSH 서버 간의 연결만 안전합니다.
OpenSSH 제품군은 UNIX 도메인 소켓의 로컬 및 원격 포트 전달 기능도 제공합니다. 네트워크를 통해 UNIX 도메인 소켓을 다른 시스템으로 전달하려면 ssh -L local-socket:remote-socket username@hostname
명령을 사용합니다. 예를 들면 다음과 같습니다.
~]$ ssh -L /var/mysql/mysql.sock:/var/mysql/mysql.sock username@hostname
포트 전달을 사용하여 네트워크 방화벽을 통해 정보를 안전하게 가져올 수도 있습니다. 방화벽이 표준 포트(즉, 포트 22)를 통해 SSH 트래픽을 허용하도록 구성되어 있지만 다른 포트에 대한 액세스를 차단하면 기존 SSH 연결을 통해 통신을 리디렉션하여 차단된 포트를 사용하는 두 호스트 간 연결이 계속 가능합니다.
포트 전달을 사용하여 이러한 방식으로 연결을 전달하면 클라이언트 시스템의 모든 사용자가 해당 서비스에 연결할 수 있습니다. 클라이언트 시스템이 손상되면 공격자도 서비스 전달에 액세스할 수 있습니다.
포트 전달과 관련된 시스템 관리자는 /etc/ssh/sshd_config
에서 AllowTcpForwarding
행에 No
매개 변수를 지정하고 sshd
서비스를 다시 시작하여 서버에서 이 기능을 비활성화할 수 있습니다.
12.5. 추가 리소스
Red Hat Enterprise Linux에서 OpenSSH 서버를 구성하거나 연결하는 방법에 대한 자세한 내용은 아래 나열된 리소스를 참조하십시오.
설치된 문서
-
sshd
(8) -sshd
데몬 문서의 수동 페이지에서 사용 가능한 명령줄 옵션 및 지원되는 구성 파일 및 디렉터리의 전체 목록을 제공합니다. -
SSH (1) -
ssh
-
SCP
(1) -scp
유틸리티의 도움말 페이지는 이 유틸리티 및 사용법에 대한 자세한 설명을 제공합니다. -
SFTP (1) -
sftp
-
ssh-keygen
(1) -ssh-keygen
유틸리티 문서의 설명서 페이지에서ssh
에서 사용하는 인증 키를 생성, 관리 및 변환하는 방법을 자세히 설명합니다. -
ssh_config
(5) -ssh_config
문서라는 수동 페이지에서 SSH 클라이언트 구성 옵션을 사용할 수 있습니다. -
sshd_config
(5) -sshd_config
라는 수동 페이지는 사용 가능한 SSH 데몬 구성 옵션에 대한 전체 설명을 제공합니다.
온라인 문서
- OpenSSH 홈 페이지 - 추가 문서, 자주 묻는 질문, 메일링 목록에 대한 링크, 버그 보고서 및 기타 유용한 리소스가 포함된 OpenSSH 홈 페이지.
- OpenSSL 홈 페이지 - 추가 문서, 자주 묻는 질문, 메일링 목록에 대한 링크, 기타 유용한 리소스가 포함된 OpenSSL 홈 페이지
예를 들면 다음과 같습니다.
-
6장. 권한 확보
su
및sudo
명령을 사용하여 관리 권한을 얻는 방법에 대해 설명합니다. -
10장. systemd를 사용하여 서비스 관리
systemctl
명령을 사용하여 시스템 서비스를 관리하는 방법에 대한 systemd 및 문서에 대한 자세한 정보를 제공합니다.
13장. TigerVNC
tigerv
nc(Tiger Virtual Network Computing)는 다른 컴퓨터를 원격으로 제어할 수 있는 그래픽 데스크탑 공유를 위한 시스템입니다.
tigerv
nc는 클라이언트-서버 원칙에 따라 작동합니다. 서버는 출력(vncserver
)과 클라이언트 (vncviewer
)가 서버에 연결됩니다.
이전 Red Hat Enterprise Linux 배포판과 달리, Red Hat Enterprise Linux 7의 TigerVNC
는 systemd
시스템 관리 데몬을 해당 구성에 사용합니다. /etc/sysconfig/vncserver
구성 파일은 /etc/systemd/system/vncserver@.service
로 교체되었습니다.
13.1. VNC 서버
vncserver
는 VNC(Virtual Network Computing) 데스크탑을 시작하는 유틸리티입니다. 이는 적절한 옵션과 함께 Xvnc 를 실행하고 VNC 데스크탑에서 창 관리자를 시작합니다. vncserver
를 사용하면 사용자가 어디에서나 액세스할 수 있는 시스템에서 별도의 세션을 동시에 실행할 수 있습니다.
13.1.1. VNC 서버 설치
TigerVNC 서버를 설치하려면 root
로 다음 명령을 실행합니다.
~]# yum install tigervnc-server
13.1.2. VNC 서버 구성
디스플레이 설정, 네트워크 주소 및 포트, 보안 설정 등의 선택적 매개 변수를 사용하여 사용자 계정이 시스템에 존재하는 경우 VNC 서버는 하나 이상의 사용자에 대한 디스플레이를 시작하도록 구성할 수 있습니다.
단일 사용자에 대해 VNC 디스플레이 구성
/etc/systemd/system/vncserver@.service
라는 구성 파일이 필요합니다. 이 파일을 생성하려면/usr/lib/systemd/system/vncserver@.service
파일을root
로 복사합니다.~]#
cp /usr/lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@.service
systemd
가 필요에 따라 메모리에 적절히 명명된 인스턴스를 자동으로 만들어 서비스 파일의'%i'
를 표시 번호로 대체하므로 파일 이름에 표시 번호를 포함할 필요가 없습니다. 단일 사용자의 경우 파일 이름을 변경할 필요가 없습니다. 여러 사용자의 경우, 예를 들어 특정 방식으로 사용자 이름을 파일 이름에 추가하여 각 사용자에 대해 고유하게 지정된 서비스 파일이 필요합니다. 자세한 내용은 13.1.2.1절. “두 사용자의 VNC 서버 설정” 을 참조하십시오./etc/systemd/system/vncserver@.service
를 편집하여 USER 를 실제 사용자 이름으로 교체합니다. 파일의 나머지 행은 수정되지 않은 상태로 둡니다.ExecStart=/usr/bin/vncserver_wrapper <USER> %i
참고VNC 데스크탑의 기본 크기는 1024x768입니다.
사용자의 VNC 세션은
~/.vnc/config
파일을 사용하여 추가로 구성할 수 있습니다.예를 들어 VNC 창 크기를 변경하려면 다음 행을 추가합니다.
geometry= <WIDTH> x <HEIGHT>
- 변경 사항을 저장합니다.
변경 사항을 즉시 적용하려면 다음 명령을 실행합니다.
~]#
systemctl daemon-reload
구성 파일에 정의된 사용자 또는 사용자의 암호를 설정합니다. 먼저
root
에서 USER 로 전환해야 합니다.~]# su - USER ~]$
vncpasswd
Password: Verify:중요저장된 암호는 암호화되지 않습니다. 암호 파일에 대한 액세스 권한이 있는 모든 사용자는 일반 텍스트 암호를 찾을 수 있습니다.
13.1.3절. “VNC 서버 시작” 으로 이동합니다.
13.1.2.1. 두 사용자의 VNC 서버 설정
동일한 시스템에서 두 개 이상의 사용자를 구성하려면 각 사용자에 대해 서로 다른 템플릿 유형 서비스 파일을 생성합니다.
-
두 개의 서비스 파일(예:
vncserver-USER_1@.service
및vncserver-USER_2@.service
)을 만듭니다. 두 파일 모두에서 USER 를 올바른 사용자 이름으로 대체합니다. 두 사용자의 암호를 설정합니다.
~]$ su - USER_1 ~]$
vncpasswd
Password: Verify: ~]$ su - USER_2 ~]$vncpasswd
Password: Verify:
13.1.3. VNC 서버 시작
서비스를 시작하거나 활성화하려면 명령에서 직접 표시 번호를 지정합니다. 단일 사용자에 대해 VNC 디스플레이 구성 에서 위에서 구성한 파일은 템플릿으로 작동하며, %i
는 systemd
의 표시 번호로 대체됩니다. 유효한 표시 번호를 사용하여 다음 명령을 실행합니다.
~]# systemctl start vncserver@:display_number.service
시스템을 시작할 때 서비스가 자동으로 시작되도록 활성화할 수도 있습니다. 그런 다음 로그인하면 vncserver
가 자동으로 시작됩니다. root
로서 다음과 같이 명령을 실행합니다.
~]# systemctl enable vncserver@:display_number.service
이때 다른 사용자는 VNC 뷰어 프로그램을 사용하여 정의된 디스플레이 번호 및 암호를 사용하여 VNC 서버에 연결할 수 있습니다. 그래픽 데스크탑이 설치되어 있으면 해당 데스크탑의 인스턴스가 표시됩니다. 현재 대상 시스템에 표시된 인스턴스와 같지 않습니다.
13.1.3.1. 두 명의 사용자 및 두 개의 다른 디스플레이에 대해 VNC 서버 설정
구성된 두 VNC 서버의 경우 vncserver-USER_1@.service 및 vncserver-USER_2@.service의 경우 다른 표시 번호를 활성화할 수 있습니다. 예를 들어 다음 명령은 USER_1의 VNC 서버가 디스플레이 3에서 시작되고, USER_2에 대한 VNC 서버가 디스플레이 5에서 시작되도록 합니다.
~]# systemctl start vncserver-USER_1@:3.service ~]# systemctl start vncserver-USER_2@:5.service
13.1.4. GDM용 XDMCP를 사용하여 xinetd 기반 VNC 설정
GDM(X Display Manager Control Protocol)을 사용하여 xinetd를 기반으로 하는 VNC 설정은 주로 씬 클라이언트로 구성된 클라이언트 시스템에 유용한 설정입니다. 설정 후 클라이언트는 GDM 로그인 창에 액세스하여 시스템 계정에 로그인할 수 있습니다. 설정의 전제 조건은 gdm, vnc, vnc-server 및 xinetd 패키지가 설치되어 있다는 것입니다.
~]# yum install gdm tigervnc tigervnc-server xinetd
xinetd 서비스를 활성화해야 합니다.
~]# systemctl enable xinetd.service
시스템 기본 대상 단위는 graphical.target
여야 합니다. 현재 설정된 기본 대상 유닛을 가져오려면 다음을 사용합니다.
~]# systemctl get-default
기본 대상 단위는 다음을 사용하여 변경할 수 있습니다.
~]# systemctl set-default target_name
GDM 로그인 창에 액세스 및 로그인
/etc/gdm/custom.conf
구성 파일을 편집하여 XDMCP를 사용하도록 GDM을 설정합니다.[xdmcp] Enable=true
다음 콘텐츠를 사용하여
/etc/xinetd.d/xvncserver
라는 파일을 생성합니다.service service_name { disable = no protocol = tcp socket_type = stream wait = no user = nobody server = /usr/bin/Xvnc server_args = -inetd -query localhost -once -geometry selected_geometry -depth selected_depth securitytypes=none }
server_args 섹션에서
-query localhost
옵션은 각 Xvnc 인스턴스가 xdmcp 세션에 대해 localhost를 쿼리합니다.깊이
옵션은 생성할 VNC 데스크탑의 비트 단위(비트)를 지정합니다. 허용 가능한 값은 8, 15, 16 및 24이며 다른 값으로 인해 예기치 않은 애플리케이션 동작이 발생할 수 있습니다.서비스를 정의할
/etc/services
를 편집합니다. 이렇게 하려면/etc/services
파일에 다음 스니펫을 추가합니다.# VNC xinetd GDM base service_name 5950/tcp
구성 변경 사항을 적용하려면 시스템을 재부팅합니다.
또는 다음을 실행할 수 있습니다. init 수준을 3으로 변경하고 5로 돌아가 gdm을 강제로 다시 로드합니다.
# init 3 # init 5
gdm이 UDP 포트 177에서 수신 대기 중인지 확인합니다.
# netstat -anu|grep 177 udp 0 0 0.0.0.0:177 0.0.0.0:*
xinetd 서비스를 다시 시작합니다.
~]# systemctl restart xinetd.service
xinetd 서비스가 새 서비스를 로드했는지 확인합니다.
# netstat -anpt|grep 595 tcp 0 0 :::5950 :::* LISTEN 3119/xinetd
vncviewer 명령을 사용하여 설정을 테스트합니다.
# vncviewer localhost:5950
이 명령은 암호가 표시되지 않는 localhost에 VNC 세션을 시작합니다. GDM 로그인 화면이 표시되고 유효한 사용자 이름 및 암호를 사용하여 시스템의 모든 사용자 계정에 로그인할 수 있습니다. 그런 다음 원격 연결에서 동일한 테스트를 실행할 수 있습니다.
설정에 대한 방화벽을 구성합니다. 방화벽 구성 도구를 실행하고 시스템에 들어오는 연결을 허용하도록 TCP 포트 5950을 추가합니다.
~]# firewall-cmd --permanent --zone=public --add-port=5950/tcp ~]# firewall-cmd --reload
13.1.5. VNC 세션 종료
vncserver
서비스를 활성화하는 것과 유사하게 시스템을 시작할 때 서비스의 자동 시작을 비활성화할 수 있습니다.
~]# systemctl disable vncserver@:display_number.service
또는 시스템이 실행 중이면 root
로 다음 명령을 실행하여 서비스를 중지할 수 있습니다.
~]# systemctl stop vncserver@:display_number.service
13.2. 기존 데스크탑 공유
기본적으로 로그인한 사용자는 디스플레이 0
에서 X Server에서 제공하는 데스크탑이 있습니다. 사용자는 Tiger VNC
서버 x0vncserver
를 사용하여 데스크탑을 공유할 수 있습니다.
X 데스크탑 공유
로그인한 사용자의 데스크탑을 공유하려면 x0vncserver
를 사용하여 다음과 같이 진행하십시오.
root
로 다음 명령을 입력합니다.~]# yum install tigervnc-server
사용자의 VNC 암호를 설정합니다.
~]$
vncpasswd
Password: Verify:해당 사용자로 다음 명령을 입력합니다.
~]$
x0vncserver -PasswordFile=.vnc/passwd -AlwaysShared=1
포트 5900
에 대한 연결을 허용하도록 방화벽이 구성되면 원격 뷰어가 0
을 표시하고 로그인한 사용자 데스크탑을 볼 수 있습니다. 방화벽을 구성하는 방법에 대한 자세한 내용은 13.3.2.1절. “VNC의 방화벽 설정” 을 참조하십시오.
13.3. VNC 뷰어
vncviewer
는 그래픽 사용자 인터페이스를 표시하고 vncserver
를 원격으로 제어하는 프로그램입니다.
vncviewer
를 실행하는 경우 전체 화면 모드 전환 또는 뷰어 종료와 같은 다양한 작업을 수행하는 항목이 포함된 팝업 메뉴가 있습니다. 또는 터미널을 통해 vncviewer
를 작동할 수 있습니다. 명령줄에서 vncviewer -h
를 입력하여 vncviewer
의 매개 변수를 나열합니다.
13.3.1. VNC 뷰어 설치
TigerVNC 클라이언트를 설치하려면 vncviewer
, root
로 다음 명령을 실행합니다.
~]# yum install tigervnc
13.3.2. VNC 서버에 연결
VNC 서버가 구성되면 VNC 뷰어에서 연결할 수 있습니다.
GUI를 사용하여 VNC 서버에 연결
-
인수 없이
vncviewer
명령을 입력하고VNC Viewer를 입력합니다. 연결 세부 정보
유틸리티가 표시됩니다. VNC 서버가 연결할지 묻는 메시지를 표시합니다. 필요한 경우 기존 VNC 연결을 동일한 디스플레이로 분리하지 않으려면 다음과 같이 데스크탑을 공유할 수 있는 옵션을 선택합니다.
- 버튼을 선택합니다.
-
Misc.
탭을 선택합니다. -
Shared
버튼을 선택합니다. - 확인 을 눌러 주 메뉴로 돌아갑니다.
연결할 주소 및 표시 번호를 입력합니다.
address:display_number
- 연결을 눌러 VNC 서버 디스플레이에 연결합니다.
VNC 암호를 입력하라는 메시지가 표시됩니다. 글로벌 기본 VNC 암호를 설정하지 않는 한 디스플레이 번호에 해당하는 사용자의 VNC 암호입니다.
VNC 서버 데스크탑을 보여주는 창이 나타납니다. 이는 일반 사용자가 보는 데스크탑이 아니며 Xvnc 데스크탑입니다.
CLI를 사용하여 VNC 서버에 연결
주소를 사용하여
viewer
명령을 입력하고 인수로 표시 번호를 입력합니다.vncviewer address:display_number
여기서 address 는
IP
주소 또는 호스트 이름입니다.- VNC 암호를 입력하여 인증합니다. 글로벌 기본 VNC 암호를 설정하지 않는 한 디스플레이 번호에 해당하는 사용자의 VNC 암호입니다.
- VNC 서버 데스크탑을 보여주는 창이 나타납니다. 이는 일반 사용자가 보는 데스크탑이 아니며 Xvnc 데스크탑입니다.
13.3.2.1. VNC의 방화벽 설정
암호화되지 않은 연결을 사용하는 경우 firewalld
에서 연결을 차단할 수 있습니다. firewalld
가 VNC 패킷을 통과하도록 허용하려면 특정 포트를 TCP
트래픽에 열 수 있습니다. -via
옵션을 사용하면 트래픽이 기본적으로 firewalld
에서 활성화되는 SSH
로 리디렉션됩니다.
VNC 서버의 기본 포트는 5900입니다. 원격 데스크탑에 액세스할 수 있는 포트를 사용하려면 기본 포트와 사용자의 할당된 표시 번호를 합계합니다. 예를 들어 두 번째 디스플레이의 경우: 2 + 5900 = 5902.
디스플레이 0
에서 3
까지의 경우 아래에 설명된 대로 서비스 옵션을 통해 VNC 서비스에
대한 firewalld
지원을 사용하십시오. 3
보다 큰 숫자의 경우 해당 포트는 firewalld에서 포트 열기 에서 설명하는 대로 구체적으로 열어야 합니다.
firewalld에서 VNC 서비스 활성화
다음 명령을 실행하여
firewalld
설정에 대한 정보를 확인합니다.~]$ firewall-cmd --list-all
특정 주소에서 모든 VNC 연결을 허용하려면 다음과 같이 명령을 사용합니다.
~]# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.122.116" service name=vnc-server accept' success
이러한 변경 사항은 다음 시스템을 시작한 후에도 유지되지 않습니다. 방화벽을 영구적으로 변경하려면
--permanent
옵션을 추가하는 명령을 반복합니다. 방화벽 풍부한 언어 명령 사용에 대한 자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드 를 참조하십시오.위 설정을 확인하려면 다음과 같이 명령을 사용합니다.
~]# firewall-cmd --list-all public (default, active) interfaces: bond0 bond0.192 sources: services: dhcpv6-client ssh ports: masquerade: no forward-ports: icmp-blocks: rich rules: rule family="ipv4" source address="192.168.122.116" service name="vnc-server" accept
특정 포트 또는 포트 범위를 열기 위해 firewall-cmd
명령 줄 툴에 --add-port
옵션을 사용합니다. 예를 들어 VNC 디스플레이 4
는 TCP
트래픽에 대해 포트 5904
를 열어야 합니다.
firewalld에서 포트 열기
공개 영역에서
TCP
트래픽의 포트를 여는 경우 다음과 같이root
로 명령을 실행합니다.~]# firewall-cmd --zone=public --add-port=5904/tcp success
현재 퍼블릭 영역에 열려 있는 포트를 보려면 다음과 같이 명령을 실행합니다.
~]# firewall-cmd --zone=public --list-ports 5904/tcp
firewall-cmd --zone=zone --remove-port=number/protocol
명령을 사용하여 포트를 제거할 수 있습니다.
이러한 변경 사항은 다음 시스템을 시작한 후에도 유지되지 않습니다. 방화벽을 영구적으로 변경하려면 --permanent
옵션을 추가하는 명령을 반복합니다. firewalld
에서 포트 열기 및 닫기에 대한 자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드 를 참조하십시오.
13.3.3. SSH를 사용하여 VNC 서버에 연결
VNC 는 통신의 가능한 공격에 대한 보안이 없는 일반 텍스트 네트워크 프로토콜입니다. 통신을 보호하려면 -via
옵션을 사용하여 server-client 연결을 암호화할 수 있습니다. 이렇게 하면 VNC 서버와 클라이언트 사이에 SSH
터널이 생성됩니다.
VNC 서버-클라이언트 연결을 암호화하는 명령 형식은 다음과 같습니다.
vncviewer -via user@host:display_number
예 13.1. via 옵션 사용
SSH
를 사용하여 VNC 서버에 연결하려면 다음과 같이 명령을 입력합니다.~]$ vncviewer -via USER_2@192.168.2.101:3
- 암호를 입력하라는 메시지가 표시되면 암호를 입력하고 Enter 를 눌러 확인합니다.
- 원격 데스크탑이 있는 창이 화면에 나타납니다.
VNC 액세스 제한
암호화된 연결만 선호하는 경우 systemd.service
파일인 ExecStart 줄에 -localhost
옵션을 사용하여 암호화되지 않은 연결을 모두 방지할 수 있습니다.
ExecStart=/usr/sbin/runuser -l user -c "/usr/bin/vncserver -localhost %i"
이렇게 하면 vncserver
가 -via
옵션의 결과로 SSH
를 사용하여 전송된 로컬 호스트 및 포트 전달 연결을 허용하지 않습니다.
SSH
사용에 대한 자세한 내용은 12장. OpenSSH 을 참조하십시오.
13.4. 추가 리소스
TigerVNC에 대한 자세한 내용은 아래 나열된 리소스를 참조하십시오.
설치된 문서
-
vncserver(1)
- VNC 서버 유틸리티의 수동 페이지. -
vncviewer(1)
- VNC 뷰어의 도움말 페이지. -
vncpasswd(1)
- VNC 암호 명령의 수동 페이지. -
Xvnc(1)
- Xvnc 서버 구성 옵션의 수동 페이지. -
X0vncserver(1)
- 기존 X 서버를 공유하는TigerVNC
서버의 수동 페이지.
V 부. 서버
이 부분에서는 네트워크를 통해 웹 서버를 설정하거나 파일 및 디렉터리를 공유하는 방법과 같은 서버와 관련된 다양한 주제에 대해 설명합니다.
14장. 웹 서버
웹 서버는 웹을 통해 클라이언트에 콘텐츠를 제공하는 네트워크 서비스입니다. 이는 일반적으로 웹 페이지를 의미하지만 다른 모든 문서도 될 수 있습니다. 웹 서버는 하이퍼텍스트 전송 프로토콜 (HTTP)을 사용하므로 HTTP 서버라고도 합니다.
Red Hat Enterprise Linux 7에서 제공되는 웹 서버는 다음과 같습니다.
- Apache HTTP Server
- nginx
nginx 웹 서버는 Red Hat Enterprise Linux 7용 소프트웨어 컬렉션으로만 사용할 수 있습니다. nginx, Software Collections 사용 및 기타에 대한 자세한 내용은 Red Hat Software Collections 릴리스 정보를 참조하십시오.
14.1. Apache HTTP Server
이 섹션에서는 Apache Software Foundation 에서 개발한 오픈 소스 웹 서버인 Apache HTTP Server 2.4, httpd
에 중점을 둡니다.
Red Hat Enterprise Linux 이전 릴리스에서 업그레이드하는 경우 httpd
서비스 구성을 적절하게 업데이트해야 합니다. 이 섹션에서는 새로 추가된 기능 중 일부를 검토하고 Apache HTTP Server 2.4와 버전 2.2 간의 중요한 변경 사항을 간략하게 설명하고, 이전 구성 파일의 업데이트를 안내합니다.
14.1.1. 주요 변경 사항
Red Hat Enterprise Linux 7의 Apache HTTP Server는 Red Hat Enterprise Linux 6에 비해 다음과 같이 변경되었습니다.
- httpd 서비스 제어
SysV init 스크립트에서 마이그레이션하면 서버 관리자가
apachectl
및systemctl
명령을 사용하여service
명령 대신 서비스를 제어하도록 전환해야 합니다. 다음 예는httpd
서비스에 따라 다릅니다.명령:
service httpd graceful
로 교체됨
apachectl graceful
httpd
의systemd
장치 파일은 init 스크립트의 동작이 다음과 같이 다릅니다.- 서비스가 다시 로드되면 정상 재시작이 기본적으로 사용됩니다.
정상 중지는 서비스가 중지될 때 기본적으로 사용됩니다.
명령:
service httpd configtest
로 교체됨
apachectl configtest
- 개인 /tmp
-
시스템 보안을 강화하기 위해
systemd
장치 파일은/tmp
디렉토리를 사용하여httpd
데몬을 실행하여 시스템/tmp
디렉토리로 구분합니다. - 구성 레이아웃
이제 모듈을 로드하는 구성 파일이
/etc/httpd/conf.modules.d/
디렉터리에 배치됩니다.httpd
에 로드 가능한 추가 모듈을 제공하는 패키지는 이 디렉터리에 파일을 배치합니다./etc/httpd/conf/httpd.conf
파일의 기본 섹션 앞에Include
지시문을 사용하여/etc/httpd/conf.modules.d/
디렉터리에 파일을 포함합니다. 즉,conf.modules.d/
내의 모든 구성 파일은httpd.conf
의 주요 본문 전에 처리됩니다./etc/httpd/conf.d/
디렉터리에 있는 파일에 대한IncludeOptional
지시문은httpd.conf
파일의 끝에 배치됩니다. 즉,/etc/httpd/conf.d/
내의 파일은 이제httpd.conf
의 주요 본문 후에 처리됩니다.일부 추가 구성 파일은 httpd 패키지 자체에서 제공합니다.
-
/etc/httpd/conf.d/autoindex.conf
- mod_autoindex 디렉토리 인덱싱을 구성합니다. -
/etc/httpd/conf.d/userdir.conf
- 사용자 디렉터리에 대한 액세스를 구성합니다(예: http://example.com/~username/ ). 이러한 액세스는 보안상의 이유로 기본적으로 비활성화되어 있습니다. -
/etc/httpd/conf.d/welcome.conf
- 이전 릴리스에서는 콘텐츠가 없는 경우 http://localhost/ 에 대한 시작 페이지가 표시됩니다.
-
- 기본 설정
-
이제 최소한의
httpd.conf
파일이 기본적으로 제공됩니다.Timeout
또는KeepAlive
와 같은 일반적인 설정 설정은 더 이상 기본 구성에서 명시적으로 구성되지 않습니다. 하드 코딩 설정은 기본적으로 사용됩니다. 모든 구성 지시문에 대해 하드 코드된 기본 설정은 설명서에 지정됩니다. 자세한 내용은 “설치 가능한 문서”를 참조하십시오. - 호환되지 않는 구문 변경
-
기존 구성을 httpd 2.2 에서 httpd 2.4 로 마이그레이션하는 경우
httpd
구성 구문에 대한 이전 버전과 호환되는 여러 변경 사항이 변경되었습니다. http://httpd.apache.org/docs/2.4/upgrading.html업그레이드에 대한 자세한 내용은 다음 Apache 문서를 참조하십시오. - 처리 모델
이전 Red Hat Enterprise Linux 릴리스에서는 다양한 다중 처리 모델 (MPM)을 다른
httpd
바이너리로 사용할 수 있습니다. 분기된 모델인 "prefork",/usr/sbin/httpd
.worker 로서 스레드 기반 모델 "worker"를/usr/sbin/httpd.worker
로 사용할 수 있습니다.Red Hat Enterprise Linux 7에서는 단일
httpd
바이너리만 사용되며 3개의 MPM은 로드 가능한 모듈인 worker, prefork(기본값) 및 이벤트로 사용할 수 있습니다. 세 MPM 모듈 중 하나만 로드되도록 주석 문자#
을 추가하고 제거하여 구성 파일/etc/httpd/conf.modules.d/00-mpm.conf
를 필요에 따라 편집합니다.- 패키지 변경 사항
이제 LDAP 인증 및 권한 부여 모듈이 별도의 하위 패키지인 mod_ldap 로 제공됩니다. 새로운 모듈 mod_session 및 관련 도우미 모듈은 새로운 하위 패키지인 mod_session 에 제공됩니다. 새로운 모듈 mod_proxy_html 및 mod_xml2enc 는 새로운 하위 패키지인 mod_proxy_html 에 제공됩니다. 이러한 패키지는 모두 선택적 채널에 있습니다.
참고선택적 및 추가 채널에 가입하기 전에 지원 범위 세부 정보를 참조하십시오. 이러한 채널에서 패키지를 설치하려면 How to access Optional and Supplementary channel, and -devel packages using Red Hat Subscription Manager (RHSM)를 사용하여 Red Hat Customer Portal에 설명된 단계를 따르십시오.
- 패키지 파일 시스템 레이아웃
/var/cache/mod_proxy/
디렉터리는 더 이상 제공되지 않습니다. 대신/var/cache/httpd/
디렉터리는프록시
및ssl
하위 디렉터리와 함께 패키지됩니다.httpd
와 함께 제공되는 패키지된 콘텐츠가/var/www/
에서/usr/share/httpd/
로 이동되었습니다.-
/usr/share/httpd/icons/
/var/share/httpd/icons/
에 포함된 디렉토리 인덱스와 함께 사용되는 아이콘 세트가 포함된 디렉터리입니다. 기본 구성의 http://localhost/icons/ 에서 사용할 수 있습니다. 아이콘 위치 및 가용성은/etc/httpd/conf.d/autoindex.conf
파일에서 구성할 수 있습니다. -
/usr/share/httpd/manual/
-/var/www/manual/
가/usr/share/httpd/manual/
로 이동했습니다. httpd-manual 패키지에 포함된 이 디렉터리에는httpd
에 대한 설명서의 HTML 버전이 포함되어 있습니다. 패키지가 설치된 경우 http://localhost/manual/ 에서 사용할 수 있으며,/etc/httpd/conf.d/manual.conf
파일에서 설명서의 위치 및 가용성을 구성할 수 있습니다. -
/usr/share/httpd/error/
-/var/www/error/
가/usr/share/httpd/error/
로 이동했습니다. 사용자 정의 다중 언어 HTTP 오류 페이지. 기본적으로 구성 파일은/usr/share/doc/httpd-VERSION/httpd-multilang-errordoc.conf
에 제공됩니다.
-
- 인증, 권한 부여 및 액세스 제어
-
인증, 권한 부여 및 액세스 제어 제어에 사용되는 구성 지시문이 크게 변경되었습니다.
Order
,Deny
및Allow
지시문을 사용하는 기존 구성 파일을 새Require
구문을 사용하도록 조정해야 합니다. 자세한 내용은 다음 Apache 문서를 참조하십시오. http://httpd.apache.org/docs/2.4/howto/auth.html - suexec
-
시스템 보안을 개선하기 위해 suexec 바이너리는 더 이상
루트
사용자가 사용하는 것처럼 설치되지 않습니다. 대신 보다 제한적인 권한 세트를 허용하는 파일 시스템 기능 비트가 설정됩니다. 이러한 변경과 함께 suexec 바이너리는 더 이상/var/log/httpd/suexec.log
logfile을 사용하지 않습니다. 대신 로그 메시지가 syslog 로 전송됩니다. 기본적으로 이러한 메시지는/var/log/secure
로그 파일에 표시됩니다. - 모듈 인터페이스
httpd2.2
에 대해 빌드된 타사 바이너리 모듈은 httpd 모듈 인터페이스 변경으로 인해 httpd 2.4 와 호환되지 않습니다. 이러한 모듈은 httpd 2.4 모듈 인터페이스에 필요한 대로 조정한 다음 다시 빌드해야 합니다. 버전2.4
의 API 변경 사항의 자세한 목록은 http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html 에서 확인할 수 있습니다.소스에서 모듈을 빌드하는 데 사용되는 apxs 바이너리가
/usr/sbin/apxs
에서/usr/bin/apxs
로 이동했습니다.- 제거된 모듈
Red Hat Enterprise Linux 7에서 제거된
httpd
모듈 목록:- mod_auth_mysql, mod_auth_pgsql
- httpd 2.4 에서는 mod_authn_dbd 모듈에서 내부적으로 SQL 데이터베이스 인증 지원을 제공합니다.
- mod_perl
- mod_perl 은 업스트림에서 httpd 2.4 에서 공식적으로 지원되지 않습니다.
- mod_authz_ldap
- httpd 2.4 에서는 mod_authnz_ldap 를 사용하여 하위 패키지 mod_ldap 에서 LDAP 지원을 제공합니다.
14.1.2. 구성 업데이트
Apache HTTP Server 버전 2.2에서 구성 파일을 업데이트하려면 다음 단계를 따르십시오.
-
모든 모듈 이름이 올바른지 확인합니다. 변경되었을 수 있습니다. 이름이 변경된 각 모듈에 대해
LoadModule
지시문을 조정합니다. - 로드를 시도하기 전에 모든 타사 모듈을 다시 컴파일합니다. 이는 일반적으로 인증 및 권한 부여 모듈을 의미합니다.
-
mod_userdir
모듈을 사용하는 경우UserDir
지시문에서 디렉터리 이름(일반적으로public_html
)을 나타내는지 확인합니다. - Apache HTTP 보안 서버를 사용하는 경우 SSL(Secure Sockets Layer) 프로토콜 활성화에 대한 중요한 정보는 14.1.8절. “mod_ssl 모듈 활성화” 를 참조하십시오.
다음 명령을 사용하여 구성에 가능한 오류가 있는지 확인할 수 있습니다.
~]# apachectl configtest Syntax OK
Apache HTTP Server 구성을 버전 2.2에서 2.4로 업그레이드하는 방법에 대한 자세한 내용은 http://httpd.apache.org/docs/2.4/upgrading.html 을 참조하십시오.
14.1.3. httpd 서비스 실행
이 섹션에서는 Apache HTTP 서버의 현재 상태를 시작, 중지, 다시 시작 및 확인하는 방법에 대해 설명합니다. httpd
서비스를 사용하려면 httpd 가 설치되어 있는지 확인합니다. 다음 명령을 사용하여 수행할 수 있습니다.
~]# yum install httpd
대상 개념과 Red Hat Enterprise Linux에서 시스템 서비스를 관리하는 방법에 대한 자세한 내용은 10장. systemd를 사용하여 서비스 관리 을 참조하십시오.
14.1.3.1. 서비스 시작
httpd
서비스를 실행하려면 쉘 프롬프트에 root
로 다음을 입력합니다.
~]# systemctl start httpd.service
부팅 시 서비스가 자동으로 시작되도록 하려면 다음 명령을 사용하십시오.
~]# systemctl enable httpd.service Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
Apache HTTP 서버를 보안 서버로 실행하는 경우 암호화된 개인 SSL 키를 사용하는 경우 시스템이 부팅된 후 암호가 필요할 수 있습니다.
14.1.3.2. 서비스 중지
실행 중인 httpd
서비스를 중지하려면 쉘 프롬프트에 root
로 다음을 입력합니다.
~]# systemctl stop httpd.service
부팅 시 서비스가 자동으로 시작되지 않도록 하려면 다음을 입력합니다.
~]# systemctl disable httpd.service Removed symlink /etc/systemd/system/multi-user.target.wants/httpd.service.
14.1.3.3. 서비스를 다시 시작
실행 중인 httpd
서비스를 다시 시작하는 방법은 다음 세 가지가 있습니다.
서비스를 완전히 다시 시작하려면
root
로 다음 명령을 입력하십시오.~]# systemctl restart httpd.service
그러면 실행 중인
httpd
서비스가 중지되고 즉시 다시 시작됩니다. PHP와 같이 동적으로 로드된 모듈을 설치하거나 제거한 후 이 명령을 사용하십시오.구성을
root
로 다시 로드하려면 다음을 입력합니다.~]# systemctl reload httpd.service
이로 인해 실행 중인
httpd
서비스가 구성 파일을 다시 로드합니다. 현재 처리 중인 요청이 중단되므로 클라이언트 브라우저가 오류 메시지를 표시하거나 부분 페이지를 렌더링할 수 있습니다.활성 요청에 영향을 주지 않고 구성을 다시 로드하려면
root
로 다음 명령을 입력합니다.~]# apachectl graceful
이로 인해 실행 중인
httpd
서비스가 구성 파일을 다시 로드합니다. 현재 처리 중인 모든 요청은 이전 구성을 계속 사용합니다.
Red Hat Enterprise Linux 7에서 시스템 서비스를 관리하는 방법에 대한 자세한 내용은 10장. systemd를 사용하여 서비스 관리 를 참조하십시오.
14.1.3.4. 서비스 상태 확인
httpd
서비스가 실행 중인지 확인하려면 쉘 프롬프트에서 다음을 입력합니다.
~]# systemctl is-active httpd.service active
14.1.4. 구성 파일 편집
httpd
서비스가 시작되면 기본적으로 표 14.1. “httpd 서비스 구성 파일”에 나열된 위치에서 구성을 읽습니다.
경로 | 설명 |
---|---|
| 기본 구성 파일입니다. |
| 기본 구성 파일에 포함된 구성 파일의 보조 디렉토리입니다. |
기본 구성은 대부분의 상황에 적합해야 하지만 중요한 구성 옵션 중 일부에 익숙해지는 것이 좋습니다. 변경 사항을 적용하려면 먼저 웹 서버를 다시 시작해야 합니다. httpd
서비스를 다시 시작하는 방법에 대한 자세한 내용은 14.1.3.3절. “서비스를 다시 시작”에서 참조하십시오.
구성에 가능한 오류가 있는지 확인하려면 쉘 프롬프트에서 다음을 입력합니다.
~]# apachectl configtest Syntax OK
실수로 쉽게 복구하려면 편집하기 전에 원본 파일의 복사본을 만드는 것이 좋습니다.
14.1.5. 모듈 작업
모듈식 애플리케이션이므로 httpd
서비스는 필요에 따라 런타임 시 동적으로 로드하거나 언로드할 수 있는 다수의 동적 공유 오브젝트 (DSO)와 함께 배포됩니다. Red Hat Enterprise Linux 7에서 이러한 모듈은 /usr/lib64/httpd/modules/
에 있습니다.
14.1.5.1. 모듈 로드
특정 DSO 모듈을 로드하려면 LoadModule
지시문을 사용합니다. 별도의 패키지에서 제공하는 모듈에는 /etc/httpd/conf.d/
디렉터리에 자체 구성 파일이 있는 경우가 많습니다.
예 14.1. mod_ssl DSO 로드
LoadModule ssl_module modules/mod_ssl.so
완료되면 웹 서버를 다시 시작하여 구성을 다시 로드합니다. httpd
서비스를 다시 시작하는 방법에 대한 자세한 내용은 14.1.3.3절. “서비스를 다시 시작”에서 참조하십시오.
14.1.5.2. 모듈 작성
새 DSO 모듈을 생성하려는 경우 httpd-devel 패키지가 설치되어 있는지 확인합니다. 이렇게 하려면 root
로 다음 명령을 입력합니다:
~]# yum install httpd-devel
이 패키지에는 모듈을 컴파일하는 데 필요한 파일, 헤더 파일 및 APache eXtenSion (pxs
) 유틸리티가 포함되어 있습니다.
작성되고 나면 다음 명령을 사용하여 모듈을 빌드할 수 있습니다.
~]# apxs -i -a -c module_name.c
빌드가 성공하면 Apache HTTP Server와 함께 배포되는 다른 모듈과 동일한 방식으로 모듈을 로드할 수 있어야 합니다.
14.1.6. 가상 호스트 설정
Apache HTTP Server의 가상 호스팅을 사용하면 서버에서 요청 중인 IP 주소, 호스트 이름 또는 포트를 기반으로 다양한 정보를 제공할 수 있습니다.
이름 기반 가상 호스트를 생성하려면 예제 구성 파일 /usr/share/doc/httpd-VERSION/httpd-vhosts.conf
를 /etc/httpd/conf.d/
디렉터리에 복사하고 @@Port@@
@@@@@@@@@@@ 자리 표시자 값을 대체합니다. 예 14.2. “가상 호스트 구성 예” 에 표시된 대로 요구 사항에 따라 옵션을 사용자 지정합니다.
예 14.2. 가상 호스트 구성 예
<VirtualHost *:80> ServerAdmin webmaster@penguin.example.com DocumentRoot "/www/docs/penguin.example.com" ServerName penguin.example.com ServerAlias www.penguin.example.com ErrorLog "/var/log/httpd/dummy-host.example.com-error_log" CustomLog "/var/log/httpd/dummy-host.example.com-access_log" common </VirtualHost>
ServerName
은 시스템에 할당된 유효한 DNS 이름이어야 합니다. <VirtualHost>
컨테이너는 고도로 사용자 지정할 수 있으며 기본 서버 구성 내에서 사용 가능한 대부분의 지시문을 허용합니다. 이 컨테이너 내에서 지원되지 않는 지시문에는 SuexecUserGroup
으로 교체된 User
및 Group
이 포함됩니다.
기본이 아닌 포트에서 수신하도록 가상 호스트를 구성하는 경우 그에 따라 /etc/httpd/conf/httpd.conf
파일의 글로벌 설정 섹션에서 Listen
지시문을 업데이트해야 합니다.
새로 생성된 가상 호스트를 활성화하려면 먼저 웹 서버를 다시 시작해야 합니다. httpd
서비스를 다시 시작하는 방법에 대한 자세한 내용은 14.1.3.3절. “서비스를 다시 시작”에서 참조하십시오.
14.1.7. SSL 서버 설정
SSL( Secure Sockets Layer )은 서버와 클라이언트가 안전하게 통신할 수 있도록 하는 암호화 프로토콜입니다. TLS( Transport Layer Security )라는 확장 버전과 향상된 버전과 함께 개인 정보 보호 및 데이터 무결성을 보장합니다. OpenSSL 툴킷을 사용하여 SSL/TLS 지원을 제공하는 모듈인 mod_ssl
과 함께 Apache HTTP 서버를 SSL 서버 라고 합니다. Red Hat Enterprise Linux는 또한 TLS 구현으로 Mozilla NSS 사용을 지원합니다. Mozilla NSS에 대한 지원은 mod_nss
모듈을 통해 제공됩니다.
인터셉트할 수 있는 사람이 읽고 수정할 수 있는 HTTP 연결과 달리, HTTP를 통해 SSL/TLS를 사용하면 전송된 콘텐츠를 검사하거나 수정할 수 없습니다. 이 섹션에서는 Apache HTTP Server 구성에서 이 모듈을 활성화하는 방법에 대한 기본 정보를 제공하고 개인 키 및 자체 서명 인증서를 생성하는 프로세스를 안내합니다.
14.1.7.1. 인증서 및 보안 개요
보안 통신은 키 사용에 기반합니다. 기존 또는 대칭 암호화 에서 두 트랜잭션 종료는 서로의 전송을 디코딩하는 데 사용할 수 있는 것과 동일한 키를 갖습니다. 반면 공개 또는 대칭 암호화에서는 두 개의 키가 서로 공존합니다. 개인 키는 비밀로 유지되며 일반적으로 공개 키와 공유되는 공개 키입니다. 공개 키로 인코딩된 데이터는 개인 키로만 디코딩될 수 있지만 개인 키로 인코딩된 데이터는 공개 키로만 디코딩될 수 있습니다.
SSL을 사용하여 보안 통신을 제공하려면 SSL 서버는CA( 인증 기관) 에서 서명한 디지털 인증서를 사용해야 합니다. 인증서는 서버의 다양한 속성(즉, 서버 호스트 이름, 회사 이름, 위치 등)과 CA의 개인 키를 사용하여 생성된 서명을 나열합니다. 이 서명은 특정 인증 기관이 인증서에 서명하고 인증서가 어떠한 방식으로든 수정되지 않았음을 보장합니다.
웹 브라우저가 새 SSL 연결을 설정하면 웹 서버에서 제공하는 인증서를 확인합니다. 인증서에 신뢰할 수 있는 CA의 서명이 없거나 인증서에 나열된 호스트 이름이 연결을 설정하는 데 사용되는 호스트 이름과 일치하지 않는 경우, 서버와 통신하지 않고 일반적으로 적절한 오류 메시지가 표시됩니다.
기본적으로 대부분의 웹 브라우저는 널리 사용되는 인증 기관 세트를 신뢰하도록 구성되어 있습니다. 이로 인해 대상 사용자가 연결을 신뢰할 수 있도록 보안 서버를 설정할 때 적절한 CA를 선택해야 합니다. 그렇지 않으면 오류 메시지가 표시되고 인증서를 수동으로 허용해야 합니다. 사용자가 인증서 오류를 재정의하도록 유도하면 공격자가 연결을 가로챌 수 있으므로 가능한 경우 신뢰할 수 있는 CA를 사용해야 합니다. 이에 대한 자세한 내용은 표 14.2. “공통 웹 브라우저에서 사용하는 CA 목록에 대한 정보” 을 참조하십시오.
웹 브라우저 | link |
---|---|
Mozilla Firefox | |
Opera | |
Internet Explorer | |
chromium |
SSL 서버를 설정할 때 인증서 요청 및 개인 키를 생성한 다음 인증서 요청, 회사 ID 증명, 인증 기관에 결제해야 합니다. CA에서 인증서 요청 및 ID를 확인하면 서버와 함께 사용할 수 있는 서명된 인증서를 보냅니다. 또는 CA 서명이 없는 자체 서명된 인증서를 만들 수도 있으므로 테스트 목적으로만 사용해야 합니다.
14.1.8. mod_ssl 모듈 활성화
mod_ssl
을 사용하여 SSL 또는 HTTPS 서버를 설정하려는 경우 동일한 포트를 사용하도록 구성된 mod_ns
와 같은 다른 애플리케이션 또는 모듈을 가질 수 없습니다. 포트 443
은 HTTPS의 기본 포트입니다.
mod_ssl
모듈 및 OpenSSL 툴킷을 사용하여 SSL 서버를 설정하려면 mod_ssl 및 openssl 패키지를 설치합니다. root
로 다음 명령을 입력하십시오.
~]# yum install mod_ssl openssl
이렇게 하면 기본적으로 기본 Apache HTTP Server 구성 파일에 포함된 /etc/httpd/conf.d/ssl.conf
에 mod_ssl
구성 파일이 생성됩니다. 모듈을 로드하려면 14.1.3.3절. “서비스를 다시 시작” 에 설명된 대로 httpd
서비스를 다시 시작합니다.
POODLE에서 설명하는 취약점으로 인해 다음을 수행합니다. SSLv3 취약점 (CVE-2014-3566) 은 SSL
을 비활성화하고 TLSv1.1
또는 TLSv1.2
만 사용하는 것이 좋습니다. 이전 버전과의 호환성은 TLSv1.0
을 사용하여 수행할 수 있습니다. Red Hat에서 지원하는 많은 제품에는 SSLv2
또는 SSLv3
프로토콜을 사용하거나 기본적으로 이를 활성화할 수 있습니다. 그러나 이제 SSLv2
또는 SSLv3
를 사용하는 것이 좋습니다.
14.1.8.1. mod_ssl에서 SSL 및 TLS 활성화 및 비활성화
SSL 및 TLS 프로토콜의 특정 버전을 비활성화 및 활성화하려면구성 파일의 "# SSL Global Context" 섹션에 SSLProtocol
지시문을 추가하고 다른 곳에서 이를 제거하고 모든 "VirtualHost" 섹션의 기본 항목을 편집하여 전역적으로 수행합니다. 도메인별 VirtualHost 섹션에서 지정하지 않으면 전역 섹션에서 설정을 상속합니다. 프로토콜 버전이 비활성화되도록 하려면 관리자는 SSL 글로벌 컨텍스트 섹션에서 SSLProtocol
만 지정하거나 모든 도메인별 VirtualHost 섹션에서 지정해야 합니다.
SSLv2 및 SSLv3 비활성화
SSL 버전 2 및 SSL 버전 3을 비활성화하려면 모든 VirtualHost 섹션에서 SSL 버전 2 및 SSL 버전 3을 제외한 모든 기능을 활성화하려면 다음과 같이 진행하십시오.
루트
로서/etc/httpd/conf.d/ssl.conf
파일을 열고SSLProtocol
지시문의 모든 인스턴스를 검색합니다. 기본적으로 구성 파일에는 다음과 같은 섹션이 포함되어 있습니다.~]# vi /etc/httpd/conf.d/ssl.conf # SSL Protocol support: # List the enable protocol levels with which clients will be able to # connect. Disable SSLv2 access by default: SSLProtocol all -SSLv2
이 섹션은 VirtualHost 섹션에 있습니다.
다음과 같이
SSLProtocol
행을 다음과 같이 편집합니다.# SSL Protocol support: # List the enable protocol levels with which clients will be able to # connect. Disable SSLv2 access by default: SSLProtocol all -SSLv2 -SSLv3
모든 VirtualHost 섹션에 대해 이 작업을 반복합니다. 파일을 저장하고 닫습니다.
다음과 같이
SSLProtocol
지시문의 모든 항목이 변경되었는지 확인합니다.~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf SSLProtocol all -SSLv2 -SSLv3
하나 이상의 기본 VirtualHost 섹션이 있는 경우 이 단계는 특히 중요합니다.
다음과 같이 Apache 데몬을 다시 시작하십시오.
~]# systemctl restart httpd
모든 세션이 중단됩니다.
모든 SSL 및 TLS 프로토콜 비활성화 TLS 1 및 Up
TLS 버전 1 이상을 제외한 모든 SSL 및 TLS 프로토콜 버전을 비활성화하려면 다음과 같이 진행하십시오.
루트
로서/etc/httpd/conf.d/ssl.conf
파일을 열고SSLProtocol
지시문의 모든 인스턴스를 검색합니다. 기본적으로 파일에는 다음과 같은 섹션이 포함되어 있습니다.~]# vi /etc/httpd/conf.d/ssl.conf # SSL Protocol support: # List the enable protocol levels with which clients will be able to # connect. Disable SSLv2 access by default: SSLProtocol all -SSLv2
다음과 같이
SSLProtocol
행을 다음과 같이 편집합니다.# SSL Protocol support: # List the enable protocol levels with which clients will be able to # connect. Disable SSLv2 access by default: SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
파일을 저장하고 닫습니다.
다음과 같이 변경 사항을 확인합니다.
~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
다음과 같이 Apache 데몬을 다시 시작하십시오.
~]# systemctl restart httpd
모든 세션이 중단됩니다.
SSL 및 TLS 프로토콜 상태 테스트
어떤 버전의 SSL 및 TLS가 활성화되어 있는지 확인하려면 openssl s_client -connect
명령을 사용하십시오. 명령에는 다음과 같은 형식이 있습니다.
openssl s_client -connect hostname:port -protocol
여기서 port 는 테스트할 포트이고 프로토콜 은 테스트할 프로토콜 버전입니다. 로컬에서 실행되는 SSL 서버를 테스트하려면 호스트 이름으로 localhost
를 사용합니다. 예를 들어 보안 HTTPS 연결에 대한 기본 포트를 테스트하려면 포트 443
을 사용하여 SSLv3가 활성화되어 있는지 확인하고 다음과 같이 명령을 실행합니다.
~]# openssl s_client -connect localhost:443 -ssl3 CONNECTED(00000003) 139809943877536:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40 139809943877536:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: output omitted New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv3 output truncated
위의 출력은 핸드셰이크에 실패하여 암호가 협상되지 않았음을 나타냅니다.
~]$ openssl s_client -connect localhost:443 -tls1_2 CONNECTED(00000003) depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = localhost.localdomain, emailAddress = root@localhost.localdomain output omitted New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 output truncated
위 출력은 핸드셰이크의 실패가 발생하지 않았으며 일련의 암호 집합이 협상되었음을 나타냅니다.
openssl s_client
명령 옵션은 s_client(1)
매뉴얼 페이지에 설명되어 있습니다.
SSLv3 취약점 및 테스트 방법에 대한 자세한 내용은 Red Hat 지식베이스 문서 POODLE을 참조하십시오. SSLv3 취약점 (CVE-2014-3566).
14.1.9. mod_nss 모듈 활성화
mod_nss
를 사용하여 HTTPS 서버를 설정하려는 경우 기본적으로 mod_ssl 이 포트 443
을 사용하므로 기본 설정과 함께 mod_ssl
패키지를 설치할 수 없습니다. 그러나 이는 기본 HTTPS 포트입니다. 가능한 경우 패키지를 제거합니다.
mod_ssl 을 제거하려면 root
로 다음 명령을 입력합니다.
~]# yum remove mod_ssl
다른 용도로
이 필요한 경우 포트의 포트가 mod_ssl
443
으로 변경될 때 mod_ssl이 mod_nss
와 충돌하지 않도록 443
이외의 포트를 사용하도록 /etc/httpd/conf.d/ssl.conf
파일을 수정하십시오.
하나의 모듈만 포트를 보유할 수 있으므로 mod_nss
및 mod_ssl
은 고유 포트를 사용하는 경우에만 동시에 존재할 수 있습니다. 이러한 이유로 mod_nss
는 기본적으로 8443
을 사용하지만 HTTPS의 기본 포트는 443
입니다. 포트는 Listen
지시문과 VirtualHost 이름 또는 주소에 의해 지정됩니다.
NSS의 모든 것은 "토크릿"과 관련이 있습니다. 소프트웨어 토큰은 NSS 데이터베이스에 있지만 인증서를 포함하는 물리적 토큰을 가질 수도 있습니다. OpenSSL을 사용하면 개별 인증서와 개인 키가 PEM 파일에 저장됩니다. NSS를 사용하면 데이터베이스에 저장됩니다. 각 인증서 및 키는 토큰과 연결되며 각 토큰에는 암호를 보호할 수 있습니다. 이 암호는 선택 사항이지만 암호를 사용하는 경우 Apache HTTP 서버에 시스템 시작 시 사용자 개입 없이 데이터베이스를 열기 위해 사본이 필요합니다.
mod_nss 구성
mod_nss 를
root
로 설치합니다.~]# yum install mod_nss
그러면
/etc/httpd/conf.d/nss.conf
에mod_nss
구성 파일이 생성됩니다./etc/httpd/conf.d/
디렉터리는 기본적으로 기본 Apache HTTP Server 구성 파일에 포함되어 있습니다. 모듈을 로드하려면 14.1.3.3절. “서비스를 다시 시작” 에 설명된 대로httpd
서비스를 다시 시작합니다.root
로서/etc/httpd/conf.d/nss.conf
파일을 열고Listen
지시문의 모든 인스턴스를 검색합니다.다음과 같이
Listen 8443
행을 편집합니다.Listen 443
포트
443
은HTTPS
의 기본 포트입니다.기본
VirtualHost 기본:8443
행을 다음과 같이 편집합니다.VirtualHost default:443
기본이 아닌 다른 가상 호스트 섹션이 있는 경우 편집합니다. 파일을 저장하고 닫습니다.
Mozilla NSS는
/etc/httpd/conf.d/nss.conf
파일의NSSCertificateDatabase
지시문으로 표시된 서버 인증서 데이터베이스에 인증서를 저장합니다. 기본적으로 경로는 설치 중에 생성된 NSS 데이터베이스인/etc/httpd/alias
로 설정됩니다.기본 NSS 데이터베이스를 보려면 다음과 같이 명령을 실행합니다.
~]# certutil -L -d /etc/httpd/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI cacert CTu,Cu,Cu Server-Cert u,u,u alpha u,pu,u
위의 명령 출력에서
Server-Cert
는 기본NSSNickname
입니다. L옵션
은 모든 인증서를 나열하거나 인증서 데이터베이스에 이름이 지정된 인증서에 대한 정보를 표시합니다. d 옵션은 인증서 및 키 데이터베이스 파일이 포함된 데이터베이스 디렉터리를 지정합니다.자세한 명령행 옵션은
certutil(1)
도움말 페이지를 참조하십시오.다른 데이터베이스를 사용하도록 mod_nss 를 구성하려면
/etc/httpd/conf.d/nss.conf
파일에서NSSCertificateDatabase
행을 편집합니다. 기본 파일에는 VirtualHost 섹션에 다음 행이 있습니다.# Server Certificate Database: # The NSS security database directory that holds the certificates and # keys. The database consists of 3 files: cert8.db, key3.db and secmod.db. # Provide the directory that these files exist. NSSCertificateDatabase /etc/httpd/alias
위의 명령 출력에서
alias
는 기본 NSS 데이터베이스 디렉터리인/etc/httpd/alias/
입니다.기본 NSS 인증서 데이터베이스에 암호를 적용하려면
root
로 다음 명령을 사용하십시오.~]# certutil -W -d /etc/httpd/alias Enter Password or Pin for "NSS Certificate DB": Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password: Re-enter password: Password changed successfully.
HTTPS 서버를 배포하기 전에 CA(인증 기관)에서 서명한 인증서를 사용하여 새 인증서 데이터베이스를 생성합니다.
예 14.3. Mozilla NSS 데이터베이스에 인증서 추가
certutil
명령은 NSS 데이터베이스 파일에 CA 인증서를 추가하는 데 사용됩니다.certutil -d
/etc/httpd/nss-db-directory/
-A -n "CA_certificate" -tCT,,
-a -icertificate.pem
위의 명령은 certificate.pem 이라는 PEM 형식의 파일에 저장된 CA 인증서를 추가합니다. d 옵션은 인증서 및 키 데이터베이스 파일을 포함하는 NSS 데이터베이스 디렉터리를 지정하고
-n
옵션은 인증서의 이름을 설정합니다.-t
vGPU는 인증서가 TLS 클라이언트 및 서버에서 사용될 수 있음을 의미합니다.A 옵션은 기존 인증서를 인증서 데이터베이스에 추가합니다.
데이터베이스가 없으면 생성됩니다. a 옵션을 사용하면 입력 또는 출력에 ASCII 형식을 사용할 수 있으며
-i
옵션은certificate.pem
입력 파일을 명령에 전달합니다.자세한 명령행 옵션은
certutil(1)
도움말 페이지를 참조하십시오.NSS 데이터베이스는 개인 키를 보호하도록 암호로 보호되어야 합니다.
예 14.4. Mozilla NSS 데이터베이스의 암호 설정
certutil
툴을 사용하여 다음과 같이 NSS 데이터베이스의 암호를 설정할 수 있습니다.certutil -W -d /etc/httpd/nss-db-directory/
예를 들어 기본 데이터베이스의 경우 다음과 같이
root
로 명령을 실행합니다.~]# certutil -W -d /etc/httpd/alias Enter Password or Pin for "NSS Certificate DB": Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password: Re-enter password: Password changed successfully.
다음과 같이
NSSPassPhraseDialog
지시문으로 행을 변경하여 NSS 내부 소프트웨어 토큰을 사용하도록mod_nss
를 구성합니다.~]# vi /etc/httpd/conf.d/nss.conf NSSPassPhraseDialog file:/etc/httpd/password.conf
이는 시스템 시작 시 수동 암호 입력을 방지하기 위한 것입니다. 소프트웨어 토큰은 NSS 데이터베이스에 있지만 인증서가 포함된 물리적 토큰을 가질 수도 있습니다.
NSS 데이터베이스에 포함된 SSL 서버 인증서가 RSA 인증서인 경우
NSSNickname
매개변수의 주석을 제거하고 위의 4 단계에 표시된 nickname과 일치하는지 확인합니다.~]# vi /etc/httpd/conf.d/nss.conf NSSNickname Server-Cert
NSS 데이터베이스에 포함된 SSL 서버 인증서가 ECC 인증서인 경우
NSSECCNickname
매개변수의 주석을 제거하고 위의 4 단계에 표시된 nickname과 일치하는지 확인합니다.~]# vi /etc/httpd/conf.d/nss.conf NSSECCNickname Server-Cert
NSSCertificateDatabase
매개변수의 주석을 제거하고 단계 4에 표시된 NSS 데이터베이스 디렉토리를 가리키거나 위의 5단계에서 구성된 NSS 데이터베이스 디렉토리를 가리킵니다.~]# vi /etc/httpd/conf.d/nss.conf NSSCertificateDatabase /etc/httpd/alias
/etc/httpd/alias
를 사용할 인증서 데이터베이스의 경로로 바꿉니다./etc/httpd/password.conf
파일을root
로 만듭니다.~]# vi /etc/httpd/password.conf
다음 형식으로 행을 추가합니다.
internal:password
위의 6단계에서 NSS 보안 데이터베이스에 적용된 암호로 암호 교체
/etc/httpd/password.conf
파일에 적절한 소유권 및 권한을 적용합니다.~]# chgrp apache /etc/httpd/password.conf ~]# chmod 640 /etc/httpd/password.conf ~]# ls -l /etc/httpd/password.conf -rw-r-----. 1 root apache 10 Dec 4 17:13 /etc/httpd/password.conf
/etc/httpd/password.conf
에서 소프트웨어 토큰을 사용하도록mod_nss
를 구성하려면/etc/httpd/conf.d/nss.conf
를 다음과 같이 편집합니다.~]# vi /etc/httpd/conf.d/nss.conf
- 에 설명된 대로 변경 사항을 적용하려면 Apache 서버를 다시 시작합니다. 14.1.3.3절. “서비스를 다시 시작”
POODLE에서 설명하는 취약점으로 인해 다음을 수행합니다. SSLv3 취약점 (CVE-2014-3566) 은 SSL
을 비활성화하고 TLSv1.1
또는 TLSv1.2
만 사용하는 것이 좋습니다. 이전 버전과의 호환성은 TLSv1.0
을 사용하여 수행할 수 있습니다. Red Hat에서 지원하는 많은 제품에는 SSLv2
또는 SSLv3
프로토콜을 사용하거나 기본적으로 이를 활성화할 수 있습니다. 그러나 이제 SSLv2
또는 SSLv3
를 사용하는 것이 좋습니다.
14.1.9.1. mod_nss에서 SSL 및 TLS 활성화 및 비활성화
SSL 및 TLS 프로토콜의 특정 버전을 비활성화 및 활성화하려면구성 파일의 "# SSL Global Context" 섹션에 NSSProtocol
지시문을 추가하고 다른 곳에서 이를 제거하고 모든 "VirtualHost" 섹션의 기본 항목을 편집하여 전역적으로 수행합니다. 도메인별 VirtualHost 섹션에서 지정하지 않으면 전역 섹션에서 설정을 상속합니다. 프로토콜 버전이 비활성화되도록 하려면 관리자는 "SSL 글로벌 컨텍스트" 섹션에서 NSSProtocol
만 지정하거나 모든 도메인별 VirtualHost 섹션에 지정해야 합니다.
모든 SSL 및 TLS 프로토콜 사용 안 함 TLS 1 및 Up in mod_nss 비활성화
TLS 버전 1 이상을 제외한 모든 SSL 및 TLS 프로토콜 버전을 비활성화하려면 다음과 같이 진행하십시오.
루트
로서/etc/httpd/conf.d/nss.conf
파일을 열고NSSProtocol
지시문의 모든 인스턴스를 검색합니다. 기본적으로 구성 파일에는 다음과 같은 섹션이 포함되어 있습니다.~]# vi /etc/httpd/conf.d/nss.conf # SSL Protocol: output omitted # Since all protocol ranges are completely inclusive, and no protocol in the # middle of a range may be excluded, the entry "NSSProtocol SSLv3,TLSv1.1" # is identical to the entry "NSSProtocol SSLv3,TLSv1.0,TLSv1.1". NSSProtocol SSLv3,TLSv1.0,TLSv1.1
이 섹션은 VirtualHost 섹션에 있습니다.
다음과 같이
NSSProtocol
행을 다음과 같이 편집합니다.# SSL Protocol: NSSProtocol TLSv1.0,TLSv1.1
모든 VirtualHost 섹션에 대해 이 작업을 반복합니다.
다음과 같이
Listen 8443
행을 편집합니다.Listen 443
기본
VirtualHost 기본:8443
행을 다음과 같이 편집합니다.VirtualHost default:443
기본이 아닌 다른 가상 호스트 섹션이 있는 경우 편집합니다. 파일을 저장하고 닫습니다.
다음과 같이
NSSProtocol
지시문의 모든 항목이 변경되었는지 확인합니다.~]# grep NSSProtocol /etc/httpd/conf.d/nss.conf # middle of a range may be excluded, the entry "NSSProtocol SSLv3,TLSv1.1" # is identical to the entry "NSSProtocol SSLv3,TLSv1.0,TLSv1.1". NSSProtocol TLSv1.0,TLSv1.1
하나 이상의 VirtualHost 섹션이 있는 경우 이 단계는 특히 중요합니다.
다음과 같이 Apache 데몬을 다시 시작하십시오.
~]# service httpd restart
모든 세션이 중단됩니다.
mod_nss에서 SSL 및 TLS 프로토콜 상태 테스트
mod_nss 에서 활성화되거나 비활성화되는 SSL 및 TLS 버전을 확인하려면 openssl s_client -connect
명령을 사용하십시오. openssl 패키지를 root
로 설치합니다.
~]# yum install openssl
openssl s_client -connect
명령의 형식은 다음과 같습니다.
openssl s_client -connect hostname:port -protocol
여기서 port 는 테스트할 포트이고 프로토콜 은 테스트할 프로토콜 버전입니다. 로컬에서 실행되는 SSL 서버를 테스트하려면 호스트 이름으로 localhost
를 사용합니다. 예를 들어 보안 HTTPS 연결에 대한 기본 포트를 테스트하려면 포트 443
을 사용하여 SSLv3가 활성화되어 있는지 확인하고 다음과 같이 명령을 실행합니다.
~]# openssl s_client -connect localhost:443 -ssl3 CONNECTED(00000003) 3077773036:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: output omitted New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv3 output truncated
위의 출력은 핸드셰이크에 실패하여 암호가 협상되지 않았음을 나타냅니다.
~]$ openssl s_client -connect localhost:443 -tls1 CONNECTED(00000003) depth=1 C = US, O = example.com, CN = Certificate Shack output omitted New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 output truncated
위 출력은 핸드셰이크의 실패가 발생하지 않았으며 일련의 암호 집합이 협상되었음을 나타냅니다.
openssl s_client
명령 옵션은 s_client(1)
매뉴얼 페이지에 설명되어 있습니다.
SSLv3 취약점 및 테스트 방법에 대한 자세한 내용은 Red Hat 지식베이스 문서 POODLE을 참조하십시오. SSLv3 취약점 (CVE-2014-3566).
14.1.10. 기존 키 및 인증서 사용
이전에 생성된 키와 인증서가 있는 경우 새 파일을 생성하는 대신 이러한 파일을 사용하도록 SSL 서버를 구성할 수 있습니다. 이 작업을 수행할 수 없는 경우 다음 두 가지 상황만 있습니다.
IP 주소 또는 도메인 이름을 변경하고 있습니다.
인증서는 특정 IP 주소 및 도메인 이름 쌍에 대해 발급됩니다. 이러한 값 중 하나가 변경되면 인증서가 유효하지 않습니다.
VeriSign의 인증서가 있고 서버 소프트웨어를 변경하고 있습니다.
널리 사용되는 인증 기관인 RuntimeClass는 특정 소프트웨어 제품, IP 주소 및 도메인 이름에 대한 인증서를 발행합니다. 소프트웨어 제품을 변경하면 인증서가 유효하지 않습니다.
위의 두 경우 모두 새 인증서를 가져와야 합니다. 이 항목에 대한 자세한 내용은 14.1.11절. “새 키 및 인증서 생성” 을 참조하십시오.
기존 키와 인증서를 사용하려면 관련 파일을 각각 /etc/pki/tls/private/
및 /etc/pki/tls/certs/
디렉토리로 이동합니다. root
로 다음 명령을 실행하여 이를 수행할 수 있습니다.
~]# mvkey_file.key
/etc/pki/tls/private/hostname.key
~]# mvcertificate.crt
/etc/pki/tls/certs/hostname.crt
그런 다음 /etc/httpd/conf.d/ssl.conf
구성 파일에 다음 행을 추가합니다.
SSLCertificateFile /etc/pki/tls/certs/hostname.crt SSLCertificateKeyFile /etc/pki/tls/private/hostname.key
업데이트된 구성을 로드하려면 14.1.3.3절. “서비스를 다시 시작” 에 설명된 대로 httpd
서비스를 다시 시작합니다.
예 14.5. Red Hat Secure Web Server의 키와 인증서 사용
~]# mv /etc/httpd/conf/httpsd.key /etc/pki/tls/private/penguin.example.com.key ~]# mv /etc/httpd/conf/httpsd.crt /etc/pki/tls/certs/penguin.example.com.crt
14.1.11. 새 키 및 인증서 생성
새 키와 인증서 쌍을 생성하려면 crypto-utils 패키지를 시스템에 설치해야 합니다. 이를 설치하려면 root
로 다음 명령을 입력합니다.
~]# yum install crypto-utils
이 패키지는 SSL 인증서 및 개인 키를 생성 및 관리하는 도구 집합을 제공하며 키 생성 프로세스를 통해 안내하는 Red Hat 키 쌍 생성 유틸리티인 genkey 가 포함되어 있습니다.
서버에 이미 유효한 인증서가 있고 새 인증서로 교체하는 경우 다른 일련 번호를 지정합니다. 이렇게 하면 클라이언트 브라우저에 이 변경 사항이 알림을 받고 이 새 인증서를 예상대로 업데이트하고 페이지에 액세스하지 못합니다. 사용자 지정 일련번호를 root
로 사용하여 새 인증서를 생성하려면 genkey 대신 다음 명령을 사용하십시오.
~]# openssl req -x509 -new -set_serial number -key hostname.key -out hostname.crt
시스템에 특정 호스트 이름에 대한 키 파일이 이미 있는 경우 genkey 는 시작을 거부합니다. 이 경우 다음 명령을 사용하여 기존 파일을 root
로 제거합니다.
~]# rm /etc/pki/tls/private/hostname.key
유틸리티를 실행하려면 루트
genkey
명령을 입력한 다음 적절한 호스트 이름(예: Penguin .example.com)을 입력합니다.
~]# genkey hostname
키 및 인증서 생성을 완료하려면 다음 단계를 수행합니다.
키와 인증서를 저장할 대상 위치를 검토합니다.
그림 14.1. genkey 유틸리티 실행
Tab 키를 사용하여
버튼을 선택하고 Enter 를 눌러 다음 화면으로 진행합니다.위쪽 및 아래쪽 화살표 키를 사용하여 적절한 키 크기를 선택합니다. 더 큰 키는 보안이 높아지지만 서버의 응답 시간도 증가합니다. NIST는
2048비트
를 사용하는 것이 좋습니다. NIST 특수 발행 800-131A 를 참조하십시오.그림 14.2. 키 크기 선택
완료되면 Tab 키를 사용하여
버튼을 선택하고 Enter 를 눌러 임의의 비트 생성 프로세스를 시작합니다. 선택한 키 크기에 따라 다소 시간이 걸릴 수 있습니다.인증서 요청을 인증 기관에 보낼지 여부를 결정합니다.
그림 14.3. 인증서 요청 생성
Tab 키를 사용하여
를 선택하여 인증서 요청을 작성하거나 를 선택하여 자체 서명된 인증서를 생성합니다. 그런 다음 Enter 를 눌러 선택을 확인합니다.Spacebar 키를 사용하여 개인 키 암호화를 활성화(
[*]
)
하거나 사용하지 않도록 설정합니다.그림 14.4. 개인 키 암호화
Tab 키를 사용하여
버튼을 선택하고 Enter 를 눌러 다음 화면으로 진행합니다.개인 키 암호화를 활성화한 경우 적절한 암호를 입력합니다. 보안상의 이유로 입력한 대로 표시되지 않으며 최소 5자 이상이어야 합니다.
그림 14.5. 암호를 입력
Tab 키를 사용하여
버튼을 선택하고 Enter 를 눌러 다음 화면으로 진행합니다.중요서버를 시작하려면 올바른 암호를 입력해야 합니다. 이를 손실하는 경우 새 키와 인증서를 생성해야 합니다.
인증서 세부 정보를 사용자 지정합니다.
그림 14.6. 인증서 정보 지정
Tab 키를 사용하여
버튼을 선택하고 Enter 를 눌러 키 생성을 완료합니다.이전에 인증서 요청 생성을 활성화한 경우 인증 기관으로 전송하라는 메시지가 표시됩니다.
그림 14.7. 인증서 요청을 보내는 방법에 대한 지침
Enter 를 눌러 쉘 프롬프트로 돌아갑니다.
생성된 키 및 인증서 위치를 /etc/httpd/conf.d/ssl.conf
구성 파일에 추가합니다.
SSLCertificateFile /etc/pki/tls/certs/hostname.crt SSLCertificateKeyFile /etc/pki/tls/private/hostname.key
마지막으로, 업데이트된 구성이 로드되도록 14.1.3.3절. “서비스를 다시 시작” 에 설명된 대로 httpd
서비스를 다시 시작합니다.
14.1.12. 명령줄을 사용하여 HTTP 및 HTTPS의 방화벽 구성
Red Hat Enterprise Linux는 기본적으로 HTTP
및 HTTPS
트래픽을 허용하지 않습니다. 시스템이 웹 서버 역할을 하도록 하려면 firewalld
의 지원되는 서비스를 사용하여 HTTP
및 HTTPS
트래픽이 필요에 따라 방화벽을 통과할 수 있도록 합니다.
명령줄을 사용하여 HTTP
를 활성화하려면 root
로 다음 명령을 실행합니다.
~]# firewall-cmd --add-service http success
명령줄을 사용하여 HTTPS
를 활성화하려면 root
로 다음 명령을 실행합니다.
~]# firewall-cmd --add-service https success
이러한 변경 사항은 다음 시스템을 시작한 후에도 유지되지 않습니다. 방화벽을 영구적으로 변경하려면 --permanent
옵션을 추가하는 명령을 반복합니다.
14.1.12.1. 명령줄을 사용하여 예정된 HTTPS 및 HTTPS에 대한 네트워크 액세스 확인
방화벽이 구성된 서비스를 확인하려면 명령줄을 사용하여 root
로 다음 명령을 실행합니다.
~]# firewall-cmd --list-all
public (default, active)
interfaces: em1
sources:
services: dhcpv6-client ssh
output truncated
기본 설치에서 가져온 예에서는 방화벽이 활성화되지만 HTTP
및 HTTPS
는 통과할 수 없습니다.
HTTP
및 HTTP
방화벽 서비스가 활성화되면 services
행이 다음과 유사합니다.
services: dhcpv6-client http https ssh
방화벽 서비스 활성화 또는 firewalld
를 사용하여 포트 열기 및 닫기에 대한 자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드 를 참조하십시오.
14.1.13. 추가 리소스
Apache HTTP Server에 대한 자세한 내용은 다음 리소스를 참조하십시오.
설치된 문서
-
httpd(8)
- 명령줄 옵션의 전체 목록을 포함하는httpd
서비스의 도움말 페이지입니다. -
genkey(1)
- crypto-utils 패키지에서 제공하는genkey
유틸리티의 도움말 페이지. -
apachectl(8)
- Apache HTTP 서버 제어 인터페이스의 도움말 페이지.
설치 가능한 문서
http://localhost/manual/ - 해당 지시문 및 사용 가능한 모듈에 대한 전체 설명과 함께 Apache HTTP Server의 공식 문서입니다. 이 설명서에 액세스하려면 httpd-manual 패키지가 설치되어 있고 웹 서버가 실행 중이어야 합니다.
문서에 액세스하기 전에
root
로 다음 명령을 실행합니다.~] yum install httpd-manual ~] apachectl graceful
온라인 문서
- http://httpd.apache.org/ - 모든 지시문 및 기본 모듈에 대한 문서가 있는 Apache HTTP Server의 공식 웹 사이트.
- http://www.openssl.org/ - 추가 문서가 포함된 OpenSSL 홈 페이지, 자주 묻는 질문, 메일링 목록에 대한 링크, 기타 유용한 리소스입니다.
15장. 메일 서버
Red Hat Enterprise Linux는 이메일 제공 및 액세스를 위한 다양한 고급 애플리케이션을 제공합니다. 이 장에서는 현재 사용 중인 최신 이메일 프로토콜과 이메일을 보내고 수신하도록 설계된 일부 프로그램에 대해 설명합니다.
15.1. 이메일 프로토콜
현재 이메일은 클라이언트/서버 아키텍처를 사용하여 제공됩니다. 이메일 메시지는 메일 클라이언트 프로그램을 사용하여 생성됩니다. 이 프로그램은 서버에 메시지를 보냅니다. 그런 다음 서버는 메시지를 수신자의 이메일 서버로 전달합니다. 여기서 메시지가 수신자의 이메일 클라이언트에 제공됩니다.
이 프로세스를 지원하기 위해 다양한 표준 네트워크 프로토콜을 사용하면 다른 시스템, 종종 다른 운영 체제를 실행하고 다른 이메일 프로그램을 사용하여 이메일을 보내고 받을 수 있습니다.
다음 설명 된 프로토콜은 이메일 전송에 가장 일반적으로 사용됩니다.
15.1.1. 메일 전송 프로토콜
클라이언트 애플리케이션에서 서버로, 원본 서버에서 대상 서버로의 메일 전달은SMTP( Simple mail Transfer Protocol )에 의해 처리됩니다.
15.1.1.1. SMTP
SMTP의 주요 목적은 메일 서버 간에 이메일을 전송하는 것입니다. 그러나 이는 또한 이메일 고객에게도 중요합니다. 이메일을 보내기 위해 클라이언트는 발신 메일 서버로 메시지를 보냅니다. 그러면 배달을 위해 대상 메일 서버에 연결합니다. 그러나 더 많은 중간 SMTP 서버가 이 체인에 포함될 수 있습니다. 이 개념을 메일 릴레이라고 합니다. 따라서 이메일 클라이언트를 구성할 때 SMTP 서버를 지정해야 합니다.
Red Hat Enterprise Linux에서 사용자는 메일 전송을 처리하기 위해 로컬 시스템에서 SMTP 서버를 구성할 수 있습니다. 그러나 발신 메일에 대해 원격 SMTP 서버를 구성할 수도 있습니다.
SMTP 프로토콜에 대한 한 가지 중요한 점은 인증이 필요하지 않다는 것입니다. 이렇게 하면 인터넷의 모든 사람이 다른 사람이나 큰 그룹에도 이메일을 보낼 수 있습니다. 이 특징은 정크 이메일 또는 스팸 을 가능하게 하는 SMTP의 특징입니다. 중계 제한으로 인해 인터넷상의 임의의 사용자가 이메일을 SMTP 서버를 통해 보내는 것을 제한하며, 인터넷의 다른 서버로는 전송됩니다. 이러한 제한 사항을 적용하지 않는 서버를 공개 릴레이 서버라고 합니다.
Red Hat Enterprise Linux 7은78 및 Sendmail SMTP 프로그램을 제공합니다.
15.1.2. 메일 액세스 프로토콜
이메일 클라이언트 애플리케이션이 메일 서버에서 이메일을 검색하는 데 사용하는 두 가지 기본 프로토콜인POP( Post Office Protocol ) 및 RHSA( Internet Message Access Protocol )입니다.
15.1.2.1. POP
Red Hat Enterprise Linux의 기본 POP 서버는 Dovecot 이며 dovecot 패키지에서 제공합니다.
Dovecot 를 설치하려면 다음 명령을 실행합니다.
~]# yum install dovecot
YUM을 사용하여 패키지 설치에 대한 자세한 내용은 9.2.4절. “패키지 설치” 을 참조하십시오.
POP
서버를 사용하면 클라이언트 애플리케이션에서 이메일 메시지를 다운로드합니다. 기본적으로 대부분의 POP
이메일 클라이언트는 전송 후 이메일 서버에서 메시지를 삭제하도록 자동으로 구성되지만 이 설정은 일반적으로 변경할 수 있습니다.
POP
는 이메일 첨부 파일을 허용하는 Multipurpose Internet Mail Extensions (MIME)와 같은 중요한 인터넷 메시지 표준과 완전히 호환됩니다.
POP
는 이메일을 읽을 수 있는 시스템을 가진 사용자에게 가장 적합합니다. 또한 인터넷에 지속적으로 연결되지 않은 사용자 또는 메일 서버가 포함된 네트워크에서도 잘 작동합니다. 네트워크 연결이 느리기 때문에 POP
는 인증 시 각 메시지의 전체 콘텐츠를 다운로드하기 위해 클라이언트 프로그램이 필요합니다. 메시지가 큰 첨부 파일이 있는 경우 시간이 오래 걸릴 수 있습니다.
표준 POP
프로토콜의 최신 버전은 POP3
입니다.
그러나 덜 사용되는 다양한 POP
프로토콜 변형이 있습니다.
-
APOP -
POP3
MD5
인증 사용자 암호의 인코딩된 해시는 암호화되지 않은 암호를 전송하지 않고 이메일 클라이언트에서 서버로 전송됩니다. -
KPOP - Kerberos 인증을 사용하는
POP3
-
RPOP -
RPOP
인증을 사용하는POP3
. 이는 암호와 유사한 사용자별 ID를 사용하여 POP 요청을 인증합니다. 그러나 이 ID는 암호화되지 않으므로RPOP
는 표준POP
보다 더 안전하지 않습니다.
보안을 강화하기 위해 클라이언트 인증 및 데이터 전송 세션에SSL( Secure Socket Layer ) 암호화를 사용할 수 있습니다. SSL 암호화를 활성화하려면 다음을 사용합니다.
-
pop3s
서비스 -
stunnel
애플리케이션 -
starttls
명령
이메일 통신 보안에 대한 자세한 내용은 15.5.1절. “통신 보안” 을 참조하십시오.
15.1.2.2. IMAP
Red Hat Enterprise Linux의 기본 gRPC 서버는 Dovecot 이며 dovecot 패키지에서 제공합니다. Dovecot 를 설치하는 방법에 대한 자세한 내용은 15.1.2.1절. “POP” 을 참조하십시오.
gRPC 메일 서버를
사용하는 경우 사용자가 읽거나 삭제할 수 있는 서버에 이메일 메시지가 남아 있습니다. 클라이언트 애플리케이션에서는 또한 서버에서 메일 디렉터리를 생성, 이름 변경 또는 삭제하여 이메일을 구성 및 저장할 수 있습니다.
redfish
는 여러 시스템을 사용하여 이메일에 액세스하는 사용자에게 특히 유용합니다. 이 프로토콜은 또한 느린 연결을 통해 메일 서버에 연결하는 사용자에게 편리합니다. 이메일 헤더 정보 만 열 때까지 메시지에 다운로드되므로 대역폭을 절약할 수 있습니다. 사용자는 또한 보거나 다운로드 하지 않고 메시지를 삭제할 수 있는 기능이 있습니다.
편의를 위해 pxe
클라이언트 애플리케이션은 로컬로 메시지 사본을 캐싱할 수 있으므로, 사용자가 gRPC 서버에 직접 연결되지 않을 때 이전에 메시지를 읽을 수
있습니다.
POP
와 같은 IMAP
는 이메일 첨부 파일을 허용하는 MIME과 같은 중요한 인터넷 메시지 표준과 완벽하게 호환됩니다.
보안을 강화하기 위해 클라이언트 인증 및 데이터 전송 세션에 SSL
암호화를 사용할 수 있습니다. 이 기능은 SriovIBNetwork s 서비스를 사용하거나
stunnel
프로그램을 사용하여 활성화할 수 있습니다.
-
pop3s
서비스 -
stunnel
애플리케이션 -
starttls
명령
이메일 통신 보안에 대한 자세한 내용은 15.5.1절. “통신 보안” 을 참조하십시오.
상용, gRPC 클라이언트 및 서버뿐만 아니라 기타 무료도 사용할 수 있으며, 많은 경우 operations 중 많은 사용자가 operations를 확장하고 추가 기능을 제공합니다.
15.1.2.3. dovecot
dove cot 패키지에 포함된 마스터
및 dovecot
데몬에 의해 creatingvv 및 POP3
프로토콜을 구현하는 redfish-loginpop3-login
프로세스는 dovecot 데몬에 의해 생성됩니다. DestinationRule 및
POP
의 사용은 /etc/dovecot/dovecot.conf
구성 파일을 통해 구성됩니다. 기본적으로 dovecot
는 SSL
을 사용하여 보안 버전과 함께 gRPC 및 POP3
을 실행합니다.
POP
를 사용하도록 dovecot
를 구성하려면 다음 단계를 완료합니다.
/etc/dovecot/dovecot.conf
구성 파일을 편집하여프로토콜
변수의 주석을 제거하고 행 시작 시 해시 기호(#
) 삭제)에pop3
인수가 포함되어 있는지 확인합니다. 예를 들면 다음과 같습니다.protocols = imap pop3 lmtp
protocols
변수가 주석 처리되면dovecot
는 위에서 설명한 대로 기본값을 사용합니다.root
로 다음 명령을 실행하여 현재 세션에 대해 작동을 변경합니다.~]# systemctl restart dovecot
다음 재부팅 후 명령을 실행하여 변경합니다.
~]# systemctl enable dovecot Created symlink from /etc/systemd/system/multi-user.target.wants/dovecot.service to /usr/lib/systemd/system/dovecot.service.
참고dovecot
는 pxe 서버를 시작한 보고서만 보고하지만POP3
서버도 시작합니다.
SMTP
와 달리 redfish 및
POP3
모두 사용자 이름 및 암호를 사용하여 클라이언트를 인증해야 합니다. 기본적으로 두 프로토콜의 암호는 암호화되지 않은 네트워크를 통해 전달됩니다.
dovecot
에서 SSL
을 구성하려면 다음을 수행합니다.
/etc/dovecot/conf.d/10-ssl.conf
구성을 편집하여ssl_protocols
변수의 주석을 제거하고!SSLv2 !SSLv3
인수가 포함되어 있는지 확인합니다.ssl_protocols = !SSLv2 !SSLv3
이 값을 사용하면
dovecot
가 SSL 버전 2와 3을 방지할 수 있으며 둘 다 안전하지 않은 것으로 알려져 있습니다. 이는 POODLE에서 설명하는 취약점으로 인한 것입니다. SSLv3 취약점 (CVE-2014-3566). Etcd 및 Dovecot에서 POODLE SSL 3.0 취약점(CVE-2014-3566)에 대한 확인 을 참조하십시오./etc/dovecot/conf.d/10-ssl.conf
에 다음 옵션이 포함되어 있는지 확인합니다.ssl=required
-
원하는 대로
/etc/pki/dovecot/dovecot-openssl.cnf
구성 파일을 편집합니다. 그러나 일반적인 설치에서는 이 파일을 수정할 필요가 없습니다. -
/etc/pki/dovecot/certs/dovecot.pem
및/etc/pki/dovecot/private/dovecot.pem
파일의 이름을 변경, 이동 또는 삭제합니다. dovecot
자체 서명된 인증서를 생성하는/usr/libexec/dovecot/mkcert.sh
스크립트를 실행합니다. 이러한 인증서는/etc/pki/dovecot/certs
및/etc/pki/dovecot/private
디렉터리에 복사됩니다. 변경 사항을 구현하려면root
로 다음 명령을 실행하여dovecot
를 다시 시작합니다.~]# systemctl restart dovecot
Dovecot
에 대한 자세한 내용은 http://www.dovecot.org 에서 확인할 수 있습니다.
15.2. 이메일 프로그램 분류
일반적으로 모든 이메일 애플리케이션은 세 가지 분류 중 하나 이상에 속합니다. 각 분류는 이메일 메시지 이동 및 관리 과정에서 특정 역할을 수행합니다. 대부분의 사용자는 메시지를 수신하고 보내는 데 사용하는 특정 이메일 프로그램만을 알고 있지만, 각 이메일은 이메일이 올바른 대상에 도달하도록 하는 데 중요합니다.
15.2.1. 메일 전송 에이전트
MTA (mail Transport Agent )는 SMTP
를 사용하여 호스트 간에 이메일 메시지를 전송합니다. 메시지에는 의도한 대상으로 이동할 때 여러 MTA가 포함될 수 있습니다.
시스템 간에 메시지를 전달하는 것은 다소 간단해 보일 수 있지만 특정 MTA가 전송에 대한 메시지를 수락할 수 있는지 여부를 결정하는 전체 프로세스는 매우 복잡합니다. 또한 스팸 문제로 인해 특정 MTA의 사용은 일반적으로 MTA의 구성 또는 MTA가 상주하는 네트워크에 대한 액세스 구성에 의해 제한됩니다.
일부 이메일 클라이언트 프로그램은 이메일을 보낼 때 MTA 역할을 할 수 있습니다. 그러나 이러한 이메일 클라이언트 프로그램에는 사용할 권한이 있는 MTA에만 아웃바운드 메시지를 보낼 수 있지만 의도된 수신자의 이메일 서버에 메시지를 직접 전달할 수 없기 때문에 실제 MTA의 역할이 없습니다. 이 기능은 애플리케이션을 실행하는 호스트에 자체 MTA가 없는 경우 유용합니다.
Red Hat Enterprise Linux는 두 개의 MTA, Postfix 및 Sendmail 을 제공하므로 이메일 클라이언트 프로그램은 MTA 역할을 할 필요가 없는 경우가 많습니다. Red Hat Enterprise Linux에는 Fetchmail 이라는 특별한 용도 MTA도 포함되어 있습니다.
Postfix, Sendmail 및 Fetchmail에 대한 자세한 내용은 15.3절. “메일 전송 에이전트” 를 참조하십시오.
15.2.2. 메일 전송 에이전트
MDA( mail Delivery Agent )는 MTA에서 적절한 사용자의 메일로 수신되는 이메일을 파일로 호출합니다. 대부분의 경우 MDA는 실제로 메일
또는 Procmail과 같은LDA( Local Delivery Agent )입니다.
이메일 클라이언트 애플리케이션에서 읽을 수 있는 지점으로 전달을 위해 실제로 메시지를 처리하는 모든 프로그램은 MDA로 간주할 수 있습니다. 이러한 이유로 일부 MTA(예: Sendmail 및 Postfix)는 로컬 사용자의 메일 스풀 파일에 새 이메일 메시지를 추가할 때 MDA의 역할을 채울 수 있습니다. 일반적으로 MDA는 시스템 간에 메시지를 전송하지 않으며 사용자 인터페이스를 제공하지 않습니다. MDA는 이메일 클라이언트 애플리케이션에 액세스할 이메일 클라이언트 애플리케이션에 액세스할 수 있도록 로컬 시스템에서 메시지를 배포하고 정렬합니다.
15.2.3. 메일 사용자 에이전트
MUA (mail User Agent )는 이메일 클라이언트 애플리케이션과 동의어입니다. MUA는 최소한 사용자가 이메일 메시지를 읽고 작성할 수 있는 프로그램입니다. MUA는 다음 작업을 처리할 수 있습니다.
-
POP
또는 NetNamespace 프로토콜을 통해 메시지 검색 - 메시지를 저장하기 위해 RuntimeClass를 설정합니다.
- MTA에 아웃바운드 메시지 전송.
MUA는 graphical일 수도 있고, (예: rhcos , DomainMapping ) 또는 mail
또는 Mutt 와 같은 간단한 텍스트 기반 인터페이스를 사용할 수 있습니다.
15.3. 메일 전송 에이전트
Red Hat Enterprise Linux 7은 다음 두 가지 주요 MTA를 제공합니다. redfish 및 Sendmail. redfish는 기본 MTA로 구성되며 Sendmail은 더 이상 사용되지 않는 것으로 간주됩니다. 기본 MTA를 Sendmail으로 전환해야 하는 경우 Postfix를 제거하거나 다음 명령을 root
로 사용하여 Sendmail로 전환할 수 있습니다.
~]# alternatives --config mta
다음 명령을 사용하여 원하는 서비스를 활성화할 수도 있습니다.
~]# systemctl enable service
마찬가지로 서비스를 비활성화하려면 쉘 프롬프트에서 다음을 입력합니다.
~]# systemctl disable service
Red Hat Enterprise Linux 7에서 시스템 서비스를 관리하는 방법에 대한 자세한 내용은 10장. systemd를 사용하여 서비스 관리 를 참조하십시오.
15.3.1. RHEA
원래 IBM의 보안 전문가 및 프로그래머가 Wetse Venema에서 개발되었으며, post는 안전하고 빠르고 쉽게 구성할 수 있도록 설계된 Sendmail 호환 MTA입니다.
보안 향상을 위해 Postfix는 제한된 권한이 있는 작은 프로세스가 마스터 데몬에서 시작되는 모듈식 설계를 사용합니다. 권한이 적은 작은 프로세스는 메일 전송의 다양한 단계와 관련된 매우 구체적인 작업을 수행하고 변경된 루트 환경에서 실행되어 공격의 영향을 제한합니다.
로컬 컴퓨터가 아닌 호스트의 네트워크 연결을 수락하도록 Postfix를 구성하는 작업은 구성 파일의 몇 가지 사소한 변경 사항만 사용합니다. 그러나 더 복잡한 요구 사항이 있는 사용자를 위해 SASL은 다양한 구성 옵션과 다양한 구성 옵션을 제공하여 매우 다양하고 완전한 기능을 갖춘 MTA를 만드는 타사 애드온을 제공합니다.
redfish의 구성 파일은 사람이 읽을 수 있고 250개 이상의 지시문을 지원합니다. Sendmail과 달리 변경 사항을 적용하려면 매크로 처리가 필요하지 않으며 가장 일반적으로 사용되는 옵션의 대부분은 크게 주석 처리된 파일에 설명되어 있습니다.
15.3.1.1. 기본 SASL 설치
postfix 실행 파일은 postfix
입니다. 이 데몬은 메일 배달을 처리하는 데 필요한 모든 관련 프로세스를 시작합니다.
Postfix는 구성 파일을 /etc/hiera/
디렉터리에 저장합니다. 다음은 더 일반적으로 사용되는 파일 목록입니다.
-
액세스
- 액세스 제어에 사용됩니다. 이 파일은 Postfix에 연결할 수 있는 호스트를 지정합니다. -
main.cf
- 글로벌 Postfix 구성 파일. 대부분의 구성 옵션은 이 파일에 지정되어 있습니다. -
master.cf
- Postfix가 메일 전달을 수행하기 위해 다양한 프로세스와 상호 작용하는 방법을 지정합니다. -
transport
- 호스트를 릴레이할 맵 이메일 주소입니다.
aliases
파일은 /etc
디렉토리에서 찾을 수 있습니다. 이 파일은 Postfix와 Sendmail 간에 공유됩니다. 이는 사용자 ID 별칭을 설명하는 메일 프로토콜에 필요한 구성 가능한 목록입니다.
기본 /etc/hiera/main.cf
파일은 Postfix가 로컬 컴퓨터가 아닌 호스트의 네트워크 연결을 수락하도록 허용하지 않습니다. rsyslog를 다른 클라이언트의 서버로 구성하는 방법은 15.3.1.3절. “기본 Postfix 구성” 을 참조하십시오.
해당 변경 사항을 적용하려면 /etc/hiera/
디렉터리에 있는 구성 파일의 옵션을 변경한 후 postfix
서비스를 다시 시작합니다. 이렇게 하려면 root
로 다음 명령을 실행하십시오.
~]# systemctl restart postfix
15.3.1.2. 이전 릴리스에서 업그레이드
Red Hat Enterprise Linux 7의 다음 설정은 이전 릴리스와 다릅니다.
-
disable_vrfy_command = no
- 이는 기본적으로 비활성화되며 Sendmail의 기본값이 다릅니다. 예로 변경한 경우 특정 이메일 주소 수집 방법을 방지할 수 있습니다. -
allow_percent_hack = yes
- 기본적으로 활성화되어 있습니다. 이메일 주소에서%
문자를 제거할 수 있습니다. 백분율 해킹은 이메일 메시지의 발신자 제어 라우팅을 허용하는 이전 해결 방법입니다.DNS
및 메일 라우팅은 이제 훨씬 더 신뢰할 수 있지만 Postfix는 계속 해킹을 지원합니다. 백분율 재쓰기를 해제하려면allow_percent_hack
을no
로 설정합니다. -
일부 애플리케이션이 이메일을 전송하지 못하도록 할 수 있기 때문에 Sendmail에 있기 때문에 기본적으로 이
_helo_required = no
- 이는 기본적으로 비활성화되어 있습니다. MAIL, FROM 또는 ETRN 명령을 보내기 전에 클라이언트가 HELO 또는 EHLO 명령을 전송하도록 요구하도록yes
로 변경할 수 있습니다.
15.3.1.3. 기본 Postfix 구성
기본적으로 Postfix는 로컬 호스트가 아닌 호스트의 네트워크 연결을 허용하지 않습니다. root
로 다음 단계를 수행하여 네트워크에서 다른 호스트에 대한 메일 전달을 활성화합니다.
-
vi
와 같은 텍스트 편집기를 사용하여/etc/ alice/main.cf
파일을 편집합니다. -
해시 기호
(#
)를 제거하여mydomain
행의 주석을 제거하고 domain.tld 를 메일 서버가 서비스하는 도메인으로 교체합니다(예:example.com
. -
myorigin = $mydomain
행의 주석을 제거합니다. -
myhostname
행의 주석을 제거하고 host.domain.tld 를 시스템의 호스트 이름으로 교체합니다. -
mydestination = $myhostname, localhost.$mydomain
행의 주석을 제거합니다. -
mynetworks
행의 주석을 제거하고 168.100.189.0/28 을 서버에 연결할 수 있는 호스트의 유효한 네트워크 설정으로 바꿉니다. -
inet_interfaces = 모든
행의 주석을 제거합니다. -
inet_interfaces = localhost
행을 주석 처리합니다. -
postfix
서비스를 다시 시작합니다.
이러한 단계가 완료되면 호스트는 외부 이메일을 수락하여 전달할 수 있습니다.
Postfix에는 구성 옵션의 많은 정렬이 있습니다. Postfix를 구성하는 방법을 배울 수 있는 가장 좋은 방법 중 하나는 /etc/hiera/main.cf
구성 파일 내의 주석을 읽는 것입니다. Postfix 구성, SpamAssassin 통합 또는 /etc/hiera/main.cf 매개변수에 대한 자세한 설명을 포함한 추가 리소스는 http://www.postfix.org/ 에서 온라인으로 확인할 수 있습니다.
POODLE에서 설명하는 취약점으로 인해 다음을 수행합니다. SSLv3 취약점 (CVE-2014-3566) 은 SSL
을 비활성화하고 TLSv1.1
또는 TLSv1.2
만 사용하는 것이 좋습니다. Etcd 및 Dovecot에서 POODLE SSL 3.0 취약점(CVE-2014-3566)에 대한 확인 을 참조하십시오.
15.3.1.4. LDAP에서 SASL 사용
Postfix는 LDAP
디렉터리를 다양한 조회 테이블(예: 별칭
,가상
,표준
등)의 소스로 사용할 수 있습니다. 이렇게 하면 LDAP
에서 계층적 사용자 정보를 저장할 수 있으며,mit은 필요한 경우에만 LDAP
쿼리 결과를 제공할 수 있습니다. 이 정보를 로컬에 저장하지 않으면 관리자가 쉽게 관리할 수 있습니다.
15.3.1.4.1. /etc/aliases 조회 예
다음은 LDAP
를 사용하여 /etc/aliases
파일을 검색하는 기본 예입니다. /etc/northeast/main.cf
파일에 다음이 포함되어 있는지 확인합니다.
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
아직 없는 경우 /etc/dhcp/ldap-aliases.cf
파일을 만들고 다음 파일이 포함되어 있는지 확인합니다.
server_host = ldap.example.com search_base = dc=example, dc=com
여기서 ldap.example.com
,example
및 com
은 사용 가능한 기존 LDAP
서버의 사양으로 교체해야 하는 매개 변수입니다.
/etc/journal/ldap-aliases.cf
파일은 LDAP
SSL
및 ACPI TLS
를 활성화하는 매개 변수를 포함하여 다양한 매개 변수를 지정할 수 있습니다. 자세한 내용은 ldap _table(5) 매뉴얼
페이지를 참조하십시오.
LDAP
에 대한 자세한 내용은 System-Level Authentication Guide 의 OpenLDAP 를 참조하십시오.
15.3.2. 이메일 보내기
다른 MTA와 마찬가지로 sendmail의 핵심 목적은 일반적으로 SMTP
프로토콜을 사용하여 호스트 간에 이메일을 안전하게 전송하는 것입니다. Sendmail은 더 이상 사용되지 않으며 관리자는 가능한 경우 redfish를 사용하는 것이 좋습니다. 자세한 내용은 15.3.1절. “RHEA”를 참조하십시오.
15.3.2.1. 목적 및 제한 사항
보낸 편지가 무엇인지, 그리고 그것이 무엇을 할 수 있는지에 대해 인식하는 것이 중요합니다. 여러 역할을 수행하는 모놀리식 애플리케이션의 며칠 동안 Sendmail은 조직 내에서 이메일 서버를 실행하는 데 필요한 유일한 애플리케이션처럼 보일 수 있습니다. Sendmail은 각 사용자의 디렉토리로 이메일을 스풀(spool)하고 사용자에게 아웃바운드 이메일을 전달할 수 있기 때문에 기술적으로는 사실입니다. 그러나 대부분의 사용자는 실제로 간단한 이메일 전송보다 훨씬 더 많은 것을 필요로합니다. 일반적으로 사용자는 해당 메시지를 로컬 시스템에 다운로드하는 MUA를 사용하는 MUA
를 사용하여
이메일과 상호 작용하려고 합니다. 또는 웹 인터페이스를 사용하여 메일함에 대한 액세스 권한을 얻을 수 있습니다.Or, they may prefer a Web interface to gain access to their mailbox. 이러한 다른 응용 프로그램은 Sendmail과 함께 작동 할 수 있지만 실제로는 다른 이유로 존재하며 서로 별도로 작동 할 수 있습니다.
이 섹션의 범위를 벗어나서 Sendmail이 할 수 있거나 구성되어야 합니다. 문자 그대로 수백 가지의 다양한 옵션 및 규칙 세트로, 전체 볼륨은 할 수있는 모든 것을 설명하고 잘못된 것을 수정하는 방법을 돕기 위해 최선을 다하고 있습니다. Sendmail 리소스 목록은 15.7절. “추가 리소스” 을 참조하십시오.
이 섹션에서는 기본적으로 Sendmail과 함께 설치된 파일을 검토하고 원치 않는 이메일(spam)을 중지하는 방법과 LDAP(Lightweight Directory Access Protocol )를 사용하여 Sendmail을 확장하는 방법을 포함하여 기본 구성 변경 사항을 검토합니다.
15.3.2.2. 기본 Sendmail 설치
Sendmail을 사용하려면 먼저 루트로
다음을 실행하여 sendmail 패키지가 시스템에 설치되어 있는지 확인하십시오.
~]# yum install sendmail
Sendmail을 구성하려면 root
로 를 실행하여 sendmail-cf 패키지가 시스템에 설치되어 있는지 확인합니다.
~]# yum install sendmail-cf
YUM을 사용하여 패키지 설치에 대한 자세한 내용은 9.2.4절. “패키지 설치” 을 참조하십시오.
Sendmail을 사용하기 전에 기본 MTA를 Postfix에서 전환해야 합니다. 기본 MTA를 전환하는 방법에 대한 자세한 내용은 15.3절. “메일 전송 에이전트” 을 참조하십시오.
Sendmail 실행 파일은 sendmail
입니다.
sendmail 구성 파일은 /etc/mail/sendmail.cf
.에 있습니다. sendmail.cf
파일을 직접 편집하지 마십시오. Sendmail을 설정하려면 /etc/mail/sendmail.mc
파일을 편집하고 원본 /etc/mail/sendmail.cf
파일을 백업하고 sendmail
서비스를 다시 시작합니다. 다시 시작의 일부로 sendmail.cf 파일과 데이터베이스의 모든 바이너리 표현은 다시 빌드됩니다.
# systemctl restart sendmail
Sendmail 구성에 대한 자세한 내용은 15.3.2.3절. “일반적인 Sendmail 구성 변경 사항” 에서 확인할 수 있습니다.
다양한 Sendmail 구성 파일은 /etc/mail/
디렉토리에 다음과 같이 설치됩니다.
-
액세스
- 아웃바운드 이메일에 대해 Sendmail을 사용할 수 있는 시스템을 지정합니다. -
domaintable
- 도메인 이름 매핑을 지정합니다. -
local-host-names
- 호스트의 별칭을 지정합니다. -
mailertable
- 특정 도메인의 라우팅을 재정의하는 명령을 지정합니다. -
virtusertable
- 하나의 시스템에서 여러 가상 도메인을 호스팅할 수 있도록 도메인별 별칭 형식을 지정합니다.
/etc/mail/
디렉토리의 여러 설정 파일(예: 액세스
,도메인 테이블
,mailertable
및 virtusertable
)은 데이터베이스 파일에 해당 정보를 저장하므로 Sendmail은 구성 변경을 사용할 수 있습니다.
이러한 구성에 대한 변경 사항을 데이터베이스 파일에 포함하려면 다음 명령을 실행합니다.
# systemctl restart sendmail
15.3.2.3. 일반적인 Sendmail 구성 변경 사항
Sendmail 구성 파일을 변경할 때는 기존 파일을 편집하지 않고 완전히 새로운 /etc/mail/sendmail.cf
파일을 생성하는 것이 가장 좋습니다.
sendmail.cf
파일을 변경하거나 변경하기 전에 백업 사본을 생성합니다.
Sendmail에 원하는 기능을 추가하려면 /etc/mail/sendmail.mc
파일을 루트로
편집합니다. 완료되면 sendmail
서비스를 다시 시작하고 m4 패키지가 설치되면 m4
매크로 프로세서에서 새 sendmail.cf
구성 파일을 자동으로 생성합니다.
~]# systemctl restart sendmail
기본 sendmail.cf
파일은 Sendmail이 로컬 컴퓨터 이외의 모든 호스트의 네트워크 연결을 수락하도록 허용하지 않습니다. Sendmail을 다른 클라이언트에 대한 서버로 구성하려면 /etc/mail/sendmail.mc
파일을 편집하고 DAE 6443_ OPTIONS
지시문의 Addr=
옵션에 지정된 주소를 active 네트워크 장치의 IP 주소로 변경하거나 DAE 6443_ OPTIONS
지시문에서 모든 DAE 6443_OPTIONS 지시어를 함께 배치하여 주석으로 지정합니다.
완료되면 서비스를 다시 시작하여
/etc/mail/sendmail.cf
를 다시 생성합니다.
~]# systemctl restart sendmail
Red Hat Enterprise Linux의 기본 구성은 대부분의 SMTP
- 전용 사이트에서 작동합니다.
/
README 파일을 참조하십시오.
etc/share/sendmail-cf/README
파일의 향후 구성에 영향을 미칠 수 있으므로 /usr/share/sendmail-cf/
디렉터리에 있는 디렉터리의 파일을 편집하기 전에 /usr/share/sendmail-cf/
15.3.2.4. 마스커레이딩
일반적인 Sendmail 구성 중 하나는 단일 시스템이 네트워크상의 모든 컴퓨터에 대한 메일 게이트웨이 역할을 하도록 하는 것입니다. 예를 들어, 한 회사에서는 모든 이메일을 처리하고 나가는 모든 메일에 일관된 반환 주소를 할당하는 mail.example.com
이라는 시스템이 필요할 수 있습니다.
이 경우 Sendmail 서버는 회사 네트워크의 머신 이름을 마스커레이드하여 반환 주소가
대신 되게 해야 합니다.
user@host.example.com
이렇게 하려면 /etc/mail/sendmail.mc
에 다음 행을 추가하십시오.
FEATURE(always_add_domain)dnl FEATURE(masquerade_entire_domain)dnl FEATURE(masquerade_envelope)dnl FEATURE(allmasquerade)dnl MASQUERADE_DOMAIN(`example.com.')dnl MASQUERADE_AS(`example.com')dnl
sendmail.mc의 변경된 구성에서 새 sendmail.cf
파일을 생성한 후 다음 명령으로 sendmail 서비스를 다시 시작합니다.
# systemctl restart sendmail
메일 서버, DNS
및 DHCP
서버 및 프로비저닝 애플리케이션의 관리자는 조직에 사용된 호스트 이름 형식에 동의해야 합니다. 권장 이름 지정 방법에 대한 자세한 내용은 Red Hat Enterprise Linux 7 네트워킹 가이드 를 참조하십시오.
15.3.2.5. 스팸 중지
이메일 스팸은 통신을 요청하지 않는 사용자가 수신한 불필요한 이메일과 원치 않는 이메일로 정의될 수 있습니다. 이는 혼란스럽고 비용이 많이 들고 인터넷 통신 표준을 광범위하게 악용하는 것입니다.
sendmail을 사용하면 정크 이메일을 보내는 데 사용되는 새로운 스팸 기술을 쉽게 차단할 수 있습니다. 또한 기본적으로 더 일반적인 스팸 방법을 많이 차단합니다. sendmail에서 사용할 수 있는 주요 스팸 기능은 헤더 검사 이며,거부 거부 (기본값: 버전 8.9), 액세스 데이터베이스 및 발신자 정보 점검 입니다.
예를 들어 Sendmail 버전 8.9부터 릴레이라고도 하는 SMTP
메시지의 전달은 기본적으로 비활성화되어 있습니다. 이러한 변경이 발생하기 전에 메일 호스트(x.edu
)를 전달하여 한 당사자(y.com
)의 메시지를 수락하고 다른 파티(z.net
)로 보냅니다. 그러나 이제 모든 도메인이 서버를 통해 이메일을 릴레이할 수 있도록 Sendmail을 구성해야 합니다. 릴레이 도메인을 구성하려면 /etc/mail/relay-domains
파일을 편집하고 Sendmail을 다시 시작합니다.
~]# systemctl restart sendmail
그러나 인터넷의 서버도 스팸 메시지를 보낼 수 있습니다. 이러한 경우 /etc/mail/access
파일을 통해 사용할 수 있는 Sendmail의 액세스 제어 기능을 사용하여 원하지 않는 호스트에서 연결을 방지할 수 있습니다. 다음 예제에서는 이 파일을 차단과 특히 Sendmail 서버에 대한 액세스를 허용하는 방법을 보여줍니다.
badspammer.com ERROR:550 "Go away and do not spam us anymore" tux.badspammer.com OK 10.0 RELAY
이 예에서는 badspammer.com
에서 전송된 모든 이메일이 550 RFC-821 호환 오류 코드로 차단되어 메시지가 다시 전송되었음을 보여줍니다. tux.badspammer.com
하위 도메인에서 전송된 이메일은 허용됩니다. 마지막 줄은 10.0.. . 네트워크에서 전송된 모든 이메일이 메일 서버를 통해 중계될 수 있음을 보여줍니다.
/etc/mail/access.db
파일은 데이터베이스이므로 다음 명령을 사용하여 변경 사항을 업데이트합니다.
# systemctl restart sendmail
위의 예는 Sendmail이 액세스를 허용하거나 차단하는 측면에서 수행할 수 있는 작업의 작은 부분만을 나타냅니다. 자세한 내용과 예제는 /usr/share/sendmail-cf/README
파일을 참조하십시오.
Sendmail은 이메일을 제공할 때 Procmail MDA를 호출하기 때문에 SpamAssassin과 같은 스팸 필터링 프로그램을 사용하여 사용자의 스팸을 식별 및 파일할 수도 있습니다. SpamAssassin 사용에 대한 자세한 내용은 15.4.2.6절. “스팸 필터” 를 참조하십시오.
15.3.2.6. LDAP로 Sendmail 사용
LDAP
를 사용하는 것은 훨씬 더 큰 그룹에서 특정 사용자에 대한 특정 정보를 찾는 매우 빠르고 강력한 방법입니다. 예를 들어 LDAP
서버를 사용하여 사용자의 마지막 이름에 의해 공통 회사 디렉토리에서 특정 이메일 주소를 조회할 수 있습니다. 이러한 종류의 구현에서 LDAP
는 Sendmail과 크게 분리되어, LDAP
에서 계층적 사용자 정보를 저장하고, 미리 전송된 이메일 메시지의 LDAP
쿼리 결과를 통해서만 Sendmail을 보냅니다.
그러나 Sendmail은 LDAP
와 훨씬 더 큰 통합을 지원합니다. 여기서 LDAP
를 사용하여 /etc/aliases
및 /etc/mail/virtusertables
, 함께 작동하여 중간에서 엔터프라이즈급 조직을 지원하기 위해 함께 작동하는 별도의 유지 관리 파일을 교체합니다. 즉, LDAP
는 Sendmail 및 별도의 구성 파일에서 다양한 애플리케이션에서 활용할 수 있는 강력한 LDAP
클러스터로 메일 라우팅 수준을 추상화합니다.
현재 버전의 Sendmail에는 LDAP
에 대한 지원이 포함되어 있습니다. LDAP
를 사용하여 Sendmail 서버를 확장하려면 먼저 OpenLDAP, 실행 및 올바르게 구성된 LDAP
서버를 가져옵니다. 그런 다음 /etc/mail/sendmail.mc
를 편집하여 다음을 포함합니다.
LDAPROUTE_DOMAIN('yourdomain.com')dnl
FEATURE('ldap_routing')dnl
이는 LDAP
를 사용한 Sendmail의 매우 기본적인 구성일 뿐입니다. LDAP 구현, 특히 공통
서버를 사용하도록 여러 Sendmail 시스템을 구성하는 경우 이 구성과 크게 다를 수 있습니다.
LDAP
자세한 LDAP
라우팅 구성 지침 및 예제는 /usr/share/sendmail-cf/README
를 참조하십시오.
다음으로 m4
매크로 프로세서를 실행하고 Sendmail을 다시 시작하여 /etc/mail/sendmail.cf
파일을 다시 생성합니다. 자세한 내용은 15.3.2.3절. “일반적인 Sendmail 구성 변경 사항” 을 참조하십시오.
LDAP
에 대한 자세한 내용은 System-Level Authentication Guide 의 OpenLDAP 를 참조하십시오.
15.3.3. fetchmail
fetchmail은 원격 서버에서 이메일을 검색하고 로컬 MTA로 전달하는 MTA입니다. 많은 사용자는 MUA에서 이메일을 읽고 구성하는 과정에서 원격 서버에 있는 메시지를 다운로드하는 프로세스를 분리할 수 있다는 것을 인지하고 있습니다. 전화 접속 사용자를 염두에 두고 설계, Fetchmail은 모든 이메일 메시지를 신속하게 메일 스풀 파일에 연결합니다. ( POP3
및 6443을 포함한 모든 프로토콜을 포함
) 필요한 경우 이메일 메시지를 SMTP
서버에 전달할 수도 있습니다.
Fetchmail 을 사용하려면 먼저 root
로 실행하여 fetchmail 패키지가 시스템에 설치되어 있는지 확인하십시오.
~]# yum install fetchmail
YUM을 사용하여 패키지 설치에 대한 자세한 내용은 9.2.4절. “패키지 설치” 을 참조하십시오.
fetchmail은 사용자의 홈 디렉터리에서 .fetchmailrc
파일을 사용하여 각 사용자에 대해 구성됩니다. 아직 존재하지 않는 경우 홈 디렉터리에 .fetchmailrc
파일을 만듭니다.
.fetchmailrc
파일의 기본 설정을 사용하여 Fetchmail은 원격 서버에서 이메일을 확인하고 다운로드합니다. 그런 다음 로컬 MTA를 사용하여 올바른 사용자의 스풀 파일에 이메일을 배치하여 로컬 시스템의 포트 25로 전달합니다. Procmail을 사용할 수 있는 경우 이메일을 필터링하여 MUA에서 읽을 수 있도록 메일에 배치합니다.
15.3.3.1. 이메일 설정 옵션 가져오기
Fetchmail을 실행할 때 원격 서버에서 이메일을 확인하는 데 필요한 모든 옵션을 전달할 수 있지만 .fetchmailrc
파일을 사용하는 것이 훨씬 쉬워집니다. fetchmail
명령이 실행될 때마다 사용할 옵션에 대해 원하는 구성 옵션을 .fetchmailrc
파일에 배치합니다. 명령줄에서 해당 옵션을 지정하여 Fetchmail을 실행할 때 재정의할 수 있습니다.
사용자의 .fetchmailrc
파일에는 다음 세 가지 구성 옵션 클래스가 있습니다.
- 글로벌 옵션 - 프로그램의 작동을 제어하거나 이메일을 확인하는 모든 연결에 대한 설정을 제공하는 Fetchmail 지침을 제공합니다.
- 서버 옵션 - 폴링 중인 서버에 대한 필수 정보(예: 호스트 이름, 특정 이메일 서버에 대한 기본 설정(예: 시간 초과) 전에 대기할 포트 또는 확인하는 시간(초)에 대한 기본 정보를 지정합니다. 이러한 옵션은 해당 서버를 사용하는 모든 사용자에게 영향을 미칩니다.
- 사용자 옵션 - 사용자 이름 및 암호와 같은 정보가 포함되어 있으며, 지정된 이메일 서버를 사용하여 이메일을 인증하고 확인합니다.
전역 옵션은 .fetchmailrc
파일의 맨 위에 나타나는 다음 하나 이상의 서버 옵션이 표시되며, 각 옵션은 Fetchmail에서 확인해야 하는 다른 이메일 서버를 지정합니다. 사용자 옵션은 해당 이메일 서버를 확인하는 각 사용자 계정에 대한 서버 옵션을 따릅니다. 서버 옵션과 마찬가지로, 특정 서버에 사용할 여러 사용자 옵션을 지정하고 동일한 서버에서 여러 이메일 계정을 확인할 수 있습니다.
서버 옵션은 서버 정보 앞에 있는 특수 옵션 동사, 폴링
또는 건너뛰기
를 사용하여 .fetchmailrc
파일의 서비스로 호출됩니다. 폴링
작업은 Fetchmail에 이 서버 옵션을 실행할 때 이 서버 옵션을 사용하도록 지시합니다. 이 옵션은 지정된 사용자 옵션을 사용하여 이메일을 확인합니다. 그러나 건너뛰기
작업 이후 서버 옵션은 Fetchmail이 호출될 때 이 서버의 호스트 이름을 지정하지 않는 한 확인되지 않습니다. 건너뛰기 옵션은 특별히 호출될 때 건너뛰
는 서버만 확인하므로 .fetchmailrc
파일에서 구성을 테스트할 때 유용하며 현재 사용 중인 구성에 영향을 미치지 않기 때문입니다.
다음은 .fetchmailrc
파일의 예입니다.
set postmaster "user1" set bouncemail poll pop.domain.com proto pop3 user 'user1' there with password 'secret' is user1 here poll mail.domain2.com user 'user5' there with password 'secret2' is user1 here user 'user7' there with password 'secret3' is user1 here
이 예에서 글로벌 옵션은 사용자가 마지막 수단으로 이메일을 전송하도록 지정합니다 (Postmaster 옵션) 및 모든 이메일 오류는 발신자 대신postmaster
로 전송됩니다 (보통mail
옵션). set
작업에서는 이 줄에 글로벌 옵션이 포함되어 있음을 Fetchmail에 지시합니다. 그런 다음 두 개의 이메일 서버가 지정되어 있고 하나는 POP3
을 사용하여 확인하고 다른 하나는 작동하는 프로토콜을 찾기 위해 다양한 프로토콜을 시도합니다. 두 명의 사용자가 두 번째 서버 옵션을 사용하여 확인되지만 모든 사용자에 대해 발견된 모든 이메일은 user1
의 메일 스풀으로 전송됩니다. 이렇게 하면 단일 MUA 박스에 표시되는 동안 여러 서버에서 여러 개의 RuntimeClass를 확인할 수 있습니다. 각 사용자의 특정 정보는 사용자
작업으로 시작됩니다.
사용자는 .fetchmailrc
파일에 비밀번호를 둘 필요가 없습니다. 암호' 섹션'을 사용하여
을 생략하면 Fetchmail이 시작 시 암호를 요청합니다.
fetchmail에는 여러 글로벌, 서버 및 로컬 옵션이 있습니다. 이러한 옵션 중 대부분은 거의 사용되지 않거나 매우 구체적인 상황에만 적용됩니다. fetchmail
도움말 페이지는 각 옵션을 자세히 설명하지만 가장 일반적인 옵션은 다음 세 섹션에 나열되어 있습니다.
15.3.3.2. 글로벌 옵션
각 전역 옵션은 설정된
작업 후에 한 줄에 배치해야 합니다.
-
daemon 초
- 데몬 모드를 지정합니다. 여기서 Fetchmail은 백그라운드에서 유지됩니다. 서버를 폴링하기 전에 초를 Fetchmail이 대기하는 시간(초)으로 바꿉니다. -
Postmaster
- 배달 문제 발생시 이메일을 보낼 로컬 사용자를 지정합니다. -
Syslog
- 오류 및 상태 메시지에 대한 로그 파일을 지정합니다. 기본적으로/var/log/maillog
입니다.
15.3.3.3. 서버 옵션
폴링
또는 건너뛰기
후에 서버 옵션을 .fetchmailrc
의 자신의 줄에 배치해야 합니다.
-
auth auth-type
- auth-type 을 사용할 인증 유형으로 바꿉니다. 기본적으로암호
인증이 사용되지만 일부 프로토콜은kerberos_v5
,kerberos_v4
,ssh
를 포함한 다른 유형의 인증을 지원합니다.모든
인증 유형을 사용하는 경우, Fetchmail은 먼저 암호가 필요하지 않은 메서드를 시도한 다음 암호를 마스킹하는 방법 및 마지막으로 서버에 인증하기 위해 암호화되지 않은 암호를 전송하려고 시도합니다. -
간격 번호
- 구성된 모든 서버에서 이메일을 확인하는횟수
마다 지정된 서버를 호출합니다. 이 옵션은 일반적으로 사용자가 메시지를 거의 수신하는 이메일 서버에 사용됩니다. -
포트 포트 번호
- 포트 번호를 포트 번호로 바꿉니다. 이 값은 지정된 프로토콜의 기본 포트 번호를 재정의합니다. -
proto protocol
- 서버에서 메시지를 확인할 때 사용하기 위해pop3
또는1.8.0과 같은 프로토콜로 바꿉니다. -
시간 제한 시간 -
시간 초과
- 초를 서버 비활성 시간(초)으로 교체한 후 Fetchmail이 연결 시도 시 포기합니다. 이 값을 설정하지 않으면 기본값300
초가 사용됩니다.
15.3.3.4. 사용자 옵션
사용자 옵션은 서버 옵션 아래에 또는 server 옵션과 동일한 행에 배치될 수 있습니다. 두 경우 모두 정의된 옵션은 사용자
옵션(아래 정의)을 따라야 합니다.
-
fetchAll
- 이미 확인한 메시지를 포함하여 대기열의 모든 메시지를 다운로드하도록 Fetchmail 주문합니다. 기본적으로 Fetchmail은 새 메시지만 당깁니다. -
fetchlimit number
- 중지하기 전에 검색할 메시지 수로 번호를 바꿉니다. -
flush
- 새 메시지를 검색하기 전에 대기열에서 이전에 확인한 모든 메시지를 삭제합니다. -
max-number-bytes
제한 - Fetchmail로 메시지를 검색할 때 허용되는 최대 크기(바이트)로 max-number-bytes를 바꿉니다. 이 옵션은 느린 네트워크 링크에 유용합니다. 큰 메시지가 다운로드하는 데 시간이 너무 오래 걸리는 경우 유용합니다. -
암호 '
- password를 사용자의 암호로 바꿉니다. -
사전 연결 "
- 사용자 메시지를 검색하기 전에 명령을 실행할 명령으로 교체하십시오. -
postconnect "
- 사용자 메시지를 검색한 후 실행할 명령으로 교체하십시오. -
SSL
- SSL 암호화를 활성화합니다. 작성 시 기본 작업은SSL2
,SSL3
,SSL23
,TLS1
,TLS1.1
및TLS1.2
에서 사용 가능한 최상의 기능을 사용하는 것입니다.SSL2
는 더 이상 사용되지 않으며 POODLE로 인해 발생합니다. SSLv3 취약점 (CVE-2014-3566)SSLv3
을 사용해서는 안 됩니다. 그러나 TLS1 또는 최신 버전을 강제로 사용할 수 있는 방법은 없으므로 연결된 메일 서버가SSLv2
및SSLv3
를 사용하지 않도록 구성되어 있는지 확인합니다. 서버를 설정할 수 없는SSLv2
및SSLv3
을 사용하도록 설정할 수 없는stunnel
을 사용합니다. -
sslproto
- 허용된 SSL 또는 TLS 프로토콜을 정의합니다. 가능한 값은SSL2
,SSL3
,SSL23
및TLS1
입니다.sslproto
가 생략되거나, 설정되지 않았거나, 잘못된 값으로 설정된 경우 기본값은SSL23
입니다. 기본 작업은SSLv2
,SSLv3
,TLSv1
,TLS1.1
및TLS1.2
에서 최상의 기능을 사용하는 것입니다. SSL 또는 TLS의 다른 값을 설정하면 다른 모든 프로토콜이 비활성화됩니다. POODLE으로 인한 경우: SSLv3 취약점 (CVE-2014-3566), 이 옵션을 생략하거나SSLv23
으로 설정하는 것이 좋습니다.SSLv2
및SSLv3
. 서버를 설정할 수 없는SSLv2
및SSLv3
을 사용하도록 설정할 수 없는stunnel
을 사용합니다. -
사용자 "username"
- username 을 Fetchmail에서 사용하는 사용자 이름으로 대체하여 메시지를 검색합니다. 이 옵션은 다른 모든 사용자 옵션보다 우선해야합니다.
15.3.3.5. 가져오기 이메일 명령 옵션
fetchmail
명령을 실행할 때 명령줄에서 사용되는 대부분의 Fetchmail 옵션은 .fetchmailrc
구성 옵션을 미러링합니다. 이러한 방식으로 Fetchmail은 구성 파일과 함께 또는 구성 파일 없이 사용될 수 있습니다. 이러한 옵션은 .fetchmailrc
파일에서 쉽게 남기기 때문에 대부분의 사용자가 명령줄에서 사용하지 않습니다.
특정 목적을 위해 다른 옵션을 사용하여 fetchmail
명령을 실행하는 것이 바람직한 경우가 있을 수 있습니다. 명령줄에 지정된 옵션에서 구성 파일 옵션을 재정의하므로 명령 옵션을 실행하여 오류가 발생하는 .fetchmailrc
설정을 일시적으로 덮어쓸 수 있습니다.
15.3.3.6. 정보 또는 디버깅 옵션
fetchmail
명령 이후에 사용되는 특정 옵션은 중요한 정보를 제공할 수 있습니다.
-
--configdump
-.fetchmailrc
및 Fetchmail 기본값의 정보를 기반으로 가능한 모든 옵션을 표시합니다. 이 옵션을 사용할 때 모든 사용자에 대한 이메일이 검색되지 않습니다. -
-s
- 자동 모드로 Fetchmail을 실행하여 오류 이외의 모든 메시지를fetchmail
명령 다음에 나타나지 않습니다. -
-V
- 자세한 정보 표시 모드로 Fetchmail을 실행하여 Fetchmail과 원격 이메일 서버 간의 모든 통신을 표시합니다. -
-V
- 자세한 버전 정보를 표시하고, 글로벌 옵션을 나열하고, 이메일 프로토콜 및 인증 방법을 포함하여 각 사용자와 함께 사용할 설정을 표시합니다. 이 옵션을 사용할 때 모든 사용자에 대한 이메일이 검색되지 않습니다.
15.3.3.7. 특수 옵션
이러한 옵션은 종종 .fetchmailrc
파일에 있는 기본값을 덮어쓰는 데 유용합니다.
-
-a
- Fetchmail은 신규 또는 이전에 본 적이 있는지 여부에 관계없이 원격 이메일 서버에서 모든 메시지를 다운로드합니다. 기본적으로 Fetchmail은 새 메시지만 다운로드합니다. -
-k
- Fetchmail은 원격 이메일 서버에 메시지를 다운로드한 후 남겨둡니다. 이 옵션은 메시지를 다운로드한 후 삭제하는 기본 동작을 재정의합니다. -
-L max-number-bytes
- Fetchmail은 특정 크기에 대한 메시지를 다운로드하지 않고 원격 이메일 서버에 남겨둡니다. -
--quit
- Fetchmail 데몬 프로세스를 쿼리합니다.
더 많은 명령과 .fetchmailrc
옵션은 fetchmail
매뉴얼 페이지에서 찾을 수 있습니다.
15.3.4. MT( mail Transport Agent) 구성
MTA (mail Transport Agent )는 이메일을 보내는 데 중요합니다. DomainMapping 또는 Mutt 와 같은 MUA( 메일 사용자 에이전트 )는 이메일을 읽고 작성하는 데 사용됩니다. 사용자가 MUA에서 이메일을 보내면 메시지가 MTA로 전송되어 대상에 도달할 때까지 일련의 MTA를 통해 메시지를 보냅니다.
사용자가 시스템에서 이메일을 보내지 않더라도 일부 자동화된 작업 또는 시스템 프로그램은 mail
명령을 사용하여 로그 메시지가 포함된 이메일을 로컬 시스템의 root
사용자에게 보낼 수 있습니다.
Red Hat Enterprise Linux 7은 다음 두 가지 MTA를 제공합니다. redfish 및 Sendmail. 둘 다 설치된 경우 Postfix는 기본 MTA입니다.
15.4. 메일 전송 에이전트
Red Hat Enterprise Linux에는 기본 MDA로 Procmail
이 포함되어 있습니다. 두 애플리케이션 모두 LDA로 간주되며 MTA의 스풀 파일에서 사용자의 메일로 이메일을 이동합니다. 그러나 Procmail은 강력한 필터링 시스템을 제공합니다.
이 섹션은 Procmail에 대해서만 자세히 설명되어 있습니다. mail
명령에 대한 자세한 내용은 man 페이지(man mail
)를 참조하십시오.
procmail은 localhost의 메일 스풀 파일에 배치된 이메일을 제공하고 필터링합니다. 시스템 리소스에 대한 강력하고 견고하며 널리 사용됩니다. procmail은 이메일 클라이언트 애플리케이션에서 읽을 수 있는 이메일을 전달하는 데 중요한 역할을 할 수 있습니다.
procmail은 여러 가지 방법으로 호출될 수 있습니다. MTA가 이메일을 스풀 파일에 배치할 때마다 Procmail이 시작됩니다. 그런 다음 procmail은 MUA에 대한 이메일을 필터링하고 파일을 종료합니다. 대안적으로, MUA는 메시지가 올바른 보고로 이동되도록 메시지를 수신할 때마다 Procmail을 실행하도록 구성될 수 있다. 기본적으로 /etc/procmailrc
또는 사용자 홈 디렉토리에 있는 ~/.procmailrc
파일(또는 rc 파일라고도 함)이 MTA가 새 메시지를 수신할 때마다 Procmail을 호출합니다.
기본적으로 /etc
디렉터리에 시스템 전체 rc
파일이 없으며 사용자의 홈 디렉터리에 .procmailrc
파일이 존재하지 않습니다. 따라서 Procmail을 사용하려면 각 사용자가 특정 환경 변수 및 규칙을 사용하여 .procmailrc
파일을 구성해야 합니다.
Procmail이 이메일 메시지에 따라 작동하는지 여부는 메시지가 rc
파일의 지정된 조건 또는 레시피 와 일치하는지 여부에 따라 달라집니다. 메시지가 레시피와 일치하면 이메일이 지정된 파일에 배치되거나 삭제되거나 처리되지 않습니다.
Procmail이 시작되면 이메일 메시지를 읽고 헤더 정보에서 본문을 구분합니다. 다음으로 Procmail은 /etc/procmailrc
s/ 디렉토리에서 시스템 전체의 기본 환경 변수 및 레시피를 위해 /etc/procmail
디렉터리에서 /etc/procmailrcs/ 파일을 찾습니다. 그런 다음 procmail은 사용자의 홈 디렉터리에서 rc
s/.procmailrc
파일을 검색합니다. 많은 사용자가 홈 디렉터리의 .procmailrc
파일 내에서 참조되는 Procmail에 대한 추가 rc
파일을 생성합니다.
15.4.1. procmail 구성
Procmail 구성 파일에는 중요한 환경 변수가 포함되어 있습니다. 이러한 변수는 정렬할 메시지와 레시피와 일치하지 않는 메시지와 함께 수행할 메시지와 같은 작업을 지정합니다.
이러한 환경 변수는 일반적으로 다음 형식으로 ~/.procmailrc
파일의 시작 부분에 표시됩니다.
env-variable="value"
이 예제에서 env- Variables는
변수의 이름이고 value
는 변수를 정의합니다.
대부분의 Procmail 사용자가 사용하지 않는 환경 변수가 많이 있으며 더 중요한 환경 변수 중 다수는 이미 기본값으로 정의되어 있습니다. 대부분의 경우 다음 변수가 사용됩니다.
DEFAULT
- 레시피와 일치하지 않는 메시지가 배치되는 기본 사서함을 설정합니다.기본
DEFAULT
값은$ORGMAIL
과 동일합니다.INCLUDERC
- 확인할 메시지에 대한 더 많은 레시피가 포함된 추가rc
파일을 지정합니다. 이렇게 하면 Procmail 레시피 목록을 스팸 차단 및 이메일 목록 차단과 같은 다른 역할을 수행하는 개별 파일로 분리한 다음 사용자의~/.procmailrc
파일에서 주석 문자를 사용하거나 사용할 수 있습니다.예를 들어 사용자의
~/.procmailrc
파일의 행은 다음과 같습니다.MAILDIR=$HOME/Msgs INCLUDERC=$MAILDIR/lists.rc INCLUDERC=$MAILDIR/spam.rc
이메일 목록의 Procmail 필터링을 해제하려면 스팸 제어를 그대로 두려면 해시 기호
(#
)를 사용하여 첫 번째INCLUDERC
라인을 주석 처리합니다. 현재 디렉터리를 기준으로 경로를 사용합니다.-
LOCKSLEEP
- 특정 잠금 파일을 사용하도록 Procmail의 시도 사이에 시간(초)을 설정합니다. 기본값은 8초입니다. -
LOCKTIMEOUT
- Procmail이 잠금 파일이 오래되었다고 가정하고 삭제할 수 있다고 가정하기 전에 잠금 파일이 마지막으로 수정된 후 경과해야 하는 시간(초)을 설정합니다. 기본값은 1024초입니다. -
LOGFILE
- Procmail 정보 또는 오류 메시지가 기록되는 파일입니다. -
MAILDIR
- Procmail에 대한 현재 작업 디렉터리를 설정합니다. 설정하는 경우 다른 모든 Procmail 경로는 이 디렉터리에 상대적입니다. 기본
또는 레시피 필요한 위치에 있을 수 없는 경우 메시지를 배치할 수 없는 경우 원래의 메일 메시지 또는 다른 위치를 지정합니다.G
maIL - Specifies the original mailbox, or another place to put the messages if they cannot be placed in the default or recipe-required location.기본적으로
/var/spool/mail/$LOGNAME
값이 사용됩니다.-
SUSPEND
- 스왑 공간과 같은 필요한 리소스를 사용할 수 없는 경우 해당 Procmail이 일시 중지되는 시간(초)을 설정합니다. -
SWITCHRC
- 사용자가 추가 Procmail 레시피가 포함된 외부 파일을 지정할 수 있습니다.INCLUDERC
옵션과 마찬가지로 레시피 검사는 참조 구성 파일에서 실제로 중지되고SWITCHRC
-specified 파일의 레시피만 사용됩니다. -
VERBOSE
- Procmail을 사용하여 자세한 정보를 기록합니다. 이 옵션은 디버깅에 유용합니다.
다른 중요한 환경 변수는 쉘(예: LOGNAME
, 로그인 이름, 홈 디렉터리의 위치, 기본 쉘)과 같은 쉘에서 가져옵니다.
모든 환경 변수와 해당 기본값에 대한 포괄적인 설명은 procmailrc
매뉴얼 페이지에서 확인할 수 있습니다.
15.4.2. procmail Recipes
새로운 사용자는 종종 Procmail을 사용하는 학습의 가장 어려운 부분을 레시피 작성을 찾습니다. 이 어려움이 종종 문자열 일치에 대한 자격을 지정하는 데 사용되는 정규 표현식 을 사용하여 메시지와 일치하는 레시피에 특성이 있습니다. 그러나 정규식을 구성하는 것은 쉽지 않으며 읽을 때 이해하기가 덜 어렵습니다. 또한 정규 표현식에 관계없이 Procmail 레시피를 작성하는 방법의 일관성을 통해 예제를 쉽게 배울 수 있습니다. Procmail 레시피 예제를 보려면 15.4.2.5절. “레시피의 예” 를 참조하십시오.
procmail 레시피는 다음과 같은 형식을 취합니다.
:0 flags : lockfile-name * condition_1_special-condition-character condition_1_regular_expression * condition_2_special-condition-character condition-2_regular_expression * condition_N_special-condition-character condition-N_regular_expression special-action-character action-to-perform
Procmail 레시피의 처음 두 문자는 콜론과 0입니다. 다양한 플래그를 0 뒤에 배치하여 Procmail이 레시피를 처리하는 방법을 제어할 수 있습니다. flags
섹션 뒤의 콜론은 이 메시지에 대해 lockfile이 생성되었음을 지정합니다. lockfile이 생성되는 경우 lockfile-name
을 대체하여 이름을 지정할 수 있습니다.
레시피에는 메시지와 일치하는 여러 조건이 포함될 수 있습니다. 조건이 없는 경우 모든 메시지는 레시피와 일치합니다. 정규 표현식은 메시지 일치를 용이하게 하기 위해 일부 조건에 배치됩니다. 여러 조건을 사용하는 경우 작업을 수행하기 위해 모두 일치해야 합니다. 레시피의 첫 번째 줄에 설정된 플래그를 기반으로 조건을 확인합니다. 별표 문자(*
) 뒤에 배치된 선택적 특수 문자는 조건을 추가로 제어할 수 있습니다.
action-to-perform
인수는 메시지가 조건 중 하나와 일치할 때 수행되는 작업을 지정합니다. 레시피마다 하나의 동작만 있을 수 있습니다. 대부분의 경우 메일 메일의 이름은 여기에 해당 파일로 일치하는 메시지를 직접 지정하여 이메일을 효과적으로 정렬하는 데 사용됩니다. 작업을 지정하기 전에 특수 작업 문자를 사용할 수도 있습니다. 자세한 내용은 15.4.2.4절. “특별 조건 및 작업”를 참조하십시오.
15.4.2.1. vs 제공. 제공되지 않음 Recipes
레시피가 특정 메시지와 일치하는 경우 사용되는 작업은 전달 또는 탐색 이외의 레시피로 간주되는지 여부를 결정합니다. 전달 레시피에는 메시지를 파일에 쓰거나, 메시지를 다른 프로그램에 전송하거나, 메시지를 다른 이메일 주소로 전달하는 작업이 포함됩니다. 위임되지 않은 레시피는 중첩 블록과 같은 다른 모든 작업을 다룹니다. 중첩 블록은 레시피의 조건과 일치하는 메시지에 수행되는 중괄호 {
}
에 포함된 일련의 작업입니다. 블록 중첩은 서로 중첩될 수 있으므로 메시지에 대한 작업을 식별하고 수행하기 위한 더 큰 제어 기능을 제공합니다.
메시지가 전달 레시피와 일치하면 Procmail은 지정된 작업을 수행하고 메시지를 다른 레시피와 비교하는 것을 중지합니다. 위임되지 않은 레시피와 일치하는 메시지는 다른 레시피와 계속 비교됩니다.
15.4.2.2. 플래그
플래그는 레시피의 조건을 메시지와 비교하는 방법을 결정하는 데 필요합니다. egrep 유틸리티는 조건과 일치하도록 내부적으로 사용됩니다. 다음 플래그가 일반적으로 사용됩니다.
-
A
- 이 레시피는A
또는 플래그 없이 이전 레시피가 이 메시지와도 일치하는 경우에만 사용되도록 지정합니다. -
A - 이 레시피는
A
또는 플래그의 이전 레시피가 이 메시지와 일치하고 성공적으로 완료된 경우에만 사용되도록 지정합니다. -
B
- 메시지 본문을 구문 분석하고 일치하는 조건을 찾습니다. -
b
- 파일에 메시지 작성 또는 전달과 같은 결과 동작에서 본문을 사용합니다. 이는 기본 동작입니다. -
C
- 이메일의 이산화탄소 사본을 생성합니다. 이 기능은 필요한 작업을 메시지에서 수행할 수 있고 메시지 사본이rc
파일에서 계속 처리될 수 있으므로 레시피를 전달하는 데 유용합니다. -
D
- Egrep비교
대/소문자를 구분합니다. 기본적으로 비교 프로세스는 대/소문자를 구분하지 않습니다. -
e -
A
플래그와 유사하지만 레시피의 조건은E
다른
동작과 비교됩니다. -
E - 즉시 이전 레시피에 지정된 작업이 실패한 경우에만 메시지와 비교됩니다.
-
f
- 파이프를 필터로 사용합니다. -
H
- 메시지의 헤더를 구문 분석하고 일치하는 조건을 찾습니다. 이는 기본 동작입니다. -
h
- 결과 작업에서 헤더를 사용합니다. 이는 기본 동작입니다. -
W
- Tells Procmail 지정된 필터 또는 프로그램이 완료될 때까지 기다렸다가 필터링 된 메시지를 고려하기 전에 성공했는지 여부를 보고합니다. -
W
- "Program failure" 메시지가 억제된다는 점을 제외하고는w
와 동일합니다.
추가 플래그의 자세한 목록은 procmailrc
매뉴얼 페이지를 참조하십시오.
15.4.2.3. 로컬 잠금 파일 지정
Lockfiles는 하나 이상의 프로세스가 동시에 메시지를 변경하지 않도록 하기 위해 Procmail에 매우 유용합니다. 레시피의 첫 번째 줄에 플래그 뒤에 콜론(:
)을 배치하여 로컬 잠금 파일을 지정합니다. 그러면 대상 파일 이름과 LOCKEXT
글로벌 환경 변수에 설정된 모든 항목에 따라 로컬 잠금 파일이 생성됩니다.
또는 콜론 뒤에 이 레시피와 함께 사용할 로컬 잠금 파일의 이름을 지정합니다.
15.4.2.4. 특별 조건 및 작업
Procmail 레시피 조건 및 조치 이전에 사용된 특수 문자는 해석 방식을 변경합니다.
다음 문자는 레시피의 조건 줄 시작 부분에 별표 문자(*
) 뒤에 사용할 수 있습니다.
-
!
- 조건 줄에서 이 문자는 조건을 반전하여 조건이 메시지와 일치하지 않는 경우에만 일치됩니다. -
지정된 수
의
바이트 수를 확인합니다.Checks whether the message is under a specified number of bytes. -
메시지가 지정된 바이트 수를 초과하는
지
확인합니다.Checks if the message is over a specified number of bytes.
특수 작업을 수행하는 데 사용되는 문자는 다음과 같습니다.
-
!
- 작업 라인에서 이 문자는 Procmail에 메시지를 지정된 이메일 주소로 전달하도록 지시합니다. -
$
-rc
파일의 앞부분에 설정된 변수를 나타냅니다. 이는 종종 다양한 레시피에서 참조할 수 있는 공통 메일박스를 설정하는 데 사용됩니다. -
|
- 메시지를 처리하기 위해 지정된 프로그램을 시작합니다. -
{
및}
- 일치하는 메시지에 적용할 추가 레시피를 포함하는 데 사용되는 중첩 블록을 구성합니다.
작업 행 시작 시 특수 문자가 사용되지 않는 경우 Procmail은 작업 줄에서 메시지를 쓸 수 있는 메일박스를 지정한다고 가정합니다.
15.4.2.5. 레시피의 예
procmail은 매우 유연한 프로그램이지만, 이러한 유연성으로 인해 처음부터 Procmail 레시피를 합성하는 것은 새로운 사용자에게 어려울 수 있습니다.
Procmail 레시피 조건을 구축하는 기술을 개발하는 가장 좋은 방법은 다른 사람이 빌드한 많은 예제를 보는 것과 함께 정규 표현식에 대한 강력한 이해에서 비롯됩니다. 정규 표현식에 대한 자세한 설명은 이 섹션의 범위를 벗어납니다. Procmail 레시피 및 유용한 샘플 Procmail 레시피의 구조는 인터넷의 다양한 위치에서 찾을 수 있습니다. 정규 표현식의 적절한 사용 및 조정은 이러한 레시피 예제를 보면 파생될 수 있습니다. 또한 기본 정규 표현식 규칙에 대한 소개 정보는 grep(1)
도움말 페이지에서 확인할 수 있습니다.
다음 간단한 예제에서는 Procmail 레시피의 기본 구조를 보여주고 더 복잡한 구조를 위한 기반을 제공할 수 있습니다.
기본 레시피는 다음 예와 같이 조건을 포함하지 않을 수도 있습니다.
:0: new-mail.spool
첫 번째 줄은 로컬 잠금 파일을 만들도록 지정하지만 이름을 지정하지 않으므로 Procmail은 대상 파일 이름을 사용하고 LOCKEXT
환경 변수에 지정된 값을 추가합니다. 조건이 지정되지 않으므로 모든 메시지가 이 레시피와 일치하며 new-mail.spool
이라는 단일 스풀 파일에 MAILDIR
환경 변수에서 지정한 디렉터리에 배치됩니다. 그러면 MUA가 이 파일의 메시지를 볼 수 있습니다.
이와 같은 기본 레시피를 모든 rc
파일의 끝에 배치하여 메시지를 기본 위치로 보낼 수 있습니다.
다음 예제는 특정 이메일 주소의 메시지를 일치시켜 버립니다.
:0 * ^From: spammer@domain.com /dev/null
이 예에서는 spammer@domain.com
에서 보낸 모든 메시지는 /dev/null
장치로 보내어 삭제합니다.
영구 삭제를 위해 /dev/null
에 메시지를 보내기 전에 규칙이 의도한 대로 작동하는지 확인하십시오. 레시피에서 의도하지 않은 메시지를 실수로 포착하고 해당 메시지가 사라진 경우 규칙 문제를 해결하기가 어려워집니다.
더 나은 해결책은 레시피의 작업을 특정 메일로 가리키는 것입니다.이 작업은 때때로 false positive를 찾는 것입니다. 메시지가 실수로 일치하지 않는 경우, 사서함을 삭제하고 메시지를 /dev/null
로 보내도록 작업을 보냅니다.
다음 레시피는 특정 메일링 리스트에서 전송된 이메일을 가져와 지정된 폴더에 배치합니다.
:0: * ^(From|Cc|To).*tux-lug tuxlug
tux-lug@domain.com
메일링 리스트에서 전송된 모든 메시지는 MUA에 대해 tuxlug
mailbox에 자동으로 배치됩니다. 이 예제의 조건은 From
,Cc
또는 To
행에 메일링 목록의 이메일 주소가 있는 경우 메시지와 일치합니다.
자세한 내용과 강력한 레시피는 15.7절. “추가 리소스” 에서 제공되는 많은 Procmail 온라인 리소스를 참조하십시오.
15.4.2.6. 스팸 필터
새 이메일을 수신하면 Sendmail, Postfix 및 Fetchmail이 호출되므로 Procmail은 스팸을 경감하기 위한 강력한 도구로 사용할 수 있습니다.
이는 Procmail이 SpamAssassin과 함께 사용되는 경우 특히 그러합니다. 함께 사용하면 이 두 애플리케이션은 스팸 이메일을 신속하게 식별하고 정렬하거나 삭제할 수 있습니다.
SpamAssassin은 헤더 분석, 텍스트 분석, 블랙리스트, 스팸 추적 데이터베이스, 자체 learn Bayesian 스팸 분석을 사용하여 빠르고 정확하게 스팸을 식별하고 태그를 지정합니다.
SpamAssassin 을 사용하려면 먼저 root
로 를 실행하여 시스템에 spam assin 패키지가 설치되어 있는지 확인하십시오.
~]# yum install spamassassin
YUM을 사용하여 패키지 설치에 대한 자세한 내용은 9.2.4절. “패키지 설치” 을 참조하십시오.
로컬 사용자가 SpamAssassin을 사용하는 가장 쉬운 방법은 ~/.procmailrc
파일 맨 위에 다음 행을 배치하는 것입니다.
INCLUDERC=/etc/mail/spamassassin/spamassassin-default.rc
/etc/mail/spamassin/spamassin-default.rc
에는 들어오는 모든 이메일에 대해 SpamAssassin을 활성화하는 간단한 Procmail 규칙이 포함되어 있습니다. 이메일이 스팸으로 결정되면 헤더에 태그되고 제목은 다음 패턴 앞에 추가됩니다.
*****SPAM*****
이메일의 메시지 본문도 스팸으로 진단될 수 있는 요소에 대해 실행 중인 것으로 시작됩니다.
스팸으로 태그된 이메일의 경우 다음과 유사한 규칙을 사용할 수 있습니다.
:0 Hw * ^X-Spam-Status: Yes spam
이 규칙은 헤더에 스팸으로 태그된 모든 이메일을 스팸이라고 하는 메일 메일에 저장합니다
.
SpamAssassin은 Perl 스크립트이므로 사용 중인 서버에서 바이너리 SpamAssassin 데몬(spamd
) 및 클라이언트 애플리케이션(spamc)을 사용해야 할 수 있습니다. 그러나 이러한 방식으로 SpamAssassin을 구성하려면 호스트에 root
액세스가 필요합니다.
스팸 데몬을
시작하려면 다음 명령을 입력합니다.
~]# systemctl start spamassassin
시스템이 부팅될 때 SpamAssassin 데몬을 시작하려면 다음을 실행합니다.
systemctl enable spamassassin.service
서비스 시작 및 중지에 대한 자세한 내용은 10장. systemd를 사용하여 서비스 관리 을 참조하십시오.
Perl 스크립트 대신 SpamAssassin 클라이언트 애플리케이션을 사용하도록 Procmail을 구성하려면 ~/.procmailrc
파일 맨 위에 다음 행을 배치합니다. 시스템 전체 구성의 경우 /etc/procmailrc
에 배치합니다.
INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc
15.5. 메일 사용자 에이전트
Red Hat Enterprise Linux는 다양한 이메일 프로그램(예: DomainMapping )과 같은 그래픽 이메일 클라이언트 프로그램 및 DomainMapping과 같은 텍스트 기반 이메일 프로그램을 제공합니다.
이 섹션의 나머지 부분에서는 클라이언트와 서버 간 통신을 보호하는 데 중점을 둡니다.
15.5.1. 통신 보안
MUA는 Red Hat Enterprise Linux에 포함된 (예: rsh , Mutt ) SSL 암호화 이메일 세션을 제공합니다.
암호화되지 않은 네트워크를 통해 이동하는 다른 서비스와 마찬가지로 사용자 이름, 암호 및 전체 메시지와 같은 중요한 이메일 정보는 네트워크의 사용자가 인터셉트하고 볼 수 있습니다. 또한 표준 POP
및 pxe 프로토콜은 인증 정보를 암호화되지 않으므로 공격자가 네트워크를 통해 전달되는 사용자 이름과 암호를 수집하여 사용자 계정에 액세스할 수 있습니다.
15.5.1.1. 보안 이메일 클라이언트
원격 서버에서 이메일을 확인하도록 설계된 대부분의 Linux MUA는 SSL 암호화를 지원합니다. 이메일을 검색할 때 SSL을 사용하려면 이메일 클라이언트와 서버 모두에서 이 SSL을 활성화해야 합니다.
SSL은 클라이언트 측에서 쉽게 사용할 수 있으며 MUA 구성 창에서 버튼을 클릭하거나 MUA 구성 파일의 옵션을 통해 수행합니다. MUA가 메시지를
인증하고 다운로드하는 데 사용하는 알려진 포트 번호(993 및 995)가 각각 있습니다.
15.5.1.2. 이메일 고객 통신 보안
이메일 서버에서 redfish 및
POP
사용자에게 SSL 암호화를 제공하는 것은 간단한 문제입니다.
먼저 SSL 인증서를 생성합니다. 이 작업은 SSL 인증서에 대해CA( 인증 기관) 에 적용하거나 자체 서명된 인증서를 생성하여 두 가지 방법으로 수행할 수 있습니다.
자체 서명된 인증서는 테스트 목적으로만 사용해야 합니다. 프로덕션 환경에서 사용하는 모든 서버는 CA에서 서명한 SSL 인증서를 사용해야 합니다.
gRPC 또는 POP
에 대한 자체 서명된 SSL 인증서를 생성하려면 /etc/pki/dovecot/
디렉터리로 변경하고, 선호하는 대로 /etc/pki/dovecot/dovecot-openssl.cnf
구성 파일의 인증서 매개 변수를 편집하고 다음 명령을 root
로 입력합니다.
dovecot]# rm -f certs/dovecot.pem private/dovecot.pem dovecot]# /usr/libexec/dovecot/mkcert.sh
완료되면 /etc/dovecot/conf.d/10-ssl.conf
파일에 다음 구성이 있는지 확인합니다.
ssl_cert = </etc/pki/dovecot/certs/dovecot.pem ssl_key = </etc/pki/dovecot/private/dovecot.pem
다음 명령을 실행하여 dovecot
데몬을 다시 시작합니다.
~]# systemctl restart dovecot
또는 stunnel
명령을 DomainMapping 또는 POP
서비스에 대한 표준 비보안 연결에 대한 암호화 래퍼로 사용할
수 있습니다.
stunnel
유틸리티는 Red Hat Enterprise Linux에 포함된 외부 OpenSSL 라이브러리를 사용하여 강력한 암호화 기능을 제공하고 네트워크 연결을 보호합니다. SSL 인증서를 받기 위해 CA에 적용하는 것이 좋지만 자체 서명된 인증서를 만들 수도 있습니다.
stunnel 을 설치하고 기본 설정을 생성하는 방법에 대한 지침은 Red Hat Enterprise Linux 7 보안 가이드에서 stunnel
사용을 참조하십시오. SMT S 및
에 대한 래퍼로 POP3S
stunnel
을 구성하려면 /etc/stunnel/stunnel.conf
구성 파일에 다음 행을 추가합니다.
[pop3s] accept = 995 connect = 110 [imaps] accept = 993 connect = 143
보안 가이드에서는 stunnel
을 시작하고 중지하는 방법도 설명합니다. 일단 시작하면, pxe 또는 POP
이메일 클라이언트를 사용하고 SSL 암호화를 사용하여 이메일 서버에 연결할 수 있습니다.
15.6. 안티바이러스 및 안티바이러스로 메일 서버 구성
이메일 전송이 완료되면 수신 이메일에는 스팸으로 알려진 원치 않는 메시지가 포함될 수 있습니다. 이러한 메시지에는 보안 위험 및 시스템에서 보안 위험 및 잠재적 프로덕션 손실이 발생할 수 있는 유해한 바이러스 및 악성 코드가 포함될 수 있습니다.
이러한 위험을 방지하기 위해, 들어오는 메시지를 필터링하고 스팸 방지 및 안티바이러스 솔루션을 사용하여 바이러스에 대해 확인할 수 있습니다.
15.6.1. 메일 전송 에이전트 또는 메일 전송 에이전트에 대한 스팸 필터링 구성
MTA(메일 전송 에이전트), MSDA(메일 전송 에이전트) 또는 MUA(메일 사용자 에이전트)에서 스팸을 필터링할 수 있습니다. 이 장에서는 MTA 및 MDA의 스팸 필터링에 대해 설명합니다.
15.6.1.1. 메일 전송 에이전트에서 스팸 필터링 구성
Red Hat Enterprise Linux 7은 다음 두 가지 주요 MTA를 제공합니다. redfish 및 Sendmail.
MTA를 설치하고 구성하는 방법에 대한 자세한 내용은 15.3절. “메일 전송 에이전트” 을 참조하십시오.
MTA 측에서 스팸을 중지하는 것은 여러 가지 스팸 방지 기능이 있는 Sendmail을 사용할 수 있습니다. 헤더 검사,거부 거부,액세스 데이터베이스 및 발신자 정보 확인. 자세한 내용은 15.3.2.5절. “스팸 중지” 에서 참조하십시오.
또한 redfish 및 Sendmail은 타사 메일 필터(밀리코어)와 함께 작동하여 메일 처리 체인의 스팸 및 바이러스를 필터링할 수 있습니다. Postfix의 경우 milters에 대한 지원이 postfix 패키지에 직접 포함됩니다. Sendmail의 경우 milters를 사용할 수 있도록 sendmail-milter 패키지를 설치해야 합니다.
15.6.1.2. 메일 전송 에이전트에서 스팸 필터링 구성
Red Hat Enterprise Linux에는 두 가지 기본 MDA, Procmail 및 mail
유틸리티가 포함되어 있습니다. 자세한 내용은 15.2.2절. “메일 전송 에이전트”를 참조하십시오.
MDA에서 스팸을 방지하기 위해 Procmail 사용자는 spam assin 패키지에서 사용할 수 있는 SpamAssassin이라는 타사 소프트웨어를 설치할 수 있습니다. SpamAssassin은 수신 메일에서 스팸을 식별하기 위해 다양한 방법을 사용하는 스팸 탐지 시스템입니다. Spamassin 설치, 구성 및 배포에 대한 자세한 내용은 15.4.2.6절. “스팸 필터” 또는 How can I configure Spamassin to filter all the incoming mail on my server를 참조하십시오. Red Hat 지식베이스 문서. SpamAssassin에 대한 자세한 내용은 SpamAssassin 프로젝트 웹 사이트를 참조하십시오.
SpamAssasin은 타사 소프트웨어이며 Red Hat은 해당 사용을 지원하지 않습니다.
spam assin 패키지는 EPEL(Extra Packages for Enterprise Linux) 리포지토리를 통해서만 사용할 수 있습니다. EPEL 리포지토리 사용에 대한 자세한 내용은 15.6.3절. “EPEL Repository를 사용하여 안티바이크 및 안티바이러스 소프트웨어 설치” 을 참조하십시오.
Red Hat이 타사 소프트웨어를 처리하는 방법과 Red Hat에서 어떤 수준의 지원을 제공하는지 알아보려면 Red Hat 글로벌 지원 서비스는 타사 소프트웨어, 드라이버 및/또는 인증되지 않은 하드웨어/하이퍼 바이저 또는 게스트 운영 체제를 처리하는방법을 참조하십시오. Red Hat 지식베이스 문서.
15.6.2. 안티바이러스 보호 구성
바이러스로부터 시스템을 보호하려면 ClamAV, 트로저, 악성 코드 및 기타 악성 소프트웨어를 탐지하기위한 오픈 소스 안티바이러스 엔진을 설치할 수 있습니다. ClamAV에 대한 자세한 내용은 ClamAV 프로젝트 웹 사이트를 참조하십시오.
ClamAV는 타사 소프트웨어이며 Red Hat은 사용을 지원하지 않습니다.
clamav, clamav-data, clamav-server 및 clamav-update 패키지는 EPEL(Extra Packages for Enterprise Linux) 리포지토리에서만 사용할 수 있습니다. EPEL 리포지토리 사용에 대한 자세한 내용은 15.6.3절. “EPEL Repository를 사용하여 안티바이크 및 안티바이러스 소프트웨어 설치” 을 참조하십시오.
Red Hat이 타사 소프트웨어를 처리하는 방법과 Red Hat에서 어떤 수준의 지원을 제공하는지 알아보려면 Red Hat 글로벌 지원 서비스는 타사 소프트웨어, 드라이버 및/또는 인증되지 않은 하드웨어/하이퍼 바이저 또는 게스트 운영 체제를 처리하는방법을 참조하십시오. Red Hat 지식베이스 문서.
EPEL 리포지토리를 활성화했으면 다음 명령을 root
사용자로 실행하여 ClamAV를 설치합니다.
~]# yum install clamav clamav-data clamav-server clamav-update
15.6.3. EPEL Repository를 사용하여 안티바이크 및 안티바이러스 소프트웨어 설치
EPEL은 Red Hat Enterprise Linux에 대한 높은 품질의 추가 패키지를 생성, 유지 관리 및 관리하는 Fedora Special Interest Group입니다. 자세한 내용은 Fedora EPEL 웹 사이트를 참조하십시오.
EPEL 리포지토리를 사용하려면 Red Hat Enterprise Linux 7용 최신 버전의 epel-release 패키지를 다운로드합니다. root
사용자로 다음 명령을 실행할 수도 있습니다.
~]# yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpmzu
EPEL 리포지토리를 처음 사용하는 경우 공개 GPG 키로 인증해야 합니다. 자세한 내용은 Fedora 패키지 서명 키를 참조하십시오.
15.7. 추가 리소스
다음은 이메일 애플리케이션에 대한 추가 설명서 목록입니다.
15.7.1. 설치된 문서
Sendmail 구성에 대한 정보는 sendmail 및 sendmail-cf 패키지에 포함되어 있습니다.
/usr/share/sendmail-cf/README
-m4
매크로 프로세서에 대한 정보, Sendmail의 파일 위치, 지원되는 메일러, 향상된 기능에 액세스하는 방법 등을 포함합니다.또한
sendmail
및aliases
도움말 페이지에는 다양한 Sendmail 옵션을 다루는 유용한 정보와 Sendmail/etc/mail/aliases
파일의 적절한 구성이 포함되어 있습니다.
-
/usr/share/doc/hiera-version-number/
- Postfix를 구성하는 방법에 대한 많은 정보가 포함되어 있습니다. version-number 를 Postfix의 버전 번호로 바꿉니다. -
/usr/share/doc/fetchmail-version-number/
-FEATURES
파일에 있는 Fetchmail 전체 목록 및 안내FAQ
문서가 포함되어 있습니다. version-number 를 Fetchmail의 버전 번호로 바꿉니다. /usr/share/doc/procmail-version-number/
- Procmail에 대한 개요, 모든 프로그램 기능을 탐색하는FEATURES
파일, 일반적인 설정 질문에 대한 답변이 포함된FAQ
파일이 포함되어 있습니다.버전 번호를 Procmail의 버전 번호로 바꿉니다.
Procmail 작동 방식을 학습하고 새 레시피를 생성할 때 다음 Procmail 도움말 페이지가 매우 중요합니다.
-
procmail
- Procmail 작동 방식 및 이메일 필터링과 관련된 단계를 제공합니다. -
procmailrc
- 레시피를 구성하는 데 사용되는rc
파일 형식을 설명합니다. -
procmailex
- Procmail 레시피의 유용한 실제 예제를 많이 제공합니다. -
procmailsc
- 메시지의 특정 레시피와 일치하도록 Procmail에서 사용하는 가중치가 있는 스크래핑 기술 설명. -
/usr/share/doc/spamassin-version-number/
- SpamAssassin과 관련된 많은 양의 정보를 포함합니다. 버전 번호를 spam assin 패키지의 버전 번호로 바꿉니다.
-
15.7.2. 온라인 문서
- TLS로 postfix를 구성하는 방법? - TLS 를 사용하도록 postfix 구성을 설명하는 Red Hat 지식베이스 문서.
- Sendmail Smart Host 구성 방법 - 이메일 스마트 호스트 구성을 설명하는 Red Hat 지식베이스 솔루션
- http://www.sendmail.org/ - Sendmail 기능, 문서 및 구성 예제에 대한 상세한 기술 분석을 제공합니다.
- http://www.sendmail.com/ - 사용 가능한 많은 옵션에 대한 확장된 보기를 포함하여 Sendmail 관련 뉴스, 인터뷰 및 기사가 포함되어 있습니다.
- http://www.postfix.org/ - Postfix 프로젝트 홈 페이지에 대해 많은 정보를 포함하고 있습니다. 메일링 리스트는 정보를 찾는데 특히 좋은 곳입니다.
- http://www.fetchmail.info/fetchmail-FAQ.html - Fetchmail에 대한 철저한 FAQ.
- http://www.spamassassin.org/ - SpamAssassin 프로젝트의 공식 사이트.
16장. 파일 및 인쇄 서버
이 장에서는 Red Hat Enterprise Linux에 제공되는 기본 FTP 서버인SMB( Server Message Block ) 및 일반 인터넷 파일 시스템 (FS ) 프로토콜의 오픈 소스 구현인 Samba 의 설치 및 구성을 안내합니다. 또한 인쇄 설정 도구를 사용하여 프린터를 구성하는 방법을 설명합니다.
16.1. Samba
Samba는 Red Hat Enterprise Linux에서 SMB(Server Message Block) 프로토콜을 구현합니다. SMB 프로토콜은 파일 공유 및 공유 프린터와 같은 서버의 리소스에 액세스하는 데 사용됩니다. 또한 Samba는 Microsoft Windows에서 사용하는 DCE RPC(Distributed Computing Environment Remote Procedure Call) 프로토콜을 구현합니다.
다음과 같이 Samba를 실행할 수 있습니다.
- Active Directory(AD) 또는 NT4 도메인 구성원
- 독립 실행형 서버
NT4 PDC(기본 도메인 컨트롤러) 또는 백업 도메인 컨트롤러(BDC)
참고Red Hat은 NT4 도메인을 지원하는 Windows 버전이 포함된 기존 설치에서만 이러한 모드를 지원합니다. Microsoft 운영 체제 이후 Windows 7 및 Windows Server 2008 R2는 NT4 도메인을 지원하지 않기 때문에 새로운 Samba NT4 도메인을 설정하지 않는 것이 좋습니다.
설치 모드와는 독립적으로 디렉터리와 프린터를 선택적으로 공유할 수 있습니다. 그러면 Samba가 파일 및 인쇄 서버로 작동할 수 있습니다.
Red Hat은 Samba를 AD 도메인 컨트롤러(DC)로 실행하는 것을 지원하지 않습니다.
16.1.1. Samba 서비스
Samba는 다음 서비스를 제공합니다.
smbd
이 서비스는 SMB 프로토콜을 사용하여 파일 공유 및 인쇄 서비스를 제공합니다. 또한 서비스는 리소스 잠금을 담당하고 사용자 연결을 인증합니다.
smb
systemd
서비스는smbd
데몬을 시작하고 중지합니다.ClusterRoled
서비스를
사용하려면 samba 패키지를 설치합니다.nmbd
이 서비스는 NetBIOS over IPv4 프로토콜을 사용하여 호스트 이름 및 IP 확인을 제공합니다. 이름 확인 외에도
nmbd
서비스를 사용하면 SMB 네트워크를 검색하여 도메인, 작업 그룹, 호스트, 파일 공유 및 프린터를 찾을 수 있습니다. 이를 위해 서비스는 이 정보를 브로드캐스트 클라이언트에 직접 보고하거나 로컬 또는 마스터 브라우저로 전달합니다.nmb
systemd
서비스는nmbd
데몬을 시작하고 중지합니다.최신 SMB 네트워크는 DNS를 사용하여 클라이언트 및 IP 주소를 확인합니다.
nmbd
서비스를 사용하려면 samba 패키지를 설치합니다.winbindd
winbindd
서비스는 로컬 시스템에서 AD 또는 NT4 도메인 사용자 및 그룹을 사용할 수 있는 NSS(Name Service Switch)의 인터페이스를 제공합니다. 예를 들어, 도메인 사용자는 Samba 서버 또는 다른 로컬 서비스에 호스팅된 서비스에 대해 인증할 수 있습니다.winbind
systemd
서비스는winbindd
데몬을 시작하고 중지합니다.Samba를 도메인 멤버로 설정하는 경우,
smb
를 시작해야 합니다. 그렇지 않으면 로컬 시스템에서 도메인 사용자 및 그룹을 사용할 수 없습니다.d 서비스보다 먼저 winbind
dwinbindd
서비스를 사용하려면 samba-winbind 패키지를 설치합니다.중요Red Hat은 로컬 시스템에 도메인 사용자 및 그룹을 제공하기 위해
winbindd
서비스가 있는 서버로 Samba 실행을 지원합니다. Windows ACL(액세스 제어 목록) 지원 및 NT LAN Manager(NTLM) 대체와 같은 특정 제한으로 인해 Samba에서 SSSD(System Security Services Daemon)를 사용하는 것은 현재 이러한 사용 사례에서 지원되지 않습니다. 자세한 내용은 Red Hat Knowledgebase 문서 IdM 클라이언트에서 실행 중인 Samba 파일 서버에 대한 지원 상태 또는 SSSD가 클라이언트 데몬으로 사용되는 직접 등록된 AD 클라이언트를 참조하십시오.
16.1.2. testparm
utility 를 사용하여 gRPC.conf
파일 확인
testparm
유틸리티는 /etc/samba/smb.conf
파일의 Samba 구성이 올바른지 확인합니다. 유틸리티는 잘못된 매개 변수와 값을 감지하지만 ID 매핑과 같은 잘못된 설정도 탐지합니다. testparm
이 문제를 보고하지 않으면 Samba 서비스가 /etc/samba/smb.conf
파일을 로드합니다. testparm
은 구성된 서비스가 사용 가능한지 또는 예상대로 작동하는지 확인할 수 없습니다.
Red Hat은 이 파일을 수정한 후 testparm
을 사용하여 /etc/hiera/hiera.conf
파일을 확인하는 것이 좋습니다.
/etc/hiera/hiera.conf
파일을 확인하려면 testparm
유틸리티를 root 사용자로 실행합니다. testparm
에서 구성에 잘못된 매개변수, 값 또는 기타 오류를 보고하면 문제를 해결하고 유틸리티를 다시 실행합니다.
예 16.1. testparm
사용
다음 출력에서는 존재하지 않는 매개변수와 잘못된 ID 매핑 구성을 보고합니다.
~]# testparm Load smb config files from /etc/samba/smb.conf rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) Unknown parameter encountered: "log levell" Processing section "[example_share]" Loaded services file OK. ERROR: The idmap range for the domain * (tdb) overlaps with the range of DOMAIN (ad)! Server role: ROLE_DOMAIN_MEMBER Press enter to see a dump of your service definitions # Global parameters [global] ... [example_share] ...
16.1.3. Samba 보안 모드 이해
/etc/samba/smb.conf
파일의 [global]
섹션에 있는 security
매개 변수는 Samba가 서비스에 연결하는 사용자를 인증하는 방법을 관리합니다. 에서 Samba를 설치하는 모드에 따라 매개 변수를 다른 값으로 설정해야 합니다.
AD 도메인 멤버에서
security
= advertising를 설정합니다.이 모드에서 Samba는 Kerberos를 사용하여 AD 사용자를 인증합니다.
도메인 구성원으로 Samba를 설정하는 방법에 대한 자세한 내용은 16.1.5절. “Samba를 도메인 멤버로 설정” 을 참조하십시오.
독립 실행형 서버에서
security
=user
를 설정합니다.이 모드에서 Samba는 로컬 데이터베이스를 사용하여 연결 사용자를 인증합니다.
독립 실행형 서버로 Samba를 설정하는 방법에 대한 자세한 내용은 16.1.4절. “Samba를 독립 실행형 서버로 설정” 을 참조하십시오.
NT4 PDC 또는 BDC에서
security
=user
를 설정합니다.이 모드에서 Samba는 로컬 또는 LDAP 데이터베이스로 사용자를 인증합니다.
NT4 도메인 멤버에서
security
=domain
을 설정합니다.이 모드에서 Samba는 사용자를 NT4 PDC 또는 BDC에 연결하는 것을 인증합니다. AD 도메인 구성원에서는 이 모드를 사용할 수 없습니다.
도메인 구성원으로 Samba를 설정하는 방법에 대한 자세한 내용은 16.1.5절. “Samba를 도메인 멤버로 설정” 을 참조하십시오.
자세한 내용은 tutorial .conf (5) 도움말 페이지의 보안
매개변수에 대한 설명을 참조하십시오.
16.1.4. Samba를 독립 실행형 서버로 설정
특정 상황에서는 관리자가 도메인의 멤버가 아닌 Samba 서버를 설정하려고 합니다. 이 설치 모드에서 Samba는 중앙 DC가 아니라 로컬 데이터베이스로 사용자를 인증합니다. 또한 게스트 액세스를 활성화하여 사용자가 인증 없이 하나 이상의 서비스에 연결할 수 있습니다.
16.1.4.1. 독립 실행형 서버에 대한 서버 구성 설정
Samba를 독립 실행형 서버로 설정하려면 다음을 수행합니다.
Samba를 독립 실행형 서버로 설정
samba 패키지를 설치합니다.
~]# yum install samba
/etc/samba/smb.conf
파일을 편집하고 다음 매개변수를 설정합니다.[global] workgroup = Example-WG netbios name = Server security = user log file = /var/log/samba/%m.log log level = 1
이 구성은
Example-WG
작업 그룹 내에서Server
라는 독립 실행형 서버를 정의합니다. 또한 이 구성을 사용하면 최소 수준( 1)에서 로깅할 수있으며
로그 파일은/var/log/samba/
디렉터리에 저장됩니다. Samba는log file
매개 변수의%m
매크로를 클라이언트 연결의 NetBIOS 이름으로 확장합니다. 이를 통해 각 클라이언트에 대한 개별 로그 파일이 활성화됩니다.자세한 내용은 xfs .conf(5) 도움말 페이지의 매개 변수 설명을 참조하십시오.
파일 또는 프린터 공유를 구성합니다. 보기:
/etc/samba/smb.conf
파일을 확인합니다.~]# testparm
자세한 내용은 16.1.2절. “
testparm
utility를 사용하여 gRPC.conf
파일 확인”의 내용을 참조하십시오.- 인증이 필요한 공유를 설정하면 사용자 계정을 생성합니다. 자세한 내용은 16.1.4.2절. “로컬 사용자 계정 생성 및 활성화”의 내용을 참조하십시오.
필요한 포트를 열고
firewall-cmd
유틸리티를 사용하여 방화벽 구성을 다시 로드합니다.~]# firewall-cmd --permanent --add-port={139/tcp,445/tcp} ~]# firewall-cmd --reload
ClusterRole
서비스를
시작합니다.~]# systemctl start smb
필요에 따라 시스템이 부팅될 때redentials 서비스가 자동으로 시작되도록 활성화합니다.
~]# systemctl enable smb
16.1.4.2. 로컬 사용자 계정 생성 및 활성화
사용자가 공유에 연결할 때 인증할 수 있도록 하려면 운영 체제와 Samba 데이터베이스에서 Samba 호스트에 계정을 만들어야 합니다. Samba는 파일 시스템 개체 및 Samba 계정에서 연결 사용자를 인증하기 위해 운영 체제 계정이 ACL(액세스 제어 목록)의 유효성을 검사해야 합니다.
passdb backend = tdbsam
기본 설정을 사용하는 경우 Samba는 사용자 계정을 /var/lib/samba/private/passdb.tdb
데이터베이스에 저장합니다.
예를 들어 예제
Samba 사용자를 만들려면 다음을 수행합니다.
Samba 사용자 생성
운영 체제 계정을 생성합니다.
~]# useradd -M -s /sbin/nologin example
이전 명령은 홈 디렉터리를 생성하지 않고
예제
계정을 추가합니다. 계정이 Samba로 인증하는 데만 사용되는 경우 계정이 로컬에 로그인하지 못하도록/sbin/nologin
명령을 쉘로 할당합니다.활성화하려면 암호를 운영 체제 계정으로 설정합니다.
~]# passwd example Enter new UNIX password: password Retype new UNIX password: password passwd: password updated successfully
Samba는 운영 체제 계정에 설정된 암호를 사용하여 인증하지 않습니다. 그러나 계정을 활성화하려면 암호를 설정해야 합니다. 계정이 비활성화되어 있으면 Samba는 이 사용자가 연결하면 액세스를 거부합니다.
사용자를 Samba 데이터베이스에 추가하고 암호를 계정으로 설정합니다.
~]# smbpasswd -a example New SMB password: password Retype new SMB password: password Added user example.
이 계정을 사용하여 Samba 공유에 연결할 때 인증하려면 이 암호를 사용합니다.
Samba 계정을 활성화합니다.
~]# smbpasswd -e example Enabled user example.
16.1.5. Samba를 도메인 멤버로 설정
AD 또는 NT4 도메인을 실행하는 관리자는 Samba를 사용하여 Red Hat Enterprise Linux 서버를 도메인에 가입하려는 경우가 많습니다. 이를 통해 다음을 수행할 수 있습니다.
- 다른 도메인 구성원의 도메인 리소스에 액세스
-
sshd
와 같은 로컬 서비스에 도메인 사용자를 인증합니다 - 서버에서 파일 및 인쇄 서버 역할을 할 디렉터리와 프린터 공유
16.1.5.1. 도메인 가입
Red Hat Enterprise Linux 시스템을 도메인에 가입하려면 다음을 수행합니다.
도메인에 Red Hat Enterprise Linux 시스템 가입
다음 패키지를 설치합니다.
~]# yum install realmd oddjob-mkhomedir oddjob samba-winbind-clients \ samba-winbind samba-common-tools
도메인 멤버에서 디렉터리 또는 프린터를 공유하려면 samba 패키지를 설치합니다.
~]# yum install samba
AD에 가입하는 경우 samba-winbind-krb5-locator 패키지를 추가로 설치합니다.
~]# yum install samba-winbind-krb5-locator
이 플러그인을 사용하면 Kerberos가 DNS 서비스 레코드를 사용하는 AD 사이트를 기반으로 KDC(Key Distribution Center)를 찾을 수 있습니다.
필요한 경우 기존
/etc/hiera/hiera.conf
Samba 구성 파일의 이름을 변경합니다.~]# mv /etc/samba/smb.conf /etc/samba/smb.conf.old
도메인에 가입합니다. 예를 들어
ad.example.com
이라는 도메인에 참여하려면 다음을 수행합니다.~]# realm join --membership-software=samba --client-software=winbind ad.example.com
이전 명령을 사용하면
realm
유틸리티가 자동으로 수행됩니다.-
ad.example
.com 도메인의 멤버십에 대한 /etc/samba/smb.conf
파일을 만듭니다. -
사용자 및 그룹 조회에 대한
winbind
모듈을/etc/nsswitch.conf
파일에 추가합니다. -
/etc/pam.d/
디렉토리에서 PAM(Pluggable Authentication Module) 구성 파일을 업데이트합니다. winbind
서비스를 시작하고 시스템이 부팅될 때 서비스가 시작됩니다.realm
유틸리티에 대한 자세한 내용은 Red Hat Windows Integration Guide 의 realm(8) 도움말 페이지 및 해당 섹션을 참조하십시오.
-
-
선택적으로
/etc/samba/smb.conf
파일에서 대체 ID 매핑 백엔드 또는 사용자 지정된 ID 매핑 설정을 설정합니다. 자세한 내용은 16.1.5.3절. “ID 매핑 이해”의 내용을 참조하십시오. - 선택적으로 구성을 확인합니다. 16.1.5.2절. “도메인 구성원으로서의 Samba Was Correctly Joined as a Domain Member 확인”을 참조하십시오.
winbindd
가 실행 중인지 확인합니다.~]# systemctl status winbind
중요Samba가 도메인 사용자 및 그룹 정보를 쿼리하도록 활성화하려면
winbindd
서비스가 실행 중이어야 합니다. floatingd를 시작하기 전에.
디렉터리 및 프린터를 공유하도록 samba 패키지를 설치한 경우 xfsd
서비스를
시작합니다.~]# systemctl start smb
16.1.5.2. 도메인 구성원으로서의 Samba Was Correctly Joined as a Domain Member 확인
Red Hat Enterprise Linux에 도메인 멤버로 가입한 후 다른 테스트를 실행하여 조인이 성공했는지 확인할 수 있습니다. 보기:
운영 체제가 도메인 사용자 계정 및 그룹을 검색할 수 있는지 확인
getent
유틸리티를 사용하여 운영 체제가 도메인 사용자 및 그룹을 검색할 수 있는지 확인합니다. 예를 들면 다음과 같습니다.
AD
도메인의관리자
계정을 쿼리하려면 다음을 수행합니다.~]# getent passwd AD\\administrator AD\administrator:*:10000:10000::/home/administrator@AD:/bin/bash
AD
도메인에서Domain Users
그룹의 멤버를 쿼리하려면 다음을 수행합니다.~]# getent group "AD\\Domain Users" AD\domain users:x:10000:user
명령이 올바르게 작동하는 경우 파일 및 디렉터리에 대한 권한을 설정할 때 도메인 사용자 및 그룹을 사용할 수 있는지 확인합니다. 예를 들어 /srv/samba/example.txt
파일의 소유자를 AD\administrator로 설정하고 그룹을
로 설정하려면 다음을 수행합니다.
AD\
Domain Users
~]# chown "AD\administrator":"AD\Domain Users" /srv/samba/example.txt
AD 도메인 사용자가 Kerberos 티켓을 받을 수 있는지 확인
AD 환경에서 사용자는 DC에서 Kerberos 티켓을 받을 수 있습니다. 예를 들어 관리자가
Kerberos 티켓을 받을 수 있는지 확인하려면 다음을 수행합니다.
kinit
및 klist
유틸리티를 사용하려면 Samba 도메인 멤버에 KnativeServing5- octets 패키지를 설치합니다.
Kerberos 티켓 검색
administrator@AD.EXAMPLE.COM
주요인의 티켓을 받습니다.~]# kinit administrator@AD.EXAMPLE.COM
캐시된 Kerberos 티켓을 표시합니다.
~]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: administrator@AD.EXAMPLE.COM Valid starting Expires Service principal 11.09.2017 14:46:21 12.09.2017 00:46:21 krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM renew until 18.09.2017 14:46:19
사용 가능한 도메인 나열
winbindd
서비스를 통해 사용 가능한 모든 도메인을 나열하려면 다음을 입력합니다.
~]# wbinfo --all-domains
Samba가 도메인 멤버로 성공적으로 가입된 경우 이 명령은 기본 제공 및 로컬 호스트 이름을 표시하고 도메인 Samba는 신뢰할 수 있는 도메인을 포함하는 멤버입니다.
예 16.2. 사용 가능한 도메인 표시
~]# wbinfo --all-domains
BUILTIN
SAMBA-SERVER
AD
16.1.5.3. ID 매핑 이해
Windows 도메인은 고유한 SID(보안 식별자)를 통해 사용자와 그룹을 구분합니다. 그러나 Linux에는 사용자 및 그룹마다 고유한 UID와 GID가 필요합니다. 도메인 구성원으로 Samba를 실행하는 경우 winbindd
서비스는 도메인 사용자 및 그룹에 대한 정보를 운영 체제에 제공합니다.
winbindd
서비스를 활성화하여 Linux에 사용자와 그룹에 고유한 ID를 제공하려면 /etc/samba/smb.conf 파일에 ID 매핑을 구성해야 합니다.
- 로컬 데이터베이스(기본 도메인)
- Samba 서버가 멤버인 AD 또는 NT4 도메인
- 사용자가 이 Samba 서버의 리소스에 액세스할 수 있어야 하는 각 신뢰할 수 있는 도메인
16.1.5.3.1. 계획 ID 범위
Linux UID 및 GID를 AD에 저장하든, 이를 생성하도록 Samba를 구성하는 경우 각 도메인 구성에는 다른 도메인과 겹치지 않아야 하는 고유한 ID 범위가 필요합니다.
중복 ID 범위를 설정하면 Samba가 올바르게 작동하지 않습니다.
예 16.3. 고유 ID 범위
다음은 기본값(*
), AD-DOM 및
도메인에 대한 인수 이외의 ID 매핑 범위를 보여줍니다.
TRUST-DOM
[global] ... idmap config * : backend = tdb idmap config * : range = 10000-999999 idmap config AD-DOM:backend = rid idmap config AD-DOM:range = 2000000-2999999 idmap config TRUST-DOM:backend = rid idmap config TRUST-DOM:range = 4000000-4999999
도메인당 하나의 범위만 할당할 수 있습니다. 따라서 도메인 범위 사이에 충분한 공간을 남겨 두십시오. 이렇게 하면 나중에 도메인이 확장되는 경우 범위를 확장할 수 있습니다.
나중에 도메인에 다른 범위를 할당하면 이러한 사용자와 그룹이 이전에 만든 파일과 디렉터리의 소유권이 손실됩니다.
16.1.5.3.2. *
기본 도메인
도메인 환경에서는 다음 각각에 대해 하나의 ID 매핑 구성을 추가합니다.
- Samba 서버가 멤버인 도메인
- Samba 서버에 액세스할 수 있는 신뢰할 수 있는 각 도메인
그러나 다른 모든 개체에 대해 Samba는 기본 도메인의 ID를 할당합니다. 여기에는 다음이 포함됩니다.
- 로컬 Samba 사용자 및 그룹
-
BUILTIN\Administrators
와 같은 Samba 기본 제공 계정 및 그룹
Samba가 올바르게 작동하도록 하려면 이 섹션에 설명된 대로 기본 도메인을 구성해야 합니다.
할당된 ID를 영구적으로 저장하려면 기본 도메인 백엔드에 쓸 수 있어야 합니다.
기본 도메인의 경우 다음 백엔드 중 하나를 사용할 수 있습니다.
tdb
tdb
백엔드를 사용하도록 기본 도메인을 구성하는 경우 나중에 생성될 오브젝트를 포함할 ID 범위를 설정하고 정의된 도메인 ID 매핑 구성의 일부가 아닌 ID 범위를 설정합니다.예를 들어
/etc/samba/smb.conf
파일의[global]
섹션에서 다음을 설정합니다.idmap config * : backend = tdb idmap config * : range = 10000-999999
자세한 내용은 16.1.5.4.1절. “
tdb
ID 매핑 백엔드 사용”의 내용을 참조하십시오.autorid
autorid
백엔드를 사용하도록 기본 도메인을 구성하는 경우 도메인에 대한 ID 매핑 구성을 추가하는 것은 선택 사항입니다.예를 들어
/etc/samba/smb.conf
파일의[global]
섹션에서 다음을 설정합니다.idmap config * : backend = autorid idmap config * : range = 10000-999999
자세한 내용은
자동 백엔드
구성의 내용을 참조하십시오.
16.1.5.4. 다른 ID 매핑 백엔드
Samba는 특정 구성에 대해 다양한 ID 매핑 백엔드를 제공합니다. 가장 자주 사용되는 백엔드는 다음과 같습니다.
백엔드 | 사용 사례 |
---|---|
|
|
| AD 도메인만 해당 |
| AD 및 NT4 도메인 |
|
AD, NT4 및 |
다음 섹션에서는 이점, 권장 시나리오, 백엔드를 사용할 위치 및 구성 방법에 대해 설명합니다.
16.1.5.4.1. tdb
ID 매핑 백엔드 사용
winbindd
서비스는 기본적으로 쓰기 가능한 tdb
ID 매핑 백엔드를 사용하여 SID(보안 식별자), UID 및 GID 매핑 테이블을 저장합니다. 여기에는 로컬 사용자, 그룹 및 기본 제공 주체가 포함됩니다.
이 백엔드는 *
기본 도메인에만 사용합니다. 예를 들면 다음과 같습니다.
idmap config * : backend = tdb idmap config * : range = 10000-999999
*
기본 도메인에 대한 자세한 내용은 16.1.5.3.2절. “*
기본 도메인” 을 참조하십시오.
16.1.5.4.2. 광고
ID 매핑 백엔드 사용
ad
ID 매핑 백엔드는 읽기 전용 API를 구현하여 AD에서 계정 및 그룹 정보를 읽습니다. 이는 다음과 같은 이점을 제공합니다.
- 모든 사용자 및 그룹 설정은 AD에 중앙에 저장됩니다.
- 이 백엔드를 사용하는 모든 Samba 서버에서 사용자 및 그룹 ID가 일관되게 유지됩니다.
- ID는 손상될 수 있는 로컬 데이터베이스에 저장되지 않으므로 파일 소유권을 분실할 수 없습니다.
ad
백엔드는 AD에서 다음 속성을 읽습니다.
AD 특성 이름 | 오브젝트 유형 | 매핑됨 |
---|---|---|
| 사용자 및 그룹 | 사용자 또는 그룹 이름 (오브젝트에 따라) |
| 사용자 | 사용자 ID(UID) |
| Group | 그룹 ID(GID) |
| 사용자 | 사용자 쉘의 경로 |
| 사용자 | 사용자의 홈 디렉터리 경로 |
| 사용자 | 기본 그룹 ID |
[a]
Samba는 idmap config DOMAIN:unix_nss_info = yes 를 설정하는 경우에만 이 속성을 읽습니다.
[b]
Samba는 idmap config DOMAIN:unix_primary_group = yes 를 설정하는 경우에만 이 속성을 읽습니다.
|
ad
백엔드의 사전 요구 사항
ad
ID 매핑 백엔드를 사용하려면 다음을 수행합니다.
-
사용자와 그룹 모두 AD에 고유한 ID를 설정해야 하며 ID는
/etc/samba/smb.conf
파일에 구성된 범위 내에 있어야 합니다. 범위를 벗어나는 ID가 있는 개체는 Samba 서버에서 사용할 수 없습니다. -
사용자와 그룹은 AD에서 모든 필수 속성을 설정해야 합니다. 필수 속성이 없으면 Samba 서버에서 사용자 또는 그룹을 사용할 수 없습니다. 필요한 속성은 구성에 따라 다릅니다. 표 16.2. “사용자 및 그룹 오브젝트에서
광고
백엔드 읽기 속성”을 참조하십시오.
ad
백엔드 구성
ad
ID 매핑 백엔드를 사용하도록 Samba AD 멤버를 구성하려면 다음을 수행합니다.
도메인 멤버에서 광고
백엔드 구성
/etc/samba/smb.conf
파일에서[global]
섹션을 편집합니다.없는 경우 기본 도메인 (
*
)의 ID 매핑 구성을 추가합니다. 예를 들면 다음과 같습니다.idmap config * : backend = tdb idmap config * : range = 10000-999999
기본 도메인 구성에 대한 자세한 내용은 16.1.5.3.2절. “
*
기본 도메인” 을 참조하십시오.AD 도메인의
ad
ID 매핑 백엔드를 활성화합니다.idmap config DOMAIN : backend = ad
AD 도메인의 사용자와 그룹에 할당된 ID 범위를 설정합니다. 예를 들면 다음과 같습니다.
idmap config DOMAIN : range = 2000000-2999999
중요범위는 이 서버의 다른 도메인 구성과 겹치지 않아야 합니다. 또한 범위는 나중에 할당되는 모든 ID를 포함할 만큼 충분히 커야 합니다. 자세한 내용은 16.1.5.3.1절. “계획 ID 범위”의 내용을 참조하십시오.
AD에서 속성을 읽을 때 Samba가 RFC 2307 스키마를 사용하도록 설정합니다.
idmap config DOMAIN : schema_mode = rfc2307
Samba가 해당 AD 속성에서 로그인 쉘 및 사용자 홈 디렉터리 경로를 읽을 수 있도록 하려면 다음을 설정합니다.
idmap config DOMAIN : unix_nss_info = yes
또는 모든 사용자에게 적용되는 균일한 도메인 전체 홈 디렉터리 경로 및 로그인 쉘을 설정할 수 있습니다. 예를 들면 다음과 같습니다.
template shell = /bin/bash template homedir = /home/%U
변수 대체에 대한 자세한 내용은 gRPC .conf(5) 도움말 페이지의 VARIABLE SUBSTITUTIONS 섹션을 참조하십시오.
기본적으로 Samba는 사용자 오브젝트의
primaryGroupID
속성을 Linux의 사용자 기본 그룹으로 사용합니다. 또는 대신gidNumber
특성에 설정된 값을 사용하도록 Samba를 구성할 수 있습니다.idmap config DOMAIN : unix_primary_group = yes
/etc/samba/smb.conf
파일을 확인합니다.~]# testparm
자세한 내용은 16.1.2절. “
testparm
utility를 사용하여 gRPC.conf
파일 확인”의 내용을 참조하십시오.Samba 구성을 다시 로드합니다.
~]# smbcontrol all reload-config
- 설정이 예상대로 작동하는지 확인합니다. “운영 체제가 도메인 사용자 계정 및 그룹을 검색할 수 있는지 확인”을 참조하십시오.
자세한 내용은 tutorial .conf(5) 및 idmap_ad(8) 매뉴얼 페이지를 참조하십시오.
16.1.5.4.3. 라이딩 ID
매핑 사용
Samba는 Windows GovCloud의 RID(RID)를 사용하여 Red Hat Enterprise Linux에 ID를 생성할 수 있습니다.
RID는 SID의 마지막 부분입니다. 예를 들어 사용자의 SID가 S-1-5-21-5421822485-11512151-421485315-30014
이면 30014
가 해당하는 RID입니다. 자세한 내용은 Samba에서 로컬 ID를 계산하는 방법에 대한 자세한 내용은 idmap_rid(8) 매뉴얼 페이지를 참조하십시오.
제거
ID 매핑 백엔드는 AD 및 NT4 도메인의 알고리즘 매핑 체계를 기반으로 계정과 그룹 정보를 계산하는 읽기 전용 API를 구현합니다. 백엔드를 구성할 때 idmap config DOMAIN : range
매개변수에서 가장 낮은 RID를 설정해야 합니다. Samba는 이 매개 변수에 설정된 것보다 낮은 RID를 가진 사용자 또는 그룹을 매핑하지 않습니다.
읽기 전용 백엔드인 remove는 BUILT
IN
그룹과 같은 새 ID를 할당할 수 없습니다. 따라서 *
기본 도메인에 이 백엔드를 사용하지 마십시오.
혜택
- 구성된 범위 내에 RID가 있는 모든 도메인 사용자 및 그룹은 도메인 멤버에서 자동으로 사용할 수 있습니다.
- ID, 홈 디렉터리 및 로그인 쉘을 수동으로 할당할 필요가 없습니다.
단점
- 모든 도메인 사용자는 동일한 로그인 쉘 및 홈 디렉터리가 할당됩니다. 그러나 변수를 사용할 수 있습니다.
-
사용자 및 그룹 ID는 모두 동일한 ID 범위 설정으로
제거
백엔드를 사용하는 경우 Samba 도메인 멤버에서만 동일합니다. - 도메인 구성원에서 개별 사용자 또는 그룹을 사용할 수 없는 경우 제외할 수 없습니다. 구성된 범위를 벗어난 사용자와 그룹만 제외됩니다.
-
winbindd
서비스에서 ID를 계산하는 데 사용하는 공식에 따라 다른 도메인의 오브젝트에 동일한 RID가 있는 경우 다중 도메인 환경에서 중복 ID가 발생할 수 있습니다.
제거 백엔드
구성
제거
ID 매핑 백엔드를 사용하도록 Samba 도메인 멤버를 구성하려면 다음을 수행합니다.
도메인 멤버에서 제거
백엔드 구성
/etc/samba/smb.conf
파일에서[global]
섹션을 편집합니다.없는 경우 기본 도메인 (
*
)의 ID 매핑 구성을 추가합니다. 예를 들면 다음과 같습니다.idmap config * : backend = tdb idmap config * : range = 10000-999999
기본 도메인 구성에 대한 자세한 내용은 16.1.5.3.2절. “
*
기본 도메인” 을 참조하십시오.도메인에 대해
제거
ID 매핑 백엔드를 활성화합니다.idmap config DOMAIN : backend = rid
향후 할당될 모든 RID를 포함할 만큼 큰 범위를 설정합니다. 예를 들면 다음과 같습니다.
idmap config DOMAIN : range = 2000000-2999999
Samba는 이 도메인의 RID가 범위에 속하지 않는 사용자와 그룹을 무시합니다.
중요범위는 이 서버의 다른 도메인 구성과 겹치지 않아야 합니다. 자세한 내용은 16.1.5.3.1절. “계획 ID 범위”의 내용을 참조하십시오.
매핑된 모든 사용자에게 할당될 쉘 및 홈 디렉터리 경로를 설정합니다. 예를 들면 다음과 같습니다.
template shell = /bin/bash template homedir = /home/%U
변수 대체에 대한 자세한 내용은 gRPC .conf(5) 도움말 페이지의 VARIABLE SUBSTITUTIONS 섹션을 참조하십시오.
/etc/samba/smb.conf
파일을 확인합니다.~]# testparm
자세한 내용은 16.1.2절. “
testparm
utility를 사용하여 gRPC.conf
파일 확인”의 내용을 참조하십시오.Samba 구성을 다시 로드합니다.
~]# smbcontrol all reload-config
- 설정이 예상대로 작동하는지 확인합니다. “운영 체제가 도메인 사용자 계정 및 그룹을 검색할 수 있는지 확인”을 참조하십시오.
16.1.5.4.4. 자동 ID
매핑 백엔드 사용
자동라이드 백엔드
는 제거
ID 매핑 백엔드와 유사하게 작동하지만 다른 도메인에 대한 ID를 자동으로 할당할 수 있습니다. 이를 통해 다음과 같은 상황에서 autorid
백엔드를 사용할 수 있습니다.
-
*
기본 도메인에만 해당됩니다. -
*
기본 도메인 및 추가 도메인의 경우 각 추가 도메인에 대한 ID 매핑 구성을 생성할 필요가 없습니다. - 특정 도메인에만 적용됩니다.
혜택
- 계산된 UID 및 GID가 구성된 범위 내에 있는 모든 도메인 사용자와 그룹은 도메인 멤버에서 자동으로 사용할 수 있습니다.
- ID, 홈 디렉터리 및 로그인 쉘을 수동으로 할당할 필요가 없습니다.
- 다중 도메인 환경의 여러 오브젝트에 동일한 RID가 있는 경우에도 중복 ID가 없습니다.
단점
- 사용자 및 그룹 ID는 Samba 도메인 구성원에서 동일하지 않습니다.
- 모든 도메인 사용자는 동일한 로그인 쉘 및 홈 디렉터리가 할당됩니다. 그러나 변수를 사용할 수 있습니다.
- 도메인 구성원에서 개별 사용자 또는 그룹을 사용할 수 없는 경우 제외할 수 없습니다. 계산된 UID 또는 GID가 구성된 범위를 벗어나는 사용자와 그룹만 제외됩니다.
자동 백엔드
구성
*
기본 도메인의 자동
ID 매핑 백엔드를 사용하도록 Samba 도메인 멤버를 구성하려면 다음을 수행합니다.
기본 도메인에 autorid
를 사용하는 경우 도메인에 대한 ID 매핑 구성을 추가하는 것은 선택 사항입니다.
도메인 멤버에서 자동
백엔드 구성
/etc/samba/smb.conf
파일에서[global]
섹션을 편집합니다.*
기본 도메인의autorid
ID 매핑 백엔드를 활성화합니다.idmap config * : backend = autorid
모든 기존 및 향후 객체에 ID를 할당할 수 있을 만큼 큰 범위를 설정합니다. 예를 들면 다음과 같습니다.
idmap config * : range = 10000-999999
Samba는 이 도메인에서 계산된 ID가 범위에 속하지 않는 사용자와 그룹을 무시합니다. 백엔드 계산된 ID에 대한 자세한 내용은 idmap_autorid(8) 매뉴얼 페이지의 MAPPING FORMULAS 섹션을 참조하십시오.
주의범위를 설정하고 Samba가 사용을 시작한 후 범위의 상한값만 늘릴 수 있습니다. 범위에 대한 다른 모든 변경으로 인해 새 ID 할당이 발생할 수 있으므로 파일 소유권이 손상될 수 있습니다.
선택적으로 범위 크기를 설정합니다. 예를 들면 다음과 같습니다.
idmap config * : rangesize = 200000
Samba는
idmap config * : range
매개변수에 설정된 범위의 모든 ID를 사용할 때까지 각 도메인의 오브젝트에 대해 이 연속 ID 수를 할당합니다. 자세한 내용은 idmap_autorid(8) 매뉴얼 페이지의rangesize
매개변수 설명을 참조하십시오.매핑된 모든 사용자에게 할당될 쉘 및 홈 디렉터리 경로를 설정합니다. 예를 들면 다음과 같습니다.
template shell = /bin/bash template homedir = /home/%U
변수 대체에 대한 자세한 내용은 gRPC .conf(5) 도움말 페이지의 VARIABLE SUBSTITUTIONS 섹션을 참조하십시오.
필요한 경우 도메인에 대한 ID 매핑 구성을 추가합니다. 개별 도메인에 대한 구성이 없는 경우 Samba는 이전에 구성된
*
기본 도메인에서자동
만료 백엔드 설정을 사용하여 ID를 계산합니다.중요개별 도메인에 추가 백엔드를 구성하는 경우 모든 ID 매핑 구성 범위가 겹치지 않아야 합니다. 자세한 내용은 16.1.5.3.1절. “계획 ID 범위”의 내용을 참조하십시오.
/etc/samba/smb.conf
파일을 확인합니다.~]# testparm
자세한 내용은 16.1.2절. “
testparm
utility를 사용하여 gRPC.conf
파일 확인”의 내용을 참조하십시오.Samba 구성을 다시 로드합니다.
~]# smbcontrol all reload-config
- 설정이 예상대로 작동하는지 확인합니다. “운영 체제가 도메인 사용자 계정 및 그룹을 검색할 수 있는지 확인”을 참조하십시오.
16.1.7. Samba 인쇄 서버 설정
Samba를 출력 서버로 설정하면 네트워크의 클라이언트가 Samba를 사용하여 출력할 수 있습니다. 또한 Windows 클라이언트가 구성된 경우 Samba 서버에서 드라이버를 다운로드할 수 있습니다.
프린터를 공유하려면 먼저 Samba를 설정합니다.
16.1.7.1. Samba 스풀sd
서비스
Samba 스풀sd
는 smbd
서비스에 통합된 서비스입니다. Samba 구성에서 spoolsd
를 활성화하여 작업 또는 프린터 수가 많은 인쇄 서버의 성능을 크게 높입니다.
spools d
없이 Samba는 smbd
프로세스를 분기하고 각 출력 작업의 printcap
캐시를 초기화합니다. 프린터가 많은 경우 캐시를 초기화하는 동안 smbd
서비스가 여러 초 동안 응답하지 않을 수 있습니다. spools d
서비스를 사용하면 지연 없이 출력 작업을 처리하는 미리 분기된 smbd
프로세스를 시작할 수 있습니다. 기본 spoolsd
smbd
프로세스는 낮은 메모리를 사용하고 하위 프로세스를 포크하고 종료합니다.
스풀sd
서비스를 활성화하려면 다음을 수행합니다.
스풀sd
서비스 활성화
/etc/samba/smb.conf
파일에서[global]
섹션을 편집합니다.다음 매개변수를 추가합니다.
rpc_server:spoolss = external rpc_daemon:spoolssd = fork
선택적으로 다음 매개변수를 설정할 수 있습니다.
매개변수 기본값 설명 spoolssd:prefork_min_children
5
최소 하위 프로세스 수
spoolssd:prefork_max_children
25
최대 하위 프로세스 수
spoolssd:prefork_spawn_rate
5
새 연결이 설정된 경우 Samba는 이 매개 변수에 설정된 새 하위 프로세스 수를 spools
sd:prefork_max_children
에 설정된 값까지 분기합니다.spoolssd:prefork_max_allowed_clients
100
클라이언트 수, 자식 프로세스는
spoolssd:prefork_child_min_life
60
하위 프로세스의 최소 수명(초)입니다. 60초는 최소값입니다.
/etc/samba/smb.conf
파일을 확인합니다.~]# testparm
자세한 내용은 16.1.2절. “
testparm
utility를 사용하여 gRPC.conf
파일 확인”의 내용을 참조하십시오.smb
서비스를 다시 시작하십시오.~]# systemctl restart smb
서비스를 다시 시작한 후에는 Samba에서 smbd
하위 프로세스를 자동으로 시작합니다.
~]# ps axf ... 30903 smbd 30912 \_ smbd 30913 \_ smbd 30914 \_ smbd 30915 \_ smbd ...
16.1.7.2. Samba에서 출력 서버 지원 활성화
인쇄 서버 지원을 활성화하려면 다음을 수행합니다.
Samba에서 출력 서버 지원 활성화
Samba 서버에서 CUPS를 설정하고 프린터를 CUPS 백엔드에 추가합니다. 자세한 내용은 16.3절. “설정 인쇄”의 내용을 참조하십시오.
참고Samba는 CUPS가 Samba 출력 서버에 로컬로 설치된 경우에만 CUPS로 출력 작업을 전달할 수 있습니다.
/etc/samba/smb.conf
파일을 편집합니다.spools
d 서비스를 활성화하려면
[global]
섹션에 다음 매개변수를 추가합니다.rpc_server:spoolss = external rpc_daemon:spoolssd = fork
자세한 내용은 16.1.7.1절. “Samba
스풀sd
서비스”의 내용을 참조하십시오.출력 백엔드를 구성하려면
[printers]
섹션을 추가합니다.[printers] comment = All Printers path = /var/tmp/ printable = yes create mask = 0600
중요프린터
공유 이름은 하드 코딩되어 있으며 변경할 수 없습니다.
/etc/samba/smb.conf
파일을 확인합니다.~]# testparm
자세한 내용은 16.1.2절. “
testparm
utility를 사용하여 gRPC.conf
파일 확인”의 내용을 참조하십시오.필요한 포트를 열고
firewall-cmd
유틸리티를 사용하여 방화벽 구성을 다시 로드합니다.~]# firewall-cmd --permanent --add-service=samba ~]# firewall-cmd --reload
smb
서비스를 다시 시작하십시오.~]# systemctl restart smb
서비스를 다시 시작한 후 Samba는 CUPS 백엔드에 구성된 모든 프린터를 자동으로 공유합니다. 특정 프린터만 수동으로 공유하려면 16.1.7.3절. “특정 프린터 수동 공유”을 참조하십시오.
16.1.7.3. 특정 프린터 수동 공유
Samba를 출력 서버로 구성한 경우 기본적으로 Samba는 CUPS 백엔드에 구성된 모든 프린터를 공유합니다. 특정 프린터만 공유하려면 다음을 수행합니다.
특정 프린터 수동 공유
/etc/samba/smb.conf
파일을 편집합니다.[global]
섹션에서 설정을 설정하여 자동 프린터 공유를 비활성화합니다.load printers = no
공유할 각 프린터에 대해 섹션을 추가합니다. 예를 들어 Samba
에서 CUPS 백엔드의
printer로 공유하려면 다음 섹션을 추가합니다.example
라는 프린터를 Example-[Example-Printer] path = /var/tmp/ printable = yes printer name = example
각 프린터에 대해 개별 스풀 디렉토리가 필요하지 않습니다.
[printers]
섹션에 설정한 것과 동일한 스풀 디렉토리를 프린터매개변수에
설정할 수 있습니다.
/etc/samba/smb.conf
파일을 확인합니다.~]# testparm
자세한 내용은 16.1.2절. “
testparm
utility를 사용하여 gRPC.conf
파일 확인”의 내용을 참조하십시오.Samba 구성을 다시 로드합니다.
~]# smbcontrol all reload-config
16.1.7.4. Windows 클라이언트에 대한 자동 프린터 드라이버 다운로드 설정
Windows 클라이언트용 Samba 출력 서버를 실행하는 경우 드라이버 및 사전 설정 프린터를 업로드할 수 있습니다. 사용자가 프린터에 연결하면 Windows가 자동으로 드라이버를 다운로드하여 클라이언트에 로컬로 설치합니다. 사용자는 설치에 대한 로컬 관리자 권한이 필요하지 않습니다. 또한 Windows는 트레이 수와 같이 사전 구성된 드라이버 설정을 적용합니다.
자동 프린터 드라이버 다운로드를 설정하기 전에 Samba를 인쇄 서버로 구성하고 프린터를 공유해야 합니다. 자세한 내용은 16.1.7절. “Samba 인쇄 서버 설정”의 내용을 참조하십시오.
16.1.7.4.1. 프린터 드라이버에 대한 기본 정보
이 섹션에서는 프린터 드라이버에 대한 일반적인 정보를 제공합니다.
지원되는 드라이버 모델 버전
Samba는 Windows 2000 이상 및 Windows Server 2000 이상에서 지원되는 프린터 드라이버 모델 버전 3만 지원합니다. Samba는 Windows 8 및 Windows Server 2012에 도입된 드라이버 모델 버전 4를 지원하지 않습니다. 그러나 이러한 버전과 이후 버전의 Windows 버전도 버전 3 드라이버를 지원합니다.
패키지 인식 드라이버
Samba는 패키지 인식 드라이버를 지원하지 않습니다.
업로드를 위한 printer 드라이버 준비
드라이버를 Samba 인쇄 서버에 업로드하려면 다음을 수행하십시오.
- 압축된 형식으로 제공되는 경우 드라이버의 압축을 풉니다.
일부 드라이버에서는 Windows 호스트에서 로컬로 드라이버를 설치하는 설정 애플리케이션을 시작해야 합니다. 특정 상황에서 설치 프로그램은 설치를 실행하는 동안 개별 파일을 운영 체제의 임시 폴더로 추출합니다. 드라이버 파일을 업로드에 사용하려면 다음을 수행합니다.
- 설치 프로그램을 시작합니다.
- 임시 폴더에서 새 위치로 파일을 복사합니다.
- 설치를 취소합니다.
프린터 제조업체에 인쇄 서버 업로드를 지원하는 드라이버를 요청합니다.
프린터에 대한 32비트 및 64비트 드라이버를 클라이언트에 제공
32비트 및 64비트 Windows 클라이언트 모두에 대해 프린터용 드라이버를 제공하려면 두 아키텍처에서 정확히 동일한 이름으로 드라이버를 업로드해야 합니다. 예를 들어 Example PostScript라는 32비트 드라이버와
라는 64비트 드라이버를 업로드하는 경우 이름이 일치하지 않습니다. 따라서 프린터에 드라이버 중 하나만 할당할 수 있으며 두 아키텍처에서는 드라이버를 모두 사용할 수 없습니다.
Example PostScript
(v1.0)
16.1.7.4.2. 사용자가 드라이버 업로드 및 사전 설정 활성화
프린터 드라이버를 업로드하고 사전 구성할 수 있으려면 사용자 또는 그룹에 SeprintOperatorPrivilege
권한이 부여되어야 합니다. 사용자를 printadmin
그룹에 추가해야 합니다. Red Hat Enterprise Linux는 samba 패키지를 설치할 때 이 그룹을 자동으로 생성합니다. printadmin
그룹에는 1000보다 낮은 사용 가능한 가장 낮은 동적 시스템 GID가 할당됩니다.
SeprintOperatorPrivilege
권한을 printadmin
그룹에 부여하려면 다음을 수행합니다.
~]# net rpc rights grant "printadmin" SePrintOperatorPrivilege \ -U "DOMAIN\administrator" Enter DOMAIN\administrator's password: Successfully granted rights.
도메인 환경에서 도메인 그룹에 Se printOperatorPrivilege
을 부여합니다. 이를 통해 사용자의 그룹 멤버십을 업데이트하여 권한을 중앙에서 관리할 수 있습니다.
SePrintOperatorPrivilege
이 부여된 모든 사용자 및 그룹을 나열하려면 다음을 수행하십시오.
~]# net rpc rights list privileges SePrintOperatorPrivilege \ -U "DOMAIN\administrator" Enter administrator's password: SePrintOperatorPrivilege: BUILTIN\Administrators DOMAIN\printadmin
16.1.7.4.4. 클라이언트가 Samba Print Server를 신뢰할 수 있도록Enable the connection to enable clients to trust the Samba Print Server
보안상의 이유로 최신 Windows 운영 체제는 클라이언트가 신뢰할 수 없는 서버에서 패키지 인식 프린터 드라이버를 다운로드하지 못하도록 합니다. 인쇄 서버가 AD의 멤버인 경우 도메인에 그룹 정책 오브젝트(GPO)를 만들어 Samba 서버를 신뢰할 수 있습니다.
grant를 만들려면 사용 중인 Windows 컴퓨터에는 Windows Remote Server Administration Tools (RSAT)가 설치되어 있어야 합니다. 자세한 내용은 Windows 설명서를 참조하십시오.
클라이언트가 Samba Print Server를 신뢰할 수 있도록Enable the connection to enable clients to trust the Samba Print Server
-
AD 도메인
Administrator
사용자와 같은 그룹 정책을 편집할 수 있는 계정을 사용하여 Windows 컴퓨터에 로그인합니다. - 그룹 정책 관리 콘솔을 엽니다.
AD 도메인을 마우스 오른쪽 버튼으로 클릭하고
Create a rsh in this domain을 선택하고 여기에 Link를
선택합니다.-
legacy 프린터 드라이버 정책과
같은 grant name을 입력하고 를 클릭합니다. 새 GPO가 도메인 항목에 표시됩니다. -
새로 생성된 Group Policy Management Editor 를 마우스 오른쪽 버튼으로 클릭하고
Edit
를 선택하여 그룹 정책 관리 편집기를 엽니다. 창 오른쪽에서
Point and Print Restriction
을 두 번 클릭하여 정책을 편집합니다.정책을 활성화하고 다음 옵션을 설정합니다.
-
Users(사용자)는 이러한 서버를 가리키고 출력할 수 있으며 Samba 인쇄
서버의 FQDN(정규화된 도메인 이름)을 이 옵션 옆에 있는 필드에 입력합니다. Security Prompts
(보안 프롬프트) 아래에 있는 두 확인란 모두에서Do not show warning or elevation prompt(경고 또는 승격 프롬프트
표시 안 함)를 선택합니다.
-
- 를 클릭합니다.
Package Point and Print - Approved servers
를 두 번 클릭하여 정책을 편집합니다.- 정책을 활성화하고 (표시) 버튼을 클릭합니다.
Samba 출력 서버의 FQDN을 입력합니다.
-
Show Contents
및 policy properties 창을 모두 닫습니다. 를 클릭하여
- 그룹 정책 관리 편집기 를 닫습니다.
- 그룹 정책 관리 콘솔을 닫습니다.
Windows 도메인 멤버가 그룹 정책을 적용한 후에는 사용자가 프린터에 연결하면 Samba 서버에서 프린터 드라이버를 자동으로 다운로드합니다.
그룹 정책 사용에 대한 자세한 내용은 Windows 설명서를 참조하십시오.
16.1.7.4.5. 드라이버 및 사전 설정 프린터 업로드
Windows 클라이언트에서 인쇄 관리 애플리케이션을 사용하여 Samba 인쇄 서버에 호스팅되는 드라이버 및 사전 구성 프린터를 업로드합니다. 자세한 내용은 Windows 설명서를 참조하십시오.
16.1.8. Samba 서버의 성능 튜닝
이 섹션에서는 특정 상황에서 Samba의 성능을 향상시킬 수 있는 설정과 성능에 부정적인 영향을 미칠 수 있는 설정에 대해 설명합니다.
16.1.8.1. SMB 프로토콜 버전 설정
각 새 SMB 버전은 기능을 추가하고 프로토콜의 성능을 향상시킵니다. 최신 Windows 및 Windows Server 운영 체제는 항상 최신 프로토콜 버전을 지원합니다. Samba도 최신 프로토콜 버전을 사용하는 경우 Samba에 연결하는 Windows 클라이언트는 성능 개선을 활용합니다. Samba에서 서버 max 프로토콜
의 기본값은 지원되는 최신 SMB 프로토콜 버전으로 설정됩니다.
안정적인 최신 SMB 프로토콜 버전을 항상 활성화하려면 server max protocol
매개 변수를 설정하지 마십시오. 매개 변수를 수동으로 설정한 경우 최신 프로토콜 버전을 활성화하려면 새 버전의 SMB 프로토콜로 설정을 수정해야 합니다.
설정을 해제하려면 /etc/hiera/hiera.conf
파일의 [global]
섹션에서 server max protocol
매개 변수를 제거합니다.
16.1.8.3. 심각한 성능 영향을 미칠 수 있는 설정
기본적으로 Red Hat Enterprise Linux의 커널은 고성능 네트워크 성능을 위해 조정됩니다. 예를 들어 커널은 버퍼 크기에 자동 튜닝 메커니즘을 사용합니다. /etc/samba/smb.conf
파일에서 socket options
매개 변수를 설정하면 이러한 커널 설정이 재정의됩니다. 결과적으로 이 매개 변수를 설정하면 대부분의 경우 Samba 네트워크 성능이 저하됩니다.
커널에서 최적화된 설정을 사용하려면 /etc/samba/smb.conf
의 [global]
섹션에서 소켓 옵션
매개 변수를 제거합니다.
16.1.9. 자주 사용하는 Samba 명령줄 유틸리티
이 섹션에서는 Samba 서버를 사용할 때 자주 사용되는 명령에 대해 설명합니다.
16.1.9.1. 네트워크
유틸리티 사용
net
유틸리티를 사용하면 Samba 서버에서 여러 관리 작업을 수행할 수 있습니다. 이 섹션에서는 net
유틸리티의 가장 자주 사용되는 하위 명령을 설명합니다.
자세한 내용은 net(8) 매뉴얼 페이지를 참조하십시오.
16.1.9.1.1. net advertising join 및 net1.8.0 조인
을
사용하는 경우
net1.8.0 조인
을
net
유틸리티의 조인
하위 명령을 사용하여 Samba를 AD 또는 NT4 도메인에 연결할 수 있습니다. 도메인에 가입하려면 /etc/samba/smb.conf
파일을 수동으로 생성하고 PAM과 같은 추가 구성을 선택적으로 업데이트해야 합니다.
Red Hat은 realm
유틸리티를 사용하여 도메인에 가입하는 것이 좋습니다. realm
유틸리티는 관련된 모든 구성 파일을 자동으로 업데이트합니다. 자세한 내용은 16.1.5.1절. “도메인 가입”의 내용을 참조하십시오.
net
명령을 사용하여 도메인에 참여하려면 다음을 수행합니다.
net
명령을 사용하여 도메인 가입
다음 설정으로
/etc/samba/smb.conf
파일을 수동으로 생성합니다.AD 도메인 멤버의 경우:
[global] workgroup = domain_name security = ads passdb backend = tdbsam realm = AD_REALM
NT4 도메인 멤버의 경우:
[global] workgroup = domain_name security = user passdb backend = tdbsam
-
*
기본 도메인의 ID 매핑 구성과/etc/hiera/hiera.conf의
자세한 내용은 16.1.5.3절. “ID 매핑 이해”의 내용을 참조하십시오.[global]
섹션에 참여하려는 도메인의 ID 매핑 구성을 추가합니다. /etc/samba/smb.conf
파일을 확인합니다.~]# testparm
자세한 내용은 16.1.2절. “
testparm
utility를 사용하여 gRPC.conf
파일 확인”의 내용을 참조하십시오.도메인에 도메인 관리자로 가입합니다.
AD 도메인에 가입하려면 다음을 수행합니다.
~]# net ads join -U "DOMAINpass:quotes[administrator]"
NT4 도메인에 가입하려면 다음을 수행합니다.
~]# net rpc join -U "DOMAINpass:quotes[administrator]"
winbind 소스를
/etc/nsswitch.conf 파일의
passwd
및그룹
database 항목에 추가합니다.passwd: files winbind group: files winbind
winbind
서비스를 활성화하고 시작합니다.~]# systemctl enable winbind ~]# systemctl start winbind
선택적으로
authconf
유틸리티를 사용하여 PAM을 구성합니다.자세한 내용은 Red Hat System-Level Authentication Guide 의 Pluggable Authentication Modules (PAM) 섹션을 참조하십시오.
AD 환경에 선택적으로 Kerberos 클라이언트를 구성합니다.
자세한 내용은 Red Hat System-Level Authentication Guide 의 Kerberos Client 구성 섹션을 참조하십시오.
16.1.9.1.2. net1.8.0 rights
명령 사용
Windows에서는 공유 또는 업로드 프린터 드라이버에 ACL을 설정하는 등의 특수 작업을 수행할 수 있도록 계정과 그룹에 권한을 할당할 수 있습니다. Samba 서버에서는 net rpc rights
명령을 사용하여 권한을 관리할 수 있습니다.
권한 나열
사용 가능한 모든 권한 및 소유자를 나열하려면 net rpc rights list
명령을 사용합니다. 예를 들면 다음과 같습니다.
net rpc rights list -U "DOMAINpass:attributes[{blank}]administrator" Enter DOMAINpass:attributes[{blank}]administrator's password: SeMachineAccountPrivilege Add machines to domain SeTakeOwnershipPrivilege Take ownership of files or other objects SeBackupPrivilege Back up files and directories SeRestorePrivilege Restore files and directories SeRemoteShutdownPrivilege Force shutdown from a remote system SePrintOperatorPrivilege Manage printers SeAddUsersPrivilege Add users and groups to the domain SeDiskOperatorPrivilege Manage disk shares SeSecurityPrivilege System security
권한 부여
계정 또는 그룹에 권한을 부여하려면 net rpc rights grant
명령을 사용합니다.
예를 들어, DOMAIN\printadmin
그룹에 Se printOperatorPrivilege
권한을 부여합니다.
~]# net rpc rights grant "DOMAIN\printadmin" SePrintOperatorPrivilege \ -U "DOMAIN\administrator" Enter DOMAIN\administrator's password: Successfully granted rights.
권한 취소
계정 또는 그룹에서 권한을 취소하려면 net1.8.0 권한을
사용합니다.
예를 들어 DOMAIN\printadmin
권한을 취소하려면 다음을 수행합니다.
그룹에서 Seprint
OperatorPrivilege
~]# net rpc rights remoke "DOMAIN\printadmin" SePrintOperatorPrivilege \ -U "DOMAIN\administrator" Enter DOMAIN\administrator's password: Successfully revoked rights.
16.1.9.1.4. net user
명령 사용
net user
명령을 사용하면 AD DC 또는 NT4 PDC에서 다음 작업을 수행할 수 있습니다.
- 모든 사용자 계정 나열
- 사용자 추가
- 사용자 제거
AD 도메인용 광고
나 NT4 도메인용 rpc
와 같은 연결 방법을 지정하는 것은 도메인 사용자 계정을 나열하는 경우에만 필요합니다. 다른 사용자 관련 하위 명령은 연결 방법을 자동으로 감지할 수 있습니다.
-U user_name
매개 변수를 명령에 전달하여 요청된 작업을 수행할 수 있는 사용자를 지정합니다.
도메인 사용자 계정 나열
AD 도메인의 모든 사용자를 나열하려면 다음을 수행합니다.
~]# net ads user -U "DOMAIN\administrator"
NT4 도메인의 모든 사용자를 나열하려면 다음을 수행하십시오.
~]# net rpc user -U "DOMAIN\administrator"
도메인에 사용자 계정 추가
Samba 도메인 멤버에서 net user add
명령을 사용하여 사용자 계정을 도메인에 추가할 수 있습니다.
예를 들어 user
계정을 도메인에 추가합니다.
도메인에 사용자 계정 추가
계정을 추가합니다.
~]# net user add user password -U "DOMAIN\administrator" User user added
선택적으로, 원격 프로시저 호출(RPC) 쉘을 사용하여 AD DC 또는 NT4 PDC에서 계정을 활성화합니다. 예를 들면 다음과 같습니다.
~]# net rpc shell -U DOMAIN\administrator -S DC_or_PDC_name Talking to domain DOMAIN (S-1-5-21-1424831554-512457234-5642315751) net rpc> user edit disabled user no Set user's disabled flag from [yes] to [no] net rpc> exit
도메인에서 사용자 계정 삭제
Samba 도메인 멤버에서는 net user delete
명령을 사용하여 도메인에서 사용자 계정을 제거할 수 있습니다.
예를 들어 도메인에서 user
계정을 제거하려면 다음을 수행합니다.
~]# net user delete user -U "DOMAIN\administrator" User user deleted
16.1.9.2. RuntimeClass 클라이언트 유틸리티
사용
rpcclient
유틸리티를 사용하면 로컬 또는 원격 SMB 서버에서 클라이언트측 MS-RPC 기능을 수동으로 실행할 수 있습니다. 그러나 대부분의 기능은 Samba에서 제공하는 별도의 유틸리티로 통합됩니다. rpcclient
는 MS-PRC 함수를 테스트하는 경우에만 사용합니다.
예를 들어 유틸리티를 사용하여 다음을 수행할 수 있습니다.
프린터 스풀 하위 시스템(SPOOLSS) 관리.
예 16.9. 프린터에 드라이버 할당
~]# rpcclient server_name -U "DOMAINpass:quotes[administrator]" \ -c 'setdriver "printer_name" "driver_name"' Enter DOMAINpass:quotes[administrator]s password: Successfully set printer_name to driver driver_name.
SMB 서버에 대한 정보를 검색합니다.
예 16.10. 모든 파일 공유 및 공유 프린터 나열
~]# rpcclient server_name -U "DOMAINpass:quotes[administrator]" -c 'netshareenum' Enter DOMAINpass:quotes[administrator]s password: netname: Example_Share remark: path: C:\srv\samba\example_share\ password: netname: Example_Printer remark: path: C:\var\spool\samba\ password:
SCC(Security Account Manager Remote) 프로토콜을 사용하여 작업을 수행합니다.
예 16.11. SMB 서버에 사용자 나열
~]# rpcclient server_name -U "DOMAINpass:quotes[administrator]" -c 'enumdomusers' Enter DOMAINpass:quotes[administrator]s password: user:[user1] rid:[0x3e8] user:[user2] rid:[0x3e9]
독립 실행형 서버 또는 도메인 구성원에 대해 명령을 실행하면 로컬 데이터베이스의 사용자가 나열됩니다. AD DC 또는 NT4 PDC에 대해 명령을 실행하면 도메인 사용자가 나열됩니다.
지원되는 하위 명령의 전체 목록은 RuntimeClass client(1) 도움말 페이지의 COMMANDS 섹션을 참조하십시오.
16.1.9.3. samba-regedit
애플리케이션 사용
프린터 구성과 같은 특정 설정은 Samba 서버의 레지스트리에 저장됩니다. ncurses 기반 samba-regedit
애플리케이션을 사용하여 Samba 서버의 레지스트리를 편집할 수 있습니다.
애플리케이션을 시작하려면 다음을 입력합니다.
~]# samba-regedit
다음 키를 사용합니다.
- 커서가 이동한 후 커서가 삭제됩니다. 레지스트리 트리와 값을 탐색합니다.
- Enter: 키를 열거나 값을 편집합니다.
-
탭:
Key
(키)와Value(값
) 창 사이를 전환합니다. - Ctrl+C: 애플리케이션을 닫습니다.
16.1.9.4. xfs cacls
유틸리티 사용
16.1.9.5. KubeMacPool 클라이언트 유틸리티
사용
ClusterRole client
유틸리티를 사용하면 명령줄 FTP 클라이언트와 유사하게 SMB 서버의 파일 공유에 액세스할 수 있습니다. 예를 들어 이를 사용하여 공유에 파일을 업로드하고 다운로드할 수 있습니다.
예를 들어 DOMAIN\user
계정을 사용하여 서버에서
호스팅되는 예제
공유에 인증하려면 다음을 수행합니다.
~]# smbclient -U "DOMAIN\user" //server/example Enter domain\user's password: Domain=[SERVER] OS=[Windows 6.1] Server=[Samba 4.6.2] smb: \>
smbclient
가 공유에 성공적으로 연결되면 유틸리티는 대화형 모드로 전환되고 다음 프롬프트가 표시됩니다.
smb: \>
대화형 쉘에서 사용 가능한 모든 명령을 표시하려면 다음을 입력합니다.
smb: \> help
특정 명령에 대한 도움말을 표시하려면 다음을 입력합니다.
smb: \> help command_name
대화형 쉘에서 사용할 수 있는 명령에 대한 자세한 내용 및 설명은 tutorial client(1) 매뉴얼페이지를 참조하십시오.
16.1.9.5.1. tekton client
를 대화형 모드로 사용
smbclient
를 -c
매개 변수 없이 사용하는 경우 유틸리티는 대화형 모드로 들어갑니다.
다음 절차에서는 SMB 공유에 연결하고 하위 디렉터리에서 파일을 다운로드하는 방법을 보여줍니다.
xfs client
를 사용하여 SMB 공유에서 파일 다운로드
공유에 연결합니다.
~]# smbclient -U "DOMAINpass:quotes[user_name]" //server_name/share_name
/example/
디렉터리로 변경합니다.smb: \> cd /example/
디렉터리에 파일을 나열합니다.
smb: \example\> ls . D 0 Mon Sep 1 10:00:00 2017 .. D 0 Mon Sep 1 10:00:00 2017 example.txt N 1048576 Mon Sep 1 10:00:00 2017 9950208 blocks of size 1024. 8247144 blocks available
example.txt
파일을 다운로드합니다.smb: \example\> get example.txt getting file \directory\subdirectory\example.txt of size 1048576 as example.txt (511975,0 KiloBytes/sec) (average 170666,7 KiloBytes/sec)
공유에서 연결을 끊습니다.
smb: \example\> exit
16.1.9.5.2. 스크립트 모드에서 ClusterRoleclient
사용
-c
command 매개변수를 ClusterRole client
에 전달하면 원격 SMB 공유에서 명령을 자동으로 실행할 수 있습니다. 이를 통해 스크립트에서 smbclient
를 사용할 수 있습니다.
다음 명령은 SMB 공유에 연결하고 하위 디렉터리에서 파일을 다운로드하는 방법을 보여줍니다.
~]# smbclient -U DOMAINpass:quotes[user_name] //server_name/share_name \ -c "cd /example/ ; get example.txt ; exit"
16.1.9.6. redhat control
utility 사용
smbcontrol
유틸리티를 사용하면 smbd,
또는 모든 서비스에 명령 메시지를 보낼 수 있습니다. 이러한 제어 메시지는 서비스(예:)에서 구성을 다시 로드하도록 지시합니다.
nmbd
,winbindd
예 16.12. ClusterRoled ,nmbd
,
winbindd
서비스의 구성 다시 로드
예를 들어 ClusterRoled의 구성을 다시 로드하려면nmbd
,winbindd
, reload-config
message-type을 모든
대상으로 보냅니다.
~]# smbcontrol all reload-config
자세한 내용과 사용 가능한 명령 메시지 유형 목록은 bookinfo control (1)도움말 페이지를 참조하십시오.
16.1.9.7. redhatpasswd utility 사용
smbpasswd
유틸리티는 로컬 Samba 데이터베이스에서 사용자 계정과 암호를 관리합니다.
명령을 사용자로 실행하는 경우 사용자 의
Samba 암호가 변경됩니다. 예를 들면 다음과 같습니다.
[user@server ~]$ smbpasswd New SMB password: Retype new SMB password:
root
사용자로 smbpasswd
를 실행하는 경우 유틸리티를 사용하여 다음을 수행할 수 있습니다.
새 사용자를 생성합니다.
[root@server ~]# smbpasswd -a user_name New SMB password: Retype new SMB password: Added user user_name.
참고사용자를 Samba 데이터베이스에 추가하려면 로컬 운영 체제에서 계정을 만들어야 합니다. 보기 4.3.1절. “새 사용자 추가”
Samba 사용자를 활성화합니다.
[root@server ~]# smbpasswd -e user_name Enabled user user_name.
Samba 사용자를 비활성화합니다.
[root@server ~]# smbpasswd -x user_name Disabled user user_name.
사용자를 삭제합니다.
[root@server ~]# smbpasswd -x user_name Deleted user user_name.
자세한 내용은 gRPCpasswd(8) 매뉴얼페이지를 참조하십시오.
16.1.9.8. ClusterRole status
utility 사용
smbstatus
유틸리티는 다음에 대해 보고합니다.
-
smbd
데몬의 PID당 Samba 서버에 대한 연결. 이 보고서에는 사용자 이름, 기본 그룹, SMB 프로토콜 버전, 암호화 및 서명 정보가 포함됩니다. -
Samba 공유별 연결. 이 보고서에는
smbd
데몬의 PID, 연결 시스템의 IP, 연결이 설정된 타임스탬프, 암호화 및 서명 정보가 포함됩니다. - 잠긴 파일 목록. 보고서 항목에는 opportunistic 잠금 (oplock) 유형과 같은 추가 세부 정보가 포함됩니다.
예 16.13. ClusterRole status utility
의 출력
~]# smbstatus Samba version 4.6.2 PID Username Group Machine Protocol Version Encryption Signing ----------------------------------------------------------------------------------------------------------------------------- 963 DOMAIN\administrator DOMAIN\domain users client-pc (ipv4:192.0.2.1:57786) SMB3_02 - AES-128-CMAC Service pid Machine Connected at Encryption Signing: ------------------------------------------------------------------------------- example 969 192.0.2.1 Mo Sep 1 10:00:00 2017 CEST - AES-128-CMAC Locked files: Pid Uid DenyMode Access R/W Oplock SharePath Name Time ------------------------------------------------------------------------------------------------------------ 969 10000 DENY_WRITE 0x120089 RDONLY LEASE(RWH) /srv/samba/example file.txt Mon Sep 1 10:00:00 2017
자세한 내용은 KubeMacPool status (1)도움말 페이지를 참조하십시오.
16.1.9.9. xfs tar
유틸리티 사용
smbtar
유틸리티는 SMB 공유 또는 하위 디렉터리의 콘텐츠를 백업하고 tar
아카이브에 콘텐츠를 저장합니다. 또는 테이프 장치에 콘텐츠를 작성할 수 있습니다.
예를 들어, //server/example/
공유에 있는 demo
디렉터리의 콘텐츠를 백업하고 해당 콘텐츠를 /root/example.tar
아카이브에 저장하려면 다음을 실행합니다.
~]# smbtar -s server -x example -u user_name -p password -t /root/example.tar
자세한 내용은 tutorial tar (1)도움말 페이지를 참조하십시오.
16.1.9.10. testparm
utility 사용
16.1.9.11. wbinfo
utilities 사용
wbinfo
유틸리티는 winbindd
서비스에서 생성 및 사용하는 정보를 쿼리하고 반환합니다.
wbinfo
를 사용하려면 winbindd
서비스를 구성하고 실행해야 합니다.
예를 들어 wbinfo
를 사용하여 다음을 수행할 수 있습니다.
도메인 사용자를 나열합니다.
~]# wbinfo -u AD\administrator AD\guest ...
도메인 그룹을 나열합니다.
~]# wbinfo -g AD\domain computers AD\domain admins AD\domain users ...
사용자의 SID를 표시합니다.
~]# wbinfo --name-to-sid="AD\administrator" S-1-5-21-1762709870-351891212-3141221786-500 SID_USER (1)
도메인 및 신뢰에 대한 정보를 표시합니다.
~]# wbinfo --trusted-domains --verbose Domain Name DNS Domain Trust Type Transitive In Out BUILTIN None Yes Yes Yes server None Yes Yes Yes DOMAIN1 domain1.example.com None Yes Yes Yes DOMAIN2 domain2.example.com External No Yes Yes
자세한 내용은 wbinfo(1) 도움말 페이지를 참조하십시오.
16.1.10. 추가 리소스
Red Hat Samba 패키지에는 패키지가 설치하는 모든 Samba 명령 및 구성 파일에 대한 도움말 페이지가 포함되어 있습니다. 예를 들어 이 파일에서 설정할 수 있는 모든 구성 매개변수를 설명하는
/etc/samba/smb.conf
파일의 도움말 페이지를 표시하려면 다음을 수행합니다.~]# man 5 smb.conf
-
/usr/share/docs/samba-version/
: Samba 프로젝트에서 제공하는 일반 문서, 예제 스크립트 및 LDAP 스키마 파일을 포함합니다. - Red Hat Cluster Storage 관리 가이드: GlusterFS 볼륨에 저장된 디렉터리를 공유하도록 Samba 및 CDTB(Clustered Trivial Database)를 설정하는 방법에 대한 정보를 제공합니다.
- Red Hat Enterprise Linux High Availability Add-on Administration 가이드의 Red Hat High Availability Cluster의 활성/활성 Samba Server 는 Samba 고가용성 설치를 구성하는 방법을 설명합니다.
- Red Hat Enterprise Linux에 SMB 공유 마운트에 대한 자세한 내용은 Red Hat Storage 관리 가이드 의 해당 섹션을 참조하십시오.
16.2. FTP
FTP
( File Transfer Protocol )는 오늘날 인터넷에서 발견된 가장 오래되고 가장 일반적으로 사용되는 프로토콜 중 하나입니다. 그 목적은 사용자가 원격 호스트에 직접 로그인하거나 원격 시스템을 사용하는 방법에 대한 지식이 없어도 네트워크의 컴퓨터 호스트 간에 안정적으로 파일을 전송하는 것입니다. 사용자는 표준 간단한 명령 세트를 사용하여 원격 시스템의 파일에 액세스할 수 있습니다.
이 섹션에서는 FTP
프로토콜의 기본 설정에 대해 간단히 설명하고 Red Hat Enterprise Linux에서 권장되는 FTP
서버인 series 를 소개합니다.
16.2.1. 파일 전송 프로토콜
FTP는 클라이언트-서버 아키텍처를 사용하여 TCP
네트워크 프로토콜을 사용하여 파일을 전송합니다. FTP
는 다소 오래된 프로토콜이므로 암호화되지 않은 사용자 이름 및 암호 인증을 사용합니다. 이러한 이유로, 이는 안전하지 않은 프로토콜로 간주되며 반드시 필요한 경우를 제외하고 사용해서는 안 됩니다. 그러나 FTP
는 인터넷에서 매우 유용하기 때문에 파일을 공용으로 공유하는 데 필요한 경우가 많습니다. 따라서 시스템 관리자는 FTP
의 고유한 특성을 알고 있어야 합니다.
이 섹션에서는 TLS
가 보안한 연결을 설정하도록 SMCP를 구성하는 방법과 SELinux 의 도움말을 사용하여 FTP
서버를 보호하는 방법에 대해 설명합니다. FTP
를 올바르게 대체하는 것은 OpenSSH 도구 제품군에서 sftp 입니다. OpenSSH 구성 및 일반적인 SSH
프로토콜에 대한 자세한 내용은 12장. OpenSSH 을 참조하십시오.
인터넷에서 사용되는 대부분의 프로토콜과 달리 FTP
는 제대로 작동하기 위해 여러 네트워크 포트가 필요합니다.
클라이언트 애플리케이션이 FTP 서버에 대한 연결을 시작할 때 서버에서 포트 21을 엽니다( 명령 포트 라고도 함). 이 포트는 서버에 모든 명령을 실행하는 데 사용됩니다. 서버에서 요청한 모든 데이터는 데이터 포트를 통해 클라이언트로 반환됩니다. 데이터 연결에 대한 포트 번호 및 데이터 연결이 초기화되는 방법은 클라이언트가 활성 모드 또는 패시브 모드로 데이터를 요청하는지 여부에 따라 달라집니다.
FTP
다음은 이러한 모드를 정의합니다.
- 활성 모드
-
활성 모드는
FTP
프로토콜에서 클라이언트 애플리케이션으로 데이터를 전송하기 위해 사용하는 원래 방법입니다.FTP
클라이언트에 의해 활성 모드 데이터 전송이 시작되면 서버는 서버에서 IP 주소로 포트 20에서IP
주소로의 연결을 열고 클라이언트가 지정한 임의의 권한이 없는 포트(24개 이상)로 연결합니다. 이 배열은 클라이언트 시스템이 1024 이상의 모든 포트에서 연결을 수락할 수 있어야 함을 의미합니다. 인터넷과 같은 안전하지 않은 네트워크가 증가함에 따라 클라이언트 머신 보호용 방화벽 사용이 이제 널리 사용되고 있습니다. 이러한 클라이언트 측 방화벽은 종종 활성 모드FTP
서버에서 들어오는 연결을 거부하기 때문에 패시브 모드가 고안되었습니다. - Passive 모드
활성 모드와 같은 패시브 모드는
FTP
클라이언트 애플리케이션에 의해 시작됩니다. 서버에서 데이터를 요청할 때FTP
클라이언트는 패시브 모드에서 데이터에 액세스하기를 원하는 것을 나타내며 서버는 서버에서IP
주소와 권한이 없는 임의의 포트 (greater than 1024)를 제공합니다. 그런 다음 클라이언트는 서버의 해당 포트에 연결하여 요청된 정보를 다운로드합니다.패시브 모드는 데이터 연결과의 클라이언트 측 방화벽 간섭에 대한 문제를 해결하지만 서버 측 방화벽의 관리를 어렵게 관리할 수 있습니다.
FTP
서버에서 권한이 없는 포트 범위를 제한하여 서버에서 열려 있는 포트 수를 줄일 수 있습니다. 이를 통해 서버에 대한 방화벽 규칙 설정 프로세스도 간소화됩니다.
16.2.2. vsftpd 서버
Very Secure FTP Daemon (keepalived )은 처음부터 빠르고 안정적이며, 가장 중요한 것은 안전한 것으로 설계됩니다. AWS는 Red Hat Enterprise Linux와 함께 배포되는 유일한 독립형 FTP
서버이며, 이는 많은 수의 연결을 효율적이고 안전하게 처리할 수 있기 때문입니다.
vsftpd
에서 사용하는 보안 모델에는 다음 세 가지 주요 요소가 있습니다.
- 권한 있는 및 권한이 없는 프로세스를 강력하게 분리 - 프로세스 분리는 서로 다른 작업을 처리하고 이러한 각 프로세스는 작업에 필요한 최소한의 권한으로 실행됩니다.
-
높은 권한이 필요한 작업은 필요한 최소한의 권한을 가진 프로세스에서 처리됩니다.
libcap
라이브러리에서 발견되는 compatibilities를 활용함으로써 전체 루트 권한이 필요한 작업을 보다 안전하게 실행할 수 있습니다. -
대부분의 프로세스는
chroot
environment - 가능한 경우 프로세스가 공유 중인 디렉터리로 변경-루트가 됩니다. 이 디렉터리는chroot
environment로 간주됩니다. 예를 들어/var/ftp/
디렉터리가 기본 공유 디렉터리인 경우 SMCP는/var/ftp/
를/
라고 하는 새 루트 디렉터리에 다시 할당합니다.이렇게 하면 새 루트 디렉토리에 포함되지 않은 디렉터리에 대한 잠재적인 악의적인 해커 활동을 허용하지 않습니다.
이러한 보안 관행을 사용하는 것은 SMCP가 요청을 처리하는 방식에 다음과 같은 영향을 미칩니다.
-
상위 프로세스는 필요한 최소한의 권한으로 실행됩니다. 상위 프로세스는 위험 수준을 최소화하기 위해 필요한 권한 수준을 동적으로 계산합니다. 하위 프로세스는
FTP
클라이언트와 직접 상호 작용을 처리하고 가능한 한 권한 없이 를 실행합니다. -
상위 권한이 필요한 모든 작업은 소규모 상위 프로세스에서 처리합니다. - Apache
HTTP
Server 와 마찬가지로 Much는 들어오는 연결을 처리하기 위해 권한이 없는 하위 프로세스를 시작합니다.이를 통해 권한 있는 상위 프로세스가 가능한 한 작게 되고 비교적 적은 작업을 처리할 수 있습니다.
- 권한이 없는 하위 프로세스의 모든 요청은 상위 프로세스에 의해 신뢰되지 않습니다 - 하위 프로세스와의 통신은 소켓을 통해 수신되고, 하위 프로세스의 모든 정보의 유효성이 작업을 수행하기 전에 확인됩니다.
-
chroot
환경의 권한이 없는 하위 프로세스에서FTP
클라이언트와의 대부분의 상호 작용 은 권한이 없으며 공유 중인 디렉터리에만 액세스할 수 있기 때문에 충돌된 프로세스는 공격자가 공유 파일에 대한 액세스 권한만 허용합니다.
16.2.2.1. 시작 및 중지 member
현재 세션에서
SMCP 서비스를 시작하려면 쉘 프롬프트에 root
로 다음을 입력합니다.
~]# systemctl start vsftpd.service
현재 세션에서 서비스를 중지하려면 root
로 다음을 입력합니다.
~]# systemctl stop vsftpd.service
member 서비스를 다시
시작하려면 root
로 다음 명령을 실행합니다.
~]# systemctl restart vsftpd.service
이 명령은 iLO 서비스를 중지하고 즉시 시작합니다. 이 서비스는 이 FTP
서버의 구성 파일을 편집한 후 구성 변경을 수행하는 가장 효율적인 방법입니다. 또는 다음 명령을 사용하여 이미 실행 중인 경우에만
SMCP
서비스를 다시 시작할 수 있습니다.
~]# systemctl try-restart vsftpd.service
기본적으로 member 서비스는
부팅 시 자동으로 시작되지 않습니다. 부팅 시 시작되도록 member 서비스를 구성하려면 root
로 쉘 프롬프트에 다음을 입력합니다.
~]# systemctl enable vsftpd.service Created symlink from /etc/systemd/system/multi-user.target.wants/vsftpd.service to /usr/lib/systemd/system/vsftpd.service.
Red Hat Enterprise Linux 7에서 시스템 서비스를 관리하는 방법에 대한 자세한 내용은 10장. systemd를 사용하여 서비스 관리 를 참조하십시오.
16.2.2.2. 이름이 여러 개의 Copie를 시작
한 컴퓨터가 여러 FTP
도메인을 제공하는 데 사용되는 경우가 있습니다. 이 기술은 Multihoming 이라고 합니다. SMCP를 사용하여 다중 홈을 사용하는
한 가지 방법은 각각 자체 구성 파일을 사용하여 데몬의 여러 사본을 실행하는 것입니다.
이렇게 하려면 먼저 시스템의 네트워크 장치 또는 별칭 네트워크 장치에 모든 관련 IP
주소를 할당합니다. 네트워크 장치, 장치 별칭 및 네트워크 구성 스크립트에 대한 추가 정보를 구성하는 방법에 대한 자세한 내용은 Red Hat Enterprise Linux 7 네트워킹 가이드 를 참조하십시오.
다음으로 FTP
도메인의 DNS 서버는 올바른 시스템을 참조하도록 구성해야 합니다. BIND 에 대한 자세한 내용은 Red Hat Enterprise Linux에서 사용되는 DNS
프로토콜 구현 및 구성 파일을 보려면 Red Hat Enterprise Linux 7 네트워킹 가이드 를 참조하십시오.
member 가
서로 다른 IP
주소의 요청에 응답하려면 데몬의 여러 사본이 실행 중이어야 합니다.
데몬의 여러 인스턴스를 쉽게 시작할 수 있도록 인스턴스화된 서비스를 시작하기 위한 특수 systemd 서비스 단위(666vsftpd
@.service
)가 NetNamespace 패키지에 제공됩니다.
이 서비스 유닛을 사용하려면 FTP
서버의 필요한 각 인스턴스에 대해 별도의 vsftpd
구성 파일을 생성하여 /etc/htpasswd/
디렉터리에 배치해야 합니다. 이러한 각 설정 파일은 고유한 이름(예: /etc/htpasswd/octets-site-2.conf
)을 사용해야 하며 root
사용자만 읽고 쓸 수 있어야 합니다.
IPv4
네트워크에서 수신 대기하는 각 FTP
서버에 대한 각 구성 파일 내에서 다음 지시문이 고유해야 합니다.
listen_address=N.N.N.N
N.N.N 을 제공되는 FTP
사이트의 고유한 IP
주소로 바꿉니다. 사이트에서 IPv6
을 사용하는 경우 대신 listen_address6
지시문을 사용합니다.
/etc/tekton/
디렉토리에 여러 구성 파일이 있는 경우, root
로 다음 명령을 실행하여 RuntimeClass 데몬의 개별 인스턴스를 시작할 수 있습니다.
~]# systemctl start vsftpd@configuration-file-name.service
위의 명령에서 configuration-file-name 을 요구되는 서버 구성 파일의 고유 이름으로, (예:666 -site-2)
로 바꿉니다. 구성 파일의 .conf
확장자는 명령에 포함되어서는 안 됩니다.
engine 데몬의 여러 인스턴스를 한 번에 시작하려는 경우 RuntimeClass 패키지에 제공된 systemd 대상 단위 파일(True.target
)을 사용할 수 있습니다. 이 systemd 대상은
/etc/tekton/ 디렉토리에 있는 사용 가능한 각
시작하게 됩니다. 다음 명령을 vsftpd
구성 파일에 대해 독립 vsftpd
데몬을root
로 실행하여 대상을 활성화합니다.
~]# systemctl enable vsftpd.target Created symlink from /etc/systemd/system/multi-user.target.wants/vsftpd.target to /usr/lib/systemd/system/vsftpd.target.
위의 명령은 부팅 시 구성된 RuntimeClass 서버 인스턴스(구성된
서버 인스턴스와 함께)를 시작하도록 systemd 서비스 관리자를 구성합니다. 시스템을 재부팅하지 않고 즉시 서비스를 시작하려면 vsftpd
root
로 다음 명령을 실행합니다.
~]# systemctl start vsftpd.target
systemd 대상을 사용하여 서비스 관리에 대한 자세한 내용은 10.3절. “systemd 대상 작업” 를 참조하십시오.
서버 단위로 변경하는 것을 고려해야 하는 기타 지시문은 다음과 같습니다.
-
anon_root
-
local_root
-
vsftpd_log_file
-
xferlog_file
16.2.2.3. TLS를 사용하여 rootfs 연결 암호화
기본적으로 사용자 이름, 암호, 데이터 없이 암호화 없이 데이터를 전송하는 FTP
의 본질적으로 안전하지 않은 특성을 대응하기 위해 SMCP 데몬을 구성하여 연결을 인증하고 모든 전송을 암호화할 수 있습니다.
TLS
가 활성화된 TLS와 통신하려면 TLS
를 지원하는 FTP
클라이언트가 필요합니다.
SSL
(Secure Sockets Layer)은 이전 보안 프로토콜 구현의 이름입니다. 새 버전은 TLS
(Transport Layer Security)라고 합니다. SSL
로 인해 심각한 보안 취약점이 발생하므로 최신 버전(TLS
)만 사용해야 합니다. ssl_enable
지시문이 YES
로 설정되어 있을 때 기본적으로 TLS
가 지원되고 있는 경우 vsftpd.conf
파일에 사용된 구성 지시문과 함께 SSL
이름을 사용하는 문서도 포함되어 있습니다.
TLS
지원을 사용하도록 ssl_enable
구성 지시문의 vsftpd.conf
파일을 YES
로 설정합니다. ssl_enable
옵션이 활성화된 경우 적절하게 구성된 TLS
설정에 대해 제공되는 기타 TLS
- 관련 지시문의 기본 설정입니다. 여기에는 모든 연결에 TLS
v1 프로토콜만 사용해야 하거나( insecure SSL
프로토콜 버전 사용은 기본적으로 비활성화되어 있음) 암호 및 데이터 전송에 TLS
를 사용하기 위해 모든 비익명 로그인을 사용하도록 강제하는 것이 포함됩니다.
예 16.14. TLS를 사용하도록 rootfs 구성
이 예에서 구성 지시문에서는 vsftpd.conf
파일에서 이전 SSL
버전의 보안 프로토콜을 명시적으로 비활성화합니다.
ssl_enable=YES ssl_tlsv1=YES ssl_sslv2=NO ssl_sslv3=NO
설정을 수정한 후 SMCP 서비스를 다시 시작합니다.
~]# systemctl restart vsftpd.service
iLO에서 TLS사용을 세부 조정하려면 다른
(5) 매뉴얼 페이지를 참조하십시오. TLS
- 관련 구성 지시문의 경우 SMCP.conf
16.2.2.4. SMCP의 SELinux 정책
iLO 데몬(다른 ftpd
프로세스)을 관리하는 SELinux 정책은 필수 액세스 제어(기본적으로 최소 액세스 권한을 기반으로 함)를 정의합니다.
FTP
데몬이 특정 파일 또는 디렉터리에 액세스할 수 있도록 하려면 적절한 레이블을 할당해야 합니다.
예를 들어 익명으로 파일을 공유하려면 공개_content_t
레이블을 공유할 파일과 디렉토리에 할당해야 합니다. chcon
명령을 root
로 사용하여 이 작업을 수행할 수 있습니다.
~]# chcon -R -t public_content_t /path/to/directory
위의 명령에서 /path/to/directory 를 레이블을 할당하려는 디렉터리의 경로로 바꿉니다. 마찬가지로 파일 업로드 디렉터리를 설정하려면 해당 특정 디렉터리에 public_content_rw_t
레이블을 할당해야 합니다. 그 외에도 allow_ftpd_anon_write
SELinux 부울 옵션을 1
로 설정해야 합니다. setsebool
명령을 root
로 사용하여 다음을 수행합니다.
~]# setsebool -P allow_ftpd_anon_write=1
로컬 사용자가 Red Hat Enterprise Linux 7의 기본 설정인 FTP
를 통해 홈 디렉토리에 액세스할 수 있도록 하려면 ftp_home_dir
부울 옵션을 1
로 설정해야 합니다. enterprise
가 Red Hat Enterprise Linux 7에서 기본적으로 활성화되어 있는 독립형 모드에서 실행되도록 허용된 경우 ftpd_is_daemon
옵션도 1
로 설정해야 합니다.
FTP
와 관련된 SELinux 정책을 구성하는 방법에 대한 다른 유용한 레이블 및 부울 옵션의 예를 포함하여 자세한 내용은 ftpd_selinux(8) 매뉴얼 페이지를 참조하십시오. 또한 일반적으로 SELinux에 대한 자세한 내용은 Red Hat Enterprise Linux 7 SELinux 사용자 및 관리자 가이드 를 참조하십시오.
16.2.3. 추가 리소스
SMCP에 대한 자세한 내용은 다음 리소스를 참조하십시오.
16.2.3.1. 설치된 문서
-
/usr/share/doc/htpasswd-version-number/
directory - version-number 가 설치된 버전의 member 패키지로 교체 됩니다. 이 디렉터리에는 소프트웨어에 대한 기본 정보가 포함된README
파일이 포함되어 있습니다.TUNING
파일에는 기본 성능 튜닝 팁이 포함되어 있으며SEC/
디렉터리에는vsftpd
에서 사용하는 보안 모델에 대한 정보가 포함되어 있습니다. RuntimeClass
- 관련 도움말 페이지 - 데몬과 구성 파일에 대한 여러 도움말 페이지가 있습니다. 다음은 몇 가지 중요한 매뉴얼 페이지를 나열합니다.- 서버 애플리케이션
{blank}
-
RuntimeClass(8) - vsftpd에 사용할 수 있는 명령줄 옵션에 대해 설명합니다.
-
RuntimeClass(8) - vsftpd에 사용할 수 있는 명령줄 옵션에 대해 설명합니다.
- 구성 파일
{blank}
-
vsftpd.conf
(5) - SMCP의 구성 파일 내에서 사용할 수 있는 자세한 옵션 목록이 포함되어 있습니다. -
hosts_access(5) -
TCP
래퍼 구성 파일인hosts.allow
및hosts.deny
에서 사용할 수 있는 형식과 옵션에 대해 설명합니다.
-
- SELinux와의 상호 작용
{blank}
-
ftpd_selinux(8) -
ftpd
프로세스를 관리하는 SELinux 정책과 SELinux 레이블을 할당하는 방법에 대한 설명 및 부울 설정 방법에 대한 설명이 포함되어 있습니다.
-
ftpd_selinux(8) -
16.2.3.2. 온라인 문서
- General의 vsftpd 및 FTP 정보
{blank}
-
http://vsftpd.beasts.org/ -
vsftpd
프로젝트 페이지는 최신 문서를 찾고 소프트웨어 작성자에게 연락할 수 있는 좋은 위치입니다. -
http://slacksite.com/other/ftp.html - 이 웹 사이트는 활성 모드 FTP와 수동 모드
FTP
의 차이점에 대한 간결한 설명을 제공합니다.
-
http://vsftpd.beasts.org/ -
- Red Hat Enterprise Linux 문서
{blank}
-
Red Hat Enterprise Linux 7 네트워킹 가이드 - 이 시스템의 네트워크 인터페이스, 네트워크 및 네트워크 서비스의 구성 및 관리와 관련된 Red Hat Enterprise Linux 7의 네트워킹 가이드.
hostnamectl
유틸리티를 소개하고 이를 사용하여 로컬 및 원격으로 명령줄에서 호스트 이름을 보고 설정하는 방법을 설명합니다. -
Red Hat Enterprise Linux 7 SELinux 사용자 및 관리자 가이드 - Red Hat Enterprise Linux 7 의 SELinux 사용자 및 관리자 안내서는 SELinux 및 문서의 기본 원칙을 설명합니다. Apache HTTP Server, Postgres , PostgreSQL 또는 OpenShift 와 같은 다양한 서비스로 SELinux 를 구성하고 사용하는 방법에 대해 자세히 설명합니다.
systemd
에서 관리하는 시스템 서비스에 대한 SELinux 액세스 권한을 구성하는 방법에 대해 설명합니다. - Red Hat Enterprise Linux 7 보안 가이드 - Red Hat Enterprise Linux 7의 보안 가이드는 로컬 및 원격 침입, 악용 및 악의적인 활동을 위해 워크스테이션 및 서버를 보호하는 프로세스와 관행을 학습하는 데 도움이 됩니다. 또한 중요한 시스템 서비스를 보호하는 방법도 설명합니다.
-
Red Hat Enterprise Linux 7 네트워킹 가이드 - 이 시스템의 네트워크 인터페이스, 네트워크 및 네트워크 서비스의 구성 및 관리와 관련된 Red Hat Enterprise Linux 7의 네트워킹 가이드.
- 관련 RFC 문서
{blank}
16.3. 설정 인쇄
인쇄 설정 도구는 프린터 구성, 프린터 구성 파일의 유지 관리, 스풀 디렉터리 및 출력 필터, 프린터 클래스 관리를 위한 기능을 제공합니다.
이 도구는 Common Unix Printing System (CUPS)을 기반으로 합니다. CUPS를 사용한 이전 Red Hat Enterprise Linux 버전에서 시스템을 업그레이드한 경우 업그레이드 프로세스에서 구성된 프린터를 보존했습니다.
cupsd.conf
man 페이지 페이지 CUPS 서버의 구성 여기에는 SSL
지원을 활성화하기 위한 지시문이 포함되어 있습니다. 그러나 CUPS는 사용된 프로토콜 버전을 제어할 수 없습니다. POODLE SSLv3.0 취약점 (CVE-2014-3566)에 대해 해결된 취약점으로 인해 구성 설정을 통해 SSLv3를 비활성화하지 않도록 허용하는 구성 요소의 경우 Red Hat은 보안을 위해 이에 의존하지 않는 것이 좋습니다. 보안 터널을 제공하고 SSLv3
을 비활성화하려면 stunnel 을 사용하는 것이 좋습니다. stunnel 사용에 대한 자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드 를 참조하십시오.
원격 시스템의 인쇄 설정 도구에 대한 임시 보안 연결의 경우 12.4.1절. “X11 전달” 에 설명된 대로 SSH
를 통해 X11 전달을 사용하십시오.
CUPS 웹 애플리케이션 또는 명령줄에서 직접 프린터에서 동일한 추가 작업을 수행할 수 있습니다. 애플리케이션에 액세스하려면 웹 브라우저에서 http://localhost:631/ 로 이동합니다. CUPS 설명서의 경우 웹 사이트의 홈
탭에 있는 링크를 참조하십시오.
16.3.1. 인쇄 설정 구성 도구 시작
인쇄 설정 도구를 사용하면 기존 프린터에서 다양한 작업을 수행하고 새 프린터를 설정할 수 있습니다. CUPS를 직접 사용할 수도 있습니다( http://localhost:631/ 로 이동하여 CUPS 웹 애플리케이션에 액세스).
명령줄에서 인쇄 설정 도구를 시작하려면 쉘 프롬프트에서 system-config-os
tree를 입력합니다. 인쇄 설정 도구가 나타납니다. 또는 GNOME 데스크탑을 사용하는 경우 Super 키를 눌러 activities Overview를 입력하고 Print Settings
을 입력한 다음 Enter 를 누릅니다. 인쇄 설정 도구가 나타납니다. Super 키는 키보드와 기타 하드웨어에 따라 다양한 길잡이에 표시되지만 일반적으로 스페이스바 왼쪽에 있는 Windows 또는 Command 키로 나타납니다.
그림 16.1. “설정 창 인쇄” 에 표시된 인쇄 설정
창이 표시됩니다.
그림 16.1. 설정 창 인쇄
16.3.2. printer 설정 시작
프린터 설정 프로세스는 프린터 대기열 유형에 따라 다릅니다.
USB와 연결된 로컬 프린터를 설정하는 경우 프린터가 자동으로 검색되고 추가됩니다. 패키지를 설치할지 확인하고 관리자 또는 root
사용자 암호를 입력하라는 메시지가 표시됩니다. 다른 포트 유형 및 네트워크 프린터와 연결된 로컬 프린터를 수동으로 설정해야 합니다.
수동 프린터 설정을 시작하려면 다음 절차를 따르십시오.
- 인쇄 설정 도구를 시작합니다( 16.3.1절. “인쇄 설정 구성 도구 시작”참조).
- → → 이동합니다.
-
Authenticate
대화 상자에서 관리자 또는root
사용자 암호를 입력합니다. 원격 프린터를 처음 구성하는 경우 방화벽에 대한 조정 권한을 부여하라는 메시지가 표시됩니다. - 프린터 연결 유형을 선택하고 오른쪽에 있는 영역에 세부 정보를 제공합니다.
16.3.3. 로컬 프린터 추가
직렬 포트 이외의 것과 연결된 로컬 프린터를 추가하려면 다음 절차를 따르십시오.
-
추가
프린터 대화 상자를 엽니다( 16.3.2절. “printer 설정 시작”참조). -
장치가 자동으로 나타나지 않으면 왼쪽 목록에 프린터가 연결된 포트 (예:
Serial Port #1
또는LPT #1
)를 선택합니다. 오른쪽에 연결 속성을 입력합니다.On the right, enter the connection properties:
기타
의 경우-
URI
(예: file:/dev/lp0) 직렬 포트
의 경우baud Rate
패리티
데이터 비트
흐름 제어
그림 16.2. 로컬 프린터 추가
- 를 클릭합니다.
- 프린터 모델을 선택합니다. 자세한 내용은 16.3.8절. “프린터 모델 및 완료 선택” 을 참조하십시오.
16.3.4. AppSocket/HPSOURCEDirect 프린터 추가
AppSocket/HP젯Direct 프린터를 추가하려면 다음 절차를 따르십시오.
-
새 프린터
대화 상자를 엽니다( 16.3.1절. “인쇄 설정 구성 도구 시작”참조). - 왼쪽 목록에서 → 를 선택합니다.
오른쪽에서 연결 설정을 입력합니다.
호스트 이름
-
프린터 호스트 이름 또는
IP
주소 포트 번호
인쇄 작업을 수신 대기하는 프린터 포트(기본적으로
9100
)입니다.그림 16.3. pcsDirect 프린터 추가
- 를 클릭합니다.
- 프린터 모델을 선택합니다. 자세한 내용은 16.3.8절. “프린터 모델 및 완료 선택” 을 참조하십시오.
16.3.5. IPP printer 추가
IPP
프린터는 동일한 TCP/IP 네트워크의 다른 시스템에 연결된 프린터입니다. 이 프린터가 연결된 시스템은 CUPS를 실행하거나 IPP
를 사용하도록 구성할 수 있습니다.
프린터 서버에서 방화벽이 활성화된 경우 포트 631
에서 들어오는 TCP
연결을 허용하도록 방화벽을 구성해야 합니다. CUPS 검색 프로토콜을 사용하면 클라이언트 시스템이 공유 CUPS 대기열을 자동으로 검색할 수 있습니다. 이를 활성화하려면 클라이언트 시스템의 방화벽이 포트 631
에서 들어오는 UDP
패킷을 허용하도록 구성해야 합니다.
IPP
프린터를 추가하려면 다음 절차를 따르십시오.
-
새 프린터
대화 상자를 엽니다( 16.3.2절. “printer 설정 시작”참조). -
왼쪽의 장치 목록에서 네트워크 프린터 및
인터넷 인쇄 프로토콜(ipp) 또는
을 선택합니다.인터넷 인쇄
프로토콜(https) 오른쪽에서 연결 설정을 입력합니다.
host
-
IPP
프린터의 호스트 이름입니다. queue
새 큐에 할당할 큐 이름입니다( 박스가 비어 있으면 장치 노드를 기반으로 한 이름이 사용됩니다).
그림 16.4. IPP 프린터 추가
- 계속하려면 를 클릭합니다.
- 프린터 모델을 선택합니다. 자세한 내용은 16.3.8절. “프린터 모델 및 완료 선택” 을 참조하십시오.
16.3.6. LPD/LPR 호스트 또는 프린터 추가
LPD/LPR 호스트 또는 프린터를 추가하려면 다음 절차를 따르십시오.
-
새 프린터
대화 상자를 엽니다( 16.3.2절. “printer 설정 시작”참조). - 왼쪽의 장치 목록에서 → 를 선택합니다.
오른쪽에서 연결 설정을 입력합니다.
host
LPD/LPR 프린터 또는 호스트의 호스트 이름입니다.
선택적으로
를 클릭하여 LPD 호스트에서 대기열을 찾습니다.queue
새 큐에 할당할 큐 이름입니다( 박스가 비어 있으면 장치 노드를 기반으로 한 이름이 사용됩니다).
그림 16.5. LPD/LPR 프린터 추가
- 계속하려면 를 클릭합니다.
- 프린터 모델을 선택합니다. 자세한 내용은 16.3.8절. “프린터 모델 및 완료 선택” 을 참조하십시오.
16.3.7. Samba (SMB) 프린터 추가
Samba 프린터를 추가하려면 다음 절차를 따르십시오.
Samba 프린터를 추가하려면 samba-client 패키지가 설치되어 있어야 합니다. root
로 다음을 실행하여 수행할 수 있습니다.
yum install samba-client
YUM을 사용하여 패키지 설치에 대한 자세한 내용은 9.2.4절. “패키지 설치” 을 참조하십시오.
-
새 프린터
대화 상자를 엽니다( 16.3.2절. “printer 설정 시작”참조). - 왼쪽 목록에서 SamBA를 .
KubeMacPool
://
필드에 SMB 주소를 입력합니다. 컴퓨터 이름/소유 공유 포맷을 사용합니다. 그림 16.6. “SMB 프린터 추가” 에서 컴퓨터 이름은dellbox
이며 프린터 공유는r2
입니다.그림 16.6. SMB 프린터 추가
- 를 클릭하여 사용 가능한 작업 그룹/도메인을 확인합니다. 특정 호스트의 대기열만 표시하려면 호스트 이름(NetBios 이름)을 입력하고 를 클릭합니다.
옵션 중 하나를 선택합니다.
-
인증이 필요한지 묻는
프롬프트 사용자 : 문서를 인쇄할 때 사용자 이름 및 암호가 사용자에게 수집됩니다. -
지금 인증 세부 정보 설정
: 지금 인증 정보를 제공하므로 나중에 필요하지 않습니다.Username
필드에 프린터에 액세스할 사용자 이름을 입력합니다. 이 사용자는 SMB 시스템에 있어야 하며 사용자는 프린터에 액세스할 수 있는 권한이 있어야 합니다. 기본 사용자 이름은 일반적으로 Windows서버용 게스트
또는 Samba 서버의 경우nobody
입니다.
-
Username
필드에 지정된 사용자에 대해암호
(필요한 경우)를 입력합니다.주의Samba 프린터 사용자 이름과 암호는
루트
및 Linux Printing Daemon,lpd
에서 읽을 수 있는 암호화되지 않은 파일로 프린터 서버에 저장됩니다. 따라서 프린터 서버에 대한루트
액세스 권한이 있는 다른 사용자는 Samba 프린터에 액세스하는 데 사용하는 사용자 이름과 암호를 볼 수 있습니다.따라서 Samba 프린터에 액세스하기 위해 사용자 이름과 암호를 선택할 때는 로컬 Red Hat Enterprise Linux 시스템에 액세스하는 데 사용하는 암호와 다른 암호를 선택하는 것이 좋습니다.
Samba 출력 서버에서 공유되는 파일이 있는 경우 출력 대기열에서 사용하는 것과 다른 암호를 사용하는 것이 좋습니다.
- 을 클릭하여 연결을 테스트합니다. 확인에 성공하면 프린터 공유 접근성을 확인하는 대화 상자가 나타납니다.
- 를 클릭합니다.
- 프린터 모델을 선택합니다. 자세한 내용은 16.3.8절. “프린터 모델 및 완료 선택” 을 참조하십시오.
16.3.8. 프린터 모델 및 완료 선택
프린터 연결 유형을 올바르게 선택했으면 시스템에서 드라이버를 가져오려고 합니다. 프로세스가 실패하면 드라이버 리소스를 수동으로 검색하거나 검색할 수 있습니다.
프린터 드라이버를 제공하고 설치를 완료하려면 다음 절차를 따르십시오.
자동 드라이버 감지 실패 후 표시되는 창에서 다음 옵션 중 하나를 선택합니다.
-
데이터베이스에서 print를 선택합니다
. - 시스템은Makes
목록에서 프린터의 선택한크에 따라 드라이버를 선택합니다. 프린터 모델이 나열되지 않은 경우일반
을 선택합니다. -
PPD 파일 제공
- 시스템은 설치에 제공된 PPD (PPD) 파일을 사용합니다. PPD 파일은 제조업체가 일반적으로 제공하는 것처럼 프린터와 함께 제공될 수도 있습니다. PPD 파일을 사용할 수 있는 경우 이 옵션을 선택하고 옵션 설명 아래에 브라우저 표시줄을 사용하여 PPD 파일을 선택할 수 있습니다. 다운로드할 프린터 드라이버를 검색
-Make 및 model 필드에 프린터의 제조업체와 모델을
입력하여 Openprinting.org에서 적절한 패키지를 검색합니다.그림 16.7. 프린터 브랜드 선택
-
이전 선택에 따라 아래 표시된 영역의 세부 정보를 제공합니다.
-
데이터베이스 선택 옵션에서 프린터 선택
옵션. -
Provide PPD 파일 옵션의 PPD 파일
위치입니다. -
프린터 메이크업 및 모델 -
프린터 드라이버 검색 옵션을 다운로드합니다
.
-
- 계속하려면 를 클릭합니다.
옵션에 적용 가능한 경우 그림 16.8. “프린터 모델 선택” 에 표시된 창이 표시됩니다. 왼쪽의 모델 열에서
해당
모델을 선택합니다.참고오른쪽에는 권장 프린터 드라이버가 자동으로 선택되지만 사용 가능한 다른 드라이버를 선택할 수 있습니다. 인쇄 드라이버는 프린터로 인쇄할 데이터를 이해할 수 있는 형식으로 처리합니다. 로컬 프린터가 컴퓨터에 직접 연결되어 있으므로 프린터로 전송되는 데이터를 처리하기 위해서는 프린터 드라이버가 있어야 합니다.
그림 16.8. 프린터 모델 선택
- 를 클릭합니다.
Describe printer
아래에서 printer이름
필드에 프린터의 고유 이름을 입력합니다. 프린터 이름에는 문자, 숫자, 대시(-) 및 밑줄( )을 포함할 수 있습니다. 공백을 포함해서는안 됩니다. 또한Description
및Location
필드를 사용하여 프린터 정보를 추가할 수도 있습니다. 두 필드 모두 선택 사항이며 공백을 포함할 수 있습니다.그림 16.9. 프린터 설정
- 클릭하여 프린터 구성을 확인하고 설정이 올바르면 출력 대기열을 추가합니다. (전환)을 클릭하여 프린터 구성을 수정합니다.
- 변경 사항이 적용되면 테스트 페이지를 인쇄할 수 있는 대화 상자가 나타납니다. 이제 16.3.9절. “테스트 페이지 인쇄” 에 설명된 대로 나중에 테스트 페이지를 출력할 수 있습니다. 클릭하여 테스트 페이지를 인쇄합니다. 또는
16.3.9. 테스트 페이지 인쇄
프린터를 설정하거나 프린터 구성을 변경한 후 테스트 페이지를 인쇄하여 프린터가 제대로 작동하는지 확인합니다.
-
인쇄
창에서 프린터를 마우스 오른쪽 버튼으로 클릭하고속성
을 클릭합니다. -
속성 창에서 왼쪽에서 설정을 클릭합니다.In the Properties window, click
Settings
on the left. -
표시된
설정
탭에서 버튼을 클릭합니다.
16.3.10. 기존 프린터 수정
기존 프린터를 삭제하려면 인쇄 설정
창에서 프린터를 선택하고 print 로 이동합니다. 프린터 삭제를 확인합니다. 또는 Delete 키를 누릅니다.
기본 프린터를 설정하려면 프린터 목록에서 프린터를 마우스 오른쪽 버튼으로 클릭하고 컨텍스트 메뉴에서 Set as Default
버튼을 클릭합니다.
16.3.10.1. 설정 페이지
프린터 드라이버 구성을 변경하려면 printer 목록에서 해당 이름을 두 번 클릭하고 왼쪽의 Settings
레이블을 클릭하여 설정
페이지를 표시합니다.
make 및 model과 같은 프린터 설정을 수정하고, 테스트 페이지를 출력하고, 장치 위치(URI) 등을 변경할 수 있습니다.
그림 16.10. 설정 페이지
16.3.10.2. 정책 페이지
왼쪽의 Policies
버튼을 클릭하여 프린터 상태로 설정을 변경하고 출력을 인쇄합니다.
프린터 상태를 선택하고 프린터의 오류 정책을
구성 (프린터 작업을 중단, 재시도 또는 오류가 발생하면 중지 할 수 있습니다).
배너 페이지 (예: 원래 프린터와 같은 인쇄 작업의 측면, 작업이 시작된 사용자의 이름, 출력되는 문서의 보안 상태)를 설명하는 페이지 : Starting Banner
또는 Ending Banner
드롭다운 메뉴를 클릭하고 인쇄 작업의 특성을 가장 잘 설명하는 옵션을 선택할 수 있습니다.
16.3.10.2.1. 프린터 공유
정책
페이지에서 프린터를 공유로 표시할 수 있습니다. 프린터가 공유되면 네트워크에 게시된 사용자가 이를 사용할 수 있습니다. 프린터의 공유 기능을 허용하려면 → 으로 이동하여 이 시스템에 연결된 공유 프린터 게시
를 선택합니다.
그림 16.11. 정책 페이지
방화벽이 포트 631
에 대한 수신 TCP
연결을 허용하는지 확인합니다. 네트워크 인쇄 서버(IPP) 프로토콜의 포트입니다. Red Hat Enterprise Linux 7에서 방화벽을 통한
IPP
트래픽을 허용하려면 firewalld
의IPP
서비스를 사용하십시오. 이렇게 하려면 다음과 같이 진행하십시오.
firewalld에서 IPP 서비스 활성화
그래픽 firewall-config 도구를 시작하려면 Super 키를 눌러 활동 개요를 입력하고
방화벽
을 입력한 다음 Enter 를 누릅니다.방화벽 구성
창이 열립니다. 관리자 또는루트
암호를 입력하라는 메시지가 표시됩니다.또는 명령줄을 사용하여 그래픽 방화벽 구성 도구를 시작하려면
root
사용자로 다음 명령을 입력합니다.~]# firewall-config
방화벽 구성
창이 열립니다.왼쪽 아래에 있는 "연결됨"이라는 단어를 찾습니다. 이는 firewall-config 도구가 사용자 공간 데몬인
firewalld
에 연결되었음을 나타냅니다.현재 방화벽 설정을 즉시 변경하려면
Configuration
(구성)이라는 드롭다운 선택 메뉴가런타임
으로 설정되어 있는지 확인합니다. 또는 다음 시스템 시작 시 적용할 설정을 편집하려면 드롭다운 목록에서Permanent
를 선택합니다.-
Zones
탭을 선택한 다음 사용할 네트워크 인터페이스에 해당하는 방화벽 영역을 선택합니다. 기본값은공용
영역입니다.Interfaces
(인터페이스) 탭에는 영역에 할당된 인터페이스가 표시됩니다. -
서비스
탭을 선택한 다음 공유를 활성화할ipp 서비스를 선택합니다. 네트워크 프린터에 액세스하는 데
ipp-client
서비스가 필요합니다. - firewall-config 도구를 닫습니다.
firewalld
에서 포트 열기 및 닫기에 대한 자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드 를 참조하십시오.
16.3.10.2.2. 액세스 제어 페이지
액세스 제어
페이지에서 구성된 프린터에 대한 사용자 수준 액세스를 변경할 수 있습니다. 왼쪽의 Access Control
(액세스 제어) 레이블을 클릭하여 페이지를 표시합니다. 이러한 사용자를 제외한 모든 사용자에 대해
허용을 선택하고 아래에 사용자 설정을 정의합니다. 텍스트 상자에 사용자 이름을 입력하고 .
인쇄 허용
또는 이러한 사용자를 제외한 모든 사용자에 대해 인쇄
그림 16.12. 액세스 제어 페이지
16.3.10.2.3. 프린터 옵션 페이지
프린터 옵션
페이지에는 프린터 미디어 및 출력에 대한 다양한 구성 옵션이 포함되어 있으며 해당 콘텐츠는 프린터마다 다를 수 있습니다. 여기에는 일반 인쇄, 문서, 품질 및 인쇄 크기 설정이 포함되어 있습니다.
그림 16.13. 프린터 옵션 페이지
16.3.10.2.4. 작업 옵션 페이지
Job Options
페이지에서 프린터 작업 옵션을 자세히 설명할 수 있습니다. 왼쪽의 Job Options
(작업 옵션) 레이블을 클릭하여 페이지를 표시합니다. 기본 설정을 편집하여 사본, 오리엔테이션, 페이지 수, 양측별 페이지 수, 스케일링(프린트 인쇄 영역의 크기 증가 또는 감소), 더 작은 물리적인 인쇄 영역에 맞게 사용할 수 있는 사용자 지정 작업 옵션, 자세한 텍스트 옵션 및 사용자 지정 작업 옵션을 적용합니다.
그림 16.14. 작업 옵션 페이지
16.3.10.2.5. Ink/Toner Levels 페이지
Ink/Toner Levels
페이지에는 사용 가능 및 프린터 상태 메시지가 있는 경우 토너 상태에 대한 세부 정보가 포함되어 있습니다. 왼쪽의 Ink/Toner Levels
레이블을 클릭하여 페이지를 표시합니다.
그림 16.15. Ink/Toner Levels 페이지
16.3.10.3. 출력 작업 관리
SMT에서 텍스트 파일을 인쇄하거나 GIMP 에서 이미지를 인쇄하는 등 인쇄 작업을 프린터 데몬으로 보내면 인쇄 작업이 출력 스풀 큐에 추가됩니다. 인쇄 스풀 대기열은 프린터로 전송된 출력 작업 목록과 각 출력 요청에 대한 정보(예: 요청 상태, 작업 번호 등)입니다.
인쇄 프로세스 중에 프린터 상태
아이콘이 패널의 알림 영역에 나타납니다. 출력 작업의 상태를 확인하려면 그림 16.16. “GNOME 인쇄 상태” 과 유사한 창을 표시하는 프린터 상태
을 클릭합니다.
그림 16.16. GNOME 인쇄 상태
출력 작업을 취소, 보류, 릴리스, 재프린트하거나 인증하려면 GNOME Print Status (GNOME 인쇄 상태)에서 작업을 선택하고 작업 메뉴에서 해당 명령을 클릭합니다.
쉘 프롬프트에서 출력 spool의 출력 작업 목록을 보려면 lpstat -o
명령을 입력합니다. 마지막 몇 줄은 다음과 유사합니다.
예 16.15. lpstat -o
출력 예
$ lpstat -o
Charlie-60 twaugh 1024 Tue 08 Feb 2011 16:42:11 GMT
Aaron-61 twaugh 1024 Tue 08 Feb 2011 16:42:44 GMT
Ben-62 root 1024 Tue 08 Feb 2011 16:45:42 GMT
출력 작업을 취소하려면 lpstat -o
명령을 사용하여 요청의 작업 번호를 찾은 다음 명령 cancel 작업 번호를
사용합니다. 예를 들어 cancel 60
은 예 16.15. “lpstat -o
출력 예” 에서 출력 작업을 취소합니다. cancel 명령을 사용하여 다른 사용자가 시작한 인쇄 작업을 취소할
수 없습니다. 그러나 cancel -U root job_number
명령을 실행하여 이러한 작업을 삭제할 수 있습니다. 이러한 취소를 방지하려면 프린터 작업 정책을 인증하여
인증을 강제 적용합니다.
root
쉘 프롬프트에서 직접 파일을 출력할 수도 있습니다. 예를 들어 lp sample.txt
명령은 텍스트 파일 sample.txt
를 출력합니다. print 필터는 해당 파일의 유형을 결정하고 프린터가 이해할 수 있는 형식으로 변환합니다.
16.3.11. 추가 리소스
Red Hat Enterprise Linux의 인쇄에 대한 자세한 내용은 다음 리소스를 참조하십시오.
설치된 문서
-
LP(1)
- 명령줄에서 파일을 출력할 수 있는lp
명령의 도움말 페이지. -
LPR(1)
- 명령줄에서 파일을 출력할 수 있는lpr
명령의 수동 페이지. -
cancel(1)
- 출력 대기열에서 출력 작업을 제거할 명령줄 유틸리티의 도움말 페이지입니다. -
mpage(1)
- 한시판에 여러 페이지를 인쇄하는 명령줄 유틸리티의 도움말 페이지입니다. -
cupsd(8)
- CUPS 프린터 데몬의 도움말 페이지. -
cupsd.conf(5)
- CUPS 프린터 데몬 구성 파일의 수동 페이지. -
classes.conf(5)
- CUPS의 클래스 구성 파일의 도움말 페이지. -
lpstat(1)
-lpstat
명령의 수동 페이지. 이 명령은 클래스, 작업 및 프린터에 대한 상태 정보를 표시합니다.
온라인 문서
- http://www.linuxprinting.org/ - Linux Foundation 웹 사이트의 Openprinting 그룹에는 Linux에서 인쇄에 대한 많은 정보가 포함되어 있습니다.
- http://www.cups.org/ - CUPS 웹 사이트에서 CUPS에 대한 문서, FAQ 및 뉴스 그룹을 제공합니다.
17장. 데이터베이스 서버
이 장에서는 MySQL 기술을 기반으로 하는 빠르고 강력한 오픈 소스 데이터베이스 서버인 MariaDB 서버의 설치 및 구성을 안내합니다. 이 장에서는 MariaDB 데이터를 백업하는 방법도 설명합니다.
17.1. MariaDB
MariaDB 는 데이터를 구조화된 정보로 변환하고 데이터에 액세스하기 위한 SQL 인터페이스를 제공하는 관계형 데이터베이스입니다. 여기에는 여러 스토리지 엔진 및 플러그인뿐만 아니라 지리적 정보 시스템(GIS)이 포함됩니다.
Red Hat Enterprise Linux 7에는 MySQL 데이터베이스 제품군의 서버 기본 구현으로 MariaDB 5.5 가 포함되어 있습니다. 이후 버전의 MariaDB 데이터베이스 서버는 Red Hat Enterprise Linux 6 및 Red Hat Enterprise Linux 7의 Software Collections로 제공됩니다. 최신 버전에 대한 자세한 내용은 Red Hat Software Collections의 릴리스 정보를 참조하십시오.
17.1.1. MariaDB 서버 설치
MariaDB 서버를 설치하려면 다음 절차를 따르십시오.
MariaDB 서버 설치
mariadb 및 mariadb-server 패키지가 필수 서버에 설치되어 있는지 확인합니다.
~]# yum install mariadb mariadb-server
mariadb
서비스를 시작합니다.~]# systemctl start mariadb.service
부팅 시 시작되도록
mariadb
서비스를 활성화합니다.~]# systemctl enable mariadb.service
17.1.1.1. MariaDB 설치 보안 개선
mysql_secure_installation
명령을 실행하여 MariaDB 서버를 설치할 때 보안을 개선할 수 있습니다.
~]# mysql_secure_installation
이 명령은 완전히 대화형 스크립트를 시작하여 프로세스의 각 단계를 표시합니다. 스크립트를 사용하면 다음과 같은 방법으로 보안을 강화할 수 있습니다.
- root 계정의 암호 설정
- 익명 사용자 제거
- 원격(로컬 호스트 외부) 루트 로그인 금지
- 테스트 데이터베이스 제거
17.1.2. 네트워킹을 위한 MariaDB 서버 구성
네트워킹에 대한 MariaDB 서버를 구성하려면 /etc/my.cnf.d/server.cnf
파일의 [mysqld]
섹션을 사용합니다. 여기서 다음 구성 지시문을 설정할 수 있습니다.
bind-address
bind-address는 서버가 수신 대기할 주소입니다.
가능한 옵션은 호스트 이름, IPv4 주소 또는 IPv6 주소입니다.
skip-networking
가능한 값은 다음과 같습니다.
0 - 모든 클라이언트 수신 대기
1 - 로컬 클라이언트만 수신 대기
port
MariaDB 가 TCP/IP 연결을 수신 대기하는 포트입니다.
17.1.3. MariaDB 데이터 백업
MariaDB 데이터베이스에서 데이터를 백업하는 방법은 다음 두 가지가 있습니다.
- 논리적 백업
- 물리적 백업
17.1.3.1. 논리적 백업
논리적 백업은 데이터를 복원하는 데 필요한 SQL 문으로 구성됩니다. 이러한 유형의 백업은 일반 텍스트 파일로 정보와 레코드를 내보냅니다.
물리적 백업보다 논리적 백업의 주요 장점은 이식성과 유연성입니다. 물리적 백업에서는 사용할 수 없는 다른 하드웨어 구성, MariaDB 버전 또는 DBMS(데이터베이스 관리 시스템)에서 데이터를 복원할 수 있습니다.
논리적 백업은 mariadb.service
가 실행 중인 경우에만 수행할 수 있습니다. 논리적 백업에는 로그 및 구성 파일이 포함되지 않습니다.
17.1.3.2. 물리적 백업
물리적 백업은 콘텐츠를 저장하는 파일 및 디렉터리의 사본으로 구성됩니다.
물리적 백업은 논리적 백업과 비교하여 다음과 같은 이점이 있습니다.
- 출력이 더 작습니다.
- 백업은 크기가 작습니다.
- 백업 및 복원 속도가 빨라집니다.
- 백업에는 로그 및 구성 파일이 포함됩니다.
mariadb.service가 실행되지 않거나 백업 중에 변경되지 않도록 데이터베이스의 모든 테이블이 잠길 때 물리적 백업을 수행해야 합니다.
18장. chrony Suite를 사용하여 NTP 설정
IT의 여러 이유로 정확한 시간 유지가 중요합니다. 예를 들어 네트워킹에서는 패킷 및 로그의 정확한 타임스탬프가 필요합니다. Linux 시스템에서 NTP
프로토콜은 사용자 공간으로 실행되는 데몬에 의해 구현됩니다.
사용자 공간 데몬은 커널에서 실행되는 시스템 클럭을 업데이트합니다. 시스템 클럭은 다양한 클럭 소스를 사용하여 시간을 유지할 수 있습니다. 일반적으로TSC( Time Stamp TSC )가 사용됩니다. TSC는 마지막 재설정 이후 사이클 수를 계산하는 CPU 레지스터입니다. 매우 빠르고 높은 해상도가 있으며 중단이 없습니다.
데몬 ntpd
와 chronyd
는 각각 ntp 및 chrony 패키지의 리포지토리에서 사용할 수 있습니다.
이 장에서는 chrony 제품군 사용에 대해 설명합니다.
18.1. chrony Suite 소개
Chrony 는 NTP(Network Time Protocol) 구현입니다. Chrony 를 사용할 수 있습니다.
-
시스템 클럭을
NTP
서버와 동기화하려면 - 시스템 클럭을 참조 클럭과 동기화하기 위해, 예를 들면 GPS 수신기,
- 시스템 시계를 수동 시간 입력과 동기화하려면
-
NTPv4(RFC 5905)
서버 또는 피어로서 네트워크의 다른 컴퓨터에 시간 서비스를 제공합니다.
chrony는 간헐적인 네트워크 연결, 과도한 정체된 네트워크, 온도 변경(또는 기존 컴퓨터 클럭이 온도에 민감함) 및 가상 머신에서 실행되지 않는 시스템을 포함한 다양한 조건에서 잘 작동합니다.
인터넷을 통해 동기화된 두 시스템 간의 일반적인 정확도는 몇 밀리초 내에 있으며 10초 이내에 LAN의 경우 입니다. 하드웨어 타임스탬프 또는 하드웨어 참조 클럭은 마이크로초 수준에 동기화된 두 시스템 간의 정확도를 향상시킬 수 있습니다.
chrony 는 사용자 공간으로 실행되는 데몬인 chronyd
, chronyc, chronyd
의 성능을 모니터링하고 실행 시 다양한 운영 매개 변수를 변경하는 데 사용할 수 있는 명령행 프로그램으로 구성됩니다.
18.1.1. ntpd와 chronyd의 차이점
chronyd
가 ntpd
보다 더 나은 작업을 수행할 수 있습니다.
-
chronyd
는 시간 참조에 대한 액세스가 간헐적인 환경에서 제대로 작동할 수 있지만ntpd
는 제대로 작동하기 위해 시간 참조를 정기적으로 폴링해야 합니다. -
네트워크가 더 긴 기간 동안 혼잡한 경우에도
chronyd
가 제대로 작동할 수 있습니다. -
chronyd
는 일반적으로 클럭을 더 빠르고 더 나은 정확도와 동기화할 수 있습니다. -
chronyd
는rystal oscillator의 온도 변화와 같이 시계 속도의 급격한 변화에 빠르게 적응하는 반면,ntpd
는 다시 다운로드하는 데 오랜 시간이 필요할 수 있습니다. -
기본 구성에서 clock이 다른 실행 프로그램을 활성화하지 않도록 시스템 시작 시 동기화된 후
chronyd
를 수행하지 않습니다.ntpd
는 시간을 너무 단계를 거치지 않도록 구성할 수 있지만 클럭의 정확도에 부정적인 영향을 미치는 시계를 조정하는 다른 수단을 사용해야 합니다. -
chronyd
는 더 큰 범위에서 Linux 시스템에서 클럭 속도를 조정할 수 있으므로 손상되거나 불안정한 시계가 있는 시스템에서도 작동할 수 있습니다. 예를 들어 일부 가상 시스템에서 다음을 수행합니다. -
chronyd
는 크기가 작아서 메모리를 적게 사용하고 필요한 경우에만 CPU를 켜고 절전이 더 좋습니다.
chronyd
가 수행할 수 있는 작업은 ntpd
에서 수행할 수 없습니다.
-
chronyd
는 시간 수정 방법이 수동 입력인 격리된 네트워크에 대한 지원을 제공합니다. 예를 들어, 관리자가 시계를 보면 문제를 해결할 수 있습니다.chronyd
는 다른 업데이트에서 수정된 오류를 검사하여 컴퓨터가 시간 증가 또는 손실 속도를 추정하고 이 추정치를 사용하여 나중에 컴퓨터 시계를 조정할 수 있습니다. -
chronyd
는 컴퓨터가 꺼진 시간을 유지 관리하는 클럭과 같이 실시간 클럭의 속도 또는 손실 속도를 파악하는 기능을 제공합니다. 이 데이터를 사용하면 시스템이 실시간 클럭에서 가져온 수정된 시간 값을 사용하여 시스템 시간을 설정할 때 이 데이터를 사용할 수 있습니다. 이러한 실시간 시계 기능은 현재 Linux 시스템에서만 사용할 수 있습니다. -
chronyd
는 로컬 네트워크에서 매우 정확한 동기화를 허용하는 Linux에서 하드웨어 타임스탬프를 지원합니다.
ntpd
는 chronyd
가 할 수 없는 작업을 수행할 수 있습니다.
-
ntpd
는 브로드캐스트, 멀티 캐스트 및 많은 캐스트 클라이언트 및 서버를 포함하여NTP
버전 4(RFC 5905)의 모든 작동 모드를 지원합니다. 브로드캐스트 및 멀티캐스트 모드는 인증을 사용하더라도 본질적으로 덜 정확하고 일반 서버 및 클라이언트 모드보다 안전하지 않으며 일반적으로 피해야 합니다. -
ntpd
는 공용 키 암호화로 서버를 인증하기 위해 Autokey 프로토콜(RFC 5906)을 지원합니다. 이 프로토콜은 안전하지 않은 것으로 입증되었으며NTS(Network Time Security) 사양의 구현으로 대체될 수 있습니다. -
ntpd
에는 많은 참조 시계에 대한 드라이버가 포함되어 있지만chronyd
는 다른 프로그램(예: gpsd )을 사용하여 공유 메모리(SHM) 또는 Unix domain socket(SOCK)을 사용하여 데이터에 액세스합니다.
18.1.2. NTP 데몬 간 선택
chrony 는 chrony를 지원하지 않는 툴에서 관리하거나 모니터링하는 시스템을 제외한 모든 시스템 또는 chrony와 함께 사용할 수 없는 하드웨어 참조 시계가 있는 시스템을 제외하고 모든 시스템에서 우선적으로 사용해야 합니다.
Autokey
프로토콜을 사용하여 패킷 인증을 수행하는 데 필요한 시스템은 chronyd
가 이 프로토콜을 지원하지 않기 때문에 ntpd
에서만 사용할 수 있습니다. Autokey
프로토콜에는 심각한 보안 문제가 있으므로 이 프로토콜을 사용하는 것은 피해야 합니다. Autokey
대신 chronyd
와 ntpd
둘 다에서 지원하는 대칭 키의 인증을 사용합니다. Chrony 는 SHA256 및 SHA512와 같은 더 강력한 해시 기능을 지원하지만 ntpd
는 MD5 및 SHA1만 사용할 수 있습니다.
18.2. chrony 및 구성 이해
18.2.1. chronyd 및 chronyc 이해
chrony 데몬인 chronyd
는 명령행 유틸리티 chronyc 에서 모니터링하고 제어할 수 있습니다. 이 유틸리티는 여러 명령을 입력하여 chronyd
의 현재 상태를 쿼리하고 해당 구성을 변경할 수 있는 명령 프롬프트를 제공합니다. 기본적으로 chronyd
는 chronyc 의 로컬 인스턴스의 명령만 허용하지만 원격 호스트에서 모니터링 명령도 허용하도록 구성할 수 있습니다. 원격 액세스는 제한되어야 합니다.
18.2.2. chrony 설정 명령 이해
chronyd
의 기본 구성 파일은 /etc/chrony.conf
입니다. f 옵션을
사용하여 대체 구성 파일 경로를 지정할 수 있습니다. 추가 옵션은 chronyd
도움말 페이지를 참조하십시오.
다음은 chronyd
구성 옵션의 선택 사항입니다.
- comments
- 주석 앞에 #, %, ; 또는 !
- allow
-
필요한 경우
NTP
서버 역할을 하는 시스템에 대한NTP
연결을 허용하는 호스트, 서브넷 또는 네트워크를 지정합니다. 기본값은 연결을 허용하지 않습니다.
예 18.1. 허용
옵션을 사용하여 액세스 권한 부여:
IPv4에 대한 액세스 권한을 부여하려면 이 명령을 사용합니다.
allow 192.0.2.0/24
IPv6에 대한 액세스 권한을 부여하려면 이 명령을 사용합니다.
allow 2001:0db8:85a3::8a2e:0370:7334
클라이언트 액세스를 허용하려면 UDP 포트 번호 123을 방화벽에 열어야 합니다.
~]# firewall-cmd --zone=public --add-port=123/udp
123 포트를 영구적으로 열려면 --permanent
옵션을 사용하십시오.
~]# firewall-cmd --permanent --zone=public --add-port=123/udp
- cmdallow
-
이는 특정 서브넷 또는 호스트에 대한 액세스를 제어할 수 있다는 점을 제외하고
allow
(컨트롤 액세스(control access)"는 해당 호스트에서 chronyc 를 실행하고 이 컴퓨터의
chronyd
에 성공적으로 연결할 수 있음을 의미합니다.) 구문은 동일합니다. 또한cmddeny all
지시문과 유사한 동작이 있는모든 지시문이
있습니다. - dumpdir
-
chronyd
를 다시 시작할 때 측정 기록을 저장할 디렉터리의 경로입니다(실행 중이 아닌 경우 시스템 클럭 동작이 변경되지 않음) 이 기능을 사용할 경우(구성 파일에서dumponexit
명령 또는 chronyc의dump
명령을 통해) 측정 항목이 저장되는 디렉터리를 정의하는 데dumpdir
명령을 사용해야 합니다. - dumponexit
-
이 명령이 있는 경우
chronyd
가 프로그램이 종료될 때마다 기록된 각 시간 소스에 대한 측정 기록을 저장해야 함을 나타냅니다. (위의dumpdir
명령을 참조하십시오. - hwtimestamp
-
hwtimestamp
지시문을 사용하면 매우 정확한 동기화를 위해 하드웨어 타임스탬프를 사용할 수 있습니다. 자세한 내용은chrony.conf(5)
매뉴얼 페이지를 참조하십시오. - 지역
local
키워드는 현재 동기화 소스가 없는 경우에도chronyd
가 클라이언트의 관점에서 실시간으로 동기화되도록 허용하는 데 사용됩니다. 이 옵션은 일반적으로 격리된 네트워크의 "마스터" 컴퓨터에서 사용되며, 이 경우 여러 컴퓨터를 서로 동기화해야 하며 "마스터"는 수동 입력을 통해 실시간으로 유지됩니다.명령의 예는 다음과 같습니다.
local stratum 10
10의 큰 값은 시간이 신뢰할 수 없다는 참조 클럭에서 너무 많은 홉이 있음을 나타냅니다. 컴퓨터가 궁극적으로 참조 클럭에 동기화되는 다른 컴퓨터에 액세스할 수 있는 경우 10보다 작은 계층에 있을 것입니다. 따라서
로컬
명령에 대해 10과 같은 높은 값을 선택하면 머신의 시간이 실시간으로 혼동되지 않도록 할 수 있으며 실제 서버를 파악할 수 있는 클라이언트에는 유출되지 않았습니다.- log
log
명령은 특정 정보가 기록될 것임을 나타냅니다. 다음 옵션을 허용합니다.- 측정
-
이 옵션은 원시
NTP
측정 및 metrics.log라는 파일에 관련 정보를 기록합니다.
- statistics
-
이 옵션은
statistics.log
라는 파일에 대한 회귀 처리 정보를 기록합니다. - tracking
-
이 옵션은 시스템의 이득 또는 손실율의 추정치와 changes를
tracking.log
라는 파일에 기록합니다. - rtc
- 이 옵션은 시스템의 실시간 시계에 대한 정보를 기록합니다.
- refclocks
-
이 옵션은
refclocks.log
라는 파일에 원시 및 필터링된 참조 클럭 측정을 기록합니다. - tempcomp
이 옵션은
tempcomp.log
라는 파일에 온도 측정 및 시스템 속도 가격을 기록합니다.로그 파일은
logdir
명령으로 지정된 디렉터리에 작성됩니다.명령의 예는 다음과 같습니다.
log measurements statistics tracking
- LOGDIR
이 지시문을 사용하면 로그 파일을 지정할 디렉터리를 지정할 수 있습니다.
이 지시문을 사용하는 예는 다음과 같습니다.
logdir /var/log/chrony
- 설정
일반적으로
chronyd
는 필요에 따라 클럭을 늦추거나 속도를 늦추어 시스템이 시간 오프셋을 점차적으로 수정하도록 합니다. 특정 상황에서는 시스템 시계가 너무 멀리 떨어져서 이 슬라이싱 프로세스가 시스템 시계를 수정하는 데 매우 오랜 시간이 걸릴 수 있습니다. 이 지시어는 조정이 임계값보다 큰 경우chronyd
가 시스템 클럭을 차지하지만chronyd
가 지정된 제한보다 시작되었기 때문에 클럭 업데이트가 더 이상 없는 경우에만 수행합니다(제한을 비활성화하는 데 음수 값을 사용할 수 있음).initstepslew
지시문은NTP
소스에서만 작동하기 때문에 참조 클럭을 사용할 때 특히 유용합니다.이 지시문을 사용하는 예는 다음과 같습니다.
makestep 1000 10
이 경우 조정이 1000초보다 크고 처음 10개 시계 업데이트에서만 시스템 클럭이 수행됩니다.
- maxchange
이 지시문은 클럭 업데이트 시 수정된 최대 오프셋을 설정합니다. 시스템 시계의 대규모 초기 조정을 허용하기 위해 지정된 수의 업데이트 횟수가 지정된 후에만 검사가 수행됩니다. 지정된 최대값보다 큰 오프셋이 발생하면 지정된 횟수에 대해 무시되고
chronyd
가 포기하고 종료됩니다(종료에 음수 값을 사용할 수 없음). 두 경우 모두 메시지가 syslog로 전송됩니다.이 지시문을 사용하는 예는 다음과 같습니다.
maxchange 1000 1 2
첫 번째 클럭 업데이트 후
chronyd
는 모든 클럭 업데이트에서 오프셋을 확인한 후 1000초보다 큰 두 가지 조정 사항을 무시하고 다른 업데이트를 종료합니다.- maxupdateskew
chronyd
의 작업 중 하나는 참조 소스에 대해 컴퓨터 클럭이 얼마나 빠르게 실행되는지 또는 속도가 느려지는 작업을 수행하는 것입니다. 또한 예상 값에 바인딩된 오류의 추정치를 계산합니다.오류 범위가 너무 크면 측정이 아직 해결되지 않았으며 추정된 이득 또는 손실 비율은 매우 신뢰할 수 없음을 나타냅니다.
maxupdateskew
매개변수는 추정치가 너무 신뢰할 수 있는지 여부를 결정하는 임계값입니다. 기본적으로 임계값은 1000 ppm입니다.구문의 형식은 다음과 같습니다.
maxupdateskew skew-in-ppm
skew-in-ppm 에 대한 일반적인 값은 전화선을 통해 서버에 전화 접속 연결 시 100개, LAN상의 컴퓨터에 대해 5 또는 10일 수 있습니다.
이것은 신뢰할 수 없는 추정치를 사용하는 것을 방지할 수 있는 유일한 수단이 아닙니다. 항상
chronyd
는 예상 얻을 또는 손실 비율과 추정치에 바인딩된 오류를 추적합니다. 소스 중 하나에서 다른 측정에 따라 새 추정치가 생성되면 가중치화된 조합 알고리즘이 마스터 추정을 업데이트하는 데 사용됩니다.chronyd
에 신뢰할 수 있는 기존의 마스터 추정치가 있고 큰 오류가 있는 새 추정치가 생성되는 경우 기존 마스터 추정은 새 마스터 추정에서 제외됩니다.- minsources
minsources
지시문은 로컬 클럭이 업데이트되기 전에 소스 선택 알고리즘에서 선택 가능한 것으로 간주해야 하는 최소 소스 수를 설정합니다.구문의 형식은 다음과 같습니다.
minsources number-of-sources
기본적으로 소스 수는 1입니다. minsources를 더 큰 수로 설정하면 여러 소스가 서로 일치해야 하므로 안정성을 향상시킬 수 있습니다.
- noclientlog
- 인수를 사용하지 않는 이 지시문은 클라이언트 액세스가 기록되지 않도록 지정합니다. 일반적으로 로깅되어 chronyc 에서 clients 명령을 사용하여 통계를 보고할 수 있습니다.
- reselectdist
chronyd
가 사용 가능한 소스에서 동기화 소스를 선택하면 최소 동기화 거리가 있는 동기화가 우선합니다. 그러나 비슷한 거리가 있는 소스가 있을 때 자주 재선택되지 않도록 하려면 현재 선택되지 않은 소스의 거리에 고정 거리가 추가됩니다. 이 설정은reselectdist
옵션을 사용하여 설정할 수 있습니다. 기본적으로 거리는 100 마이크로초입니다.구문의 형식은 다음과 같습니다.
reselectdist dist-in-seconds
- stratumweight
stratumweight
지시문은chronyd
가 사용 가능한 소스에서 동기화 소스를 선택할 때 stratum당 최대 거리를 동기화 거리에 추가합니다.구문의 형식은 다음과 같습니다.
stratumweight dist-in-seconds
기본적으로 dist-in-seconds 는 1밀리초입니다. 즉, 더 낮은 계층에 있는 소스가 일반적으로 거리가 훨씬 더 나빠질 때에도 더 높은 계층에 있는 소스보다 우선합니다.
stratumweight
를 0으로 설정하면 소스를 선택할 때chronyd
가 stratum을 무시합니다.- rtcfile
rtcfile
지시문은chronyd
가 시스템의 실시간 클럭(RTC)의 정확성을 추적하는 데 관련된 매개 변수를 저장할 수 있는 파일의 이름을 정의합니다.구문의 형식은 다음과 같습니다.
rtcfile /var/lib/chrony/rtc
chronyd
는 종료 시 및writertc
명령이 chronyc 에서 발급될 때 이 파일에 정보를 저장합니다. 저장된 정보는 일부 epoch에서 RTC의 오류, 즉 epoch (3년 1월 1일 이후) 및 RTC가 시간을 늘리거나 손실하는 속도입니다. 코드에 따라 시스템에 따라 모든 실시간 시계가 지원되는 것은 아닙니다. 이 지시문을 사용하는 경우 임의 간격으로 조정된 경우 실시간 클럭 드리프트가 실시간 클럭 드리프트를 조정하는 속도를 측정해야 하므로 실시간 클럭 드리프트를 수동으로 조정할 수 없습니다.- rtcsync
-
rtcsync
지시문은 기본적으로/etc/chrony.conf
파일에 있습니다. 이렇게 하면 커널에서 시스템 클럭이 동기화되고 커널이 11분마다 실시간 클럭을 업데이트합니다.
18.2.3. chronyc를 통한 보안
Chronyc 는 다음 두 가지 방법으로 chronyd
에 액세스할 수 있습니다.
- 인터넷 프로토콜(IPv4 또는 IPv6)
-
UNIX 도메인 소켓 -
루트
또는 chrony 사용자가 로컬로 액세스할 수 있습니다.
기본적으로 chronyc 는 Unix 도메인 소켓에 연결됩니다. 기본 경로는 /var/run/chrony/chronyd.sock
입니다. 이 연결에 실패하면 예를 들어 chronyc 가 루트가 아닌 사용자에서 실행되는 경우 chronyc 는 127.0.0.1에 연결을 시도한 다음 ::1을 시도합니다.
chronyd
의 동작에 영향을 미치지 않는 다음 모니터링 명령만 네트워크에서 허용됩니다.
- activity
- 수동 목록
- rtcdata
- smoothing
- 소스
- sourcestats
- tracking
- waitsync
chronyd
가 이러한 명령을 허용하는 호스트 세트는 chronyd
의 설정 파일에서 cmdallow
지시문 또는 chronyc 의 cmdallow
명령을 사용하여 구성할 수 있습니다. 기본적으로 이 명령은 localhost(127.0.0.1 또는 ::1)에서만 사용할 수 있습니다.
다른 모든 명령은 Unix 도메인 소켓을 통해서만 허용됩니다. 네트워크를 통해 전송되면 chronyd
는 localhost에서 가져온 경우에도 Not authorized
error로 응답합니다.
chronyc를 사용하여 chronyd에 원격으로 액세스
/etc/chrony.conf
파일에 다음을 추가하여 IPv4 및 IPv6 주소 모두에서 액세스를 허용합니다.bindcmdaddress 0.0.0.0
또는
bindcmdaddress :
cmdallow
지시문을 사용하여 원격 IP 주소, 네트워크 또는 서브넷의 명령을 허용합니다./etc/chrony.conf
파일에 다음 내용을 추가합니다.cmdallow 192.168.1.0/24
방화벽에서 포트 323을 열어 원격 시스템에서 연결합니다.
~]# firewall-cmd --zone=public --add-port=323/udp
포트 323을 영구적으로 읽으려면
--permanent
를 사용하십시오.~]# firewall-cmd --permanent --zone=public --add-port=323/udp
allow
지시문은 NTP
액세스를 위한 반면, cmdallow
지시문은 원격 명령을 수신할 수 있도록 하는 것입니다. chronyc 를 로컬로 실행하여 일시적으로 이러한 변경을 수행할 수 있습니다. 구성 파일을 편집하여 영구적으로 변경합니다.
18.3. chrony 사용
18.3.1. chrony 설치
chrony 제품군은 기본적으로 일부 Red Hat Enterprise Linux 7 버전에 설치됩니다. 필요한 경우 root
로 다음 명령을 실행합니다.
~]# yum install chrony
chrony 데몬의 기본 위치는 /usr/sbin/chronyd
입니다. 명령행 유틸리티는 /usr/bin/chronyc
에 설치됩니다.
18.3.2. chronyd 상태 확인
chronyd
의 상태를 확인하려면 다음 명령을 실행합니다.
~]$ systemctl status chronyd
chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled)
Active: active (running) since Wed 2013-06-12 22:23:16 CEST; 11h ago
18.3.3. chronyd 시작
chronyd
를 시작하려면 root
로 다음 명령을 실행합니다.
~]# systemctl start chronyd
시스템을 시작할 때 chronyd
가 자동으로 시작되도록 하려면 root
로 다음 명령을 실행합니다.
~]# systemctl enable chronyd
18.3.4. chronyd 중지
chronyd
를 중지하려면 root
로 다음 명령을 실행합니다.
~]# systemctl stop chronyd
시스템 시작 시 chronyd
가 자동으로 시작되지 않도록 하려면 root
로 다음 명령을 실행합니다.
~]# systemctl disable chronyd
18.3.5. chrony가 Synchronized인지 확인
chrony 가 동기화되었는지 확인하려면 추적
, 소스, sourcestats
명령을 사용하십시오.
18.3.5.1. chrony 추적 확인
chrony 추적을 확인하려면 다음 명령을 실행합니다.
~]$ chronyc tracking
Reference ID : CB00710F (foo.example.net)
Stratum : 3
Ref time (UTC) : Fri Jan 27 09:49:17 2017
System time : 0.000006523 seconds slow of NTP time
Last offset : -0.000006747 seconds
RMS offset : 0.000035822 seconds
Frequency : 3.225 ppm slow
Residual freq : 0.000 ppm
Skew : 0.129 ppm
Root delay : 0.013639022 seconds
Root dispersion : 0.001100737 seconds
Update interval : 64.2 seconds
Leap status : Normal
필드는 다음과 같습니다.
- 참조 ID
-
이는 사용 가능한 경우 참조 ID 및 이름(또는
IP
주소)이며, 컴퓨터에서 현재 동기화된 서버의 이름입니다. 참조 ID는 IPv4 주소와 혼동하지 않도록 16진수입니다. - stratum
- stratum은 연결된 참조 시계가 있는 컴퓨터에서 홉을 얼마나 많이 떨어져 있는지를 나타냅니다. 이러한 컴퓨터는 stratum-1 컴퓨터이므로 예제의 컴퓨터는 두 홉 떨어져 있습니다 (즉, a.b.c는 stratum-2이고 stratum-1에서 동기화됨).
- ref time
- 이는 참조 소스의 마지막 측정이 처리된 시간(UTC)입니다.
- 시스템 시간
-
정규 작업에서는 timescale의 모든 이동이 특정 애플리케이션 프로그램에 부정적인 결과를 초래할 수 있기 때문에
chronyd
가 시스템 클럭을 단계하지 않습니다. 대신, 시스템 시계의 모든 오류는 오류가 제거 될 때까지 시스템 시계를 약간 속도를 늦추거나 느려서 시스템 시계의 정상적인 속도로 반환하여 수정됩니다. 이로 인해 시스템 클럭 (gettimeofday()
시스템 호출을 사용하여 다른 프로그램에서 읽는 것처럼)이 있거나 쉘의 date 명령에 따라chronyd
가 현재 true 시간(서버 모드에서 작동할 때NTP
클라이언트에 보고됨)과 다른 기간이 있을 것입니다. 이 줄에 보고되는 값은 이 효과 때문에 차이가 있습니다. - 마지막 오프셋
- 이는 마지막 클럭 업데이트 시 예상 로컬 오프셋입니다.
- RMS 오프셋
- 오프셋 값의 장기 평균입니다.
- frequency
-
chronyd
가 수정하지 않은 경우 시스템의 시계가 잘못된 비율입니다. ppm(100만 개당 부분)으로 표시됩니다. 예를 들어 1 ppm의 값은 시스템의 시계가 1 초이라고 생각할 때 실제로 true 시간을 기준으로 1.000001 초만큼 고급이라고 생각할 수 있음을 의미합니다. - Residual freq
현재 선택한 참조 소스에 대한 "기분 빈도"를 표시합니다. 이는 참조 소스에서 측정이 필요한 것과 현재 사용 중인 빈도와 현재 사용된 빈도 간의 차이를 반영합니다.
이 값이 항상 0이 아닌 이유는 매끄러운 절차가 빈도에 적용되기 때문입니다. 참조 소스에서 측정을 얻을 때마다 새로운 잔류 빈도가 계산될 때마다 이 재순기의 예상 정확도가 기존 빈도 값의 예상 정확도(다음 참조)와 비교됩니다.
가중치 평균은 새로운 빈도에 대해 계산되며, 가중치는 이러한 인수에 따라 계산됩니다. 참조 소스의 측정이 일관된 추세를 따르는 경우 시간 경과에 따라 재순위가 0이 됩니다.
- skew
- 이는 빈도에 바인딩된 예상 오류입니다.
- 루트 지연
- 이는 컴퓨터가 궁극적으로 동기화되는 stratum-1 컴퓨터에 대한 네트워크 경로 지연의 총입니다. 루트 지연 값은 나노초 해상도로 인쇄됩니다. 특정 극단적인 상황에서는 이 값이 음수일 수 있습니다. (즉, 컴퓨터의 Frequencies가 서로를 추적하지 않는 대칭 피어 배열에서 발생할 수 있으며 네트워크 지연은 각 컴퓨터에서 차례대로 매우 짧습니다.)
- 근본 분산
- 이는 모든 컴퓨터를 통해 컴퓨터가 궁극적으로 동기화되는 stratum-1 컴퓨터로 다시 누적된 총 분산입니다. 분산은 시스템 클럭 해상도, 통계 측정 차이 등으로 인한 것입니다. 근본 분산 값은 나노초 해상도로 인쇄됩니다.
- consequent 상태
- 이 상태는 just 상태이며 이는 Normal, Insert second, Delete second 또는 Not synchronized일 수 있습니다.
18.3.5.2. chrony 소스 확인
source 명령은 chronyd
가 액세스 중인 현재 시간 소스에 대한 정보를 표시합니다.
선택적 인수 -v를 지정할 수 있습니다. 즉 자세한 내용은 다음과 같습니다. 이 경우 추가 주석 줄은 열의 의미를 상기시키는 것으로 표시됩니다.
~]$ chronyc sources 210 Number of sources = 3 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* GPS0 0 4 377 11 -479ns[ -621ns] +/- 134ns ^? a.b.c 2 6 377 23 -923us[ -924us] +/- 43ms ^+ d.e.f 1 6 377 21 -2629us[-2619us] +/- 86ms
열은 다음과 같습니다.
- M
-
이는 소스의 모드를 나타냅니다.
^
은 서버를 의미하며=
는 피어 및#
은 로컬에 연결된 참조 클럭을 나타냅니다. - S
-
이 열은 소스의 상태를 나타냅니다. "*"는
chronyd
가 현재 동기화된 소스를 나타냅니다. "+"는 선택한 소스와 결합되는 허용 가능한 소스를 나타냅니다. "-"는 결합 알고리즘으로 제외되는 허용 가능한 소스를 나타냅니다. "?"는 연결이 손실되었거나 패킷이 모든 테스트를 통과하지 않은 소스를 나타냅니다.chronyd
가 falseticker 라고 생각하는 시계를 나타냅니다. "~"은 시간이 다른 소스의 대부분과 일치하지 않음을 나타냅니다. "~"는 시간이 너무 많은 변동성을 갖는 소스임을 나타냅니다. "?" 조건은 시작 시 적어도 3개의 샘플이 수집될 때까지 표시됩니다. - 이름/IP 주소
-
이는 소스의 이름 또는
IP
주소 또는 참조 시계의 참조 ID를 보여줍니다. - stratum
- 이것은 가장 최근에 수신된 샘플에서 보고된 소스 스트랩을 보여줍니다. stratum 1은 로컬로 연결된 참조 시계가 있는 컴퓨터를 나타냅니다. 계층 1 컴퓨터에 동기화된 컴퓨터는 stratum 2에 있습니다. 계층 2 컴퓨터에 동기화된 컴퓨터는 stratum 3 등에 있습니다.
- poll
이는 소스를 폴링하는 속도를 초 단위로 표시합니다. 따라서 6의 값은 64초마다 측정이 수행됨을 나타냅니다.
chronyd
는 prevailing 조건에 대한 응답으로 폴링 속도가 자동으로 달라집니다.- 연결
- 이는 소스의 도달 레지스터가 8진수 숫자로 출력되는 것을 보여줍니다. 레지스터에는 8비트가 있으며 소스에서 수신되거나 누락된 모든 패킷에서 업데이트됩니다. 값 377은 마지막 8개의 전송 모두에 대해 유효한 응답이 수신되었음을 나타냅니다.
- LastRx
-
이 열에는 최근 샘플이 소스에서 수신한 시간을 보여줍니다. 이는 일반적으로 초 단위입니다.
m
,h
,d
또는y
는 분, 시간, 일 또는 연도를 나타냅니다. 10 년의 값은 아직 이 소스에서 수신된 샘플이 없음을 나타냅니다. - 마지막 샘플
-
이 열에는 마지막 측정에서 로컬 클럭과 소스 간 오프셋이 표시됩니다. 대괄호의 숫자는 실제 측정 오프셋을 보여줍니다. 이 접미사는
ns
(나노초),us
(마이크로 표시),ms
(초 단위 표시) 또는s
(초)로 붙일 수 있습니다. 대괄호 왼쪽의 숫자는 이후 로컬 시계에 적용되는 모든 슬리어를 허용하도록 조정된 원래 측정을 보여줍니다.+/-
표시기 이후의 숫자는 측정에서 오류 여백을 보여줍니다. 양수 오프셋은 로컬 시계가 소스보다 앞서 있음을 나타냅니다.
18.3.5.3. chrony 소스 통계 확인
sourcestats
명령은 chronyd
에서 현재 검사 중인 각 소스에 대한 드리프트 비율 및 오프셋 추정 프로세스에 대한 정보를 표시합니다.
선택적 인수 -v
를 지정할 수 있습니다. 즉 자세한 내용은 다음과 같습니다. 이 경우 추가 주석 줄은 열의 의미를 상기시키는 것으로 표시됩니다.
~]$ chronyc sourcestats
210 Number of sources = 1
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
===============================================================================
abc.def.ghi 11 5 46m -0.001 0.045 1us 25us
열은 다음과 같습니다.
- 이름/IP 주소
-
이는
NTP
서버(또는 피어)의 이름 또는IP
주소이거나 나머지 줄과 관련된 참조 시계의 참조 ID입니다. - NP
- 이는 현재 서버에 대해 유지 중인 샘플 포인트의 수입니다. 드리프트 비율 및 현재 오프셋은 이러한 점을 통해 선형 회귀를 수행하여 추정됩니다.
- NR
-
이는 마지막 회귀에 따라 동일한 기호를 갖는 남은 횟수입니다. 이 숫자가 샘플 수에 비해 너무 작아지면 직선이 더 이상 데이터에 적합하지 않음을 나타냅니다. 실행 수가 너무 작으면
chronyd
가 이전 샘플을 삭제하고 실행 횟수가 수락될 때까지 회귀를 다시 실행합니다. - 기간
- 이는 가장 오래된 샘플과 최신 샘플 사이의 간격입니다. 단위가 표시되지 않으면 초 단위가 표시됩니다. 예에서 간격은 46분입니다.
- frequency
- 이는 서버에 대한 예상 남은 빈도이며, 100만 개당 파트에 해당합니다. 이 경우 컴퓨터 클럭은 서버에 비해 109 느릴 때 1 파트가 실행되는 것으로 추정됩니다.
- Freq Skew
- 이는 Freq에 바인딩된 예상 오류입니다(100만 개당 부분 수).
- offset
- 이는 소스의 예상 오프셋입니다.
- STD Dev
- 이는 예상 샘플 표준 결정입니다.
18.3.6. 시스템 시계 수동 조정
시스템 클럭을 즉시 단계적으로 조정하려면 슬래핑하여 진행 중인 조정을 바이패스하고 root
로 다음 명령을 실행합니다.
~]# chronyc makestep
rtcfile
지시문을 사용하는 경우 실시간 클럭을 수동으로 조정할 수 없습니다. 임의의 조정으로 chrony의 실시간 클럭 드리프트가 발생하는 비율을 측정해야 합니다.
18.4. 다른 환경에 대한 chrony 설정
18.4.1. 격리된 네트워크에서 시스템의 chrony 설정
인터넷에 연결되지 않은 네트워크의 경우 하나의 컴퓨터가 마스터 timeserver로 선택됩니다. 다른 컴퓨터는 마스터 또는 클라이언트의 직접 클라이언트입니다. 마스터에서 드리프트 파일은 시스템 클럭의 평균 드리프트 속도로 수동으로 설정해야 합니다. 마스터가 재부팅되면 주변 시스템에서 시간을 가져오고 평균을 계산하여 시스템 클럭을 설정합니다. 그런 다음 드리프트 파일에 따라 조정을 다시 시작합니다. settime
명령을 사용하면 드리프트 파일이 자동으로 업데이트됩니다.
root
로 실행되는 텍스트 편집기를 사용하여 마스터로 선택한 시스템에서 다음과 같이 /etc/chrony.conf
를 편집합니다.
driftfile /var/lib/chrony/drift commandkey 1 keyfile /etc/chrony.keys initstepslew 10 client1 client3 client6 local stratum 8 manual allow 192.0.2.0
여기서 192.0.2.0
은 클라이언트가 연결할 수 있는 네트워크 또는 서브넷 주소입니다.
마스터의 클라이언트가 root
로 실행되는 텍스트 편집기를 사용하여 마스터의 클라이언트를 지시하도록 선택한 시스템에서 다음과 같이 /etc/chrony.conf
를 편집합니다.
server master driftfile /var/lib/chrony/drift logdir /var/log/chrony log measurements statistics tracking keyfile /etc/chrony.keys commandkey 24 local stratum 10 initstepslew 20 master allow 192.0.2.123
여기서 192.0.2.123
은 마스터의 주소이며 master
는 마스터의 호스트 이름입니다. 이 구성을 사용하는 클라이언트는 다시 시작하면 마스터를 재동기화합니다.
마스터의 클라이언트가 아닌 클라이언트 시스템에서 /etc/chrony.conf
파일은 로컬
및 허용
지시문을 생략해야 한다는 점을 제외하고 동일해야 합니다.
Isolated Network에서는 로컬 참조 모드를 활성화하는 로컬
지시문을 사용할 수도 있습니다. 그러면 로컬 참조 모드를 활성화하는 로컬 지시문을 사용할 수 있으므로, 동기화되지 않았거나 시계의 마지막 업데이트가 오래 전에 발생했던 경우에도 NTP 서버로의 chronyd
가 실시간으로 표시될 수 있습니다.
네트워크에 있는 여러 서버가 동일한 로컬 구성을 사용하고 두 서버를 폴링하는 클라이언트의 혼동 없이 서로 동기화되도록 하려면 고립 모드를 활성화하는 로컬
지시문의 분리 옵션을 사용합니다. 다른 모든 서버를 로컬로 폴링하도록 각 서버를 구성해야 합니다.
이렇게 하면 참조 ID가 가장 작은 서버만 로컬 참조가 활성 상태이고 다른 서버가 동기화됩니다. 서버가 실패하면 다른 서버가 대신합니다.
18.5. chronyc 사용
18.5.1. chronyc를 사용하여 chronyd 제어
대화형 모드에서 명령행 유틸리티 chronyc 를 사용하여 chronyd
의 로컬 인스턴스를 변경하려면 root
로 다음 명령을 입력합니다.
~]# chronyc
restricted 명령 중 일부를 사용할 경우 chronyc 를 root
로 실행해야 합니다.
chronyc 명령 프롬프트가 다음과 같이 표시됩니다.
chronyc>
help
를 입력하여 모든 명령을 나열할 수 있습니다.
다음과 같이 명령과 함께 호출되는 경우 비대화형 명령 모드에서 유틸리티를 호출할 수도 있습니다.
chronyc command
chronyc 를 사용한 변경 사항은 영구적이 아니며 chronyd
를 다시 시작한 후 손실됩니다. 영구 변경 사항은 /etc/chrony.conf
를 수정합니다.
18.6. HW 타임스탬프링이 있는 Chrony
18.6.1. 하드웨어 타임 스탬프(Hardware Timestamping) 이해
하드웨어 타임스탬프는 일부 NIC(Network Interface Controller)에서 지원되는 기능으로, 수신 및 발신 패킷의 정확한 타임스탬프를 제공합니다. NTP
타임스탬프는 일반적으로 시스템 클럭을 사용하여 커널 및 chronyd 에 의해 생성됩니다. 그러나 HW 타임스탬프ing이 활성화되면 NIC는 자체 클럭을 사용하여 패킷이 링크 계층 또는 물리적 계층을 입력하거나 나가는 경우 타임스탬프를 생성합니다. NTP
와 함께 사용하면 하드웨어 타임스탬프가 동기화의 정확도를 크게 향상시킬 수 있습니다. 최상의 정확도를 위해 NTP
서버와 NTP
클라이언트는 하드웨어 타임스탬프를 사용해야 합니다. 이상적인 조건에서는 마이크로 초의 정확도가 가능할 수 있습니다.
하드웨어 타임스탬프를 사용하는 시간 동기화를 위한 또 다른 프로토콜은 PTP
입니다. PTP
에 대한 자세한 내용은 20장. ptp4l을 사용하여 PTP 구성 을 참조하십시오. NTP
와 달리PTP
는 네트워크 스위치 및 라우터의 지원에 의존합니다. 동기화의 최상의 정확도에 도달하려면 PTP
지원 기능이 포함된 스위치 및 라우터가 있는 네트워크에서 PTP
를 사용하고 이러한 스위치 및 라우터가 없는 네트워크에서 NTP
를 선호합니다.
18.6.2. 하드웨어 타임 스탬프 확인
NTP
를 사용한 하드웨어 타임스탬프를 인터페이스에서 확인하려면 ethtool -T
명령을 사용합니다. ethtool
이 SOF_TIMESTAMPING_TX_HARDWARE
및 SOF_TIMESTAMPING_TX_SOFTWARE
기능 및 HWTSTAMP_FILTER_ALL
필터 모드를 나열하는 경우 NTP
를 사용한 하드웨어 타임 스탬프링에 사용할 수 있습니다.
예 18.2. 특정 인터페이스에서 하드웨어 타임 스탬프 지원 확인
~]# ethtool -T eth0
출력:
Timestamping parameters for eth0: Capabilities: hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) PTP Hardware Clock: 0 Hardware Transmit Timestamp Modes: off (HWTSTAMP_TX_OFF) on (HWTSTAMP_TX_ON) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) all (HWTSTAMP_FILTER_ALL) ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC) ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)
18.6.3. 하드웨어 타임 스탬프 활성화
하드웨어 타임스탬프를 활성화하려면 /etc/chrony.conf
파일에 hwtimestamp
지시문을 사용합니다. 지시문은 단일 인터페이스를 지정하거나 와일드카드 문자()를 사용하여 이를 지원하는 모든 인터페이스에서 하드웨어 타임스탬프를 활성화할 수 있습니다. linuxptp 패키지의 [application]*ptp4l 와 같은 다른 애플리케이션이 없는 경우 와일드카드 사양을 사용하는 경우 인터페이스에서 하드웨어 타임스탬프를 사용하는 것입니다. chrony 구성 파일에서 여러 hwtimestamp
지시문이 허용됩니다.
예 18.3. hwtimestamp 지시문을 사용하여 하드웨어 타임 스탬프 활성화
hwtimestamp eth0 hwtimestamp eth1 hwtimestamp *
18.6.4. 클라이언트 Polling Interval 구성
폴링 간격(64-1024초)의 기본 범위는 인터넷 서버에 권장됩니다. 로컬 서버 및 하드웨어 타임스탬프의 경우 시스템 클럭의 오프셋을 최소화하기 위해 더 짧은 폴링 간격을 구성해야 합니다.
/etc/chrony.conf
의 다음 지시문은 1초 폴링 간격을 사용하여 로컬 NTP
서버를 지정합니다.
server ntp.local minpoll 0 maxpoll 0
18.6.5. 대화형 모드 활성화
하드웨어
어플라이언스가 아니라 일반적인 용도의 컴퓨터에서 chrony 와 같은 소프트웨어 NTP
NTP
구현을 실행하는 NTP 서버는 패킷을 보낸 후에만 하드웨어 전송 타임스탬프를 가져옵니다. 이 동작은 서버가 해당하는 패킷에 타임스탬프를 저장하지 않도록 합니다. 전송 후 생성된 전송 타임스탬프를 수신하는 NTP
클라이언트가 /etc/chrony.conf
의 server 지시문에 xleave
옵션을 추가하여 NTP
인터리빙 모드를 사용하도록 클라이언트를 구성합니다.
server ntp.local minpoll 0 maxpoll 0 xleave
18.6.6. 많은 수의 클라이언트에 대해 서버 구성
기본 서버 구성을 사용하면 대부분 수천 개의 클라이언트가 동시에 interleaved 모드를 사용할 수 있습니다. 더 많은 수의 클라이언트에 대해 서버를 구성하려면 /etc/chrony.conf
에서 clientloglimit
지시문을 늘립니다. 이 지시문은 서버에 클라이언트 액세스 로깅을 위해 할당된 최대 메모리 크기를 지정합니다.
clientloglimit 100000000
18.6.7. 하드웨어 타임 스탬프 확인
인터페이스에서 하드웨어 타임스탬프가 성공적으로 활성화되었는지 확인하려면 시스템 로그를 확인합니다. 로그에 성공적으로 활성화된 하드웨어 타임스탬프가 있는 각 인터페이스에 대해 chronyd 의 메시지가 포함되어야 합니다.
예 18.4. 하드웨어 Timestamping이 활성화된 인터페이스에 대한 로그 메시지
chronyd[4081]: Enabled HW timestamping on eth0 chronyd[4081]: Enabled HW timestamping on eth1
chronyd 가 NTP
클라이언트 또는 피어로 구성된 경우 chronyc ntpdata
명령을 통해 각 NTP
소스에 대해 보고된 전송 및 타임스탬프 지정 모드와 시간 초과 모드를 사용할 수 있습니다.
예 18.5. 각 NTP 소스에 대한 Transmit, Receive Timestamping 및 Interleaved Mode를 보고합니다.
~]# chronyc ntpdata
출력:
Remote address : 203.0.113.15 (CB00710F) Remote port : 123 Local address : 203.0.113.74 (CB00714A) Leap status : Normal Version : 4 Mode : Server Stratum : 1 Poll interval : 0 (1 seconds) Precision : -24 (0.000000060 seconds) Root delay : 0.000015 seconds Root dispersion : 0.000015 seconds Reference ID : 47505300 (GPS) Reference time : Wed May 03 13:47:45 2017 Offset : -0.000000134 seconds Peer delay : 0.000005396 seconds Peer dispersion : 0.000002329 seconds Response time : 0.000152073 seconds Jitter asymmetry: +0.00 NTP tests : 111 111 1111 Interleaved : Yes Authenticated : No TX timestamping : Hardware RX timestamping : Hardware Total TX : 27 Total RX : 27 Total valid RX : 27
예 18.6. NTP 측정의 기능 보고
# chronyc sourcestats
하드웨어 타임스탬프를 활성화하면 NTP
측정의 안정성이 정상적인 부하에 따라 수십 또는 수백 나노초 내에 있어야 합니다. 이 안정성은 chronyc sourcestats
명령 출력의 Std Dev
열에 보고됩니다.
출력:
210 Number of sources = 1 Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ntp.local 12 7 11 +0.000 0.019 +0ns 49ns
18.6.8. PTP-NTP 브리지 구성
PTP 지원이 포함된 스위치 또는 라우터가 없는 네트워크에서 매우 정확한PTP
(Precision Time Protocol) 하위 마스터를 사용할 수 있는 경우, 컴퓨터는
슬레이브 및 stratum-1 PTP
NTP
서버로 작동하도록 전용될 수 있습니다. 이러한 컴퓨터에는 두 개 이상의 네트워크 인터페이스가 있어야 하며, 할아버지 마스터와 근접하거나 이에 대한 직접 연결이 있어야 합니다. 이렇게 하면 네트워크에서 매우 정확한 동기화가 수행됩니다.
linuxptp 패키지에서 ptp4l 및 phc2sys 프로그램을 구성하여 PTP
를 사용하여 시스템 클럭을 동기화하도록 하나의 인터페이스를 사용합니다. 구성은 20장. ptp4l을 사용하여 PTP 구성 에 설명되어 있습니다. 다른 인터페이스를 사용하여 시스템 시간을 제공하도록 chronyd 를 구성합니다.
예 18.7. 기타 인터페이스를 사용하여 시스템 시간 제공으로 chronyd 구성
bindaddress 203.0.113.74 hwtimestamp eth1 local stratum 1
18.7. 추가 리소스
다음 정보 소스는 chrony 에 대한 추가 리소스를 제공합니다.
18.7.1. 설치된 문서
-
chronyc(1)
도움말 페이지 - 명령 및 명령 옵션을 포함하여 chronyc 명령줄 인터페이스 툴에 대해 설명합니다. -
chronyd(8)
도움말 페이지 - 명령 및 명령 옵션을 포함하여 chronyd 데몬을 설명합니다. -
chrony.conf(5)
도움말 페이지 - chrony 구성 파일에 대해 설명합니다.
18.7.2. 온라인 문서
FAQ에 대한 답변은 http://chrony.tuxfamily.org/faq.html를 참조하십시오.
19장. ntpd를 사용하여 NTP 설정
19.1. NTP 소개
NTP( Network Time Protocol )는 네트워크 컴퓨터 시스템의 시간 시계를 네트워크 또는 인터넷상의 공통 참조에 동기화하기 위해 시간 및 날짜 정보의 정확한 분배를 가능하게 합니다. 전 세계의 많은 표준 본문에는 참조로 사용할 수 있는 원자성 시계가 있습니다. Global Position System을 구성하는 위성에는 두 개 이상의 원자성 시계가 포함되어 있어 시간 신호가 매우 정확해집니다. 그러나 이러한 지표는 정책상의 이유로 인해 의도적으로 저하될 수 있습니다. 이상적인 상황은 각 사이트에 사이트 전체 시간 서버 역할을 하기 위해 자체 참조 클럭이 연결된 서버가 있는 경우입니다. 낮은 빈도의 라디오 전송 또는 GPS (Global Position System)를 통해 시간 및 날짜를 얻는 많은 장치가 있습니다. 그러나 대부분의 경우 지리적으로 분산된 위치에서 인터넷에 연결된 공개적으로 액세스 가능한 다양한 서버를 사용할 수 있습니다. 이 NTP
서버는 "Coordinated Universal Time"(UTC)을 제공합니다. 이 시간 서버에 대한 정보는 www.pool.ntp.org 에서 확인할 수 있습니다.
IT의 여러 이유로 정확한 시간 유지가 중요합니다. 예를 들어 네트워킹에서는 패킷 및 로그의 정확한 타임스탬프가 필요합니다. 로그는 서비스 및 보안 문제를 조사하는 데 사용되므로 다른 시스템에서 만든 타임스탬프는 실제 값으로 동기화된 클럭에 의해 만들어야 합니다. 시스템과 네트워크가 점점 빨라짐에 따라 정확도와 해상도가 높은 클럭이 필요합니다. 일부 국가에는 시계를 정확하게 동기화해야합니다. 자세한 내용은 www.ntp.org 을 참조하십시오. Linux 시스템에서 NTP
는 사용자 공간으로 실행되는 데몬에 의해 구현됩니다. Red Hat Enterprise Linux 7의 기본 NTP
사용자 공간 데몬은 chronyd
입니다. ntpd
데몬을 사용하려면 비활성화해야 합니다. chrony 에 대한 자세한 내용은 18장. chrony Suite를 사용하여 NTP 설정 을 참조하십시오.
사용자 공간 데몬은 커널에서 실행되는 소프트웨어 클럭인 시스템 클럭을 업데이트합니다. Linux는 " RTC( Real Time Clock")라는 일반적인 내장 하드웨어 클럭보다 더 나은 해상도로 소프트웨어 클럭을 사용합니다. 하드웨어 시계에 대한 자세한 내용은 rtc(4)
및 hwclock(8)
도움말 페이지를 참조하십시오. 시스템 클럭은 다양한 클럭 소스를 사용하여 시간을 유지할 수 있습니다. 일반적으로TSC( Time Stamp TSC )가 사용됩니다. TSC는 마지막 재설정 이후 사이클 수를 계산하는 CPU 레지스터입니다. 매우 빠르고 높은 해상도가 있으며 인터럽트가 없습니다. 시스템 시작 시 시스템 클럭은 RTC에서 시간과 날짜를 읽습니다. RTC에 의해 유지되는 시간은 온도 변동으로 인해 매달 5분까지 변동될 것입니다. 따라서 시스템 시계가 지속적으로 외부 시간 참조와 동기화되어야 합니다. 시스템 클럭이 ntpd
로 동기화되고 있는 경우 커널은 11분마다 RTC를 자동으로 업데이트합니다.
19.2. NTP Strata
NTP
서버는 시간 신호의 소스인 원자 시계와의 동기화 거리에 따라 분류됩니다. 서버는 계층 또는 계층으로 정렬되는 것으로 간주되며 1에서 15까지로 간주됩니다. 따라서 stratum이라는 단어는 특정 레이어를 참조할 때 사용됩니다. Atomic 클럭은 이것이 소스인 것처럼 스트레칭 0이라고 하며, 인터넷에서 스트레이트 0 패킷이 전송되지 않으며, 모든 stratum 시계가 계층 1이라고 하는 서버에 연결되어 있습니다. 이 서버는 Stratum 1로 표시된 패킷을 보냅니다. stratum n
이 표시된 패킷을 통해 동기화되는 서버는 다음, lower, stratum에 속하고 패킷을 stratum n+1
로 표시합니다. 동일한 계층의 서버는 서로 패킷을 교환할 수 있지만 한 계층에만 속하는 패킷을 계속 지정할 수 있지만 한 계층만 연결된 계층, 동기화된 가장 큰 참조 아래에 있는 stratum입니다. 지정 스트라운트 16은 서버가 현재 신뢰할 수 있는 시간 소스에 동기화되지 않음을 나타내는 데 사용됩니다.
기본적으로 NTP
클라이언트는 그 아래에 있는 계층에 있는 해당 시스템의 서버 역할을 합니다.
다음은 NTP
스트레타에 대한 요약입니다.
- stratum 0
Atomic Clock과 해당 신호는 radio 및 GPS를 통해 브로드캐스트
- GPS (Global Positioning System)
- 휴대폰 시스템
낮은 Frequency radio Broadcasts WWVB ( USA.), JJY-40 및 JJY-60 (Japan), DCF77 (Germany) 및 MSF (United UK)
이러한 신호는 전용 장치에서 수신할 수 있으며 일반적으로 RS-232가 조직 또는 사이트 전체 시간 서버로 사용되는 시스템에 연결됩니다.
- stratum 1
- 무선 시계, GPS 시계 또는 원자 시계가 연결된 컴퓨터
- stratum 2
- stratum 1에서 읽기; 낮은 계층으로 Serves to lower strata
- stratum 3
- stratum 2; Serves to lower strata에서 읽기
- stratum n+1
- stratum n; lower strata로 읽습니다.
- stratum 15
- stratum 14;이 가장 낮은 계층입니다.
이 프로세스는 스트레칭 15로 계속되며, 이는 가장 낮은 유효한 계층입니다. 레이블 Stratum 16은 동기화되지 않은 상태를 표시하는 데 사용됩니다.
19.3. NTP 이해
Red Hat Enterprise Linux에서 사용하는 NTP
버전은 RFC 1305 네트워크 시간 프로토콜(버전 3) 사양, 구현 및 분석 및 rootfsRFC 5905 네트워크 시간 프로토콜 버전 4에 설명되어 있습니다. 프로토콜 및 알고리즘 사양
이 NTP
구현에서는 2초의 정확도를 실현할 수 있습니다. 인터넷을 통해 10초의 정확도가 정상입니다. LAN(Local Area Network)에서 1ms 정확도는 이상적인 조건에서 가능합니다. 이는 클럭 드리프트가 현재 고려 및 수정되었으며, 이는 보다 단순하고 단순한 시간 프로토콜 시스템에서 수행되지 않았기 때문입니다. 233 Picoseconds의 해상도는 64비트 타임스탬프를 사용하여 제공됩니다. 타임스탬프의 첫 번째 32비트는 초 동안 사용되며 마지막 32비트는 초 단위로 사용됩니다.
NTP
는 00:00 (midnight) 이후의 시간(midnight) 1년 1월 1일(sidnight)의 수입니다. 초를 계산하는 데 32 비트가 사용되므로 시간은 2036에서 "롤 오버"가된다는 것을 의미합니다. 그러나 NTP
는 타임 스탬프 간의 차이에서 작동하므로 다른 시간 프로토콜 구현과 동일한 수준의 문제가 발생하지 않습니다. 부팅 시 68년 이내에 하드웨어 시계를 사용할 수 있는 경우 NTP
는 현재 날짜를 올바르게 해석합니다. NTP4
사양은 "Era Number" 및 "Era Offset"를 제공하여 68년 이상의 시간 길이를 처리할 때 소프트웨어를 더 견고하게 만드는 데 사용할 수 있습니다. 이를 Unix Year 2038 문제와 혼동하지 마십시오.
NTP
프로토콜은 정확도를 높이기 위해 추가 정보를 제공합니다. 4개의 타임 스탬프는 왕복 시간 및 서버 응답 시간을 계산하는 데 사용됩니다. 시스템의 역할이 NTP
클라이언트로 참조 시간 서버와 동기화되도록 하기 위해 패킷은 "원본 타임스탬프"와 함께 전송됩니다. 패킷이 도착하면 시간 서버에서 "receive Time stamp"를 추가합니다. 시간 및 날짜 정보에 대한 요청을 처리한 후 패킷을 반환하기 직전에는 "전송 타임스탬프"가 추가됩니다. 반환 패킷이 NTP
클라이언트에 도달하면 "receive Time stamp"가 생성됩니다. 고객은 이제 총 왕복 시간을 계산하고 처리 시간을 뺀 뒤 실제 이동 시간을 도출할 수 있습니다. 발신 및 반환 트립트가 동일한 시간이 소요된다고 가정하면 NTP
데이터를 수신하는 단일 간격 지연이 계산됩니다. 전체 NTP
알고리즘은 여기에 제시된 것보다 훨씬 더 복잡합니다.
시간 정보를 포함하는 패킷이 즉시 응답하지는 않지만 먼저 유효성 검사를 확인한 다음 여러 다른 시간 샘플과 함께 처리하여 추정에 도달할 수 있습니다. 그런 다음 시스템 클럭과 비교하여 시간 오프셋을 결정하고 시스템 클럭의 시간과 ntpd
가 결정된 시간을 결정합니다. 시스템 클럭은 사용 중인 카운터의 빈도를 변경하여 이 오프셋을 줄이기 위해 초당 0.5ms의 속도로 느리게 조정됩니다. 이 방법을 사용하여 시계를 1초 이상 조정하려면 최소 2000초가 걸립니다. 이 느린 변경은 슬라이딩이라고 하며 뒤로 갈 수 없습니다. 시계의 시간 오프셋이 128ms(기본 설정)를 초과하는 경우, ntpd
는 클럭 전방 또는 이전을 "단계"할 수 있습니다. 시스템 시작 시 시간 오프셋이 1000초보다 크면 사용자 또는 설치 스크립트가 수동 조정을 수행해야 합니다. 3장. 날짜 및 시간 구성을 참조하십시오. ntpd
명령에 대한 -g
옵션(기본적으로 사용)으로 시스템 시작 시의 모든 오프셋이 수정되지만 정상적인 작업 중에 최대 1000초의 오프셋만 수정됩니다.
일부 소프트웨어가 실패하거나 시간이 거꾸로 변경되면 오류가 발생할 수 있습니다. 단계 변경에 민감한 시스템의 경우 임계값은 -x
옵션( -g
옵션과 관련이 없음)을 사용하여 128ms가 아닌 600 s로 변경할 수 있습니다. -x
옵션을 사용하여 스테핑 제한을 0.128 s에서 600 s로 늘릴 때 클럭을 제어하는 다른 방법을 사용해야하기 때문에 단점이 있습니다. 커널 클럭 분야를 비활성화하고 시계 정확도에 부정적인 영향을 미칠 수 있습니다. /etc/sysconfig/ntpd
설정 파일에 -x
옵션을 추가할 수 있습니다.
19.4. Drift 파일 이해
드리프트 파일은 nominal frequency에서 실행되는 시스템 클럭과 UTC와의 동기화에 필요한 빈도 간 빈도를 저장하는 데 사용됩니다. 존재하는 경우 드리프트 파일에 포함된 값은 시스템 시작 시 읽고 클럭 소스를 수정하는 데 사용됩니다. 드리프트 파일을 사용하면 안정적이고 정확한 시간을 달성하는 데 필요한 시간이 줄어듭니다. 값이 계산되고 드리프트 파일이 시간당 한 번 ntpd
로 교체됩니다. 드리프트 파일은 업데이트만으로 대체되며, 이로 인해 드리프트 파일은 ntpd
에 쓰기 권한이 있는 디렉터리에 있어야 합니다.
19.5. UTC, 시간대 및 DST
NTP
가 UTC(Universal Time, Coordinated)에 완전히 포함되므로 Timezones 및 DST (Daylight Saving Time)는 시스템에 의해 로컬로 적용됩니다. /etc/localtime
파일은 /usr/share/zoneinfo
의 영역 정보 파일인 의 복사 또는 심볼릭 링크입니다. RTC는 /etc/adjtime
의 3번째 라인에 지정된 대로 현지 시간 또는 UTC에 있을 수 있으며 이는 RTC 시계가 어떻게 설정되었는지 나타내는 LOCAL 또는 UTC 중 하나입니다. 사용자는 날짜 및 시간 그래픽 구성 도구에서 System Clock Uses UTC
확인란을 사용하여 이 설정을 쉽게 변경할 수 있습니다. 해당 툴 사용 방법에 대한 자세한 내용은 3장. 날짜 및 시간 구성 을 참조하십시오. 일광 절약 시간이 변경될 때 다양한 문제를 방지하기 위해 RTC를 실행하는 것이 좋습니다.
ntpd
의 작동은 man 페이지 ntpd(8)
에 자세히 설명되어 있습니다. resources 섹션에는 유용한 정보 소스가 나열됩니다. 19.20절. “추가 리소스”을 참조하십시오.
19.6. NTP의 인증 옵션
NTPv4
NTPv4는 대칭 키 암호화를 지원하는 동안 공개 symmetric 암호화를 기반으로 하는 Autokey Security Architecture에 대한 지원이 추가되었습니다. Autokey 프로토콜은 RFC 5906 Network Time Protocol Version 4에 설명되어 있습니다. Autokey Specification. 하지만 나중에 이 프로토콜의 보안 문제가 심각한 보안 문제가 있는 것으로 확인되었기 때문에 Red Hat은 대신 대칭 키를 사용할 것을 강력히 권장합니다. man 페이지 ntp_auth(5)
는 ntpd
의 인증 옵션 및 명령을 설명합니다.
네트워크의 공격자는 잘못된 시간 정보로 NTP
패킷을 전송하여 서비스 중단을 시도할 수 있습니다. NTP
서버의 공용 풀을 사용하는 시스템에서는 /etc/ntp.conf
에 공용 NTP
서버 목록에 3개 이상의 NTP
서버를 사용하면 이러한 위험이 완화됩니다. 하나의 시간 소스만 손상되었거나 스푸핑된 경우 ntpd
는 해당 소스를 무시합니다. 위험 평가를 수행하고 애플리케이션 및 조직에 잘못된 시간의 영향을 고려해야 합니다. 내부 시간 소스가 있는 경우 NTP
패킷이 배포된 네트워크를 보호하는 단계를 고려해야 합니다. 위험 평가를 수행하고 위험이 허용되며 애플리케이션에 미치는 영향은 최소의 경우 인증을 사용하지 않도록 선택할 수 있습니다.
브로드캐스트 및 멀티 캐스트 모드에는 기본적으로 인증이 필요합니다. 네트워크를 신뢰하기로 결정한 경우 ntp.conf
파일에서 disable auth
지시문을 사용하여 인증을 비활성화할 수 있습니다. 또는 SHA1 또는 MD5 대칭 키를 사용하거나 Autokey 스키마를 사용하여 공개(비밀도) 키 암호화로 인증을 구성해야 합니다. 대칭 암호화의 자동 키 체계는 ntp_auth(8)
도움말 페이지에 설명되어 있으며 키 생성은 ntp-keygen(8
)에 설명되어 있습니다. 대칭 키 암호화를 구현하려면 키
옵션에 대한 설명은 19.17.12절. “키를 사용하여 Symmetric Authentication 구성” 을 참조하십시오.
19.7. 가상 머신의 시간 관리
가상 머신은 실제 하드웨어 시계에 액세스할 수 없으며 호스트 시스템의 작업 부하에 따라 안정성이 다르기 때문에 가상 클럭이 충분히 안정적이지 않습니다. 이러한 이유로 반가상화 클럭은 사용 중인 가상화 애플리케이션에서 제공해야 합니다. KVM 이 있는 Red Hat Enterprise Linux에서 기본 클럭 소스는 kvm-clock
입니다. Red Hat Enterprise Linux 7 Virtualization 배포 및 관리 가이드의 KVM 게스트 타이밍 관리 장을 참조하십시오.
19.8. Leap Seconds 이해
GMT (Greenwich Mean Time)는 전지의 회전에 따라 날을 측정하여 파생되었습니다. 원자성 시계가 처음 만들어지면 시간을 더 정확하게 정의 할 가능성이되었습니다. 1958에서는 국제 Atomic Time (TAI)이 더 정확하고 매우 안정적인 원자 시계를 기반으로 도입되었습니다. 보다 정확한 천문 시간, Universal Time 1 (UT1)도 GMT를 대체하는 도입되었습니다. 원자 시계는 실제로 지구의 회전보다 훨씬 더 안정적이므로 두 번 분리되기 시작했습니다. 이러한 이유로 UTC는 실질적인 조치로 도입되었습니다. UT1의 1초 이내에 유지되지만 많은 소규모의 조정을 피하기 위해 관리 가능한 방식으로 차이를 조정하기 위해 윤초의 개념을 도입하기로 결정했습니다. UT1과 UTC의 차이점은 1초 이상 변동될 때까지 모니터링됩니다. 그런 다음 1초 조정, 앞선 또는 뒤로 도입해야 합니다. 지구 회전 속도의 에라미한 특성으로 인해, 조정에 대한 필요성은 미래에 멀리 예측할 수 없습니다. 조정 시기를 결정하는 것은 International Earth Rotation and Reference Systems Service (IERS) 에 의해 이루어집니다. 그러나 NTP
는 보류 중인 윤 초에 대한 정보를 전송하고 자동으로 적용하기 때문에 이러한 발표는 스트라운트 1 서버 관리자에게만 중요합니다.
19.9. ntpd 설정 파일 이해
데몬인 ntpd
는 시스템 시작 시 또는 서비스가 다시 시작될 때 구성 파일을 읽습니다. 파일의 기본 위치는 /etc/ntp.conf
이며 다음 명령을 입력하여 파일을 볼 수 있습니다.
~]$ less /etc/ntp.conf
설정 명령은 이 장의 뒷부분에서 간단히 설명합니다. 19.17절. “NTP 설정” 및 ntp.conf(5)
도움말 페이지에서 자세한 내용을 참조하십시오.
다음은 기본 구성 파일의 내용에 대한 간략한 설명입니다.
- 드리프트 파일 항목
드리프트 파일의 경로가 지정되어 있으며 Red Hat Enterprise Linux의 기본 항목은 다음과 같습니다.
driftfile /var/lib/ntp/drift
이 값을 변경한 경우
ntpd
에서 디렉터리에 쓸 수 있습니다. 파일에는 모든 시스템 또는 서비스 시작 후 시스템 클럭 빈도를 조정하는 데 사용되는 하나의 값이 포함되어 있습니다. 자세한 내용은 Drift 파일 이해를 참조하십시오.- 액세스 제어 항목
다음 줄은 기본 액세스 제어 제한을 설정합니다.
restrict default nomodify notrap nopeer noquery
-
nomodify
옵션은 설정을 변경할 수 없습니다. -
notrap
옵션은ntpdc
제어 메시지 프로토콜 트랩을 방지합니다. -
nopeer
옵션은 피어 연관이 형성되는 것을 방지합니다. noquery
옵션은ntpq
및ntpdc
쿼리를 허용하지만 시간 쿼리는 응답하지 않습니다.중요ntpq
및ntpdc
쿼리는 간소화 공격에 사용될 수 있으므로 공개적으로 액세스 가능한 시스템의restrict 기본
명령에서noquery
옵션을 제거하지 마십시오.자세한 내용은 CVE-2013-5211 을 참조하십시오.
127.0.0.0/8
범위 내의 주소는 다양한 프로세스 또는 애플리케이션에 필요한 경우가 있습니다. 위의 "제한 기본" 줄에 명시적으로 허용되지 않는 모든 항목에 대한 액세스를 차단하므로IPv4
및IPv6
에 대한 표준 루프백 주소에 대한 액세스는 다음 줄을 통해 허용됩니다.# the administrative functions. restrict 127.0.0.1 restrict ::1
주소를 다른 응용 프로그램에서 특별히 요구하는 경우 아래에 추가할 수 있습니다.
위의 "제한 기본" 라인으로 인해 로컬 네트워크의 호스트는 허용되지 않습니다. 예를 들어
192.0.2.0/24
네트워크의 호스트가 시간과 통계를 쿼리할 수 있도록 허용하려면 다음과 같은 형식의 행이 필요합니다.restrict 192.0.2.0 mask 255.255.255.0 nomodify notrap nopeer
특정 호스트에서 무제한 액세스를 허용하려면(예:
192.0.2.250/32
) 다음 형식의 행이 필요합니다.restrict 192.0.2.250
255.255.255.255
의 마스크는 지정되지 않은 경우 적용됩니다.restrict 명령은
ntp_acc(5)
도움말 페이지에 설명되어 있습니다.
-
- 공용 서버 항목
기본적으로
ntp.conf
파일에는 4개의 공용 서버 항목이 포함되어 있습니다.server 0.rhel.pool.ntp.org iburst server 1.rhel.pool.ntp.org iburst server 2.rhel.pool.ntp.org iburst server 3.rhel.pool.ntp.org iburst
- 브로드캐스트 멀티 캐스트 서버 항목
-
기본적으로
ntp.conf
파일에는 몇 가지 주석 처리된 예제가 포함되어 있습니다. 이는 대체로 자체 설명적입니다. 특정 명령에 대한 설명은 19.17절. “NTP 설정” 을 참조하십시오. 필요한 경우 예제 바로 아래에 명령을 추가합니다.
클라이언트 프로그램 dhclient 가 DHCP 서버에서 DHCP
NTP
서버 목록을 수신하면 해당 서버를 ntp.conf
에 추가하고 서비스를 다시 시작합니다. 해당 기능을 비활성화하려면 PEERNTP=no
를 /etc/sysconfig/network
에 추가합니다.
19.10. ntpd Sysconfig 파일 이해
이 파일은 service start의 ntpd
init 스크립트에서 읽습니다. 기본 내용은 다음과 같습니다.
# Command line options for ntpd OPTIONS="-g"
g 옵션을 사용하면 ntpd
가 1000s의 오프셋 제한을 무시하고 오프셋이 1000 s보다 큰 경우에도 시간을 동기화하려고 시도하지만 시스템 시작 시에만 해당 시간을 동기화합니다. 이 옵션이 없으면 시간 오프셋이 1000 s보다 크면 ntpd 가 종료됩니다. 또한 서비스를 다시 시작하고
-g
옵션을 사용하여 오프셋이 1000 s보다 크면 시스템 시작 후에도 종료됩니다.
19.11. chrony 비활성화
ntpd
를 기본 사용자 공간 데몬을 사용하려면 chronyd
를 중지하고 비활성화해야 합니다. root
로 다음 명령을 실행합니다.
~]# systemctl stop chronyd
시스템 시작 시 다시 시작되지 않도록 하려면 root
로 다음 명령을 실행합니다.
~]# systemctl disable chronyd
chronyd
의 상태를 확인하려면 다음 명령을 실행합니다.
~]$ systemctl status chronyd
19.12. NTP 데몬이 설치되었는지 확인
ntpd
가 설치되었는지 확인하려면 root
로 다음 명령을 입력합니다.
~]# yum install ntp
NTP
는 데몬 또는 서비스 ntpd
를 통해 구현되며, ntp 패키지에 포함됩니다.
19.13. NTP 데몬(ntpd) 설치
ntpd
를 설치하려면 root
로 다음 명령을 입력합니다.
~]# yum install ntp
시스템 시작 시 ntpd
를 활성화하려면 root
로 다음 명령을 입력합니다.
~]# systemctl enable ntpd
19.14. NTP 상태 확인
ntpd
가 실행 중인지 확인하고 시스템 시작 시 실행되도록 구성된 경우 다음 명령을 실행합니다.
~]$ systemctl status ntpd
ntpd
에서 간단한 상태 보고서를 얻으려면 다음 명령을 실행합니다.
~]$ ntpstat
unsynchronised
time server re-starting
polling server every 64 s
~]$ ntpstat
synchronised to NTP server (10.5.26.10) at stratum 2
time correct to within 52 ms
polling server every 1024 s
19.15. 향후 NTP 패킷을 허용하도록 방화벽 구성
NTP
트래픽은 포트 123
의 UDP
패킷으로 구성되며 NTP
가 작동하려면 네트워크 및 호스트 기반 방화벽을 통해 허용해야 합니다.
그래픽 방화벽 구성 도구를 사용하여 클라이언트에 대해 들어오는 NTP
트래픽을 허용하도록 방화벽 이 구성되었는지 확인합니다.
그래픽 firewall-config 도구를 시작하려면 Super 키를 눌러 활동 개요를 입력하고 방화벽
을 입력한 다음 Enter 를 누릅니다. 방화벽 구성
창이 열립니다. 사용자 암호를 입력하라는 메시지가 표시됩니다.
명령줄을 사용하여 그래픽 방화벽 구성 도구를 시작하려면 root
사용자로 다음 명령을 입력합니다.
~]# firewall-config
방화벽 구성
창이 열립니다. 참고 이 명령은 일반 사용자로 실행할 수 있지만 경우에 따라 루트
암호를 입력하라는 메시지가 표시됩니다.
왼쪽 아래에 있는 "연결됨"이라는 단어를 찾습니다. 이는 firewall-config 도구가 사용자 공간 데몬인 firewalld
에 연결되었음을 나타냅니다.
19.15.1. 방화벽 설정 변경
현재 방화벽 설정을 즉시 변경하려면 Configuration
(구성)이라는 드롭다운 선택 메뉴가 런타임
으로 설정되어 있는지 확인합니다. 또는 다음 시스템 시작 시 적용할 설정을 편집하려면 드롭다운 목록에서 Permanent
를 선택합니다.
런타임
모드에서 방화벽 설정을 변경할 때 선택 사항은 서비스와 관련된 확인란을 설정하거나 해제할 때 즉시 적용됩니다. 다른 사용자가 사용할 수 있는 시스템에서 작업할 때는 이 점을 염두에 두어야 합니다.
Permanent
모드에서 방화벽 설정을 변경할 때 방화벽을 다시 로드하거나 시스템을 다시 시작할 때만 선택이 적용됩니다. 방화벽을 다시 로드하려면 옵션 메뉴를 선택하고 다시 로드 방화벽
을 선택합니다.
19.15.2. NTP 패킷 방화벽에서 포트 열기
방화벽을 통한 트래픽을 특정 포트로 허용하려면 firewall-config 도구를 시작하고 설정을 변경할 네트워크 영역을 선택합니다. Ports
(포트) 탭을 선택한 다음 (추가) 버튼을 클릭합니다. 포트 및 프로토콜
창이 열립니다.
포트 번호 123
을 입력하고 드롭다운 목록에서 udp
를 선택합니다.
19.16. ntpdate 서버 구성
ntpdate
서비스의 용도는 시스템 부팅 중에 클럭을 설정하는 것입니다. 이는 ntpdate
이후에 시작된 서비스가 올바른 시간을 가지도록 하고 시계에서 건너뛰는 것을 관찰하지 못하도록 하기 위해 이전에 사용되었습니다. ntpdate
및 step-tickers 목록은 더 이상 사용되지 않으므로 Red Hat Enterprise Linux 7은 기본적으로 -g
옵션을 ntpdate
가 아닌 ntpd
명령에 사용합니다.
Red Hat Enterprise Linux 7의 ntpdate
서비스는 ntpd 서비스 없이 사용되거나
명령에 ntpd
-x
옵션이 지정된 경우 유용합니다. ntpd
를 -x
와 함께 사용하지만 ntpd 서비스가 활성화되지 않은 경우 시간 차이가 600초보다 큰 경우에만 클럭을 단계별로 수정합니다. 600초보다 작은 오프셋을 사용하면 클럭은 수정된 모든 시간 동안 약 2000초 동안 느리게 조정됩니다.
시스템을 시작할 때 ntpdate
서비스가 실행되도록 활성화되었는지 확인하려면 다음 명령을 실행합니다.
~]$ systemctl status ntpdate
시스템 시작 시 서비스가 실행되도록 하려면 root
로 다음 명령을 실행합니다.
~]# systemctl enable ntpdate
Red Hat Enterprise Linux 7의 기본 /etc/ntp/step-tickers
파일에는 0.rhel.pool.ntp.org
가 포함되어 있습니다. 추가 ntpdate
서버를 구성하려면 루트로
실행되는 텍스트 편집기를 사용하여 /etc/ntp/step-tickers
를 편집합니다. 등록된 서버 수는 매우 중요하지 않습니다. ntpdate
는 시스템을 시작할 때만 날짜 정보를 가져오는 데 이 정보를 사용합니다. 내부 시간 서버가 있는 경우 첫 번째 줄에 해당 호스트 이름을 사용합니다. 백업으로 두 번째 행에 있는 추가 호스트는 적합하지 않습니다. 백업 서버 선택 및 두 번째 호스트가 내부 또는 외부인지 여부는 위험 평가에 따라 달라집니다. 예를 들어 첫 번째 서버에 영향을 미치는 문제가 두 번째 서버에도 영향을 미칠 가능성은 얼마나 됩니까? 첫 번째 서버에 대한 액세스가 중단되는 경우 내부 서버에 연결하는 것보다 외부 서버에 대한 연결을 사용할 수 있을 가능성이 높습니까?
19.17. NTP 설정
NTP
서비스의 기본 구성을 변경하려면 root
사용자로 실행되는 텍스트 편집기를 사용하여 /etc/ntp.conf
파일을 편집합니다. 이 파일은 ntpd
와 함께 설치되며 기본적으로 Red Hat 풀의 시간 서버를 사용하도록 구성됩니다. man 페이지 ntp.conf(5)
는 ntp_acc(5)
도움말 페이지에 설명된 액세스 및 속도 제한 명령 외에도 구성 파일에서 사용할 수 있는 명령 옵션을 설명합니다.
19.17.1. NTP 서비스에 대한 액세스 제어 구성
시스템에서 실행 중인 NTP
서비스에 대한 액세스를 제한하거나 제어하려면 ntp.conf
파일에서 restrict
명령을 사용하십시오. 주석 처리된 예제를 참조하십시오.
# Hosts on local network are less restricted. #restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
restrict
명령은 다음 형식을 사용합니다.
restrict
address [mask mask] option
여기서 address 및 mask 는 제한을 적용할 IP 주소를 지정하고, 옵션 은 다음 중 하나 이상입니다.
-
ignore
- 모든 패킷은ntpq
및ntpdc
쿼리를 포함하여 무시됩니다. -
Ko
D - 원치 않는 쿼리를 줄이기 위해 "Kiss-o'-death" 패킷을 보낼 수 있습니다. -
제한
- 패킷이 속도 제한 기본값을 위반하는 경우 시간 서비스 요청에 응답하지 않습니다.ntpq
및ntpdc
쿼리는 영향을 받지 않습니다.discard
명령 및 기본값에 대한 자세한 내용은 19.17.2절. “NTP 서비스에 대한 속도 제한 액세스 구성” 을 참조하십시오. -
lowpriotrap
- 일치하는 호스트를 우선 순위가 낮은 것으로 설정하여 설정된 트랩입니다. -
nomodify
- 설정을 변경할 수 없습니다. -
noquery
-ntpq
및ntpdc
쿼리를 방지합니다. 그러나 시간 쿼리는 응답하지 않습니다. -
nopeer
- 피어 연결이 형성되는 것을 방지합니다. -
noserve
-ntpq
및ntpdc
쿼리를 제외한 모든 패킷을 거부합니다. -
Notrap
-ntpdc
제어 메시지 프로토콜 트랩을 방지합니다. -
notrust
- 암호로 인증되지 않은 패킷을 거부합니다. -
ntpport
- 소스 포트가 표준NTP
UDP
포트123
인 경우에만 제한 사항을 적용하도록 일치 알고리즘을 수정합니다. -
Version
- 현재NTP
버전과 일치하지 않는 패킷을 거부합니다.
쿼리에 전혀 응답하지 않도록 속도 제한 액세스를 구성하려면 각 제한
명령에 제한된
옵션이 있어야 합니다. ntpd
가 KoD
패킷으로 응답해야하는 경우 restrict
명령에는 제한
옵션과 kod
옵션이 모두 있어야 합니다.
ntpq
및 ntpdc
쿼리는 간소화 공격에 사용할 수 있습니다(자세한 내용은 CVE-2013-5211 참조) 공개적으로 액세스 가능한 시스템의 기본
명령에서 noquery
옵션을 제거하지 마십시오.
19.17.2. NTP 서비스에 대한 속도 제한 액세스 구성
시스템에서 실행 중인 NTP
서비스에 대한 속도 제한 액세스를 활성화하려면 19.17.1절. “NTP 서비스에 대한 액세스 제어 구성” 에 설명된 대로 제한
옵션을 제한
명령에 추가합니다. 기본 삭제 매개변수를 사용하지 않으려면 여기에 설명된 대로 삭제
명령도 사용합니다.
삭제
명령은 다음 형식을 취합니다.
discard
average
valueminimum
valuemonitor
value
-
average
- 허용되는 최소 평균 패킷 간격을 지정하고, log2 초 내에 인수를 허용합니다. 기본값은3(103) 과 8초입니다. -
minimum
- 허용되는 최소 패킷 간격을 지정하고, log2 초 내에 인수를 허용합니다. 기본값은1(10분2 초)입니다. -
Monitor
- 허용된 속도 제한을 초과하면 패킷의 삭제 가능성을 지정합니다. 기본값은 3000초입니다. 이 옵션은 초당 1000개 이상의 요청을 수신하는 서버용입니다.
삭제
명령의 예는 다음과 같습니다.
discard average 4
discard average 4 minimum 2
19.17.3. 피어 주소 추가
즉, 동일한 stratum의 NTP
서비스를 실행하는 서버의 주소를 추가하려면 ntp.conf
파일에서 peer
명령을 사용하십시오.
peer
명령은 다음과 같은 형식을 취합니다.
peer
address
여기서 address 는 IP
유니캐스트 주소이거나 DNS
확인 가능한 이름입니다. 주소는 동일한 계층 구조의 멤버로 알려진 시스템의 내용일 뿐입니다. 피어는 서로 다른 시간 소스를 하나 이상 보유해야 합니다. 피어는 일반적으로 동일한 관리 제어 시스템에 있습니다.
19.17.4. 서버 주소 추가
서버 주소를 추가하려면, 즉 더 높은 계층 시스템의 NTP
서비스를 실행하는 서버의 주소를 추가하고, ntp.conf
파일에서 server
명령을 사용합니다.
server
명령은 다음 형식을 취합니다.
server
address
여기서 address 는 IP
유니캐스트 주소이거나 DNS
확인 가능한 이름입니다. 패킷을 수신할 원격 참조 서버 또는 로컬 참조 클럭의 주소입니다.
19.17.5. 브로드캐스트 또는 멀티 캐스트 서버 주소 추가
전송을 위해 브로드캐스트 또는 멀티캐스트 주소를 추가하려면, 브로드캐스트 또는 멀티캐스트 NTP
패킷의 주소가 ntp.conf
파일에서 브로드캐스트
명령을 사용하십시오.
브로드캐스트 및 멀티 캐스트 모드에는 기본적으로 인증이 필요합니다. 19.6절. “NTP의 인증 옵션”을 참조하십시오.
broadcast
명령은 다음 형식을 취합니다.
broadcast
address
여기서 address 는 패킷이 전송되는 IP
브로드캐스트 또는 멀티캐스트 주소입니다.
이 명령은 NTP
브로드캐스트 서버로 작동하도록 시스템을 구성합니다. 사용된 주소는 브로드캐스트 또는 멀티캐스트 주소여야 합니다. 브로드캐스트 주소는 IPv4
주소 255.255.255.255
를 의미합니다. 기본적으로 라우터는 브로드캐스트 메시지를 전달하지 않습니다. 멀티캐스트 주소는 IPv4
클래스 D 주소 또는 IPv6
주소일 수 있습니다. IANA는 IPv4
멀티캐스트 주소 224.0.1.1
및 IPv6
주소 FF05::101
(site local)을 NTP
에 할당했습니다. RFC 2365 관리 범위 IP 멀티 캐스트에 설명된 대로 관리 범위가 지정된 IPv4
멀티캐스트 주소도 사용할 수 있습니다.
19.17.6. 멀티 캐스트 클라이언트 주소 추가
예를 들어 NTP
서버 검색에 사용할 멀티캐스트 주소를 구성하려면 ntp.conf
파일에서 manycastclient
명령을 사용합니다.
manycastclient
명령은 다음 형식을 취합니다.
manycastclient
address
여기서 address 는 패킷을 수신할 IP
멀티캐스트 주소입니다. 클라이언트는 주소로 요청을 보내고 응답에서 최상의 서버를 선택하고 다른 서버를 무시합니다. 그런 다음 NTP
통신에서는 검색된 NTP
서버가 ntp.conf
에 나열된 것처럼 유니캐스트 연결을 사용합니다.
이 명령은 NTP
클라이언트로 작동하도록 시스템을 구성합니다. 시스템은 클라이언트와 서버 모두를 동시에 수행할 수 있습니다.
19.17.7. Broadcast 클라이언트 주소 추가
브로드캐스트 NTP
패킷에 대해 모니터링할 브로드캐스트 주소를 구성하려면 ntp.conf
파일에서 broadcastclient
명령을 사용하십시오.
broadcastclient
명령은 다음 형식을 취합니다.
broadcastclient
브로드캐스트 메시지를 수신할 수 있습니다. 기본적으로 인증이 필요합니다. 19.6절. “NTP의 인증 옵션”을 참조하십시오.
이 명령은 NTP
클라이언트로 작동하도록 시스템을 구성합니다. 시스템은 클라이언트와 서버 모두를 동시에 수행할 수 있습니다.
19.17.8. 멀티 캐스트 서버 주소 추가
예를 들어, 클라이언트가 NTP
패킷을 멀티 캐스트하여 서버를 검색할 수 있도록 주소를 구성하려면 ntp.conf
파일에서 manycastserver
명령을 사용하십시오.
manycastserver
명령은 다음 형식을 취합니다.
manycastserver
address
멀티 캐스트 메시지 전송을 활성화합니다. 여기서 address 는 멀티 캐스트의 주소입니다. 이는 서비스 중단을 방지하기 위해 인증과 함께 사용해야 합니다.
이 명령은 NTP
서버 역할을 하는 시스템을 구성합니다. 시스템은 클라이언트와 서버 모두를 동시에 수행할 수 있습니다.
19.17.9. 멀티 캐스트 클라이언트 주소 추가
멀티 캐스트 클라이언트 주소를 추가하려면 멀티캐스트 NTP
패킷에 대해 모니터링할 멀티캐스트 주소를 구성하려면 ntp.conf
파일에서 multicastclient
명령을 사용하십시오.
multicastclient
명령은 다음 형식을 사용합니다.
multicastclient
address
멀티 캐스트 메시지 수신을 활성화합니다. 여기에서 address 는 서브스크립션할 주소입니다. 이는 서비스 중단을 방지하기 위해 인증과 함께 사용해야 합니다.
이 명령은 NTP
클라이언트로 작동하도록 시스템을 구성합니다. 시스템은 클라이언트와 서버 모두를 동시에 수행할 수 있습니다.
19.17.10. 버스트 옵션 구성
공용 서버에 대해 버스트
옵션을 사용하는 것은 악용으로 간주됩니다. 공용 NTP
서버에 이 옵션을 사용하지 마십시오. 조직 내의 애플리케이션에만 사용하십시오.
평균 시간 오프셋 통계를 늘리려면 서버 명령 끝에 다음 옵션을 추가합니다.
burst
모든 폴링 간격에서 서버가 응답할 때 시스템은 일반적인 하나의 패킷 대신 최대 8개의 패킷을 전송합니다. server
명령과 함께 사용하여 시계열 계산의 평균 품질을 개선할 수 있습니다.
19.17.11. iburst 옵션 구성
초기 동기화에 걸린 시간을 개선하려면 서버 명령 끝에 다음 옵션을 추가합니다.
iburst
서버에 연결할 수 없는 경우 일반적인 하나의 패킷 대신 8개의 패킷을 전송합니다. 패킷 간격은 일반적으로 2 s입니다; 그러나 첫 번째 패킷과 두 번째 패킷 사이의 간격은 calldelay
명령으로 변경할 수 있습니다. 모뎀이나 ISDN 호출에 대한 추가 시간을 허용하도록 calldelay 명령을 사용하여 변경할 수 있습니다. server
명령과 함께 사용하면 초기 동기화에 소요되는 시간을 줄일 수 있습니다. 이제 구성 파일의 기본 옵션입니다.
19.17.12. 키를 사용하여 Symmetric Authentication 구성
키를 사용하여 대칭 인증을 구성하려면 서버 또는 피어 명령 끝에 다음 옵션을 추가합니다.
key
number
여기서 숫자는 1
~65534 범위에
포함됩니다. 이 옵션을 사용하면 패킷에서 메시지 인증 코드(MAC )를사용할 수 있습니다. 이 옵션은 피어
,서버
, 브로드캐스트 및 manycastclient
명령과 함께 사용할 수 있습니다.
옵션은 다음과 같이 /etc/ntp.conf
파일에서 사용할 수 있습니다.
server 192.168.1.1 key 10 broadcast 192.168.1.255 key 20 manycastclient 239.255.254.254 key 30
자세한 내용은 19.6절. “NTP의 인증 옵션” 참조하십시오.
19.17.13. Poll Interval 구성
기본 폴링 간격을 변경하려면 server 또는 peer 명령 끝에 다음 옵션을 추가합니다.
minpoll
value andmaxpoll
value
기본 폴링 간격을 변경하는 옵션(초 단위)은 2를 값 의 거듭제곱으로 늘려 계산합니다. 즉, 간격은 log2 초로 표시됩니다. 기본 minpoll
값은 6, 26 이며 64 s입니다. maxpoll
의 기본값은 10이며 이는 1024 s입니다. 허용되는 값은 3~17포함 범위에 있으며 각각 8 s에서 36.4 h와 같습니다. 이러한 옵션은 피어
또는 서버와
함께 사용할 수 있습니다. maxpoll
을 더 짧게 설정하면 클럭 정확도가 향상될 수 있습니다.
19.17.14. 서버 환경 설정
특정 서버가 유사한 통계적 품질보다 우선하도록 지정하려면 서버 또는 피어 명령 끝에 다음 옵션을 추가합니다.
prefer
이 서버는 유사한 통계 품질의 다른 서버에 우선적으로 동기화되는 데 사용합니다. 이 옵션은 피어
또는 서버
명령과 함께 사용할 수 있습니다.
19.17.15. NTP 패킷에 대한 Time-to-Live 구성
특정TTL( Time-to-live ) 값을 기본값 대신 사용해야 함을 지정하려면 서버 또는 피어 명령 끝에 다음 옵션을 추가합니다.
ttl
value
브로드캐스트 서버 및 멀티 캐스트 NTP
서버에서 보낸 패킷에 사용할 TTL(Time-to-live) 값을 지정합니다. 많은 캐스트 클라이언트에서 "expanding ring search"에 사용할 최대 time-to-live 값을 지정합니다. 기본값은 127
입니다.
19.17.16. 사용할 NTP 버전 구성
특정 NTP
버전을 기본값 대신 사용하도록 지정하려면 서버 또는 피어 명령 끝에 다음 옵션을 추가합니다.
version
value
생성된 NTP
패킷에서 설정된 NTP
버전을 지정합니다. 값은 1
에서 4
까지의 범위일 수 있습니다. 기본값은 4
입니다.
19.18. 하드웨어 Clock 업데이트 구성
시스템 클럭은 실시간 클럭 (RTC)이라고도 하는 하드웨어 시계를 업데이트하는 데 사용할 수 있습니다. 이 섹션에서는 작업에 대한 세 가지 접근 방식을 보여줍니다.
- 즉시 1회 업데이트
하드웨어 시계의 즉시 일회성 업데이트를 수행하려면 다음 명령을 root로 실행하십시오.
~]# hwclock --systohc
- 모든 부팅 시 업데이트
ntpdate 동기화 유틸리티를 실행한 후 모든 부팅 시 하드웨어 클럭을 업데이트하려면 다음을 수행합니다.
/etc/sysconfig/ntpdate
파일에 다음 행을 추가합니다.SYNC_HWCLOCK=yes
ntpdate
서비스를 root로 활성화합니다.~]# systemctl enable ntpdate.service
ntpdate
서비스는/etc/ntp/step-tickers
파일에 정의된 NTP 서버를 사용합니다.참고가상 머신의 경우 가상 머신이 아닌 다음 호스트 시스템을 부팅할 때 하드웨어 시계가 업데이트됩니다.
- NTP를 통한 업데이트
ntpd
또는chronyd
서비스에서 시스템 시계를 업데이트할 때마다 하드웨어 클럭을 업데이트할 수 있습니다.ntpd
서비스를 root로 시작합니다.~]# systemctl start ntpd.service
부팅 후에도 동작이 지속되도록 하려면 부팅 시 서비스가 자동으로 시작되도록 합니다.
~]# systemctl enable ntpd.service
또는
chronyd
서비스를 root로 시작합니다.~]# systemctl start chronyd.service
부팅 후에도 동작이 지속되도록 하려면 부팅 시 서비스가 자동으로 시작되도록 합니다.
~]# systemctl enable chronyd.service
결과적으로 시스템 클럭이
ntpd
또는chronyd
에 의해 동기화될 때마다 커널은 11분 후에 하드웨어 클럭을 자동으로 업데이트합니다.주의위의 11 분 모드가 항상 활성화되어 있지 않기 때문에 이 방법이 항상 작동하지 않을 수 있습니다. 결과적으로 시스템 클럭 업데이트 시 하드웨어 클럭이 반드시 업데이트되지는 않습니다.
하드웨어 클럭과 소프트웨어 클럭의 동기화를 확인하려면
ntpdc -c kerninfo
또는ntptime
명령을root
로 사용하십시오.~]# ntpdc -c kerninfo
결과는 다음과 같습니다.
pll offset: 0 s pll frequency: 0.000 ppm maximum error: 8.0185 s estimated error: 0 s
status: 2001 pll nano
pll time constant: 6 precision: 1e-09 s frequency tolerance: 500 ppm또는
~]# ntptime
결과는 다음과 같습니다.
ntp_gettime() returns code 0 (OK) time dcba5798.c3dfe2e0 Mon, May 8 2017 11:34:00.765, (.765135199), maximum error 8010000 us, estimated error 0 us, TAI offset 0 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 0.000 us, frequency 0.000 ppm, interval 1 s, maximum error 8010000 us, estimated error 0 us, status 0x2001 (PLL,NANO), time constant 6, precision 0.001 us, tolerance 500 ppm,
하드웨어 클럭이 시스템 클럭에 동기화되는지 여부를 인식하려면 출력의 상태 행을 참조하십시오. 행에
unsync
또는UNSYNC
단어가 포함된 경우 하드웨어 클럭이 시스템 클럭에 동기화되지 않습니다.하드웨어 시계가 시스템 클럭에 동기화되어 있습니다.
status 0x2001 (PLL,NANO)
하드웨어 클럭은 시스템 클럭에 동기화되지 않습니다.
status 0x41 (PLL,UNSYNC)
19.19. Clock 소스 구성
시스템에서 사용 가능한 클럭 소스를 나열하려면 다음 명령을 실행합니다.
~]$ cd /sys/devices/system/clocksource/clocksource0/ clocksource0]$ cat available_clocksource kvm-clock tsc hpet acpi_pm clocksource0]$ cat current_clocksource kvm-clock
위의 예에서 커널은 kvm-clock 을 사용합니다. 부팅 시 가상 머신이므로 이 값이 선택되었습니다. 사용 가능한 클럭 소스는 아키텍처에 따라 다릅니다.
기본 클럭 소스를 재정의하려면 커널의 GRUB 2 메뉴 항목 끝에 clocksource
지시문을 추가합니다. grubby
도구를 사용하여 변경합니다. 예를 들어 시스템에서 tsc
clock 소스를 사용하도록 기본 커널을 강제 적용하려면 다음과 같이 명령을 입력합니다.
~]# grubby --args=clocksource=tsc --update-kernel=DEFAULT
--update-kernel
매개변수는 ALL
키워드 또는 쉼표로 구분된 커널 인덱스 번호 목록도 허용합니다.
GRUB 2 메뉴를 변경하는 방법에 대한 자세한 내용은 26장. Working with GRUB 2 를 참조하십시오.
19.20. 추가 리소스
다음 정보 소스는 NTP
및 ntpd
에 대한 추가 리소스를 제공합니다.
19.20.1. 설치된 문서
-
ntpd(8)
도움말 페이지 - 명령줄 옵션을 포함하여ntpd
를 자세히 설명합니다. -
NTP.conf(5) 도움말
페이지 - 서버 및 피어와의 연결을 구성하는 방법에 대한 정보가 포함되어 있습니다. -
ntpq(8)
도움말 페이지 -NTP
서버 모니터링 및 조회를 위한NTP
쿼리 유틸리티 설명. -
ntpdc(8)
도움말 페이지 -ntpd
의 상태를 쿼리하고 변경하기 위한ntpd
유틸리티에 대해 설명합니다. -
ntp_auth(5)
도움말 페이지 -ntpd
에 대한 인증 옵션, 명령 및 키 관리에 대해 설명합니다. -
ntp_keygen(8)
도움말 페이지 -ntpd
에 대한 공용 키와 개인 키를 생성하는 방법을 설명합니다. -
ntp_acc(5)
도움말 페이지 -restrict
명령을 사용하여 액세스 제어 옵션에 대해 설명합니다. -
ntp_mon(5)
도움말 페이지 - 통계 수집에 대한 모니터링 옵션에 대해 설명합니다. -
ntp_clock(5)
도움말 페이지 - 참조 클럭 구성을 위한 명령에 대해 설명합니다. -
ntp_misc(5)
도움말 페이지 - 기타 옵션에 대해 설명합니다. -
ntp_decode(5)
도움말 페이지 -ntpd
보고 및 모니터링에 사용되는 상태 단어, 이벤트 메시지 및 오류 코드를 나열합니다. -
ntpstat(8)
도움말 페이지 - 로컬 머신에서 실행 중인NTP
데몬의 동기화 상태를 보고하기 위한 유틸리티에 대해 설명합니다. -
ntptime(8)
도움말 페이지 - 커널 시간 변수를 읽고 설정하는 유틸리티에 대해 설명합니다. -
tickadj(8)
도움말 페이지 - 읽기 및 필요에 따라 틱의 길이를 설정하는 유틸리티에 대해 설명합니다.
19.20.2. 유용한 웹 사이트
- http://doc.ntp.org/
- NTP 문서 아카이브
- http://www.eecis.udel.edu/~mills/ntp.html
- 네트워크 시간 동기화 연구 프로젝트.
- http://www.eecis.udel.edu/~mills/ntp/html/manyopt.html
-
NTPv4
의 자동 서버 검색에 대한 정보입니다.
20장. ptp4l을 사용하여 PTP 구성
20.1. PTP 소개
PTP( Precision Time Protocol )는 네트워크에서 클럭을 동기화하는 데 사용되는 프로토콜입니다. 하드웨어 지원과 함께 사용하면 PTP
는 일반적으로 NTP
에서 얻을 수 있는 것보다 훨씬 더 나은 하위 마이크로초 정확도를 수행할 수 있습니다. PTP
지원은 커널 공간과 사용자 공간으로 나뉩니다. Red Hat Enterprise Linux의 커널에는 네트워크 드라이버에서 제공하는 PTP
클럭에 대한 지원이 포함되어 있습니다. 프로토콜의 실제 구현은 Linux의 IEEE 표준 1588에 따라 PTPv2
구현인 linuxptp 라고 합니다.
linuxptp 패키지에는 클럭 동기화를 위한 ptp4l 및 phc2sys 프로그램이 포함되어 있습니다. ptp4l 프로그램은 PTP
경계 클럭 및 일반 시계를 구현합니다. 하드웨어 타임스탬프를 사용하면 PTP
하드웨어 클럭을 마스터 클럭과 동기화하고 시스템 클럭을 마스터 클럭과 동기화합니다. phc2sys 프로그램은NIC( 네트워크 인터페이스 카드 )의 PTP
하드웨어 클럭에 시스템 클럭을 동기화하기 위해 하드웨어 타임 스탬프링과만 필요합니다.
20.1.1. PTP 이해
PTP
에 의해 동기화된 클럭은 마스터 슬레이브 계층 구조로 구성됩니다. 슬레이브는 자신의 마스터에 대한 슬레이브일 수 있는 마스터와 동기화됩니다. 계층 구조는 모든 클럭에서 실행되는 최상의 마스터 클럭 (BMC) 알고리즘에 의해 자동으로 생성 및 업데이트됩니다. 시계가 하나의 포트만 있으면 마스터 또는 슬레이브 일 수 있으며 이러한 시계를 일반 시계 (OC)라고 합니다. 여러 포트가 있는 시계를 다른 포트와 슬레이브에서 마스터할 수 있습니다. 이러한 시계를 경계 시계(BC)라고 합니다. 최상위 레벨 마스터는 할머 마스터 클럭 ( Global Positioning System (GPS) 시간 소스를 사용하여 동기화 할 수 있습니다. GPS 기반 시간 소스를 사용하면 분산된 네트워크를 높은 정확도와 동기화할 수 있습니다.
그림 20.1. PTP 할 수 있는 마스터, 경계 및 슬레이브 Clocks
20.1.2. PTP의 이점
PTP
가NTP( Network Time Protocol )를 초과하는 주요 이점 중 하나는 다양한NIC(네트워크 인터페이스 컨트롤러) 및 네트워크 스위치에 있는 하드웨어 지원입니다. 이 특수 하드웨어를 통해 PTP
는 메시지 전송 지연을 고려하여 시간 동기화의 정확도를 크게 향상시킵니다. 네트워크 내에서 PTP가 활성화된 하드웨어 구성 요소를 사용할 수는 있지만 종종 지터 증가를 유발하거나 지연에 대한 대칭을 도입하여 통신 경로에 사용되는 여러 가지 비PTP 인식 구성 요소와 함께 추가되는 경우가 있습니다. 최적의 정확도를 달성하기 위해 PTP 클럭 간의 모든 네트워킹 구성 요소가
하드웨어가 활성화된 것이 좋습니다. 모든 네트워킹 하드웨어가 PTP
PTP
를 지원하지 않는 대규모 네트워크의 시간 동기화가 NTP
에 더 적합할 수 있습니다.
하드웨어 PTP
지원을 통해 NIC에는 수신 및 전송된 PTP
메시지를 타임스탬프에 사용되는 자체 온보드 클럭이 있습니다. PTP
마스터에 동기화되는 이 온보드 클럭이며, 컴퓨터의 시스템 클럭은 NIC의 PTP
하드웨어 클럭에 동기화됩니다. 소프트웨어 PTP
지원을 통해 시스템 클럭은 PTP
메시지를 타임 스탬프하는 데 사용되며 PTP
마스터와 직접 동기화됩니다. 하드웨어 PTP
지원은 소프트웨어 PTP 지원에서 운영 체제의 PTP
패킷을 추가로 처리해야 하는 동안 전송 및 수신되는 정확한 순간에
패킷을 타임 스탬프할 수 있기 때문에 더 나은 정확도를 제공합니다.
PTP
20.2. PTP 사용
PTP
를 사용하기 위해 의도된 인터페이스용 커널 네트워크 드라이버는 소프트웨어 또는 하드웨어 타임스탬프 기능을 지원해야 합니다.
20.2.1. 드라이버 및 하드웨어 지원 확인
드라이버에 하드웨어 타임스탬프 지원 외에도 NIC는 물리적 하드웨어에서 이 기능을 지원할 수 있어야 합니다. 특정 드라이버 및 NIC의 타임스탬프 기능을 확인하는 가장 좋은 방법은 ethtool 유틸리티를 사용하여 인터페이스를 쿼리하는 것입니다. 이 예에서 eth3 는 확인하려는 인터페이스입니다.
~]# ethtool -T eth3 Time stamping parameters for eth3: Capabilities: hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) PTP Hardware Clock: 0 Hardware Transmit Timestamp Modes: off (HWTSTAMP_TX_OFF) on (HWTSTAMP_TX_ON) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) all (HWTSTAMP_FILTER_ALL)
ethtool
에서 출력한 PTP 하드웨어 클럭
값은 PTP 하드웨어 클록의 인덱스입니다. /dev/ptp*
장치의 이름에 해당합니다. 첫 번째 C에는 인덱스가 0입니다.
소프트웨어 타임스탬프 지원의 경우 매개 변수 목록에 다음이 포함되어야 합니다.
-
SOF_TIMESTAMPING_SOFTWARE
-
SOF_TIMESTAMPING_TX_SOFTWARE
-
SOF_TIMESTAMPING_RX_SOFTWARE
하드웨어 타임스탬프 지원의 경우 매개변수 목록에 다음이 포함되어야 합니다.
-
SOF_TIMESTAMPING_RAW_HARDWARE
-
SOF_TIMESTAMPING_TX_HARDWARE
-
SOF_TIMESTAMPING_RX_HARDWARE
20.2.2. PTP 설치
Red Hat Enterprise Linux의 커널에는 PTP
가 포함되어 있습니다. 사용자 공간 지원은 linuxptp 패키지의 도구를 통해 제공됩니다. linuxptp 를 설치하려면 root
로 다음 명령을 실행합니다.
~]# yum install linuxptp
이렇게 하면 ptp4l 및 phc2sys 가 설치됩니다.
시스템 클럭을 동시에 설정하기 위해 둘 이상의 서비스를 실행하지 마십시오. NTP
를 사용하여 PTP
시간을 제공하려는 경우 20.8절. “NTP를 사용하여 PTP 시간 제공” 을 참조하십시오.
20.2.3. ptp4l 시작
ptp4l 프로그램은 명령줄에서 시작하거나 서비스로 시작할 수 있습니다. 서비스로 실행하는 경우 /etc/sysconfig/ptp4l
파일에 옵션이 지정됩니다. 서비스와 명령줄에서 모두 사용하는 데 필요한 옵션은 /etc/ptp4l.conf
파일에 지정해야 합니다. /etc/sysconfig/
파일에는 ptp4l
-f /etc/ptp4l.conf
명령줄 옵션이 포함되어 있으며, 이로 인해 ptp4l 프로그램이 /etc/ptp4l.conf
파일을 읽고 포함된 옵션을 처리합니다. /etc/ptp4l.conf
의 사용은 20.4절. “구성 파일 지정” 에 설명되어 있습니다. 다른 ptp4l 옵션 및 구성 파일 설정에 대한 자세한 내용은 ptp4l(8)
매뉴얼 페이지에서 확인할 수 있습니다.
ptp4l을 서비스로 시작
ptp4l 을 서비스로 시작하려면 root
로 다음 명령을 실행합니다.
~]# systemctl start ptp4l
Red Hat Enterprise Linux 7에서 시스템 서비스 관리에 대한 자세한 내용은 10장. systemd를 사용하여 서비스 관리 를 참조하십시오.
명령줄에서 ptp4l 사용
ptp4l 프로그램은 기본적으로 하드웨어 타임 스탬프를 사용하려고 합니다. ptp4l 을 하드웨어 타임 스탬프링 가능 드라이버 및 NIC와 함께 사용하려면 -i
옵션과 함께 사용할 네트워크 인터페이스를 제공해야 합니다. root
로 다음 명령을 입력하십시오.
~]# ptp4l -i eth3 -m
여기서 eth3 는 구성할 인터페이스입니다. 다음은 NIC의 PTP
시계가 마스터에 동기화될 때 ptp4l 의 출력 예입니다.
~]# ptp4l -i eth3 -m selected eth3 as PTP clock port 1: INITIALIZING to LISTENING on INITIALIZE port 0: INITIALIZING to LISTENING on INITIALIZE port 1: new foreign master 00a069.fffe.0b552d-1 selected best master clock 00a069.fffe.0b552d port 1: LISTENING to UNCALIBRATED on RS_SLAVE master offset -23947 s0 freq +0 path delay 11350 master offset -28867 s0 freq +0 path delay 11236 master offset -32801 s0 freq +0 path delay 10841 master offset -37203 s1 freq +0 path delay 10583 master offset -7275 s2 freq -30575 path delay 10583 port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED master offset -4552 s2 freq -30035 path delay 10385
마스터 오프셋 값은 나노초 단위로 마스터에서 측정된 오프셋입니다. s0
,s1
,s2
문자열은 다른 클럭 서지 상태를 나타냅니다. s0
의 잠금 해제, s1
은 클럭 단계이며 s2
가 잠겼습니다. 서비스가 잠긴 상태(s2
)에 있으면 pi_offset_const
옵션이 구성 파일에서 양수 값으로 설정되어 있지 않으면(보통 ptp4l(8)
도움말 페이지에 설명됨) 클럭은 단계되지 않습니다(예: ptp4l(8) 도움말 페이지에 설명됨). adj
값은 10억 개당 부분(ppb)에서 클럭의 빈도 조정입니다. 경로 지연 값은 나노초 단위의 마스터에서 전송된 동기화 메시지의 예상 지연입니다. 포트 0은 로컬 PTP
관리에 사용되는 Unix 도메인 소켓입니다. 포트 1은 eth3
인터페이스(위의 예를 기반으로 함)입니다. INITIALIZING, LISTENING,UNCALIBRATED 및 SLAVE는 INITIALIZE, RS_SLAVE, RS_CLOCK_SELEED 이벤트에서 변경될 수 있는 포트 상태 중 일부입니다. 마지막 상태 변경 메시지에서 포트 상태가 happensALIBRATED에서 SLAVE로 변경되었습니다. 이는 PTP
마스터 클럭을 사용한 성공적인 동기화를 나타냅니다.
ptp4l에서 메시지 로깅
기본적으로 메시지는 /var/log/message
으로 전송됩니다. 그러나 -m
옵션을 지정하면 디버깅에 유용할 수 있는 표준 출력에 로깅할 수 있습니다.
소프트웨어 타임스탬프를 활성화하려면 다음과 같이 -S
옵션을 사용해야 합니다.
~]# ptp4l -i eth3 -m -S
20.2.3.1. Delay measuredment Mechanism 선택
두 가지 지연 측정 메커니즘이 있으며 다음과 같이 ptp4l
명령에 옵션을 추가하여 선택할 수 있습니다.
-P
P2
P
는 피어 투 피어 (P2P) 지연 측정 메커니즘을 선택합니다.P2P 메커니즘은 네트워크 토폴로지의 변경에 더 빨리 반응하므로 선호되며 다른 메커니즘보다 지연을 측정하는 데 더 정확할 수 있습니다. P2P 메커니즘은 각 포트가 최대 다른 P2P 포트와 PTP 메시지를 교환하는 토폴로지에서만 사용할 수 있습니다. 통신 경로에서 투명한 클럭을 포함한 모든 하드웨어에서 지원 및 사용해야 합니다.
-E
e는 엔드 투 엔드 (
E
2E) 지연 측정 메커니즘을 선택합니다. 이는 기본값입니다.E2E 메커니즘은 지연 "request-response" 메커니즘이라고도 합니다.
-A
A를 사용하면 지연 측정 메커니즘을 자동으로 선택할 수 있습니다.
자동 옵션은 E2E 모드에서 ptp4l 을 시작합니다. 피어 지연 요청이 수신되는 경우 P2P 모드로 변경됩니다.
단일 PTP
통신 경로의 모든 클럭은 동일한 메커니즘을 사용하여 지연을 측정해야 합니다. 경고는 다음과 같은 경우에 인쇄됩니다.
- E2E 메커니즘을 사용하여 포트에서 피어 지연 요청이 수신되는 경우
- P2P 메커니즘을 사용하여 포트에서 E2E 지연 요청이 수신되면.
20.3. 여러 인터페이스에서 PTP 사용
다른 네트워크에 여러 인터페이스가 있는 PTP를 사용하는 경우 역방향 경로 전달 모드를 느슨한 모드로 변경해야 합니다. Red Hat Enterprise Linux 7은 기본적으로 RFC 3704의 Strict Reverse Path Forwarding, Multihomed Networks의 Ingress 필터링에 따라 Strict Reverse Path Forwarding를 사용합니다. 자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드 의 역행 경로 전달 섹션을 참조하십시오.
sysctl
유틸리티는 커널의 튜닝 가능 항목에 값을 읽고 쓰는 데 사용됩니다. 실행 중인 시스템을 변경하려면 명령줄에서 직접 sysctl
명령을 사용하여 변경할 수 있으며 /etc/sysctl.conf
파일에 행을 추가하여 영구적으로 변경할 수 있습니다.
전역적으로 느슨한 모드 필터링으로 변경하려면
root
로 다음 명령을 입력합니다.~]# sysctl -w net.ipv4.conf.default.rp_filter=2 ~]# sysctl -w net.ipv4.conf.all.rp_filter=2
네트워크 인터페이스당 역방향 경로 필터링 모드를 변경하려면 모든 PTP 인터페이스에서
net.ipv4.interface.rp_filter
명령을 사용합니다. 예를 들어 장치 이름em1
의 경우:~]# sysctl -w net.ipv4.conf.em1.rp_filter=2
재부팅해도 이러한 설정을 영구적으로 설정하려면 /etc/sysctl.conf
파일을 수정합니다. 모든 인터페이스 또는 특정 인터페이스에 대한 모드를 변경할 수 있습니다.
모든 인터페이스의 모드를 변경하려면 root
사용자로 실행 중인 편집기를 사용하여 /etc/sysctl.conf
파일을 열고 다음과 같이 행을 추가합니다.
net.ipv4.conf.all.rp_filter=2
특정 인터페이스만 변경하려면 다음 형식으로 여러 행을 추가합니다.
net.ipv4.conf.interface.rp_filter=2
모든 및 특정 인터페이스에 대한 설정을 사용하는 경우 각 인터페이스에서 소스 검증을 수행할 때 conf/{all,interface}/rp_filter
의 최대 값도 사용됩니다.
기본 설정을 사용하여 모드를 변경할 수도 있습니다. 즉, 새로 생성된 인터페이스에만 적용됩니다.
sysctl
매개변수의 모든,default 또는 특정 장치 설정을 사용하는 방법에 대한 자세한 내용은 Red Hat Knowledgebase 문서 "all", "default" 및 sysctl 매개변수의 특정 장치? 를 참조하십시오.
부팅 프로세스 중 sysctl
서비스 타이밍으로 인해 두 가지 유형의 문제가 발생할 수 있습니다.
드라이버는
sysctl
서비스가 실행되기 전에 로드됩니다.이 경우 영향을 받는 네트워크 인터페이스는 커널에서 사전 설정된 모드를 사용하며
sysctl
기본값은 무시됩니다.이 문제에 대한 해결 방법은 Red Hat 지식베이스 문서 "all", "default" 및 sysctl 매개변수의 특정 장치 차이점 을 참조하십시오.
sysctl
서비스가 실행된 후 드라이버가 로드되거나 다시 로드됩니다.이 경우 재부팅 후 일부
sysctl.conf
매개변수를 사용하지 않을 수 있습니다. 이러한 설정은 사용할 수 없거나 기본값으로 돌아갈 수 있습니다.이 문제의 해결 방법은 Red Hat Knowledgebase 문서 일부 sysctl.conf 매개 변수가 재부팅 후에도 사용되지 않으며 설정을 수동으로 조정하는 것이 예상대로 작동하는 것을 참조하십시오.
20.4. 구성 파일 지정
명령줄에서 설정할 수 없는 명령행 옵션 및 기타 옵션은 선택적 구성 파일에 설정할 수 있습니다.
기본적으로 구성 파일을 읽을 수 없으므로 런타임 시 -f
옵션을 사용하여 지정해야 합니다. 예를 들면 다음과 같습니다.
~]# ptp4l -f /etc/ptp4l.conf
위에 표시된 -i eth3 -m -S
옵션과 동등한 구성 파일은 다음과 같습니다.
~]# cat /etc/ptp4l.conf [global] verbose 1 time_stamping software [eth3]
20.5. PTP 관리 클라이언트 사용
PTP
관리 클라이언트인 pmc 는 다음과 같이 ptp4l 에서 추가 정보를 얻는 데 사용할 수 있습니다.
~]# pmc -u -b 0 'GET CURRENT_DATA_SET' sending: GET CURRENT_DATA_SET 90e2ba.fffe.20c7f8-0 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET stepsRemoved 1 offsetFromMaster -142.0 meanPathDelay 9310.0
~]# pmc -u -b 0 'GET TIME_STATUS_NP' sending: GET TIME_STATUS_NP 90e2ba.fffe.20c7f8-0 seq 0 RESPONSE MANAGMENT TIME_STATUS_NP master_offset 310 ingress_time 1361545089345029441 cumulativeScaledRateOffset +1.000000000 scaledLastGmPhaseChange 0 gmTimeBaseIndicator 0 lastGmPhaseChange 0x0000'0000000000000000.0000 gmPresent true gmIdentity 00a069.fffe.0b552d
-b
옵션을 0
으로 설정하면 로컬에서 실행 중인 ptp4l 인스턴스로 경계가 제한됩니다. 더 큰 경계 값은 로컬 클럭에서 추가로 PTP
노드에서 정보를 검색합니다. 복구 가능한 정보는 다음과 같습니다.
-
단계Removed
는 할아버지 시계에 대한 통신 경로의 수입니다. -
offsetFrom Master
및 master_offset은 나노초 단위의 마스터에서 마지막 측정된 클럭 오프셋입니다. -
meanPathDelay
는 나노초 단위의 마스터에서 전송된 동기화 메시지의 예상 지연입니다. -
gmPresent
가 true인 경우PTP
클럭은 마스터와 동기화되며 로컬 시계는 할머마스터 시계가 아닙니다. -
gmIdentity
은 할 수 없는 마스터의 ID입니다.
pmc 명령의 전체 목록은 다음을 root
로 입력합니다.
~]# pmc help
추가 정보는 pmc(8)
도움말 페이지에서 확인할 수 있습니다.
20.6. 시계 동기화
phc2sys 프로그램은 시스템 클럭을 NIC의 PTP
하드웨어 클럭 (kubeconfigC )과동기화하는 데 사용됩니다. phc2sys 서비스는 /etc/sysconfig/phc2sys
구성 파일에서 구성됩니다. /etc/sysconfig/phc2sys
파일의 기본 설정은 다음과 같습니다.
OPTIONS="-a -r"
a 옵션을 사용하면 phc2sys 가 ptp4l 애플리케이션에서 시계를 동기화합니다.
PTP
포트 상태의 변경 사항을 준수하여 NIC 하드웨어 클럭 간의 동기화를 적절하게 조정합니다. -r
옵션도 지정하지 않는 한 시스템 클럭은 동기화되지 않습니다. 시스템 클럭을 시간 소스가 될 수 있도록 하려면 -r
옵션을 두 번 지정합니다.
/etc/sysconfig/phc2sys
를 변경한 후 root
로 명령을 실행하여 명령줄에서 phc2sys 서비스를 다시 시작합니다.
~]# systemctl restart phc2sys
정상적인 상황에서는 systemctl
명령을 사용하여 phc2sys 서비스를 시작, 중지 및 다시 시작합니다.
phc2sys 를 서비스로 시작하지 않으려면 명령줄에서 시작할 수 있습니다. 예를 들어 root
로 다음 명령을 입력합니다.
~]# phc2sys -a -r
a 옵션을 사용하면 phc2sys 가 ptp4l 애플리케이션에서 시계를 동기화합니다. 시스템 클럭을 시간 소스가 될 수 있도록 하려면
-r
옵션을 두 번 지정합니다.
또는 -s
옵션을 사용하여 시스템 클럭을 특정 인터페이스의 PTP
하드웨어 시계와 동기화합니다. 예를 들면 다음과 같습니다.
~]# phc2sys -s eth3 -w
-w
옵션은 실행중인 ptp4l 애플리케이션이 PTP
클럭을 동기화한 다음, ptp4l 에서 UTC 오프셋으로 TAI 를 검색합니다.
일반적으로 PTP
는 국제 Atomic Time (TAI) 타임스케일에서 작동하지만 시스템 시계는UTC( 협정 세계시) 로 유지됩니다. TAI와 UTC 타임스케일 사이의 현재 오프셋은 36초입니다. 도약 초를 삽입하거나 삭제할 때 오프셋이 변경되어 일반적으로 몇 년 마다 발생합니다. 다음과 같이 -w
를 사용하지 않을 때 이 오프셋을 수동으로 설정하는 데 -O
옵션을 사용해야 합니다.
~]# phc2sys -s eth3 -O -36
phc2sys servo가 잠긴 상태이면 -S
옵션을 사용하지 않는 한 클럭은 축소되지 않습니다. 즉, ptp4l 프로그램이 PTP
하드웨어 클럭을 동기화한 후에 phc2sys 프로그램을 시작해야 합니다. 그러나 -w
를 사용하면 시계를 동기화할 때까지 대기하므로 ptp4l 후에 phc2sys 를 시작할 필요가 없습니다.
phc2sys 프로그램은 다음을 실행하여 서비스로 시작할 수도 있습니다.
~]# systemctl start phc2sys
서비스로 실행하는 경우 /etc/sysconfig/phc2sys
파일에 옵션이 지정됩니다. 다양한 phc2sys 옵션에 대한 자세한 내용은 phc2sys(8)
매뉴얼 페이지에서 확인할 수 있습니다.
이 섹션의 예제에서는 명령이 슬레이브 시스템 또는 슬레이브 포트에서 실행된다고 가정합니다.
20.7. 시간 동기화 확인
PTP
시간 동기화가 올바르게 작동하면 하드웨어 시간 스탬프가 사용되는 경우 오프셋 및 빈도 조정을 포함하는 새 메시지가 주기적으로 ptp4l 및 phc2sys 출력에 출력됩니다. 출력 값이 곧 통합되었습니다. 이러한 메시지는 /var/log/inspector
파일에서 확인할 수 있습니다.
ptp4l 및 phc2sys 출력의 다음 예는 다음과 같습니다.
- 오프셋(나노초)
- 빈도 오프셋 (억 개당 부분) (ppb)
- 경로 지연 (나노초)
ptp4l 출력의 예는 다음과 같습니다.
ptp4l[352.359]: selected /dev/ptp0 as PTP clock ptp4l[352.361]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[352.361]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[353.210]: port 1: new foreign master 00a069.fffe.0b552d-1 ptp4l[357.214]: selected best master clock 00a069.fffe.0b552d ptp4l[357.214]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[359.224]: master offset 3304 s0 freq +0 path delay 9202 ptp4l[360.224]: master offset 3708 s1 freq -29492 path delay 9202 ptp4l[361.224]: master offset -3145 s2 freq -32637 path delay 9202 ptp4l[361.224]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[362.223]: master offset -145 s2 freq -30580 path delay 9202 ptp4l[363.223]: master offset 1043 s2 freq -29436 path delay 8972 ptp4l[364.223]: master offset 266 s2 freq -29900 path delay 9153 ptp4l[365.223]: master offset 430 s2 freq -29656 path delay 9153 ptp4l[366.223]: master offset 615 s2 freq -29342 path delay 9169 ptp4l[367.222]: master offset -191 s2 freq -29964 path delay 9169 ptp4l[368.223]: master offset 466 s2 freq -29364 path delay 9170 ptp4l[369.235]: master offset 24 s2 freq -29666 path delay 9196 ptp4l[370.235]: master offset -375 s2 freq -30058 path delay 9238 ptp4l[371.235]: master offset 285 s2 freq -29511 path delay 9199 ptp4l[372.235]: master offset -78 s2 freq -29788 path delay 9204
phc2sys 출력 예:
phc2sys[526.527]: Waiting for ptp4l... phc2sys[527.528]: Waiting for ptp4l... phc2sys[528.528]: phc offset 55341 s0 freq +0 delay 2729 phc2sys[529.528]: phc offset 54658 s1 freq -37690 delay 2725 phc2sys[530.528]: phc offset 888 s2 freq -36802 delay 2756 phc2sys[531.528]: phc offset 1156 s2 freq -36268 delay 2766 phc2sys[532.528]: phc offset 411 s2 freq -36666 delay 2738 phc2sys[533.528]: phc offset -73 s2 freq -37026 delay 2764 phc2sys[534.528]: phc offset 39 s2 freq -36936 delay 2746 phc2sys[535.529]: phc offset 95 s2 freq -36869 delay 2733 phc2sys[536.529]: phc offset -359 s2 freq -37294 delay 2738 phc2sys[537.529]: phc offset -257 s2 freq -37300 delay 2753 phc2sys[538.529]: phc offset 119 s2 freq -37001 delay 2745 phc2sys[539.529]: phc offset 288 s2 freq -36796 delay 2766 phc2sys[540.529]: phc offset -149 s2 freq -37147 delay 2760 phc2sys[541.529]: phc offset -352 s2 freq -37395 delay 2771 phc2sys[542.529]: phc offset 166 s2 freq -36982 delay 2748 phc2sys[543.529]: phc offset 50 s2 freq -37048 delay 2756 phc2sys[544.530]: phc offset -31 s2 freq -37114 delay 2748 phc2sys[545.530]: phc offset -333 s2 freq -37426 delay 2747 phc2sys[546.530]: phc offset 194 s2 freq -36999 delay 2749
ptp4l 출력을 줄이고 값만 출력하려면 summary_interval
지시문을 사용합니다. summary_interval
지시문은 2의 power에 대해 초 단위로 지정됩니다. 예를 들어 출력을 1024
초마다 줄이려면 /etc/ptp4l.conf
파일에 다음 행을 추가합니다.
summary_interval 10
summary_interval
이 6으로 설정된 ptp4l 출력의 예는 다음과 같습니다.
ptp4l: [615.253] selected /dev/ptp0 as PTP clock ptp4l: [615.255] port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l: [615.255] port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l: [615.564] port 1: new foreign master 00a069.fffe.0b552d-1 ptp4l: [619.574] selected best master clock 00a069.fffe.0b552d ptp4l: [619.574] port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l: [623.573] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l: [684.649] rms 669 max 3691 freq -29383 ± 3735 delay 9232 ± 122 ptp4l: [748.724] rms 253 max 588 freq -29787 ± 221 delay 9219 ± 158 ptp4l: [812.793] rms 287 max 673 freq -29802 ± 248 delay 9211 ± 183 ptp4l: [876.853] rms 226 max 534 freq -29795 ± 197 delay 9221 ± 138 ptp4l: [940.925] rms 250 max 562 freq -29801 ± 218 delay 9199 ± 148 ptp4l: [1004.988] rms 226 max 525 freq -29802 ± 196 delay 9228 ± 143 ptp4l: [1069.065] rms 300 max 646 freq -29802 ± 259 delay 9214 ± 176 ptp4l: [1133.125] rms 226 max 505 freq -29792 ± 197 delay 9225 ± 159 ptp4l: [1197.185] rms 244 max 688 freq -29790 ± 211 delay 9201 ± 162
기본적으로 summary_interval
은 0으로 설정되므로 메시지는 최대 빈도인 초당 한 번 인쇄됩니다. 메시지는 LOG_INFO 수준에 기록됩니다. 메시지를 비활성화하려면 -l
옵션을 사용하여 최대 로그 수준을 5 이하로 설정합니다.
~]# phc2sys -l 5
-u
옵션을 사용하여 phc2sys 출력을 줄일 수 있습니다.
~]# phc2sys -u summary-updates
여기서 summary-updates 는 요약 통계에 포함할 클럭 업데이트의 수입니다. 예를 들면 다음과 같습니다.
~]# phc2sys -s eth3 -w -m -u 60 phc2sys[700.948]: rms 1837 max 10123 freq -36474 ± 4752 delay 2752 ± 16 phc2sys[760.954]: rms 194 max 457 freq -37084 ± 174 delay 2753 ± 12 phc2sys[820.963]: rms 211 max 487 freq -37085 ± 185 delay 2750 ± 19 phc2sys[880.968]: rms 183 max 440 freq -37102 ± 164 delay 2734 ± 91 phc2sys[940.973]: rms 244 max 584 freq -37095 ± 216 delay 2748 ± 16 phc2sys[1000.979]: rms 220 max 573 freq -36666 ± 182 delay 2747 ± 43 phc2sys[1060.984]: rms 266 max 675 freq -36759 ± 234 delay 2753 ± 17
이러한 옵션과 함께 사용하면 통계 업데이트 간격이 60초(-u
), phc2sys
가 동기화 상태가 될 때까지 대기하고 메시지가 표준 출력(
)으로 출력됩니다. -
mphc2sys
옵션에 대한 자세한 내용은 phc2sys(5)
매뉴얼 페이지를 참조하십시오.
출력에는 다음이 포함됩니다.
- 오프셋 루트는 사각형(rms)을 의미합니다.
- 최대 절대 오프셋 (max)
- 빈도 오프셋(freq): 평균 및 표준 편차
- 경로 지연(delay): 평균 및 표준 편차
20.8. NTP를 사용하여 PTP 시간 제공
LOCAL 참조 클럭 드라이버를 사용하여 ptp4l 또는 phc2sys 로 동기화된 시스템 클럭에서 시간을 배포하도록 ntpd
데몬을 구성할 수 있습니다. ntpd
가 시스템 클럭을 조정하지 못하도록 ntp.conf
파일은 NTP
서버를 지정해서는 안 됩니다. 다음은 ntp.conf
의 최소 예입니다.
~]# cat /etc/ntp.conf server 127.127.1.0 fudge 127.127.1.0 stratum 0
클라이언트 프로그램 dhclient 가 DHCP 서버에서 DHCP
NTP
서버 목록을 수신하면 해당 서버를 ntp.conf
에 추가하고 서비스를 다시 시작합니다. 해당 기능을 비활성화하려면 PEERNTP=no
를 /etc/sysconfig/network
에 추가합니다.
20.9. PTP를 사용하여 NTP 시간 제공
반면 NTP
에서 PTP
동기화를 수행할 수도 있습니다. ntpd
가 시스템 클럭을 동기화하는 데 사용되는 경우, ptp4l 은 priority1
옵션(또는 최상의 마스터 클럭 알고리즘에 포함된 다른 클럭 옵션)을 사용하여 구성할 수 있으며 PTP
를 통해 시스템 클럭으로부터 시간을 분배할 수 있습니다.
~]# cat /etc/ptp4l.conf [global] priority1 127 [eth3] # ptp4l -f /etc/ptp4l.conf
하드웨어 타임스탬프를 사용하면 PTP
하드웨어 클럭을 시스템 클럭과 동기화하는 데 phc2sys 를 사용해야 합니다. phc2sys 를 서비스로 실행하는 경우 /etc/sysconfig/phc2sys
구성 파일을 편집합니다. /etc/sysconfig/phc2sys
파일의 기본 설정은 다음과 같습니다.
OPTIONS="-a -r"
루트
로서 다음과 같이 해당 행을 편집합니다.
~]# vi /etc/sysconfig/phc2sys OPTIONS="-a -r -r"
r 옵션은 시스템 클럭에서 NIC에서 PTP
하드웨어 클럭의 동기화를 허용하기 위해 두 번 사용됩니다. 변경 사항을 적용하려면 phc2sys 서비스를 다시 시작하십시오.
~]# systemctl restart phc2sys
PTP
클럭 빈도의 신속한 변경을 방지하기 위해, 시스템 클럭에 대한 동기화는 P
(프로포션)(proportional) 및 I
(integral) 상수를 사용하여 느슨할 수 있습니다.
~]# phc2sys -a -r -r -P 0.01 -I 0.0001
20.10. timemaster를 사용하여 PTP 또는 NTP 시간 동기화
네트워크에 사용 가능한 PTP
도메인이 여러 개 있거나 NTP
를 대체해야 하는 경우 timemaster 프로그램을 사용하여 시스템 클럭을 모든 사용 가능한 시간 소스와 동기화할 수 있습니다. PTP
시간은 공유 메모리 드라이버를 통해 phc2sys 및 ptp4l 에 의해 제공됩니다(시스템에 구성된 NTP
데몬에 따라SHM 참조 클럭을 chronyd
또는 ntpd
로 참조). 그런 다음 NTP
데몬은 PTP
및 NTP
모두 모든 시간 소스를 비교하고 최상의 소스를 사용하여 시스템 시계를 동기화할 수 있습니다.
시작시, 타임마스터는 NTP
및 PTP
시간 소스를 지정하는 구성 파일을 읽고, 어떤 네트워크 인터페이스에 고유한 PTP
하드웨어 클럭 (PHC)이 있는지 확인하고, ptp4l 및 chronyd
또는 ntpd
에 대한 구성 파일을 생성하고, ptp4l 을 시작합니다. 필요에 따라 phc2sys 및 chronyd
또는 ntpd
프로세스. 종료 시 생성된 구성 파일이 제거됩니다. chronyd
,ntpd
및 ptp4l 의 구성 파일을 /var/run/timemaster/
에 씁니다.
20.10.1. 서비스로 Timemaster 시작
timemaster 를 서비스로 시작하려면 root
로 다음 명령을 실행합니다.
~]# systemctl start timemaster
그러면 /etc/timemaster.conf
의 옵션이 표시됩니다. Red Hat Enterprise Linux 7에서 시스템 서비스 관리에 대한 자세한 내용은 10장. systemd를 사용하여 서비스 관리 를 참조하십시오.
20.10.2. timemaster 설정 파일 이해
Red Hat Enterprise Linux는 기본 /etc/timemaster.conf
파일과 기본 옵션이 포함된 여러 섹션을 제공합니다. 섹션 제목은 대괄호로 묶습니다.
기본 구성을 보려면 다음과 같이 명령을 실행합니다.
~]$ less /etc/timemaster.conf # Configuration file for timemaster #[ntp_server ntp-server.local] #minpoll 4 #maxpoll 4 #[ptp_domain 0] #interfaces eth0 [timemaster] ntp_program chronyd [chrony.conf] include /etc/chrony.conf [ntp.conf] includefile /etc/ntp.conf [ptp4l.conf] [chronyd] path /usr/sbin/chronyd options -u chrony [ntpd] path /usr/sbin/ntpd options -u ntp:ntp -g [phc2sys] path /usr/sbin/phc2sys [ptp4l] path /usr/sbin/ptp4l
다음과 같이 이름이 지정된 섹션을 확인합니다.
[ntp_server address]
NTP
서버 섹션의 예입니다. "ntp-server.local"은 로컬 LAN의 NTP
서버에 대한 호스트 이름의 예입니다. 호스트 이름 또는 IP
주소를 섹션 이름의 일부로 사용하여 필요에 따라 섹션을 추가합니다. 해당 example 섹션의 짧은 폴링 값은 퍼블릭 서버에 적합하지 않습니다. 적절한 minpoll
및 maxpoll
값에 대한 설명은 19장. ntpd를 사용하여 NTP 설정 을 참조하십시오.
다음과 같이 이름이 지정된 섹션을 확인합니다.
[ptp_domain number]
"PTP 도메인"은 서로 동기화하는 하나 이상의 PTP
클럭 그룹입니다. 다른 도메인의 클럭과 동기화되지 않을 수 있습니다. 동일한 도메인 번호로 구성된 클럭은 도메인을 구성합니다. PTP
할머니 시계가 포함됩니다. 각 "PTP 도메인" 섹션의 도메인 번호는 네트워크에 구성된 PTP
도메인 중 하나에 대응해야 합니다.
자체 PTP
클럭이 있는 모든 인터페이스에 대해 ptp4l 인스턴스가 시작되고 하드웨어 타임 스탬프가 자동으로 활성화됩니다. 하드웨어 타임스탬프를 지원하는 인터페이스에는 PTP
클럭(PHC)이 연결되어 있지만 NIC의 인터페이스 그룹이 NetNamespaceC를 공유할 수 있습니다. 동일한 EgressIPC를 공유하는 각 인터페이스 그룹과 소프트웨어 타임 스탬프만 지원하는 각 인터페이스에 대해 별도의 ptp4l 인스턴스가 시작됩니다. 모든 ptp4l 인스턴스는 슬레이브로 실행되도록 구성되어 있습니다. 하드웨어 타임스탬프와의 인터페이스가 두 개 이상의 PTP
도메인에 지정되는 경우 생성된 첫 번째 ptp4l 인스턴스만 하드웨어 타임 스탬프가 활성화됩니다.
다음과 같이 이름이 지정된 섹션을 확인합니다.
[timemaster]
기본 timemaster 설정에는 액세스 제한 및 인증 키 설정을 포함하도록 시스템 ntpd
및 chrony 구성(/etc/ntp.conf
또는 /etc/chronyd.conf
)이 포함됩니다. 즉, 여기에 지정된 모든 NTP
서버도 timemaster 와 함께 사용됩니다.
섹션 제목은 다음과 같습니다.
-
[NTP_SERVER ntp-server.local]
- 이 서버의 폴링 간격을 지정합니다. 필요에 따라 추가 섹션을 만듭니다. 섹션 제목에 호스트 이름 또는IP
주소를 포함합니다. -
[ptp_domain 0]
- 이 도메인에 대해PTP
클럭이 구성된 인터페이스를 지정합니다. 필요에 따라 적절한 도메인 번호를 사용하여 추가 섹션을 생성합니다. -
[timemaster]
- 사용할NTP
데몬을 지정합니다. 가능한 값은chronyd
및ntpd
입니다. -
[chrony.conf]
-chronyd
에 대해 생성된 구성 파일에 복사할 추가 설정을 지정합니다. -
[NTP.conf]
-ntpd
에 대해 생성된 구성 파일에 복사할 추가 설정을 지정합니다. -
[ ptp4l.conf]
- ptp4l 에 대해 생성된 구성 파일에 복사할 옵션을 지정합니다. -
[chronyd]
- 명령줄에서chronyd
에 전달할 추가 설정을 지정합니다. -
[ntpd]
- 명령줄에 전달할 추가 설정을ntpd
로 지정합니다. -
[phc2sys]
- 명령줄에서 phc2sys 로 전달할 추가 설정을 지정합니다. -
[ ptp4l ]
- 명령줄에서 ptp4l의 모든 인스턴스에 전달할 추가 설정을 지정합니다.
섹션 제목과 내용은 timemaster(8)
매뉴얼 페이지에 자세히 설명되어 있습니다.
20.10.3. 타임 마스터 옵션 구성
timemaster 설정 파일 편집
기본 구성을 변경하려면
root
로 편집하기 위해/etc/timemaster.conf
파일을 엽니다.~]# vi /etc/timemaster.conf
-
timemaster 를 사용하여 제어하려는 각
NTP
서버에 대해[ntp_server 주소]
섹션을 만듭니다. example 섹션의 짧은 폴링 값은 퍼블릭 서버에 적합하지 않습니다. 적절한minpoll
및maxpoll
값에 대한 설명은 19장. ntpd를 사용하여 NTP 설정 을 참조하십시오. 도메인에 사용해야 하는 인터페이스를 추가하려면
#[ptp_domain 0]
섹션을 편집하고 인터페이스를 추가합니다. 필요에 따라 추가 도메인을 생성합니다. 예를 들면 다음과 같습니다.[ptp_domain 0] interfaces eth0 [ptp_domain 1] interfaces eth1
-
이 시스템에서
ntpd
를NTP
데몬으로 사용해야 하는 경우[timemaster]
섹션의 기본 항목을chronyd
에서ntpd
로 변경합니다. ntpd와 chronyd의 차이점에 대한 자세한 내용은 18장. chrony Suite를 사용하여 NTP 설정 를 참조하십시오. -
chronyd
를 이 시스템에서NTP
서버로 사용하는 경우[chrony.conf]
섹션에 기본 옵션인/etc/chrony.conf
항목을 추가합니다./etc/chrony.conf
의 경로가 변경된 것으로 알려진 경우 기본include
항목을 편집합니다. -
이 시스템에서
ntpd
를NTP
서버로 사용하는 경우[ntp.conf]
섹션에 기본 옵션 아래에/etc/ntp.conf
항목을 추가합니다./etc/ntp.conf
의 경로가 변경된 것으로 알려진 경우 기본include
항목을 편집합니다. -
[ ptp4l.conf]
섹션에서 ptp4l 용으로 생성된 구성 파일에 복사할 옵션을 추가합니다. 이 장에서는 일반적인 옵션 및 자세한 내용은ptp4l(8)
매뉴얼 페이지에서 확인할 수 있습니다. -
[chronyd]
섹션에서 timemaster 에 의해 호출될 때chronyd
에 전달할 명령줄 옵션을 추가합니다.chronyd
사용에 대한 자세한 내용은 18장. chrony Suite를 사용하여 NTP 설정 을 참조하십시오. -
[ntpd]
섹션에서 timemaster 에 의해 호출될 때ntpd
로 전달할 명령줄 옵션을 추가합니다.ntpd
사용에 대한 자세한 내용은 19장. ntpd를 사용하여 NTP 설정 을 참조하십시오. -
[phc2sys]
섹션에서 timemaster 에 의해 호출될 때 phc2sys 로 전달할 명령줄 옵션을 추가합니다. 이 장에서는 일반적인 옵션 및 자세한 내용은phy2sys(8)
매뉴얼 페이지에서 확인할 수 있습니다. -
[ ptp4l ]
섹션에서 timemaster 에 의해 호출될 때 ptp4l로 전달할 명령줄 옵션을 추가합니다. 이 장에서는 일반적인 옵션 및 자세한 내용은ptp4l(8)
매뉴얼 페이지에서 확인할 수 있습니다. 설정 파일을 저장하고
root
로 다음 명령을 실행하여 timemaster 를 다시 시작합니다.~]# systemctl restart timemaster
20.11. 정확도 개선
이전에는 틱리스 커널 기능을 비활성화하면 시스템 클럭의 안정성을 크게 향상시킬 수 있었기 때문에 PTP
동기화 정확도를 개선할 수 있었습니다. 커널 부팅 옵션 매개변수에 nohz=off
를 추가하여 커널 틱리스 모드를 비활성화할 수 있습니다. 그러나 kernel-3.10.0-197.el7
에 적용된 최근 개선 사항은 시스템 클럭의 안정성과 nohz=off
가 없는 시계의 안정성이 크게 향상되었으며 대부분의 사용자에게 훨씬 작아야 합니다.
새로운 어댑터 서비스를 사용하도록 ptp4l 및 phc2sys 애플리케이션을 구성할 수 있습니다. PI servo의 장점은 적합한 수행을 위해 PI 상수를 구성 할 필요가 없다는 것입니다. ptp4l 에 이를 사용하려면 /etc/ptp4l.conf
파일에 다음 행을 추가합니다.
clock_servo linreg
/etc/ ptp4l.conf
를 변경한 후 root
로 다음 명령을 실행하여 명령줄에서 ptp4l 서비스를 다시 시작합니다.
~]# systemctl restart ptp4l
이를 phc2sys 에 사용하려면 /etc/sysconfig/phc2sys
파일에 다음 행을 추가합니다.
-E linreg
/etc/sysconfig/phc2sys
를 변경한 후 root
로 다음 명령을 실행하여 명령줄에서 phc2sys 서비스를 다시 시작합니다.
~]# systemctl restart phc2sys
20.12. 추가 리소스
다음 정보 소스는 PTP
및 ptp4l 툴과 관련된 추가 리소스를 제공합니다.
20.12.1. 설치된 문서
-
ptp4l
(8) 도움말 페이지 - 구성 파일의 형식을 포함하여 ptp4l 옵션에 대해 설명합니다. -
PMC(8)
도움말 페이지 -PTP
관리 클라이언트 및 해당 명령 옵션을 설명합니다. -
phc2sys(8)
도움말 페이지 - 시스템 클럭을PTP
하드웨어 클럭(PHC)과 동기화하는 툴을 설명합니다. -
timemaster(8)
도움말 페이지 - ptp4l 및 phc2sys 를 사용하여chronyd
또는ntpd
를 사용하여 시스템 클럭을 동기화하는 프로그램에 대해 설명합니다.
20.12.2. 유용한 웹 사이트
- http://www.nist.gov/el/isd/ieee/ieee1588.cfm
- IEEE 1588 표준입니다.
VI 부. 모니터링 및 자동화
이 부분에서는 시스템 관리자가 시스템 성능을 모니터링하고 시스템 작업을 자동화하며 버그를 보고할 수 있는 다양한 도구에 대해 설명합니다.
21장. 시스템 모니터링 툴
시스템을 구성하기 위해 시스템 관리자는 사용 가능한 메모리 양, 사용 가능한 디스크 공간, 하드 드라이브의 분할 방법 또는 실행 중인 프로세스를 판별해야 하는 경우가 많습니다.
21.1. 시스템 프로세스 보기
21.1.1. ps 명령 사용
ps
명령을 사용하면 실행 중인 프로세스에 대한 정보를 표시할 수 있습니다. 이 명령은 명령을 실행할 때 실행 중인 항목에 대한 정적 목록(즉, 해당 목록)을 생성합니다. 실행 중인 프로세스 목록을 지속적으로 업데이트하려는 경우 top
명령 또는 System Monitor 애플리케이션을 대신 사용하십시오.
다른 사용자가 소유한 프로세스를 포함하여 시스템에서 현재 실행 중인 모든 프로세스를 나열하려면 쉘 프롬프트에서 다음을 입력합니다.
ps
ax
나열된 각 프로세스에 대해 ps ax
명령은 프로세스 ID(PID
), 연결된 터미널(TTY
), 현재 상태(STAT
), cumulated CPU 시간(TIME
), 실행 파일 이름(COMMAND
)을 표시합니다. 예를 들면 다음과 같습니다.
~]$ ps ax
PID TTY STAT TIME COMMAND
1 ? Ss 0:01 /usr/lib/systemd/systemd --switched-root --system --deserialize 23
2 ? S 0:00 [kthreadd]
3 ? S 0:00 [ksoftirqd/0]
5 ? S> 0:00 [kworker/0:0H]
[output truncated]
각 프로세스와 함께 소유자를 표시하려면 다음 명령을 사용합니다.
ps
aux
ps ax
명령에서 제공하는 정보 외에도 ps aux
는 프로세스 소유자(USER
), CPU 백분율(%CPU
) 및 메모리(%MEM
) 사용량, 킬로바이트(VSZ
)의 가상 메모리 크기, 킬로바이트(RSS
)의 실제 메모리 크기 및 프로세스가 시작된 날짜 또는 프로세스를 표시합니다. 예를 들면 다음과 같습니다.
~]$ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.3 0.3 134776 6840 ? Ss 09:28 0:01 /usr/lib/systemd/systemd --switched-root --system --d
root 2 0.0 0.0 0 0 ? S 09:28 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S 09:28 0:00 [ksoftirqd/0]
root 5 0.0 0.0 0 0 ? S> 09:28 0:00 [kworker/0:0H]
[output truncated]
grep
과 함께 ps
명령을 사용하여 특정 프로세스가 실행 중인지 확인할 수도 있습니다. 예를 들어 SMT가 실행 중인지 확인하려면 다음을 입력합니다.
~]$ ps ax | grep emacs 12056 pts/3 S+ 0:00 emacs 12060 pts/2 S+ 0:00 grep --color=auto emacs
사용 가능한 명령줄 옵션의 전체 목록은 ps(1) 매뉴얼 페이지를 참조하십시오.
21.1.2. 맨 위 명령 사용
top
명령은 시스템에서 실행 중인 프로세스의 실시간 목록을 표시합니다. 또한 시스템 가동 시간, 현재 CPU 및 메모리 사용량 또는 실행 중인 총 프로세스 수에 대한 추가 정보를 표시하고 목록 정렬 또는 프로세스 종료와 같은 작업을 수행할 수 있습니다.
top
명령을 실행하려면 쉘 프롬프트에서 다음을 입력합니다.
top
나열된 각 프로세스에 대해 top
명령은 프로세스 ID(PID
), 프로세스 소유자(USER
), 우선 순위(PR
), 좋은 값(NI
), 프로세스에서 사용하는 가상 메모리 양(VIRT
), 프로세스가 사용하는 가상 메모리 양(예:RES
)을 표시합니다. 프로세스에서 사용하는 공유 메모리 양(SHR
), 프로세스 상태 필드 S
), CPU (%CPU
) 및 메모리 (%MEM
) 사용량, cumulated CPU 시간 (TIME+
), 실행 가능한 파일의 이름 (monMAND )입니다. 예를 들면 다음과 같습니다.
~]$ top top - 16:42:12 up 13 min, 2 users, load average: 0.67, 0.31, 0.19 Tasks: 165 total, 2 running, 163 sleeping, 0 stopped, 0 zombie %Cpu(s): 37.5 us, 3.0 sy, 0.0 ni, 59.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 1016800 total, 77368 free, 728936 used, 210496 buff/cache KiB Swap: 839676 total, 776796 free, 62880 used. 122628 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3168 sjw 20 0 1454628 143240 15016 S 20.3 14.1 0:22.53 gnome-shell 4006 sjw 20 0 1367832 298876 27856 S 13.0 29.4 0:15.58 firefox 1683 root 20 0 242204 50464 4268 S 6.0 5.0 0:07.76 Xorg 4125 sjw 20 0 555148 19820 12644 S 1.3 1.9 0:00.48 gnome-terminal- 10 root 20 0 0 0 0 S 0.3 0.0 0:00.39 rcu_sched 3091 sjw 20 0 37000 1468 904 S 0.3 0.1 0:00.31 dbus-daemon 3096 sjw 20 0 129688 2164 1492 S 0.3 0.2 0:00.14 at-spi2-registr 3925 root 20 0 0 0 0 S 0.3 0.0 0:00.05 kworker/0:0 1 root 20 0 126568 3884 1052 S 0.0 0.4 0:01.61 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0 6 root 20 0 0 0 0 S 0.0 0.0 0:00.07 kworker/u2:0 [output truncated]
표 21.1. “대화형 최상위 명령” top
과 함께 사용할 수 있는 유용한 대화형 명령이 포함되어 있습니다. 자세한 내용은 상단(1) 설명서 페이지를 참조하십시오.
명령 | 설명 |
---|---|
자주 하는질문 | 디스플레이를 즉시 새로 고침합니다. |
h | 대화식 명령의 도움말 화면을 표시합니다. |
h, ? | 창 및 필드 그룹에 대한 도움말 화면을 표시합니다. |
k | 프로세스를 종료합니다. 프로세스 ID와 전송할 신호를 입력하라는 메시지가 표시됩니다. |
n | 표시되는 프로세스 수를 변경합니다. 번호를 입력하라는 메시지가 표시됩니다. |
u | 목록을 사용자별로 정렬합니다. |
M | 메모리를 사용하여 목록을 정렬합니다. |
P | CPU 사용량에 따라 목록을 정렬합니다. |
q | 유틸리티를 종료하고 쉘 프롬프트로 돌아갑니다. |
21.1.3. 시스템 모니터 도구 사용
System Monitor 도구의 프로세스
탭을 사용하면 그래픽 사용자 인터페이스에서 프로세스를 보고, 검색, 검색, 우선 순위를 변경할 수 있습니다.
명령줄에서 시스템 모니터 도구를 시작하려면 쉘 프롬프트에서 gnome-system-monitor
를 입력합니다. 시스템 모니터 도구가 나타납니다. 또는 GNOME 데스크탑을 사용하는 경우 Super 키를 눌러 activities Overview를 입력하고 System Monitor
를 입력한 다음 Enter 를 누릅니다. 시스템 모니터 도구가 나타납니다. Super 키는 키보드와 기타 하드웨어에 따라 다양한 길잡이에 표시되지만 일반적으로 스페이스바 왼쪽에 있는 Windows 또는 Command 키로 나타납니다.
프로세스
탭을 클릭하여 실행 중인 프로세스 목록을 확인합니다.
그림 21.1. 시스템 모니터 - 프로세스
나열된 각 프로세스에 대해 시스템 모니터 툴에는 이름(Process Name
), 현재상태(상태
), CPU 사용량(% CPU
사용량), 좋은 값(Vice ), 프로세스ID
(ID ), 메모리 사용량(메모리
), 프로세스가 대기 중인 채널(예:채널 대기
) 및 세션(Session
)에 대한 추가 세부 정보가 표시됩니다. 특정 열별 정보를 오름차순으로 정렬하려면 해당 열의 이름을 클릭합니다. 열 이름을 다시 클릭하여 오름차순과 내림차순 사이의 정렬을 전환합니다.
기본적으로 System Monitor 툴은 현재 사용자가 소유한 프로세스 목록을 표시합니다. 보기 메뉴에서 다양한 옵션을 선택하면 다음을 수행할 수 있습니다.
- 활성 프로세스만 표시
- 모든 프로세스 보기
- 프로세스 보기
- 프로세스 종속 항목 보기
또한 다음 두 개의 버튼을 사용하면 다음을 수행할 수 있습니다.
- 프로세스 목록을 새로 고칩니다.
- 목록에서 프로세스를 선택한 다음 버튼을 클릭하여 프로세스를 종료합니다.
21.2. 메모리 사용량 보기
21.2.1. 무료 명령 사용
free
명령을 사용하면 시스템에서 사용 가능한 메모리의 양을 표시할 수 있습니다. 이렇게 하려면 쉘 프롬프트에서 다음을 입력합니다.
free
free
명령은 실제 메모리(Mem
) 및 스왑 공간(swap ) 둘 다에 대한 정보를 제공합니다. 사용 중인 메모리 총 양(전체 ), 사용 중인 메모리 양, 사용 가능(사용 가능), 공유(공유 ), 버퍼 합계 및 캐시(
buff/cache
) 및 사용 가능한 메모리 양을 표시합니다. 예를 들면 다음과 같습니다.
~]$ free
total used free shared buff/cache available
Mem: 1016800 727300 84684 3500 204816 124068
Swap: 839676 66920 772756
기본적으로 free
는 킬로바이트 값을 표시합니다. 값을 메가바이트로 표시하려면 -m
명령줄 옵션을 제공합니다.
free
-m
예를 들면 다음과 같습니다.
~]$ free -m
total used free shared buff/cache available
Mem: 992 711 81 3 200 120
Swap: 819 65 754
사용 가능한 명령줄 옵션의 전체 목록은 무료(1) 매뉴얼 페이지를 참조하십시오.
21.2.2. 시스템 모니터 도구 사용
System Monitor 도구의 리소스
탭을 사용하면 시스템의 사용 가능한 메모리 양을 볼 수 있습니다.
명령줄에서 시스템 모니터 도구를 시작하려면 쉘 프롬프트에서 gnome-system-monitor
를 입력합니다. 시스템 모니터 도구가 나타납니다. 또는 GNOME 데스크탑을 사용하는 경우 Super 키를 눌러 activities Overview를 입력하고 System Monitor
를 입력한 다음 Enter 를 누릅니다. 시스템 모니터 도구가 나타납니다. Super 키는 키보드와 기타 하드웨어에 따라 다양한 길잡이에 표시되지만 일반적으로 스페이스바 왼쪽에 있는 Windows 또는 Command 키로 나타납니다.
리소스
탭을 클릭하여 시스템의 메모리 사용량을 확인합니다.
그림 21.2. 시스템 모니터 - 리소스
Memory andswap History
섹션의 System Monitor 툴에는 메모리 및 스왑 사용 내역의 그래픽 표현과 실제 메모리(메모리
) 및 스왑 공간(swap
space)의 총 크기 및 사용 빈도가 표시됩니다.
21.3. CPU 사용량 보기
21.3.1. 시스템 모니터 도구 사용
System Monitor 도구의 리소스
탭을 사용하면 시스템의 현재 CPU 사용량을 볼 수 있습니다.
명령줄에서 시스템 모니터 도구를 시작하려면 쉘 프롬프트에서 gnome-system-monitor
를 입력합니다. 시스템 모니터 도구가 나타납니다. 또는 GNOME 데스크탑을 사용하는 경우 Super 키를 눌러 activities Overview를 입력하고 System Monitor
를 입력한 다음 Enter 를 누릅니다. 시스템 모니터 도구가 나타납니다. Super 키는 키보드와 기타 하드웨어에 따라 다양한 길잡이에 표시되지만 일반적으로 스페이스바 왼쪽에 있는 Windows 또는 Command 키로 나타납니다.
리소스
탭을 클릭하여 시스템의 CPU 사용량을 확인합니다.
CPU 기록
섹션에서 System Monitor 툴은 CPU 사용 내역의 그래픽 표시를 표시하고 현재 사용 중인 CPU의 백분율을 표시합니다.
21.4. 블록 장치 및 파일 시스템 보기
21.4.1. lsblk 명령 사용
lsblk
명령을 사용하면 사용 가능한 블록 장치 목록을 표시할 수 있습니다. blkid
명령보다 출력 포맷에서 더 많은 정보와 더 나은 제어 기능을 제공합니다. udev 에서 정보를 읽기 때문에root
가 아닌 사용자가 사용할 수 있습니다. 블록 장치 목록을 표시하려면 쉘 프롬프트에서 다음을 입력합니다.
lsblk
나열된 각 블록 장치에 대해 lsblk
명령은 장치 이름(NAME
), 주 및 마이너 장치 번호(MAJ:MIN
), 장치를 이동식(RM
), 장치의크기
(SIZE ), 디바이스가 읽기 전용(RO
),유형
(type ), 장치가 마운트된 경우 장치 이름( NAME ), 주 및 마이너 장치 번호( MAJ:MIN ), 장치를 표시합니다. 예를 들면 다음과 같습니다.
~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 252:0 0 20G 0 rom |-vda1 252:1 0 500M 0 part /boot `-vda2 252:2 0 19.5G 0 part |-vg_kvm-lv_root (dm-0) 253:0 0 18G 0 lvm / `-vg_kvm-lv_swap (dm-1) 253:1 0 1.5G 0 lvm [SWAP]
기본적으로 lsblk
는 트리와 유사한 형식으로 블록 장치를 나열합니다. 정보를 일반 목록으로 표시하려면 -l
명령줄 옵션을 추가합니다.
lsblk
-l
예를 들면 다음과 같습니다.
~]$ lsblk -l NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 252:0 0 20G 0 rom vda1 252:1 0 500M 0 part /boot vda2 252:2 0 19.5G 0 part vg_kvm-lv_root (dm-0) 253:0 0 18G 0 lvm / vg_kvm-lv_swap (dm-1) 253:1 0 1.5G 0 lvm [SWAP]
사용 가능한 명령줄 옵션의 전체 목록은 lsblk(8) 매뉴얼 페이지를 참조하십시오.
21.4.2. blkid 명령 사용
blkid
명령을 사용하면 사용 가능한 블록 장치에 대한 하위 수준 정보를 표시할 수 있습니다. 루트 권한이 필요하므로 root
가 아닌 사용자는 lsblk
명령을 사용해야 합니다. 이렇게 하려면 쉘 프롬프트에서
root
로 다음을 입력합니다.
blkid
나열된 각 블록 장치에 대해 blkid
명령은UUID
(Universal ly unique identifier ), 파일 시스템 유형(TYPE
), 볼륨 레이블(LABEL
)과 같은 사용 가능한 속성을 표시합니다. 예를 들면 다음과 같습니다.
~]# blkid /dev/vda1: UUID="7fa9c421-0054-4555-b0ca-b470a97a3d84" TYPE="ext4" /dev/vda2: UUID="7IvYzk-TnnK-oPjf-ipdD-cofz-DXaJ-gPdgBW" TYPE="LVM2_member" /dev/mapper/vg_kvm-lv_root: UUID="a07b967c-71a0-4925-ab02-aebcad2ae824" TYPE="ext4" /dev/mapper/vg_kvm-lv_swap: UUID="d7ef54ca-9c41-4de4-ac1b-4193b0c1ddb6" TYPE="swap"
기본적으로 blkid
명령은 사용 가능한 모든 블록 장치를 나열합니다. 특정 장치에 대한 정보를 표시하려면 명령줄에서 장치 이름을 지정합니다.
blkid device_name
예를 들어 /dev/vda1
에 대한 정보를 표시하려면 root
로 를 입력합니다.
~]# blkid /dev/vda1 /dev/vda1: UUID="7fa9c421-0054-4555-b0ca-b470a97a3d84" TYPE="ext4"
-p
및 -o udev
명령줄 옵션과 함께 위의 명령을 사용하여 자세한 정보를 얻을 수도 있습니다. 이 명령을 실행하려면 root
권한이 필요합니다.
blkid -po udev device_name
예를 들면 다음과 같습니다.
~]# blkid -po udev /dev/vda1 ID_FS_UUID=7fa9c421-0054-4555-b0ca-b470a97a3d84 ID_FS_UUID_ENC=7fa9c421-0054-4555-b0ca-b470a97a3d84 ID_FS_VERSION=1.0 ID_FS_TYPE=ext4 ID_FS_USAGE=filesystem
사용 가능한 명령줄 옵션의 전체 목록은 blkid(8) 매뉴얼 페이지를 참조하십시오.
21.4.3. findmnt 명령 사용
findmnt
명령을 사용하면 현재 마운트된 파일 시스템 목록을 표시할 수 있습니다. 이렇게 하려면 쉘 프롬프트에서 다음을 입력합니다.
findmnt
나열된 각 파일 시스템에 대해 findmnt
명령은 대상 마운트 지점(TARGET
), 소스 장치(소스
장치), 파일 시스템 유형(FSTYPE
), 관련 마운트 옵션(OPTIONS
)을 표시합니다. 예를 들면 다음과 같습니다.
~]$ findmnt TARGET SOURCE FSTYPE OPTIONS / /dev/mapper/rhel-root xfs rw,relatime,seclabel,attr2,inode64,noquota ├─/proc proc proc rw,nosuid,nodev,noexec,relatime │ ├─/proc/sys/fs/binfmt_misc systemd-1 autofs rw,relatime,fd=32,pgrp=1,timeout=300,minproto=5,maxproto=5,direct │ └─/proc/fs/nfsd sunrpc nfsd rw,relatime ├─/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime,seclabel │ ├─/sys/kernel/security securityfs securityfs rw,nosuid,nodev,noexec,relatime │ ├─/sys/fs/cgroup tmpfs tmpfs rw,nosuid,nodev,noexec,seclabel,mode=755 [output truncated]
기본적으로 findmnt
는 트리와 같은 형식으로 파일 시스템을 나열합니다. 정보를 일반 목록으로 표시하려면 -l
명령줄 옵션을 추가합니다.
findmnt
-l
예를 들면 다음과 같습니다.
~]$ findmnt -l TARGET SOURCE FSTYPE OPTIONS /proc proc proc rw,nosuid,nodev,noexec,relatime /sys sysfs sysfs rw,nosuid,nodev,noexec,relatime,seclabel /dev devtmpfs devtmpfs rw,nosuid,seclabel,size=933372k,nr_inodes=233343,mode=755 /sys/kernel/security securityfs securityfs rw,nosuid,nodev,noexec,relatime /dev/shm tmpfs tmpfs rw,nosuid,nodev,seclabel /dev/pts devpts devpts rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000 /run tmpfs tmpfs rw,nosuid,nodev,seclabel,mode=755 /sys/fs/cgroup tmpfs tmpfs rw,nosuid,nodev,noexec,seclabel,mode=755 [output truncated]
특정 유형의 파일 시스템만 나열하도록 선택할 수도 있습니다. 이렇게 하려면 -t
명령줄 옵션 뒤에 파일 시스템 유형을 추가합니다.
findmnt
-t
type
예를 들어 xfs
파일 시스템을 모두 나열하려면 다음을 입력합니다.
~]$ findmnt -t xfs
TARGET SOURCE FSTYPE OPTIONS
/ /dev/mapper/rhel-root xfs rw,relatime,seclabel,attr2,inode64,noquota
└─/boot /dev/vda1 xfs rw,relatime,seclabel,attr2,inode64,noquota
사용 가능한 명령줄 옵션의 전체 목록은 findmnt(8) 매뉴얼 페이지를 참조하십시오.
21.4.4. df 명령 사용
df
명령을 사용하면 시스템의 디스크 공간 사용에 대한 자세한 보고서를 표시할 수 있습니다. 이렇게 하려면 쉘 프롬프트에서 다음을 입력합니다.
df
나열된 각 파일 시스템에 대해 df
명령은 이름(파일 시스템
), 크기(1K-블록
또는 크기
),사용된
공간 양(사용 가능 ), 공간 사용량(사용 가능
), 공간 사용량(사용%
), 어디에 마운트되어 있는 파일 시스템(으)을 표시합니다. 예를 들면 다음과 같습니다.
~]$ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vg_kvm-lv_root 18618236 4357360 13315112 25% / tmpfs 380376 288 380088 1% /dev/shm /dev/vda1 495844 77029 393215 17% /boot
기본적으로 df
명령은 파티션 크기를 1 킬로바이트 블록으로 표시하고 사용된 디스크 공간(KB)을 표시합니다. 메가바이트 및 기가바이트로 정보를 보려면 -h
명령줄 옵션을 제공하여 df
가 사람이 읽을 수 있는 형식으로 값을 표시합니다.
df
-h
예를 들면 다음과 같습니다.
~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_kvm-lv_root 18G 4.2G 13G 25% / tmpfs 372M 288K 372M 1% /dev/shm /dev/vda1 485M 76M 384M 17% /boot
사용 가능한 명령줄 옵션의 전체 목록은 df(1) 매뉴얼 페이지를 참조하십시오.
21.4.5. du 명령 사용
du
명령을 사용하면 디렉터리의 파일에서 사용하는 공간의 양을 표시할 수 있습니다. 현재 작업 디렉터리의 각 하위 디렉터리에 대한 디스크 사용량을 표시하려면 추가 명령줄 옵션 없이 명령을 실행합니다.
du
예를 들면 다음과 같습니다.
~]$ du
14972 ./Downloads
4 ./.mozilla/extensions
4 ./.mozilla/plugins
12 ./.mozilla
15004 .
기본적으로 du
명령은 디스크 사용량을 킬로바이트 단위로 표시합니다. 정보를 메가바이트 및 기가바이트로 보려면 -h
명령줄 옵션을 제공하여 유틸리티에서 사용자가 읽을 수 있는 형식으로 값을 표시합니다.
du
-h
예를 들면 다음과 같습니다.
~]$ du -h
15M ./Downloads
4.0K ./.mozilla/extensions
4.0K ./.mozilla/plugins
12K ./.mozilla
15M .
목록 끝에 du
명령은 항상 현재 디렉토리에 대한 총체를 표시합니다. 이 정보만 표시하려면 -s
명령줄 옵션을 제공합니다.
du
-sh
예를 들면 다음과 같습니다.
~]$ du -sh
15M .
사용 가능한 명령줄 옵션의 전체 목록은 du(1) 매뉴얼 페이지를 참조하십시오.
21.4.6. 시스템 모니터 도구 사용
시스템 모니터 도구의 파일시스템
탭을 사용하면 그래픽 사용자 인터페이스에서 파일 시스템 및 디스크 공간 사용량을 볼 수 있습니다.
명령줄에서 시스템 모니터 도구를 시작하려면 쉘 프롬프트에서 gnome-system-monitor
를 입력합니다. 시스템 모니터 도구가 나타납니다. 또는 GNOME 데스크탑을 사용하는 경우 Super 키를 눌러 activities Overview를 입력하고 System Monitor
를 입력한 다음 Enter 를 누릅니다. 시스템 모니터 도구가 나타납니다. Super 키는 키보드와 기타 하드웨어에 따라 다양한 길잡이에 표시되지만 일반적으로 스페이스바 왼쪽에 있는 Windows 또는 Command 키로 나타납니다.
파일 시스템
탭을 클릭하여 파일 시스템 목록을 확인합니다.
그림 21.3. 시스템 모니터 - 파일 시스템
나열된 각 파일 시스템에 대해 시스템 모니터 툴은 소스장치
(Device ), 대상 마운트 지점(Directory
), 파일 시스템유형
(유형 ), 크기(합계
) 및 사용 가능한 공간(사용 가능) 및사용된
공간(사용 가능
)을 표시합니다.
21.5. 하드웨어 정보 보기
21.5.1. lspci 명령 사용
lspci
명령을 사용하면 연결된 PCI 버스 및 장치에 대한 정보를 표시할 수 있습니다. 시스템에 있는 모든 PCI 장치를 나열하려면 쉘 프롬프트에서 다음을 입력합니다.
lspci
예를 들면 다음과 같은 간단한 장치 목록이 표시됩니다.
~]$ lspci 00:00.0 Host bridge: Intel Corporation 82X38/X48 Express DRAM Controller 00:01.0 PCI bridge: Intel Corporation 82X38/X48 Express Host-Primary PCI Express Bridge 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02) 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02) 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02) [output truncated]
-v
명령줄 옵션을 사용하여 더 자세한 출력을 표시하거나 -vv
를 사용하여 매우 자세한 출력을 표시할 수도 있습니다.
lspci
-v
|-vv
예를 들어 시스템 비디오 카드의 제조업체, 모델 및 메모리 크기를 결정하려면 다음을 입력합니다.
~]$ lspci -v
[output truncated]
01:00.0 VGA compatible controller: nVidia Corporation G84 [Quadro FX 370] (rev a1) (prog-if 00 [VGA controller])
Subsystem: nVidia Corporation Device 0491
Physical Slot: 2
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at f2000000 (32-bit, non-prefetchable) [size=16M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
Memory at f0000000 (64-bit, non-prefetchable) [size=32M]
I/O ports at 1100 [size=128]
Expansion ROM at <unassigned> [disabled]
Capabilities: <access denied>
Kernel driver in use: nouveau
Kernel modules: nouveau, nvidiafb
[output truncated]
사용 가능한 명령줄 옵션의 전체 목록은 lspci(8) 매뉴얼 페이지를 참조하십시오.
21.5.2. lsusb 명령 사용
lsusb
명령을 사용하면 USB 버스 및 장치에 연결된 장치에 대한 정보를 표시할 수 있습니다. 시스템에 있는 모든 USB 장치를 나열하려면 쉘 프롬프트에서 다음을 입력합니다.
lsusb
예를 들면 다음과 같은 간단한 장치 목록이 표시됩니다.
~]$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[output truncated]
Bus 001 Device 002: ID 0bda:0151 Realtek Semiconductor Corp. Mass Storage Device (Multicard Reader)
Bus 008 Device 002: ID 03f0:2c24 Hewlett-Packard Logitech M-UAL-96 Mouse
Bus 008 Device 003: ID 04b3:3025 IBM Corp.
-v
명령줄 옵션을 사용하여 더 자세한 출력을 표시할 수도 있습니다.
lsusb
-v
예를 들면 다음과 같습니다.
~]$ lsusb -v
[output truncated]
Bus 008 Device 002: ID 03f0:2c24 Hewlett-Packard Logitech M-UAL-96 Mouse
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x03f0 Hewlett-Packard
idProduct 0x2c24 Logitech M-UAL-96 Mouse
bcdDevice 31.00
iManufacturer 1
iProduct 2
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
[output truncated]
사용 가능한 명령줄 옵션의 전체 목록은 lsusb(8) 매뉴얼 페이지를 참조하십시오.
21.5.3. lscpu 명령 사용
lscpu
명령을 사용하면 CPU 수, 아키텍처, 공급 업체, 제품군, 모델, CPU 캐시 등을 포함하여 시스템에 있는 CPU에 대한 정보를 나열할 수 있습니다. 이렇게 하려면 쉘 프롬프트에서 다음을 입력합니다.
lscpu
예를 들면 다음과 같습니다.
~]$ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 23 Stepping: 7 CPU MHz: 1998.000 BogoMIPS: 4999.98 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 3072K NUMA node0 CPU(s): 0-3
사용 가능한 명령줄 옵션의 전체 목록은 lscpu(1) 매뉴얼 페이지를 참조하십시오.
21.6. 하드웨어 오류 확인
Red Hat Enterprise Linux 7에는 새로운 하드웨어 이벤트 보고서 메커니즘 (HERM )이 도입되었습니다. 이 메커니즘은 듀얼 인라인 메모리 모듈 (DIMMs)에 대한 오류 탐지 및 수정 (EDAC) 메커니즘에 의해 보고된 오류 보고된 메모리 오류를 수집하여 사용자 공간으로 보고합니다. 사용자 공간 데몬 rasdaemon
은 커널 추적 메커니즘에서 제공하는 모든 안정성, 가용성 및 서비스 가용성(RAS) 오류 이벤트를 포착하고 처리하고 이를 기록합니다. edac-utils
에서 이전에 제공하는 함수는 이제 rasdaemon
으로 교체되었습니다.
rasdaemon
을 설치하려면 root
로 다음 명령을 입력합니다.
~]# yum install rasdaemon
다음과 같이 서비스를 시작합니다.
~]# systemctl start rasdaemon
시스템을 시작할 때 서비스를 실행하려면 다음 명령을 입력합니다.
~]# systemctl enable rasdaemon
ras-mc-ctl
유틸리티는 EDAC 드라이버를 사용할 수 있는 수단을 제공합니다. 다음 명령을 입력하여 명령 옵션 목록을 확인합니다.
~]$ ras-mc-ctl --help
Usage: ras-mc-ctl [OPTIONS...]
--quiet Quiet operation.
--mainboard Print mainboard vendor and model for this hardware.
--status Print status of EDAC drivers.
output truncated
메모리 컨트롤러 이벤트에 대한 요약을 보려면 root
로 다음을 실행합니다.
~]# ras-mc-ctl --summary Memory controller events summary: Corrected on DIMM Label(s): 'CPU_SrcID#0_Ha#0_Chan#0_DIMM#0' location: 0:0:0:-1 errors: 1 No PCIe AER errors. No Extlog errors. MCE records summary: 1 MEMORY CONTROLLER RD_CHANNEL0_ERR Transaction: Memory read error errors 2 No Error errors
메모리 컨트롤러에서 보고한 오류 목록을 보려면 root
로 실행합니다.
~]# ras-mc-ctl --errors Memory controller events: 1 3172-02-17 00:47:01 -0500 1 Corrected error(s): memory read error at CPU_SrcID#0_Ha#0_Chan#0_DIMM#0 location: 0:0:0:-1, addr 65928, grain 7, syndrome 0 area:DRAM err_code:0001:0090 socket:0 ha:0 channel_mask:1 rank:0 No PCIe AER errors. No Extlog errors. MCE events: 1 3171-11-09 06:20:21 -0500 error: MEMORY CONTROLLER RD_CHANNEL0_ERR Transaction: Memory read error, mcg mcgstatus=0, mci Corrected_error, n_errors=1, mcgcap=0x01000c16, status=0x8c00004000010090, addr=0x1018893000, misc=0x15020a086, walltime=0x57e96780, cpuid=0x00050663, bank=0x00000007 2 3205-06-22 00:13:41 -0400 error: No Error, mcg mcgstatus=0, mci Corrected_error Error_enabled, mcgcap=0x01000c16, status=0x9400000000000000, addr=0x0000abcd, walltime=0x57e967ea, cpuid=0x00050663, bank=0x00000001 3 3205-06-22 00:13:41 -0400 error: No Error, mcg mcgstatus=0, mci Corrected_error Error_enabled, mcgcap=0x01000c16, status=0x9400000000000000, addr=0x00001234, walltime=0x57e967ea, cpu=0x00000001, cpuid=0x00050663, apicid=0x00000002, bank=0x00000002
이러한 명령은 ras-mc-ctl(8)
매뉴얼 페이지에도 설명되어 있습니다.
21.7. Net-SNMP를 사용하여 성능 모니터링
Red Hat Enterprise Linux 7에는 유연하고 확장 가능한 간단한 네트워크 관리 프로토콜 (SNMP) 에이전트가 포함된 Net-SNMP 소프트웨어 제품군이 포함되어 있습니다. 이 에이전트 및 관련 유틸리티는 다수의 시스템의 성능 데이터를 SNMP
프로토콜에 대한 폴링을 지원하는 다양한 툴로 제공하는 데 사용할 수 있습니다.
이 섹션에서는 Net-SNMP 에이전트를 구성하여 네트워크를 통해 성능 데이터를 안전하게 제공하고, SNMP 프로토콜을 사용하여 데이터를 검색하고, Systemd 에이전트를 확장하여 사용자 지정 성능 지표를 제공하는 방법에 대한 정보를 제공합니다.
21.7.1. Net-SNMP 설치
Net-SNMP 소프트웨어 제품군은 Red Hat Enterprise Linux 소프트웨어 배포에서 RPM 패키지 세트로 사용할 수 있습니다. 표 21.2. “사용 가능한 Net-SNMP 패키지” 는 각 패키지와 해당 컨텐츠를 요약합니다.
패키지 | 제공 |
---|---|
net-snmp | SNMP 에이전트 데몬 및 문서. 이 패키지는 성능 데이터를 내보내는 데 필요합니다. |
net-snmp-libs |
|
net-snmp-utils |
|
net-snmp-perl |
|
net-snmp-python | Python용 SNMP 클라이언트 라이브러리입니다. 이 패키지는 Optional 채널에서 제공합니다. Red Hat 추가 채널에 대한 자세한 내용은 9.5.7절. “선택적 리포지토리 추가” 를 참조하십시오. |
이러한 패키지를 설치하려면 다음 형식으로 yum
명령을 사용하십시오.
yum
install
package…
예를 들어 이 섹션의 나머지 부분에서 사용된 SNMP 에이전트 데몬 및 SNMP 클라이언트를 설치하려면 쉘 프롬프트에 root
로 다음을 입력합니다.
~]# yum install net-snmp net-snmp-libs net-snmp-utils
Red Hat Enterprise Linux에 새 패키지를 설치하는 방법에 대한 자세한 내용은 9.2.4절. “패키지 설치” 를 참조하십시오.
21.7.2. Net-SNMP 데몬 실행
net-snmp 패키지에는 snmpd
, SNMP Agent Daemon이 포함되어 있습니다. 이 섹션에서는 snmpd
서비스를 시작, 중지 및 다시 시작하는 방법에 대한 정보를 제공합니다. Red Hat Enterprise Linux 7에서 시스템 서비스 관리에 대한 자세한 내용은 10장. systemd를 사용하여 서비스 관리 를 참조하십시오.
21.7.2.1. 서비스 시작
현재 세션에서 snmpd
서비스를 실행하려면 쉘 프롬프트에 root
로 다음을 입력합니다.
systemctl start snmpd.service
부팅 시 자동으로 시작하도록 서비스를 구성하려면 다음 명령을 사용합니다.
systemctl enable snmpd.service
21.7.2.2. 서비스 중지
실행 중인 snmpd
서비스를 중지하려면 쉘 프롬프트에 root
로 다음을 입력합니다.
systemctl stop snmpd.service
부팅 시 서비스 시작을 비활성화하려면 다음 명령을 사용하십시오.
systemctl disable snmpd.service
21.7.2.3. 서비스를 다시 시작
실행 중인 snmpd
서비스를 다시 시작하려면 쉘 프롬프트에서 다음을 입력합니다.
systemctl restart snmpd.service
이 명령은 서비스를 중지하고 빠른 연속으로 다시 시작합니다. 서비스를 중지하지 않고 구성을 다시 로드하려면 다음 명령을 대신 실행합니다.
systemctl reload snmpd.service
이로 인해 실행 중인 snmpd
서비스가 구성을 다시 로드합니다.
21.7.3. Net-SNMP 구성
Net-SNMP 에이전트 데몬 구성을 변경하려면 /etc/snmp/snmpd.conf
구성 파일을 편집합니다. Red Hat Enterprise Linux 7에 포함된 기본 snmpd.conf
파일은 크게 주석 처리되어 에이전트 구성을 위한 좋은 시작점으로 사용됩니다.
이 섹션에서는 시스템 정보 설정 및 인증 구성의 두 가지 공통 작업에 중점을 둡니다. 사용 가능한 구성 지시문에 대한 자세한 내용은 snmpd.conf
(5) 매뉴얼 페이지를 참조하십시오. 또한 유효한 에이전트 구성을 대화형으로 생성하는 데 사용할 수 있는 snmpconf
라는 net-snmp 패키지에 유틸리티도 있습니다.
이 섹션에 설명된 snmpwalk
유틸리티를 사용하려면 net-snmp-utils 패키지를 설치해야 합니다.
구성 파일의 변경 사항을 적용하려면 root
로 다음 명령을 실행하여 snmpd
서비스가 구성을 다시 읽도록 합니다.
systemctl reload snmpd.service
21.7.3.1. 시스템 정보 설정
net-SNMP는 시스템 트리를 통해 몇 가지 기본 시스템
정보를 제공합니다. 예를 들어 다음 snmpwalk
명령은 기본 에이전트 구성이 있는 시스템
트리를 보여줍니다.
~]# snmpwalk -v2c -c public localhost system SNMPv2-MIB::sysDescr.0 = STRING: Linux localhost.localdomain 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64 SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (464) 0:00:04.64 SNMPv2-MIB::sysContact.0 = STRING: Root <root@localhost> (configure /etc/snmp/snmp.local.conf) [output truncated]
기본적으로 sysName
개체는 호스트 이름으로 설정됩니다. sysLocation
및 sysContact
오브젝트는 다음과 같이 syslocation
및 sysContact
지시문의 값을 변경하여 /etc/snmp/snmpd.conf
파일에서 구성할 수 있습니다.
syslocation Datacenter, Row 4, Rack 3 syscontact UNIX Admin <admin@example.com>
구성 파일을 변경한 후 설정을 다시 로드하고 snmpwalk
명령을 다시 실행하여 테스트합니다.
~]# systemctl reload snmp.service ~]# snmpwalk -v2c -c public localhost system SNMPv2-MIB::sysDescr.0 = STRING: Linux localhost.localdomain 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64 SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (35424) 0:05:54.24 SNMPv2-MIB::sysContact.0 = STRING: UNIX Admin <admin@example.com> SNMPv2-MIB::sysName.0 = STRING: localhost.localdomain SNMPv2-MIB::sysLocation.0 = STRING: Datacenter, Row 4, Rack 3 [output truncated]
21.7.3.2. 인증 구성
Net-SNMP 에이전트 데몬에서는 다음 세 가지 버전의 SNMP 프로토콜을 모두 지원합니다. 처음 두 버전(1 및 2c)은 커뮤니티 문자열 을 사용하여 간단한 인증을 제공합니다. 이 문자열은 에이전트와 모든 클라이언트 유틸리티 간의 공유 시크릿입니다. 문자열은 네트워크를 통해 일반 텍스트로 전달되지만 안전한 것으로 간주되지 않습니다. SNMP 프로토콜의 버전 3은 다양한 프로토콜을 사용하여 사용자 인증 및 메시지 암호화를 지원합니다. Net-SNMP 에이전트는 SSH를 통한 터널링 및 X.509 인증서를 사용한 TLS 인증도 지원합니다.
Manila 버전 2c 커뮤니티 구성
SNMP 버전 2c 커뮤니티를 구성하려면 /etc/snmp/snmpd.conf
구성 파일에서 rocommunity
또는 rwcommunity
지시문을 사용합니다. 지시문 형식은 다음과 같습니다.
directive community source OID
커뮤니티가 사용할 커뮤니티 문자열인 경우 source 는 IP 주소 또는 서브넷이며, OID 는 액세스를 제공하는 Systemd 트리입니다. 예를 들어 다음 지시문은 로컬 머신의 커뮤니티 문자열 "redhat"을 사용하여 클라이언트에 시스템
트리에 대한 읽기 전용 액세스를 제공합니다.
rocommunity redhat 127.0.0.1 .1.3.6.1.2.1.1
구성을 테스트하려면 -v
및 -c
옵션과 함께 snmpwalk
명령을 사용합니다.
~]# snmpwalk -v2c -c redhat localhost system SNMPv2-MIB::sysDescr.0 = STRING: Linux localhost.localdomain 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64 SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (101376) 0:16:53.76 SNMPv2-MIB::sysContact.0 = STRING: UNIX Admin <admin@example.com> SNMPv2-MIB::sysName.0 = STRING: localhost.localdomain SNMPv2-MIB::sysLocation.0 = STRING: Datacenter, Row 4, Rack 3 [output truncated]
Manila 버전 3 사용자 구성
SNMP 버전 3 사용자를 구성하려면 net-snmp-create-v3-user
명령을 사용합니다. 이 명령은 사용자를 생성하고 사용자에게 액세스 권한을 부여하는 /var/lib/net-snmpd.conf
및 /etc/snmp/snmpd.conf
파일에 항목을 추가합니다. net-snmp-create-v3-user
명령은 에이전트가 실행되지 않는 경우에만 실행할 수 있습니다. 다음 예제에서는 암호 "redhatsnmp"를 사용하여 "admin" 사용자를 생성합니다.
~]# systemctl stop snmpd.service ~]# net-snmp-create-v3-user Enter a SNMPv3 user name to create: admin Enter authentication pass-phrase: redhatsnmp Enter encryption pass-phrase: [press return to reuse the authentication pass-phrase] adding the following line to /var/lib/net-snmp/snmpd.conf: createUser admin MD5 "redhatsnmp" DES adding the following line to /etc/snmp/snmpd.conf: rwuser admin ~]# systemctl start snmpd.service
net-snmp/snmp/snmpd.conf에
지시문(또는 /etc/snmp/snmpd.conf
에 추가하는 rwuser
-ro
명령줄 옵션이 제공되는 경우 rouser
)은 rwcommunity
및 rocommunity
지시문과 유사한 형식을 갖습니다.
directive usernoauth
|auth
|priv
OID
여기서 사용자는 사용자 이름이고 OID 는 액세스를 제공하기 위해 repeatedly 트리입니다. 기본적으로 Net-SNMP 에이전트 데몬에서는 인증된 요청( auth
옵션)만 허용합니다. noauth
옵션을 사용하면 인증되지 않은 요청을 허용할 수 있으며 priv
옵션을 사용하면 암호화를 사용할 수 있습니다. authpriv
옵션은 요청을 인증해야 하고 응답을 암호화하도록 지정합니다.
예를 들어 다음 줄은 "admin" 사용자에게 전체 트리에 대한 읽기-쓰기 액세스 권한을 부여합니다.
rwuser admin authpriv .1
구성을 테스트하려면 다음 행을 사용하여 사용자의 홈 디렉터리에 .
라는 구성 파일을 만듭니다.
snmp/
디렉토리와 해당 디렉토리에 snmp.conf
defVersion 3 defSecurityLevel authPriv defSecurityName admin defPassphrase redhatsnmp
snmpwalk
명령은 이제 에이전트를 쿼리할 때 이러한 인증 설정을 사용합니다.
~]$ snmpwalk -v3 localhost system SNMPv2-MIB::sysDescr.0 = STRING: Linux localhost.localdomain 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64 [output truncated]
21.7.4. SNMP를 통한 성능 데이터 검색
Red Hat Enterprise Linux의 Net-SNMP Agent는 SNMP 프로토콜을 통해 다양한 성능 정보를 제공합니다. 또한 시스템에 설치된 RPM 패키지 목록, 시스템에서 현재 실행 중인 프로세스 목록 또는 시스템의 네트워크 구성에 대해 에이전트를 쿼리할 수 있습니다.
이 섹션에서는 Keycloak을 통해 사용할 수 있는 성능 튜닝과 관련된 OID에 대한 개요를 제공합니다. net-snmp-utils 패키지가 설치되어 있고 사용자에게 21.7.3.2절. “인증 구성” 에 설명된 대로 Systemd 트리에 대한 액세스 권한이 부여된 것으로 가정합니다.
21.7.4.1. 하드웨어 구성
Net-SNMP에 포함된 Host Resources
MiB는 호스트의 현재 하드웨어 및 소프트웨어 구성에 대한 정보를 클라이언트 유틸리티에 제공합니다. 표 21.3. “사용 가능한 OIDs” 는 해당 MIB에서 사용할 수 있는 다양한 OID를 요약합니다.
OID | 설명 |
---|---|
| 가동 시간, 사용자 수 및 실행 중인 프로세스 수와 같은 일반적인 시스템 정보를 포함합니다. |
| 메모리 및 파일 시스템 사용량에 대한 데이터를 포함합니다. |
| 모든 프로세서, 네트워크 장치 및 파일 시스템의 목록을 포함합니다. |
| 실행 중인 모든 프로세스의 목록을 포함합니다. |
| HOST-RESOURCES-MIB::hrSWRun의 프로세스 테이블에 대한 메모리 및 CPU 통계가 포함되어 있습니다. |
| RPM 데이터베이스 목록이 포함되어 있습니다. |
또한 사용 가능한 정보의 요약을 검색하는 데 사용할 수 있는 Host Resources MiB에서 사용할 수 있는 다양한 SNMP 테이블도 있습니다. 다음 예제에서는 HOST-RESOURCES-MIB::hrFSTable
을 표시합니다.
~]$ snmptable -Cb localhost HOST-RESOURCES-MIB::hrFSTable
SNMP table: HOST-RESOURCES-MIB::hrFSTable
Index MountPoint RemoteMountPoint Type
Access Bootable StorageIndex LastFullBackupDate LastPartialBackupDate
1 "/" "" HOST-RESOURCES-TYPES::hrFSLinuxExt2
readWrite true 31 0-1-1,0:0:0.0 0-1-1,0:0:0.0
5 "/dev/shm" "" HOST-RESOURCES-TYPES::hrFSOther
readWrite false 35 0-1-1,0:0:0.0 0-1-1,0:0:0.0
6 "/boot" "" HOST-RESOURCES-TYPES::hrFSLinuxExt2
readWrite false 36 0-1-1,0:0:0.0 0-1-1,0:0:0.0
HOST-RESOURCES-MIB
에 대한 자세한 내용은 /usr/share/snmp/mibs/HOST-RESOURCES-MIB.txt
파일을 참조하십시오.
21.7.4.2. CPU 및 메모리 정보
대부분의 시스템 성능 데이터는 UCD SNMP MIB
에서 사용할 수 있습니다. systemStats
OID는 프로세서 사용량에 대한 여러 카운터를 제공합니다.
~]$ snmpwalk localhost UCD-SNMP-MIB::systemStats
UCD-SNMP-MIB::ssIndex.0 = INTEGER: 1
UCD-SNMP-MIB::ssErrorName.0 = STRING: systemStats
UCD-SNMP-MIB::ssSwapIn.0 = INTEGER: 0 kB
UCD-SNMP-MIB::ssSwapOut.0 = INTEGER: 0 kB
UCD-SNMP-MIB::ssIOSent.0 = INTEGER: 0 blocks/s
UCD-SNMP-MIB::ssIOReceive.0 = INTEGER: 0 blocks/s
UCD-SNMP-MIB::ssSysInterrupts.0 = INTEGER: 29 interrupts/s
UCD-SNMP-MIB::ssSysContext.0 = INTEGER: 18 switches/s
UCD-SNMP-MIB::ssCpuUser.0 = INTEGER: 0
UCD-SNMP-MIB::ssCpuSystem.0 = INTEGER: 0
UCD-SNMP-MIB::ssCpuIdle.0 = INTEGER: 99
UCD-SNMP-MIB::ssCpuRawUser.0 = Counter32: 2278
UCD-SNMP-MIB::ssCpuRawNice.0 = Counter32: 1395
UCD-SNMP-MIB::ssCpuRawSystem.0 = Counter32: 6826
UCD-SNMP-MIB::ssCpuRawIdle.0 = Counter32: 3383736
UCD-SNMP-MIB::ssCpuRawWait.0 = Counter32: 7629
UCD-SNMP-MIB::ssCpuRawKernel.0 = Counter32: 0
UCD-SNMP-MIB::ssCpuRawInterrupt.0 = Counter32: 434
UCD-SNMP-MIB::ssIORawSent.0 = Counter32: 266770
UCD-SNMP-MIB::ssIORawReceived.0 = Counter32: 427302
UCD-SNMP-MIB::ssRawInterrupts.0 = Counter32: 743442
UCD-SNMP-MIB::ssRawContexts.0 = Counter32: 718557
UCD-SNMP-MIB::ssCpuRawSoftIRQ.0 = Counter32: 128
UCD-SNMP-MIB::ssRawSwapIn.0 = Counter32: 0
UCD-SNMP-MIB::ssRawSwapOut.0 = Counter32: 0
특히 ssCpuRawUser
,ssCpuRawSystem
,ssCpuRaw
Idle 및 ssCpuRawIdle
OIDs는 시스템이 커널 공간, 사용자 공간, 사용자 공간,에서 대부분의 프로세서 시간을 소비하고 있는지 여부를 결정하는 데 도움이 되는 카운터를 제공합니다. 또는 I/O. ssRawSwapIn
및 ssRawSwapOut
은 시스템이 메모리 소진으로 인한 고충 여부를 결정할 때 유용할 수 있습니다.
무료
명령에 유사한 데이터를 제공하는 UCD-SNMP-MIB::memory
OID에서 더 많은 메모리 정보를 사용할 수 있습니다.
~]$ snmpwalk localhost UCD-SNMP-MIB::memory
UCD-SNMP-MIB::memIndex.0 = INTEGER: 0
UCD-SNMP-MIB::memErrorName.0 = STRING: swap
UCD-SNMP-MIB::memTotalSwap.0 = INTEGER: 1023992 kB
UCD-SNMP-MIB::memAvailSwap.0 = INTEGER: 1023992 kB
UCD-SNMP-MIB::memTotalReal.0 = INTEGER: 1021588 kB
UCD-SNMP-MIB::memAvailReal.0 = INTEGER: 634260 kB
UCD-SNMP-MIB::memTotalFree.0 = INTEGER: 1658252 kB
UCD-SNMP-MIB::memMinimumSwap.0 = INTEGER: 16000 kB
UCD-SNMP-MIB::memBuffer.0 = INTEGER: 30760 kB
UCD-SNMP-MIB::memCached.0 = INTEGER: 216200 kB
UCD-SNMP-MIB::memSwapError.0 = INTEGER: noError(0)
UCD-SNMP-MIB::memSwapErrorMsg.0 = STRING:
부하 평균은 UCD SNMP MIB
에서도 사용할 수 있습니다. SNMP 테이블 UCD-SNMP-MIB::laTable
에는 1, 5, 15분 부하 평균 목록이 있습니다.
~]$ snmptable localhost UCD-SNMP-MIB::laTable
SNMP table: UCD-SNMP-MIB::laTable
laIndex laNames laLoad laConfig laLoadInt laLoadFloat laErrorFlag laErrMessage
1 Load-1 0.00 12.00 0 0.000000 noError
2 Load-5 0.00 12.00 0 0.000000 noError
3 Load-15 0.00 12.00 0 0.000000 noError
21.7.4.3. 파일 시스템 및 디스크 정보
Host Resources MiB는
파일 시스템 크기 및 사용에 대한 정보를 제공합니다. 각 파일 시스템(및 각 메모리 풀)에는 HOST-RESOURCES-MIB::hrStorageTable
테이블에 항목이 있습니다.
~]$ snmptable -Cb localhost HOST-RESOURCES-MIB::hrStorageTable
SNMP table: HOST-RESOURCES-MIB::hrStorageTable
Index Type Descr
AllocationUnits Size Used AllocationFailures
1 HOST-RESOURCES-TYPES::hrStorageRam Physical memory
1024 Bytes 1021588 388064 ?
3 HOST-RESOURCES-TYPES::hrStorageVirtualMemory Virtual memory
1024 Bytes 2045580 388064 ?
6 HOST-RESOURCES-TYPES::hrStorageOther Memory buffers
1024 Bytes 1021588 31048 ?
7 HOST-RESOURCES-TYPES::hrStorageOther Cached memory
1024 Bytes 216604 216604 ?
10 HOST-RESOURCES-TYPES::hrStorageVirtualMemory Swap space
1024 Bytes 1023992 0 ?
31 HOST-RESOURCES-TYPES::hrStorageFixedDisk /
4096 Bytes 2277614 250391 ?
35 HOST-RESOURCES-TYPES::hrStorageFixedDisk /dev/shm
4096 Bytes 127698 0 ?
36 HOST-RESOURCES-TYPES::hrStorageFixedDisk /boot
1024 Bytes 198337 26694 ?
HOST-RESOURCES-MIB::hrStorageSize
및 HOST-RESOURCES-MIB::hrStorageUsed
아래의 OID를 사용하여 마운트된 각 파일 시스템의 나머지 용량을 계산할 수 있습니다.
I/O 데이터는 UCD-SNMP-MIBStats
(sIORawSent.0 및
) 및 ssIORawRecieved.0
UCD-DISKIO-MIB::diskIOTable
둘 다에서 사용할 수 있습니다. 후자의 경우 훨씬 더 세분화된 데이터를 제공합니다. 이 표에는 디스크IONReadX 및
의 OID가 있으며, 시스템 부팅 이후 해당 블록 장치에서 읽고 쓰는 바이트 수에 대한 카운터를 제공합니다.
diskIONWrittenX
~]$ snmptable -Cb localhost UCD-DISKIO-MIB::diskIOTable
SNMP table: UCD-DISKIO-MIB::diskIOTable
Index Device NRead NWritten Reads Writes LA1 LA5 LA15 NReadX NWrittenX
...
25 sda 216886272 139109376 16409 4894 ? ? ? 216886272 139109376
26 sda1 2455552 5120 613 2 ? ? ? 2455552 5120
27 sda2 1486848 0 332 0 ? ? ? 1486848 0
28 sda3 212321280 139104256 15312 4871 ? ? ? 212321280 139104256
21.7.4.4. 네트워크 정보
Interfaces MiB는
네트워크 장치에 대한 정보를 제공합니다. IF-MIB::ifTable
은 시스템의 각 인터페이스에 대한 항목, 인터페이스 구성 및 인터페이스에 대한 다양한 패킷 카운터를 사용하여 SNMP 테이블을 제공합니다. 다음 예제에서는 두 개의 물리적 네트워크 인터페이스가 있는 시스템에서 ifTable
의 처음 몇 개의 열을 보여줍니다.
~]$ snmptable -Cb localhost IF-MIB::ifTable
SNMP table: IF-MIB::ifTable
Index Descr Type Mtu Speed PhysAddress AdminStatus
1 lo softwareLoopback 16436 10000000 up
2 eth0 ethernetCsmacd 1500 0 52:54:0:c7:69:58 up
3 eth1 ethernetCsmacd 1500 0 52:54:0:a7:a3:24 down
네트워크 트래픽은 OIDs IF-MIB::ifOutOctets
및 IF-MIB::ifInOctets
에서 사용할 수 있습니다. 다음 Keycloak 쿼리는 이 시스템의 각 인터페이스에 대한 네트워크 트래픽을 검색합니다.
~]$snmpwalk localhost IF-MIB::ifDescr
IF-MIB::ifDescr.1 = STRING: lo IF-MIB::ifDescr.2 = STRING: eth0 IF-MIB::ifDescr.3 = STRING: eth1 ~]$snmpwalk localhost IF-MIB::ifOutOctets
IF-MIB::ifOutOctets.1 = Counter32: 10060699 IF-MIB::ifOutOctets.2 = Counter32: 650 IF-MIB::ifOutOctets.3 = Counter32: 0 ~]$snmpwalk localhost IF-MIB::ifInOctets
IF-MIB::ifInOctets.1 = Counter32: 10060699 IF-MIB::ifInOctets.2 = Counter32: 78650 IF-MIB::ifInOctets.3 = Counter32: 0
21.7.5. Net-SNMP 확장
원시 시스템 지표 외에도 애플리케이션 지표를 제공하도록 Net-SNMP 에이전트를 확장할 수 있습니다. 이를 통해 용량 계획 및 성능 문제 해결을 수행할 수 있습니다. 예를 들어, 테스트 중에 이메일 시스템에 5 분의 부하 평균 15가 있다는 것을 아는 것이 도움이 될 수 있지만 이메일 시스템이 초당 80,000개의 메시지의 부하 평균을 처리하는 동안 이메일 시스템의 부하 평균 15를 사용하는 것이 더 도움이 됩니다. 시스템 지표와 동일한 인터페이스를 통해 애플리케이션 메트릭을 사용할 수 있는 경우 시스템 성능에 대한 다양한 로드 시나리오의 영향을 시각화할 수도 있습니다(예: 각 추가 10,000개의 메시지는 000까지 선형적으로 로드 평균 증가).
Red Hat Enterprise Linux에 포함된 여러 애플리케이션에서 Net-SNMP 에이전트를 확장하여 Keycloak을 통해 애플리케이션 지표를 제공합니다. 사용자 지정 애플리케이션에 대한 에이전트를 확장하는 방법은 여러 가지가 있습니다. 이 섹션에서는 선택적 채널에서 쉘 스크립트 및 Perl 플러그인을 사용하여 에이전트 확장을 설명합니다. net-snmp-utils 및 net-snmp-perl 패키지가 설치되어 있고 사용자에게 21.7.3.2절. “인증 구성” 에 설명된 대로 Systemd 트리에 대한 액세스 권한이 부여된 것으로 가정합니다.
21.7.5.1. 쉘 스크립트를 사용하여 Net-SNMP 확장
Net-SNMP 에이전트는 임의의 쉘 스크립트를 쿼리하는 데 사용할 수 있는 확장 기능인 mB(NET-SNMP-EXTEND-MIB
)를 제공합니다. 실행할 쉘 스크립트를 지정하려면 /etc/snmp/snmpd.conf
파일에서 extend
지시문을 사용합니다. 정의한 후에는 에이전트에서 종료 코드와 Keycloak을 통해 명령의 출력을 제공합니다. 아래 예제에서는 프로세스 테이블에서 httpd
프로세스 수를 결정하는 스크립트를 사용하여 이 메커니즘을 보여줍니다.
또한 Net-SNMP 에이전트는 proc
지시문을 통해 프로세스 테이블을 확인하기 위한 내장 메커니즘을 제공합니다. 자세한 내용은 snmpd.conf(5) 매뉴얼 페이지를 참조하십시오.
다음 쉘 스크립트의 종료 코드는 지정된 시점에서 시스템에서 실행되는 httpd
프로세스 수입니다.
#!/bin/sh
NUMPIDS=pgrep httpd | wc -l
exit $NUMPIDS
이 스크립트를 SNMP에서 사용할 수 있도록 하려면 시스템 경로의 위치에 스크립트를 복사하고 실행 가능한 비트를 설정하고, /etc/snmp/snmpd.conf
파일에 extend
지시문을 추가합니다. extend
지시문의 형식은 다음과 같습니다.
extend
name prog args
… 여기서 name 은 확장자에 대한 식별 문자열입니다. prog 는 실행할 프로그램이며 args 는 프로그램을 제공하는 인수입니다. 예를 들어 위의 쉘 스크립트가 /usr/local/bin/check_apache.sh
에 복사되는 경우 다음 지시어는 Systemd 트리에 스크립트를 추가합니다.
extend httpd_pids /bin/sh /usr/local/bin/check_apache.sh
그러면 NET-SNMP-EXTEND-MIB::nsExtendObjects
에서 스크립트를 쿼리할 수 있습니다.
~]$ snmpwalk localhost NET-SNMP-EXTEND-MIB::nsExtendObjects NET-SNMP-EXTEND-MIB::nsExtendNumEntries.0 = INTEGER: 1 NET-SNMP-EXTEND-MIB::nsExtendCommand."httpd_pids" = STRING: /bin/sh NET-SNMP-EXTEND-MIB::nsExtendArgs."httpd_pids" = STRING: /usr/local/bin/check_apache.sh NET-SNMP-EXTEND-MIB::nsExtendInput."httpd_pids" = STRING: NET-SNMP-EXTEND-MIB::nsExtendCacheTime."httpd_pids" = INTEGER: 5 NET-SNMP-EXTEND-MIB::nsExtendExecType."httpd_pids" = INTEGER: exec(1) NET-SNMP-EXTEND-MIB::nsExtendRunType."httpd_pids" = INTEGER: run-on-read(1) NET-SNMP-EXTEND-MIB::nsExtendStorage."httpd_pids" = INTEGER: permanent(4) NET-SNMP-EXTEND-MIB::nsExtendStatus."httpd_pids" = INTEGER: active(1) NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."httpd_pids" = STRING: NET-SNMP-EXTEND-MIB::nsExtendOutputFull."httpd_pids" = STRING: NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."httpd_pids" = INTEGER: 1 NET-SNMP-EXTEND-MIB::nsExtendResult."httpd_pids" = INTEGER: 8 NET-SNMP-EXTEND-MIB::nsExtendOutLine."httpd_pids".1 = STRING:
이 예제의 종료 코드("8")는 INTEGER 유형으로 제공되며 모든 출력은 STRING 유형으로 제공됩니다. 여러 지표를 정수로 노출하려면 extend
지시문을 사용하여 스크립트에 다른 인수를 제공합니다. 예를 들어 다음 쉘 스크립트를 사용하여 임의의 문자열과 일치하는 프로세스 수를 확인할 수 있으며 프로세스 수를 제공하는 텍스트 문자열을 출력할 수도 있습니다.
#!/bin/sh
PATTERN=$1
NUMPIDS=pgrep $PATTERN | wc -l
echo "There are $NUMPIDS $PATTERN processes."
exit $NUMPIDS
다음 /etc/snmp/snmpd.conf
지시문은 위의 스크립트가 /usr/local/bin/check_proc.sh
에 복사되면 httpd
PID 수와 snmpd
PID 수를 모두 제공합니다.
extend httpd_pids /bin/sh /usr/local/bin/check_proc.sh httpd extend snmpd_pids /bin/sh /usr/local/bin/check_proc.sh snmpd
다음 예제에서는 nsExtendObjects
OID의 snmpwalk
의 출력을 보여줍니다.
~]$ snmpwalk localhost NET-SNMP-EXTEND-MIB::nsExtendObjects NET-SNMP-EXTEND-MIB::nsExtendNumEntries.0 = INTEGER: 2 NET-SNMP-EXTEND-MIB::nsExtendCommand."httpd_pids" = STRING: /bin/sh NET-SNMP-EXTEND-MIB::nsExtendCommand."snmpd_pids" = STRING: /bin/sh NET-SNMP-EXTEND-MIB::nsExtendArgs."httpd_pids" = STRING: /usr/local/bin/check_proc.sh httpd NET-SNMP-EXTEND-MIB::nsExtendArgs."snmpd_pids" = STRING: /usr/local/bin/check_proc.sh snmpd NET-SNMP-EXTEND-MIB::nsExtendInput."httpd_pids" = STRING: NET-SNMP-EXTEND-MIB::nsExtendInput."snmpd_pids" = STRING: ... NET-SNMP-EXTEND-MIB::nsExtendResult."httpd_pids" = INTEGER: 8 NET-SNMP-EXTEND-MIB::nsExtendResult."snmpd_pids" = INTEGER: 1 NET-SNMP-EXTEND-MIB::nsExtendOutLine."httpd_pids".1 = STRING: There are 8 httpd processes. NET-SNMP-EXTEND-MIB::nsExtendOutLine."snmpd_pids".1 = STRING: There are 1 snmpd processes.
정수 종료 코드는 0-255 범위로 제한됩니다. 256을 초과할 가능성이 있는 값의 경우 스크립트의 표준 출력(문자열로 입력됨) 또는 에이전트를 확장하는 다른 방법을 사용합니다.
마지막 예는 시스템의 사용 가능한 메모리와 httpd
프로세스 수에 대한 쿼리를 보여줍니다. 성능 테스트 중에 이 쿼리를 사용하여 메모리 부족에 대한 프로세스 수의 영향을 확인할 수 있습니다.
~]$ snmpget localhost \ 'NET-SNMP-EXTEND-MIB::nsExtendResult."httpd_pids"' \ UCD-SNMP-MIB::memAvailReal.0 NET-SNMP-EXTEND-MIB::nsExtendResult."httpd_pids" = INTEGER: 8 UCD-SNMP-MIB::memAvailReal.0 = INTEGER: 799664 kB
21.7.5.2. Perl을 사용하여 Net-SNMP 확장
extend
지시문을 사용하여 쉘 스크립트를 실행하는 것은 Keycloak을 통해 사용자 지정 애플리케이션 지표를 노출하는 데 상당히 제한된 방법입니다. Net-SNMP 에이전트에서는 사용자 정의 오브젝트를 노출하기 위한 내장 Perl 인터페이스도 제공합니다. Optional 채널의 net-snmp-perl 패키지는 Red Hat Enterprise Linux에 임베디드 Perl 플러그인을 작성하는 데 사용되는 NetSNMP::agent
Perl 모듈을 제공합니다.
선택적 및 추가 채널에 가입하기 전에 지원 범위 세부 정보를 참조하십시오. 이러한 채널에서 패키지를 설치하려면 How to access Optional and Supplementary channel, and -devel packages using Red Hat Subscription Manager (RHSM)를 사용하여 Red Hat Customer Portal에 설명된 단계를 따르십시오.
NetSNMP::agent
Perl 모듈은 에이전트
의 OID 트리에 대한 요청을 처리하는 데 사용되는 에이전트 오브젝트를 제공합니다. 에이전트
오브젝트의 생성자에는 snmpd
또는 독립 실행형 에이전트의 하위 에이전트로 에이전트를 실행하는 옵션이 있습니다. 포함된 에이전트를 만드는 데는 인수가 필요하지 않습니다.
use NetSNMP::agent (':all'); my $agent = new NetSNMP::agent();
에이전트
오브젝트에는 특정 OID에 콜백 함수를 등록하는 데 사용되는 레지스터 방법이 있습니다.
register
함수는 콜백 함수에 대한 이름, OID 및 포인터를 사용합니다. 다음 예제에서는 OID .1.3 .6.1.4.1.8072.9999에서 요청을 처리할 중첩 에이전트에
hello_handler
라는 콜백 함수를 등록합니다.
$agent->register("hello_world", ".1.3.6.1.4.1.8072.9999.9999", \&hello_handler);
OID .1.3 .6.1.4.1.8072.
9999(NET-SNMP-MIB::netSnmpPlaypen
)는 일반적으로 설명 목적으로만 사용됩니다. 조직에 이미 루트 OID가 없는 경우 ISO 이름 등록 기관(미국의ANSI)에 문의하여 얻을 수 있습니다.
처리기 함수는 네 개의 매개변수인 HANDLER
,REGISTRATION_INFO
,REQUEST_INFO
, REQUESTS
를 사용하여 호출됩니다. REQUESTS
매개변수에는 현재 호출의 요청 목록이 포함되어 있으며 반복하여 데이터로 채워야 합니다. 목록의 요청
오브젝트에는 요청의 OID 및 값을
조작하는 get 및 set
메서드가 있습니다. 예를 들어 다음 호출은 요청 오브젝트의 값을 "hello world" 문자열로 설정합니다.
$request->setValue(ASN_OCTET_STR, "hello world");
handler 함수는 GET 요청과 GETNEXT 요청의 두 가지 유형에 응답해야 합니다. 요청 유형은 처리기 함수에 세 번째 매개 변수로 전달된 request_info
오브젝트에서 getMode
메서드를 호출하여 결정됩니다. 요청이 GET 요청인 경우 호출자는 요청의 OID에 따라 처리기가 요청
오브젝트의 값을
설정해야 합니다. 요청이 GETNEXT 요청인 경우 호출자는 요청의 OID를 트리에서 사용 가능한 다음 OID로 설정할 수도 있습니다. 이는 다음 코드 예제에 설명되어 있습니다.
my $request; my $string_value = "hello world"; my $integer_value = "8675309"; for($request = $requests; $request; $request = $request->next()) { my $oid = $request->getOID(); if ($request_info->getMode() == MODE_GET) { if ($oid == new NetSNMP::OID(".1.3.6.1.4.1.8072.9999.9999.1.0")) { $request->setValue(ASN_OCTET_STR, $string_value); } elsif ($oid == new NetSNMP::OID(".1.3.6.1.4.1.8072.9999.9999.1.1")) { $request->setValue(ASN_INTEGER, $integer_value); } } elsif ($request_info->getMode() == MODE_GETNEXT) { if ($oid == new NetSNMP::OID(".1.3.6.1.4.1.8072.9999.9999.1.0")) { $request->setOID(".1.3.6.1.4.1.8072.9999.9999.1.1"); $request->setValue(ASN_INTEGER, $integer_value); } elsif ($oid < new NetSNMP::OID(".1.3.6.1.4.1.8072.9999.9999.1.0")) { $request->setOID(".1.3.6.1.4.1.8072.9999.9999.1.0"); $request->setValue(ASN_OCTET_STR, $string_value); } } }
getMode
가 MODE_GET
을 반환하면 핸들러는 요청
오브젝트에서 getOID
호출 값을 분석합니다. OID가 ".1.0"으로 종료되면 요청의
값은
string_value
로 설정되거나 OID가 ".1.1"으로 종료되면 integer_value
로 설정됩니다. getMode
가 MODE_GETNEXT
를 반환하는 경우, 처리기는 요청의 OID가 ".1.0"인지 여부를 결정하고, ".1.1"의 OID 및 값을 설정합니다. 트리에서 ".1.0"보다 트리에서 요청이 높으면 OID 및 ".1.0"의 값이 설정됩니다. 이것은 실제로 트리의 "next" 값을 반환하여 snmpwalk
와 같은 프로그램은 구조에 대한 사전 지식없이 트리를 트 트 트롤할 수 있습니다.
변수 유형은 NetSNMP::ASN
의 상수를 사용하여 설정됩니다. 사용 가능한 상수 전체 목록은 perldoc
for NetSNMP::ASN
을 참조하십시오.
이 예제 Perl 플러그인의 전체 코드 목록은 다음과 같습니다.
#!/usr/bin/perl use NetSNMP::agent (':all'); use NetSNMP::ASN qw(ASN_OCTET_STR ASN_INTEGER); sub hello_handler { my ($handler, $registration_info, $request_info, $requests) = @_; my $request; my $string_value = "hello world"; my $integer_value = "8675309"; for($request = $requests; $request; $request = $request->next()) { my $oid = $request->getOID(); if ($request_info->getMode() == MODE_GET) { if ($oid == new NetSNMP::OID(".1.3.6.1.4.1.8072.9999.9999.1.0")) { $request->setValue(ASN_OCTET_STR, $string_value); } elsif ($oid == new NetSNMP::OID(".1.3.6.1.4.1.8072.9999.9999.1.1")) { $request->setValue(ASN_INTEGER, $integer_value); } } elsif ($request_info->getMode() == MODE_GETNEXT) { if ($oid == new NetSNMP::OID(".1.3.6.1.4.1.8072.9999.9999.1.0")) { $request->setOID(".1.3.6.1.4.1.8072.9999.9999.1.1"); $request->setValue(ASN_INTEGER, $integer_value); } elsif ($oid < new NetSNMP::OID(".1.3.6.1.4.1.8072.9999.9999.1.0")) { $request->setOID(".1.3.6.1.4.1.8072.9999.9999.1.0"); $request->setValue(ASN_OCTET_STR, $string_value); } } } } my $agent = new NetSNMP::agent(); $agent->register("hello_world", ".1.3.6.1.4.1.8072.9999.9999", \&hello_handler);
플러그인을 테스트하려면 위의 프로그램을 /usr/share/snmp/snmp_world.pl
에 복사하고 /etc/snmp/snmpd.conf
구성 파일에 다음 행을 추가합니다.
perl do "/usr/share/snmp/hello_world.pl"
새 Perl 플러그인을 로드하려면 SNMP 에이전트 데몬을 다시 시작해야 합니다. 다시 시작되면 snmpwalk
가 새 데이터를 반환해야 합니다.
~]$ snmpwalk localhost NET-SNMP-MIB::netSnmpPlaypen
NET-SNMP-MIB::netSnmpPlaypen.1.0 = STRING: "hello world"
NET-SNMP-MIB::netSnmpPlaypen.1.1 = INTEGER: 8675309
또한 snmpget
을 사용하여 핸들러의 다른 모드를 실행해야 합니다.
~]$snmpget localhost \
NET-SNMP-MIB::netSnmpPlaypen.1.0 \
NET-SNMP-MIB::netSnmpPlaypen.1.1
NET-SNMP-MIB::netSnmpPlaypen.1.0 = STRING: "hello world" NET-SNMP-MIB::netSnmpPlaypen.1.1 = INTEGER: 8675309
21.8. 추가 리소스
시스템 정보 수집에 대한 자세한 내용은 다음 리소스를 참조하십시오.
21.8.1. 설치된 문서
-
lscpu(1) -
lscpu
명령의 도움말 페이지. -
lsusb(8) -
lsusb
명령의 도움말 페이지. -
findmnt(8) -
findmnt
명령의 도움말 페이지. -
blkid(8) -
blkid
명령의 수동 페이지. -
lsblk(8) -
lsblk
명령의 수동 페이지. -
ps(1) -
ps
명령의 수동 페이지. -
top(1) -
top
명령의 도움말 페이지. -
free(1) -
무료
명령의 도움말 페이지. -
DF (1) -
df
명령의 도움말 페이지. -
du(1) -
du
명령의 도움말 페이지. -
lspci(8) -
lspci
명령의 도움말 페이지. -
snmpd(8) -
snmpd
서비스의 도움말 페이지. -
snmpd.conf(5) - 사용 가능한 구성 지시문에 대한 전체 문서가 포함된
/etc/snmp/snmpd.conf
파일의 도움말 페이지.
22장. OpenLMI
일반적으로 OpenLMI 로 축약되는 Open Linux Management Infrastructure 는 Linux 시스템 관리를 위한 공통 인프라입니다. 기존 툴 위에 빌드되고 시스템 관리자로부터 기본 시스템의 복잡성을 숨기기 위해 추상화 계층 역할을 합니다. OpenLMI는 로컬 또는 원격으로 액세스할 수 있는 서비스 세트와 함께 배포되며 하드웨어, 운영 체제 및 시스템 서비스를 관리하고 모니터링하는 데 사용할 수 있는 여러 언어 바인딩, 표준 API 및 표준 스크립팅 인터페이스를 제공합니다.
22.1. OpenLMI 정보
OpenLMI는 물리적 시스템과 가상 머신 모두에서 Red Hat Enterprise Linux 시스템을 실행하는 프로덕션 서버에 공통 관리 인터페이스를 제공하도록 설계되었습니다. 다음과 같은 세 가지 구성 요소로 구성됩니다.
- 시스템 관리 에이전트 - 이러한 에이전트는 관리형 시스템에 설치되고 표준 오브젝트 브로커에 제공되는 개체 모델을 구현합니다. OpenLMI에서 구현된 초기 에이전트에는 스토리지 구성 및 네트워크 구성이 포함되지만 나중에 작업에서는 시스템 관리의 추가 요소를 다룹니다. 시스템 관리 에이전트는 일반적으로 일반 정보 모델 공급자 또는 CIM 공급자 라고 합니다.
- 표준 오브젝트 브로커 - 오브젝트 브로커는 시스템 관리 에이전트를 관리하고 이에 대한 인터페이스를 제공합니다. 표준 오브젝트 브로커는 CIM Object Monitor 또는 CIMOM 라고도 합니다.
- 클라이언트 애플리케이션 및 스크립트 - 클라이언트 애플리케이션 및 스크립트는 표준 오브젝트 브로커를 통해 시스템 관리 에이전트를 호출합니다.
OpenLMI 프로젝트는 스크립트 또는 시스템 관리 콘솔에서 사용할 수 있는 하위 수준 인터페이스를 제공하여 기존 관리 이니셔티브를 보완합니다. OpenLMI와 함께 배포되는 인터페이스에는 C, C++, Python, Java 및 대화형 명령줄 클라이언트가 포함되며, 모두 각 에이전트에서 구현된 기능에 동일한 전체 액세스를 제공합니다. 이렇게 하면 사용하려는 프로그래밍 인터페이스에 관계없이 항상 동일한 기능에 액세스할 수 있습니다.
22.1.1. 주요 기능
다음은 시스템에 OpenLMI 설치 및 사용의 주요 이점입니다.
- OpenLMI는 로컬 및 원격 시스템의 구성, 관리 및 모니터링을 위한 표준 인터페이스를 제공합니다.
- 물리적 시스템과 가상 시스템에서 실행되는 프로덕션 서버를 구성, 관리 및 모니터링할 수 있습니다.
- 스토리지 장치 및 복잡한 네트워크를 구성, 관리 및 모니터링할 수 있는 CIM 공급자 컬렉션과 함께 배포됩니다.
- 이를 통해 C, C++, Python 및 Java 프로그램에서 시스템 관리 함수를 호출할 수 있으며 명령줄 인터페이스를 제공하는 LMIShell을 포함할 수 있습니다.
- 오픈 업계 표준을 기반으로 하는 자유 소프트웨어입니다.
22.1.2. 관리 기능
OpenLMI의 주요 기능에는 스토리지 장치, 네트워크, 시스템 서비스, 사용자 계정, 하드웨어 및 소프트웨어 구성, 전원 관리 및 Active Directory와의 상호 작용의 관리가 포함됩니다. Red Hat Enterprise Linux 7과 함께 배포된 CIM 공급자의 전체 목록은 표 22.1. “사용 가능한 CIM 공급자” 을 참조하십시오.
패키지 이름 | 설명 |
---|---|
OpenLMI-account | 사용자 계정을 관리하는 CIM 공급자입니다. |
openlmi-logicalfile | 파일 및 디렉터리를 읽는 CIM 공급자입니다. |
openlmi-networking | 네트워크 관리를 위한 CIM 공급자입니다. |
openlmi-powermanagement | 전원 관리를 위한 CIM 공급자입니다. |
openlmi-service | 시스템 서비스를 관리하기 위한 CIM 공급자입니다. |
openlmi-storage | 스토리지 관리를 위한 CIM 공급자입니다. |
OpenLMI-fan | 컴퓨터 팬을 제어하는 CIM 공급자입니다. |
openlmi-hardware | 하드웨어 정보를 검색하기 위한 CIM 공급자입니다. |
openlmi-realmd | realmd를 구성하기 위한 CIM 공급자입니다. |
openlmi-software[a] | 소프트웨어 관리를 위한 CIM 공급자입니다. |
22.2. OpenLMI 설치
OpenLMI는 CIMOM, 개별 CIM 공급자 및 클라이언트 애플리케이션을 포함하는 RPM 패키지 모음으로 배포됩니다. 이를 통해 관리 시스템과 클라이언트 시스템을 구분하고 필요한 구성 요소만 설치할 수 있습니다.
22.2.1. 관리형 시스템에 OpenLMI 설치
관리형 시스템은 OpenLMI 클라이언트 도구를 사용하여 모니터링하고 관리하려는 시스템입니다. 관리 시스템에 OpenLMI를 설치하려면 다음 단계를 완료합니다.
쉘 프롬프트에서
root
로 다음을 입력하여 tog-pegasus 패키지를 설치합니다.yum install tog-pegasus
이 명령은 OpenPegasus CIMOM과 모든 종속 항목을 시스템에 설치하고
pegasus
사용자에 대한 사용자 계정을 생성합니다.다음 명령을
root
로 실행하여 필요한 CIM 공급자를 설치합니다.yum install openlmi-{storage,networking,service,account,powermanagement}
이 명령은 스토리지, 네트워크, 서비스, 계정 및 전원 관리를 위해 CIM 공급자를 설치합니다. Red Hat Enterprise Linux 7과 함께 배포된 CIM 공급자의 전체 목록은 표 22.1. “사용 가능한 CIM 공급자” 를 참조하십시오.
/etc/Pegasus/access.conf
구성 파일을 편집하여 OpenPegasus CIMOM에 연결할 수 있는 사용자 목록을 사용자 지정합니다. 기본적으로pegasus
사용자만 원격으로 및 로컬 모두에서 CIMOM에 액세스할 수 있습니다. 이 사용자 계정을 활성화하려면root
로 다음 명령을 실행하여 사용자 암호를 설정합니다.passwd pegasus
tog-pegasus.service
유닛을 활성화하여 OpenPegasus CIMOM을 시작합니다. 현재 세션에서tog-pegasus.service
장치를 활성화하려면 쉘 프롬프트에root
로 다음을 입력합니다.systemctl start tog-pegasus.service
부팅 시 자동으로 시작되도록
tog-pegasus.service
단위를 구성하려면root
로 입력합니다.systemctl enable tog-pegasus.service
원격 시스템에서 관리 시스템과 상호 작용하려면 포트
5989
(Wbem-https
)에서 TCP 통신을 활성화합니다. 현재 세션에서 이 포트를 여는 경우root
로 다음 명령을 실행합니다.firewall-cmd --add-port 5989/tcp
TCP 통신을 위해 포트
5989
를 영구적으로 열려면root
로 를 입력합니다.firewall-cmd --permanent --add-port 5989/tcp
이제 관리되는 시스템에 연결하고 22.4절. “LMIShell 사용” 에 설명된 대로 OpenLMI 클라이언트 툴을 사용하여 상호 작용할 수 있습니다. 관리 시스템에서 직접 OpenLMI 작업을 수행하려는 경우 22.2.2절. “클라이언트 시스템에 OpenLMI 설치” 에 설명된 단계를 완료하십시오.
22.2.2. 클라이언트 시스템에 OpenLMI 설치
클라이언트 시스템은 관리 시스템과 상호 작용하려는 시스템입니다. 일반적인 시나리오에서는 클라이언트 시스템과 관리 시스템이 두 개의 개별 시스템에 설치되어 있지만 관리 시스템에 클라이언트 툴을 설치하고 직접 상호 작용할 수도 있습니다.
클라이언트 시스템에 OpenLMI를 설치하려면 다음 단계를 완료합니다.
root
로 쉘 프롬프트에서 다음을 입력하여 openlmi-tools 패키지를 설치합니다.yum install openlmi-tools
이 명령은 LMIShell, OpenPegasus에서 제공하는 CIM 개체에 액세스하기 위한 대화형 클라이언트 및 인터프리터, 시스템에 대한 모든 종속성을 설치합니다.
- 22.3절. “OpenPegasus에 대한 SSL 인증서 구성” 에 설명된 대로 OpenPegasus에 대한 SSL 인증서를 구성합니다.
이제 LMIShell 클라이언트를 사용하여 22.4절. “LMIShell 사용” 에 설명된 대로 관리 시스템과 상호 작용할 수 있습니다.
22.3. OpenPegasus에 대한 SSL 인증서 구성
OpenLMI는 HTTP 전송 계층에서 작동하는 웹 기반 엔터프라이즈 관리(WBEM) 프로토콜을 사용합니다. 표준 HTTP Basic 인증은 이 프로토콜에서 수행되는데, 이는 사용자 이름 및 암호가 요청과 함께 전송됨을 의미합니다.
보안 인증을 위해서는 통신에 HTTPS를 사용하도록 OpenPegasus CIMOM을 구성해야 합니다. 암호화된 채널을 구축하기 위해 관리 시스템에 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 인증서가 필요합니다.
시스템에서 SSL/TLS 인증서를 관리하는 방법은 다음 두 가지가 있습니다.
- 자체 서명된 인증서는 인프라를 덜 사용해야 하지만 클라이언트에 배포하는 것이 더 어려워지고 안전하게 관리하기가 더 어렵습니다.
- 권한이 서명된 인증서는 설정한 후 고객에게 더 쉽게 배포할 수 있지만 초기 비용이 더 필요할 수 있습니다.
기관 서명 인증서를 사용하는 경우 클라이언트 시스템에서 신뢰할 수 있는 인증 기관을 구성해야 합니다. 그러면 권한이 모든 관리 시스템의 CIMOM 인증서에 서명하는 데 사용할 수 있습니다. 인증서는 인증서 체인의 일부일 수 있으므로 관리 시스템 인증서에 서명하는 데 사용되는 인증서는 다른 기관(예: RuntimeClass, CAcert, RSA 등)에 의해 서명될 수 있습니다.
파일 시스템의 기본 인증서 및 신뢰 저장소 위치는 표 22.2. “인증서 및 신뢰 저장소 위치” 에 나열됩니다.
구성 옵션 | 위치 | 설명 |
---|---|---|
|
| CIMOM의 공용 인증서입니다. |
|
| CIMOM에서만 알려진 개인 키입니다. |
|
| 신뢰할 수 있는 인증 기관 목록을 제공하는 파일 또는 디렉터리입니다. |
표 22.2. “인증서 및 신뢰 저장소 위치” 에 언급된 파일을 수정하는 경우 tog-pegasus
서비스를 다시 시작하여 새 인증서를 인식하는지 확인합니다. 서비스를 다시 시작하려면 root
로 쉘 프롬프트에 다음을 입력합니다.
systemctl restart tog-pegasus.service
Red Hat Enterprise Linux 7에서 시스템 서비스를 관리하는 방법에 대한 자세한 내용은 10장. systemd를 사용하여 서비스 관리 를 참조하십시오.
22.3.1. 자체 서명된 인증서 관리
자체 서명된 인증서는 자체 개인 키를 사용하여 자체에 서명하고 신뢰 체인과 연결되지 않습니다. 관리 시스템에서 tog-pegasus
서비스가 처음 시작되기 전에 관리자가 인증서를 제공하지 않은 경우 자체 서명된 인증서 세트가 시스템의 기본 호스트 이름을 인증서 제목으로 사용하여 자동으로 생성됩니다.
자동으로 생성된 자체 서명 인증서는 기본적으로 10년 동안 유효하지만 자동 갱신 기능은 없습니다. 이러한 인증서를 수정하려면 주체의 OpenSSL 또는 Mozilla NSS 문서에서 제공하는 지침에 따라 새 인증서를 수동으로 생성해야 합니다.
자체 서명된 인증서를 신뢰하도록 클라이언트 시스템을 구성하려면 다음 단계를 완료합니다.
관리 시스템에서 클라이언트 시스템의
/etc/Pegasus/server.pem
인증서를 클라이언트 시스템의/etc/pki/ca-trust/source/anchors/
디렉터리로 복사합니다. 이렇게 하려면 쉘 프롬프트에서root
로 다음을 입력합니다.scp root@hostname:/etc/Pegasus/server.pem /etc/pki/ca-trust/source/anchors/pegasus-hostname.pem
hostname 을 관리 시스템의 호스트 이름으로 교체합니다. 이 명령은
sshd
서비스가 관리 시스템에서 실행되고 있고root
사용자가 SSH 프로토콜을 통해 시스템에 로그인할 수 있도록 구성된 경우에만 작동합니다.sshd
서비스를 설치 및 구성하고scp
명령을 사용하여 SSH 프로토콜을 통해 파일을 전송하는 방법에 대한 자세한 내용은 12장. OpenSSH 을 참조하십시오.검사 합계를 원본 파일의 검사 합계와 비교하여 클라이언트 시스템에서 인증서의 무결성을 확인합니다. 관리 시스템에서
/etc/Pegasus/server.pem
파일의 검사 합계를 계산하려면 해당 시스템에서root
로 다음 명령을 실행합니다.sha1sum /etc/Pegasus/server.pem
클라이언트 시스템에서
/etc/pki/ca-trust/source/anchors/pegasus-hostname.pem
파일의 검사 합계를 계산하려면 이 시스템에서 다음 명령을 실행합니다.sha1sum /etc/pki/ca-trust/source/anchors/pegasus-hostname.pem
hostname 을 관리 시스템의 호스트 이름으로 교체합니다.
다음 명령을
root
로 실행하여 클라이언트 시스템에서 신뢰 저장소를 업데이트합니다.update-ca-trust extract
22.3.2. ID 관리를 사용하여 기관 서명 인증서 관리(권장)
Red Hat Enterprise Linux의 Identity Management 기능은 도메인에 연결된 시스템 내의 SSL 인증서 관리를 간소화하는 도메인 컨트롤러를 제공합니다. 그 외에는 ID 관리 서버는 포함된 인증 기관을 제공합니다. 클라이언트 및 관리형 시스템을 도메인에 조인하는 방법에 대한 정보는 Red Hat Enterprise Linux 7 Linux 7 Linux 도메인 ID, 인증 및 정책 가이드 또는 FreeIPA 설명서를 참조하십시오.
관리 시스템을 Identity Management에 등록해야 합니다. 클라이언트 시스템의 경우 등록은 선택 사항입니다.
관리 시스템에서 다음 단계가 필요합니다.
- ipa-client 패키지를 설치하고 Red Hat Enterprise Linux 7 Linux 7 Linux 도메인 ID, 인증 및 정책 가이드에 설명된 대로 Identity Management에 시스템을 등록합니다.
root
로 다음 명령을 입력하여 ID 관리 서명 인증서를 신뢰할 수 있는 저장소로 복사합니다.cp /etc/ipa/ca.crt /etc/pki/ca-trust/source/anchors/ipa.crt
다음 명령을
root
로 실행하여 신뢰 저장소를 업데이트합니다.update-ca-trust extract
권한 있는 도메인 사용자로 다음 명령을 실행하여 ID 관리 도메인에서 Pegasus를 서비스로 등록합니다.
ipa service-add CIMOM/hostname
hostname 을 관리 시스템의 호스트 이름으로 교체합니다.
이 명령은 ipa-admintools 패키지가 설치된 Identity Management 도메인의 모든 시스템에서 실행할 수 있습니다. 서명된 SSL 인증서를 생성하는 데 사용할 수 있는 ID 관리에 서비스 항목을 생성합니다.
-
/etc/Pegasus/
디렉터리에 있는 PEM 파일을 백업합니다(권장). root
로 다음 명령을 실행하여 서명된 인증서를 검색합니다.ipa-getcert request -f /etc/Pegasus/server.pem -k /etc/Pegasus/file.pem -N CN=hostname -K CIMOM/hostname
hostname 을 관리 시스템의 호스트 이름으로 교체합니다.
이제 인증서와 키 파일이 적절한 위치에 유지됩니다.
ipa-client-install
스크립트를 통해 관리 시스템에 설치된certmonger
데몬을 사용하면 필요한 경우 인증서를 최신 상태로 유지하고 갱신할 수 있습니다.자세한 내용은 Red Hat Enterprise Linux 7 Linux 도메인 ID, 인증 및 정책 가이드 를 참조하십시오.
클라이언트 시스템을 등록하고 신뢰 저장소를 업데이트하려면 아래 단계를 따르십시오.
- ipa-client 패키지를 설치하고 Red Hat Enterprise Linux 7 Linux 7 Linux 도메인 ID, 인증 및 정책 가이드에 설명된 대로 Identity Management에 시스템을 등록합니다.
root
로 다음 명령을 입력하여 ID 관리 서명 인증서를 신뢰할 수 있는 저장소로 복사합니다.cp /etc/ipa/ca.crt /etc/pki/ca-trust/source/anchors/ipa.crt
다음 명령을
root
로 실행하여 신뢰 저장소를 업데이트합니다.update-ca-trust extract
클라이언트 시스템을 Identity Management에 등록하지 않으려면 다음 단계를 완료하여 신뢰 저장소를 업데이트합니다.
-
동일한 ID 관리 도메인에 연결된 다른 시스템에서
/etc/ipa/ca.crt
파일을root
로 신뢰할 수 있는 저장소/etc/pki/ca-trust/source/anchors/
디렉터리에 안전하게 복사합니다. 다음 명령을
root
로 실행하여 신뢰 저장소를 업데이트합니다.update-ca-trust extract
22.3.3. 수동으로 권한 서명 인증서 관리
ID 관리 이외의 다른 메커니즘을 사용하여 권한 서명 인증서를 관리하려면 더 많은 수동 구성이 필요합니다.
모든 클라이언트가 관리 시스템 인증서에 서명할 기관의 인증서를 신뢰하도록 해야 합니다.
- 기본적으로 인증 기관을 신뢰하는 경우 이를 수행하기 위해 특정 단계를 수행할 필요가 없습니다.
기본적으로 인증 기관을 신뢰할 수 없는 경우 인증서를 클라이언트 및 관리 시스템에서 가져와야 합니다.
다음 명령을
root
로 입력하여 신뢰할 수 있는 저장소에 인증서를 복사합니다.cp /path/to/ca.crt /etc/pki/ca-trust/source/anchors/ca.crt
다음 명령을
root
로 실행하여 신뢰 저장소를 업데이트합니다.update-ca-trust extract
관리 시스템에서 다음 단계를 완료합니다.
인증서에 대한 정보를 저장하기 위해 새 SSL 구성 파일
/etc/Pegasus/ssl.cnf
를 만듭니다. 이 파일의 내용은 다음 예와 유사해야 합니다.[ req ] distinguished_name = req_distinguished_name prompt = no [ req_distinguished_name ] C = US ST = Massachusetts L = Westford O = Fedora OU = Fedora OpenLMI CN = hostname
hostname 을 관리형 시스템의 정규화된 도메인 이름으로 교체합니다.
다음 명령을
root
로 사용하여 관리 시스템에서 개인 키를 생성합니다.openssl genrsa -out /etc/Pegasus/file.pem 1024
이 명령을
root
로 실행하여 CSR(인증서 서명 요청)을 생성합니다.openssl req -config /etc/Pegasus/ssl.cnf -new -key /etc/Pegasus/file.pem -out /etc/Pegasus/server.csr
-
/etc/Pegasus/server.csr
파일을 서명을 위한 인증 기관에 보냅니다. 파일을 제출하는 자세한 절차는 특정 인증 기관에 따라 다릅니다. -
서명된 인증서가 인증 기관에서 수신되면 이를
/etc/Pegasus/server.pem
으로 저장합니다. 신뢰할 수 있는 기관의 인증서를 Pegasus 신뢰 저장소에 복사하여 Pegasus를
root
로 실행하여 자체 인증서를 신뢰할 수 있습니다.cp /path/to/ca.crt /etc/Pegasus/client.pem
설명된 모든 단계를 완료한 후 서명 기관을 신뢰하는 클라이언트는 관리형 서버의 CIMOM과 성공적으로 통신할 수 있습니다.
ID 관리 솔루션과 달리 인증서를 갱신해야 하는 경우 설명된 모든 수동 단계를 다시 수행해야 합니다. 인증서가 만료되기 전에 인증서를 갱신하는 것이 좋습니다.
22.4. LMIShell 사용
LMIShell 은 OpenPegasus CIMOM에서 제공하는 CIM 개체에 액세스하는 데 사용할 수 있는 대화형 클라이언트 및 비대화형 인터프리터입니다. Python 인터프리터를 기반으로 하지만 CIM 오브젝트와 상호 작용을 위한 추가 함수 및 클래스도 구현합니다.
22.4.1. LMIShell 시작, 사용 및 종료
Python 인터프리터와 마찬가지로 LMIShell을 대화형 클라이언트로 사용하거나 LMIShell 스크립트의 비대화형 인터프리터로 사용할 수 있습니다.
LMIShell in Interactive Mode 시작
대화형 모드에서 LMIShell 인터프리터를 시작하려면 추가 인수 없이 lmishell
명령을 실행합니다.
lmishell
기본적으로 LMIShell이 CIMOM과 연결을 설정하려고 할 때 인증 기관 신뢰 저장소에 대한 서버 측 인증서의 유효성을 검사합니다. 이 검증을 비활성화하려면 --noverify
또는 -n
명령줄 옵션을 사용하여 lmishell
명령을 실행합니다.
lmishell --noverify
탭 완료 사용
대화형 모드에서 실행하는 경우 LMIShell 인터프리터를 사용하면 Tab 키를 눌러 네임스페이스, 클래스, 메서드 및 개체 속성을 포함한 기본 프로그래밍 구조 및 CIM 개체를 완료할 수 있습니다.
검색 내역
기본적으로 LMIShell은 ~/.lmishell_history
파일의 대화형 프롬프트에 입력한 모든 명령을 저장합니다. 그러면 명령 기록을 검색하고 프롬프트에 다시 입력할 필요 없이 대화형 모드에서 이미 입력된 행을 다시 사용할 수 있습니다. 명령 기록에서 뒤로 이동하려면 위쪽 화살표 키 또는 Ctrl+p 키 조합을 누릅니다. 명령 기록에서 앞으로 이동하려면 아래쪽 화살표 키 또는 Ctrl+n 키 조합을 누릅니다.
또한 LMIShell은 증분 역방향 검색도 지원합니다. 명령 기록에서 특정 행을 찾으려면 Ctrl+r 을 누르고 명령의 일부를 입력하기 시작합니다. 예를 들면 다음과 같습니다.
> (reverse-i-search)`connect
': c = connect("server.example.com", "pegasus")
명령 기록을 지우려면 clear_history()
함수를 다음과 같이 사용합니다.
clear_history
()
~/.lmishellrc
구성 파일에서 history_length
옵션의 값을 변경하여 명령 기록에 저장된 행 수를 구성할 수 있습니다. 또한 이 구성 파일의 history_file
옵션 값을 변경하여 기록 파일의 위치를 변경할 수 있습니다. 예를 들어 기록 파일의 위치를 ~/.lmishell_history
로 설정하고 LMIShell을 구성하여 최대 1000
행을 저장하려면 ~/.lmishellrc
파일에 다음 행을 추가합니다.
history_file = "~/.lmishell_history" history_length = 1000
예외 처리
기본적으로 LMIShell 인터프리터는 모든 예외를 처리하고 반환 값을 사용합니다. 코드에서 모든 예외를 처리하려면 다음과 같이 use_exceptions()
함수를 사용합니다.
use_exceptions
()
자동 예외 처리를 다시 활성화하려면 다음을 사용합니다.
use_exception
(False
)
~/.lmishellrc
구성 파일의 use_exceptions
옵션 값을 True
로 변경하여 예외 처리를 영구적으로 비활성화할 수 있습니다.
use_exceptions = True
임시 캐시 구성
기본 구성을 사용하면 LMIShell 연결 개체는 네트워크 통신을 줄이기 위해 CIM 클래스 이름 및 CIM 클래스를 저장하는 데 임시 캐시를 사용합니다. 이 임시 캐시를 지우려면 다음과 같이 clear_cache()
메서드를 사용합니다.
object_name.clear_cache
()
object_name 을 연결 오브젝트의 이름으로 바꿉니다.
특정 연결 오브젝트에 대한 임시 캐시를 비활성화하려면 다음과 같이 use_cache()
메서드를 사용합니다.
object_name.use_cache
(False
)
다시 활성화하려면 다음을 사용하십시오.
object_name.use_cache
(True
)
~/.lmishellrc
구성 파일의 use_cache
옵션 값을 False
로 변경하여 연결 오브젝트에 대한 임시 캐시를 영구적으로 비활성화할 수 있습니다.
use_cache = False
LMIShell 종료
LMIShell 인터프리터를 종료하고 쉘 프롬프트로 돌아가려면 Ctrl+d 키 조합을 클릭하거나 exit()
함수를 다음과 같이 실행합니다.
> quit()
~]$
LMIShell 스크립트 실행
LMIShell 스크립트를 실행하려면 다음과 같이 lmishell
명령을 실행합니다.
lmishell file_name
file_name 을 스크립트 이름으로 바꿉니다. 실행 후 LMIShell 스크립트를 검사하려면 --interact
또는 -i
명령줄 옵션도 지정합니다.
lmishell --interact file_name
LMIShell 스크립트의 기본 파일 확장자는 .lmi
입니다.
22.4.2. CIMOM에 연결
LMIShell을 사용하면 동일한 시스템에서 로컬로 실행 중인 CIMOM 또는 네트워크를 통해 액세스할 수 있는 원격 시스템에서 연결할 수 있습니다.
원격 CIMOM에 연결
원격 CIMOM에서 제공하는 CIM 개체에 액세스하려면 다음과 같이 connect()
함수를 사용하여 연결 오브젝트를 생성합니다.
connect
(host_name, user_name, password)
host_name 을 관리 시스템의 호스트 이름으로 바꾸고 user_name 을 시스템에서 실행 중인 OpenPegasus CIMOM에 연결할 수 있는 사용자 이름으로, 암호를 사용자의 암호로 바꿉니다. 암호를 생략하면 LMIShell에서 사용자에게 암호를 입력하라는 메시지를 표시합니다. 함수는 LMIConnection
개체를 반환합니다.
예 22.1. 원격 CIMOM에 연결
server.example.com
에서 실행되는 OpenPegasus CIMOM에 사용자 pegasus
으로 연결하려면 대화형 프롬프트에서 다음을 입력합니다.
> c = connect("server.example.com", "pegasus")
password:
>
로컬 CIMOM에 연결
LMIShell을 사용하면 Unix 소켓을 사용하여 로컬 CIMOM에 연결할 수 있습니다. 이러한 연결 유형의 경우 루트
사용자로 LMIShell 인터프리터를 실행하고 /var/run/tog-pegasus/cimxml.socket
소켓이 있어야 합니다.
로컬 CIMOM에서 제공하는 CIM 개체에 액세스하려면 다음과 같이 connect()
함수를 사용하여 연결 오브젝트를 생성합니다.
connect
(host_name)
host_name 을 localhost
,127.0.0.1
또는 ::1
로 바꿉니다. 함수는 LMIConnection
개체 또는 None
을 반환합니다.
예 22.2. 로컬 CIMOM에 연결
root
사용자로 localhost
에서 실행되는 OpenPegasus CIMOM에 연결하려면 대화형 프롬프트에서 다음을 입력합니다.
> c = connect("localhost")
>
CIMOM에 대한 연결 확인
connect()
함수는 LMIConnection
개체를 반환하거나 연결을 설정할 수 없는 경우 None
을 반환합니다. 또한 connect()
함수가 연결을 설정하지 못하면 표준 오류 출력에 오류 메시지를 출력합니다.
CIMOM에 대한 연결이 성공적으로 설정되었는지 확인하려면 다음과 같이 isinstance()
함수를 사용합니다.
isinstance
(object_name,LMIConnection
)
object_name 을 연결 오브젝트의 이름으로 바꿉니다. 이 함수는 object_name 이 LMIConnection
객체이거나 그렇지 않으면 False
를 반환합니다.
예 22.3. CIMOM에 대한 연결 확인
예 22.1. “원격 CIMOM에 연결” 에서 만든 c
변수에 LMIConnection
개체가 포함되어 있는지 확인하려면 대화형 프롬프트에서 다음을 입력합니다.
> isinstance(c, LMIConnection)
True
>
또는 c
가 None
이 아닌지 확인할 수 있습니다.
> c is None
False
>
22.4.3. 네임스페이스 작업
LMIShell 네임스페이스는 사용 가능한 클래스를 구성하고 다른 네임스페이스 및 클래스에 대한 hierarchic 액세스 포인트 역할을 하는 자연 수단을 제공합니다. 루트
네임스페이스는 연결 오브젝트의 첫 번째 진입점입니다.
사용 가능한 네임스페이스 나열
사용 가능한 모든 네임스페이스를 나열하려면 다음과 같이 print_namespaces()
메서드를 사용합니다.
object_name.print_namespaces
()
object_name 을 검사할 오브젝트의 이름으로 바꿉니다. 이 메서드는 사용 가능한 네임스페이스를 표준 출력에 출력합니다.
사용 가능한 네임스페이스 목록을 가져오려면 오브젝트 특성 네임스페이스에
액세스합니다.
object_name.namespaces
이렇게 하면 문자열 목록이 반환됩니다.
예 22.4. 사용 가능한 네임스페이스 나열
예 22.1. “원격 CIMOM에 연결” 에서 생성된 c
연결 오브젝트의 루트
네임스페이스 오브젝트를 검사하고 사용 가능한 모든 네임스페이스를 나열하려면 대화형 프롬프트에서 다음을 입력합니다.
> c.root.print_namespaces() cimv2 interop PG_InterOp PG_Internal >
이러한 네임스페이스 목록을 root_namespaces
라는 변수에 할당하려면 다음을 입력합니다.
> root_namespaces = c.root.namespaces >
네임스페이스 오브젝트 액세스
특정 네임스페이스 오브젝트에 액세스하려면 다음 구문을 사용합니다.
object_name.namespace_name
object_name 을 검사할 오브젝트의 이름으로, namespace_name 을 액세스할 네임스페이스의 이름으로 바꿉니다. LMINamespace
오브젝트가 반환됩니다.
예 22.5. 네임스페이스 오브젝트 액세스
예 22.1. “원격 CIMOM에 연결” 에서 생성한 c
연결 오브젝트의 cimv2
네임스페이스에 액세스하여 ns
라는 변수에 할당하려면 대화형 프롬프트에서 다음을 입력합니다.
> ns = c.root.cimv2
>
22.4.4. 클래스 작업
LMIShell 클래스는 CIMOM에서 제공하는 클래스를 나타냅니다. 속성, 메서드, 인스턴스, 인스턴스 이름 및 ValueMap 속성에 액세스하고 나열하며 해당 문서 문자열을 출력하고 새 인스턴스 및 인스턴스 이름을 생성할 수 있습니다.
사용 가능한 클래스 나열
특정 네임스페이스에서 사용 가능한 모든 클래스를 나열하려면 다음과 같이 print_classes()
메서드를 사용합니다.
namespace_object.print_classes()
namespace_object 를 검사할 네임스페이스 오브젝트로 교체합니다. 이 메서드는 표준 출력에 사용 가능한 클래스를 출력합니다.
사용 가능한 클래스 목록을 가져오려면 classes()
메서드를 사용합니다.
namespace_object.classes
()
이 메서드는 문자열 목록을 반환합니다.
예 22.6. 사용 가능한 클래스 나열
예 22.5. “네임스페이스 오브젝트 액세스” 에서 생성된 ns
네임스페이스 오브젝트를 검사하고 사용 가능한 모든 클래스를 나열하려면 대화형 프롬프트에서 다음을 입력합니다.
> ns.print_classes() CIM_CollectionInSystem CIM_ConcreteIdentity CIM_ControlledBy CIM_DeviceSAPImplementation CIM_MemberOfStatusCollection ... >
이러한 클래스 목록을 cimv2_classes
라는 변수에 할당하려면 다음을 입력합니다.
> cimv2_classes = ns.classes() >
클래스 오브젝트 액세스
CIMOM에서 제공하는 특정 클래스 오브젝트에 액세스하려면 다음 구문을 사용합니다.
namespace_object.class_name
namespace_object 를 검사할 네임스페이스 오브젝트의 이름으로 바꾸고 class_name 을 액세스할 클래스의 이름으로 바꿉니다.
예 22.7. 클래스 오브젝트 액세스
예 22.5. “네임스페이스 오브젝트 액세스” 에서 만든 ns
네임스페이스 오브젝트의 LMI_IPNetworkConnection
클래스에 액세스하여 cls
라는 변수에 할당하려면 대화형 프롬프트에서 다음을 입력합니다.
> cls = ns.LMI_IPNetworkConnection >
클래스 오브젝트 검사
모든 클래스 오브젝트는 해당 이름 및 자신이 속한 네임스페이스에 대한 정보와 자세한 클래스 문서를 저장합니다. 특정 클래스 오브젝트의 이름을 가져오려면 다음 구문을 사용합니다.
class_object.classname
class_object 를 검사할 클래스 오브젝트의 이름으로 교체합니다. 이렇게 하면 개체 이름의 문자열 표현이 반환됩니다.
클래스 오브젝트가 속하는 네임스페이스에 대한 정보를 가져오려면 다음을 사용합니다.
class_object.namespace
네임스페이스의 문자열 표현이 반환됩니다.
자세한 클래스 문서를 표시하려면 다음과 같이 doc()
메서드를 사용합니다.
class_object.doc
()
예 22.8. 클래스 오브젝트 검사
예 22.7. “클래스 오브젝트 액세스” 에서 생성된 cls
클래스 오브젝트를 검사하고 해당 이름과 해당 네임스페이스를 표시하려면 대화형 프롬프트에서 다음을 입력합니다.
> cls.classname 'LMI_IPNetworkConnection' > cls.namespace 'root/cimv2' >
클래스 설명서에 액세스하려면 다음을 입력합니다.
> cls.doc() Class: LMI_IPNetworkConnection SuperClass: CIM_IPNetworkConnection [qualifier] string UMLPackagePath: 'CIM::Network::IP' [qualifier] string Version: '0.1.0' ...
사용 가능한 방법 나열
특정 클래스 오브젝트의 사용 가능한 모든 메서드를 나열하려면 다음과 같이 print_methods()
메서드를 사용합니다.
class_object.print_methods
()
class_object 를 검사할 클래스 오브젝트의 이름으로 교체합니다. 이 메서드는 표준 출력에 사용 가능한 방법을 출력합니다.
사용 가능한 메서드 목록을 가져오려면 methods()
메서드를 사용합니다.
class_object.methods()
이 메서드는 문자열 목록을 반환합니다.
예 22.9. 사용 가능한 방법 나열
예 22.7. “클래스 오브젝트 액세스” 에서 생성된 cls
클래스 오브젝트를 검사하고 사용 가능한 모든 메서드를 나열하려면 대화형 프롬프트에서 다음을 입력합니다.
> cls.print_methods() RequestStateChange >
이러한 메서드 목록을 service_methods
라는 변수에 할당하려면 다음을 입력합니다.
> service_methods = cls.methods() >
사용 가능한 속성 나열
특정 클래스 개체의 사용 가능한 모든 속성을 나열하려면 다음과 같이 print_properties()
메서드를 사용합니다.
class_object.print_properties
()
class_object 를 검사할 클래스 오브젝트의 이름으로 교체합니다. 이 메서드는 표준 출력에 사용 가능한 속성을 출력합니다.
사용 가능한 속성 목록을 가져오려면 properties()
메서드를 사용합니다.
class_object.properties
()
이 메서드는 문자열 목록을 반환합니다.
예 22.10. 사용 가능한 속성 나열
예 22.7. “클래스 오브젝트 액세스” 에서 생성된 cls
클래스 오브젝트를 검사하고 사용 가능한 모든 속성을 나열하려면 대화형 프롬프트에서 다음을 입력합니다.
> cls.print_properties() RequestedState HealthState StatusDescriptions TransitioningToState Generation ... >
service_properties
라는 변수에 이러한 클래스 목록을 할당하려면 다음을 입력합니다.
> service_properties = cls.properties() >
ValueMap 속성 나열 및 보기
CIM 클래스에는 Managed Object Format(MOF) 정의에 ValueMap 속성 을 포함할 수 있습니다. ValueMap 속성에는 상수 값이 포함되어 있으며, 메서드를 호출하거나 반환된 값을 확인할 때 유용할 수 있습니다. ValueMap properties contain constant values, which may be useful when calling methods or checking returned values.
특정 클래스 개체의 사용 가능한 모든 ValueMap 속성을 나열하려면 다음과 같이 print_valuemap_properties()
메서드를 사용합니다.
class_object.print_valuemap_properties
()
class_object 를 검사할 클래스 오브젝트의 이름으로 교체합니다. 이 메서드는 사용 가능한 ValueMap 속성을 표준 출력에 출력합니다.
사용 가능한 ValueMap 속성 목록을 가져오려면 valuemap_properties()
메서드를 사용합니다.
class_object.valuemap_properties
()
이 메서드는 문자열 목록을 반환합니다.
예 22.11. ValueMap 속성 나열
예 22.7. “클래스 오브젝트 액세스” 에서 생성된 cls
클래스 오브젝트를 검사하고 사용 가능한 모든 ValueMap 속성을 나열하려면 대화형 프롬프트에서 다음을 입력합니다.
> cls.print_valuemap_properties() RequestedState HealthState TransitioningToState DetailedStatus OperationalStatus ... >
service_valuemap_properties
라는 변수에 이러한 ValueMap 속성 목록을 할당하려면 다음을 입력합니다.
> service_valuemap_properties = cls.valuemap_properties() >
특정 ValueMap 속성에 액세스하려면 다음 구문을 사용합니다.
class_object.valuemap_propertyValues
valuemap_property 를 액세스할 ValueMap 속성의 이름으로 바꿉니다.
사용 가능한 모든 상수 값을 나열하려면 다음과 같이 print_values()
메서드를 사용합니다.
class_object.valuemap_propertyValues
.print_values
()
이 메서드는 사용 가능한 상수 값을 표준 출력에 출력합니다. values()
메서드를 사용하여 사용 가능한 상수 값 목록을 가져올 수도 있습니다.
class_object.valuemap_propertyValues
.values
()
이 메서드는 문자열 목록을 반환합니다.
예 22.12. ValueMap 속성 액세스
예 22.11. “ValueMap 속성 나열” RequestedState
라는 ValueMap 속성을 언급합니다. 이 속성을 검사하고 사용 가능한 상수 값을 나열하려면 대화형 프롬프트에서 다음을 입력합니다.
> cls.RequestedStateValues.print_values() Reset NoChange NotApplicable Quiesce Unknown ... >
이러한 상수 값 목록을 requested_state_values
라는 변수에 할당하려면 다음을 입력합니다.
> requested_state_values = cls.RequestedStateValues.values() >
특정 상수 값에 액세스하려면 다음 구문을 사용합니다.
class_object.valuemap_propertyValues
.constant_value_name
constant_value_name 을 상수 값의 이름으로 바꿉니다. 또는 다음과 같이 value()
메서드를 사용할 수 있습니다.
class_object.valuemap_propertyValues
.value
("constant_value_name")
특정 상수 값의 이름을 확인하려면 value_name()
메서드를 사용합니다.
class_object.valuemap_propertyValues
.value_name
("constant_value")
이 메서드는 문자열을 반환합니다.
예 22.13. Constant 값에 액세스
예 22.12. “ValueMap 속성 액세스” RequestedState
속성이 Reset
이라는 상수 값을 제공하는 것을 보여줍니다. 이 명명된 상수 값에 액세스하려면 대화형 프롬프트에서 다음을 입력합니다.
>cls.RequestedStateValues.Reset
11 >cls.RequestedStateValues.value("Reset")
11 >
이 상수 값의 이름을 확인하려면 다음을 입력합니다.
> cls.RequestedStateValues.value_name(11) u'Reset' >
CIMClass 오브젝트 가져오기
많은 클래스 메서드에는 CIMClass
개체에 대한 액세스가 필요하지 않으므로 LMIShell은 호출된 메서드가 실제로 필요할 때 CIMOM에서 이 오브젝트만 가져옵니다. CIMClass
오브젝트를 수동으로 가져오려면 다음과 같이 fetch()
메서드를 사용합니다.
class_object.fetch
()
class_object 를 클래스 오브젝트의 이름으로 바꿉니다. CIMClass
오브젝트에 액세스해야 하는 메서드는 자동으로 가져옵니다.
22.4.5. 인스턴스 작업
LMIShell 인스턴스는 CIMOM에서 제공하는 인스턴스를 나타냅니다. 속성을 가져오고 설정하고, 메서드를 나열 및 호출하고, 문서 문자열을 출력하고, 관련 또는 연결 오브젝트 목록을 가져오고, 수정된 오브젝트를 CIMOM으로 푸시하고, CIMOM에서 개별 인스턴스를 삭제할 수 있습니다.
인스턴스 액세스
특정 클래스 개체의 사용 가능한 모든 인스턴스 목록을 가져오려면 다음과 같이 instances()
메서드를 사용합니다.
class_object.instances
()
class_object 를 검사할 클래스 오브젝트의 이름으로 교체합니다. 이 메서드는 LMIInstance
오브젝트 목록을 반환합니다.
클래스 오브젝트의 첫 번째 인스턴스에 액세스하려면 first_instance()
메서드를 사용합니다.
class_object.first_instance
()
이 메서드는 LMIInstance
개체를 반환합니다.
모든 인스턴스를 나열하거나 첫 번째 인스턴스를 반환하는 것 외에도 instances()
와 first_instance()
모두 선택적 인수를 지원하여 결과를 필터링할 수 있습니다.
class_object.instances
(criteria)
class_object.first_instance
(criteria)
기준을 키-값 쌍으로 구성된 사전으로 교체합니다. 여기서 키는 이러한 속성의 필수 값을 나타내는 인스턴스 속성 및 값을 나타냅니다.
예 22.14. 인스턴스 액세스
예 22.7. “클래스 오브젝트 액세스” 에서 생성된 cls
클래스 오브젝트의 첫 번째 인스턴스를 찾은 다음 ElementName
속성이 eth0
과 같고 device
라는 변수에 할당하려면 대화형 프롬프트에서 다음을 입력합니다.
> device = cls.first_instance({"ElementName": "eth0"}) >
인스턴스 검사
모든 인스턴스 오브젝트는 해당 클래스 이름 및 자신이 속한 네임스페이스에 대한 정보와 해당 속성 및 값에 대한 자세한 문서를 저장합니다. 또한 인스턴스 오브젝트를 사용하면 고유한 ID 오브젝트를 검색할 수 있습니다.
특정 인스턴스 개체의 클래스 이름을 가져오려면 다음 구문을 사용합니다.
instance_object.classname
instance_object 를 검사할 인스턴스 오브젝트의 이름으로 교체합니다. 이 함수는 클래스 이름의 문자열 표현을 반환합니다.
인스턴스 오브젝트가 속하는 네임스페이스에 대한 정보를 가져오려면 다음을 사용합니다.
instance_object.namespace
네임스페이스의 문자열 표현이 반환됩니다.
인스턴스 오브젝트의 고유한 ID 오브젝트를 검색하려면 다음을 사용합니다.
instance_object.path
LMIInstanceName
오브젝트를 반환합니다.
마지막으로 자세한 문서를 표시하려면 다음과 같이 doc()
메서드를 사용합니다.
instance_object.doc
()
예 22.15. 인스턴스 검사
예 22.14. “인스턴스 액세스” 에서 생성된 장치
인스턴스 오브젝트를 검사하고 클래스 이름과 해당 네임스페이스를 표시하려면 대화형 프롬프트에서 다음을 입력합니다.
> device.classname u'LMI_IPNetworkConnection' > device.namespace 'root/cimv2' >
인스턴스 오브젝트 설명서에 액세스하려면 다음을 입력합니다.
> device.doc() Instance of LMI_IPNetworkConnection [property] uint16 RequestedState = '12' [property] uint16 HealthState [property array] string [] StatusDescriptions ...
새 인스턴스 생성
특정 CIM 공급자를 통해 특정 클래스 개체의 새 인스턴스를 만들 수 있습니다. 클래스 오브젝트의 새 인스턴스를 생성하려면 다음과 같이 create_instance()
메서드를 사용합니다.
class_object.create_instance
(properties)
class_object 를 클래스 오브젝트의 이름으로 바꾸고 속성은 키-값 쌍으로 구성된 사전으로 교체합니다. 여기서 키는 인스턴스 속성과 값이 속성 값을 나타냅니다. 이 메서드는 LMIInstance
개체를 반환합니다.
예 22.16. 새 인스턴스 생성
LMI_Group
클래스는 시스템 그룹을 나타내고 LMI_Account
클래스는 관리형 시스템의 사용자 계정을 나타냅니다. 예 22.5. “네임스페이스 오브젝트 액세스” 에서 생성된 ns
네임스페이스 오브젝트를 사용하려면 pegasus
라는 시스템 그룹과 lmishell-user
라는 사용자에 대한 이 두 클래스의 인스턴스를 생성하고 해당 클래스를 group
및 user
라는 변수에 할당하고 대화형 프롬프트에서 다음을 입력합니다.
> group = ns.LMI_Group.first_instance({"Name" : "pegasus"}) > user = ns.LMI_Account.first_instance({"Name" : "lmishell-user"}) >
lmishell-user
사용자에 대한 LMI_Identity
클래스의 인스턴스를 가져오려면 다음을 입력합니다.
> identity = user.first_associator(ResultClass="LMI_Identity") >
LMI_MemberOfGroup
클래스는 시스템 그룹 멤버십을 나타냅니다. LMI_MemberOfGroup
클래스를 사용하여 lmishell-user
를 pegasus
그룹에 추가하려면 다음과 같이 이 클래스의 새 인스턴스를 만듭니다.
> ns.LMI_MemberOfGroup.create_instance({ ... "Member" : identity.path, ... "Collection" : group.path}) LMIInstance(classname="LMI_MemberOfGroup", ...) >
개별 인스턴스 삭제
CIMOM에서 특정 인스턴스를 삭제하려면 다음과 같이 delete()
메서드를 사용합니다.
instance_object.delete
()
instance_object 를 삭제할 인스턴스 오브젝트의 이름으로 교체합니다. 이 메서드는 부울을 반환합니다. 인스턴스를 삭제한 후에는 해당 속성 및 메서드에 액세스할 수 없습니다.
예 22.17. 개별 인스턴스 삭제
LMI_Account
클래스는 관리 시스템의 사용자 계정을 나타냅니다. 예 22.5. “네임스페이스 오브젝트 액세스” 에서 생성된 ns
네임스페이스 오브젝트를 사용하려면 lmishell-
라는 사용자에 대한 user
LMI_Account
클래스의 인스턴스를 생성하고 대화형 프롬프트에서 다음을 입력합니다.
> user = ns.LMI_Account.first_instance({"Name" : "lmishell-user"}) >
이 인스턴스를 삭제하고 시스템에서 lmishell-user
를 제거하려면 다음을 입력합니다.
> user.delete()
True
>
사용 가능한 속성 나열 및 액세스
특정 인스턴스 개체의 사용 가능한 모든 속성을 나열하려면 다음과 같이 print_properties()
메서드를 사용합니다.
instance_object.print_properties
()
instance_object 를 검사할 인스턴스 오브젝트의 이름으로 교체합니다. 이 메서드는 표준 출력에 사용 가능한 속성을 출력합니다.
사용 가능한 속성 목록을 가져오려면 properties()
메서드를 사용합니다.
instance_object.properties
()
이 메서드는 문자열 목록을 반환합니다.
예 22.18. 사용 가능한 속성 나열
예 22.14. “인스턴스 액세스” 에서 생성된 장치
인스턴스 오브젝트를 검사하고 사용 가능한 모든 속성을 나열하려면 대화형 프롬프트에서 다음을 입력합니다.
> device.print_properties() RequestedState HealthState StatusDescriptions TransitioningToState Generation ... >
이러한 속성 목록을 device_properties
라는 변수에 할당하려면 다음을 입력합니다.
> device_properties = device.properties() >
특정 속성의 현재 값을 가져오려면 다음 구문을 사용합니다.
instance_object.property_name
property_name 을 액세스할 속성의 이름으로 바꿉니다.
특정 속성의 값을 수정하려면 다음과 같이 값을 할당합니다.To modify the value of a particular property, assign a value to it as follows:
instance_object.property_name = value
값을 속성의 새 값으로 바꿉니다. CIMOM에 변경 사항을 전파하려면 push()
메서드도 실행해야 합니다.
instance_object.push
()
이 메서드는 반환 값, 반환 값 매개 변수 및 오류 문자열로 구성 된 3 개의item tuple을 반환 합니다.This method returns a three-item tuple consisting of a return value, return value parameters, and an error string.
예 22.19. 개별 속성 액세스
예 22.14. “인스턴스 액세스” 에서 생성된 장치
인스턴스 오브젝트를 검사하고 SystemName
이라는 속성의 값을 표시하려면 대화형 프롬프트에서 다음을 입력합니다.
> device.SystemName
u'server.example.com'
>
사용 가능한 방법 나열 및 사용
특정 인스턴스 오브젝트의 사용 가능한 모든 메서드를 나열하려면 다음과 같이 print_methods()
메서드를 사용합니다.
instance_object.print_methods
()
instance_object 를 검사할 인스턴스 오브젝트의 이름으로 교체합니다. 이 메서드는 표준 출력에 사용 가능한 방법을 출력합니다.
사용 가능한 메서드 목록을 가져오려면 method()
메서드를 사용합니다.
instance_object.methods
()
이 메서드는 문자열 목록을 반환합니다.
예 22.20. 사용 가능한 방법 나열
예 22.14. “인스턴스 액세스” 에서 생성된 장치
인스턴스 오브젝트를 검사하고 사용 가능한 모든 방법을 나열하려면 대화형 프롬프트에서 다음을 입력합니다.
> device.print_methods() RequestStateChange >
이러한 메서드 목록을 network_device_methods
라는 변수에 할당하려면 다음을 입력합니다.
> network_device_methods = device.methods() >
특정 메서드를 호출하려면 다음 구문을 사용합니다.
instance_object.method_name( parameter=value, ...)
instance_object 를 사용할 인스턴스 오브젝트의 이름으로, method_name 을 호출할 메서드의 이름으로, 매개 변수를 설정할 매개변수 의 이름으로, value 를 이 매개 변수의 값으로 바꿉니다. 메서드 반환은 반환 값, 반환 값 매개 변수 및 오류 문자열로 구성 된 3 개의item tuple을 반환 합니다.Services return a three-item tuple consisting of a return value, return value parameters, and an error string.
LMIInstance
오브젝트는 콘텐츠(properties, methods, 한정자 등)를 자동으로 새로 고침 하지 않습니다. 이렇게 하려면 아래에 설명된 대로 refresh()
메서드를 사용합니다.
예 22.21. 방법 사용
PG_ComputerSystem
클래스는 시스템을 나타냅니다. 예 22.5. “네임스페이스 오브젝트 액세스” 에서 만든 ns
네임 스페이스 개체를 사용하여 이 클래스의 인스턴스를 만들고 sys
라는 변수에 할당하려면 대화형 프롬프트에서 다음을 입력합니다.
> sys = ns.PG_ComputerSystem.first_instance() >
LMI_AccountManagementService
클래스는 시스템의 사용자 및 그룹을 관리할 수 있는 메서드를 구현합니다. 이 클래스의 인스턴스를 생성하고 acc
라는 변수에 할당하려면 다음을 입력합니다.
> acc = ns.LMI_AccountManagementService.first_instance() >
시스템에서 lmishell-user
라는 새 사용자를 생성하려면 다음과 같이 CreateAccount()
메서드를 사용합니다.
> acc.CreateAccount(Name="lmishell-user", System=sys) LMIReturnValue(rval=0, rparams=NocaseDict({u'Account': LMIInstanceName(classname="LMI_Account"...), u'Identities': [LMIInstanceName(classname="LMI_Identity"...), LMIInstanceName(classname="LMI_Identity"...)]}), errorstr='')
LMIShell은 동기 메서드를 사용할 때 LMIShell에서 해당 Job 객체가 "프로어링된" 상태로 변경될 때까지 기다린 다음 이 작업의 반환 매개변수를 반환합니다. 지정된 메서드가 다음 클래스 중 하나의 개체를 반환하면 LMIShell은 동기 메서드 호출을 수행할 수 있습니다.
-
LMI_StorageJob
-
LMI_SoftwareInstallationJob
-
LMI_NetworkJob
LMIShell은 먼저 waiting 메서드로 표시를 사용하려고 합니다. 실패하면 대신 폴링 방법을 사용합니다.
동기 메서드 호출을 수행하려면 다음 구문을 사용합니다.
instance_object.Sync
method_name(
parameter=value,
...)
instance_object 를 사용할 인스턴스 오브젝트의 이름으로, method_name 을 호출할 메서드의 이름으로, 매개 변수를 설정할 매개변수 의 이름으로, value 를 이 매개 변수의 값으로 바꿉니다. 모든 동기 메서드에는 이름에 Sync
접두사가 있고 작업의 반환 값, 작업의 반환 값 매개 변수, 작업의 반환 값 매개 변수 및 작업의 오류 문자열로 구성된 3-item tuple을 반환합니다.
LMIShell은 폴링 방법만 사용하도록 할 수도 있습니다. 이렇게 하려면 다음과 같이 PreferPolling
매개변수를 지정합니다.
instance_object.Sync
method_name(PreferPolling
=True
parameter=value, ...)
ValueMap 매개변수 나열 및 보기
CIM 메서드에는 Managed Object Format(MOF) 정의에 ValueMap 매개 변수 가 포함될 수 있습니다. ValueMap 매개변수에는 상수 값이 포함됩니다.
특정 메서드의 사용 가능한 ValueMap 매개 변수를 모두 나열하려면 다음과 같이 print_valuemap_parameters()
메서드를 사용합니다.
instance_object.method_name.print_valuemap_parameters
()
instance_object 를 인스턴스 오브젝트의 이름과 method_name 을 검사할 메서드의 이름으로 바꿉니다. 이 메서드는 사용 가능한 ValueMap 매개 변수를 표준 출력에 출력합니다.
사용 가능한 ValueMap 매개변수 목록을 가져오려면 valuemap_parameters()
메서드를 사용합니다.
instance_object.method_name.valuemap_parameters
()
이 메서드는 문자열 목록을 반환합니다.
예 22.22. ValueMap 매개변수 나열
예 22.21. “방법 사용” 에서 생성된 acc
인스턴스 오브젝트를 검사하고 CreateAccount()
메서드의 사용 가능한 모든 ValueMap 매개변수를 나열하려면 대화형 프롬프트에서 다음을 입력합니다.
> acc.CreateAccount.print_valuemap_parameters() CreateAccount >
이러한 ValueMap 매개변수 목록을 create_account_parameters
라는 변수에 할당하려면 다음을 입력합니다.
> create_account_parameters = acc.CreateAccount.valuemap_parameters() >
특정 ValueMap 매개변수에 액세스하려면 다음 구문을 사용하십시오.
instance_object.method_name.valuemap_parameterValues
valuemap_parameter 를 액세스할 ValueMap 매개변수의 이름으로 바꿉니다.
사용 가능한 모든 상수 값을 나열하려면 다음과 같이 print_values()
메서드를 사용합니다.
instance_object.method_name.valuemap_parameterValues
.print_values
()
이 메서드는 사용 가능한 상수 값을 표준 출력에 출력합니다. values()
메서드를 사용하여 사용 가능한 상수 값 목록을 가져올 수도 있습니다.
instance_object.method_name.valuemap_parameterValues
.values
()
이 메서드는 문자열 목록을 반환합니다.
예 22.23. ValueMap 매개변수에 액세스
예 22.22. “ValueMap 매개변수 나열” CreateAccount
라는 ValueMap 매개변수를 언급합니다. 이 매개 변수를 검사하고 사용 가능한 상수 값을 나열하려면 대화형 프롬프트에서 다음을 입력합니다.
> acc.CreateAccount.CreateAccountValues.print_values() Operationunsupported Failed Unabletosetpasswordusercreated Unabletocreatehomedirectoryusercreatedandpasswordset Operationcompletedsuccessfully >
이러한 상수 값 목록을 create_account_values
라는 변수에 할당하려면 다음을 입력합니다.
> create_account_values = acc.CreateAccount.CreateAccountValues.values() >
특정 상수 값에 액세스하려면 다음 구문을 사용합니다.
instance_object.method_name.valuemap_parameterValues
.constant_value_name
constant_value_name 을 상수 값의 이름으로 바꿉니다. 또는 다음과 같이 value()
메서드를 사용할 수 있습니다.
instance_object.method_name.valuemap_parameterValues
.value
("constant_value_name")
특정 상수 값의 이름을 확인하려면 value_name()
메서드를 사용합니다.
instance_object.method_name.valuemap_parameterValues
.value_name
("constant_value")
이 메서드는 문자열을 반환합니다.
예 22.24. Constant 값에 액세스
예 22.23. “ValueMap 매개변수에 액세스” CreateAccount
ValueMap 매개변수가 Failed
라는 상수 값을 제공하는 것을 보여줍니다. 이 명명된 상수 값에 액세스하려면 대화형 프롬프트에서 다음을 입력합니다.
>acc.CreateAccount.CreateAccountValues.Failed
2 >acc.CreateAccount.CreateAccountValues.value("Failed")
2 >
이 상수 값의 이름을 확인하려면 다음을 입력합니다.
> acc.CreateAccount.CreateAccountValues.value_name(2) u'Failed' >
인스턴스 오브젝트 새로 고침
CIMOM 측에서 CIM 개체를 나타내는 LMIShell에서 사용하는 로컬 개체는 LMIShell으로 작업하는 동안 이러한 개체가 변경되는 경우 오래된 개체를 가져올 수 있습니다. 특정 인스턴스 개체의 속성 및 메서드를 업데이트하려면 다음과 같이 refresh()
메서드를 사용합니다.
instance_object.refresh
()
instance_object 를 새로 고칠 오브젝트의 이름으로 교체합니다. 이 메서드는 반환 값, 반환 값 매개 변수 및 오류 문자열로 구성 된 3 개의item tuple을 반환 합니다.This method returns a three-item tuple consisting of a return value, return value parameter, and an error string.
예 22.25. 인스턴스 오브젝트 새로 고침
예 22.14. “인스턴스 액세스” 에서 생성된 장치
인스턴스 오브젝트의 속성 및 메서드를 업데이트하려면 대화형 프롬프트에서 다음을 입력합니다.
> device.refresh()
LMIReturnValue(rval=True, rparams=NocaseDict({}), errorstr='')
>
MOF 표현 표시
인스턴스 오브젝트의MOF(Managed Object Format) 표현을 표시하려면 다음과 같이 tomof()
메서드를 사용합니다.
instance_object.tomof
()
instance_object 를 검사할 인스턴스 오브젝트의 이름으로 교체합니다. 이 메서드는 오브젝트의 MOF 표현을 표준 출력에 출력합니다.
예 22.26. MOF 표현 표시
예 22.14. “인스턴스 액세스” 에서 생성된 장치
인스턴스 오브젝트의 MOF 표현을 표시하려면 대화형 프롬프트에서 다음을 입력합니다.
> device.tomof() instance of LMI_IPNetworkConnection { RequestedState = 12; HealthState = NULL; StatusDescriptions = NULL; TransitioningToState = 12; ...
22.4.6. 인스턴스 이름 작업
LMIShell 인스턴스 이름은 기본 키와 해당 값 집합을 보유하는 오브젝트입니다. 이러한 유형의 개체는 인스턴스를 정확하게 식별합니다.
인스턴스 이름 액세스
CIMInstance
오브젝트는 CIMInstanceName
개체에 의해 식별됩니다. 사용 가능한 모든 인스턴스 이름 오브젝트 목록을 가져오려면 다음과 같이 instance_names()
메서드를 사용합니다.
class_object.instance_names
()
class_object 를 검사할 클래스 오브젝트의 이름으로 교체합니다. 이 메서드는 LMIInstanceName
오브젝트 목록을 반환합니다.
클래스 오브젝트의 첫 번째 인스턴스 이름 오브젝트에 액세스하려면 first_instance_name()
메서드를 사용합니다.
class_object.first_instance_name
()
이 메서드는 LMIInstanceName
개체를 반환합니다.
모든 인스턴스 이름 오브젝트를 나열하거나 첫 번째 오브젝트를 반환하는 것 외에도 instance_names()
와 first_instance_name()
모두 선택적 인수를 지원하여 결과를 필터링할 수 있습니다.
class_object.instance_names
(criteria)
class_object.first_instance_name
(criteria)
기준을 키-값 쌍으로 구성된 사전으로 교체합니다. 여기서 키는 키 속성과 이러한 키 속성의 필수 값을 나타냅니다.
예 22.27. 인스턴스 이름 액세스
예 22.7. “클래스 오브젝트 액세스” 에서 만든 cls
클래스 오브젝트의 첫 번째 인스턴스 이름을 찾아 eth0
과 동일한 변수 device_name
에 할당하려면 대화형 프롬프트에서 다음을 입력합니다.
> device_name = cls.first_instance_name({"Name": "eth0"}) >
인스턴스 이름 검사
모든 인스턴스 이름 오브젝트는 해당 클래스 이름 및 해당 네임스페이스에 대한 정보를 저장합니다.
특정 인스턴스 이름 개체의 클래스 이름을 가져오려면 다음 구문을 사용합니다.
instance_name_object.classname
instance_name_object 를 검사할 인스턴스 이름 오브젝트의 이름으로 바꿉니다. 이 함수는 클래스 이름의 문자열 표현을 반환합니다.
인스턴스 이름 오브젝트가 속하는 네임스페이스에 대한 정보를 가져오려면 다음을 사용합니다.
instance_name_object.namespace
네임스페이스의 문자열 표현이 반환됩니다.
예 22.28. 인스턴스 이름 검사
예 22.27. “인스턴스 이름 액세스” 에서 생성된 device_name
인스턴스 이름 오브젝트를 검사하고 클래스 이름과 해당 네임스페이스를 표시하려면 대화형 프롬프트에서 다음을 입력합니다.
> device_name.classname u'LMI_IPNetworkConnection' > device_name.namespace 'root/cimv2' >
새 인스턴스 이름 생성
LMIShell을 사용하면 원격 오브젝트의 기본 키를 모두 알고 있는 경우 새 래핑된 CIMInstanceName
개체를 만들 수 있습니다. 그러면 이 인스턴스 이름 오브젝트를 사용하여 전체 인스턴스 오브젝트를 검색할 수 있습니다.
클래스 오브젝트의 새 인스턴스 이름을 생성하려면 다음과 같이 new_instance_name()
메서드를 사용합니다.
class_object.new_instance_name
(key_properties)
class_object 를 클래스 오브젝트의 이름으로 바꾸고 key_properties 를 키-값 쌍으로 구성된 사전으로 교체합니다. 여기서 키는 키 속성과 값을 키 속성 값을 나타냅니다. 이 메서드는 LMIInstanceName
개체를 반환합니다.
예 22.29. 새 인스턴스 이름 생성
LMI_Account
클래스는 관리 시스템의 사용자 계정을 나타냅니다. 예 22.5. “네임스페이스 오브젝트 액세스” 에서 생성된 ns
네임스페이스 오브젝트를 사용하고 관리 시스템에서 lmishell-user
사용자를 나타내는 LMI_Account
클래스의 새 인스턴스 이름을 생성하려면 대화형 프롬프트에서 다음을 입력합니다.
> instance_name = ns.LMI_Account.new_instance_name({ ... "CreationClassName" : "LMI_Account", ... "Name" : "lmishell-user", ... "SystemCreationClassName" : "PG_ComputerSystem", ... "SystemName" : "server"}) >
키 속성 나열 및 액세스
특정 인스턴스 이름 개체의 사용 가능한 모든 키 속성을 나열하려면 다음과 같이 print_key_properties()
메서드를 사용합니다.
instance_name_object.print_key_properties
()
instance_name_object 를 검사할 인스턴스 이름 오브젝트의 이름으로 바꿉니다. 이 메서드는 사용 가능한 키 속성을 표준 출력에 출력합니다.
사용 가능한 키 속성 목록을 가져오려면 key_properties()
메서드를 사용합니다.
instance_name_object.key_properties
()
이 메서드는 문자열 목록을 반환합니다.
예 22.30. 사용 가능한 키 속성 나열
예 22.27. “인스턴스 이름 액세스” 에서 생성된 device_name
인스턴스 이름 오브젝트를 검사하고 사용 가능한 모든 키 속성을 나열하려면 대화형 프롬프트에서 다음을 입력합니다.
> device_name.print_key_properties() CreationClassName SystemName Name SystemCreationClassName >
device_name_properties
라는 변수에 이러한 키 속성 목록을 할당하려면 다음을 입력합니다.
> device_name_properties = device_name.key_properties() >
특정 키 속성의 현재 값을 가져오려면 다음 구문을 사용합니다.
instance_name_object.key_property_name
key_property_name 을 액세스할 키 속성 이름으로 교체합니다.
예 22.31. 개별 키 속성 액세스
예 22.27. “인스턴스 이름 액세스” 에서 생성된 device_name
인스턴스 이름 오브젝트를 검사하고 SystemName
이라는 키 속성의 값을 표시하려면 대화형 프롬프트에서 다음을 입력합니다.
> device_name.SystemName u'server.example.com' >
인스턴스 이름을 인스턴스로 변환
각 인스턴스 이름은 인스턴스로 변환할 수 있습니다. 이렇게 하려면 다음과 같이 to_instance()
메서드를 사용합니다.
instance_name_object.to_instance
()
instance_name_object 를 변환할 인스턴스 이름 오브젝트의 이름으로 바꿉니다. 이 메서드는 LMIInstance
개체를 반환합니다.
예 22.32. 인스턴스 이름을 인스턴스로 변환
예 22.27. “인스턴스 이름 액세스” 에서 생성된 device_name
인스턴스 이름 오브젝트를 인스턴스 오브젝트로 변환하고 device
라는 변수에 할당하려면 대화형 프롬프트에서 다음을 입력합니다.
> device = device_name.to_instance() >
22.4.7. 관련 오브젝트 작업
공통 정보 모델은 관리되는 개체 간의 연관 관계를 정의합니다.
Associated Instances에 액세스
특정 인스턴스 개체와 연결된 모든 개체 목록을 가져오려면 다음과 같이 associators()
메서드를 사용합니다.
instance_object.associators
(
AssocClass=class_name,
ResultClass=class_name,
ResultRole=role,
IncludeQualifiers=include_qualifiers,
IncludeClassOrigin=include_class_origin,
PropertyList=property_list)
특정 인스턴스 오브젝트와 연결된 첫 번째 오브젝트에 액세스하려면 first_associator()
메서드를 사용합니다.
instance_object.first_associator
(
AssocClass=class_name,
ResultClass=class_name,
ResultRole=role,
IncludeQualifiers=include_qualifiers,
IncludeClassOrigin=include_class_origin,
PropertyList=property_list)
instance_object 를 검사할 인스턴스 오브젝트의 이름으로 교체합니다. 다음 매개변수를 지정하여 결과를 필터링할 수 있습니다.
-
AssocClass
- 반환된 각 오브젝트는 이 클래스의 인스턴스 또는 해당 하위 클래스 중 하나를 통해 소스 오브젝트와 연결되어야 합니다. 기본값은None
입니다. -
ResultClass
- 각각의 반환된 오브젝트는 이 클래스의 인스턴스이거나 하위 클래스 중 하나여야 합니다. 그렇지 않으면 이 클래스 또는 해당 하위 클래스 중 하나여야 합니다. 기본값은None
입니다. -
역할
- 반환된 각 오브젝트는 소스 오브젝트가 지정된 역할을 수행하는 연결을 통해 소스 오브젝트와 연결되어 있어야 합니다. 연결 클래스의 속성 이름은 소스 오브젝트를 참조하는 이 매개변수 값과 일치해야 합니다. 기본값은None
입니다. -
ResultRole
- 반환된 각 오브젝트는 반환된 오브젝트가 지정된 역할을 수행하는 연관을 통해 소스 오브젝트와 연결되어야 합니다. 반환된 오브젝트를 참조하는 연관 클래스의 속성 이름은 이 매개 변수의 값과 일치해야 합니다. 기본값은None
입니다.
나머지 매개변수는 다음을 참조합니다.
-
IncludeQualifiers
- 각 오브젝트의 모든 한정자(오브젝트 및 반환된 속성에 대한 포함)가 응답에서 QUALIFIER 요소로 포함되어야 하는지를 나타내는 부울입니다. 기본값은False
입니다. -
IncludeClassOrigin
- 반환된 각 개체의 모든 적절한 요소에 CLASSORIGIN 특성이 있는지 여부를 나타내는 부울입니다. 기본값은False
입니다. -
PropertyList
- 이 목록의 멤버는 하나 이상의 속성 이름을 정의합니다. 반환된 오브젝트에는 이 목록에서 누락된 속성에 대한 요소가 포함되지 않습니다.PropertyList
가 빈 목록이면 반환된 개체에 속성이 포함되지 않습니다.None
이면 추가 필터링이 정의되지 않습니다. 기본값은None
입니다.
예 22.33. Associated Instances에 액세스
LMI_StorageExtent
클래스는 시스템에서 사용 가능한 블록 장치를 나타냅니다. 예 22.5. “네임스페이스 오브젝트 액세스” 에 생성된 ns
네임스페이스 오브젝트를 사용하려면 /dev/
라는 블록 장치에 대한 vda
LMI_StorageExtent
클래스의 인스턴스를 생성하고 상호 작용 프롬프트에 다음을 입력합니다.
> vda = ns.LMI_StorageExtent.first_instance({ ... "DeviceID" : "/dev/vda"}) >
이 블록 장치의 모든 디스크 파티션 목록을 가져와 vda_partitions
라는 변수에 할당하려면 다음과 같이 associators()
메서드를 사용합니다.
> vda_partitions = vda.associators(ResultClass="LMI_DiskPartition") >
관련 인스턴스 이름 액세스
특정 인스턴스 오브젝트의 모든 연결된 인스턴스 이름 목록을 가져오려면 다음과 같이 associator_names()
메서드를 사용합니다.
instance_object.associator_names
(
AssocClass=class_name,
ResultClass=class_name,
Role=role,
ResultRole=role)
특정 인스턴스 오브젝트의 첫 번째 연결된 인스턴스 이름에 액세스하려면 first_associator_name()
메서드를 사용합니다.
instance_object.first_associator_name
(
AssocClass=class_object,
ResultClass=class_object,
Role=role,
ResultRole=role)
instance_object 를 검사할 인스턴스 오브젝트의 이름으로 교체합니다. 다음 매개변수를 지정하여 결과를 필터링할 수 있습니다.
-
AssocClass
- 반환된 각 이름은이 클래스의 인스턴스 또는 하위 클래스 중 하나를 통해 소스 개체와 연결되어야 하는 개체를 식별합니다.AssocClass - Each returned name identifies an object that must be associated with the source object through an instance of this class or one of its subclasses. 기본값은None
입니다. -
ResultClass
- 각 반환된 이름은 이 클래스의 인스턴스이거나 하위 클래스 중 하나여야 하는 개체를 식별하거나 이 클래스 또는 해당 하위 클래스 중 하나여야 합니다. 기본값은None
입니다. -
역할 - 반환된 각 이름은 소스 개체가 지정된 역할을 수행하는 연결을 통해 소스 개체와 연결되어야 하는 개체를 식별합니다.
Role
- Each returned name identifies an object that must be associated with the source object through an association in which the source object plays the specified role. 연결 클래스의 속성 이름은 소스 오브젝트를 참조하는 이 매개변수 값과 일치해야 합니다. 기본값은None
입니다. -
ResultRole
- 반환된 각 이름은 반환된 명명된 개체가 지정된 역할을 수행하는 연결을 통해 소스 오브젝트와 연결해야 하는 개체를 식별합니다. 반환된 오브젝트를 참조하는 연관 클래스의 속성 이름은 이 매개 변수의 값과 일치해야 합니다. 기본값은None
입니다.
예 22.34. 관련 인스턴스 이름 액세스
예 22.33. “Associated Instances에 액세스” 에서 생성된 vda
인스턴스 오브젝트를 사용하려면 연결된 인스턴스 이름 목록을 가져오고 vda_partitions
라는 변수에 할당합니다.
> vda_partitions = vda.associator_names(ResultClass="LMI_DiskPartition") >
22.4.8. associate 개체 작업
공통 정보 모델은 관리되는 개체 간의 연관 관계를 정의합니다. association 개체는 다른 두 개체 간의 관계를 정의합니다.
associate 인스턴스에 액세스
특정 대상 개체를 참조하는 연관 오브젝트 목록을 가져오려면 다음과 같이 references()
메서드를 사용합니다.
instance_object.references
(
ResultClass=class_name,
Role=role,
IncludeQualifiers=include_qualifiers,
IncludeClassOrigin=include_class_origin,
PropertyList=property_list)
특정 대상 오브젝트를 참조하는 첫 번째 연관 오브젝트에 액세스하려면 first_reference()
메서드를 사용합니다.
instance_object.first_reference
(
... ResultClass=class_name,
... Role=role,
... IncludeQualifiers=include_qualifiers,
... IncludeClassOrigin=include_class_origin,
... PropertyList=property_list)
>
instance_object 를 검사할 인스턴스 오브젝트의 이름으로 교체합니다. 다음 매개변수를 지정하여 결과를 필터링할 수 있습니다.
-
ResultClass
- 각각의 반환된 오브젝트는 이 클래스의 인스턴스이거나 하위 클래스 중 하나여야 합니다. 그렇지 않으면 이 클래스 또는 해당 하위 클래스 중 하나여야 합니다. 기본값은None
입니다. -
role
- 반환된 각 오브젝트는 이 매개변수의 값과 일치하는 이름이 있는 속성을 통해 대상 오브젝트를 참조해야 합니다. 기본값은None
입니다.
나머지 매개변수는 다음을 참조합니다.
-
IncludeQualifiers
- 각 오브젝트(오브젝트 및 반환된 속성에 대한 규정 준수 포함)가 응답에 QUALIFIER 요소로 포함되어야 하는지 여부를 나타내는 부울입니다. 기본값은False
입니다. -
IncludeClassOrigin
- 반환된 각 개체의 모든 적절한 요소에 CLASSORIGIN 특성이 있는지 여부를 나타내는 부울입니다. 기본값은False
입니다. -
PropertyList
- 이 목록의 멤버는 하나 이상의 속성 이름을 정의합니다. 반환된 오브젝트에는 이 목록에서 누락된 속성에 대한 요소가 포함되지 않습니다.PropertyList
가 빈 목록이면 반환된 개체에 속성이 포함되지 않습니다.None
이면 추가 필터링이 정의되지 않습니다. 기본값은None
입니다.
예 22.35. associate 인스턴스에 액세스
LMI_LANEndpoint
클래스는 특정 네트워크 인터페이스 장치와 연결된 통신 끝점을 나타냅니다. 예 22.5. “네임스페이스 오브젝트 액세스” 에서 생성된 ns
네임스페이스 오브젝트를 사용하려면 eth0이라는 네트워크 인터페이스 장치에 대한 LMI_LANEndpoint
클래스의 인스턴스를 만들고 이를 lan_endpoint
라는 변수에 할당하고 대화형 프롬프트에서 다음을 입력합니다.
> lan_endpoint = ns.LMI_LANEndpoint.first_instance({ ... "Name" : "eth0"}) >
LMI_BindsToLANEndpoint
개체를 참조하는 첫 번째 연결 개체에 액세스하여 bind
라는 변수에 할당하려면 다음을 입력합니다.
> bind = lan_endpoint.first_reference( ... ResultClass="LMI_BindsToLANEndpoint") >
이제 Dependent
속성을 사용하여 해당 네트워크 인터페이스 장치의 IP 주소를 나타내는 종속 LMI_IPProtocolEndpoint
클래스에 액세스할 수 있습니다.
> ip = bind.Dependent.to_instance() > print ip.IPv4Address 192.168.122.1 >
associate 인스턴스 이름 액세스
특정 인스턴스 개체의 연결 인스턴스 이름 목록을 가져오려면 다음과 같이 reference_names()
메서드를 사용합니다.
instance_object.reference_names
(
ResultClass=class_name,
Role=role)
특정 인스턴스 오브젝트의 첫 번째 연결 인스턴스 이름에 액세스하려면 first_reference_name()
메서드를 사용합니다.
instance_object.first_reference_name
(
ResultClass=class_name,
Role=role)
instance_object 를 검사할 인스턴스 오브젝트의 이름으로 교체합니다. 다음 매개변수를 지정하여 결과를 필터링할 수 있습니다.
-
ResultClass
- 반환된 각 개체 이름은 이 클래스의 인스턴스 또는 해당 하위 클래스 중 하나 또는 해당 하위 클래스 중 하나를 식별합니다. 기본값은None
입니다. -
role
- 반환된 각 오브젝트는 이 매개변수의 값과 일치하는 이름이 있는 속성을 통해 대상 인스턴스를 참조하는 오브젝트를 식별합니다. 기본값은None
입니다.
예 22.36. associate 인스턴스 이름 액세스
예 22.35. “associate 인스턴스에 액세스” 에 생성된 lan_endpoint
인스턴스 개체를 사용하려면 LMI_BindsToLANEndpoint
오브젝트를 참조하는 첫 번째 연결 인스턴스 이름에 액세스하여 bind
라는 변수에 할당합니다.
> bind = lan_endpoint.first_reference_name( ... ResultClass="LMI_BindsToLANEndpoint")
이제 Dependent
속성을 사용하여 해당 네트워크 인터페이스 장치의 IP 주소를 나타내는 종속 LMI_IPProtocolEndpoint
클래스에 액세스할 수 있습니다.
> ip = bind.Dependent.to_instance() > print ip.IPv4Address 192.168.122.1 >
22.4.9. 인디케이션 작업
표시는 데이터의 특정 변경에 대한 응답으로 발생하는 특정 이벤트에 대한 반응입니다. LMIShell은 이러한 이벤트 응답을 수신하기 위해 표시를 구독할 수 있습니다.
구독 취소
표시를 구독하려면 다음과 같이 subscribe_indication()
메서드를 사용합니다.
connection_object.subscribe_indication
( QueryLanguage="WQL"
, Query='SELECT * FROM CIM_InstModification'
, Name="cpu"
, CreationNamespace="root/interop"
, SubscriptionCreationClassName="CIM_IndicationSubscription"
, FilterCreationClassName="CIM_IndicationFilter"
, FilterSystemCreationClassName="CIM_ComputerSystem"
, FilterSourceNamespace="root/cimv2"
, HandlerCreationClassName="CIM_IndicationHandlerCIMXML"
, HandlerSystemCreationClassName="CIM_ComputerSystem"
, Destination="http://host_name:5988"
)
또는 다음과 같이 더 짧은 버전의 메서드 호출을 사용할 수 있습니다.
connection_object.subscribe_indication
( Query='SELECT * FROM CIM_InstModification'
, Name="cpu"
, Destination="http://host_name:5988"
)
connection_object 를 연결 오브젝트로 바꾸고 host_name 을 표시를 전달하려는 시스템의 호스트 이름으로 바꿉니다.
기본적으로 LMIShell 인터프리터에서 생성한 모든 서브스크립션은 인터프리터가 종료될 때 자동으로 삭제됩니다. 이 동작을 변경하려면 Permanent=True
키워드 매개변수를 subscribe_indication()
메서드 호출에 전달합니다. 이렇게 하면 LMIShell에서 서브스크립션을 삭제하지 못합니다.
예 22.37. 구독 취소
예 22.1. “원격 CIMOM에 연결” 에서 생성된 c
연결 오브젝트를 사용하고 cpu
라는 표시를 구독하려면 대화형 프롬프트에서 다음을 입력합니다.
> c.subscribe_indication( ... QueryLanguage="WQL", ... Query='SELECT * FROM CIM_InstModification', ... Name="cpu", ... CreationNamespace="root/interop", ... SubscriptionCreationClassName="CIM_IndicationSubscription", ... FilterCreationClassName="CIM_IndicationFilter", ... FilterSystemCreationClassName="CIM_ComputerSystem", ... FilterSourceNamespace="root/cimv2", ... HandlerCreationClassName="CIM_IndicationHandlerCIMXML", ... HandlerSystemCreationClassName="CIM_ComputerSystem", ... Destination="http://server.example.com:5988") LMIReturnValue(rval=True, rparams=NocaseDict({}), errorstr='') >
구독 취소 나열
구독한 표시를 모두 나열하려면 다음과 같이 print_subscribed_indications()
메서드를 사용합니다.
connection_object.print_subscribed_indications
()
connection_object 를 검사할 연결 오브젝트의 이름으로 바꿉니다. 이 메서드는 서브스크립션된 표시를 표준 출력에 출력합니다.
구독한 표시 목록을 가져오려면 subscribed_indications()
메서드를 사용합니다.
connection_object.subscribed_indications
()
이 메서드는 문자열 목록을 반환합니다.
예 22.38. 구독 취소 나열
예 22.1. “원격 CIMOM에 연결” 에서 생성된 c
연결 오브젝트를 검사하고 모든 구독 표시를 나열하려면 대화형 프롬프트에서 다음을 입력합니다.
> c.print_subscribed_indications() >
표시라는 변수에 이러한 표시 목록을 할당하려면 다음을 입력합니다.
> indications = c.subscribed_indications() >
Indications에서 구독 해제
기본적으로 LMIShell 인터프리터에서 생성한 모든 서브스크립션은 인터프리터가 종료될 때 자동으로 삭제됩니다. 개별 서브스크립션을 더 빨리 삭제하려면 subscription _indication()
방법을 다음과 같이 사용하십시오.
connection_object.unsubscribe_indication
(indication_name)
connection_object 를 연결 개체의 이름으로 바꾸고 indication_name 을 삭제할 표시의 이름으로 바꿉니다.
모든 서브스크립션을 삭제하려면subscription _all_indications()
방법을 사용하십시오.
connection_object.unsubscribe_all_indications
()
예 22.39. Indications에서 구독 해제
예 22.1. “원격 CIMOM에 연결” 에서 생성된 c
연결 오브젝트를 사용하고 예 22.37. “구독 취소” 에서 생성된 표시를 구독 취소하려면 대화형 프롬프트에서 다음을 입력합니다.
> c.unsubscribe_indication('cpu') LMIReturnValue(rval=True, rparams=NocaseDict({}), errorstr='') >
Indication Handler 구현
subscribe_indication()
메서드를 사용하면 표시를 전달할 시스템의 호스트 이름을 지정할 수 있습니다. 다음 예제에서는 표시 처리기를 구현하는 방법을 보여줍니다.
> def handler(ind, arg1, arg2, kwargs): ... exported_objects = ind.exported_objects() ... do_something_with(exported_objects) > listener = LmiIndicationListener("0.0.0.0", listening_port) > listener.add_handler("indication-name-XXXXXXXX", handler, arg1, arg2, kwargs)
> listener.start()
>
처리기의 첫 번째 인수는 표시로 내보낸 메서드 및 오브젝트 목록을 포함하는 LmiIndication
오브젝트입니다. 다른 매개 변수는 사용자별입니다. 이러한 인수는 리스너에 처리기를 추가할 때 지정해야 합니다.
위의 예에서 add_handler()
메서드 호출은 8개의 "X" 문자가 있는 특수 문자열을 사용합니다. 이러한 문자는 가능한 처리기 이름 충돌을 피하기 위해 리스너에 의해 생성되는 임의의 문자열로 교체됩니다. 임의의 문자열을 사용하려면 표시 리스너를 먼저 시작한 다음 처리기 오브젝트의 Destination
속성에 schema://host_name/random_string
값이 포함되도록 표시를 구독하십시오.
예 22.40. Indication Handler 구현
다음 스크립트는 192.168.122.1
에 있는 관리 시스템을 모니터링하는 핸들러를 작성하고 새 사용자 계정이 생성될 때마다 indication_callback()
함수를 호출하는 방법을 보여줍니다.
#!/usr/bin/lmishell import sys from time import sleep from lmi.shell.LMIUtil import LMIPassByRef from lmi.shell.LMIIndicationListener import LMIIndicationListener # These are passed by reference to indication_callback var1 = LMIPassByRef("some_value") var2 = LMIPassByRef("some_other_value") def indication_callback(ind, var1, var2): # Do something with ind, var1 and var2 print ind.exported_objects() print var1.value print var2.value c = connect("hostname", "username", "password") listener = LMIIndicationListener("0.0.0.0", 65500) unique_name = listener.add_handler( "demo-XXXXXXXX", # Creates a unique name for me indication_callback, # Callback to be called var1, # Variable passed by ref var2 # Variable passed by ref ) listener.start() print c.subscribe_indication( Name=unique_name, Query="SELECT * FROM LMI_AccountInstanceCreationIndication WHERE SOURCEINSTANCE ISA LMI_Account", Destination="192.168.122.1:65500" ) try: while True: sleep(60) except KeyboardInterrupt: sys.exit(0)
22.4.10. 사용 예
이 섹션에서는 OpenLMI 패키지와 함께 배포되는 다양한 CIM 공급자에 대한 여러 예제를 제공합니다. 이 섹션의 모든 예제에서는 다음 두 변수 정의를 사용합니다.
c = connect("host_name", "user_name", "password") ns = c.root.cimv2
host_name 을 관리 시스템의 호스트 이름으로 바꾸고 user_name 을 시스템에서 실행되는 OpenPegasus CIMOM에 연결할 수 있는 사용자 이름으로, 암호를 사용자의 암호로 바꿉니다.
OpenLMI 서비스 공급자 사용
openlmi-service 패키지는 시스템 서비스를 관리하기 위해 CIM 공급자를 설치합니다. 아래 예제에서는 이 CIM 공급자를 사용하여 사용 가능한 시스템 서비스를 나열하는 방법과 시작, 중지, 활성화 및 비활성화 방법을 보여줍니다.
예 22.41. 사용 가능한 서비스 나열
서비스가 시작(TRUE
) 또는 중지되었는지(false ) 및 상태 문자열과 함께 관리 머신에서 사용 가능한 모든 서비스를 나열하려면 다음 코드 스니펫을 사용합니다.
for service in ns.LMI_Service.instances(): print "%s:\t%s" % (service.Name, service.Status)
기본적으로 활성화된 서비스만 나열하려면 다음 코드 조각을 사용합니다.
cls = ns.LMI_Service for service in cls.instances(): if service.EnabledDefault == cls.EnabledDefaultValues.Enabled: print service.Name
EnabledDefault
속성 값은 활성화된 서비스의 경우 2
와 동일하며 비활성화된 서비스의 경우 3
입니다.
cups
서비스에 대한 정보를 표시하려면 다음을 사용하십시오.
cups = ns.LMI_Service.first_instance({"Name": "cups.service"}) cups.doc()
예 22.42. 서비스 시작 및 중지
cups
서비스를 시작하고 중지하고 현재 상태를 확인하려면 다음 코드 조각을 사용하십시오.
cups = ns.LMI_Service.first_instance({"Name": "cups.service"}) cups.StartService() print cups.Status cups.StopService() print cups.Status
예 22.43. 서비스 활성화 및 비활성화
cups
서비스를 활성화 및 비활성화하고 EnabledDefault
속성을 표시하려면 다음 코드 조각을 사용합니다.
cups = ns.LMI_Service.first_instance({"Name": "cups.service"}) cups.TurnServiceOff() print cups.EnabledDefault cups.TurnServiceOn() print cups.EnabledDefault
OpenLMI 네트워킹 공급자 사용
openlmi-networking 패키지에서 네트워킹을 위한 CIM 공급자를 설치합니다. 아래 예제에서는 이 CIM 공급자를 사용하여 특정 포트 번호와 연결된 IP 주소를 나열하고, 새 연결을 생성하고, 고정 IP 주소를 구성하고, 연결을 활성화하는 방법을 보여줍니다.
예 22.44. 기타 포트 번호와 연결된 IP 주소 나열
eth0 네트워크 인터페이스와 연결된 모든 IP 주소를 나열하려면 다음 코드 스니펫을 사용합니다.
device = ns.LMI_IPNetworkConnection.first_instance({'ElementName': 'eth0'}) for endpoint in device.associators(AssocClass="LMI_NetworkSAPSAPDependency", ResultClass="LMI_IPProtocolEndpoint"): if endpoint.ProtocolIFType == ns.LMI_IPProtocolEndpoint.ProtocolIFTypeValues.IPv4: print "IPv4: %s/%s" % (endpoint.IPv4Address, endpoint.SubnetMask) elif endpoint.ProtocolIFType == ns.LMI_IPProtocolEndpoint.ProtocolIFTypeValues.IPv6: print "IPv6: %s/%d" % (endpoint.IPv6Address, endpoint.IPv6SubnetPrefixLength)
이 코드 스니펫은 지정된 LMI_IPI_IP NetworkConnection 클래스와 연결된
클래스를 사용합니다.
LMI_IP
ProtocolEndpoint
기본 게이트웨이를 표시하려면 다음 코드 조각을 사용합니다.
for rsap in device.associators(AssocClass="LMI_NetworkRemoteAccessAvailableToElement", ResultClass="LMI_NetworkRemoteServiceAccessPoint"): if rsap.AccessContext == ns.LMI_NetworkRemoteServiceAccessPoint.AccessContextValues.DefaultGateway: print "Default Gateway: %s" % rsap.AccessInfo
기본 게이트웨이는 AccessContext
속성이 DefaultGateway
인 LMI_NetworkRemoteServiceAccessPoint
인스턴스로 표시됩니다.
DNS 서버 목록을 가져오려면 다음과 같이 오브젝트 모델을 통과해야 합니다.
-
LMI_NetworkSAPSAPDependency
를 사용하여 지정된LMI_IPNetworkConnection
과 연결된LMI_IPProtocolEndpoint
인스턴스를 가져옵니다. -
LMI_DNSProtocolEndpoint
인스턴스에 대해 동일한 연결을 사용합니다.
LMI_NetworkRemoteServiceAccessPoint
인스턴스는 LMI_NetworkRemoteAccessAvailableTo
RegistryLogin을 통해 연결된 DNS 서버와 동일한 AccessContext
속성을 사용하여 AccessInfo
속성에 DNS 서버 주소를 갖습니다.
RemoteServiceAccessPath
및 항목을 복제할 수 있는 경로가 더 있을 수 있습니다. 다음 코드 스니펫에서는 set()
함수를 사용하여 DNS 서버 목록에서 중복 항목을 제거합니다.
dnsservers = set() for ipendpoint in device.associators(AssocClass="LMI_NetworkSAPSAPDependency", ResultClass="LMI_IPProtocolEndpoint"): for dnsedpoint in ipendpoint.associators(AssocClass="LMI_NetworkSAPSAPDependency", ResultClass="LMI_DNSProtocolEndpoint"): for rsap in dnsedpoint.associators(AssocClass="LMI_NetworkRemoteAccessAvailableToElement", ResultClass="LMI_NetworkRemoteServiceAccessPoint"): if rsap.AccessContext == ns.LMI_NetworkRemoteServiceAccessPoint.AccessContextValues.DNSServer: dnsservers.add(rsap.AccessInfo) print "DNS:", ", ".join(dnsservers)
예 22.45. 새 연결 생성 및 정적 IP 주소 구성
네트워크 인터페이스 eth0에 대한 정적 IPv4 및 stateless IPv6 구성을 사용하여 새 설정을 생성하려면 다음 코드 스니펫을 사용하십시오.
capability = ns.LMI_IPNetworkConnectionCapabilities.first_instance({ 'ElementName': 'eth0' }) result = capability.LMI_CreateIPSetting(Caption='eth0 Static', IPv4Type=capability.LMI_CreateIPSetting.IPv4TypeValues.Static, IPv6Type=capability.LMI_CreateIPSetting.IPv6TypeValues.Stateless) setting = result.rparams["SettingData"].to_instance() for settingData in setting.associators(AssocClass="LMI_OrderedIPAssignmentComponent"): if setting.ProtocolIFType == ns.LMI_IPAssignmentSettingData.ProtocolIFTypeValues.IPv4: # Set static IPv4 address settingData.IPAddresses = ["192.168.1.100"] settingData.SubnetMasks = ["255.255.0.0"] settingData.GatewayAddresses = ["192.168.1.1"] settingData.push()
이 코드 스니펫은 LMI_IPNetworkConnection
Capabilities .LMI_IPNetworkConnectionCapabilities 를 통해 LMI_IPNetworkConnectionCapabilities
.NET Framework 인스턴스에
메서드를 호출하여 새 설정을 생성합니다. 또한 LMI_CreateIP
Setting()push()
메서드를 사용하여 설정을 수정합니다.
예 22.46. 연결 활성화
네트워크 인터페이스에 설정을 적용하려면 LMI_IPConfigurationService
클래스의 ApplySettingToIPNetworkConnection()
메서드를 호출합니다. 이 메서드는 비동기적이며 작업을 반환합니다. 다음 코드 조각에서는 이 메서드를 동기적으로 호출하는 방법을 보여줍니다.
setting = ns.LMI_IPAssignmentSettingData.first_instance({ "Caption": "eth0 Static" }) port = ns.LMI_IPNetworkConnection.first_instance({ 'ElementName': 'ens8' }) service = ns.LMI_IPConfigurationService.first_instance() service.SyncApplySettingToIPNetworkConnection(SettingData=setting, IPNetworkConnection=port, Mode=32768)
Mode
매개변수는 설정이 적용되는 방법에 영향을 미칩니다. 이 매개변수의 가장 일반적으로 사용되는 값은 다음과 같습니다.
-
1
- 지금 설정을 적용하고 자동으로 활성화되도록 설정합니다. -
2
- 자동 활성화되도록 설정하고 지금 적용하지 마십시오. -
4
- 자동 활성화의 연결을 해제하고 비활성화합니다. -
5
- 설정 상태를 변경하지 말고 자동 활성화만 비활성화합니다. -
32768
- 설정을 적용합니다. -
32769
- 연결 끊기
OpenLMI 스토리지 공급자 사용
openlmi-storage 패키지는 스토리지 관리를 위해 CIM 공급자를 설치합니다. 아래 예제에서는 이 CIM 공급자를 사용하여 볼륨 그룹을 생성하고, 논리 볼륨을 생성하고, 파일 시스템을 빌드하며, 파일 시스템을 마운트하며, 시스템에 알려진 블록 장치를 나열하는 방법을 보여줍니다.
c
및 ns
변수 외에도 다음 예제에는 다음 변수 정의를 사용합니다.
MEGABYTE = 1024*1024 storage_service = ns.LMI_StorageConfigurationService.first_instance() filesystem_service = ns.LMI_FileSystemConfigurationService.first_instance()
예 22.47. 볼륨 그룹 생성
/dev/myGroup/
에 있는 새 볼륨 그룹을 만들려면 3개의 멤버와 기본 확장 영역 크기가 4MB인 경우 다음 코드 조각을 사용하십시오.
# Find the devices to add to the volume group # (filtering the CIM_StorageExtent.instances() # call would be faster, but this is easier to read): sda1 = ns.CIM_StorageExtent.first_instance({"Name": "/dev/sda1"}) sdb1 = ns.CIM_StorageExtent.first_instance({"Name": "/dev/sdb1"}) sdc1 = ns.CIM_StorageExtent.first_instance({"Name": "/dev/sdc1"}) # Create a new volume group: (ret, outparams, err) = storage_service.SyncCreateOrModifyVG( ElementName="myGroup", InExtents=[sda1, sdb1, sdc1]) vg = outparams['Pool'].to_instance() print "VG", vg.PoolID, \ "with extent size", vg.ExtentSize, \ "and", vg.RemainingExtents, "free extents created."
예 22.48. 논리 볼륨 생성
크기가 100MB인 두 개의 논리 볼륨을 생성하려면 다음 코드 스니펫을 사용하십시오.
# Find the volume group: vg = ns.LMI_VGStoragePool.first_instance({"Name": "/dev/mapper/myGroup"}) # Create the first logical volume: (ret, outparams, err) = storage_service.SyncCreateOrModifyLV( ElementName="Vol1", InPool=vg, Size=100 * MEGABYTE) lv = outparams['TheElement'].to_instance() print "LV", lv.DeviceID, \ "with", lv.BlockSize * lv.NumberOfBlocks,\ "bytes created." # Create the second logical volume: (ret, outparams, err) = storage_service.SyncCreateOrModifyLV( ElementName="Vol2", InPool=vg, Size=100 * MEGABYTE) lv = outparams['TheElement'].to_instance() print "LV", lv.DeviceID, \ "with", lv.BlockSize * lv.NumberOfBlocks, \ "bytes created."
예 22.49. 파일 시스템 생성
예 22.48. “논리 볼륨 생성” 의 논리 볼륨 lv
에 ext3
파일 시스템을 생성하려면 다음 코드 조각을 사용하십시오.
(ret, outparams, err) = filesystem_service.SyncLMI_CreateFileSystem( FileSystemType=filesystem_service.LMI_CreateFileSystem.FileSystemTypeValues.EXT3, InExtents=[lv])
예 22.50. 파일 시스템 마운트
예 22.49. “파일 시스템 생성” 에 생성된 파일 시스템을 마운트하려면 다음 코드 조각을 사용합니다.
# Find the file system on the logical volume: fs = lv.first_associator(ResultClass="LMI_LocalFileSystem") mount_service = ns.LMI_MountConfigurationService.first_instance() (rc, out, err) = mount_service.SyncCreateMount( FileSystemType='ext3', Mode=32768, # just mount FileSystem=fs, MountPoint='/mnt/test', FileSystemSpec=lv.Name)
예 22.51. 블록 장치 나열
시스템에 알려진 모든 블록 장치를 나열하려면 다음 코드 스니펫을 사용하십시오.
devices = ns.CIM_StorageExtent.instances() for device in devices: if lmi_isinstance(device, ns.CIM_Memory): # Memory and CPU caches are StorageExtents too, do not print them continue print device.classname, print device.DeviceID, print device.Name, print device.BlockSize*device.NumberOfBlocks
OpenLMI 하드웨어 공급자 사용
openlmi-hardware 패키지는 하드웨어 모니터링을 위해 CIM 공급자를 설치합니다. 아래 예제에서는 이 CIM 공급자를 사용하여 시스템의 CPU, 메모리 모듈, PCI 장치 및 제조업체 및 모델에 대한 정보를 검색하는 방법을 보여줍니다.
예 22.52. CPU 정보 보기
CPU 이름, 프로세서 코어 수 및 하드웨어 스레드 수와 같은 기본 CPU 정보를 표시하려면 다음 코드 스니펫을 사용합니다.
cpu = ns.LMI_Processor.first_instance() cpu_cap = cpu.associators(ResultClass="LMI_ProcessorCapabilities")[0] print cpu.Name print cpu_cap.NumberOfProcessorCores print cpu_cap.NumberOfHardwareThreads
예 22.53. 메모리 정보 보기
개별 크기와 같은 메모리 모듈에 대한 기본 정보를 표시하려면 다음 코드 조각을 사용합니다.
mem = ns.LMI_Memory.first_instance() for i in mem.associators(ResultClass="LMI_PhysicalMemory"): print i.Name
예 22.54. Chassis 정보 보기
제조업체 또는 해당 모델과 같은 머신에 대한 기본 정보를 표시하려면 다음 코드 조각을 사용합니다.
chassis = ns.LMI_Chassis.first_instance() print chassis.Manufacturer print chassis.Model
예 22.55. PCI 장치 나열
시스템에 알려진 모든 PCI 장치를 나열하려면 다음 코드 스니펫을 사용하십시오.
for pci in ns.LMI_PCIDevice.instances(): print pci.Name
22.5. OpenLMI 스크립트 사용
LMIShell 인터프리터는 사용자 지정 관리 툴을 개발하는 데 사용할 수 있는 Python 모듈 위에 빌드됩니다. OpenLMI Scripts 프로젝트는 OpenLMI 공급자와 함께 사용할 수 있는 여러 Python 라이브러리를 제공합니다. 또한 명령줄에서 이러한 라이브러리와 상호 작용하는 데 사용할 수 있는 확장 가능한 유틸리티인 lmi
와 함께 배포됩니다.
시스템에 OpenLMI 스크립트를 설치하려면 쉘 프롬프트에서 다음을 입력합니다.
easy_install --user openlmi-scripts
이 명령은 Python 모듈과 lmi
유틸리티를 ~/.local/
디렉터리에 설치합니다. lmi
유틸리티의 기능을 확장하려면 다음 명령을 사용하여 추가 OpenLMI 모듈을 설치합니다.
easy_install --user package_name
사용 가능한 모듈의 전체 목록은 Python 웹 사이트를 참조하십시오. OpenLMI 스크립트에 대한 자세한 내용은 OpenLMI Scripts 공식 문서를 참조하십시오.
22.6. 추가 리소스
일반적으로 OpenLMI 및 시스템 관리에 대한 자세한 내용은 아래 나열된 리소스를 참조하십시오.
설치된 문서
-
lmishell(1) -
lmishell
클라이언트 및 인터프리터의 설명서 페이지는 실행 및 사용에 대한 자세한 정보를 제공합니다.
온라인 문서
- Red Hat Enterprise Linux 7 네트워킹 가이드 - Red Hat Enterprise Linux 7의 네트워킹 가이드, 시스템의 네트워크 인터페이스 및 네트워크 서비스의 구성 및 관리와 관련된 관련 정보입니다.
- Red Hat Enterprise Linux 7 스토리지 관리 가이드 - Red Hat Enterprise Linux 7용 스토리지 관리 가이드는 시스템의 스토리지 장치 및 파일 시스템을 관리하는 방법에 대한 지침을 제공합니다.
- Red Hat Enterprise Linux 7 Power Management Guide - Red Hat Enterprise Linux 7용 Power Management Guide 는 시스템의 전력 소비를 효과적으로 관리하는 방법을 설명합니다. 또한 서버와 랩탑 모두에 대해 전력 소비를 줄이는 다양한 기술을 설명하고 각 기술이 시스템의 전반적인 성능에 어떤 영향을 미치는지 설명합니다.
- Red Hat Enterprise Linux 7 Linux 도메인 ID, 인증 및 정책 가이드 - Red Hat Enterprise Linux 7의 Linux 도메인 ID, 인증 및 정책 안내서는 서버와 클라이언트 모두를 포함하여 IPA 도메인을 설치, 구성 및 관리하는 모든 측면을 다룹니다. 이 가이드는 IT 및 시스템 관리자를 위한 것입니다.
- FreeIPA 문서 - FreeIPA 문서는 FreeIPA Identity Management 프로젝트 사용에 대한 기본 사용자 설명서 역할을 합니다.
- OpenSSL 홈 페이지 - OpenSSL 홈 페이지는 OpenSSL 프로젝트에 대한 개요를 제공합니다.
- Mozilla NSS 문서 - Mozilla NSS 문서는 Mozilla NSS 프로젝트 사용에 대한 기본 사용자 설명서 역할을 합니다.
예를 들면 다음과 같습니다.
- 4장. 사용자 및 그룹 관리 그래픽 사용자 인터페이스 및 명령줄에서 시스템 사용자 및 그룹을 관리하는 방법을 설명합니다.
- 9장. yum YUM 패키지 관리자를 사용하여 명령줄에서 패키지를 검색, 설치, 업데이트 및 제거하는 방법을 설명합니다.
-
10장. systemd를 사용하여 서비스 관리
systemctl
명령을 사용하여 시스템 서비스를 관리하고,systemd
대상을 구성하고, 전원 관리 명령을 실행하는 방법을 systemd 및 문서에 대해 소개합니다. -
12장. OpenSSH SSH 서버 및
ssh
,scp
,sftp
클라이언트 유틸리티를 사용하여 액세스하는 방법에 대해 설명합니다.
23장. 로그 파일 보기 및 관리
로그 파일은 커널, 서비스 및 커널에서 실행되는 애플리케이션을 포함하여 시스템에 대한 메시지가 포함된 파일입니다. 다양한 정보를 위한 다양한 로그 파일이 있습니다. 예를 들어 기본 시스템 로그 파일, 보안 메시지의 로그 파일, cron 작업의 로그 파일이 있습니다.
로그 파일은 커널 드라이버를 로드하려고 하거나 시스템에 대한 무단 로그인 시도를 찾는 것과 같은 시스템 문제를 해결할 때 매우 유용할 수 있습니다. 이 장에서는 로그 파일을 찾을 위치, 로그 파일을 보는 방법 및 로그 파일에서 찾아야 할 사항에 대해 설명합니다.
일부 로그 파일은 rsyslogd
라는 데몬에 의해 제어됩니다. rsyslogd
데몬은 sysklogd 를 위한 향상된 대체이며 확장된 필터링, 메시지 암호화 보호 릴레이, 다양한 구성 옵션, 입력 및 출력 모듈, TCP
또는 UDP
프로토콜을 통한 전송 지원 기능을 제공합니다. rsyslog 는 sysklogd 와 호환됩니다.
systemd
의 구성 요소인 journald
데몬에서 로그 파일을 관리할 수도 있습니다. journald
데몬은 Syslog 메시지, 커널 로그 메시지, 초기 RAM 디스크 및 초기 부팅 메시지를 캡처하고 모든 서비스의 표준 출력 및 표준 오류 출력에 기록된 메시지와 모든 서비스의 표준 오류 출력을 캡처하고 이를 사용자에게 제공합니다. 구조화되고 인덱싱된 바이너리 파일 형식인 네이티브 저널 파일 형식은 검색을 개선하고 더 빠른 작업을 제공하며, 타임스탬프 또는 사용자 ID와 같은 메타 데이터 정보도 저장합니다. journald
에서 생성된 로그 파일은 기본적으로 지속되지 않으며 로그 파일은 메모리 또는 /run/log/journal/
디렉터리에만 저장됩니다. 기록된 데이터의 양은 용량 제한에 도달하면 가장 오래된 항목이 삭제됩니다. 그러나 이 설정은 변경될 수 있습니다. 23.10.5절. “영구 스토리지 활성화” 를 참조하십시오. journal에 대한 자세한 내용은 23.10절. “저널 사용” 을 참조하십시오.
기본적으로 이 두 가지 로깅 툴은 시스템에 공존합니다. journald
데몬은 문제 해결을 위한 기본 툴입니다. 구조화된 로그 메시지를 생성하는 데 필요한 추가 데이터도 제공합니다. journald
에서 수집한 데이터는 데이터를 추가로 처리하기 위해 rsyslogd
에서 사용할 수 있는 /run/systemd/journal/syslog
소켓으로 전달됩니다. 그러나 rsyslog 는 imjournal
입력 모듈을 통해 기본적으로 실제 통합을 수행하므로 앞서 언급한 소켓을 피할 수 있습니다. 또한 omjournal
모듈을 사용하여 rsyslogd
에서 journald
로 데이터를 이전할 수도 있습니다. 자세한 내용은 23.7절. “Rsyslog 및 journal의 상호 작용” 을 참조하십시오. 이러한 통합을 통해 텍스트 기반 로그를 일관된 형식으로 유지 관리하여 rsyslogd
에 따라 가능한 애플리케이션 또는 구성과의 호환성을 보장할 수 있습니다. 또한 구조화된 형식으로 rsyslog 메시지를 유지 관리할 수 있습니다( 23.8절. “Rsyslog를 사용한 구조화된 로깅”참조).
23.1. 로그 파일 찾기
rsyslogd
에서 유지 관리하는 로그 파일 목록은 /etc/journal.conf
구성 파일에서 확인할 수 있습니다. 대부분의 로그 파일은 /var/log/
디렉토리에 있습니다. httpd
및 samba
와 같은 일부 애플리케이션에는 로그 파일의 /var/log/
내에 디렉터리가 있습니다.
/var/log/
디렉터리에 번호가 번호가 지정된 여러 파일(예: cron-20100906
)을 확인할 수 있습니다. 이 숫자는 순환된 로그 파일에 추가된 타임스탬프를 나타냅니다. 로그 파일이 순환되므로 파일 크기가 너무 크지 않습니다. logrotate
패키지에는 /etc/logrotate.conf
구성 파일과 /etc/logrotate.d/
디렉터리에 있는 구성 파일에 따라 로그 파일을 자동으로 순환하는 cron 작업이 포함되어 있습니다.
23.2. Rsyslog의 기본 구성
rsyslog 의 기본 설정 파일은 /etc/journal.conf
입니다. 여기서는 필터 및 동작 부분으로 구성된 글로벌 지시문,모듈 및 규칙을 지정할 수 있습니다. 또한 해시 기호(#
)에 따라 텍스트 형태로 주석을 추가할 수 있습니다.
23.2.1. filters
규칙은 syslog 메시지의 하위 집합을 선택하는 필터 부분과 선택한 메시지로 수행할 작업을 지정하는 작업 부분에 의해 지정됩니다. /etc/journal.conf
구성 파일에 규칙을 정의하려면 한 줄에서 필터 및 작업을 모두 정의하고 하나 이상의 공백 또는 탭으로 구분합니다.
rsyslog 는 선택한 속성에 따라 syslog 메시지를 필터링하는 다양한 방법을 제공합니다. 사용 가능한 필터링 방법은 facilities /Priority-based ,Property-based , Expression 기반 필터로 나눌 수 있습니다.
- 기능/우선 순위 기반 필터
syslog 메시지를 필터링하는 데 가장 많이 사용되고 잘 알려진 방법은 두 조건에 따라 syslog 메시지를 필터링하는 기능/우선 기반 필터를 사용하는 것입니다. 기능 및 우선순위는 점으로 구분되어 있습니다. 선택기를 생성하려면 다음 구문을 사용합니다.
FACILITY.PRIORITY
다음과 같습니다.
-
FACILITY 는 특정 syslog 메시지를 생성하는 하위 시스템을 지정합니다. 예를 들어
메일
하위 시스템은 모든 메일 관련 syslog 메시지를 처리합니다. FACILITY 는 다음 키워드(또는 숫자 코드) 중 하나로 나타낼 수 있습니다. Kern (0),user
(1),mail
(2),daemon
(3),auth
(4),syslog
(5),lpr
(6),news
(7),cron
(8),authpriv
(9)(10),local0
에서local7
(16 - 23)을 통해 local0. PRIORITY 는 syslog 메시지의 우선 순위를 지정합니다. PRIORITY 는 다음 키워드(또는 숫자) 중 하나로 나타낼 수 있습니다.
debug
(7),info
(6),notice
(5),warning
(4),err
(3),crit
(2),alert
(1) 및emerg
(0)앞에서 설명한 구문은 정의된 우선 순위가 높은 syslog 메시지를 선택합니다. 등호(
=
)가 있는 priority 키워드를 선행하여 지정된 우선순위가 있는 syslog 메시지만 선택하도록 지정합니다. 다른 모든 우선순위는 무시됩니다. 반대로 느낌표(!
!)가 있는 우선순위 키워드 앞의 명령은 우선 순위가 정의된 syslog 메시지를 제외한 모든 syslog 메시지를 선택합니다.위에 명시된 키워드 외에 별표(*)를 사용하여 모든 기능 또는 우선 순위를 정의할 수도 있습니다(보장 전 또는 쉼표 뒤에 있는 위치에 따라 다름).
priority 키워드를 지정하면 우선순위가 없는 기능에는 적용되지 않습니다.
기능 및 우선 순위 조건은 모두 대소문자를 구분하지 않습니다.
여러 기능과 우선 순위를 정의하려면 쉼표(
,
)로 구분합니다. 한 줄에 여러 개의 선택기를 정의하려면 Semi-colon(;)과 분리합니다
. selector 필드의 각 선택기는 이전 항목을 덮어쓸 수 있으며, 이는 패턴에서 일부 우선순위를 제외할 수 있습니다.예 23.1. 기능/우선 순위 기반 필터
다음은
/etc/journal.conf에 지정할 수 있는 간단한 기능/우선 기반 필터의 몇 가지 예입니다.
우선 순위가 있는 커널 syslog 메시지를 모두 선택하려면 구성 파일에 다음 텍스트를 추가합니다.kern.*
우선 순위
crit
이상에서 모든 메일 syslog 메시지를 선택하려면 다음 양식을 사용하십시오.mail.crit
info
또는debug
우선 순위가 있는 메시지를 제외한 모든 cron syslog 메시지를 선택하려면 다음 형식으로 구성을 설정합니다.cron.!info,!debug
-
FACILITY 는 특정 syslog 메시지를 생성하는 하위 시스템을 지정합니다. 예를 들어
- 속성 기반 필터
속성 기반 필터를 사용하면
시간 생성
또는 syslog 태그와 같은 속성으로syslog 메시지를 필터링할 수 있습니다
. 속성에 대한 자세한 내용은 “속성” 을 참조하십시오. 지정된 각 속성을 표 23.1. “속성 기반 비교 작업” 에 나열된 compare-operations 중 하나를 사용하여 특정 값과 비교할 수 있습니다. 속성 이름과 비교 작업은 모두 대소문자를 구분합니다.속성 기반 필터는 콜론(
:
)으로 시작해야 합니다. 필터를 정의하려면 다음 구문을 사용합니다.:PROPERTY, [!]COMPARE_OPERATION, "STRING"
다음과 같습니다.
- PROPERTY 속성은 원하는 속성을 지정합니다.
-
선택적 느낌표(!
!)
는 compare-operation의 출력을 부정합니다. 다른 부울 연산자는 현재 속성 기반 필터에서 지원되지 않습니다. - COMPARE_OPERATION 속성은 표 23.1. “속성 기반 비교 작업” 에 나열된 비교 작업 중 하나를 지정합니다.
STRING 속성은 속성이 제공하는 텍스트와 비교되는 값을 지정합니다. 이 값은 따옴표로 묶어야 합니다. 문자열 내의 특정 문자(예: 따옴표(예:
"
))를 이스케이프하려면 백슬래시 문자(\
)를 사용합니다.표 23.1. 속성 기반 비교 작업 compare-operation 설명 contains
제공된 문자열이 속성에서 제공하는 텍스트의 모든 부분과 일치하는지 확인합니다.
isequal
제공된 문자열을 속성에서 제공하는 모든 텍스트와 비교합니다. 이 두 값은 정확히 일치해야 합니다.
startswith
제공된 문자열이 속성에서 제공하는 텍스트의 시작 부분에 정확히 있는지 여부를 확인합니다.
regex
제공된 POSIX BRE(Basic Regular Expression)를 속성에서 제공하는 텍스트와 비교합니다.
ereregex
제공된 POSIX ERE(Extended Regular Expression) 정규식을 속성에서 제공하는 텍스트와 비교합니다.
isempty
속성이 비어 있는지 확인합니다. 값이 삭제됩니다. 이는 정규화 결과에 따라 일부 필드가 채워질 수 있는 정규화된 데이터로 작업할 때 특히 유용합니다.
예 23.2. 속성 기반 필터
다음은
/etc/octets.conf에 지정할 수 있는 속성 기반 필터의 몇 가지 예입니다.
메시지 텍스트에 문자열오류가
포함된 syslog 메시지를 선택하려면 다음을 사용합니다.:msg, contains, "error"
다음 필터는 호스트 이름
host1
에서 수신한 syslog 메시지를 선택합니다.:hostname, isequal, "host1"
치명적이고 오류 사이에 텍스트가 없는 오류(예:
fatal
lib오류
:msg, !regex, "fatal .* error"
- 표현식 기반 필터
표현식 기반 필터는 정의된 산술, 부울 또는 문자열 작업에 따라 syslog 메시지를 선택합니다. 표현식 기반 필터는 RainerScript 라는 rsyslog의 자체 스크립팅 언어를 사용하여 복잡한 필터를 빌드합니다.
표현식 기반 필터의 기본 구문은 다음과 같습니다.
if EXPRESSION then ACTION else ACTION
다음과 같습니다.
EXPRESSION 속성은 평가할 표현식을 나타냅니다. 예를 들어
$msg는 'DEVNAME' 또는
.$syslogfacility-text == 'local0'
로 시작합니다및
또는
연산자를 사용하여 단일 필터에서 둘 이상의 표현식을 지정할 수 있습니다.rsyslog 는 표현식 기반 필터에서 대소문자를 구분하지 않는 비교를 지원합니다. EXPRESSION 속성 내에서
contains_i
또는startswith_i
compare-operations를 사용할 수 있습니다. 예를 들면 다음과 같습니다.$hostname이with_i "<HOST_NAME>"을 시작하는 경우LATE
.-
expression이 true 값을 반환하면 action에 수행할 작업을 나타냅니다.Represents an action to be performed if the expression returns the value
true
. 이 작업은 단일 작업 또는 curly braces로 묶은 임의의 복잡한 스크립트일 수 있습니다. 새 줄 시작 시 표현식 기반 필터는 키워드로 표시됩니다. 그런 다음 키워드는 Process에서 EXPRESSION 을 분리합니다. 선택적으로 else 키워드를 사용하여 조건이 충족되지 않는 경우 수행할 작업을 지정할 수 있습니다.
표현식 기반 필터를 사용하면 예 23.3. “표현식 기반 필터” 에서처럼 curly braces로 묶은 스크립트를 사용하여 조건을 중첩할 수 있습니다. 이 스크립트를 사용하면 표현식 내에서 기능/우선 기반 필터를 사용할 수 있습니다. 그러나 여기서는 속성 기반 필터를 사용하지 않는 것이 좋습니다. RainerScript는 특수 함수
re_match()
및re_extract()
를 사용하여 정규식을 지원합니다.예 23.3. 표현식 기반 필터
다음 표현식에는 두 개의 중첩된 조건이 포함되어 있습니다. prog1 이라는 프로그램에서 생성된 로그 파일은 메시지에 "test" 문자열이 있는지에 따라 두 개의 파일로 나뉩니다.
if $programname == 'prog1' then { action(type="omfile" file="/var/log/prog1.log") if $msg contains 'test' then action(type="omfile" file="/var/log/prog1test.log") else action(type="omfile" file="/var/log/prog1notest.log") }
다양한 표현식 기반 필터의 예제를 보려면 “온라인 문서” 를 참조하십시오. RainerScript는 rsyslog의 새로운 구성 형식을 기반으로합니다. 23.3절. “새 구성 형식 사용”
23.2.2. 작업
작업은 이미 정의된 선택기에서 필터링한 메시지로 수행할 작업을 지정합니다. 다음은 규칙에 정의할 수 있는 몇 가지 작업입니다.
- 로그 파일에 syslog 메시지 저장
대부분의 작업은 syslog 메시지가 저장된 로그 파일을 지정합니다. 이 작업은 이미 정의된 선택기 다음에 파일 경로를 지정하여 수행됩니다.
FILTER PATH
여기서 first LTER는 사용자 지정 선택기와 PATH 를 나타내는 대상 파일의 경로입니다.
예를 들어 다음 규칙은 모든 cron syslog 메시지를 선택하는 선택기와 이를
/var/log/cron.log
로그 파일에 저장하는 작업으로 구성됩니다.cron.* /var/log/cron.log
기본적으로 syslog 메시지가 생성될 때마다 로그 파일이 동기화됩니다. 동기화를 생략하도록 지정한 파일 경로의 접두사로 대시 표시(
-
)를 사용합니다.FILTER -PATH
쓰기 시도 직후 시스템이 종료되면 정보가 손실될 수 있습니다. 그러나 이 설정은 특히 매우 자세한 로그 메시지를 생성하는 프로그램을 실행하는 경우 성능을 향상시킬 수 있습니다.
지정된 파일 경로는 정적 또는 동적 일 수 있습니다. 정적 파일은 위 예제와 같이 고정 파일 경로로 표시됩니다. 동적 파일 경로는 수신된 메시지에 따라 다를 수 있습니다. 동적 파일 경로는 템플릿과 물음표(? ) 접두사
로
표시됩니다.FILTER ?DynamicFile
여기서 DynamicFile 은 출력 경로를 수정하는 사전 정의된 템플릿의 이름입니다. 대시 접두사(
-
)를 사용하여 동기화를 비활성화할 수도 있으며, 콜론으로 구분된 여러 템플릿을 사용할 수도 있습니다.지정한 파일이 기존 터미널 또는
/dev/console
장치인 경우 각각 X Window System을 사용할 때 표준 출력(특정 터미널처리) 또는 콘솔(특별/dev/console
-handling 사용)으로 syslog 메시지가 전송됩니다.- 네트워크를 통해 syslog 메시지 전송
rsyslog 를 사용하면 네트워크를 통해 syslog 메시지를 보내고 받을 수 있습니다. 이 기능을 사용하면 한 시스템에서 여러 호스트의 syslog 메시지를 관리할 수 있습니다. syslog 메시지를 원격 머신으로 전달하려면 다음 구문을 사용하십시오.
@(
zNUMBER
)HOST:PORT다음과 같습니다.
-
at 기호(
@
)는 syslog 메시지가UDP
프로토콜을 사용하여 호스트로 전달됨을 나타냅니다.TCP
프로토콜을 사용하려면@@
) 사이에 공백이 없는 부호에서 두 개를 사용합니다. -
선택적
zNUMBER
설정은 syslog 메시지에 대해 zlib 압축을 활성화합니다. NUMBER 속성은 압축 수준을 지정합니다(1에서 가장 낮은 부터 9~최대). 압축은rsyslogd
에서 자동으로 확인되며, 압축된 압축이 있는 경우 60바이트 이하의 메시지가 압축되지 않는 경우에만 메시지가 압축됩니다. - HOST 속성은 선택한 syslog 메시지를 수신하는 호스트를 지정합니다.
PORT 속성은 호스트 시스템의 포트를 지정합니다.
IPv6
주소를 호스트로 지정할 때 주소를 대괄호([
,]
)로 묶습니다.예 23.4. 네트워크를 통해 syslog 메시지 전송
다음은 네트워크를 통해 syslog 메시지를 전달하는 작업의 몇 가지 예입니다(모든 작업이 우선 순위가 있는 모든 메시지를 선택하는 선택기와 함께 시작됨).
UDP
프로토콜을 통해192.168.0.1
으로 메시지를 전달하려면 다음을 입력합니다.. @192.168.0.1
포트 6514 및
TCP
프로토콜을 사용하여 메시지를 "example.com"으로 전달하려면 다음을 사용합니다.. @@example.com:6514
다음은 zlib (level 9 압축)로 메시지를 압축하고
UDP
프로토콜을 사용하여2001:db8::1
로 전달합니다.. @(z9)[2001:db8::1]
-
at 기호(
- 출력 채널
출력 채널은 주로 로그 파일이 확장될 수 있는 최대 크기를 지정하는 데 사용됩니다. 이는 로그 파일 순환에 매우 유용합니다(자세한 내용은 23.2.5절. “로그 순환”참조). 출력 채널은 기본적으로 출력 작업에 대한 정보 컬렉션입니다. 출력 채널은
$outchannel
지시문으로 정의됩니다. 출력 채널을/etc/journal.conf
에 정의하려면 다음 구문을 사용하십시오.$outchannel NAME, FILE_NAME, MAX_SIZE, ACTION
다음과 같습니다.
- NAME 속성은 출력 채널의 이름을 지정합니다.
- FILE_NAME 속성은 출력 파일의 이름을 지정합니다. 출력 채널은 파이프, 터미널 또는 기타 종류의 출력이 아닌 파일에만 쓸 수 있습니다.
- MAX_SIZE 속성은 지정된 파일(GB)이 증가할 수 있는최대 크기를 나타냅니다. 이 값은 바이트 단위로 지정됩니다.
rhcos 속성은 MAX_SIZE 에 정의된 최대 크기가 충돌할 때 수행되는 작업을 지정합니다.
정의된 출력 채널을 규칙 내에서 작업으로 사용하려면 다음을 입력합니다.
FILTER :omfile:$NAME
예 23.5. 출력 채널 로그 회전
다음 출력은 출력 채널을 사용하여 간단한 로그 회전을 보여줍니다. 먼저 출력 채널은
$outchannel
지시문을 통해 정의됩니다.$outchannel log_rotation, /var/log/test_log.log, 104857600, /home/joe/log_rotation_script
그런 다음 우선 순위로 모든 syslog 메시지를 선택하고 실행된 syslog 메시지에서 이전에 정의된 출력 채널을 실행하는 규칙에 사용됩니다.
. :omfile:$log_rotation
제한이 100MB이면
/home/joe/log_rotation_script
가 실행됩니다. 이 스크립트는 파일을 다른 폴더로 이동하는 것을 포함하거나, 특정 콘텐츠를 편집하거나 간단히 제거할 수 있습니다.
- 특정 사용자에게 syslog 메시지 전송
-
rsyslog 는 예 23.7. “여러 작업 지정”같이 메시지를 보낼 사용자의 사용자 이름을 지정하여 syslog 메시지를 특정 사용자에게 보낼 수 있습니다. 둘 이상의 사용자를 지정하려면 각 사용자 이름을 쉼표( )로 구분합니다.
- 프로그램 실행
rsyslog 를 사용하면 선택한 syslog 메시지에 대한 프로그램을 실행하고
system()
호출을 사용하여 쉘에서 프로그램을 실행할 수 있습니다. 실행할 프로그램을 지정하려면 캐럿 문자(^
)로 접두사를 지정합니다. 결과적으로 수신된 메시지를 포맷하고 한 줄 매개 변수로 지정된 실행 파일에 전달하는 템플릿을 지정합니다(템플릿에 대한 자세한 내용은 23.2.3절. “템플릿”참조).FILTER ^EXECUTABLE; TEMPLATE
여기서 FILTER 조건의 출력은 EXECUTABLE 으로 표시되는 프로그램에 의해 처리됩니다. 이 프로그램은 유효한 실행 파일일 수 있습니다. TEMPLATE 을 형식 템플릿의 이름으로 바꿉니다.
예 23.6. 프로그램 실행
다음 예에서 우선순위가 있는 syslog 메시지가 선택되고
템플릿
템플릿으로 포맷되고 test-program 프로그램에 매개 변수로 전달되며, 이 매개변수는 제공된 매개 변수로 실행됩니다.. ^test-program;template
주의모든 호스트에서 메시지를 수락하고 쉘 실행 작업을 사용하는 경우 명령 삽입에 취약할 수 있습니다. 공격자는 작업에서 실행되도록 지정한 프로그램에서 명령을 삽입하고 실행할 수 있습니다. 가능한 보안 위협을 방지하려면 쉘 실행 작업을 철저히 고려합니다.
- 데이터베이스에 syslog 메시지 저장
선택한 syslog 메시지는 데이터베이스 작성기 작업을 사용하여 데이터베이스 테이블에 직접 쓸 수 있습니다. 데이터베이스 작성자는 다음 구문을 사용합니다.
:PLUGIN:DB_HOST,DB_NAME,DB_USER,DB_PASSWORD;TEMPLATE
다음과 같습니다.
-
PLUGIN 은 데이터베이스 작성(예:
ommysql
플러그인)을 처리하는 지정된 플러그인을 호출합니다. - DB_HOST 속성은 데이터베이스 호스트 이름을 지정합니다.
- DB_NAME 속성은 데이터베이스 이름을 지정합니다.
- DB_USER 속성은 데이터베이스 사용자를 지정합니다.
- DB_PASSWORD 속성은 앞서 언급한 데이터베이스 사용자와 함께 사용되는 암호를 지정합니다.
TEMPLATE 속성은 syslog 메시지를 수정하는 템플릿의 선택적 사용을 지정합니다. 템플릿에 대한 자세한 내용은 23.2.3절. “템플릿” 을 참조하십시오.
중요현재 rsyslog 는
MySQL
및PostgreSQL
데이터베이스만 지원합니다.MySQL
및PostgreSQL
데이터베이스 작성기 기능을 사용하려면 rsyslog-mysql 및 rsyslog-pgsql 패키지를 각각 설치합니다. 또한/etc/journal.conf 구성 파일에 적절한 모듈을 로드해야 합니다.
module(load=”ommysql”) # Output module for MySQL support module(load=”ompgsql”) # Output module for PostgreSQL support
rsyslog 모듈에 대한 자세한 내용은 23.6절. “Rsyslog 모듈 사용” 을 참조하십시오.
또는
omlibdb
모듈 (supports)에서 제공하는 일반 데이터베이스 인터페이스를 사용할 수도 있습니다. firebird/Interbase, MS SQL, Sybase, SQLLite, Ingres, Oracle, mSQL).
-
PLUGIN 은 데이터베이스 작성(예:
- syslog 메시지 삭제
선택한 메시지를 삭제하려면
stop
을 사용합니다.삭제 작업은 주로 추가 처리를 수행하기 전에 메시지를 필터링하는 데 사용됩니다. 로그 파일을 채울 일부 반복 메시지를 생략하려는 경우 유용할 수 있습니다. 삭제 작업 결과는 지정된 구성 파일에서 작업 목록 위에 이러한 작업을 배치하기 위해 지정된 위치에 따라 달라집니다. 메시지가 삭제되면 나중에 설정 파일 줄에서 검색할 수 없습니다.
예를 들어 다음 규칙은
local5.*
필터와 일치하는 모든 메시지를 삭제합니다.local5.* stop
다음 예에서 모든 cron syslog 메시지가 삭제됩니다.
cron.* stop
참고rsyslog 7 이전 버전에서 틸드 문자(
~
)는 syslog 메시지를 삭제하는것을 중지
하는 대신 사용되었습니다.
여러 작업 지정
각 선택기에 대해 여러 작업을 지정할 수 있습니다. 하나의 선택기에 대해 여러 작업을 지정하려면 각 작업을 별도의 줄에 작성하고 앞에 (&) 문자를 추가합니다.
FILTER ACTION & ACTION & ACTION
여러 작업을 지정하면 지정된 선택기를 한 번만 평가해야 하므로 원하는 결과의 전체 성능이 향상됩니다.
예 23.7. 여러 작업 지정
다음 예에서 중요한 우선 순위(crit
)가 있는 모든 커널 syslog 메시지는 템플릿 임시
에 의해 처리되고 테스트 프로그램
실행 파일에 전달되고 UDP
프로토콜을 통해 192.168.0.1
으로 전달됩니다.
kern.=crit user1 & ^test-program;temp & @192.168.0.1
모든 작업 뒤에 메시지를 포맷하는 템플릿이 올 수 있습니다. 템플릿을 지정하려면 별칭(;
)이 있는 작업 접미사를 지정하고 템플릿 이름을 지정합니다. 템플릿에 대한 자세한 내용은 23.2.3절. “템플릿” 을 참조하십시오.
작업에 사용하기 전에 템플릿을 정의해야 합니다. 그러지 않으면 무시됩니다. 즉, 템플릿 정의에서 항상 /etc/journal.conf의 규칙 정의 앞에 와야 합니다.
23.2.3. 템플릿
rsyslog 에 의해 생성된 모든 출력은 템플릿을 사용하여 필요에 따라 수정하고 포맷할 수 있습니다. 템플릿을 생성하려면 /etc/journal.conf에서 다음 구문을 사용합니다.
template(name=”TEMPLATE_NAME” type=”string” string="text %PROPERTY% more text" [option.OPTION="on"])
다음과 같습니다.
-
template()
는 템플릿을 정의하는 블록을 도입하는 지시문입니다. -
TEMPLATE_NAME
필수 인수는 템플릿을 참조하는 데 사용됩니다.TEMPLATE_NAME
은 고유해야 합니다. -
유형
필수 인수는 "list", "subtree", "string" 또는 "plugin" 값 중 하나를 가져올 수 있습니다. -
string
인수는 실제 템플릿 텍스트입니다. 이 텍스트 내에서 \n 줄 바꿈 또는 \r과 같은 특수 문자를 사용할 수 있습니다.With this text, special characters, such as \n for newline or \r for carriage return. % 또는 "와 같은 기타 문자는 문자 그대로 사용하려는 경우 이스케이프해야 합니다. 이 텍스트 내에서 새 줄의 경우\n
또는 캐리지 리턴의 경우\r
와 같은 특수 문자를 사용할 수 있습니다.%
또는"
와 같은 기타 문자는 문자 그대로 사용하려는 경우 이스케이프해야 합니다. -
두 백분율 기호(
%
) 간에 지정된 텍스트는 syslog 메시지의 특정 콘텐츠에 액세스할 수 있는 속성 을 지정합니다. 속성에 대한 자세한 내용은 “속성” 을 참조하십시오. OPTION
속성은 템플릿 기능을 수정하는 옵션을 지정합니다. 현재 지원되는 템플릿 옵션은 SQL 쿼리로 텍스트를 포맷하는 데 사용되는sql
및stdsql
또는 JSON 처리에 적합한 텍스트를 포맷하는 json과 속성 이름의대소문자
를 구분하는 대소문자를 구분합니다.참고데이터베이스 작성자는
sql
또는stdsql
옵션이 템플릿에 지정되어 있는지 확인합니다. 그렇지 않은 경우 데이터베이스 작성자는 작업을 수행하지 않습니다. 이는 SQL 삽입과 같은 가능한 보안 위협을 방지하기 위한 것입니다.자세한 내용은 23.2.2절. “작업” 의 데이터베이스에서 syslog 메시지 저장 섹션을 참조하십시오.
동적 파일 이름 생성
템플릿을 사용하여 동적 파일 이름을 생성할 수 있습니다. 파일 경로의 일부로 속성을 지정하면 syslog 메시지를 분류하는 편리한 방법인 각 고유 속성에 대해 새 파일이 생성됩니다.
예를 들어 메시지에서 타임스탬프를 추출하는 timegenerated
속성을 사용하여 각 syslog 메시지에 고유한 파일 이름을 생성합니다.
template(name=”DynamicFile” type=”list”) { constant(value=”/var/log/test_logs/”) property(name=”timegenerated”) constant(value”-test.log”) }
$template
지시문은 템플릿만 지정합니다. 이를 적용하려면 규칙 내에서 사용해야 합니다. /etc/octets.conf
에서 질문 표시(?
)를 작업 정의에서 사용하여 동적 파일 이름 템플릿을 표시합니다.
. ?DynamicFile
속성
템플릿 내에 정의된 속성(두%
기호(%))을 사용하면 속성 교체 기를 사용하여 syslog 메시지의 다양한 콘텐츠에 액세스할 수 있습니다. 템플릿 내부에 속성을 정의하려면 두 개의 따옴표("…"
) 사이에 속성을 정의하려면 다음 구문을 사용합니다.
%PROPERTY_NAME:FROM_CHAR:TO_CHAR:OPTION%
다음과 같습니다.
-
PROPERTY_NAME 속성은 속성의 이름을 지정합니다. 사용 가능한 모든 속성 및 자세한 설명은 사용 가능한 속성 섹션의
rsyslog.conf(5)
매뉴얼 페이지에서 확인할 수 있습니다. -
FROM_CHAR 및 TO_CHAR 속성은 지정된 속성이 작동할 문자 범위를 나타냅니다. 또는 정규식을 사용하여 문자 범위를 지정할 수 있습니다. 이렇게 하려면
R
문자를 FROM_CHAR 속성으로 설정하고 원하는 정규식을 TO_CHAR 속성으로 지정합니다. -
OPTION 속성은 입력을 소문자로 변환하는
소문자
옵션과 같은 속성 옵션을 지정합니다. 사용 가능한 모든 속성 옵션 목록과 자세한 설명은 Property Options 섹션 아래에 있는rsyslog.conf(5)
매뉴얼 페이지에서 확인할 수 있습니다.
다음은 간단한 속성의 몇 가지 예입니다.
다음 속성은 syslog 메시지의 전체 메시지 텍스트를 가져옵니다.
%msg%
다음 속성은 syslog 메시지의 메시지 텍스트의 처음 두 문자를 가져옵니다.
%msg:1:2%
다음 속성은 syslog 메시지의 전체 메시지 텍스트를 가져오고 마지막 줄 피드 문자를 삭제합니다.
%msg:::drop-last-lf%
다음 속성은 syslog 메시지가 수신될 때 생성되는 타임 스탬프의 처음 10자를 가져와서 RFC 3999 날짜 표준에 따라 포맷합니다.
%timegenerated:1:10:date-rfc3339%
템플릿 예
이 섹션에서는 rsyslog 템플릿의 몇 가지 예를 보여줍니다.
예 23.8. “자세한 syslog 메시지 템플릿” 메시지의 심각도, 기능, 메시지가 수신될 때의 타임스탬프, 호스트 이름, 메시지 텍스트, 메시지 텍스트 등을 출력하도록 syslog 메시지를 포맷하는 템플릿을 표시합니다.
예 23.8. 자세한 syslog 메시지 템플릿
template(name=”verbose” type=”list”) { property(name="syslogseverity”) property(name="syslogfacility”) property(name="timegenerated”) property(name="HOSTNAME”) property(name="syslogtag”) property(name="msg”) constant(value=”\n") }
예 23.9. “월경 메시지 템플릿” 기존 wall 메시지와 유사한 템플릿을 표시합니다(로그인되어 있고 mesg(1)
권한이 yes
로 설정된 모든 사용자에게 전송됨). 이 템플릿은 새 줄에 호스트 이름, 메시지 태그 및 타임스탬프와 함께 메시지 텍스트를 출력하고( \r
및 \n
을 사용하여) 벨( \7
사용)을 사용하여 메시지를 출력합니다.
예 23.9. 월경 메시지 템플릿
template(name=”wallmsg” type=”list”) { constant(value="\r\n\7Message from syslogd@”) property(name="HOSTNAME”) constant(value=” at ") property(name="timegenerated”) constant(value=" ...\r\n ”) property(name="syslogtag”) constant(value=” “) property(name="msg”) constant(value=”\r\n”) }
예 23.10. “데이터베이스 형식 메시지 템플릿” 데이터베이스 쿼리로 사용할 수 있도록 syslog 메시지를 포맷하는 템플릿을 표시합니다. template 옵션으로 지정된 템플릿 끝에 sql
옵션을 사용합니다. 데이터베이스 작성자가 메시지를 MySQL SQL
쿼리로 포맷하도록 지시합니다.
예 23.10. 데이터베이스 형식 메시지 템플릿
template(name="dbFormat" type="list" option.sql="on") { constant(value="insert into SystemEvents (Message, Facility, FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag)") constant(value=" values ('") property(name="msg") constant(value="', ") property(name="syslogfacility") constant(value=", '") property(name="hostname") constant(value="', ") property(name="syslogpriority") constant(value=", '") property(name="timereported" dateFormat="mysql") constant(value="', '") property(name="timegenerated" dateFormat="mysql") constant(value="', ") property(name="iut") constant(value=", '") property(name="syslogtag") constant(value="')") }
rsyslog 에는 RSYSLOG_
접두사로 식별되는 사전 정의된 템플릿 세트도 포함되어 있습니다. 이는 syslog 사용을 위해 예약되어 있으며 충돌을 피하기 위해 이 접두사를 사용하여 템플릿을 생성하지 않는 것이 좋습니다. 다음 목록은 이러한 사전 정의된 템플릿을 정의와 함께 보여줍니다.
RSYSLOG_DebugFormat
속성 문제 해결에 사용되는 특수 형식입니다.
template(name=”RSYSLOG_DebugFormat” type=”string” string="Debug line with all properties:\nFROMHOST: '%FROMHOST%', fromhost-ip: '%fromhost-ip%', HOSTNAME: '%HOSTNAME%', PRI: %PRI%,\nsyslogtag '%syslogtag%', programname: '%programname%', APP-NAME: '%APP-NAME%', PROCID: '%PROCID%', MSGID: '%MSGID%',\nTIMESTAMP: '%TIMESTAMP%', STRUCTURED-DATA: '%STRUCTURED-DATA%',\nmsg: '%msg%'\nescaped msg: '%msg:::drop-cc%'\nrawmsg: '%rawmsg%'\n\n")
RSYSLOG_SyslogProtocol23Format
IETF의 인터넷 개발 ietf-syslog-protocol-23에 지정된 형식은 새로운 syslog 표준 RFC로 간주됩니다.
template(name=”RSYSLOG_SyslogProtocol23Format” type=”string” string="%PRI%1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n ")
RSYSLOG_FileFormat
TraditionalFileFormat과 유사한 최신 스타일 로그 파일 형식이지만, 높은 정밀도 타임 스탬프 및 시간대 정보가 있습니다.
template(name="RSYSLOG_FileFormat" type="list") { property(name="timestamp" dateFormat="rfc3339") constant(value=" ") property(name="hostname") constant(value=" ") property(name="syslogtag") property(name="msg" spifno1stsp="on" ) property(name="msg" droplastlf="on" ) constant(value="\n") }
RSYSLOG_TraditionalFileFormat
단정밀도 시간 스탬프가 짧은 이전 기본 로그 파일 형식입니다.
template(name="RSYSLOG_TraditionalFileFormat" type="list") { property(name="timestamp") constant(value=" ") property(name="hostname") constant(value=" ") property(name="syslogtag") property(name="msg" spifno1stsp="on" ) property(name="msg" droplastlf="on" ) constant(value="\n") }
RSYSLOG_ForwardFormat
높은 정확도의 타임스탬프 및 시간대 정보가 있는 전달 형식입니다.
template(name="ForwardFormat" type="list") { constant(value="<") property(name="pri") constant(value=">") property(name="timestamp" dateFormat="rfc3339") constant(value=" ") property(name="hostname") constant(value=" ") property(name="syslogtag" position.from="1" position.to="32") property(name="msg" spifno1stsp="on" ) property(name="msg") }
RSYSLOG_TraditionalForwardFormat
단정밀도가 낮은 타임스탬프가 있는 기존 전달 형식입니다.
template(name="TraditionalForwardFormat" type="list") { constant(value="<") property(name="pri") constant(value=">") property(name="timestamp") constant(value=" ") property(name="hostname") constant(value=" ") property(name="syslogtag" position.from="1" position.to="32") property(name="msg" spifno1stsp="on" ) property(name="msg") }
23.2.4. 글로벌 정책
글로벌 지시문은 rsyslogd
데몬에 적용되는 구성 옵션입니다. 일반적으로 rsyslogd
데몬 또는 다음 규칙의 동작에 영향을 미치는 특정 사전 정의된 변수의 값을 지정합니다. 모든 글로벌 지시문은 글로벌 구성 블록으로
묶습니다. 다음은 로그 메시지에 대한 로컬 호스트 이름을 재정의하는 global 지시문의 예입니다.
global(localHostname=”machineXY”)
/etc/journal.conf
구성 파일에 여러 지시문을 정의할 수 있습니다. 지시문은 동일한 지시문이 다시 발생할 때까지 모든 구성 옵션의 동작에 영향을 미칩니다. 전역 지시문을 사용하여 작업, 큐 및 디버깅을 구성할 수 있습니다. 사용 가능한 모든 구성 지시문의 포괄적인 목록은 “온라인 문서” 에서 확인할 수 있습니다. 현재 $ 기반 구문을 대체하는 새로운 구성 형식이 개발되었습니다( 23.3절. “새 구성 형식 사용”참조). 그러나 클래식 글로벌 지시문은 레거시 형식으로 계속 지원됩니다.
23.2.5. 로그 순환
다음은 샘플 /etc/logrotate.conf
구성 파일입니다.
# rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # uncomment this if you want your log files compressed compress
샘플 구성 파일의 모든 행은 모든 로그 파일에 적용되는 전역 옵션을 정의합니다. 이 예에서는 매주 로그 파일이 순환되고 순환된 로그 파일은 4주 동안 보관되며, 순환된 모든 로그 파일은 gzip 에 의해 .gz
형식으로 압축됩니다. 해시 기호(#)로 시작하는 행은 주석이며 처리되지 않습니다.
특정 로그 파일에 대한 구성 옵션을 정의하고 글로벌 옵션에 배치할 수 있습니다. 그러나 /etc/logrotate.d/
디렉토리에 있는 특정 로그 파일에 대해 별도의 구성 파일을 생성하고 여기에 구성 옵션을 정의하는 것이 좋습니다.
다음은 /etc/logrotate.d/
디렉토리에 배치된 구성 파일의 예입니다.
/var/log/messages { rotate 5 weekly postrotate /usr/bin/killall -HUP syslogd endscript }
이 파일의 구성 옵션은 /var/log/message 로그 파일에
만 적용됩니다. 여기에서 지정한 설정은 가능한 경우 전역 설정을 재정의합니다. 따라서 순환된 /var/log/
catalog 로그 파일은 글로벌 옵션에 정의된 4주가 아닌 5주 동안 유지됩니다.
다음은 logrotate 구성 파일에 지정할 수 있는 일부 지시문 목록입니다.
weekly
- 매주 수행할 로그 파일의 회전을 지정합니다. 유사한 지시문은 다음과 같습니다.-
daily
-
monthly
-
yearly
-
compress
- 순환된 로그 파일의 압축을 활성화합니다. 유사한 지시문은 다음과 같습니다.-
nocompress
-
compresscmd
- 압축에 사용할 명령을 지정합니다. -
uncompresscmd
-
compressext
- 압축에 사용할 확장을 지정합니다. -
compressoptions
- 사용되는 압축 프로그램으로 전달할 옵션을 지정합니다. -
delaycompress
- 로그 파일의 압축을 로그 파일의 다음 회전으로 연기합니다.
-
-
회전 INTEGER
- 특정 주소로 전송되기 전에 로그 파일이 발생하는 회전 횟수를 지정합니다. 0 값을 지정하면 순환하지 않고 이전 로그 파일이 제거됩니다. mail ADDRESS
- 이 옵션은rotate
지시문에서 지정된 주소에 대해 정의된 횟수만큼 순환된 로그 파일의 우편을 활성화합니다. 유사한 지시문은 다음과 같습니다.-
nomail
-
mailfirst
- 방금 순환된 로그 파일이 about-to-expire 로그 파일이 아니라 메일로 전송되도록 지정합니다. -
maillast
- 방금 순환된 로그 파일 대신 about-to-expire 로그 파일을 메일로 전송하도록 지정합니다. 이는mail
이 활성화된 경우 기본 옵션입니다.
-
지시문 및 다양한 구성 옵션의 전체 목록은 logrotate(5)
매뉴얼 페이지를 참조하십시오.
23.2.6. Open 파일의 제한 사항 늘리기
특정 상황에서 rsyslog
는 열린 파일의 최대 수에 대한 제한을 초과합니다. 따라서 rsyslog
가 새 파일을 열 수 없습니다.
rsyslog
에서 열린 파일의 제한을 늘리려면 다음을 수행합니다.
다음 콘텐츠를 사용하여 /etc/systemd/system/rsylog.service.d/increase_nofile_limit.conf
파일을 만듭니다.
[Service] LimitNOFILE=16384
23.3. 새 구성 형식 사용
rsyslog 패키지의 Red Hat Enterprise Linux 7에 대해 기본적으로 설치된 rsyslog 버전 7에서 새 구성 구문이 도입되었습니다. 이 새로운 구성 형식은 특정 잘못된 구문을 허용하지 않고 더 강력하고 직관적이며 일반적인 오류를 방지하는 것을 목표로 합니다. 구문 개선은 RainerScript를 사용하는 새로운 구성 프로세서에 의해 활성화됩니다. 레거시 형식은 계속 완전하게 지원되고 있으며 기본적으로 /etc/1.8.0.conf
구성 파일에서 사용됩니다.
RainerScript는 네트워크 이벤트를 처리하고 rsyslog 와 같은 이벤트 프로세서를 구성하도록 설계된 스크립팅 언어입니다. RainerScript가 먼저 표현식 기반 필터를 정의하는 데 사용되었습니다. 예 23.3. “표현식 기반 필터” 을 참조하십시오. rsyslog 버전 7의 RainerScript 버전은 input()
및 ruleset()
문을 구현하므로 /etc/journal.conf
구성 파일을 새 구문으로 작성할 수 있습니다. 새 구문은 주로 더 구조화된다는 점에서 다릅니다. 매개 변수는 입력, 작업, 템플릿 및 모듈 로드와 같은 문에 인수로 전달됩니다. 옵션의 범위는 블록별로 제한됩니다. 이렇게 하면 가독성이 향상되고 잘못된 구성으로 인한 버그 수가 줄어듭니다. 성능 또한 큰 이점을 얻을 수 있습니다. 일부 기능은 두 구문 모두에 노출되며 일부는 새 기능에서만 발생합니다.
레거시 스타일 매개변수로 작성된 구성을 비교합니다.
$InputFileName /tmp/inputfile $InputFileTag tag1: $InputFileStateFile inputfile-state $InputRunFileMonitor
또한 새 형식 문을 사용하는 것과 동일한 구성이 있습니다.And the same configuration with use of the new format statement:
input(type="imfile" file="/tmp/inputfile" tag="tag1:" statefile="inputfile-state")
이렇게 하면 구성에 사용되는 매개변수 수를 크게 줄이고 가독성을 높이며 실행 속도가 향상됩니다. RainerScript 문 및 매개변수에 대한 자세한 내용은 “온라인 문서” 을 참조하십시오.
23.3.1. 규칙 세트
특수 지시문을 별도로 남겨 두면 rsyslog 는 필터 조건으로 구성된 규칙에서 정의한 메시지와 조건이 true인 경우 수행할 작업을 처리합니다. 기존에 작성된 /etc/octets.conf
파일을 사용하면 모든 입력 메시지의 모양으로 모든 규칙이 평가됩니다. 이 프로세스는 첫 번째 규칙으로 시작하고 모든 규칙을 처리할 때까지 또는 규칙 중 하나에서 메시지를 삭제할 때까지 계속됩니다.
그러나 규칙은 규칙 세트라는 시퀀스로 그룹화할 수 있습니다. 규칙 세트를 사용하면 특정 규칙의 효과를 선택한 입력으로만 제한하거나 특정 입력에 바인딩된 별도의 작업 세트를 정의하여 rsyslog 의 성능을 향상시킬 수 있습니다. 즉, 특정 유형의 메시지에 대해 잠재적으로 false로 평가되는 필터 조건을 건너뛸 수 있습니다. /etc/journal.conf
의 레거시 규칙 세트는 다음과 같습니다.
$RuleSet rulesetname rule rule2
다른 규칙이 정의되거나 기본 규칙 세트를 다음과 같이 호출하면 규칙을 종료합니다.
$RuleSet RSYSLOG_DefaultRuleset
rsyslog 7의 새 구성 형식을 사용하면 input()
및 ruleset()
문이 이 작업을 위해 예약되어 있습니다. /etc/journal.conf
의 새로운 형식 규칙 세트는 다음과 같습니다.
ruleset(name="rulesetname") { rule rule2 call rulesetname2 … }
rulesetname 을 규칙 집합의 식별자로 바꿉니다. ruleset 이름은 RSYSLOG_
로 시작할 수 없습니다. 이 네임스페이스는 rsyslog 에서 사용하도록 예약되어 있기 때문입니다. 그런 다음 RSYSLOG_DefaultRuleset
는 메시지에 다른 규칙 세트가 할당되어 있지 않은 경우 수행할 기본 규칙 집합을 정의합니다. 규칙 및 rule2 를 사용하면 위에서 언급한 필터 작업 형식으로 규칙을 정의할 수 있습니다. call
매개 변수를 사용하면 다른 ruleset 블록 내부에서 규칙 세트를 호출하여 중첩할 수 있습니다.
규칙 세트를 생성한 후 적용할 입력을 지정해야 합니다.
input(type="input_type" port="port_num" ruleset="rulesetname");
여기서 입력 _type , 메시지를 수집한 입력 모듈 또는 port_num - 포트 번호를 통해 식별할 수 있습니다. file 또는 tag 와 같은 다른 매개변수는 input()
에 대해 지정할 수 있습니다. rulesetname 을 메시지에 대해 평가할 규칙 세트 이름으로 교체합니다. 입력 메시지가 규칙 세트에 명시적으로 바인딩되지 않은 경우 기본 규칙 세트가 트리거됩니다.
또한 레거시 형식을 사용하여 규칙 세트를 정의할 수도 있습니다. 자세한 내용은 “온라인 문서” 을 참조하십시오.
예 23.11. 규칙 세트 사용
다음 규칙 세트를 사용하면 다양한 포트에서 들어오는 원격 메시지를 서로 처리할 수 있습니다. 다음을 /etc/journal.conf에 추가하십시오.
ruleset(name="remote-6514") { action(type="omfile" file="/var/log/remote-6514") } ruleset(name="remote-601") { cron.* action(type="omfile" file="/var/log/remote-601-cron") mail.* action(type="omfile" file="/var/log/remote-601-mail") } input(type="imtcp" port="6514" ruleset="remote-6514"); input(type="imtcp" port="601" ruleset="remote-601");
위의 예에 표시된 규칙 세트는 두 포트에서 원격 입력에 대한 로그 대상을 정의합니다(포트 601
인 경우, 메시지는 기능에 따라 정렬됩니다. 그런 다음 TCP 입력이 활성화되고 규칙 세트에 바인딩됩니다. 이 구성이 작동하려면 필요한 모듈(imtcp)을 로드해야 합니다.
23.3.2. sysklogd와의 호환성
-c
옵션을 통해 지정된 호환성 모드는 rsyslog 버전 5에 있지만 버전 7에서는 존재하지 않습니다. 또한 sysklogd-style 명령줄 옵션은 더 이상 사용되지 않으며 이러한 명령줄 옵션을 통해 rsyslog 를 구성하는 것은 피해야 합니다. 그러나 여러 템플릿과 지시문을 사용하여 sysklogd와 같은 동작을 에뮬레이션하도록 rsyslogd
를 구성할 수 있습니다.
다양한 rsyslogd
옵션에 대한 자세한 내용은 rsyslogd(8)
매뉴얼 페이지를 참조하십시오.
23.4. Rsyslog에서 큐 작업
대기열은 rsyslog 의 구성 요소 간에 대부분 syslog 메시지를 전달하는 데 사용됩니다. 큐를 사용하면 rsyslog가 여러 메시지를 동시에 처리하고 한 번에 여러 작업을 단일 메시지에 적용할 수 있습니다. rsyslog 내부의 데이터 흐름은 다음과 같이 설명할 수 있습니다.
그림 23.1. Rsyslog의 메시지 흐름
rsyslog 가 메시지를 수신할 때마다 이 메시지를 전처리기에 전달한 다음 기본 메시지 대기열에 배치합니다. 메시지는 큐 해제되어 규칙 프로세서에 전달될 때까지 기다립니다.
규칙 프로세서는 구문 분석 및 필터링 엔진입니다. 여기서는 /etc/journal.conf
에 정의된 규칙이 적용됩니다. 이러한 규칙에 따라 규칙 프로세서는 수행할 작업을 평가합니다. 각 작업에는 자체 작업 큐가 있습니다. 메시지는 이 큐를 통해 최종 출력을 생성하는 각 작업 프로세서에 전달됩니다. 이 시점에서 하나의 메시지에서 여러 작업을 동시에 실행할 수 있습니다. 이를 위해 메시지는 복제되고 여러 작업 프로세서에 전달됩니다.
작업당 하나의 큐만 가능합니다. 구성에 따라 작업 대기열 없이 메시지를 작업 프로세서에 보낼 수 있습니다. 이는 직접 대기열 의 동작입니다(아래 참조). 출력 작업이 실패하면 작업 프로세서는 작업 큐에 통지한 다음 처리되지 않은 요소를 다시 수행하고 일정 시간 간격 후에 작업을 다시 시도합니다.
요약하기 위해 규칙 프로세서 앞에는 단일 기본 메시지 큐로 또는 다양한 유형의 출력 작업 앞에 작업 큐가 있는 두 개의 위치가 있습니다. 큐는 두 가지 주요 이점을 제공하여 메시지 처리 성능이 향상됩니다.
- 이는 rsyslog구조에서 생산자와 소비자를 분리하는 버퍼 역할을 합니다.
- 메시지에서 수행되는 작업을 병렬화 할 수 있습니다.
이 외에도 시스템에 최적의 성능을 제공하기 위해 여러 지시문으로 큐를 구성할 수 있습니다. 이러한 구성 옵션에 대해서는 다음 섹션에서 설명합니다.
출력 플러그인이 메시지를 전달할 수 없는 경우 이전 메시지 큐에 저장됩니다. 큐가 채워지면 입력이 더 이상 가득 차지 않을 때까지 차단됩니다. 이렇게 하면 차단된 큐를 통해 새 메시지가 기록되지 않습니다. 별도의 작업 대기열이 없으면 SSH
로깅 방지와 같은 심각한 결과가 발생할 수 있으므로 SSH
액세스가 방지됩니다. 따라서 네트워크 또는 데이터베이스를 통해 전달되는 출력에 전용 작업 대기열을 사용하는 것이 좋습니다.
23.4.1. 대기열 정의
메시지가 저장되는 위치에 따라 가장 널리 사용되는 대기열의 직접, 즉 직접 ,메모리 내, 디스크, 디스크 기반의 여러 종류가 있습니다. 기본 메시지 큐와 작업 대기열에 대해 이러한 유형 중 하나를 선택할 수 있습니다. 다음을 /etc/journal.conf에 추가하십시오.
object(queue.type=”queue_type”)
이를 추가하면 다음에 대한 설정을 적용할 수 있습니다.
-
메인 메시지 큐: 오브젝트 를
main_queue
로 교체 -
작업 대기열: 오브젝트 를
작업으로
교체 -
ruleset
: 오브젝트 를 규칙 세트로 교체
queue_type 을 직접
,linkedlist
또는 fixedarray
(메모리 대기열 내) 또는 디스크
중 하나로 교체합니다.
기본 메시지 큐에 대한 기본 설정은 10,000개의 메시지 제한이 있는 FixedRegistryLogin 대기열입니다. 작업 대기열은 기본적으로 직접 큐로 설정됩니다.
직접 대기열
로컬 파일에 출력을 쓸 때와 같은 많은 간단한 작업의 경우 작업 앞에 큐를 빌드할 필요가 없습니다. 대기를 방지하려면 다음을 사용하십시오.
object(queue.type=”Direct”)
오브젝트 를 기본 메시지 대기열,작업
대기열 또는 규칙 세트에 사용하도록 main_queue
, action 또는 ruleset
로 바꿉니다. 직접 큐를 사용하면 생산자에서 소비자에게 즉시 메시지가 전달됩니다.
디스크 대기열
디스크 대기열은 하드 드라이브에 엄격하게 메시지를 저장하므로 높은 안정성과 가능한 모든 대기열 모드의 속도가 느려집니다. 이 모드를 사용하여 중요한 로그 데이터가 손실되지 않도록 할 수 있습니다. 그러나 대부분의 사용 사례에서는 디스크 큐를 사용하지 않는 것이 좋습니다. 디스크 큐를 설정하려면 /etc/journal.conf에 다음을 입력합니다.
object(queue.type=”Disk”)
오브젝트 를 기본 메시지 대기열,작업
대기열 또는 규칙 세트에 사용하도록 main_queue
, action 또는 ruleset
로 바꿉니다. 다음 구성 지시문을 사용하여 큐의 기본 크기를 수정할 수 있습니다.
object(queue.size=”size”)
여기서 크기는 지정된 디스크 큐 부분을 나타냅니다. 정의된 크기 제한은 제한적이지 않으며, 크기 제한을 위반하는 경우에도 rsyslog 는 항상 하나의 전체 대기열 항목을 씁니다. 디스크 큐의 각 부분은 개별 파일과 일치합니다. 이러한 파일에 대한 naming 지시문은 다음과 같습니다.
object(queue.filename=”name”)
이렇게 하면 파일의 이름 접두사와 한 파일에서 시작하여 각 파일에 대해 증가한 7자리 숫자가 설정됩니다.
object(queue.maxfilesize=”size”)
디스크 대기열은 기본 크기 1MB로 부분으로 작성됩니다. 다른 값을 사용할 크기를 지정합니다.
메모리 내 대기열
메모리 내 큐에서는 enqueued 메시지가 메모리에 유지되므로 프로세스가 매우 빠릅니다. 대기 중인 데이터는 컴퓨터가 전원을 순환하거나 종료되면 손실됩니다. 그러나 작업(queue.saveonshutdown="on")
설정을 사용하여 데이터를 종료하기 전에 저장할 수 있습니다. 메모리 내 큐에는 다음 두 가지 유형이 있습니다.
- Fixed array 큐 - 기본 메시지 큐의 기본 모드(값값이 10,000개)입니다. 이 유형의 큐는 큐 요소에 대한 포인터를 보유하는 고정 미리 할당된 배열을 사용합니다. 이러한 포인터로 인해 큐가 비어 있는 경우에도 일정 양의 메모리가 사용됩니다.Because to these pointers, even if the queue is empty a certain amount of memory is consumed. 그러나 FixedRegistryLogin은 최상의 런타임 성능을 제공하며 상대적으로 적은 수의 대기 메시지와 고성능을 기대할 때 최적입니다.
- LinkedList 큐 - 여기서 모든 구조는 연결된 목록에 동적으로 할당되므로 필요한 경우에만 메모리가 할당됩니다. LinkedList 대기열에서는 때때로 메시지 버스트가 매우 잘 작동합니다.
일반적으로 의심이 있을 때 LinkedList 큐를 사용하십시오. FixedRegistryLogin과 비교하여 메모리를 적게 사용하고 처리 오버헤드를 줄입니다.
메모리 내 대기열을 구성하려면 다음 구문을 사용합니다.
object(queue.type=”LinkedList”)
object(queue.type=”FixedArray”)
오브젝트 를 기본 메시지 대기열,작업
대기열 또는 규칙 세트에 사용하도록 main_queue
, action 또는 ruleset
로 바꿉니다.
디스크 지원 In-memory Queues
disk 및 in-memory 큐 모두 장점이 있으며 rsyslog 를 사용하면 디스크 지원 내부 대기열에서 이를 결합할 수 있습니다. 이를 위해 일반적인 메모리 내 대기열을 구성한 다음 queue.filename="file_name"
지시문을 해당 블록에 추가하여 디스크 지원을 위한 파일 이름을 정의합니다. 그런 다음 이 큐는 디스크 지원 대상이 됩니다. 즉, 메모리 내 대기열과 디스크 큐와 tandem이 작동합니다.
메모리 내 대기열이 가득 차거나 종료 후에도 유지되어야 하는 경우 디스크 대기열이 활성화됩니다. 디스크 지원 큐를 사용하면 디스크별 및 메모리 내 특정 구성 매개변수를 모두 설정할 수 있습니다. 이 유형의 큐는 가장 일반적으로 사용되는데, 잠재적으로 장기간 실행되거나 신뢰할 수 없는 작업에 유용합니다.
디스크 지원 내부 대기열의 기능을 지정하려면 so- called 워터마크를 사용합니다.
object(queue.highwatermark=”number”)
object(queue.lowwatermark=”number”)
오브젝트 를 기본 메시지 대기열,작업
대기열 또는 규칙 세트에 사용하도록 main_queue
, action 또는 ruleset
로 바꿉니다. 숫자를 여러 개의 큐에 있는 메시지로 바꿉니다. 메모리 내 대기열이 높은 워터마크에 의해 정의된 수에 도달하면 디스크에 메시지 쓰기를 시작하고 메모리 내 큐 크기가 낮은 워터마크로 정의된 수로 감소할 때까지 계속됩니다. 워터마크를 올바르게 설정하면 불필요한 디스크 쓰기를 최소화하지만 디스크 파일에 쓰기가 너무 길기 때문에 메시지 버스트도 메모리 공간을 남겨 둡니다. 따라서 높은 워터마크는 queue.size 로 설정된 전체 대기열 용량보다 작아야 합니다. 높은 워터마크와 전체 대기열 크기 간의 차이점은 메시지 버스트용으로 예약된 예비 메모리 버퍼입니다. 반면, 높은 워터마크를 너무 낮게 설정하면 불필요한 디스크 지원이 불필요하게 발생합니다.
예 23.12. 서버에 대한 로그 메시지의 안정적인 전달
rsyslog는 종종 로그 메시지가 네트워크를 통해 서버로 전달되는 중앙 집중식 로깅 시스템을 유지 관리하는 데 사용됩니다. 서버를 사용할 수 없는 경우 메시지 손실을 방지하려면 전달 작업에 대한 작업 큐를 구성하는 것이 좋습니다. 이렇게 하면 서버에 다시 연결할 때까지 전송되지 않은 메시지가 로컬로 저장됩니다. 이러한 대기열은 UDP
프로토콜을 사용하는 연결에 대해 구성할 수 없습니다.
단일 서버에 전달
이 작업은 시스템에서 호스트 이름 example.com 이 있는 서버로 로그 메시지를 전달하고 서버 중단 시 메시지를 버퍼링하도록 작업 큐를 구성하는 것입니다. 이렇게 하려면 다음 단계를 수행합니다.
/etc/journal.conf
에서 다음 구성을 사용하거나 /etc/journal.d/ 디렉토리에 다음 내용이 포함된 파일을 만듭니다.
. action(type=”omfwd” queue.type=”LinkedList” queue.filename=”example_fwd” action.resumeRetryCount="-1" queue.saveonshutdown="on" Target="example.com" Port="6514" Protocol="tcp")
다음과 같습니다.
-
queue.type
은 LinkedList in-memory 큐를 활성화합니다. -
queue.filename
은 디스크 스토리지를 정의합니다. 이 경우 backup 파일은 example_fwd 접두사가 있는/var/lib/journal/
디렉터리에 생성됩니다. -
action.resumeRetryCount= "-1"
설정을 사용하면 서버가 응답하지 않는 경우 연결을 다시 시도할 때 rsyslog가 메시지를 삭제하지 못하도록 합니다. -
enabled
queue.saveonshutdown
은 rsyslog가 종료되면 메모리 내 데이터를 저장합니다. 마지막 줄은 신뢰할 수 있는 TCP 전달을 사용하여 수신된 모든 메시지를 로깅 서버로 전달합니다. 포트 사양은 선택 사항입니다.
위의 구성을 통해 원격 서버에 연결할 수 없는 경우 rsyslog는 메모리에 메시지를 유지합니다. rsyslog가 구성된 메모리 대기열 공간이 부족하거나 종료해야 하는 경우에만 디스크의 파일이 생성되어 시스템 성능이 향상됩니다.
-
여러 서버에 전달
여러 서버에 로그 메시지를 전달하는 프로세스는 이전 절차와 유사합니다.
각 대상 서버에는 디스크에 별도의 전달 규칙, 작업 대기열 사양 및 백업 파일이 필요합니다. 예를 들어
/etc/journal.conf
에서 다음 구성을 사용하거나 /etc/journal.d/ 디렉토리에 다음 내용이 포함된 파일을 만듭니다.
. action(type=”omfwd” queue.type=”LinkedList” queue.filename=”example_fwd1” action.resumeRetryCount="-1" queue.saveonshutdown="on" Target="example1.com" Protocol="tcp") . action(type=”omfwd” queue.type=”LinkedList” queue.filename=”example_fwd2” action.resumeRetryCount="-1" queue.saveonshutdown="on" Target="example2.com" Protocol="tcp")
23.4.2. rsyslog 로그 파일용 새 디렉터리 생성
rsyslog는 syslogd
데몬으로 실행되며 SELinux에서 관리합니다. 따라서 rsyslog를 작성해야 하는 모든 파일에 적절한 SELinux 파일 컨텍스트가 있어야 합니다.
새 작업 디렉터리 생성
다른 디렉터리를 사용하여 작업 파일을 저장해야 하는 경우 다음과 같이 디렉터리를 생성합니다.
~]# mkdir
/rsyslog
SELinux 정책을 관리할 유틸리티를 설치합니다.
~]# yum install policycoreutils-python
SELinux 디렉터리 컨텍스트 유형을
/var/lib/journal/
디렉터리와 동일하게 설정합니다.~]# semanage fcontext -a -t syslogd_var_lib_t /rsyslog
SELinux 컨텍스트를 적용합니다.
~]# restorecon -R -v /rsyslog restorecon reset /rsyslog context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:syslogd_var_lib_t:s0
필요한 경우 다음과 같이 SELinux 컨텍스트를 확인합니다.
~]# ls -Zd /rsyslog drwxr-xr-x. root root system_u:object_r:syslogd_var_lib_t:s0 /rsyslog
필요한 경우 하위 디렉터리를 생성합니다. 예를 들면 다음과 같습니다.
~]# mkdir
/rsyslog/work/
하위 디렉터리는 상위 디렉터리와 동일한 SELinux 컨텍스트를 사용하여 생성됩니다.
다음을 적용하기 전에
/etc/journal.conf
에 다음 행을 추가하십시오.global(workDirectory=”/rsyslog/work”)
이 설정은 구성 파일을 구문 분석하는 동안 다음
WorkDirectory
지시문이 발생할 때까지 계속 적용됩니다.
23.4.3. 대기열 관리
모든 유형의 큐는 요구 사항에 맞게 추가로 구성할 수 있습니다. 여러 지시문을 사용하여 작업 대기열과 기본 메시지 큐를 모두 수정할 수 있습니다. 현재 사용 가능한 큐 매개변수는 20개 이상입니다. “온라인 문서” 을 참조하십시오. 이러한 설정 중 일부는 일반적으로 사용되며 작업자 스레드 관리와 같은 다른 설정은 큐 동작에 대한 더 가까운 제어 기능을 제공하며 고급 사용자를 위해 예약되어 있습니다. 고급 설정을 사용하면 rsyslog의 성능을 최적화하고 대기열을 예약하거나 시스템 종료 시 큐 동작을 수정할 수 있습니다.
대기열 크기 제한
다음 설정으로 큐에서 포함할 수 있는 메시지 수를 제한할 수 있습니다.
object(queue.highwatermark=”number”)
오브젝트 를 기본 메시지 대기열,작업
대기열 또는 규칙 세트에 사용하도록 main_queue
, action 또는 ruleset
로 바꿉니다. 숫자를 여러 개의 큐에 있는 메시지로 바꿉니다. 실제 메모리 크기가 아닌 메시지 수로만 큐 크기를 설정할 수 있습니다. 기본 큐 크기는 기본 메시지 큐 및 규칙 세트 큐에 대한 10,000개의 메시지이며 작업 큐의 경우 1000입니다.
디스크 지원 대기열은 기본적으로 무제한이며 이 지시문을 사용하여 제한할 수 없지만 다음과 같은 설정으로 물리적 디스크 공간을 바이트 단위로 예약할 수 있습니다.
object(queue.maxdiskspace=”number”)
오브젝트 를 main_queue
,action
또는 ruleset
으로 바꿉니다. number로 지정된 크기 제한이 히트되면 큐 메시지로 충분한 양의 공간을 확보할 때까지 메시지가 삭제됩니다.
메시지 삭제
대기열이 특정 수의 메시지에 도달하면 더 높은 우선순위의 항목에 대해 큐의 공간을 절약하기 위해 덜 중요한 메시지를 삭제할 수 있습니다. 삭제 프로세스를 시작하는 임계값은 so- called discard mark 로 설정할 수 있습니다.
object(queue.discardmark=”number”)
오브젝트 를 MainMsg
또는 Action
으로 교체하여 이 옵션을 기본 메시지 큐 또는 작업 대기열에 각각 사용합니다. 여기서 number 는 삭제 프로세스를 시작하기 위해 큐에 있어야 하는 여러 메시지를 나타냅니다. 삭제할 메시지를 정의하려면 다음을 사용합니다.
object(queue.discardseverity=”number”)
각 우선순위에 대해 숫자를 다음 숫자 중 하나로 교체합니다. 7
(debug), 6
(info), 5
(notice), 4
(warning), 3
(err), 2
(crit), 1
(alert), 0
(emerg) 이 설정을 사용하면 삭제 표시에 도달한 직후 대기열에서 새로 들어오고 이미 대기 중인 메시지가 모두 대기열에서 삭제됩니다.
Timeframes 사용
특정 기간 동안 대기열을 처리하도록 rsyslog 를 구성할 수 있습니다. 예를 들어 이 옵션을 사용하면 일부 처리를 사용량이 많은 시간으로 전송할 수 있습니다. 시간 프레임을 정의하려면 다음 구문을 사용합니다.
object(queue.dequeuetimebegin=”hour”)
object(queue.dequeuetimeend=”hour”)
시간 내에 시간 내에 바인딩된 시간을 지정할 수 있습니다. 분 없이 24시간 형식을 사용하십시오.
작업자 스레드 구성
작업자 스레드 는 큐에 있는 메시지에서 지정된 작업을 수행합니다. 예를 들어 기본 메시지 큐에서 작업자 작업은 들어오는 각 메시지에 필터 논리를 적용하고 관련 작업 큐에 큐에 추가하는 것입니다. 메시지가 도착하면 작업자 스레드가 자동으로 시작됩니다. 메시지 수가 특정 수에 도달하면 다른 작업자 스레드가 켜집니다. 이 번호를 지정하려면 다음을 사용합니다.
object(queue.workerthreadminimummessages=”number”)
번호를 추가 작업자 스레드를 트리거할 여러 메시지로 바꿉니다. 예를 들어 숫자가 100으로 설정된 경우 100개 이상의 메시지가 도착하면 새 작업자 스레드가 시작됩니다. 200개 이상의 메시지가 도착하면 세 번째 작업자 스레드가 시작됩니다. 그러나 병렬에서 실행 중인 너무 많은 작업 스레드는 비효율적이므로 다음을 사용하여 최대 수를 제한할 수 있습니다.
object(queue.workerthreads=”number”)
여기서 number 는 병렬로 실행할 수 있는 최대 작업 스레드 수를 나타냅니다. 기본 메시지 큐의 경우 기본 제한은 1 스레드입니다. 작업 중인 스레드가 시작되면 비활성 시간 제한이 표시될 때까지 계속 실행됩니다. 시간 제한을 설정하려면 다음을 입력합니다.
object(queue.timeoutworkerthreadshutdown=”time”)
시간을 밀리초에 설정된 기간으로 바꿉니다. 작업자 스레드를 종료한 후 새 메시지가 없는 시간을 지정합니다. 기본 설정은 1분입니다.
배치 종료
성능을 높이기 위해 한 번에 여러 개의 메시지를 큐에 적용하도록 rsyslog 를 구성할 수 있습니다. 이러한 대기열의 상한을 설정하려면 다음을 사용합니다.
$object(queue.DequeueBatchSize= ”number”)
number 를 한 번에 큐에 넣을 수 있는 최대 메시지 수로 바꿉니다. 많은 수의 허용된 작업 스레드와 결합된 설정이 늘어나면 메모리 소비가 증가합니다.
대기열 종료
메시지가 포함된 큐를 종료할 때 작업자 스레드가 큐 처리를 완료하는 데 시간 간격을 지정하여 데이터 손실을 최소화할 수 있습니다.
object(queue.timeoutshutdown=”time”)
시간 (밀리초)을 지정합니다. 이 기간 후에도 작업자는 현재 데이터 요소를 완료한 다음 종료됩니다. 처리되지 않은 메시지는 손실됩니다. 작업자에 대해 다른 시간 간격을 설정하여 최종 요소를 완료할 수 있습니다.
object(queue.timeoutactioncompletion=”time”)
이 시간 초과가 만료되면 나머지 작업자가 모두 종료됩니다. 종료 시 데이터를 저장하려면 다음을 사용합니다.
object(queue.saveonshutdown=”on”)
설정된 경우 rsyslog 가 종료되기 전에 모든 큐 요소가 디스크에 저장됩니다.
23.4.4. rsyslog 대기열용 New Syntax 사용
rsyslog 7에서 사용할 수 있는 새로운 구문에서 대기열은 action()
오브젝트 내부에 정의되어 있으며, 이 개체는 별도로 또는 /etc/journal.conf의 규칙 세트 내에서 사용할 수 있습니다.
작업 큐의 형식은 다음과 같습니다.
action(type="action_type "queue.size="queue_size" queue.type="queue_type" queue.filename="file_name"
action_type 을 작업을 수행하고 queue_size 를 큐에서 포함할 수 있는 최대 메시지 수로 교체합니다. queue_type 의 경우 디스크
를 선택하거나 메모리 내 대기열 중 하나를 선택합니다. direct
,linkedlist
또는 fixedarray
. file_name 의 경우 경로가 아닌 파일 이름만 지정합니다. 로그 파일을 저장할 새 디렉터리를 만드는 경우 SELinux 컨텍스트를 설정해야 합니다. 예제는 23.4.2절. “rsyslog 로그 파일용 새 디렉터리 생성” 을 참조하십시오.
예 23.13. 작업 대기열 정의
최대 10,000개의 메시지를 보유할 수 있는 비동기 링크 목록 기반 작업 큐를 사용하여 출력 작업을 구성하려면 다음과 같이 명령을 입력합니다.
action(type="omfile" queue.size="10000" queue.type="linkedlist" queue.filename="logfile")
직접 작업 대기열에 대한 rsyslog 7 구문은 다음과 같습니다.
. action(type="omfile" file="/var/lib/rsyslog/log_file )
여러 매개 변수가 있는 작업 대기열에 대한 rsyslog 7 구문은 다음과 같이 작성할 수 있습니다.
. action(type="omfile" queue.filename="log_file" queue.type="linkedlist" queue.size="10000" )
기본 작업 디렉터리 또는 설정할 마지막 작업 디렉터리가 사용됩니다. 다른 작업 디렉터리를 사용해야 하는 경우 작업 큐보다 먼저 행을 다음과 같이 추가합니다.
global(workDirectory="/directory")
예 23.14. 새 구문을 사용하여 단일 서버에 전달
다음 예제는 기존 sysntax와 rsyslog 7 구문의 차이점을 표시하기 위해 단일 서버에 전달 절차를 기반으로 합니다. omfwd
플러그인은 UDP
또는 TCP
를 통해 전달을 제공하는 데 사용됩니다. 기본값은 UDP
입니다. 플러그인이 내장되어 있으므로 로드할 필요가 없습니다.
/etc/journal.conf
에서 다음 구성을 사용하거나 / etc/journal.d/ 디렉토리에 다음 내용이 포함된 파일을 만듭니다.
. action(type="omfwd"
queue.type="linkedlist"
queue.filename="example_fwd"
action.resumeRetryCount="-1"
queue.saveOnShutdown="on"
target="example.com" port="6514" protocol="tcp"
)
다음과 같습니다.
-
queue.type="linkedlist"
는 LinkedList in-memory 큐를 활성화합니다. -
queue.filename
은 디스크 스토리지를 정의합니다. 이전 글로벌workDirectory
지시문으로 지정된 작업 디렉터리에서 example_fwd 접두사를 사용하여 백업 파일이 생성됩니다. -
action.resumeRetryCount -1
설정은 서버가 응답하지 않는 경우 연결을 다시 시도할 때 rsyslog가 메시지를 삭제하지 못하도록 합니다. -
enabled
queue.saveOnShutdown="on"
은 rsyslog가 종료되면 메모리 내 데이터를 저장합니다. - 마지막 줄은 수신된 모든 메시지를 로깅 서버로 전달하며 포트 사양은 선택 사항입니다.
23.5. 로깅 서버에서 rsyslog 구성
rsyslog
서비스는 로깅 서버를 실행하고 개별 시스템을 구성하여 로그 파일을 로깅 서버로 보내는 기능을 모두 제공합니다. 클라이언트 rsyslog
구성에 대한 자세한 내용은 예 23.12. “서버에 대한 로그 메시지의 안정적인 전달” 을 참조하십시오.
rsyslog
서비스는 로깅 서버로 사용할 시스템과 로그를 전송하도록 구성할 모든 시스템에 설치해야 합니다. rsyslog는 Red Hat Enterprise Linux 7에 기본적으로 설치됩니다. 필요한 경우 root
로 다음 명령을 입력합니다.
~]# yum install rsyslog
syslog 트래픽의 기본 프로토콜 및 포트는 /etc/services
파일에 나열된 UDP
및 514
입니다. 그러나 rsyslog
는 기본적으로 포트 514
에서 TCP
를 사용합니다. 구성 파일에서 /etc/journal.conf
는TCP
가 @@로 표시됩니다
.
다른 포트는 예제에 사용되지만 SELinux는 기본적으로 다음 포트에서 전송 및 수신을 허용하도록 구성됩니다.
~]# semanage port -l | grep syslog syslog_tls_port_t tcp 6514, 10514 syslog_tls_port_t udp 6514, 10514 syslogd_port_t tcp 601, 20514 syslogd_port_t udp 514, 601, 20514
semanage
유틸리티는 policycoreutils-python 패키지의 일부로 제공됩니다. 필요한 경우 다음과 같이 패키지를 설치합니다.
~]# yum install policycoreutils-python
또한 기본적으로 rsyslog
에 대한 SELinux 유형인rsyslogd_t
는 SELinux 유형rsh
_ port_t
를 사용하여 원격 쉘( rsh ) 포트로 전송 및 수신을 허용하도록 구성되어 있으며, 포트 514
에서 기본적으로 TCP
로 설정됩니다. 따라서 포트 514
에서 TCP
를 명시적으로 허용하기 위해 semanage
를 사용할 필요가 없습니다. 예를 들어 포트 514
에서 허용되도록 SELinux가 설정되어 있는지 확인하려면 다음과 같이 명령을 입력합니다.
~]# semanage port -l | grep 514
output omitted
rsh_port_t tcp 514
syslogd_port_t tcp 6514, 601
syslogd_port_t udp 514, 6514, 601
SELinux에 대한 자세한 내용은 Red Hat Enterprise Linux 7 SELinux 사용자 및 관리자 가이드를 참조하십시오.
로깅 서버로 사용하려는 시스템에서 다음 절차의 단계를 수행합니다. 이러한 절차의 모든 단계는 root
사용자로 수행해야 합니다.
포트에서 rsyslog 트래픽을 허용하도록 SELinux 구성
rsyslog
트래픽에 새 포트를 사용해야 하는 경우 로깅 서버 및 클라이언트에서 다음 절차를 따르십시오. 예를 들어 포트 10514
에서 TCP
트래픽을 전송하고 수신하려면 다음 일련의 명령을 진행합니다.
다음 매개 변수를 사용하여
semanage port
명령을 실행합니다.~]# semanage port -a -t syslogd_port_t -p tcp 10514
다음 명령을 입력하여 SELinux 포트를 검토합니다.
~]# semanage port -l | grep syslog
새 포트가
/etc/journal.conf
에 이미 구성된 경우 변경 사항을 적용하려면rsyslog
를 다시 시작하십시오.~]# service rsyslog restart
rsyslog
가 현재 수신 대기 중인 포트를 확인합니다.~]# netstat -tnlp | grep rsyslog tcp 0 0 0.0.0.0:10514 0.0.0.0:* LISTEN 2528/rsyslogd tcp 0 0 :::10514 :::* LISTEN 2528/rsyslogd
semanage port
명령에 대한 자세한 내용은 semanage-port(8)
매뉴얼 페이지를 참조하십시오.
firewalld 구성
들어오는 rsyslog
트래픽을 허용하도록 firewalld
를 구성합니다. 예를 들어 포트 10514
에서 TCP
트래픽을 허용하려면 다음과 같이 진행하십시오.
~]# firewall-cmd --zone=zone --add-port=10514/tcp success
여기서 zone 은 사용할 인터페이스의 영역입니다. 이러한 변경 사항은 다음 시스템을 시작한 후에도 유지되지 않습니다. 방화벽을 영구적으로 변경하려면 --permanent
옵션을 추가하는 명령을 반복합니다. firewalld
에서 포트 열기 및 닫기에 대한 자세한 내용은 Red Hat Enterprise Linux 7 보안 가이드 를 참조하십시오.
위 설정을 확인하려면 다음과 같이 명령을 사용합니다.
~]# firewall-cmd --list-all public (default, active) interfaces: eth0 sources: services: dhcpv6-client ssh ports: 10514/tcp masquerade: no forward-ports: icmp-blocks: rich rules:
원격 로그 메시지를 수신 및 정렬하도록 rsyslog 구성
텍스트 편집기에서
/etc/journal.conf
파일을 열고 다음과 같이 진행합니다.모듈 섹션 아래에 다음 행을 추가하십시오. 이 섹션 위에
UDP syslog 수신 제공
섹션은 다음과 같습니다.# Define templates before the rules that use them # Per-Host Templates for Remote Systems # $template TmplAuthpriv, "/var/log/remote/auth/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log" $template TmplMsg, "/var/log/remote/msg/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log"
기본
제공 TCP syslog 수신
섹션을 다음으로 바꿉니다.# Provides TCP syslog reception $ModLoad imtcp # Adding this ruleset to process remote messages $RuleSet remote1 authpriv.* ?TmplAuthpriv *.info;mail.none;authpriv.none;cron.none ?TmplMsg $RuleSet RSYSLOG_DefaultRuleset #End the rule set by switching back to the default rule set $InputTCPServerBindRuleset remote1 #Define a new input and bind it to the "remote1" rule set $InputTCPServerRun 10514
/etc/journal.conf
파일에 변경 사항을 저장합니다.
rsyslog
서비스는 로깅 서버와 이 서버에 로깅하려는 시스템에서 모두 실행되고 있어야 합니다.systemctl
명령을 사용하여rsyslog
서비스를 시작합니다.~]#
systemctl start rsyslog
나중에
rsyslog
서비스가 자동으로 시작되도록 하려면 root로 다음 명령을 입력합니다.~]#
systemctl enable rsyslog
이제 로그 서버가 사용자 환경의 다른 시스템에서 로그 파일을 수신하고 저장하도록 구성되어 있습니다.
23.5.1. 로깅 서버에서 새 템플릿 구문 사용
rsyslog 7에는 다양한 템플릿 스타일이 있습니다. 문자열 템플릿은 레거시 형식과 가장 근접하게 유사합니다. 문자열 형식을 사용하여 위 예제에서 템플릿을 재현하는 것은 다음과 같습니다.
template(name="TmplAuthpriv" type="string" string="/var/log/remote/auth/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log" ) template(name="TmplMsg" type="string" string="/var/log/remote/msg/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log" )
이러한 템플릿은 다음과 같이 목록 형식으로 작성할 수도 있습니다.
template(name="TmplAuthpriv" type="list") { constant(value="/var/log/remote/auth/") property(name="hostname") constant(value="/") property(name="programname" SecurePath="replace") constant(value=".log") } template(name="TmplMsg" type="list") { constant(value="/var/log/remote/msg/") property(name="hostname") constant(value="/") property(name="programname" SecurePath="replace") constant(value=".log") }
이 템플릿 텍스트 형식은 rsyslog에 대한 새로운 기능에 대해 더 쉽게 읽을 수 있으므로 요구 사항 변화에 따라 보다 쉽게 적응할 수 있습니다.
새 구문 변경을 완료하려면 모듈 load 명령을 재현하고, 규칙 세트를 추가한 다음, 프로토콜, 포트, 규칙 세트에 바인딩해야 합니다.
module(load="imtcp") ruleset(name="remote1"){ authpriv.* action(type="omfile" DynaFile="TmplAuthpriv") *.info;mail.none;authpriv.none;cron.none action(type="omfile" DynaFile="TmplMsg") } input(type="imtcp" port="10514" ruleset="remote1")
23.6. Rsyslog 모듈 사용
모듈식 설계로 인해 rsyslog 는 추가 기능을 제공하는 다양한 모듈을 제공합니다. 모듈은 타사에서 작성할 수 있습니다. 대부분의 모듈은 추가 입력(아래 입력 모듈 참조) 또는 출력을 제공합니다(아래 출력 모듈 참조). 다른 모듈은 각 모듈에 특정 기능을 제공합니다. 모듈은 모듈이 로드된 후 사용할 수 있게 되는 추가 구성 지시문을 제공할 수 있습니다. 모듈을 로드하려면 다음 구문을 사용합니다.
module(load=”MODULE”)
여기서 MODULE 은 원하는 모듈을 나타냅니다. 예를 들어 rsyslog 가 표준 텍스트 파일을 syslog 메시지로 변환할 수 있는 텍스트 파일 입력 모듈(imfile
)을 로드하려면 /etc/journal.conf 구성 파일에 다음 행을 지정하십시오.
module(load=”imfile”)
rsyslog 는 다음과 같은 주요 카테고리로 구분된 여러 모듈을 제공합니다.
-
입력 모듈 - 입력 모듈은 다양한 소스에서 메시지를 수집합니다. 입력 모듈의 이름은 항상
imfile
및im
journal -
출력 모듈 - 출력 모듈은 네트워크를 통해 전송, 데이터베이스에 저장 또는 암호화와 같은 다양한 대상으로 메시지를 발행하는 기능을 제공합니다. 출력 모듈의 이름은 항상
omsnmp
,
omrelp
등과 같은 om 접두사로 시작합니다. -
parser 모듈 - 이 모듈은 사용자 정의 구문 분석 규칙을 생성하거나 잘못된 형식의 메시지를 구문 분석하는 데 유용합니다. C 프로그래밍 언어에 대한 중간 지식을 사용하면 자체 메시지 구문 분석기를 만들 수 있습니다. 구문 분석 모듈의 이름은 항상
pm
rfc5424pmrfc3164
등과 같은 pm 접두사로 시작합니다. -
메시지 수정 모듈 - 메시지 수정 모듈은 syslog 메시지의 내용을 변경합니다. 이러한 모듈의 이름은
mm
접두사로 시작합니다.mmanon
,mmnormalize
또는mmjsonparse
와 같은 메시지 수정 모듈은 메시지의 익명화 또는 정규화에 사용됩니다. -
문자열 생성기 모듈 - 문자열 생성기 모듈은 메시지 콘텐츠를 기반으로 문자열을 생성하고 rsyslog 가 제공하는 템플릿 기능과 강력히 협력합니다. 템플릿에 대한 자세한 내용은 23.2.3절. “템플릿” 을 참조하십시오. 문자열 생성기 모듈의 이름은 항상
sm
접두사(예:smfile
또는smtradfile
)로 시작합니다. - 라이브러리 모듈 - 라이브러리 모듈은 다른 로드 가능한 모듈에 대한 기능을 제공합니다. 이러한 모듈은 필요한 경우 rsyslog 에 의해 자동으로 로드되며 사용자가 구성할 수 없습니다.
사용 가능한 모든 모듈 및 자세한 설명은 http://www.rsyslog.com/doc/rsyslog_conf_modules.html 에서 확인할 수 있습니다.
rsyslog 가 모듈을 로드할 때 일부 기능과 데이터에 대한 액세스 권한을 제공합니다. 이로 인해 보안 취약점이 발생할 수 있습니다. 보안 위험을 최소화하기 위해 신뢰할 수 있는 모듈만 사용하십시오.
23.6.1. 텍스트 파일 가져오기
imfile
로 축약된 텍스트 파일 입력 모듈을 사용하면 rsyslog 가 모든 텍스트 파일을 syslog 메시지 스트림으로 변환할 수 있습니다. imfile
을 사용하여 자체 텍스트 파일 로그를 생성하는 애플리케이션에서 로그 메시지를 가져올 수 있습니다. imfile
을 로드하려면 /etc/journal.conf에 다음을 추가합니다.
module(load=”imfile” PollingInterval=”int”)
여러 파일을 가져올 때에도 imfile
을 한 번 로드하는 것으로 충분합니다. PollingInterval 모듈 인수는 rsyslog 가 연결된 텍스트 파일의 변경 사항을 확인하는 빈도를 지정합니다. 기본 간격은 10초이며, 이를 변경하려면 int 를 초 단위로 지정된 시간 간격으로 바꿉니다.
가져올 텍스트 파일을 식별하려면 /etc/journal.conf에서 다음 구문을 사용하십시오.
# File 1 input(type="imfile" File="path_to_file" Tag="tag:" Severity="severity" Facility="facility") # File 2 input(type="imfile" File="path_to_file2") ...
입력 텍스트 파일을 지정하는 데 필요한 설정:
- path_to_file 을 텍스트 파일의 경로로 바꿉니다.
- tag: 를 이 메시지의 태그 이름으로 바꿉니다.
필수 지시문 외에도 텍스트 입력에 적용할 수 있는 몇 가지 다른 설정이 있습니다. 심각도를 적절한 키워드로 교체하여 가져온 메시지의 심각도 를 설정합니다. 기능을 키워드로 교체하여 메시지를 생성한 하위 시스템을 정의합니다. 심각도 및 기능에 대한 키워드는 기능/우선 우선 순위 기반 필터에서 사용되는 항목과 동일합니다. 23.2.1절. “filters”
예 23.15. 텍스트 파일 가져오기
Apache HTTP 서버는 텍스트 형식으로 로그 파일을 생성합니다. rsyslog 의 처리 기능을 Apache 오류 메시지에 적용하려면 먼저 imfile
모듈을 사용하여 메시지를 가져옵니다. 다음을 /etc/journal.conf에 추가하십시오.
module(load=”imfile”) input(type="imfile" File="/var/log/httpd/error_log" Tag="apache-error:")
23.6.2. 데이터베이스로 메시지 내보내기
텍스트 파일이 아닌 데이터베이스에서 로그 데이터를 처리하는 것이 더 빠르고 편리해질 수 있습니다. 사용된 DBMS 유형에 따라 ommysql
,ompgsql
,omoracle
또는 ommongodb
와 같은 다양한 출력 모듈 중에서 선택합니다. 또는 libdbi
라이브러리를 사용하는 일반 omlibdbi
출력 모듈을 사용합니다. omlibdbi
모듈은 데이터베이스 시스템 firebird/Interbase, MS SQL, Sybase, SQLite, Oracle, mSQL, MySQL, PostgreSQL을 지원합니다.
예 23.16. 데이터베이스로 Rsyslog messages 내보내기
rsyslog 메시지를 MySQL 데이터베이스에 저장하려면 /etc/journal.conf에 다음을 추가합니다.
module(load=”ommysql”)
. action(type”ommysql”
server=”database-server”
db=”database-name”
uid=”database-userid”
pwd=”database-password”
serverport=”1234”)
먼저 output 모듈이 로드되면 통신 포트가 지정됩니다. 서버 이름 및 데이터베이스 및 인증 데이터와 같은 추가 정보는 위의 예의 마지막 줄에 지정됩니다.
23.6.3. 암호화된 전송 활성화
네트워크 전송의 기밀성 및 무결성은 TLS 또는 GSSAPI 암호화 프로토콜을 통해 제공할 수 있습니다.
TLS( Transport Layer Security )는 네트워크를 통해 통신 보안을 제공하도록 설계된 암호화 프로토콜입니다. TLS를 사용하는 경우 rsyslog 메시지는 전송 전에 암호화되며 발신자와 수신자 간에 상호 인증이 있습니다. TLS 구성은 “TLS로 암호화된 메시지 전송 구성” 에서 참조하십시오.
GSSAPI( Generic Security Service API )는 프로그램이 보안 서비스에 액세스할 수 있는 애플리케이션 프로그래밍 인터페이스입니다. rsyslog 와 관련하여 이를 사용하려면 Kerberos 환경이 작동해야 합니다. GSSAPI 구성은 “GSSAPI를 사용하여 암호화된 메시지 전송 구성” 에서 참조하십시오.
TLS로 암호화된 메시지 전송 구성
TLS를 통해 암호화된 전송을 사용하려면 서버와 클라이언트 모두를 구성해야 합니다.
- 공개 키, 개인 키 및 인증서 파일을 만들려면 14.1.11절. “새 키 및 인증서 생성” 를 참조하십시오.
서버 측에서
/etc/journal.conf 구성 파일에 다음을 구성합니다.
gtls netstream 드라이버를 기본 드라이버로 설정합니다.
global(defaultnetstreamdriver="gtls")
인증서 파일에 경로를 제공합니다.
global(defaultnetstreamdrivercafile="path_ca.pem" defaultnetstreamdrivercertfile="path_cert.pem" defaultnetstreamdriverkeyfile="path_key.pem")
더 적은 cluttered 구성 파일을 선호하는 경우 모든 글로벌 지시문을 단일 블록에 병합할 수 있습니다.
교체:
- 공개 키의 경로가 있는 path_ca.pem
- certificate 파일 경로가 있는 path_cert.pem
- 개인 키 경로가 있는 path_key.pem
imtcp 모듈을 로드하고 드라이버 옵션을 설정합니다.
module(load=”imtcp” StreamDriver.Mode=“number” StreamDriver.AuthMode=”anon”)
서버를 시작합니다.
input(type="imtcp" port="port″)
교체:
-
드라이버 모드를 지정할 수 있습니다. TCP 전용 모드를 활성화하려면
1
을 사용합니다. 리스너를 시작할 포트 번호가 있는 포트 번호 (예:
10514)
anon
설정은 클라이언트가 인증되지 않았음을 의미합니다.
-
드라이버 모드를 지정할 수 있습니다. TCP 전용 모드를 활성화하려면
클라이언트 측에서
/etc/journal.conf 구성 파일에 다음을 구성합니다.
공개 키를 로드합니다.
global(defaultnetstreamdrivercafile="path_ca.pem")
path_ca.pem 을 공개 키의 경로로 바꿉니다.
gtls netstream 드라이버를 기본 드라이버로 설정합니다.
global(defaultnetstreamdriver="gtls")
드라이버를 구성하고 수행할 작업을 지정합니다.
module(load=”imtcp” streamdrivermode=”number” streamdriverauthmode=”anon”) input(type=”imtcp” address=”server.net” port=”port”)
번호,anon, port 를 서버에서와 동일한 값으로 바꿉니다.
위 목록의 마지막 행에서 예제 작업은 서버에서 지정된 TCP 포트로 메시지를 전달합니다.
GSSAPI를 사용하여 암호화된 메시지 전송 구성
rsyslog 에서 GSSAPI와의 상호 작용은 imgssapi 모듈에서 제공합니다. GSSAPI 전송 모드를 활성화하려면 다음을 수행합니다.
/etc/journal.conf에 다음 구성을 배치합니다.
$ModLoad imgssapi
이 지시문은 imgssapi 모듈을 로드합니다.
다음과 같이 입력을 지정합니다.
$InputGSSServerServiceName name $InputGSSServerPermitPlainTCP
on
$InputGSSServerMaxSessions number $InputGSSServerRun port- name 을 GSS 서버의 이름으로 바꿉니다.
- 번호를 교체하여 지원되는 최대 세션 수를 설정합니다. 이 수는 기본적으로 제한되지 않습니다.
GSS 서버를 시작할 선택한 포트로 포트를 바꿉니다.
설정의
$InputGSSServerPermitPlainTCP
는 서버가 동일한 포트에서 일반 TCP 메시지를 수신할 수 있도록 허용합니다. 이는 기본적으로 꺼져 있습니다.
구성 파일 판독기가 /etc/journal.conf
구성 파일에 $InputGSSServerRun 지시문이 발생하면 imgssapi
모듈이 초기화됩니다. 따라서 $InputGSSServerRun 후에 구성된 보조 옵션은 무시됩니다. 구성을 적용하려면 $InputGSSServerRun 전에 모든 imgssapi 구성 옵션을 배치해야합니다.
예 23.17. GSSAPI 사용
다음 구성을 사용하면 동일한 포트에서 일반 tcp syslog 메시지를 수신할 수도 있는 포트 1514에서 GSS 서버를 사용할 수 있습니다.
$ModLoad imgssapi $InputGSSServerPermitPlainTCP on $InputGSSServerRun 1514
23.6.4. RELP 사용
RELP( Reliable Event Logging Protocol )는 컴퓨터 네트워크에서 데이터 로깅을 위한 네트워킹 프로토콜입니다. 이벤트 메시지의 안정적인 전달을 제공하도록 설계되었으므로 메시지 손실을 허용하지 않는 환경에서 유용합니다.
RELP 구성
RELP를 구성하려면 /etc/journal.conf
파일을 사용하여 서버와 클라이언트 모두를 구성해야 합니다.
클라이언트를 구성하려면 다음을 수행합니다.
필요한 모듈을 로드합니다.
module(load="imuxsock") module(load="omrelp") module(load="imtcp")
TCP 입력을 다음과 같이 구성합니다.
input(type="imtcp" port="port″)
필요한 포트에서 리스너를 시작하려면 포트를 교체합니다.
전송 설정을 구성합니다.
action(type="omrelp" target="target_IP″ port="target_port″)
target_IP 및 target_port 를 대상 서버를 식별하는 IP 주소 및 포트로 바꿉니다.
서버를 구성하려면 다음을 수행합니다.
모듈 로드를 구성합니다.
module(load="imuxsock") module(load="imrelp" ruleset="relp")
클라이언트 구성과 유사하게 TCP 입력을 구성합니다.
input(type="imrelp" port="target_port″)
target_port 를 클라이언트에서와 동일한 값으로 바꿉니다.
규칙을 구성하고 수행할 작업을 선택합니다. 다음 예제에서 log_path 는 메시지 저장 경로를 지정합니다.
ruleset (name="relp") { action(type="omfile" file="log_path") }
TLS를 사용하여 RELP 구성
TLS를 사용하여 RELP를 구성하려면 인증을 구성해야 합니다. 그런 다음 /etc/journal.conf
파일을 사용하여 서버와 클라이언트를 모두 구성해야 합니다.
- 공개 키, 개인 키 및 인증서 파일을 만듭니다. 자세한 내용은 14.1.11절. “새 키 및 인증서 생성”에서 참조하십시오.
클라이언트를 구성하려면 다음을 수행합니다.
필요한 모듈을 로드합니다.
module(load="imuxsock") module(load="omrelp") module(load="imtcp")
TCP 입력을 다음과 같이 구성합니다.
input(type="imtcp" port="port″)
필요한 포트에서 리스너를 시작하려면 포트를 교체합니다.
전송 설정을 구성합니다.
action(type="omrelp" target="target_IP″ port="target_port″ tls="on" tls.caCert="path_ca.pem" tls.myCert="path_cert.pem" tls.myPrivKey="path_key.pem" tls.authmode="mode" tls.permittedpeer=["peer_name"] )
교체:
- 대상 서버를 식별하는 IP 주소 및 포트가 있는 target_IP 및 target_port 입니다.
- path_ca.pem,path_cert.pem, path_key.pem 및 인증 파일 경로가 있는 path_ca.pem
- 트랜잭션의 인증 모드가 있는 모드입니다. "name" 또는 "fingerprint"를 사용합니다.
허용된 피어의 인증서 지문이 있는 peer_name. 이를 지정하면
tls.permittedpeer
가 선택한 피어 그룹에 대한 연결을 제한합니다.tls="on" 설정은 TLS 프로토콜을 활성화합니다.
서버를 구성하려면 다음을 수행합니다.
모듈 로드를 구성합니다.
module(load="imuxsock") module(load="imrelp" ruleset="relp")
클라이언트 구성과 유사하게 TCP 입력을 구성합니다.
input(type="imrelp" port="target_port″ tls="on" tls.caCert="path_ca.pem" tls.myCert="path_cert.pem" tls.myPrivKey="path_key.pem" tls.authmode="name" tls.permittedpeer=["peer_name","peer_name1","peer_name2"] )
강조 표시된 값을 클라이언트에서와 동일하게 바꿉니다.
규칙을 구성하고 수행할 작업을 선택합니다. 다음 예제에서 log_path 는 메시지 저장 경로를 지정합니다.
ruleset (name="relp") { action(type="omfile" file="log_path") }
23.7. Rsyslog 및 journal의 상호 작용
위에서 언급한 것처럼, Rsyslog 및 journal 는 시스템에 존재하는 두 가지 로깅 애플리케이션이 특정 사용 사례에 적합하게 만드는 몇 가지 고유한 기능을 보유하고 있습니다. 예를 들어 구조화된 메시지를 생성하여 파일 데이터베이스에 저장하는 등 기능을 결합하는 것이 유용합니다( 23.8절. “Rsyslog를 사용한 구조화된 로깅”참조). 이러한 협력에 필요한 통신 인터페이스는 Rsyslog 측면과 journal의 통신 소켓에 입력 및 출력 모듈을 통해 제공됩니다.
기본적으로 rsyslogd
는 imjournal
모듈을 저널 파일의 기본 입력 모드로 사용합니다. 이 모듈을 사용하면 journald
에서 제공하는 구조화된 데이터뿐만 아니라 메시지도 가져옵니다. 또한 오래된 데이터는 journald
에서 가져올 수 있습니다 ( IgnorePreviousMessages
옵션을 사용하지 않는 한). imjournal
의 기본 설정은 23.8.1절. “journal에서 데이터 가져오기” 을 참조하십시오.
또는 저널
에서 제공하는 소켓에서 syslog 기반 애플리케이션의 출력으로 읽도록 rsyslogd
를 구성합니다. 소켓 경로는 /run/systemd/journal/syslog
입니다. 일반 rsyslog 메시지를 유지하려는 경우 이 옵션을 사용합니다. 소켓 입력을 imjournal
에 비해 현재 규칙 집합 바인딩 또는 필터링과 같은 더 많은 기능을 제공합니다. socket으로 된 journal 데이터를 가져오려면 /etc/journal.conf에서 다음 구성을 사용하십시오.
module(load="imuxsock" SysSock.Use="on" SysSock.Name="/run/systemd/journal/syslog")
omjournal
모듈을 사용하여 Rsyslog 의 메시지를 journal 로 출력할 수도 있습니다. 다음과 같이 /etc/journal.conf
에서 출력을 구성합니다.
module(load="omjournal") action(type="omjournal")
예를 들어 다음 구성은 tcp 포트 10514에서 수신된 모든 메시지를 journal로 전달합니다.
module(load="imtcp") module(load="omjournal") ruleset(name="remote") { action(type="omjournal") } input(type="imtcp" port="10514" ruleset="remote")
23.8. Rsyslog를 사용한 구조화된 로깅
대량의 로그 데이터를 생성하는 시스템에서는 구조화된 형식으로 로그 메시지를 유지 관리하는 것이 편리합니다. 구조화된 메시지를 사용하면 특정 정보를 검색하고 통계를 생성하며 메시지 구조의 변경 사항 및 불일치에 대처하는 것이 더 쉬워집니다. rsyslog는 JSON (JavaScript Object Notation) 형식을 사용하여 로그 메시지에 대한 구조를 제공합니다.
다음 구조화되지 않은 로그 메시지를 비교합니다.
Oct 25 10:20:37 localhost anacron[1395]: Jobs will be executed sequentially
구조화된 것과 함께 다음을 수행합니다.
{"timestamp":"2013-10-25T10:20:37", "host":"localhost", "program":"anacron", "pid":"1395", "msg":"Jobs will be executed sequentially"}
키-값 쌍을 사용하여 구조화된 데이터를 검색하는 것이 정규식으로 텍스트 파일을 검색하는 것보다 빠르고 정확합니다. 또한 이 구조를 통해 다양한 애플리케이션에서 생성되는 메시지에서 동일한 항목을 검색할 수 있습니다. 또한 JSON 파일은 추가 성능 및 분석 기능을 제공하는 MongoDB와 같은 문서 데이터베이스에 저장할 수 있습니다. 반면 구조화된 메시지에는 구조화되지 않은 메시지보다 더 많은 디스크 공간이 필요합니다.
rsyslog 에서 메타 데이터가 있는 로그 메시지는 imjournal
모듈을 사용하여 journal 에서 가져옵니다. mmjsonparse
모듈을 사용하면 journal 에서 가져온 데이터를 구문 분석하고 다른 소스에서 데이터를 구문 분석하고 데이터베이스 출력과 같이 추가로 처리할 수 있습니다. 구문 분석 성공의 경우 mmjsonparse
는 Lumberjack 프로젝트에서 정의하는 방식으로 입력 메시지를 구조화해야 합니다.
Lumberjack 프로젝트는 이전 버전과 호환되는 방식으로 rsyslog 에 구조화된 로깅을 추가하는 것을 목표로 합니다. 구조화된 메시지를 식별하기 위해 Lumberjack 은 실제 JSON 구조 앞에 추가되는 @cee: 문자열을 지정합니다. 또한 Lumberjack 은 JSON 문자열의 엔터티에 사용해야 하는 표준 필드 이름 목록을 정의합니다. Lumberjack 에 대한 자세한 내용은 “온라인 문서” 를 참조하십시오.
다음은 lumberjack 형식의 메시지의 예입니다.
@cee: {"pid":17055, "uid":1000, "gid":1000, "appname":"logger", "msg":"Message text."}
Rsyslog 내에서 이 구조를 빌드하려면 템플릿이 사용됩니다. 23.8.2절. “구조화된 메시지 필터링” 을 참조하십시오. 애플리케이션 및 서버는 libumberlog
라이브러리를 사용하여 lumberjack 호환 형식으로 메시지를 생성할 수 있습니다. libumberlog
에 대한 자세한 내용은 “온라인 문서” 을 참조하십시오.
23.8.1. journal에서 데이터 가져오기
imjournal
모듈은 기본적으로 저널 파일을 읽는 Rsyslog의 입력 모듈입니다( 23.7절. “Rsyslog 및 journal의 상호 작용”참조). 그런 다음 journal 메시지는 다른 rsyslog 메시지로 텍스트 형식으로 기록됩니다. 그러나 추가 처리에서는 journal에서 제공하는 메타 데이터를 구조화된 메시지로 변환할 수 있습니다.
journal 에서 Rsyslog 로 데이터를 가져오려면 /etc/journal.conf에서 다음 구성을 사용하십시오.
module(load=”imjournal” PersistStateInterval=”number_of_messages” StateFile=”path” ratelimit.interval=”seconds” ratelimit.burst=”burst_number” IgnorePreviousMessages=”off/on”)
- number_of_message 를 사용하면 저널 데이터를 저장해야 하는 빈도를 지정할 수 있습니다. 이 문제는 지정된 수의 메시지에 도달할 때마다 발생합니다.
- 경로를 상태 파일의 경로로 바꿉니다. 이 파일은 마지막 처리된 저널 항목을 추적합니다.
- 초 단위로 제한 간격의 길이를 설정합니다. 이 간격 중에 처리되는 메시지 수는 burst_number 에 지정된 값을 초과할 수 없습니다. 기본 설정은 600초당 20,000개의 메시지입니다. rsyslog는 지정된 시간 내에 최대 버스트 뒤에 오는 메시지를 삭제합니다.
-
IgnorePreviousMessages
를 사용하면 현재 journal에 있는 메시지를 무시하고 상태 파일이 지정되지 않은 경우 사용되는 새 메시지만 가져올 수 있습니다. 기본 설정은OFF
입니다. 이 설정이 꺼져 있고 상태 파일이 없는 경우 이전 rsyslog 세션에서 이미 처리되어도 저널의 모든 메시지가 처리됩니다.
기존 시스템 로그 입력인 imuxsock
모듈과 동시에 imjournal
을 사용할 수 있습니다. 그러나 메시지 중복을 방지하려면 imuxsock
에서 journal의 시스템 소켓을 읽지 못하도록 해야 합니다. 이를 위해 SysSock.Use
지시문을 사용합니다.
module(load”imjournal”) module(load”imuxsock” SysSock.Use=”off” Socket="/run/systemd/journal/syslog")
journal에서 저장한 모든 데이터와 메타 데이터를 구조화된 메시지로 변환할 수 있습니다. 이러한 메타 데이터 항목 중 일부는 예 23.19. “자세한 journalctl 출력” 에 나열되며 저널 필드의 전체 목록은 systemd.journal-fields(7)
매뉴얼 페이지를 참조하십시오. 예를 들어 커널에서 시작되는 메시지에서 사용하는 커널 저널 필드에 중점을 둘 수 있습니다.
23.8.2. 구조화된 메시지 필터링
rsyslog의 구문 분석 모듈에 필요한 lumberjack 형식의 메시지를 생성하려면 다음 템플릿을 사용합니다.
template(name="CEETemplate" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag% @cee: %$!all-json%\n")
이 템플릿은 @cee:
문자열을 JSON 문자열 앞에 추가하고, 예를 들어 omfile
모듈을 사용하여 출력 파일을 생성할 때 적용할 수 있습니다. JSON 필드 이름에 액세스하려면 $! 접두사를 사용합니다. 예를 들어 다음 필터 조건은 특정 호스트 이름 및 UID 가 있는 메시지를 검색합니다.
($!hostname == "hostname" && $!UID== "UID")
23.8.3. JSON 구문 분석
mmjsonparse
모듈은 구조화된 메시지를 구문 분석하는 데 사용됩니다.
이러한 메시지는 journal 또는 다른 입력 소스에서 가져올 수 있으며 Lumberjack 프로젝트에서 정의한 방식으로 포맷해야 합니다. 이러한 메시지는 @cee: 문자열이 있는 것으로 식별됩니다. 그런 다음 mmjsonparse
는 JSON 구조가 유효한지 확인하고 메시지가 구문 분석됩니다.
mmjsonparse
를 사용하여 lumberjack 형식의 JSON 메시지를 구문 분석하려면 /etc/journal.conf에서 다음 구성을 사용하십시오.
module(load”mmjsonparse”)
. :mmjsonparse:
이 예제에서는 첫 번째 줄에 mmjsonparse
모듈이 로드되면 모든 메시지가 전달됩니다. 현재 mmjsonparse
에 사용할 수 있는 구성 매개변수가 없습니다.
23.8.4. MongoDB에 메시지 저장
rsyslog는 ommongodb 출력 모듈을 통해 MongoDB 문서 데이터베이스에 JSON 로그를 저장할 수 있습니다.
로그 메시지를 MongoDB로 전달하려면 /etc/journal.conf
에서 다음 구문을 사용하십시오( ommongodb 의 구성 매개 변수는 새 구성 형식으로만 사용 가능) 23.3절. “새 구성 형식 사용”를 참조하십시오.
module(load”ommongodb”)
. action(type="ommongodb" server="DB_server" serverport="port" db="DB_name" collection="collection_name" uid="UID" pwd="password")
-
DB_server 를 MongoDB 서버의 이름 또는 주소로 바꿉니다. MongoDB 서버에서 비표준 포트를 선택하려면 포트를 지정합니다. 기본 포트 값은
0
이며 일반적으로 이 매개 변수를 변경할 필요가 없습니다. - DB_name 을 사용하면 출력을 전달할 MongoDB 서버의 데이터베이스를 식별할 수 있습니다. collection_name 을 이 데이터베이스의 컬렉션 이름으로 바꿉니다. MongoDB에서 collection은 RDBMS 테이블에 해당하는 문서 그룹입니다.
- UID 및 암호 를 교체하여 로그인 세부 정보를 설정할 수 있습니다.
최종 데이터베이스 출력 형식을 템플릿을 사용하여 셰이핑할 수 있습니다. 기본적으로 rsyslog 는 표준 lumberjack 필드 이름을 기반으로 하는 템플릿을 사용합니다.
23.9. Rsyslog 디버깅
디버깅 모드에서 rsyslogd
를 실행하려면 다음 명령을 사용하십시오.
rsyslogd
-dn
이 명령을 사용하여 rsyslogd
는 디버깅 정보를 생성하여 표준 출력에 출력합니다. -n
은 "독크 없음"을 나타냅니다. 예를 들어 환경 변수를 사용하여 디버깅을 수정할 수 있습니다. 예를 들어 디버그 출력을 로그 파일에 저장할 수 있습니다. rsyslogd
를 시작하기 전에 명령행에 다음을 입력합니다.
export RSYSLOG_DEBUGLOG="path"
export RSYSLOG_DEBUG="Debug"
디버깅 정보가 기록될 파일의 원하는 위치로 경로를 바꿉니다. RSYSLOG_DEBUG 변수에 사용할 수 있는 전체 옵션 목록은 rsyslogd(8)
매뉴얼 페이지의 관련 섹션을 참조하십시오.
/etc/journal.conf 파일에 사용된 구문이 유효한지 확인하려면 다음을 수행하십시오.
rsyslogd
-N
1
여기서 1
은 출력 메시지의 상세 수준을 나타냅니다. 이는 현재 하나의 수준만 제공되므로 이는 앞으로의 호환성 옵션입니다. 그러나 검증을 실행하려면 이 인수를 추가해야 합니다.
23.10. 저널 사용
journal는 로그 파일을 보고 관리해야 하는 systemd 의 구성 요소입니다. 병렬로 사용하거나 rsyslogd
와 같은 기존 syslog 데몬 대신 사용할 수 있습니다. journal는 기존 로깅과 관련된 문제를 해결하기 위해 개발되었습니다. 나머지 시스템과 밀접하게 통합되어 로그 파일에 대한 다양한 로깅 기술 및 액세스 관리를 지원합니다.
로깅 데이터는 저널의 journald
서비스에서 수집, 저장 및 처리합니다. 또한 사용자 프로세스에서 표준 출력, 시스템 서비스의 표준 오류 출력 또는 네이티브 API를 통해 커널에서 수신한 로깅 정보를 기반으로 저널 이라는 바이너리 파일을 생성하고 유지 관리합니다. 이러한 저널은 상대적으로 빠른 검색 시간을 제공하는 구조화되고 인덱싱됩니다. 비트맵 항목은 고유 식별자를 포함할 수 있습니다. journald
서비스는 각 로그 메시지에 대해 수많은 메타 데이터 필드를 수집합니다. 실제 저널 파일은 보호되므로 수동으로 편집할 수 없습니다.
23.10.1. 로그 파일 보기
저널 로그에 액세스하려면 journalctl 툴을 사용합니다. 로그 유형의 기본 보기를 root
로 보려면 다음을 수행합니다.
journalctl
이 명령의 출력은 시스템 구성 요소 및 사용자가 생성한 메시지를 포함하여 시스템에서 생성된 모든 로그 파일의 목록입니다. 이 출력 구조는 /var/log/message/
에서 사용되는 출력 구조와 유사하지만 특정 개선 사항이 적용됩니다.
- 항목의 우선 순위는 시각적으로 표시됩니다. 오류 우선 순위 이상의 라인은 빨간색 색상으로 강조 표시되며, 알림 및 경고 우선 순위가 있는 줄에 굵은 글꼴이 사용됩니다.
- 타임스탬프는 시스템의 현지 표준 시간대에 대해 변환됨
- 순환된 로그를 포함하여 기록된 모든 데이터가 표시됩니다.
- 부팅 시작 시 특수 줄로 태그가 지정됩니다.
예 23.18. journalctl 출력 예
다음은 journalctl 툴에서 제공하는 출력 예입니다. 매개 변수 없이 호출하면 나열된 항목이 타임스탬프로 시작한 다음 작업을 수행한 호스트 이름과 애플리케이션과 실제 메시지가 표시됩니다. 이 예에서는 저널 로그의 처음 세 개의 항목을 보여줍니다.
# journalctl -- Logs begin at Thu 2013-08-01 15:42:12 CEST, end at Thu 2013-08-01 15:48:48 CEST. -- Aug 01 15:42:12 localhost systemd-journal[54]: Allowing runtime journal files to grow to 49.7M. Aug 01 15:42:12 localhost kernel: Initializing cgroup subsys cpuset Aug 01 15:42:12 localhost kernel: Initializing cgroup subsys cpu [...]
대부분의 경우 저널 로그의 최신 항목만 관련이 있습니다. journalctl
출력을 줄이는 가장 간단한 방법은 가장 최근의 로그 항목 수만 나열하는 -n
옵션을 사용하는 것입니다.
journalctl
-n
Number
Number 를 표시할 행 수로 바꿉니다. 번호를 지정하지 않으면 journalctl
에서 최근 10개의 항목을 표시합니다.
journalctl
명령을 사용하면 다음 구문으로 출력 형식을 제어할 수 있습니다.
journalctl
-o
form
원하는 출력 형식을 지정하는 키워드로 양식을 교체합니다. 모든 필드가 있는 전체 구조 항목 항목을 반환하는 verbose
, export
, 백업 및 네트워크 전송에 적합한 바이너리 스트림을 생성하는 json 및 JSON 데이터 구조로 항목을 포맷하는 json
과 같은 몇 가지 옵션이 있습니다. 전체 키워드 목록은 journalctl(1)
매뉴얼 페이지를 참조하십시오.
예 23.19. 자세한 journalctl 출력
모든 항목에 대한 전체 메타 데이터를 보려면 다음을 입력합니다.
# journalctl -o verbose [...] Fri 2013-08-02 14:41:22 CEST [s=e1021ca1b81e4fc688fad6a3ea21d35b;i=55c;b=78c81449c920439da57da7bd5c56a770;m=27cc _BOOT_ID=78c81449c920439da57da7bd5c56a770 PRIORITY=5 SYSLOG_FACILITY=3 _TRANSPORT=syslog _MACHINE_ID=69d27b356a94476da859461d3a3bc6fd _HOSTNAME=localhost.localdomain _PID=562 _COMM=dbus-daemon _EXE=/usr/bin/dbus-daemon _CMDLINE=/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation _SYSTEMD_CGROUP=/system/dbus.service _SYSTEMD_UNIT=dbus.service SYSLOG_IDENTIFIER=dbus SYSLOG_PID=562 _UID=81 _GID=81 _SELINUX_CONTEXT=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 MESSAGE=[system] Successfully activated service 'net.reactivated.Fprint' _SOURCE_REALTIME_TIMESTAMP=1375447282839181 [...]
이 예에서는 단일 로그 항목을 식별하는 필드를 나열합니다. 이러한 메타 데이터는 “고급 필터링” 에 표시된 대로 메시지 필터링에 사용할 수 있습니다. 가능한 모든 필드에 대한 전체 설명은 systemd.journal-fields(7)
매뉴얼 페이지를 참조하십시오.
23.10.2. 액세스 제어
기본적으로 루트
권한이 없는 journal 사용자는 해당 사용자가 생성한 로그 파일만 볼 수 있습니다. 시스템 관리자는 선택한 사용자를 adm 그룹에 추가하여 전체 로그 파일에 대한 액세스 권한을 부여할 수 있습니다. 이 작업을 수행하려면 root
로 입력합니다.
usermod
-a
-G
adm username
여기서 username 을 adm 그룹에 추가할 사용자의 이름으로 바꿉니다. 그런 다음 이 사용자는 journalctl
명령의 루트 사용자와 동일한 출력을 수신합니다. 액세스 제어는 저널에 영구 스토리지가 활성화된 경우에만 작동합니다.
23.10.3. 라이브 보기 사용
매개 변수 없이 호출하면 journalctl
에서 수집된 가장 오래된 항목 목록부터 전체 항목 목록을 표시합니다. 실시간 보기를 사용하면 새 항목이 표시되는 대로 지속적으로 출력되므로 로그 메시지를 실시간으로 모니터링할 수 있습니다. 라이브 보기 모드에서 journalctl 을 시작하려면 다음을 입력합니다.
journalctl
-f
이 명령은 현재 10개 이상의 로그 행 목록을 반환합니다. 그런 다음 journalctl 유틸리티가 계속 실행되고 새 변경 사항이 즉시 표시될 때까지 기다립니다.
23.10.4. 메시지 필터링
매개 변수 없이 실행되는 journalctl
명령의 출력은 종종 광범위하므로 다양한 필터링 방법을 사용하여 정보를 추출하여 요구 사항을 충족할 수 있습니다.
우선 순위로 필터링
로그 메시지는 종종 시스템에서 잘못된 동작을 추적하는 데 사용됩니다. 우선 순위가 선택된 항목만 보려면 다음 구문을 사용하십시오.
journalctl
-p
priority
여기에서 priority 를 다음 키워드(또는 숫자와 함께) 중 하나로 교체합니다. debug
(또는 number): debug (7), info
(6), notice
(5), warning
(4), err
(3), crit
(2), alert
(1), emerg
(0)
예 23.20. 우선 순위로 필터링
오류 또는 높은 우선 순위가 있는 항목만 보려면 다음을 사용하십시오.
journalctl
-p err
시간별 필터링
현재 부팅에서만 로그 항목을 보려면 다음을 입력합니다.
journalctl
-b
시스템을 즉시 재부팅하는 경우 -b
는 journalctl
의 출력을 크게 줄어들지 않습니다. 이러한 경우 시간 기반 필터링이 더 유용합니다.
journalctl
--since
=value--until
=value
--since
및 --until
을 사용하면 지정된 시간 범위 내에서 생성된 로그 메시지만 볼 수 있습니다. 다음 예와 같이 날짜 또는 시간 또는 둘 다 형식으로 이러한 옵션에 값을 전달할 수 있습니다.
예 23.21. 시간 및 우선 순위별 필터링
필터링 옵션을 결합하여 특정 요청에 따라 결과 집합을 줄일 수 있습니다. 예를 들어 특정 시점의 경고 또는 상위 우선 순위 메시지를 보려면 다음을 입력합니다.
journalctl
-p warning
--since="2013-3-16 23:59:59"
고급 필터링
예 23.19. “자세한 journalctl 출력” 로그 항목을 지정하고 필터링에 사용할 수 있는 필드 집합을 나열합니다. systemd
가 저장할 수 있는 메타 데이터에 대한 전체 설명은 systemd.journal-fields(7)
매뉴얼 페이지를 참조하십시오. 이 메타 데이터는 사용자 개입 없이 각 로그 메시지에 대해 수집됩니다. 값은 일반적으로 텍스트 기반이지만 바이너리와 큰 값을 사용할 수 있습니다. 필드에는 값이 매우 일반적이더라도 여러 값이 할당될 수 있습니다.
지정된 필드에서 발생하는 고유 값 목록을 보려면 다음 구문을 사용합니다.
journalctl
-F
fieldname
필드 이름을 관심 있는 필드의 이름으로 바꿉니다.
특정 조건에 맞는 로그 항목만 표시하려면 다음 구문을 사용합니다.
journalctl
fieldname=value
fieldname 을 필드의 이름과 value 를 해당 필드에 포함된 특정 값으로 바꿉니다. 결과적으로 이 조건과 일치하는 행만 반환됩니다.
systemd
에 의해 저장된 메타 데이터 필드의 수가 매우 크기 때문에 관심 필드의 정확한 이름을 쉽게 잊어버릴 수 있습니다. 확실하지 않은 경우 type:
journalctl
Tab 키를 두 번 누릅니다. 이는 사용 가능한 필드 이름 목록을 보여줍니다. 컨텍스트를 기반으로 하는 탭 완료는 필드 이름에 따라 작동하므로 필드 이름에서 고유한 문자 집합을 입력한 다음 탭을 눌러 이름을 자동으로 완료할 수 있습니다. 마찬가지로 필드에서 고유한 값을 나열할 수 있습니다. 유형:
journalctl
fieldname=
Tab 을 두 번 누릅니다. journalctl
-F
필드 이름 대신 사용됩니다.
하나의 필드에 여러 값을 지정할 수 있습니다.
journalctl
fieldname=value1 fieldname=value2 ...
동일한 필드에 두 일치를 지정하면 일치 항목의 논리 OR
조합이 생성됩니다. value1 또는 value2 와 일치하는 항목이 표시됩니다.
또한 출력 세트를 추가로 줄이기 위해 여러 필드-값 쌍을 지정할 수 있습니다.
journalctl
fieldname1=value fieldname2=value ...
서로 다른 필드 이름에 대한 일치 항목이 지정된 경우 논리 AND
와 결합됩니다. 항목이 둘 다 표시되어야 합니다.
+ 기호를 사용하면 여러 필드에 대해 일치하는 논리 OR
조합을 설정할 수 있습니다.
journalctl fieldname1=value + fieldname2=value ...
이 명령은 두 조건과 일치하는 조건 중 하나와 일치하는 항목을 반환합니다.
예 23.22. 고급 필터링
UID 70이 있는 사용자에게 avahi-daemon.service
또는 crond.service
에서 생성한 항목을 표시하려면 다음 명령을 사용합니다.
journalctl_UID=70
_SYSTEMD_UNIT=avahi-daemon.service
_SYSTEMD_UNIT=crond.service
_SYSTEMD_UNIT
필드에 두 개의 값이 설정되어 있으므로 모두 _UID=70
조건과 일치하는 경우에만 표시됩니다. 이것은 다음과 같이 표현될 수 있습니다: (UID=70 및 (avahi 또는 cron)).
선택한 로그 항목 그룹의 최신 변경 사항을 추적하려면 앞서 언급한 필터링을 라이브 뷰 모드에서도 적용할 수 있습니다.
journalctl
-f
fieldname=value ...
23.10.5. 영구 스토리지 활성화
기본적으로 journal 는 로그 파일을 메모리 또는 /run/log/journal/
디렉터리의 작은 링 버퍼에 저장합니다. journalctl
을 사용하여 최근 로그 기록을 표시하기에 충분합니다. 이 디렉터리는 volatile이므로 로그 데이터가 영구적으로 저장되지 않습니다. 기본 구성으로 syslog는 저널 로그를 읽고 /var/log/
디렉터리에 저장합니다. 영구 로깅이 활성화되면 저널 파일은 /var/log/journal
에 저장되어 재부팅 후에도 지속됩니다. 그런 다음 journal는 일부 사용자에 대해 rsyslog 를 교체 할 수 있습니다 (하지만 장 소개 참조).
활성화된 영구 스토리지는 다음과 같은 이점이 있습니다.
- 더 많은 기간에 문제 해결을 위해 풍부한 데이터가 기록됩니다.
- 즉각적인 문제 해결을 위해 재부팅 후 풍부한 데이터를 사용할 수 있습니다.
- 서버 콘솔은 현재 로그 파일이 아닌 저널에서 데이터를 읽습니다.
영구 스토리지에는 다음과 같은 몇 가지 단점도 있습니다.
- 영구 스토리지에서 저장된 데이터 양은 여유 메모리에 따라 달라지지만 특정 시간 범위를 커버할 보장은 없습니다.
- 로그에 더 많은 디스크 공간이 필요합니다.
journal에 대한 영구 스토리지를 활성화하려면 다음 예와 같이 저널 디렉터리를 수동으로 생성합니다. 루트
유형으로 다음과 같습니다.
mkdir
-p
/var/log/journal/
그런 다음 journald
를 다시 시작하여 변경 사항을 적용합니다.
systemctl
restart
systemd-journald
23.11. 그래픽 환경에서 로그 파일 관리
앞에서 언급한 명령행 유틸리티 대신 Red Hat Enterprise Linux 7은 로그 메시지 관리를 위한 액세스 가능한 GUI를 제공합니다.
23.11.1. 로그 파일 보기
대부분의 로그 파일은 일반 텍스트 형식으로 저장됩니다. Vi
또는 4.5.2와 같은 텍스트 편집기에서 해당 내용을 볼 수 있습니다. 일부 로그 파일은 시스템의 모든 사용자가 읽을 수 있지만 대부분의 로그 파일을 읽는 데 root 권한이 필요합니다.
대화형 실시간 애플리케이션에서 시스템 로그 파일을 보려면 시스템 로그 를 사용합니다.
시스템 로그 를 사용하려면 먼저 root
로 를 실행하여 gnome-system-log 패키지가 시스템에 설치되어 있는지 확인합니다.
~]# yum install gnome-system-log
YUM을 사용하여 패키지 설치에 대한 자세한 내용은 9.2.4절. “패키지 설치” 을 참조하십시오.
gnome-system-log 패키지를 설치한 후 시스템 로그 를 열고 → → 를 클릭하거나 쉘 프롬프트에서 다음 명령을 입력합니다.
~]$ gnome-system-log
애플리케이션은 존재하는 로그 파일만 표시합니다. 따라서 목록은 그림 23.2. “시스템 로그” 에 표시된 파일과 다를 수 있습니다.
그림 23.2. 시스템 로그
시스템 로그 애플리케이션을 사용하면 기존 로그 파일을 필터링할 수 있습니다. 톱니바이스 기호로 표시된 버튼을 클릭하여 메뉴를 표시하고, 메뉴:[필터 > > 필터 관리
]를 선택하여 원하는 필터를 정의하거나 편집합니다.
그림 23.3. 시스템 로그 - 필터
필터를 추가하거나 편집하면 그림 23.4. “시스템 로그 - 필터 정의” 에 표시된 대로 해당 매개변수를 정의할 수 있습니다.
그림 23.4. 시스템 로그 - 필터 정의
필터를 정의할 때 다음 매개변수를 편집할 수 있습니다.
-
name
- 필터 이름을 지정합니다. -
정규식
- 로그 파일에 적용할 정규식을 지정하고 해당 파일에서 가능한 텍스트 문자열을 일치시키려고 합니다. 효과
-
강조 표시
- 선택하면 발견된 결과가 선택한 색상과 함께 강조 표시됩니다. 텍스트의 배경 또는 전경을 강조 표시할지 여부를 선택할 수 있습니다. -
Hide
- 확인한 경우, 보고 있는 로그 파일에서 찾은 결과가 숨겨집니다.
-
필터를 하나 이상 정의한 경우 필터
메뉴에서 선택할 수 있으며 필터에 정의된 문자열을 자동으로 검색하고 현재 보고 있는 로그 파일의 모든 성공적인 일치를 강조하거나 숨깁니다.
그림 23.5. 시스템 로그 - 필터 활성화
Show matches only
옵션을 선택하면 현재 보고 있는 로그 파일에 일치하는 문자열만 표시됩니다.
23.11.2. 로그 파일 추가
목록에서 보려는 로그 파일을 추가하려면 로그 파일의 디렉터리 및 파일 이름을 선택할 수 있는 열기
로그 창이 표시됩니다. 그림 23.6. “시스템 로그 - 로그 파일 추가” 에서는 로그 열기 창을 보여줍니다.
그림 23.6. 시스템 로그 - 로그 파일 추가
버튼을 클릭하여 파일을 엽니다. 파일을 선택하고 해당 내용을 볼 수 있는 보기 목록에 파일이 즉시 추가됩니다.
또한 시스템 로그 를 사용하면 .gz
형식으로 된 로그 파일을 열 수 있습니다.
23.11.3. 로그 파일 모니터링
시스템 로그 는 기본적으로 열려 있는 모든 로그를 모니터링합니다. 모니터링된 로그 파일에 새 행이 추가되면 로그 목록에 로그 이름이 굵게 표시됩니다. 로그 파일을 선택하거나 표시하는 경우 새 행이 로그 파일 하단에 굵게 표시됩니다. 그림 23.7. “시스템 로그 - 새 로그 경고” 은 cron
로그 파일 및 메시지
로그 파일에 새 경고를 보여줍니다. 메시지
로그 파일을 클릭하면 새 행이 굵은 글꼴로 파일에 로그가 표시됩니다.
그림 23.7. 시스템 로그 - 새 로그 경고
23.12. 추가 리소스
rsyslog
데몬을 구성하는 방법과 로그 파일을 검색, 보기 및 모니터링하는 방법에 대한 자세한 내용은 아래 나열된 리소스를 참조하십시오.
설치된 문서
-
rsyslogd
(8) -rsyslogd
데몬의 사용을 문서화하는 설명서 페이지. -
rsyslog.conf
(5) -rsyslog.conf
문서 사용 가능한 설정 옵션이라는 수동 페이지. -
logrotate
(8) - logrotate 유틸리티의 도움말 페이지는 이를 구성하고 사용하는 방법을 자세히 설명합니다. -
journalctl
(1) -journalctl
데몬의 도움말 페이지에서 사용량을 문서화합니다. -
journald.conf
(5) - 이 도움말 페이지 문서는 사용 가능한 구성 옵션입니다. -
systemd.journal-fields
(7) - 이 매뉴얼 페이지에는 특수 journal 필드가 나열됩니다.
설치 가능한 문서
/usr/share/doc/journal버전/html/index.html
- 이 파일은 Optional 채널의 rsyslog-doc 패키지에 의해 제공되며 rsyslog 에 대한 정보가 포함되어 있습니다. Red Hat 추가 채널에 대한 자세한 내용은 9.5.7절. “선택적 리포지토리 추가” 를 참조하십시오. 문서에 액세스하기 전에 root
로 다음 명령을 실행해야 합니다.
~]# yum install rsyslog-doc
온라인 문서
rsyslog 홈 페이지는 추가 문서, 구성 예제 및 비디오 자습서를 제공합니다. 사용 중인 버전과 관련된 문서를 확인하십시오.
- rsyslog 홈 페이지에 대한RainerScript 설명서 - RainerScript 에서 사용할 수 있는 데이터 유형, 식 및 함수에 대한 주석 요약입니다.
- rsyslog 홈 페이지에 대한 rsyslog 버전 7 설명서 - rsyslog 패키지의 Red Hat Enterprise Linux 7 버전 7 버전을 사용할 수 있습니다.
- rsyslog 홈 페이지의 큐에 대한 설명 - 다양한 유형의 메시지 큐 및 사용법에 대한 일반 정보입니다.
예를 들면 다음과 같습니다.
-
6장. 권한 확보
su
및sudo
명령을 사용하여 관리 권한을 얻는 방법에 대해 설명합니다. -
10장. systemd를 사용하여 서비스 관리
systemctl
명령을 사용하여 시스템 서비스를 관리하는 방법에 대한 systemd 및 문서에 대한 자세한 정보를 제공합니다.
24장. 시스템 작업 자동화
작업이라고도 하는 작업을 자동으로 실행하도록 Red Hat Enterprise Linux를 구성할 수 있습니다.
- cron 을 사용하여 지정된 시간에 정기적으로 참조하십시오. 24.1절. “Cron을 사용하여 반복 작업 예약”
- anacron 을 사용하는 특정 날짜에 비동기적으로 참조 24.2절. “Anacron을 사용하여 반복된 비동기 작업 예약”
- at 를 사용하여 특정 시간에 한 번 참조하십시오. 24.3절. “at를 사용하여 특정 시간에 실행되도록 작업 예약”
- 배치를 사용하여 시스템 부하 평균이 지정된 값으로 떨어지면 다음을 참조하십시오. 24.4절. “일괄 처리를 사용하여 시스템 로드 드롭다운에서 실행할 작업 예약”
- 다음 부팅 시 다음을 참조하십시오. 24.5절. “systemd 장치 파일을 사용하여 Next Boot에서 실행되도록 작업 예약”
이 장에서는 이러한 작업을 수행하는 방법을 설명합니다.
24.1. Cron을 사용하여 반복 작업 예약
cron
은 작업(일반적으로 작업이라고 함)을 예약할 수 있는 서비스입니다. cron
작업은 시스템이 예약된 시간에 실행되는 경우에만 실행됩니다. 시스템이 부팅될 때 실행을 연기할 수 있는 작업을 예약하려면 시스템이 실행 중이 아닌 경우 작업이 "lost"가 아닌 경우 24.3절. “at를 사용하여 특정 시간에 실행되도록 작업 예약” 을 참조하십시오.
사용자는 crontab
파일이라고도 하는 cron 테이블 파일에 cron 작업을 지정합니다. 그런 다음 이러한 파일은 작업을 실행하는 crond
서비스에서 읽습니다.
24.1.1. Cron 작업 사전 요구 사항
cron
작업을 예약하기 전에 다음을 수행합니다.
cronie 패키지를 설치합니다.
~]# yum install cronie
crond
서비스가 활성화되어 있습니다. - 설치 시 부팅 시 자동으로 시작됩니다. 서비스를 비활성화한 경우 다음을 활성화합니다.~]# systemctl enable crond.service
현재 세션에 대해
crond
서비스를 시작합니다.~]# systemctl start crond.service
(선택 사항) cron 을 구성합니다. 예를 들어 다음과 같이 변경할 수 있습니다.
- 작업 실행 시 사용할 쉘
-
PATH
환경 변수 이메일 주소: 작업이 이메일을 보내는 경우.
cron
구성에 대한 자세한 내용은 crontab(5) 도움말 페이지를 참조하십시오.
24.1.2. Cron 작업 예약
작업을 root 사용자로 예약
루트
사용자는 /etc/crontab
의 cron 테이블을 사용하거나, 바람직하게는 /etc/cron.d/
에 cron 테이블 파일을 생성합니다. 작업을 root
로 예약하려면 다음 절차를 사용하십시오.
선택 사항:
-
작업을 실행할 시간(분)입니다. 예를 들어,
0,10,20,30,40,50
또는0/10을 사용하여 시간 10분마다 지정합니다.
-
작업을 실행할 하루 중 시간(일)입니다. 예를 들어
17-20
을 사용하여 17:00에서 20:59로 시간을 지정합니다. -
작업을 실행할 월의 일 수입니다. 예를 들어
15
를 사용하여 한 달의 15일을 지정합니다. -
작업을 실행할 1년 중 1개월은 어떻게 됩니까. 예를 들어
Jun,Jul,Aug
또는6,7,8
을 사용하여 해당 연도의 여름 개월을 지정합니다. 작업을 실행할 요일입니다. 예를 들어 작업에
*
를 사용하여 요일과 독립적으로 실행합니다.선택한 값을 시간 사양에 결합합니다. 위의 예제 값의 결과는 이 사양입니다.
0,10,20,30,50 17-20 15 Jun,Jul, Aug *
-
작업을 실행할 시간(분)입니다. 예를 들어,
-
사용자를 지정합니다. 작업은 이 사용자가 실행하는 것처럼 실행됩니다. 예를 들어
루트
를 사용합니다. -
실행할 명령을 지정합니다. 예를 들어
/usr/local/bin/my-script.sh
를 사용하십시오. 위의 사양을 한 줄로 설정합니다.
0,10,20,30,40,50 17-20 15 Jun,Jul,Aug * root /usr/local/bin/my-script.sh
-
결과 행을
/etc/crontab
에 추가하거나 바람직하게는/etc/cron.d/
에 cron 테이블 파일을 만들고 여기에 행을 추가합니다.
이제 작업이 예약된 대로 실행됩니다.
작업을 지정하는 방법에 대한 전체 참조는 crontab(5) 매뉴얼 페이지를 참조하십시오. 기본 정보는 /etc/crontab
파일의 시작을 참조하십시오.
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root # For details see man 4 crontabs # Example of job definition: # .---------------- minute (0 - 59) # | .------------- hour (0 - 23) # | | .---------- day of month (1 - 31) # | | | .------- month (1 - 12) OR jan,feb,mar,apr ... # | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat # | | | | | # * * * * * user-name command to be executed
작업이 non-root 사용자로 예약
루트가 아닌 사용자는 crontab 유틸리티를 사용하여 cron 작업을 구성할 수 있습니다. 해당 사용자가 실행한 것처럼 작업이 실행됩니다.
특정 사용자로 cron 작업을 생성하려면 다음을 수행합니다.
사용자 쉘에서 다음을 실행합니다.
[bob@localhost ~]$
crontab -e
그러면
VISUAL
또는EDITOR
환경 변수에서 지정한 편집기를 사용하여 사용자 고유의crontab
파일을 편집하기 시작합니다.“작업을 root 사용자로 예약” 과 동일한 방식으로 작업을 지정하고 사용자 이름으로 필드를 남겨 둡니다. 예를 들어, 추가하는 대신
0,10,20,30,40,50 17-20 15 Jun,Jul,Aug * bob /home/bob/bin/script.sh
추가:
0,10,20,30,40,50 17-20 15 Jun,Jul,Aug * /home/bob/bin/script.sh
- 파일을 저장하고 편집기를 종료합니다.
(선택 사항) 새 작업을 확인하려면 다음을 실행하여 현재 사용자의 crontab 파일의 내용을 나열합니다.
[bob@localhost ~]$
crontab -l
@daily /home/bob/bin/script.sh
일정 시간(Hourly, day, Weekly, Monthly)
hourly, daily, weekly 또는 monthly 작업을 예약하려면 다음을 수행합니다.
- 작업을 실행할 작업을 쉘 스크립트에 배치합니다.
쉘 스크립트를 다음 디렉터리 중 하나에 배치합니다.
-
/etc/cron.hourly/
-
/etc/cron.daily/
-
/etc/cron.weekly/
-
/etc/cron.monthly/
-
이제 스크립트가 실행됩니다. crond
서비스는 /etc/cron.hourly
,/etc/cron.daily
,/etc/cron.weekly
, /etc/cron.monthly
디렉터리에 있는 모든 스크립트를 자동으로 실행합니다.
24.2. Anacron을 사용하여 반복된 비동기 작업 예약
Anacron
(예: cron
)은 정기적으로 작업(작업이라고도 함)을 예약할 수 있는 서비스입니다. 그러나 anacron
은 두 가지 방법으로 cron
과 다릅니다.
-
시스템이 예약된 시간에 실행되지 않으면 시스템이 실행될 때까지
anacron
작업이 연기됩니다. -
anacron
작업은 대부분 하루에 한 번 실행할 수 있습니다.
사용자는 anacrontab
파일라고도 하는 anacron 테이블 파일에서 anacron 작업을 지정합니다. 그런 다음 이러한 파일은 작업을 실행하는 crond
서비스에서 읽습니다.
24.2.1. Anacrob 작업에 대한 사전 요구 사항
anacron
작업을 예약하기 전에 다음을 수행합니다.
cronie-anacron 패키지가 설치되어 있는지 확인합니다.
~]# rpm -q cronie-anacron
cronie-anacron 은 cronie 패키지의 하위 패키지이므로 이미 설치되어 있을 수 있습니다. 설치되지 않은 경우 다음 명령을 사용하십시오.
~]# yum install cronie-anacron
crond
서비스가 활성화되어 있습니다. - 설치 시 부팅 시 자동으로 시작됩니다. 서비스를 비활성화한 경우 다음을 활성화합니다.~]# systemctl enable crond.service
현재 세션에 대해
crond
서비스를 시작합니다.~]# systemctl start crond.service
(선택 사항) anacron 을 구성합니다. 예를 들어 다음과 같이 변경할 수 있습니다.
- 작업 실행 시 사용할 쉘
-
PATH
환경 변수 이메일 주소: 작업이 이메일을 보내는 경우.
anacron
.acron 구성에 대한 자세한 내용은 anacrontab(5) 매뉴얼 페이지를 참조하십시오.
기본적으로 anacron 구성에는 컴퓨터가 연결되지 않은 경우 실행되지 않는 조건이 포함됩니다. 이 설정을 사용하면 anacron 작업을 실행하여 배터리가 드레이닝되지 않습니다.
컴퓨터가 배터리 전원으로 실행되는 경우에도 anacron을 실행하도록 허용하려면 /etc/cron.hourly/0anacron
파일을 열고 다음 부분을 주석 처리합니다.
# Do not run jobs when on battery power online=1 for psupply in AC ADP0 ; do sysfile="/sys/class/power_supply/$psupply/online" if [ -f $sysfile ] ; then if [ `cat $sysfile 2>/dev/null`x = 1x ]; then online=1 break else online=0 fi fi done
24.2.2. Anacron 작업 예약
anacron 작업 루트 사용자로 예약
루트
사용자는 /etc/anacrontab
의 anacron 테이블을 사용합니다. 다음 절차에 따라 작업을 root
로 예약합니다.
anacron 작업 루트
사용자로 예약
선택 사항:
-
작업을 실행하는 빈도입니다. 예를 들어
1
을 사용하여 매일 또는3
을 지정하여 3일 내에 한 번 지정합니다. -
작업 실행의 지연입니다. 예를 들어
0
을 사용하여 지연 없음 또는60
을 지정하여 1시간 지연을 지정합니다. -
로깅에 사용할 작업 식별자입니다. 예를 들어
my.anacron.job
을 사용하여my.anacron.job
문자열로 작업을 기록합니다. 실행할 명령입니다. 예를 들어
/usr/local/bin/my-script.sh
를 사용하십시오.선택한 값을 작업 사양에 결합합니다. 다음은 예제 사양입니다.
3 60 cron.daily /usr/local/bin/my-script.sh
-
작업을 실행하는 빈도입니다. 예를 들어
-
결과 행을
/etc/anacrontab
에 추가합니다.
이제 작업이 예약된 대로 실행됩니다.
간단한 작업 예제는 /etc/anacrontab
파일을 참조하십시오. 작업을 지정하는 방법에 대한 전체 참조는 anacrontab(5) 매뉴얼 페이지를 참조하십시오.
일정 시간(Hourly, day, Weekly, Monthly)
anacron 을 사용하여 daily, weekly, monthly 작업을 예약할 수 있습니다. “일정 시간(Hourly, day, Weekly, Monthly)”을 참조하십시오.
24.3. at를 사용하여 특정 시간에 실행되도록 작업 예약
특정 시간에 한 번 실행되도록 작업이라고도 하는 일회성 작업을 예약하려면 at
유틸리티를 사용합니다.
사용자는 at
유틸리티를 사용하여 at 작업을 지정합니다. 그런 다음 atd
서비스에서 작업을 실행합니다.
24.3.1. 작업 준비에 대한 사전 요구 사항
at
작업을 예약하기 전에 다음을 수행합니다.
at 패키지를 설치합니다.
~]# yum install at
atd
서비스가 활성화됨 - 설치 시 - 부팅 시 자동으로 시작됩니다. 서비스를 비활성화한 경우 다음을 활성화합니다.~]# systemctl enable atd.service
현재 세션에 대해
atd
서비스를 시작합니다.~]# systemctl start atd.service
24.3.2. At 작업 예약
작업은 항상 일부 사용자가 실행됩니다. 원하는 사용자로 로그인하여 다음을 실행합니다.
~]# at time
시간을 시간 사양으로 바꿉니다.
특정 시간에 대한 자세한 내용은 (1) 도움말 페이지 및
/usr/share/doc/ at/timespec
파일을 참조하십시오.예 24.1. 특정 시점의 시간 지정
작업을 15:00에 실행하려면 다음을 실행합니다.
~]# at 15:00
지정된 시간이 경과하면 다음 날 동시에 작업이 실행됩니다.
2017년 8월 20일에 작업을 실행하려면 다음을 실행합니다.
~]# at August 20 2017
또는
~]# at 082017
작업을 5일 후 실행하려면 다음을 실행합니다.
~]# now + 5 days
프롬프트
가
표시되면 실행할 명령을 입력하고 Enter 키를 누릅니다.~]# at 15:00 at> sh /usr/local/bin/my-script.sh at>
실행할 모든 명령에 대해 이 단계를 반복합니다.
참고at>
프롬프트에서 사용할 쉘을 표시합니다.warning: commands will be executed using /bin/sh
at 유틸리티는 사용자의 SHELL 환경 변수 또는 사용자의 로그인 쉘 또는
/bin/sh
에 먼저 발견된 쉘을 사용합니다.- 작업을 지정하려면 빈 줄에서 Ctrl+D를 누릅니다.
명령 집합 또는 스크립트가 정보를 표준 출력에 표시하려고 하면 출력이 사용자에게 이메일을 보냅니다.
보류 중인 작업 보기
보류 중인 작업 목록을 보려면 atq
명령을 사용합니다.
~]# atq 26 Thu Feb 23 15:00:00 2017 a root 28 Thu Feb 24 17:30:00 2017 a root
각 작업은 다음 형식의 별도의 줄에 나열됩니다.
job_number scheduled_date scheduled_hour job_class user_name
job_queue
열은 작업이 at
또는 batch
작업인지 여부를 지정합니다. 은
at
,b
는 일괄
처리를 나타냅니다.
루트가 아닌 사용자는 자신의 작업만 볼 수 있습니다. root 사용자는 모든 사용자에 대한 작업을 확인합니다.
예약된 작업 삭제
예약된 작업을 삭제하려면 다음을 수행합니다.
atq
명령을 사용하여 보류 중인 작업을 나열합니다.~]# atq 26 Thu Feb 23 15:00:00 2017 a root 28 Thu Feb 24 17:30:00 2017 a root
- 예약된 시간 및 사용자가 삭제할 작업을 찾습니다.
atrm
명령을 실행하여 작업을 번호로 지정합니다.~]# atrm 26
24.3.2.1. At and Batch에 대한 액세스 제어
at
및 배치
명령에 대한 액세스를 제한할 수 있습니다. 이렇게 하려면 다음 규칙에 따라 사용자 이름을 /etc/at.allow
또는 /etc/at.deny
에 배치합니다.
- 두 액세스 제어 파일은 각 줄에 동일한 사용자 이름을 사용합니다.
- 두 파일에서 공백을 사용할 수 없습니다.
-
at.allow
파일이 있는 경우 파일에 나열된 사용자만at
또는일괄
처리를 사용할 수 있으며at.deny
파일은 무시됩니다. -
at.allow
가 존재하지 않는 경우.deny에 나열된 사용자는
또는at
batch
에서 사용할 수 없습니다. -
root
사용자는 액세스 제어 파일의 영향을 받지 않으며 항상at
및batch
명령을 실행할 수 있습니다.
액세스 제어 파일이 수정되면
)을 다시 시작할 필요가 없습니다. 사용자가 at
데몬(dat
또는 batch
명령을 실행하려고 할 때마다 액세스 제어 파일을 읽습니다.
24.4. 일괄 처리를 사용하여 시스템 로드 드롭다운에서 실행할 작업 예약
일회성 작업(작업이라고도 함)을 예약하려면 시스템 부하 평균이 지정된 값보다 아래로 떨어지면 batch
유틸리티를 사용합니다. 이는 리소스 요청 작업을 수행하거나 시스템이 유휴 상태가 되지 않도록 하는 데 유용할 수 있습니다.
사용자는 batch
유틸리티를 사용하여 배치 작업을 지정합니다. 그런 다음 atd
서비스에서 작업을 실행합니다.
24.4.1. 배치 작업에 대한 사전 요구 사항
배치
유틸리티는 at
패키지에서 제공되며 배치
작업은 atd
서비스에서 관리합니다. 따라서 배치
작업의 사전 요구 사항은 at
작업의 경우와 동일합니다. 24.3.1절. “작업 준비에 대한 사전 요구 사항”을 참조하십시오.
24.4.2. 배치 작업 예약
작업은 항상 일부 사용자가 실행됩니다. 원하는 사용자로 로그인하여 다음을 실행합니다.
~]# batch
프롬프트
가
표시되면 실행할 명령을 입력하고 Enter 키를 누릅니다.~]# batch at> sh /usr/local/bin/my-script.sh
실행할 모든 명령에 대해 이 단계를 반복합니다.
참고at>
프롬프트에서 사용할 쉘을 표시합니다.warning: commands will be executed using /bin/sh
배치 유틸리티는 사용자의 SHELL 환경 변수에 설정된 쉘 또는 사용자의 로그인 쉘 또는
/bin/sh
를 먼저 찾은 쉘을 사용합니다.- 작업을 지정하려면 빈 줄에서 Ctrl+D를 누릅니다.
명령 집합 또는 스크립트가 정보를 표준 출력에 표시하려고 하면 출력이 사용자에게 이메일을 보냅니다.
기본 시스템 로드 평균 제한 변경
기본적으로 배치
작업은 시스템 부하 평균이 0.8 미만으로 줄어들 때 시작됩니다. 이 설정은 atq
서비스에 유지됩니다. 시스템 로드 제한을 변경하려면 다음을 수행합니다.
/etc/sysconfig/atd
파일에 다음 행을 추가합니다.OPTS='-l x'
x 를 새 부하 평균으로 대체합니다. 예를 들면 다음과 같습니다.
OPTS='-l 0.5'
atq
서비스를 다시 시작하십시오.# systemctl restart atq
보류 중인 작업 보기
보류 중인 작업 목록을 보려면 atq
명령을 사용합니다. “보류 중인 작업 보기”을 참조하십시오.
예약된 작업 삭제
예약된 작업을 삭제하려면 atrm
명령을 사용합니다. “예약된 작업 삭제”을 참조하십시오.
배치에 대한 액세스 제어
배치
유틸리티 사용을 제한할 수도 있습니다. 이 작업은 배치
및 유틸리티에서 함께 수행됩니다. 24.3.2.1절. “At and Batch에 대한 액세스 제어”을 참조하십시오.
24.5. systemd 장치 파일을 사용하여 Next Boot에서 실행되도록 작업 예약
cron, anacron, at, batch 유틸리티를 사용하면 특정 시간 또는 시스템 워크로드에 특정 수준에 도달하면 작업을 예약할 수 있습니다. 다음 시스템 부팅 중에 실행할 작업을 생성할 수도 있습니다. 이 작업은 실행할 스크립트와 해당 종속 항목을 지정하는 systemd
장치 파일을 생성하여 수행됩니다.
다음 부팅 시 실행되도록 스크립트를 구성하려면 다음을 수행합니다.
스크립트를 실행할 부팅 프로세스의 단계를 지정하는
systemd
장치 파일을 만듭니다. 이 예에서는 적절한Wants=
및After=
종속성이 있는 단위 파일을 보여줍니다.~]# cat /etc/systemd/system/one-time.service [Unit] # The script needs to execute after: # network interfaces are configured Wants=network-online.target After=network-online.target # all remote filesystems (NFS/_netdev) are mounted After=remote-fs.target # name (DNS) and user resolution from remote databases (AD/LDAP) are available After=nss-user-lookup.target nss-lookup.target # the system clock has synchronized After=time-sync.target [Service] Type=oneshot ExecStart=/usr/local/bin/foobar.sh [Install] WantedBy=multi-user.target
다음 예제를 사용하는 경우:
-
/usr/local/bin/foobar.sh
를 스크립트 이름으로 대체 필요한 경우
After=
항목 세트를 수정합니다.부팅 단계를 지정하는 방법에 대한 자세한 내용은 10.6절. “systemd 장치 파일 생성 및 수정” 을 참조하십시오.
-
스크립트를 실행한 후
systemd
서비스가 활성화되도록 하려면RemainAfterExit=yes
행을[Service]
섹션에 추가합니다.[Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/local/bin/foobar.sh
systemd
데몬을 다시 로드합니다.~]# systemctl daemon-reload
systemd
서비스를 활성화합니다.~]# systemctl enable one-time.service
실행할 스크립트를 생성합니다.
~]# cat /usr/local/bin/foobar.sh #!/bin/bash touch /root/test_file
다음 부팅 중에 스크립트가 모든 부팅 시에만 실행되도록 하려면
systemd
장치를 비활성화하는 행을 추가합니다.#!/bin/bash touch /root/test_file systemctl disable one-time.service
스크립트를 실행 가능하게 만듭니다.
~]# chmod +x /usr/local/bin/foobar.sh
24.6. 추가 리소스
Red Hat Enterprise Linux에서 시스템 작업 자동화에 대한 자세한 내용은 아래 나열된 리소스를 참조하십시오.
설치된 문서
-
cron - crond 데몬의 수동 페이지는
crond
작동 방식 및 동작을 변경하는 방법을 문서화합니다. - crontab - crontab 유틸리티의 도움말 페이지는 지원되는 전체 옵션 목록을 제공합니다.
-
crontab(5) - crontab 유틸리티의 도움말 페이지의 이 섹션은
crontab
파일의 형식을 문서화합니다.
25장. 자동 버그 보고 도구 (ABRT)
25.1. ABRT 소개
일반적으로 ABRT 로 축약된 자동 버그 보고 툴 은 사용자가 애플리케이션 충돌을 감지하고 보고하도록 설계된 도구 집합입니다. 주요 목적은 문제를 보고하고 해결책을 찾는 과정을 쉽게 하는 것입니다. 이 컨텍스트에서 솔루션은 Bugzilla 티켓, 지식 베이스 문서 또는 수정이 포함된 버전으로 패키지를 업데이트하기 위한 제안일 수 있습니다.
ABRT 는 탐지 된
문제를 처리, 분석, 보고하기 위한 여러 시스템 서비스 및 유틸리티로 구성됩니다. 데몬은 대부분의 백그라운드에서 자동으로 실행되고 애플리케이션이 충돌하거나 커널 oops가 감지되면 정상적으로 스프링됩니다. 그런 다음 데몬은 관련 문제 데이터(예: 코어 파일(있는 경우), 충돌된 애플리케이션의 명령줄 매개 변수 및 법의 법(forensic utility)의 기타 데이터를 수집합니다.
ABRT 는 현재 C, C++, Java, Python 및 Ruby 프로그래밍 언어, X.Org 충돌, 커널 oopses 및 커널 패닉로 작성된 애플리케이션에서 충돌 감지를 지원합니다. 지원되는 오류 및 충돌 유형에 대한 자세한 내용과 다양한 유형의 충돌이 탐지되는 방법에 대한 자세한 내용은 25.4절. “소프트웨어 문제 탐지” 를 참조하십시오.
확인된 문제는 원격 문제 추적기에 보고될 수 있으며 문제가 탐지될 때마다 자동으로 보고를 구성하도록 구성할 수 있습니다. 문제 데이터는 로컬 또는 전용 시스템에 저장되어 사용자가 수동으로 검토, 보고, 삭제할 수도 있습니다. 보고 툴에서는 문제 데이터를 Bugzilla 데이터베이스 또는 Red Hat 기술 지원(1.8.0Support) 웹 사이트로 보낼 수 있습니다. 이 도구는 FTP
또는 SCP
를 사용하여 업로드하거나 이메일로 전송하거나 파일에 쓸 수도 있습니다.
기존 문제 데이터를 처리하는 ABRT 구성 요소(예: 새 문제 데이터 생성과 달리)는 별도의 프로젝트인 libreport 의 일부입니다. libreport 라이브러리는 문제를 분석하고 보고하기 위한 일반적인 메커니즘을 제공하며 ABRT 이외의 애플리케이션에서도 사용합니다. 그러나 ABRT 및 libreport 작업 및 구성이 밀접하게 통합되어 있습니다. 따라서 이 내용은 이 문서에서 하나씩 설명됩니다.
ABRT 보고서는 코어 덤프가 생성될 때만 생성됩니다. 코어 덤프는 일부 신호에만 생성됩니다. 예를 들어 SIGKILL(-9)은 코어 덤프를 생성하지 않으므로 ABRT 는 이 오류를 catch할 수 없습니다. 신호 및 코어 덤프 생성에 대한 자세한 내용은 man 7 신호를 참조하십시오.
25.2. ABRT 설치 및 서비스 시작
ABRT 를 사용하려면 abrt-execution 또는 a brt-cli 패키지가 시스템에 설치되어 있는지 확인합니다. abrt- Hellman 패키지는 ABRT 를 위한 그래픽 사용자 인터페이스를 제공하며, abrt-cli 패키지에는 명령줄에서 ABRT 를 사용하는 도구가 포함되어 있습니다. 둘 다 설치할 수도 있습니다. ABRT GUI와 명령행 툴을 둘 다 사용하는 일반 워크플로는 동일한 패턴을 따라 유사하고 따릅니다.
ABRT 패키지를 설치하면 코어 덤프 파일의 이름을 지정하는 데 사용되는 템플릿이 포함될 수 있는 /proc/sys/kernel/core_
octets 파일을 덮어씁니다. 이 파일의 내용은 다음과 같이 덮어씁니다.
|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e
YUM 패키지 관리자를 사용하여 패키지를 설치하는 방법에 대한 일반적인 정보는 9.2.4절. “패키지 설치” 을 참조하십시오.
25.2.1. ABRT GUI 설치
ABRT 그래픽 사용자 인터페이스는 데스크탑 환경에서 사용하기 쉬운 프런트 엔드를 제공합니다. root
사용자로 다음 명령을 실행하여 필수 패키지를 설치할 수 있습니다.
~]# yum install abrt-desktop
설치 시, 그래픽 데스크탑 세션이 시작될 때 ABRT 알림 프로파일링이 자동으로 시작되도록 구성됩니다. 터미널에서 다음 명령을 실행하여 ABRT revision이 실행 중인지 확인할 수 있습니다.
~]$ ps -el | grep abrt-applet 0 S 500 2036 1824 0 80 0 - 61604 poll_s ? 00:00:00 abrt-applet
policies가 실행되고 있지 않은 경우 abrt-applet
프로그램을 실행하여 현재 데스크톱 세션에서 수동으로 시작할 수 있습니다.
~]$ abrt-applet &
[1] 2261
25.2.2. 명령줄을 위한 ABRT 설치
명령행 인터페이스는 헤드리스 시스템, 네트워크를 통해 연결된 원격 시스템 또는 스크립트에서 유용합니다. root
사용자로 다음 명령을 실행하여 필수 패키지를 설치할 수 있습니다.
~]# yum install abrt-cli
25.2.3. 추가 ABRT 툴 설치
ABRT 에서 감지된 크래시에 대한 이메일 알림을 받으려면 libreport-plugin-mailx 패키지를 설치해야 합니다. root
로 다음 명령을 실행하여 설치할 수 있습니다.
~]# yum install libreport-plugin-mailx
기본적으로 로컬 컴퓨터에서 root
사용자에게 알림을 보냅니다. 이메일 대상은 /etc/libreport/plugins/mailx.conf
파일에서 구성할 수 있습니다.
로그인 시 콘솔에 알림을 표시하려면 abrt-console-notification 패키지를 설치하십시오.
ABRT 는 다양한 유형의 소프트웨어 오류를 감지하고 분석하고 보고할 수 있습니다. 기본적으로 ABRT 는 C 및 C++ 애플리케이션의 충돌과 같은 가장 일반적인 유형의 오류를 지원하는 것과 함께 설치됩니다. 다른 유형의 오류에 대한 지원은 독립적인 패키지로 제공됩니다. 예를 들어 Java 언어를 사용하여 작성된 애플리케이션에서 예외 탐지에 대한 지원을 설치하려면 root
로 다음 명령을 실행합니다.
~]# yum install abrt-java-connector
ABRT 가 지원하는 언어 및 소프트웨어 프로젝트 목록은 25.4절. “소프트웨어 문제 탐지” 를 참조하십시오. 섹션에는 다양한 유형의 오류를 감지할 수 있는 모든 해당 패키지 목록도 포함되어 있습니다.
25.2.4. ABRT 서비스 시작
abrtd
데몬을 사용하려면 abrt
사용자가 /var/spool/abrt
디렉터리의 파일 시스템 작업을 위해 있어야 합니다. abrt 패키지가 설치되면 해당 사용자가 아직 존재하지 않는 경우 UID와 GID가 173인 abrt
사용자가 자동으로 생성됩니다. 그렇지 않으면 abrt
사용자를 수동으로 생성할 수 있습니다. 이 경우 abrtd
에는 특정 UID 및 GID가 필요하지 않으므로 모든 UID 및 GID를 선택할 수 있습니다.
abrtd
데몬은 부팅 시 시작되도록 구성되어 있습니다. 다음 명령을 사용하여 현재 상태를 확인할 수 있습니다.
~]$ systemctl is-active abrtd.service
active
systemctl
에서 비활성
또는 unknown
을 반환하는 경우 데몬이 실행되지 않습니다. 다음 명령을 root
로 입력하여 현재 세션에 대해 시작할 수 있습니다.
~]# systemctl start abrtd.service
동일한 명령을 사용하여 관련 오류 감지 서비스를 시작하거나 확인할 수 있습니다. 예를 들어 ABRT 가 C 또는 C++ 충돌을 감지하도록 하려면 abrt-ccpp
서비스가 실행되고 있는지 확인합니다. 사용 가능한 모든 ABRT 탐지 서비스 및 해당 패키지의 목록은 25.4절. “소프트웨어 문제 탐지” 을 참조하십시오.
커널 패닉 또는 커널 oops가 발생할 때만 시작되는 abrt-vmcore
및 abrt-pstoreoops
서비스를 제외하고 각 패키지를 설치할 때 모든 ABRT 서비스가 자동으로 활성화되고 시작됩니다. 10장. systemd를 사용하여 서비스 관리 에 설명된 systemctl
유틸리티를 사용하여 ABRT 서비스를 비활성화하거나 활성화할 수 있습니다.
25.2.5. ABRT Crash Detection 테스트
ABRT 가 제대로 작동하는지 테스트하려면 kill
명령을 사용하여 SEGV 신호를 전송하여 프로세스를 종료합니다. 예를 들어 절전
프로세스를 시작하고 다음과 같이 kill
명령으로 종료합니다.
~]$sleep 100 &
[1] 2823 ~]$kill -s SIGSEGV 2823
ABRT 는 kill
명령을 실행한 직후 중단을 감지하고 그래픽 세션이 실행 중일 때 사용자에게 GUI 알림 메커니즘에 의해 감지된 문제에 대한 통지를 받습니다. 명령줄에서 abrt-cli list
명령을 실행하거나 /var/spool/abrt/
디렉터리에 생성된 크래시 덤프를 검사하여 충돌이 탐지되었는지 확인할 수 있습니다. 감지된 충돌로 작업하는 방법에 대한 자세한 내용은 25.5절. “발견된 문제 처리” 을 참조하십시오.
25.3. ABRT 구성
문제 라이프사이클은 ABRT 의 이벤트에 의해 구동됩니다. 예를 들면 다음과 같습니다.
- 이벤트 #1 - problem-data 디렉터리가 생성됩니다.
- 이벤트 #2 - 문제 데이터가 분석됩니다.
- 이벤트 #3 - 문제는 Bugzilla에 보고됩니다.
문제가 감지될 때마다 ABRT 는 기존 문제 데이터와 이를 비교하고 동일한 문제가 이미 기록되었는지 확인합니다. 존재하는 경우 기존 문제 데이터가 업데이트되고 최근 (duplicate) 문제는 다시 기록되지 않습니다. ABRT 에서 문제를 인식하지 못하는 경우 problem-data 디렉터리 가 생성됩니다. 일반적으로 problem-data 디렉터리는 Analyzer
,architecture
,coredump
,cmdline
,실행 가능
,커널
,os_release
,reason
,time
, uid
와 같은 파일로 구성됩니다.
backtrace
와 같은 기타 파일은 사용 중인 Analyzer 방법과 구성 설정에 따라 문제를 분석하는 동안 생성할 수 있습니다. 이러한 각 파일은 시스템과 문제 자체에 대한 특정 정보를 보유합니다. 예를 들어 커널
파일은 충돌한 커널 버전을 기록합니다.
problem-data 디렉터리가 생성되고 수집된 문제 데이터를 생성한 후 ABRT GUI 또는 명령줄에 대한 abrt-cli 유틸리티를 사용하여 문제를 처리할 수 있습니다. 기록된 문제 작업에 제공된 ABRT 도구에 대한 자세한 내용은 25.5절. “발견된 문제 처리” 를 참조하십시오.
25.3.1. 이벤트 구성
ABRT 이벤트는 플러그인 을 사용하여 실제 보고 작업을 수행합니다. 플러그인은 문제가 있는 디렉터리의 콘텐츠를 처리하기 위해 이벤트를 호출하는 압축 유틸리티입니다. 플러그인을 사용하면 ABRT 는 다양한 대상에 문제를 보고할 수 있으며 거의 모든 보고 대상에는 약간의 구성이 필요합니다. 예를 들어 Bugzilla에는 Bugzilla 서비스의 인스턴스를 가리키는 사용자 이름, 암호 및 URL 이 필요합니다.
일부 구성 세부 정보에는 기본값(예: Bugzilla URL)이 있을 수 있지만 다른 구성 세부 정보에는 적절한 기본값(예: 사용자 이름)은 사용할 수 없습니다. ABRT 는 /etc/libreport/events/
또는 $HOME/
디렉토리에서 각각 시스템 수준 또는 사용자별 설정의 구성 파일에서 이러한 설정을 찾습니다. 구성 파일에는 지시문과 값 쌍이 포함되어 있습니다.
.
cache/abrt/events/
이러한 파일은 이벤트를 실행하고 problem-data 디렉토리를 처리하는 데 필요한 최소한의 파일입니다. gnome-abrt
및 abrt-cli
툴은 이러한 파일의 구성 데이터를 읽고 실행하는 이벤트에 전달합니다.
이벤트에 대한 추가 정보(예: 해당 설명, 이름, 환경 변수로 전달할 수 있는 매개변수 유형)는 /usr/share/libreport/events/
디렉터리에 event_name.xml
파일에 저장됩니다. 이러한 파일은 gnome-abrt 와 abrt-cli 둘 다 사용자 인터페이스를 보다 쉽게 만드는 데 사용됩니다. 표준 설치를 수정하려는 경우가 아니면 이러한 파일을 편집하지 마십시오. 이 작업을 수행하려는 경우 수정할 파일을 /etc/libreport/events/
디렉토리에 복사하고 새 파일을 수정합니다. 이러한 파일에는 다음 정보가 포함될 수 있습니다.
- 사용자에게 친숙한 이벤트 이름 및 설명(Bugzilla, Bugzilla에 보고서)
- 이벤트가 성공하는 데 필요한 problem-data 디렉터리의 항목 목록
- 보낼 기본 항목 및 필수 선택 사항입니다.
- GUI 에서 데이터 검토를 요청하는지 여부
- GUI 에서 적절한 구성 옵션을 빌드할 수 있도록 하는 구성 옵션, 유형(문자열, 부울 등), 기본값, 프롬프트 문자열 등이 있습니다.
예를 들어 report_Logger
이벤트는 출력 파일 이름을 매개 변수로 허용합니다. 각각의 event_name.xml
파일을 사용하여 ABRT GUI는 선택된 이벤트에 대해 지정할 수 있는 매개 변수를 결정하고 사용자가 이러한 매개변수에 대한 값을 설정할 수 있습니다. 값은 ABRT GUI에 의해 저장되고 이러한 이벤트의 후속 호출에 재사용됩니다. ABRT GUI는 GNOME 키 링 도구를 사용하여 구성 옵션을 저장하고 이벤트에 전달하여 텍스트 구성 파일의 데이터를 덮어씁니다.
그래픽 구성
창을 열려면 gnome-abrt 애플리케이션의 실행 중인 인스턴스 내에서 → → → → 선택합니다. 이 창에는 GUI 를 사용할 때 보고 프로세스 중에 선택할 수 있는 이벤트 목록이 표시됩니다. 구성 가능한 이벤트 중 하나를 선택하면 버튼을 클릭하고 해당 이벤트의 설정을 수정할 수 있습니다.
그림 25.1. ABRT 이벤트 구성
/etc/libreport/
디렉토리 계층에 있는 모든 파일은 사용자가 읽을 수 있으며 전역 설정으로 사용해야 합니다. 따라서 사용자 이름, 암호 또는 기타 중요한 데이터를 저장하는 것이 좋습니다. 사용자별 설정( GUI 애플리케이션의 설정 및 $HOME
전용 소유자에 의해 읽기)은 GNOME 키링 에 안전하게 저장되거나, abrt-cli
와 함께 사용하기 위해 $HOME/.abrt/
의 텍스트 구성 파일에 저장할 수 있습니다.
다음 표는 ABRT 의 표준 설치에 의해 제공되는 기본 분석, 수집 및 보고 이벤트의 선택을 보여줍니다. 표에는 각 이벤트 이름, 식별자, /etc/libreport/events.d/
디렉터리의 구성 파일, 간단한 설명이 나열됩니다. 구성 파일은 이벤트 식별자를 사용하지만 ABRT GUI는 해당 이름을 사용하여 개별 이벤트를 참조합니다. 또한 GUI 를 사용하여 모든 이벤트를 설정할 수 있는 것은 아닙니다. 사용자 지정 이벤트를 정의하는 방법에 대한 자세한 내용은 25.3.2절. “사용자 지정 이벤트 생성” 을 참조하십시오.
이름 | 식별자 및 구성 파일 | 설명 |
---|---|---|
uReport | report_uReport | octetsReport를 FAF 서버에 업로드합니다. |
mailx | report_Mailx
| Mailx 유틸리티를 통해 문제 보고서를 지정된 이메일 주소로 보냅니다. |
Bugzilla | report_Bugzilla
| Bugzilla 버그 추적기의 지정된 설치에 문제를 보고합니다. |
Red Hat 고객 지원 | report_RHTSupport
| Red Hat 기술 지원 시스템에 문제를 보고합니다. |
C 또는 C++ Crash 분석 | analyze_CCpp
| 분석을 위해 코어 덤프를 원격 역추적 서버로 전송하거나 원격에 실패하는 경우 로컬 분석을 수행합니다. |
보고서 업로드기 | report_Uploader
|
문제 데이터가 있는 tarball( |
VM 코어 분석 | analyze_VMcore
|
커널 oops의 문제 데이터에서 GDB (GNU 디버거)를 실행하고 커널의 |
로컬 GNU Debugger | analyze_LocalGDB
|
애플리케이션의 문제 데이터에서 GDB (GNU 디버거)를 실행하고 프로그램의 |
.xsession-errors 수집 | analyze_xsession_errors
|
관련 행을 |
logger | report_Logger
| 문제 보고서를 생성하여 지정된 로컬 파일에 저장합니다. |
kerneloops.org | report_Kerneloops
| kerneloops.org의 oops 추적기에 커널 문제를 보냅니다. |
25.3.2. 사용자 지정 이벤트 생성
각 이벤트는 각 구성 파일에서 하나의 규칙 구조에 의해 정의됩니다. 구성 파일은 일반적으로 /etc/libreport/events.d/
디렉터리에 저장됩니다. 이러한 구성 파일은 기본 구성 파일 /etc/libreport/report_event.conf
에 의해 로드됩니다. abrt는 /etc/libreport/events.d/
에 포함된 스크립트를 실행하므로 기본 구성 파일을 편집할 필요가 없습니다. 이 파일은 쉘 메타 문자(예: *, $, ?)를 수락하고 해당 위치에 상대적으로 상대 경로를 해석합니다.
각 규칙은 공백이 아닌 문자로 시작하는 줄로 시작하며 공백
문자 또는 탭
문자로 시작하는 모든 후속 줄은 이 규칙의 일부로 간주됩니다. 각 규칙은 조건 부분인 두 부분, 즉 프로그램 부분으로 구성됩니다. 조건 부분에는 다음 형식 중 하나에 있는 조건이 포함됩니다.
- VAR=VAL
- VAR!=VAL
- VAL~=REGEX
다음과 같습니다.
-
VAR 은 EventsENT 키 단어의 이름이나 problem-data 디렉터리 요소의 이름(예:
실행 가능
,패키지
,호스트
이름 등)입니다. - VAL 은 이벤트 또는 problem-data 요소의 이름입니다.
- REGEX 는 정규식입니다.
프로그램 부분은 프로그램 이름 및 쉘 해석 코드로 구성됩니다. 조건 부분의 모든 조건이 유효한 경우 프로그램 부분은 쉘에서 실행됩니다. 다음은 이벤트 예입니다.
EVENT=post-create date > /tmp/dt
echo $HOSTNAME uname -r
이 이벤트는 /tmp/dt
파일의 내용을 현재 날짜와 시간으로 덮어쓰고 표준 출력에서 시스템의 호스트 이름과 해당 커널 버전을 출력합니다.
다음은 실제로 사전 정의된 이벤트 중 하나인 더 복잡한 이벤트의 예입니다. 충돌 시 X11 라이브러리가 로드된 경우, abrt-ccpp
서비스가 사용된 문제의 문제 보고서에 관련 행을 ~/.xsession-errors
파일에 저장합니다.
EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=./libX11.
test -f ~/.xsession-errors || { echo "No ~/.xsession-errors"; exit 1; }
test -r ~/.xsession-errors || { echo "Can't read ~/.xsession-errors"; exit 1; }
executable=cat executable
&&
base_executable=${executable##*/} &&
grep -F -e "$base_executable" ~/.xsession-errors | tail -999 >xsession_errors &&
echo "Element 'xsession_errors' saved"
가능한 이벤트 세트는 확정되지 않습니다. 시스템 관리자는 /etc/libreport/events.d/
디렉토리에 필요에 따라 이벤트를 추가할 수 있습니다.
현재 다음 이벤트 이름에는 표준 ABRT 및 libreport 설치가 제공됩니다.
post-create
-
이 이벤트는 새로 생성된 problem-data 디렉토리를 처리하기 위해
abrtd
에 의해 실행됩니다.post-create
이벤트가 실행되면abrtd
는 새 문제 데이터가 이미 존재하는 문제 디렉터리 중 하나와 일치하는지 확인합니다. 이러한 문제 디렉터리가 있는 경우 업데이트되며 새 문제 데이터가 삭제됩니다.post-create
이벤트 정의의 스크립트가 0이 아닌 값으로 종료되면abrtd
는 프로세스를 종료하고 문제 데이터를 삭제합니다. notify
,notify-dup
-
알림
이벤트는생성 후
실행됩니다. 이벤트가 실행되면 사용자는 문제가 주의를 받을 자격이 있는지 확인할 수 있습니다. 동일한 문제의 중복 발생에 사용되는 경우를 제외하고 알림
은 비슷합니다. analyze_name_suffix
-
여기서 name_suffix 는 이벤트 이름의 교체 가능한 부분입니다. 이 이벤트는 수집된 데이터를 처리하는 데 사용됩니다. 예를 들어
analyze_LocalGDB
이벤트는GDB(GNU Debugger) 유틸리티를 사용하여 애플리케이션의 코어 덤프를 처리하고 충돌의 역추적을 생성합니다. collect_name_suffix
{blank}
여기서 name_suffix 는 이벤트 이름의 조정 가능한 부분입니다. 이 이벤트는 문제에 대한 추가 정보를 수집하는 데 사용됩니다.
report_name_suffix
{blank}
여기서 name_suffix 는 이벤트 이름의 조정 가능한 부분입니다. 이 이벤트는 문제를 보고하는 데 사용됩니다.
25.3.3. 자동 보고 설정
ABRT 는 초기 익명 보고서 또는 감지된 문제 또는 사용자 상호 작용 없이 자동으로 감지된 문제 또는 충돌을 보내도록 구성할 수 있습니다. 자동 보고가 켜지면 일반적으로 충돌 보고 프로세스의 시작 부분에 전송되는 keepalivedReport라고 하는 자동 보고가 감지된 직후 전송됩니다. 이렇게 하면 동일한 충돌에 따라 중복 지원 케이스가 발생하지 않습니다. 자동 보고 기능을 활성화하려면 root
로 다음 명령을 실행합니다.
~]# abrt-auto-reporting enabled
위의 명령은 /etc/abrt/abrt.conf
구성 파일의 AutoreportingEnabled
지시문을 yes
로 설정합니다. 이 시스템 전체 설정은 시스템의 모든 사용자에게 적용됩니다. 이 옵션을 활성화하면 그래픽 데스크탑 환경에서 자동 보고도 활성화됩니다. ABRT GUI에서 자동 보고를 활성화하려면 문제 보고 구성
창에서 자동으로 uReport
옵션을 YES
로 전환합니다. 이 창을 열려면 gnome-abrt 애플리케이션의 실행 중인 인스턴스 내에서 → → → → 구성을 선택합니다. 애플리케이션을 시작하려면 → → → → → → 으로 이동합니다.
그림 25.2. ABRT 문제 보고 구성
충돌 탐지 시 ABRT 는 Red Hat의 ABRT 서버에 대한 기본 정보와 함께 octetsReport를 제출합니다. 서버는 문제를 알 수 있는지 여부를 확인하고, 알려진 경우 보고된 케이스의 URL 과 함께 문제에 대한 간단한 설명을 제공하거나 알 수 없는 경우 사용자에게 보고하도록 초대합니다.
octetsReport(microreport)는 문제를 나타내는 JSON 오브젝트(예: 바이너리 충돌 또는 커널 oops)입니다. 이러한 보고서는 짧고 머신에서 읽을 수 있는 완전한 익명이 되도록 설계되었으므로 자동화된 보고에 사용할 수 있습니다. octetsReports는 버그 발생을 추적할 수 있지만 일반적으로 엔지니어가 버그를 수정할 수 있는 충분한 정보를 제공하지 않습니다. 지원 케이스를 개설하려면 전체 버그 보고서가 필요합니다.
octetsReport를 전송하지 못하도록 자동 보고 기능의 기본 동작을 변경하려면 /etc/abrt/abrt.conf
구성 파일의 AutoreportingEvent
지시문 값을 수정하여 다른 ABRT 이벤트를 가리키도록 합니다. 표준 이벤트 개요는 표 25.1. “표준 ABRT 이벤트” 을 참조하십시오.
25.4. 소프트웨어 문제 탐지
ABRT 는 다양한 프로그래밍 언어로 작성된 애플리케이션에서 크래시를 감지, 분석 및 처리할 수 있습니다. 주요 ABRT 패키지 (abrt-1.8.0 , abrt- cli) 중 하나가 설치되면 다양한 유형의 충돌을 감지하는 지원이 포함된 많은 패키지가 자동으로 설치됩니다. ABRT 를 설치하는 방법에 대한 지침은 25.2절. “ABRT 설치 및 서비스 시작” 을 참조하십시오. 지원되는 충돌 유형 및 해당 패키지 목록은 아래 표를 참조하십시오.
langauge/Project | 패키지 |
---|---|
C 또는 C++ | abrt-addon-ccpp |
Python | abrt-addon-python |
Ruby | rubygem-abrt |
Java | abrt-java-connector |
X.Org | abrt-addon-xorg |
Linux (kernel oops) | abrt-addon-kerneloops |
Linux (커널 패닉) | abrt-addon-vmcore |
Linux(영구 스토리지) | abrt-addon-pstoreoops |
25.4.1. C 및 C++ Crashes 검색
abrt-ccpp
서비스는 자체 core-dump 처리기를 설치합니다. 이 핸들러는 커널의 core_
octets 변수의 기본값을 덮어씁니다. 그러면 C 및 C++ 충돌은 abrtd
에서 처리합니다. abrt-ccpp
서비스를 중지하면 이전에 지정된 core_octets 값이 복원
됩니다.
기본적으로 /proc/sys/kernel/
octets 파일에는 코어 코어가 포함되어 있습니다. 즉, 커널이 충돌한 프로세스의 현재 디렉터리에 core
_core.
접두사가 있는 파일을 생성합니다. abrt-ccpp
서비스는 core_hiera 파일을
덮어쓰고 다음 명령을 포함합니다.
|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e
이 명령은 코어 덤프를 abrt-hook-ccpp
프로그램으로 전달하여 ABRT의 덤프 위치에 저장하고 새 크래시의 abrtd
데몬을 알리는 것을 커널에 지시합니다. 또한 디버깅을 위해 /proc/PID/ 디렉터리(여기서 PID
는 충돌된 프로세스의 ID)에서 다음 파일을 저장합니다. map
,limits
,cgroup
,status
. 형식에 대한 설명과 이러한 파일의 의미는 proc(5)를 참조하십시오.
25.4.2. Python 예외 탐지
abrt-addon-python 패키지는 Python 애플리케이션에 대한 사용자 정의 예외 핸들러를 설치합니다. 그런 다음 Python 인터프리터는 /usr/lib64/python2.7/site-packages/
에 설치된 abrt.pth
파일을 자동으로 가져옵니다. 그러면 abrt_exception_handler.py
가 자동으로 가져옵니다. 이렇게 하면 Socket API를 통해 처리되지 않은 예외를 abrtd
로 전달하는 사용자 정의 처리기를 사용하여 Python의 기본 sys.excepthook
가 재정의됩니다.
사이트별 모듈의 자동 가져오기를 비활성화하여 Python 애플리케이션을 실행할 때 ABRT 사용자 지정 예외 핸들러가 사용되지 않도록 하려면 -S
옵션을 Python 인터프리터에 전달합니다.
~]$ python -S file.py
위의 명령에서 file.py 를 사이트별 모듈을 사용하지 않고 실행하려는 Python 스크립트의 이름으로 바꿉니다.
25.4.3. Ruby 예외 탐지
rubygem-abrt 패키지는 프로그램이 종료될 때 실행되는 at_exit
기능을 사용하여 사용자 정의 핸들러를 등록합니다. 이를 통해 처리되지 않은 가능한 예외를 확인할 수 있습니다. 처리되지 않은 예외가 캡처될 때마다 ABRT 핸들러는 표준 ABRT 툴을 사용하여 Red Hat Bugzilla에 제출할 수 있는 버그 보고서를 준비합니다.
25.4.4. Java 예외 탐지
ABRT Java Connector는 예기치 않은 Java 예외를 abrtd
에 보고하는 JVM 에이전트입니다. 에이전트는 여러 JVMTI 이벤트 콜백을 등록하며 -agentlib
명령줄 매개 변수를 사용하여 JVM 에 로드해야 합니다. 등록된 콜백의 처리는 애플리케이션의 성능에 부정적인 영향을 미칩니다. 다음 명령을 사용하여 ABRT catch 예외를 Java 클래스로 가져옵니다.
~]$ java -agentlib:abrt-java-connector=abrt=on $MyClass -platform.jvmtiSupported true
위의 명령에서 $MyClass 를 테스트하려는 Java 클래스의 이름으로 바꿉니다. abrt=on
옵션을 커넥터에 전달하면 abrtd
에서 예외를 처리해야 합니다. 커넥터가 표준 출력에 예외를 출력하도록 하려면 이 옵션을 생략합니다.
25.4.5. X.Org Crashes 검색
abrt-xorg
서비스는 /var/log/Xorg .0.log파일에서 X.Org 서버
의 충돌에 대한 정보를 수집하고 처리합니다. 블랙리스트로 지정된 X.org 모듈이 로드되면 보고서가 생성되지 않습니다. 대신 적절한 설명을 사용하여 보고할 수 없는
파일이 problem-data 디렉터리에 생성됩니다. /etc/abrt/plugins/xorg.conf
파일에서 잘못된 모듈 목록을 찾을 수 있습니다. 독점형 그래픽 드라이버 모듈만 기본적으로 블랙리스트에 추가됩니다.
25.4.6. 커널 Oops 및 Panics 감지
커널 로그 출력을 확인함으로써 ABRT 는 so- called kernel oopses - Linux 커널의 올바른 동작에서 치명적이지 않은 변동을 포착하고 처리할 수 있습니다. 이 기능은 abrt-oops
서비스에서 제공합니다.
ABRT 는 또한 abrt-vmcore
서비스를 사용하여 재부팅이 필요한 치명적이고 복구할 수 없는 오류인 커널 패닉을 감지하고 처리할 수 있습니다. 이 서비스는 vmcore
파일(커널 코어 덤프)이 /var/crash/
디렉터리에 표시되는 경우에만 시작됩니다. core-dump 파일이 발견되면 abrt-vmcore
에서 /var/spool/abrt/
디렉터리에 새 problem-data
디렉터리를 생성하고 core-dump 파일을 새로 생성된 problem-data 디렉터리에 복사합니다. /var/crash/
디렉토리를 검색하면 서비스가 중지됩니다.
ABRT 가 커널 패닉을 감지하려면 시스템에서 kdump
서비스를 활성화해야 합니다. kdump 커널용으로 예약된 메모리 양을 올바르게 설정해야 합니다. system-config-kdump 그래픽 도구를 사용하거나 GRUB 2 메뉴의 커널 옵션 목록에 crashkernel
매개변수를 지정하여 설정할 수 있습니다. kdump
를 활성화 및 구성하는 방법에 대한 자세한 내용은 Red Hat Enterprise Linux 7 Kernel Crash Dump Guide 를 참조하십시오. GRUB 2 메뉴를 변경하는 방법에 대한 자세한 내용은 26장. Working with GRUB 2 를 참조하십시오.
abrt-pstoreoops
서비스를 사용하여 ABRT 는 커널 패닉에 대한 정보를 수집하고 처리할 수 있으며, 이는 pstore 를 지원하는 시스템에서 자동으로 마운트된 /sys/fs/pstore/
디렉토리에 저장됩니다. 플랫폼 종속 pstore 인터페이스(영구 스토리지)는 시스템 재부팅 사이에 데이터를 저장하는 메커니즘을 제공하므로 커널 패닉 정보를 유지할 수 있습니다. 커널 크래시 덤프 파일이 /sys/fs/pstore/
디렉터리에 표시되면 서비스가 자동으로 시작됩니다.
25.5. 발견된 문제 처리
abrtd
에서 저장한 문제 데이터는 명령줄 도구, abrt-cli
또는 그래픽 도구인 gnome-abrt
를 사용하여 보고, 보고, 삭제할 수 있습니다.
ABRT 는 새로운 문제를 로컬에 저장된 모든 문제와 비교하여 중복 문제를 식별합니다. 반복적인 충돌의 경우 ABRT 는 한 번만 수행해야 합니다. 그러나 해당 문제의 크래시 덤프를 삭제하면 다음에 이 특정 문제가 발생하면 ABRT 는 이를 새로운 충돌로 처리합니다. ABRT 는 이에 대해 경고하고 설명을 작성하라는 메시지를 표시하고 보고합니다. ABRT 가 반복적인 문제에 대해 사용자에게 알리는 것을 방지하려면 해당 문제 데이터를 삭제하지 마십시오.
25.5.1. 명령줄 도구 사용
명령줄 환경에서 abrt-console-notification 패키지가 설치되어 있는 경우 로그인 시 새 충돌을 사용자에게 알립니다. 콘솔 알림은 다음과 같습니다.
ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1398783164
감지된 문제를 보려면 abrt-cli list
명령을 입력합니다.
~]$ abrt-cli list
id 6734c6f1a1ed169500a7bfc8bd62aabaf039f9aa
Directory: /var/tmp/abrt/ccpp-2014-04-21-09:47:51-3430
count: 1
executable: /usr/bin/sleep
package: coreutils-8.22-11.el7
time: Mon 21 Apr 2014 09:47:51 AM EDT
uid: 1000
Run 'abrt-cli report /var/tmp/abrt/ccpp-2014-04-21-09:47:51-3430' for creating a case in Red Hat Customer Portal
명령 출력에 나열된 각 충돌에는 고유한 식별자와 abrt-cli를 사용하여 추가 조작에 사용할 수 있는 디렉터리가 있습니다.
abrt-cli
list
특정 문제에 대한 정보를 보려면 abrt-cli info
명령을 사용하십시오.
abrt-cli info -d directory_or_id
목록
및 정보 하위 명령을 모두 사용할 때 표시되는 정보
양을 늘리려면 -d
(-detailed
) 옵션을 전달하십시오. 이 옵션은 나열된 문제에 대한 모든 저장된 정보를 표시합니다(예: 이미 생성된 경우 해당 역추적
파일 포함).
특정 문제를 분석하고 보고하려면 abrt-cli report
명령을 사용합니다.
abrt-cli report directory_or_id
위의 명령을 호출하면 Red Hat 고객 지원을 통해 지원 사례를 열기 위한 자격 증명을 제공해야 합니다. 다음으로 abrt-cli
는 보고서의 내용이 포함된 텍스트 편집기를 엽니다. 보고되는 내용을 볼 수 있으며 충돌 및 기타 의견을 재현하는 방법에 대한 지침을 작성할 수 있습니다. 또한 문제 보고 이벤트 설정에 따라 역추적이 공용 서버로 전송되고 모든 사람이 볼 수 있으므로 역추적을 확인해야 합니다.
보고서를 확인하는 데 사용되는 텍스트 편집기를 선택할 수 있습니다. abrt-cli
는 ABRT_EDITOR
환경 변수에 정의된 편집기를 사용합니다. 변수가 정의되지 않은 경우 VISUAL
및 EDITOR
변수를 확인합니다. 이러한 변수가 설정되지 않은 경우 vi
편집기가 사용됩니다. .bashrc
구성 파일에서 기본 편집기를 설정할 수 있습니다. 예를 들어 GNU 4.5.2를 선호하는 경우 파일에 다음 행을 추가합니다.
exportVISUAL
=emacs
보고서를 완료하면 변경 사항을 저장하고 편집기를 종료합니다. Red Hat 고객 지원 데이터베이스에 문제를 보고한 경우 데이터베이스에 문제가 제출됩니다. 이제부터 보고 과정에서 제공한 이메일을 통해 문제 해결 진행 상황을 알려 드릴 것입니다. 문제 케이스를 작성하거나 Red Hat 지원팀에서 수신한 이메일을 통해 제공되는 URL을 사용하여 문제 사례를 모니터링할 수도 있습니다.
특정 문제를 보고하지 않으려면 이를 삭제할 수 있습니다. 문제를 삭제하려면 ABRT 가 해당 정보를 유지하지 않도록 명령을 사용합니다.
abrt-cli rm directory_or_id
특정 abrt-cli
명령에 대한 도움말을 표시하려면 --help
옵션을 사용합니다.
abrt-cli command --help
25.5.2. GUI 사용
ABRT 데몬은 문제 보고서가 생성될 때마다 D-Bus
메시지를 브로드캐스트합니다. ABRT revision이 그래픽 데스크탑 환경에서 실행 중인 경우 이 메시지를 캡처하고 데스크탑에 알림 대화 상자를 표시합니다. 버튼을 클릭하여 이 대화 상자를 사용하여 ABRT GUI를 열 수 있습니다. 또한 → → → + → → ABRT GUI를 열 수 있습니다.
또는 다음과 같이 명령줄에서 ABRT GUI를 실행할 수 있습니다.
~]$ gnome-abrt &
ABRT GUI 창에 감지된 문제 목록이 표시됩니다. 각 문제 항목은 실패한 애플리케이션의 이름, 애플리케이션이 충돌한 이유, 마지막으로 발생한 문제의 날짜로 구성됩니다.
그림 25.3. ABRT GUI
자세한 문제 설명에 액세스하려면 문제 보고 행을 두 번 클릭하거나 해당 문제 줄이 선택된 상태에서
버튼을 클릭합니다. 그런 다음 지침을 따라 문제를 설명하고 분석 방법을 결정하고 보고해야 할 위치를 결정할 수 있습니다. 문제를 삭제하려면 버튼을 클릭합니다.25.6. 추가 리소스
ABRT 및 관련 항목에 대한 자세한 내용은 아래 나열된 리소스를 참조하십시오.
설치된 문서
-
abrtd(8) -
abrtd
데몬의 도움말 페이지는 데몬과 함께 사용할 수 있는 옵션에 대한 정보를 제공합니다. -
abrt_event.conf구성 파일의 도움말 페이지는
abrt_event.conf
구성 파일의 형식을 설명하고 XML 파일의 이벤트 메타 데이터 구성에 대한 참조 정보를 제공합니다.
온라인 문서
- Red Hat Enterprise Linux 7 네트워킹 가이드 - 이 시스템의 네트워크 인터페이스 및 네트워크 서비스의 구성 및 관리와 관련된 Red Hat Enterprise Linux 7의 네트워킹 가이드.
-
Red Hat Enterprise Linux 7 Kernel Crash Dump Guide - Red Hat Enterprise Linux 7용 Kernel Crash Dump Guide -
kdump
충돌 복구 서비스를 설정, 테스트 및 사용하는 방법과 충돌 디버깅 유틸리티를 사용하여 결과 코어 덤프를 분석하는 방법에 대한 간략한 개요를 제공합니다.
예를 들면 다음과 같습니다.
-
23장. 로그 파일 보기 및 관리
rsyslog
데몬 및 systemd 저널의 구성을 설명하고 시스템 로그를 찾고, 보고, 모니터링하는 방법을 설명합니다. - 9장. yum YUM 패키지 관리자를 사용하여 명령줄에서 패키지를 검색, 설치, 업데이트 및 제거하는 방법을 설명합니다.
-
10장. systemd를 사용하여 서비스 관리
systemctl
명령을 사용하여 시스템 서비스를 관리하고,systemd
대상을 구성하고, 전원 관리 명령을 실행하는 방법을 systemd 및 문서에 대해 소개합니다.
VII 부. Bootloader를 사용하여 커널 사용자 지정
이 부분에서는 GRUB 2 부트로더를 사용하여 커널 사용자 지정 관리자를 지원하는 방법을 설명합니다.
26장. Working with GRUB 2
Red Hat Enterprise Linux 7은 GNU GRand Unified Bootloader (GRUB 2)의 버전 2와 함께 배포되므로 사용자가 시스템 부팅 시 로드할 운영 체제 또는 커널을 선택할 수 있습니다. 또한 GRUB 2는 사용자가 커널에 인수를 전달할 수 있도록 합니다.
26.1. GRUB 2 소개
GRUB 2는 기존 BIOS 기반 시스템의 /boot/grub2/grub.cfg
파일과 UEFI 시스템의 /boot/efi/EFI/redhat/grub.cfg
파일에서 해당 설정을 읽습니다. 이 파일에는 메뉴 정보가 포함되어 있습니다.
GRUB 2 설정 파일인 grub.cfg
, 는 설치 중에 생성되거나 /usr/sbin/grub2-mkconfig 유틸리티를 호출하여 생성되며 새 커널이 설치될 때마다 grubby
에 의해 자동으로 업데이트됩니다. grub2-mkconfig 를 사용하여 수동으로 다시 생성하면 /etc/grub.d/
에 있는 템플릿 파일과 /etc/default/grub
파일의 사용자 지정 설정에 따라 파일이 생성됩니다. grub.cfg
의 편집은 파일을 다시 생성하는 데 언제든지 grub2-mkconfig 가 손실되므로 /etc/default/grub
의 수동 변경 사항을 반영하려면 주의해야 합니다.
새 커널 제거 및 추가와 같은 grub.cfg
의 일반적인 작업은 grubby
툴을 사용하여 수행해야 하며, 스크립트의 경우 new-kernel-pkg
툴을 사용해야 합니다. grubby
를 사용하여 기본 커널을 수정하면 새 커널이 설치되면 변경 사항이 상속됩니다. grubby
에 대한 자세한 내용은 26.4절. “grubby 도구를 사용하여 GRUB 2 메뉴의 영구 변경 사항 만들기” 을 참조하십시오.
/etc/default/grub
파일은 설치 프로세스 중에 grub.cfg
를 생성할 때 anaconda
에서 사용하는 grub2-mkconfig
도구에서 사용하며, 시스템 오류 발생시 시스템 오류 발생시 사용할 수 있습니다(예: 부트 로더 구성을 다시 생성해야 하는 경우). 일반적으로 마지막 수단으로 아닌 grub2-mkconfig
를 수동으로 실행하여 grub.cfg
파일을 대체하지 않는 것이 좋습니다. /etc/default/grub
을 수동으로 변경하려면 grub.cfg
파일을 다시 빌드해야 합니다.
grub.cfg의 메뉴 항목
다양한 코드 조각 및 지시문 중에 grub.cfg
설정 파일에는 단일 GRUB 2 부팅 메뉴
항목을 나타내는 하나 이상의 메뉴 항목이 포함되어 있습니다. 이러한 블록은 항상 menuentry
키워드로 시작한 다음 제목, 옵션 목록, 열린 curly 브래킷으로 시작하고 닫는 curly 브래킷으로 끝납니다. 열기 및 닫기 브래킷 사이의 모든 내용을 들여쓰기해야 합니다. 예를 들어 다음은 Linux 커널 3.8.0-0.40.el7.x86_64를 사용하는 Red Hat Enterprise Linux 7의 샘플 메뉴 입력
블록입니다.
menuentry 'Red Hat Enterprise Linux Server' --class red --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-c60731dc-9046-4000-9182-64bdcce08616' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod xfs set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1' 19d9e294-65f8-4e37-8e73-d41d6daa6e58 else search --no-floppy --fs-uuid --set=root 19d9e294-65f8-4e37-8e73-d41d6daa6e58 fi echo 'Loading Linux 3.8.0-0.40.el7.x86_64 ...' linux16 /vmlinuz-3.8.0-0.40.el7.x86_64 root=/dev/mapper/rhel-root ro rd.md=0 rd.dm=0 rd.lvm.lv=rhel/swap crashkernel=auto rd.luks=0 vconsole.keymap=us rd.lvm.lv=rhel/root rhgb quiet echo 'Loading initial ramdisk ...' initrd /initramfs-3.8.0-0.40.el7.x86_64.img }
설치된 Linux 커널을 나타내는 각 메뉴 입력
블록에는 64비트 IBM POWER 시리즈의
, x86_64 BIOS 기반 시스템의 linux16, UEFI 기반 시스템의 linux
linuxefi
가 포함되어 있습니다. 그런 다음 initrd 지시문 뒤에 커널의 경로와
initramfs
이미지 경로가 각각 있습니다. 별도의 /boot
파티션이 생성된 경우 커널 및 initramfs
이미지에 대한 경로는 /boot
를 기준으로 합니다. 위의 예에서 initrd /initramfs-3.8.0-0.40.el7.x86_64.img
줄은 initramfs
이미지가 실제로 /boot/initramfs-3.8.0-0.40.el7.el7.x86_64.img에 있고 커널 경로에 대해 마찬가지로 initramfs 이미지가 /boot/initramfs-3.8.0-0.
el7.x86_64.img에 있음을 의미합니다.
linux16 /vmlinuz-kernel_version
행에 지정된 커널 버전 번호는 각 menuentry
블록의 initrd /initramfs-kernel_version.img
줄에 제공된 initramfs
이미지의 버전 번호와 일치해야 합니다. 초기 RAM 디스크 이미지를 확인하는 방법에 대한 자세한 내용은 Red Hat Enterprise 7 커널 관리 가이드 를 참조하십시오.
menuentry
블록에서 initrd
지시문은 동일한 커널 버전에 해당하는 initramfs
파일의 위치( /boot/
디렉토리를 별도의 파티션에 있는 경우)를 가리켜야 합니다. 초기 RAM 디스크 이미지인 mk initrd
, mkrd 파일라는 이전 도구가 생성되었기 때문에 이 지시문을 initrd
라고
합니다. grub.cfg
지시문은 다른 툴과 의
호환성을 유지하기 위해 initrd로 유지됩니다. dracut
유틸리티를 사용하여 초기 RAM 디스크 이미지를 생성하는 시스템의 파일-naming 규칙은 initramfs-kernel_version.img
입니다.
Dracut 에 대한 자세한 내용은 Red Hat Enterprise 7 커널 관리 가이드 를 참조하십시오.
26.2. GRUB 2 설정
GRUB 2 메뉴는 부팅할 때 임시로 변경될 수 있으며, 시스템이 실행되는 동안 단일 시스템 또는 새 GRUB 2 설정 파일을 만드는 과정의 일부로 수행할 수 있습니다.
- GRUB 2 메뉴를 비영구적으로 변경하려면 26.3절. “GRUB 2 메뉴의 임시 변경 사항 만들기” 를 참조하십시오.
- 실행 중인 시스템을 지속적으로 변경하려면 26.4절. “grubby 도구를 사용하여 GRUB 2 메뉴의 영구 변경 사항 만들기” 를 참조하십시오.
- GRUB 2 설정 파일 만들기 및 사용자 지정에 대한 자세한 내용은 26.5절. “GRUB 2 구성 파일 사용자 지정” 을 참조하십시오.
26.3. GRUB 2 메뉴의 임시 변경 사항 만들기
커널 메뉴 항목을 임시로 변경
단일 부팅 프로세스 중에만 커널 매개 변수를 변경하려면 다음과 같이 진행하십시오.
- 시스템을 시작하고 GRUB 2 부팅 화면에서 편집하려는 메뉴 항목으로 커서를 이동한 후 편집용 e 키를 누릅니다.
-
커서를 아래로 이동하여 커널 명령행을 찾습니다. 커널 명령행은 64비트 IBM Power Series, x86-64 BIOS 기반 시스템의
linux
16linuxefi
에서 시작합니다. 커서를 줄의 끝으로 이동합니다.
Ctrl+a 및 Ctrl+e 를 눌러 각 줄의 시작 및 끝으로 건너뜁니다. 일부 시스템에서는 홈 및 종료일 도 작동할 수 있습니다.
필요에 따라 커널 매개 변수를 편집합니다. 예를 들어 시스템을 긴급 모드로 실행하려면
linux16
행 끝에 emergency 매개변수를 추가합니다.linux16 /vmlinuz-3.10.0-0.rc4.59.el7.x86_64 root=/dev/mapper/rhel-root ro rd.md=0 rd.dm=0 rd.lvm.lv=rhel/swap crashkernel=auto rd.luks=0 vconsole.keymap=us rd.lvm.lv=rhel/root rhgb quiet emergency
시스템 메시지를 활성화하기 위해
rhgb
및quiet
매개 변수를 제거할 수 있습니다.이러한 설정은 영구적이 아니며 단일 부팅에만 적용됩니다. 시스템의 메뉴 항목을 영구적으로 변경하려면
grubby
툴을 사용합니다.grubby
사용에 대한 자세한 내용은 “GRUB 2 메뉴 항목에서 인수 추가 및 제거” 을 참조하십시오.
26.4. grubby 도구를 사용하여 GRUB 2 메뉴의 영구 변경 사항 만들기
grubby
툴을 사용하여 에서 정보를 읽고 grub.cfg
파일을 영구적으로 변경할 수 있습니다. 예를 들어 GRUB 2 메뉴 항목을 변경하여 시스템 시작 시 커널에 전달할 인수를 지정하고 기본 커널을 변경할 수 있습니다.
Red Hat Enterprise Linux 7에서 GRUB 2 구성 파일을 지정하지 않고 grubby
가 수동으로 호출되는 경우 기본값은 /etc/grub2.cfg .cfg를 검색합니다. 이 기본값은 /etc/grub2.cfg
.cfg.이 링크인 grub.cfg
파일에 대한 심볼릭 링크인 grub.cfg 파일에 종속되어 있습니다. 해당 파일을 찾을 수 없는 경우 아키텍처 종속적 기본값을 검색합니다.
기본 커널 나열
기본 커널의 파일 이름을 찾으려면 다음과 같이 명령을 입력합니다.
~]# grubby --default-kernel /boot/vmlinuz-3.10.0-229.4.2.el7.x86_64
기본 커널의 인덱스 번호를 찾으려면 다음과 같이 명령을 입력합니다.
~]# grubby --default-index 0
기본 부팅 항목 변경
기본 커널로 지정된 커널을 영구적으로 변경하려면 다음과 같이 grubby
명령을 사용합니다.
~]# grubby --set-default /boot/vmlinuz-3.10.0-229.4.2.el7.x86_64
커널용 GRUB 2 메뉴 항목 보기
커널 메뉴 항목을 모두 나열하려면 다음과 같이 명령을 입력합니다.
~]$ grubby --info=ALL
UEFI 시스템에서 모든 grubby
명령을 root
로 입력해야 합니다.
특정 커널의 GRUB 2 메뉴 항목을 보려면 다음과 같이 명령을 입력합니다.
~]$ grubby --info /boot/vmlinuz-3.10.0-229.4.2.el7.x86_64 index=0 kernel=/boot/vmlinuz-3.10.0-229.4.2.el7.x86_64 args="ro rd.lvm.lv=rhel/root crashkernel=auto rd.lvm.lv=rhel/swap vconsole.font=latarcyrheb-sun16 vconsole.keymap=us rhgb quiet LANG=en_US.UTF-8" root=/dev/mapper/rhel-root initrd=/boot/initramfs-3.10.0-229.4.2.el7.x86_64.img title=Red Hat Enterprise Linux Server (3.10.0-229.4.2.el7.x86_64) 7.0 (Maipo)
탭 완료를 시도하여 /boot/
디렉터리 내에서 사용 가능한 커널을 확인합니다.
GRUB 2 메뉴 항목에서 인수 추가 및 제거
--update-kernel
옵션은 --args
와 함께 사용할 때 메뉴 항목을 업데이트하여 기존 인수를 제거하기 위해 새 인수 및 --remove-arguments
를 추가할 수 있습니다. 이러한 옵션에는 따옴표로 구분된 공백으로 구분된 목록이 허용됩니다. GRUB 2 메뉴 항목에서 동시에 인수를 추가하고 제거하는 명령은 다음과 같습니다.
grubby --remove-args="argX argY" --args="argA argB" --update-kernel /boot/kernel
커널의 GRUB 2 메뉴 항목에서 인수를 추가하고 제거하려면 다음과 같이 명령을 사용하십시오.
~]# grubby --remove-args="rhgb quiet" --args=console=ttyS0,115200 --update-kernel /boot/vmlinuz-3.10.0-229.4.2.el7.x86_64
이 명령은 Red Hat 그래픽 부팅 인수를 제거하고 부팅 메시지를 표시하고 직렬 콘솔을 추가합니다. 콘솔 인수가 행 마지막에 추가되므로 새 콘솔이 구성된 다른 콘솔보다 우선합니다.
변경 사항을 검토하려면 다음과 같이 --info
명령 옵션을 사용합니다.
~]# grubby --info /boot/vmlinuz-3.10.0-229.4.2.el7.x86_64
index=0
kernel=/boot/vmlinuz-3.10.0-229.4.2.el7.x86_64
args="ro rd.lvm.lv=rhel/root crashkernel=auto rd.lvm.lv=rhel/swap vconsole.font=latarcyrheb-sun16 vconsole.keymap=us LANG=en_US.UTF-8 ttyS0,115200"
root=/dev/mapper/rhel-root
initrd=/boot/initramfs-3.10.0-229.4.2.el7.x86_64.img
title=Red Hat Enterprise Linux Server (3.10.0-229.4.2.el7.x86_64) 7.0 (Maipo)
동일한 인수를 사용하여 모든 커널 메뉴 업데이트
모든 커널 메뉴 항목에 동일한 커널 부팅 인수를 추가하려면 다음과 같이 명령을 입력합니다.
~]# grubby --update-kernel=ALL --args=console=ttyS0,115200
--update-kernel
매개변수는 DEFAULT 또는 쉼표로 구분된 커널 인덱스 번호 목록을 허용합니다.
커널 인수 변경
기존 커널 인수의 값을 변경하려면 필요에 따라 인수를 다시 지정하여 값을 변경합니다. 예를 들어 가상 콘솔 글꼴 크기를 변경하려면 다음과 같이 명령을 사용합니다.
~]# grubby --args=vconsole.font=latarcyrheb-sun32 --update-kernel /boot/vmlinuz-3.10.0-229.4.2.el7.x86_64
index=0
kernel=/boot/vmlinuz-3.10.0-229.4.2.el7.x86_64
args="ro rd.lvm.lv=rhel/root crashkernel=auto rd.lvm.lv=rhel/swap vconsole.font=latarcyrheb-sun32 vconsole.keymap=us LANG=en_US.UTF-8"
root=/dev/mapper/rhel-root
initrd=/boot/initramfs-3.10.0-229.4.2.el7.x86_64.img
title=Red Hat Enterprise Linux Server (3.10.0-229.4.2.el7.x86_64) 7.0 (Maipo)
자세한 명령 옵션은 grubby(8)
매뉴얼 페이지를 참조하십시오.
26.5. GRUB 2 구성 파일 사용자 지정
GRUB 2 스크립트는 사용자의 컴퓨터를 검색하고 스크립트가 찾은 운영 체제에 따라 부팅 메뉴를 빌드합니다. 최신 시스템 부팅 옵션을 반영하기 위해 커널이 업데이트되거나 새 커널이 추가될 때 부팅 메뉴가 자동으로 다시 빌드됩니다.
그러나 사용자는 특정 항목이 포함된 메뉴를 빌드하거나 특정 순서로 항목을 포함할 수 있습니다. GRUB 2를 사용하면 부팅 메뉴의 기본 사용자 지정을 통해 사용자에게 화면에 실제로 표시되는 내용을 제어할 수 있습니다.
GRUB 2는 일련의 스크립트를 사용하여 메뉴를 빌드합니다. /etc/grub.d/
디렉토리에 있습니다. 다음 파일이 포함되어 있습니다.
-
00_header
:/etc/default/grub
파일에서 GRUB 2 설정을 로드합니다. -
01_users
.cfg
파일에서 슈퍼 유저 암호를 읽습니다. Red Hat Enterprise Linux 7.0 및 7.1에서 이 파일은 설치 중에 부팅 암호를 정의한 경우에만 생성되었으며 일반 텍스트에 정의된 암호가 포함되었습니다. -
10_
Linux - Red Hat Enterprise Linux의 기본 파티션에서 커널을 찾습니다. -
30_OS-prober
다른 파티션에 있는 운영 체제에 대한 항목을 빌드합니다. -
40_custom
, 추가 메뉴 항목을 만드는 데 사용할 수 있는 템플릿.
/etc/grub.d/
디렉토리의 스크립트는 알파벳순으로 읽히므로 특정 메뉴 항목의 부팅 순서를 변경하기 위해 이름을 변경할 수 있습니다.
부팅 가능한 커널 목록을 숨기려면 /etc/default/grub
에서 GRUB_TIMEOUT
을 0으로 설정하지 마십시오. 이러한 설정을 사용하면 시스템은 항상 기본 메뉴 항목에서 즉시 부팅되고 기본 커널이 부팅되지 않으면 이전 커널을 부팅할 수 없습니다.
대신, 시스템이 시작될 때 GRUB 2가 부팅 가능한 커널 목록을 표시하지 못하도록하기 위해 /etc/default/grub
파일에서 GRUB_TIMEOUT_STYLE
옵션을 설정합니다.
GRUB_TIMEOUT_STYLE=hidden
목록을 부팅 할 때 목록을 표시하려면 키보드 또는 기타 직렬 콘솔을 사용하여 BIOS 정보가 표시되는 경우 영숫자 키를 누르고 GRUB 2 메뉴가 표시됩니다.
26.5.1. 기본 부팅 항목 변경
기본적으로 /etc/default/grub
파일에 있는 GRUB_DEFAULT
지시문의 키는 저장된
용어입니다. GRUB 2는 /boot/grub2/grubenv
에 있는 GRUB 2 환경 파일에 saved_entry
지시문으로 지정한 커널을 로드하도록 지시합니다. GRUB 2 환경 파일을 업데이트하는 grub2-set-default
명령을 사용하여 다른 GRUB 2 레코드를 기본값으로 설정할 수 있습니다.
기본적으로 saved_entry
값은 패키지 유형 커널의 최신 설치된 커널 이름으로 설정됩니다. 이는 UPDATEDEFAULT
및 DEFAULTKERNEL
지시문으로 /etc/sysconfig/kernel
에 정의되어 있습니다. root
사용자가 다음과 같이 파일을 볼 수 있습니다.
~]# cat /etc/sysconfig/kernel # UPDATEDEFAULT specifies if new-kernel-pkg should make # new kernels the default UPDATEDEFAULT=yes # DEFAULTKERNEL specifies the default kernel package type DEFAULTKERNEL=kernel
DEFAULTKERNEL
지시문은 기본값으로 사용할 패키지 유형을 지정합니다. DEFAULTKERNEL
이 패키지 유형 kernel로 설정되는 동안 kernel-debug 유형의 패키지를 설치하면 기본 커널 이 변경되지 않습니다.
GRUB 2는 saved_entry
지시문의 키로 숫자 값을 사용하여 운영 체제가 로드되는 기본 순서를 변경할 수 있도록 지원합니다. 먼저 로드해야 하는 운영 체제를 지정하려면 해당 번호를 grub2-set-default
명령에 전달합니다. 예를 들면 다음과 같습니다.
~]# grub2-set-default 2
목록의 메뉴 항목의 위치는 0으로 시작하는 숫자로 표시됩니다. 따라서 위 예제에서는 세 번째 항목이 로드됩니다. 이 값은 설치할 다음 커널의 이름으로 덮어씁니다.
시스템에서 항상 특정 메뉴 항목을 사용하도록 하려면 메뉴 항목 이름을 /etc/default/grub
파일의 GRUB_DEFAULT
지시문에 대한 키로 사용합니다. 사용 가능한 메뉴 항목을 나열하려면 root
로 다음 명령을 실행합니다.
~]# awk -F\' '$1=="menuentry " {print $2}' /etc/grub2.cfg
파일 이름 /etc/grub2.cfg
는 architecture에 종속된 grub.cfg
파일에 대한 심볼릭 링크입니다. 안정성의 이유로 이 장의 다른 예에서는 심볼릭 링크가 사용되지 않습니다. 특히 시스템을 복구할 때 절대 경로를 사용하는 것이 좋습니다.
/etc/default/grub
을 변경하려면 다음과 같이 grub.cfg
파일을 다시 빌드해야 합니다.
BIOS 기반 시스템에서
root
로 다음 명령을 실행합니다.~]# grub2-mkconfig -o /boot/grub2/grub.cfg
UEFI 기반 시스템에서
root
로 다음 명령을 실행합니다.~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
26.5.2. 메뉴 항목 편집
다른 매개 변수를 사용하여 새 GRUB 2 파일을 준비해야 하는 경우 /etc/default/grub
파일에서 GRUB_CMDLINE_LINUX
키 값을 편집합니다. GRUB 2 부팅 메뉴에 매개 변수를 추가하는 것과 유사하게 GRUB_CMDLINE_LINUX
키에 대해 여러 매개변수를 지정할 수 있습니다. 예를 들면 다음과 같습니다.
GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,9600n8"
여기서 console=tty0
은 첫 번째 가상 터미널이며 console=ttyS0
은 사용할 직렬 터미널입니다.
/etc/default/grub
을 변경하려면 다음과 같이 grub.cfg
파일을 다시 빌드해야 합니다.
BIOS 기반 시스템에서
root
로 다음 명령을 실행합니다.~]# grub2-mkconfig -o /boot/grub2/grub.cfg
UEFI 기반 시스템에서
root
로 다음 명령을 실행합니다.~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
26.5.3. 새 항목을 추가
grub2-mkconfig
명령을 실행할 때 GRUB 2는 /etc/grub.d/
디렉터리에 있는 파일을 기반으로 Linux 커널 및 기타 운영 체제를 검색합니다. /etc/grub.d/10_linux
스크립트는 동일한 파티션에 설치된 Linux 커널을 검색합니다. /etc/grub.d/30_os-prober
스크립트는 다른 운영 체제를 검색합니다. 커널을 업데이트할 때 부팅 메뉴에 메뉴 항목도 자동으로 추가됩니다.
/etc/grub.d/
디렉터리에 있는 40_custom
파일은 사용자 지정 항목의 템플릿이며 다음과 같습니다.
#!/bin/sh exec tail -n +3 $0 # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the 'exec tail' line above.
이 파일은 편집하거나 복사할 수 있습니다. 최소한 올바른 메뉴 항목에는 다음을 포함해야 합니다.
menuentry "<Title>"{ <Data> }
26.5.4. 사용자 지정 메뉴 생성
메뉴 항목을 자동으로 업데이트하지 않으려면 사용자 지정 메뉴를 만들 수 있습니다.
진행하기 전에 나중에 변경 사항을 복원해야 하는 경우 /etc/grub.d/
디렉터리의 콘텐츠를 백업합니다.
/etc/default/grub
파일을 수정해도 사용자 지정 메뉴를 만드는 데는 영향을 미치지 않습니다.
-
BIOS 기반 시스템에서
/boot/grub2/grub.cfg
또는 UEFI 머신에서 /boot/grub2/grub.cfg 콘텐츠를 복사하여/boot/efi/EFI/redhat/grub.cfg
.grub.cfg
의 콘텐츠를 기존 헤더 줄 아래의/etc/grub.d/40_custom
파일에 넣습니다.40_custom
스크립트의 실행 가능 부분은 보존해야 합니다. /etc/grub.d/40_custom
파일에 넣은 콘텐츠에서 사용자 지정메뉴를 생성하는 데 메뉴 항목
블록만 필요합니다./boot/grub2/grub.cfg
및/boot/efi/EFI/redhat/grub.cfg
파일에는메뉴 항목
블록 아래에 함수 사양 및 기타 콘텐츠가 포함될 수 있습니다. 이러한 불필요한 줄을 이전 단계에서40_custom
파일에 넣으면 내용을 지우십시오.사용자 지정
40_custom
스크립트의 예입니다.#!/bin/sh exec tail -n +3 $0 # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the 'exec tail' line above. menuentry 'First custom entry' --class red --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.10.0-67.el7.x86_64-advanced-32782dd0-4b47-4d56-a740-2076ab5e5976' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod xfs set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1' 7885bba1-8aa7-4e5d-a7ad-821f4f52170a else search --no-floppy --fs-uuid --set=root 7885bba1-8aa7-4e5d-a7ad-821f4f52170a fi linux16 /vmlinuz-3.10.0-67.el7.x86_64 root=/dev/mapper/rhel-root ro rd.lvm.lv=rhel/root vconsole.font=latarcyrheb-sun16 rd.lvm.lv=rhel/swap vconsole.keymap=us crashkernel=auto rhgb quiet LANG=en_US.UTF-8 initrd16 /initramfs-3.10.0-67.el7.x86_64.img } menuentry 'Second custom entry' --class red --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-0-rescue-07f43f20a54c4ce8ada8b70d33fd001c-advanced-32782dd0-4b47-4d56-a740-2076ab5e5976' { load_video insmod gzio insmod part_msdos insmod xfs set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1' 7885bba1-8aa7-4e5d-a7ad-821f4f52170a else search --no-floppy --fs-uuid --set=root 7885bba1-8aa7-4e5d-a7ad-821f4f52170a fi linux16 /vmlinuz-0-rescue-07f43f20a54c4ce8ada8b70d33fd001c root=/dev/mapper/rhel-root ro rd.lvm.lv=rhel/root vconsole.font=latarcyrheb-sun16 rd.lvm.lv=rhel/swap vconsole.keymap=us crashkernel=auto rhgb quiet initrd16 /initramfs-0-rescue-07f43f20a54c4ce8ada8b70d33fd001c.img }
다음을 제외한
/etc/grub.d/
디렉터리에서 모든 파일을 제거합니다.-
00_header
, -
40_custom
, -
01_users
(있는 경우) README
.또는
/etc/grub2.d/
디렉터리에 파일을 유지하려면 EgressIPa-x <file_name>
명령을 실행하여 실행할 수 없도록 설정합니다.
-
-
원하는 대로
40_custom
파일의 메뉴 항목을 편집, 추가 또는 제거합니다. 다음과 같이
grub2-mkconfig -o
명령을 실행하여grub.cfg
파일을 다시 빌드합니다.BIOS 기반 시스템에서
root
로 다음 명령을 실행합니다.~]# grub2-mkconfig -o /boot/grub2/grub.cfg
UEFI 기반 시스템에서
root
로 다음 명령을 실행합니다.~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
26.6. 암호로 GRUB 2 보호
GRUB 2는 두 가지 유형의 암호 보호를 제공합니다.
- 메뉴 항목을 수정하는 데는 암호가 필요하지만 기존 메뉴 항목을 부팅하는 데는 필요하지 않습니다.
- 메뉴 항목을 수정하고 하나, 여러 개 또는 모든 메뉴 항목을 부팅하는 데 암호가 필요합니다.
수정 항목만 사용하도록 GRUB 2 구성
GRUB 2 항목을 수정하기 위해 비밀번호 인증이 필요한 경우 다음 단계를 따르십시오.
grub2-setpassword
명령을 root로 실행합니다.~]# grub2-setpassword
암호를 입력하고 확인합니다.
Enter password: Confirm password:
다음 절차에서는 암호의 해시가 포함된 /boot/grub2/user.cfg
파일을 생성합니다. 이 암호의 사용자는 /boot/grub2/grub.cfg
파일에 정의되어 있습니다. 이 변경으로 부팅 중에 부팅 항목을 수정하려면
root
사용자 이름과 암호를 지정해야 합니다.
수정 및 부팅을 위한 암호 요청Require a Password for Modifying and Booting Entries
grub2-setpassword
를 사용하여 암호를 설정하면 메뉴 항목이 무단으로 수정되지 않지만 무단 부팅되지는 않습니다. 또한 항목을 부팅하는 데 암호가 필요한 경우 grub2-setpassword
로 암호를 설정한 후 다음 단계를 수행하십시오.
GRUB 2 암호를 잊어버린 경우 다음 프로세스에서 재구성한 항목을 부팅할 수 없습니다.
-
/boot/grub2/grub.cfg
파일을 엽니다. -
메뉴
입력으로 시작하는 행을 검색하여 암호로 보호하려는 부팅 항목을 찾습니다. 메뉴 항목 블록에서
--unrestricted
매개변수를 삭제합니다. 예를 들면 다음과 같습니다.[file contents truncated] menuentry 'Red Hat Enterprise Linux Server (3.10.0-327.18.2.rt56.223.el7_2.x86_64) 7.2 (Maipo)' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-327.el7.x86_64-advanced-c109825c-de2f-4340-a0ef-4f47d19fe4bf' { load_video set gfxpayload=keep [file contents truncated]
- 파일을 저장하고 닫습니다.
이제 항목을 부팅해도 root
사용자 이름과 암호를 입력해야 합니다.
새 커널 버전이 설치되면 /boot/grub2/grub.cfg
를 수동으로 변경하지만 grub2-mkconfig
명령을 사용하여 grub.cfg
를 다시 생성할 때 손실됩니다. 따라서 암호 보호를 유지하려면 grub2-mkconfig
를 사용한 후 위의 절차를 사용하십시오.
/boot/grub2/grub.cfg
파일의 모든 메뉴 항목에서 --unrestricted
매개변수를 삭제하면 새로 설치된 모든 커널에는 --unrestricted
없이 메뉴 항목이 생성되어 암호 보호가 자동으로 상속됩니다.
Red Hat Enterprise Linux 7.2로 업데이트 전에 암호 설정
grub2-setpassword
도구가 Red Hat Enterprise Linux 7.2에 추가되었으며 이제 GRUB 2 암호를 설정하는 표준 방법입니다. 이는 /etc/grub.d/40_custom
파일에 부팅 항목을 수동으로 지정해야 하는 이전 버전의 Red Hat Enterprise Linux와 달리 /etc/grub.d/01_users
파일에서 슈퍼 사용자입니다.
추가 GRUB 2 사용자
제한
없는 매개 변수 없이 항목을 부팅하려면 root 암호가 필요합니다. 그러나 GRUB 2를 사용하면 암호를 제공하지 않고도 이러한 항목을 부팅할 수 있는 루트가 아닌 사용자를 추가로 생성할 수 있습니다. 항목을 수정하려면 root 암호가 필요합니다. 이러한 사용자를 만드는 방법에 대한 자세한 내용은 GRUB 2 설명서 를 참조하십시오.
26.7. GRUB 2 재설치
GRUB 2를 다시 설치하는 것은 일반적으로 GRUB 2 누락 된 파일 또는 손상된 시스템의 잘못된 설치로 인해 발생하는 특정 문제를 해결하는 편리한 방법입니다. GRUB 2를 다시 설치하는 다른 이유는 다음과 같습니다.
- 이전 버전의 GRUB에서 업그레이드.
- GRUB 2 부트 로더가 설치된 운영 체제를 제어해야 합니다. 그러나 일부 운영 체제는 자체 부트 로더와 함께 설치됩니다. GRUB 2를 다시 설치하면 원하는 운영 체제에 대한 제어가 반환됩니다.
- 다른 드라이브에 부팅 정보를 추가합니다.
26.7.1. BIOS 기반 머신에 GRUB 2를 다시 설치
grub2-install
명령을 사용하면 부팅 정보가 업데이트되고 누락된 파일이 복원됩니다. 파일이 손상되지 않은 경우에만 복원됩니다.
시스템이 정상적으로 작동하는 경우 grub2-install device
명령을 사용하여 GRUB 2를 다시 설치합니다. 예를 들어 sda가 장치
인 경우 다음을 수행합니다.
~]# grub2-install /dev/sda
26.7.2. UEFI 기반 시스템에 GRUB 2 재설치
yum reinstall grub2-efi shim
명령을 사용하면 부팅 정보가 업데이트되고 누락된 파일이 복원됩니다. 파일이 손상되지 않은 경우에만 복원됩니다.
시스템이 정상적으로 작동하는 경우 yum reinstall grub2-efi shim
명령을 사용하여 GRUB 2를 다시 설치합니다. 예를 들면 다음과 같습니다.
~]# yum reinstall grub2-efi shim
26.7.3. GRUB 2 설정 및 제거
이 방법은 모든 GRUB 2 설정 파일 및 시스템 설정을 완전히 제거합니다. 모든 구성 설정을 기본값으로 재설정하려면 이 방법을 적용합니다. 설정 파일을 제거하고 GRUB 2를 다시 설치하여 손상된 파일과 잘못된 구성으로 인한 오류를 해결합니다. 이를 위해 root
로서 다음 단계를 따르십시오.
-
rm /etc/grub.d/*
명령을 실행하십시오. -
rm /etc/sysconfig/grub
명령을 실행합니다. EFI 시스템의 경우 다음 명령을 실행합니다.
~]# yum reinstall grub2-efi shim grub2-tools
BIOS 및 EFI 시스템의 경우 다음 명령을 실행합니다.
~]# yum reinstall grub2-tools
다음과 같이
grub2-mkconfig -o
명령을 실행하여grub.cfg
파일을 다시 빌드합니다.BIOS 기반 시스템에서
root
로 다음 명령을 실행합니다.~]# grub2-mkconfig -o /boot/grub2/grub.cfg
UEFI 기반 시스템에서
root
로 다음 명령을 실행합니다.~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
-
이제 26.7절. “GRUB 2 재설치” 의 절차에 따라
/boot/
파티션에서 GRUB 2를 복원하십시오.
26.8. GRUB legacy에서 GRUB 2로 업그레이드
RHEL (Red Hat Enterprise Linux)을 버전 6에서 7로 업그레이드하면 GRUB legacy에서
로 업그레이드가 자동으로 발생하지는 않지만 수동으로 수행해야합니다. 다음과 같은 이유로 GRUB 업그레이드를 수행하십시오.
GRUB
2
-
RHEL 7 이상 버전에서는
GRUB legacy가 더
이상 유지 관리되지 않으며 업데이트를 수신하지 않습니다. -
GRUB legacy
는/boot/
디렉토리 없이 시스템에서 부팅할 수 없습니다. -
GRUB 2
는 더 많은 기능을 가지고 있으며 더 신뢰할 수 있습니다. -
GRUB 2
는 더 많은 하드웨어 구성, 파일 시스템 및 드라이브 레이아웃을 지원합니다.
운영 체제의 내부 업그레이드 후 GRUB에서 GRUB 2로 업그레이드
GRUB legacy에서 GRUB 2로 업그레이드
Red Hat Upgrade Tool 에서 GRUB legacy 패키지가 제거되었는지 확인하십시오.
~]# yum remove grub
참고grub2 패키지를 설치 제거해도 설치된 GRUB legacy 부트로더에는 영향을 미치지 않습니다.
grub2 패키지가 설치되어 있는지 확인합니다. RHEL 7로 업그레이드한 후 grub2 가 시스템에 없는 경우 다음을 실행하여 수동으로 설치할 수 있습니다.
~]# yum install grub2
EFI를 사용하여 시스템을 부팅하는 경우 누락된 경우 다음 패키지를 설치합니다.
~]# yum install grub2-efi-x64 shim-x64
GRUB 2 설정 파일 생성
이 섹션에서는 원래 GRUB legacy
설정을 제거하지 않고 GRUB 2
설정을 추가하는 방법을 설명합니다.
설정을 유지합니다.
GRUB 2
가 제대로 작동하지 않는 경우 GRUB legacy
다음 옵션 중 하나를 사용하여
/etc/default/grub
파일을 수동으로 생성합니다.-
/etc/default/grub
파일을 생성합니다. 자세한 내용은 Red Hat Enterprise Linux 7에서 누락된 /etc/default/grub 파일을 다시 만드는 방법을 참조하십시오. -
유사한 Red Hat Enterprise Linux 7 시스템에서
/etc/default/grub
파일을 복사하고 그에 따라 파일을 조정합니다.
-
부트 로더에 따라 다음을 수행합니다.
레거시 BIOS를 사용하여 시스템이 부팅되는 경우 설치 장치를
GRUB 2
사양을 설치합니다.~]# grub2-install /dev/<DEVICE_NAME> --grub-setup=/bin/true
grub2-install
명령은 GRUB 이미지를/boot/grub
대상 디렉터리에 설치합니다.--grub-setup=/bin/true
옵션을 사용하면 이전GRUB legacy
설정이 삭제되지 않습니다.EFI를 사용하여 시스템을 부팅하면 shim 부트로더에 대한 부팅 항목을 만들고 펌웨어 부팅 GRUB 2에서
shim
을 시작하도록BootOrder
변수를 변경합니다.~]# efibootmgr -c -L 'Red Hat Enterprise Linux 7' -d /dev/device_name -p 1 -l '\EFI\redhat\shimx64.efi'
/dev/device_name 을 부팅 가능한 장치 파일로 바꿉니다.
주의구성 파일 확장자의 차이점에 유의하십시오.
-
.conf
는GRUB
-
GRUB 2
의 경우.cfg
다음 단계에서 실수로 이전
GRUB
설정 파일을 덮어쓰지 마십시오.GRUB 2
설정 파일을 생성합니다.시스템이 레거시 BIOS를 사용하는 경우:
~]# grub2-mkconfig -o /boot/grub2/grub.cfg
시스템이 EFI를 사용하는 경우:
~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
참고생성된
GRUB 2
설정 파일을 사용자 정의하려면 26.5절. “GRUB 2 구성 파일 사용자 지정” 를 참조하십시오./boot/grub2/grub.cfg
에서 직접 변경하지 않고/etc/default/grub
에서 변경해야 합니다. 그렇지 않으면 파일이 다시 생성될 때마다/boot/grub2/grub.cfg
변경 사항이 손실됩니다.
GRUB legacy 부트로더가 여전히 설치된 GRUB 2 테스트
이 섹션에서는 GRUB legacy
설정을 제거하지 않고 GRUB 2
를 테스트하는 방법에 대해 설명합니다. GRUB legacy
설정은 GRUB 2
설정을 확인할 때까지 유지되어야 합니다. 그렇지 않으면 시스템을 부팅할 수 없습니다. GRUB 2
설정을 안전하게 테스트하기 위해 GRUB 2
에서 GRUB
2를 시작합니다.
이 섹션은 레거시 BIOS 부팅에만 적용됩니다. EFI의 경우 이전 및 새 부트로더에 대한 부팅 항목이 있으며 EFI 펌웨어 설정으로 부팅 항목을 선택하여 기존 GRUB을 부팅할 수 있습니다.
새 섹션을
/boot/grub/grub.conf
에 추가합니다.별도의
/boot
파티션이 있는 시스템의 경우 다음을 사용하십시오.title GRUB 2 Test root (hd0,0) kernel /grub2/i386-pc/core.img boot
(hd0,0) 을
GRUB legacy
부팅 가능 장치 지정으로 대체합니다.별도의
/boot
파티션이 없는 시스템의 경우 다음을 사용하십시오.title GRUB 2 Test root (hd0,0) kernel /boot/grub2/i386-pc/core.img boot
(hd0,0) 을
GRUB legacy
부팅 가능 장치 지정으로 대체합니다.- 시스템을 재부팅합니다.
-
GRUB legacy
메뉴가 표시된 경우GRUB 2 Test
항목을 선택합니다. -
GRUB 2
메뉴가 제공되면 부팅할 커널을 선택합니다. -
위의 작업이 작동하지 않으면 다시 시작하고 다음 부팅 시
GRUB 2 Test
항목을 선택하지 마십시오.
BIOS를 사용하는 시스템에서 GRUB legacy 부트로더 교체
GRUB 2가 성공적으로 작동하는 경우:
GRUB legacy 부트로더를 GRUB 2 부트로더로 교체합니다.
~]# grub2-install /dev/sdX
이전 GRUB legacy 설정 파일을 제거하십시오.
~]# rm /boot/grub/grub.conf
시스템을 재부팅합니다.
~]# reboot
EFI를 사용하는 시스템에서 GRUB legacy 제거
GRUB 2가 성공적으로 작동하는 경우:
/boot/efi/EFI/redhat/
디렉토리의 내용을 확인하고 legacy GRUB과 관련된 더 이상 사용되지 않는 파일을 제거하십시오.~]# rm /boot/efi/EFI/redhat/grub.efi ~]# rm /boot/efi/EFI/redhat/grub.conf
Preupgrade Assistant 및 Red Hat Upgrade Tool 유틸리티를 사용하여 RHEL 6에서 RHEL 7로의 인플레이스 업그레이드를 수행한 경우, 위에 언급된 파일의 백업 사본도
.preupg
접미사로 끝납니다.~]# rm /boot/efi/EFI/redhat/*.preupg
efibootmgr
명령을 사용하여\EFI\redhat\grub.efi
파일을 참조하는 이전 부팅 항목을 찾습니다.~]# efibootmgr -v | grep '\\EFI\\redhat\\grub.efi'
출력 예:
Boot0001* Linux HD(1,GPT,542e410f-cbf2-4cce-9f5d-61c4764a5d54,0x800,0x64000)/File(\EFI\redhat\grub.efi)
이 경우의 진입 번호는
0001
입니다.확인된 부팅 항목을 제거합니다. 다음 명령은 위의 예에서 부팅 항목을 제거합니다.
~]# efibootmgr -Bb 0001
이러한 부팅 항목이 두 개 이상 있는 경우 모든 이전 부팅 항목을 제거하십시오.
RHEL6과 같은 이전 릴리스에서 RHEL7로 업그레이드한 후 GRUB legacy 부트로더를 GRUB 2 로 수동으로 업그레이드할 때까지 운영 체제는 지원되지 않습니다. 이는 주요 릴리스에서 패키지 설치가 지원되지 않기 때문입니다. RHEL 7의 경우, RHEL 6의 GRUB legacy와 달리 GRUB 2만 지원, 개발 및 테스트됩니다.
26.9. 직렬 콘솔 대신 GRUB 2
이 섹션에서는 디스플레이나 키보드 없이 시스템에서 직렬 통신을 위해 GRUB 2
를 설정하는 방법을 설명합니다.
직렬 연결을 통해 GRUB 2
터미널에 액세스하려면 특정 커널이 직렬 연결을 모니터링할 수 있도록 커널 정의에 추가 옵션을 추가해야 합니다.
예를 들면 다음과 같습니다.
console=ttyS0,9600n8
여기서 console=ttyS0
은 사용할 직렬 터미널이며 9600
은 버드 속도이고 n
은 패리티가 없고 8
은 비트 단위의 문자 길이입니다. 다음 로그 파일과 같은 작업에 대해 훨씬 더 높은
배율(예: 115200)이 더 높습니다.
직렬 콘솔 설정에 대한 자세한 내용은 다음을 참조하십시오. “설치 가능 및 외부 문서”
26.9.1. 단일 부팅을 위해 GRUB 2 설정
시스템을 단일 부팅 프로세스 중에만 사용하도록 시스템을 설정하려면 GRUB 2 부팅 메뉴가 표시되면 커서를 시작하려는 커널로 이동하고 e 키를 눌러 커널 매개 변수를 편집합니다. rhgb
및 quiet
매개변수를 제거하고 다음과 같이 linux16
행의 끝에 콘솔 매개 변수를 추가합니다.
linux16 /vmlinuz-3.10.0-0.rc4.59.el7.x86_64 root=/dev/mapper/rhel-root ro rd.md=0 rd.dm=0 rd.lvm.lv=rhel/swap crashkernel=auto rd.luks=0 vconsole.keymap=us rd.lvm.lv=rhel/root console=ttyS0,9600
이러한 설정은 영구적이 아니며 단일 부팅에만 적용됩니다.
26.9.2. 영구 변경을 위해 GRUB 2 설정
시스템의 메뉴 항목을 영구적으로 변경하려면 grubby
툴을 사용합니다. 예를 들어 기본 커널의 항목을 업데이트하려면 다음과 같이 명령을 입력합니다.
~]# grubby --remove-args="rhgb quiet" --args=console=ttyS0,9600 --update-kernel=DEFAULT
--update-kernel
매개변수는 전체 키워드 또는
쉼표로 구분된 커널 인덱스 번호 목록을 허용합니다. grubby
사용에 대한 자세한 내용은 “GRUB 2 메뉴 항목에서 인수 추가 및 제거” 을 참조하십시오.
26.9.3. 새 GRUB 2 파일 설정
새 GRUB 2 설정 파일을 빌드하는 데 필요한 경우 /etc/default/grub
파일에 다음 두 행을 추가합니다.
GRUB_TERMINAL="serial" GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1"
첫 번째 줄은 그래픽 터미널을 비활성화합니다. GRUB_TERMINAL
키를 지정하면 GRUB_TERMINAL_INPUT
및 GRUB_TERMINAL_OUTPUT
의 값이 재정의됩니다. 두 번째 줄에서 환경 및 하드웨어에 맞게 baud 속도, 패리티 및 기타 값을 조정합니다. 다음 로그 파일과 같은 작업에 대해 훨씬 더 높은
배율(예: 115200)이 더 높습니다. /etc/default/grub
파일에서 변경 사항을 완료한 후에는 GRUB 2 설정 파일을 업데이트해야 합니다.
다음과 같이 grub2-mkconfig -o
명령을 실행하여 grub.cfg
파일을 다시 빌드합니다.
BIOS 기반 시스템에서
root
로 다음 명령을 실행합니다.~]# grub2-mkconfig -o /boot/grub2/grub.cfg
UEFI 기반 시스템에서
root
로 다음 명령을 실행합니다.~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
26.9.4. 화면을 사용하여 직렬 콘솔에 연결
화면 도구는 가능한 직렬 터미널 역할을 합니다. 이를 설치하려면 root
로 실행합니다.
~]# yum install screen
직렬 콘솔을 사용하여 시스템에 연결하려면 다음 형식으로 명령을 사용합니다.
screen /dev/console_port baud_rate
기본적으로 옵션을 지정하지 않으면 화면은 표준 9600 baud 속도를 사용합니다. 더 높은 baud 속도를 설정하려면 다음을 입력하십시오.
~]$ screen /dev/console_port
115200
여기서 console_port 는 ttyS0
, 또는 tty
-02-0 이므로.
화면에서 세션을 종료하려면 Ctrl+a 를 누릅니다. :quit
를 입력하고 Enter 를 누릅니다.
추가 옵션 및 자세한 내용은 screen(1)
매뉴얼 페이지를 참조하십시오.
26.10. 부팅 중 터미널 메뉴 편집
메뉴 항목을 수정하고 부팅 시 커널에 전달할 수 있습니다. 이는 부트 로더 메뉴의 선택한 메뉴 항목에서 e 키를 누를 때 트리거되는 메뉴 항목 편집기 인터페이스를 사용하여 수행됩니다. Esc 키는 변경 사항을 취소하고 표준 메뉴 인터페이스를 다시 로드합니다. c 키는 명령줄 인터페이스를 로드합니다.
명령행 인터페이스는 가장 기본적인 GRUB 2 인터페이스이지만 가장 많은 제어 권한을 부여하는 인터페이스이기도 합니다. 명령행을 사용하면 관련 GRUB 2 명령 뒤에 Enter 키를 입력하여 실행할 수 있습니다. 이 인터페이스는 컨텍스트 기반의 Tab 키 완성을 포함한 쉘 과 유사한 몇 가지 고급 기능을 갖추고 있으며 Ctrl+a 를 눌러 줄의 시작 부분으로 이동하고 Ctrl+e 를 눌러 줄의 끝으로 이동합니다. 또한 화살표,홈,종료 및 삭제 키는 bash 쉘에서 수행하는 대로 작동합니다.
26.10.1. 복구 모드로 부팅
복구 모드는 편리한 단일 사용자 환경을 제공하며 일반적인 부팅 프로세스를 완료할 수 없는 상황에서 시스템을 복구할 수 있습니다. 복구 모드에서는 시스템이 모든 로컬 파일 시스템을 마운트하고 일부 중요한 시스템 서비스를 시작하려고 하지만 네트워크 인터페이스를 활성화하지 않거나 더 많은 사용자가 시스템에 로그인할 수 있도록 합니다. Red Hat Enterprise Linux 7에서 복구 모드는 단일 사용자 모드와 동일하며 root
암호가 필요합니다.
- 부팅 중에 복구 모드로 들어가려면 GRUB 2 부팅 화면에서 편집용 e 키를 누릅니다.
64 enterprise IBM Power 시리즈의
linux
라인 끝에, x86-64 BIOS 기반 시스템의linux16
라인, 또는 UEFI 시스템의linuxefi
라인에 다음 매개 변수를 추가하십시오.systemd.unit=rescue.target
Ctrl+a 및 Ctrl+e 를 눌러 각 줄의 시작 및 끝으로 건너뜁니다. 일부 시스템에서는 홈 및 종료일 도 작동할 수 있습니다.
동등한 매개변수인
1
,s
및단일
도 커널에 전달할 수 있습니다.- Ctrl+x 를 눌러 매개 변수를 사용하여 시스템을 부팅합니다.
26.10.2. 긴급 모드로 부팅
긴급 모드는 가능한 가장 최소한의 환경을 제공하며 시스템이 복구 모드로 전환되지 않은 경우에도 시스템을 복구할 수 있습니다. 긴급 모드에서는 읽기용으로만 루트
파일 시스템을 마운트하고 다른 로컬 파일 시스템을 마운트하지 않고 네트워크 인터페이스를 활성화하지 않으며 몇 가지 필수 서비스만 시작합니다. Red Hat Enterprise Linux 7의 긴급 모드에서는 루트
암호가 필요합니다.
- 긴급 모드로 들어가려면 GRUB 2 부팅 화면에서 편집용 e 키를 누릅니다.
64 enterprise IBM Power 시리즈의
linux
라인 끝에, x86-64 BIOS 기반 시스템의linux16
라인, 또는 UEFI 시스템의linuxefi
라인에 다음 매개 변수를 추가하십시오.systemd.unit=emergency.target
Ctrl+a 및 Ctrl+e 를 눌러 각 줄의 시작 및 끝으로 건너뜁니다. 일부 시스템에서는 홈 및 종료일 도 작동할 수 있습니다.
동등한 매개변수,
emergency
및-b
도 커널에 전달할 수 있습니다.- Ctrl+x 를 눌러 매개 변수를 사용하여 시스템을 부팅합니다.
26.10.3. 디버그 쉘로 부팅
systemd
디버그 쉘은 systemd
관련 부팅 문제를 진단하는 데 사용할 수 있는 시작 프로세스 초기에 쉘을 제공합니다. 디버그 쉘에서
, systemctl
list-jobssystemctl list-units
를 사용하여 부팅 문제의 원인을 찾을 수 있습니다. 또한 로그 메시지 수를 늘리기 위해 커널 명령줄에 debug
옵션을 추가할 수 있습니다. systemd
의 경우 커널 명령줄 옵션 debug
는 이제 systemd.log_level=debug
의 바로 가기입니다.
디버그 쉘 명령 추가
이 세션에 대해서만 디버그 쉘을 활성화하려면 다음과 같이 진행하십시오.
- GRUB 2 부팅 화면에서 편집하려는 메뉴 항목으로 커서를 이동한 후 편집할 e 키를 누릅니다.
64 enterprise IBM Power 시리즈의
linux
라인 끝에, x86-64 BIOS 기반 시스템의linux16
라인, 또는 UEFI 시스템의linuxefi
라인에 다음 매개 변수를 추가하십시오.systemd.debug-shell
선택적으로
debug
옵션을 추가합니다.Ctrl+a 및 Ctrl+e 를 눌러 각 줄의 시작 및 끝으로 건너뜁니다. 일부 시스템에서는 홈 및 종료일 도 작동할 수 있습니다.
- Ctrl+x 를 눌러 매개 변수를 사용하여 시스템을 부팅합니다.
필요하면 systemctl enable debug-shell
명령을 사용하여 모든 부팅 시 시작되도록 디버그 쉘을 설정할 수 있습니다. 또는 grubby
도구를 사용하여 GRUB 2 메뉴에서 커널 명령행을 영구적으로 변경할 수 있습니다. grubby
사용에 대한 자세한 내용은 26.4절. “grubby 도구를 사용하여 GRUB 2 메뉴의 영구 변경 사항 만들기” 을 참조하십시오.
인증을 사용하지 않으므로 디버그 쉘을 영구적으로 활성화하면 보안 위험이 있습니다. 디버깅 세션이 종료되면 비활성화합니다.
디버그 쉘에 연결
부팅 프로세스 중에 systemd-debug-generator
는 TTY9에서 디버그 쉘을 구성합니다.
- Ctrl+Alt+F9 를 눌러 디버그 쉘에 연결합니다. 가상 머신으로 작업하는 경우 이 키 조합을 전송하려면 가상화 애플리케이션의 지원이 필요합니다. 예를 들어 Virtual Machine Manager 를 사용하는 경우 메뉴에서 를 선택합니다.
-
디버그 쉘에는 인증이 필요하지 않으므로 TTY9:
[root@localhost /]#
에서 다음과 유사한 프롬프트가 표시됩니다. 필요한 경우 디버그 쉘에 있는지 확인하려면 다음과 같이 명령을 입력합니다.
/]# systemctl status $$ ● debug-shell.service - Early root shell on /dev/tty9 FOR DEBUGGING ONLY Loaded: loaded (/usr/lib/systemd/system/debug-shell.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2015-08-05 11:01:48 EDT; 2min ago Docs: man:sushell(8) Main PID: 450 (bash) CGroup: /system.slice/debug-shell.service ├─ 450 /bin/bash └─1791 systemctl status 450
- 부팅이 성공하면 기본 쉘로 돌아가려면 Ctrl+Alt+F1 을 누릅니다.
시작 문제를 진단하려면 커널 명령줄에
을 한 번 이상 추가하여 특정 systemd 장치를 마스킹할 수 있습니다. 부팅 프로세스 중에 추가 프로세스를 시작하려면 커널 명령줄에 systemd
. mask=unit_namesystemd.wants=unit_name
을 추가합니다. systemd-debug-generator(8)
매뉴얼 페이지는 이러한 옵션을 설명합니다.
26.10.4. 루트 암호 변경 및 설정
루트
암호를 설정하는 것은 Red Hat Enterprise Linux 7 설치의 필수 부분입니다. 루트
암호를 잊어버리거나 손실하면 재설정할 수 있지만, wheel 그룹의 멤버인 사용자는 다음과 같이 루트
암호를 변경할 수 있습니다.
~]$ sudo passwd root
GRUB 2에서는 Red Hat Enterprise Linux 6에 포함된 GRUB에서와 마찬가지로 더 이상 단일 사용자 모드에서 암호 재설정이 수행되지 않습니다. 이제 단일 사용자 모드와
긴급
모드에서도root
암호를 작동해야 합니다.
루트
암호를 재설정하는 두 가지 절차는 다음과 같습니다.
- 설치 디스크를 사용하여 루트 암호 재설정 GRUB 2 메뉴를 편집하지 않고도 쉘 프롬프트로 이동합니다. 이 방법은 두 절차 중 더 짧으며 권장되는 방법이기도 합니다. 부팅 디스크 또는 일반 Red Hat Enterprise Linux 7 설치 디스크를 사용할 수 있습니다.
-
rd.break를 사용하여 루트 암호 재설정 제어가
initramfs
에서systemd
로 전달되기 전에rd.break
를 사용하여 부팅 프로세스를 중단합니다. 이 방법의 단점은 더 많은 단계가 필요하며 GRUB 2 메뉴를 편집해야 할 필요가 있으며 SELinux 파일의 레이블을 다시 지정하거나 SELinux 강제 모드를 변경하는 데 걸리는 시간 중에서 선택한 다음 부팅이 완료되면/etc/shadow/
에 대한 SELinux 보안 컨텍스트를 복원해야 한다는 것입니다.
설치 디스크를 사용하여 루트 암호 재설정
- 시스템을 시작하고 BIOS 정보가 표시되면 부팅 메뉴에 대한 옵션을 선택하고 설치 디스크에서 부팅하도록 선택합니다.
-
Troubleshooting
을 선택합니다. -
Rescue a Red Hat Enterprise Linux System
을 선택합니다. -
기본 옵션인
Continue
를 선택합니다. 이 시점에서 암호화된 파일 시스템이 있는 경우 암호로 승격됩니다. - OK 를 눌러 쉘 프롬프트가 표시될 때까지 표시되는 정보를 확인합니다.
다음과 같이 파일 시스템
루트
를 변경합니다.sh-4.2# chroot /mnt/sysimage
-
passwd
명령을 입력하고 명령줄에 표시된 지침에 따라root
암호를 변경합니다. 자동 복구 가능
파일을 제거하여 디스크의 SELinux 재지정을 사용하는 시간을 방지합니다.sh-4.2# rm -f /.autorelabel
-
exit
명령을 입력하여chroot
환경을 종료합니다. -
exit
명령을 다시 입력하여 초기화를 재개하고 시스템 부팅을 완료합니다.
rd.break를 사용하여 루트 암호 재설정
- 시스템을 시작하고 GRUB 2 부팅 화면에서 편집용 e 키를 누릅니다.
rhgb
및quiet
매개 변수를 끝에서 또는linux16
라인의 끝 근처에, 또는 UEFI 시스템의linuxefi
를 제거하십시오.Ctrl+a 및 Ctrl+e 를 눌러 각 줄의 시작 및 끝으로 건너뜁니다. 일부 시스템에서는 홈 및 종료일 도 작동할 수 있습니다.
중요시스템 메시지를 활성화하려면
rhgb
및quiet
매개 변수를 제거해야 합니다.64 enterprise IBM Power 시리즈의
linux
라인 끝에, x86-64 BIOS 기반 시스템의linux16
라인, 또는 UEFI 시스템의linuxefi
라인에 다음 매개 변수를 추가하십시오.rd.break enforcing=0
enforcing=0
옵션을 추가하면 SELinux 레이블을 다시 지정하는 데 걸리는 시간을 생략할 수 있습니다.initramfs
는 제어를 Linux 커널에 전달하기 전에 중지되므로루트
파일 시스템에서 작업할 수 있습니다.initramfs
프롬프트는 Linux 행에 지정된 마지막 콘솔에 표시됩니다.Ctrl+x 를 눌러 변경된 매개 변수를 사용하여 시스템을 부팅합니다.
암호화된 파일 시스템에서는 이 시점에서 암호가 필요합니다. 그러나 메시지를 로깅하여 모호하기 때문에 암호 프롬프트가 나타나지 않을 수 있습니다. Backspace 키를 눌러 프롬프트를 확인할 수 있습니다. 로깅 메시지를 무시하는 동안 키를 해제하고 암호화된 파일 시스템의 암호를 입력합니다.
initramfs
switch_root
프롬프트가 나타납니다.파일 시스템은
/sysroot/
에 읽기 전용으로 마운트됩니다. 파일 시스템에 쓸 수 없는 경우 암호를 변경할 수 없습니다.파일 시스템을 쓰기 가능으로 다시 마운트합니다.
switch_root:/# mount -o remount,rw /sysroot
쓰기가 활성화된 파일 시스템이 다시 마운트됩니다.
파일 시스템의
루트
를 다음과 같이 변경합니다.switch_root:/# chroot /sysroot
프롬프트가
sh-4.2#
.passwd
명령을 입력하고 명령줄에 표시된 지침에 따라root
암호를 변경합니다.시스템에 쓸 수 없는 경우 다음 오류와 함께 passwd 툴이 실패합니다.
Authentication token manipulation error
암호 파일을 업데이트하면 잘못된 SELinux 보안 컨텍스트가 있는 파일이 생성됩니다. 다음 시스템 부팅 시 모든 파일의 레이블을 다시 지정하려면 다음 명령을 입력합니다.
sh-4.2# touch /.autorelabel
또는 대용량 디스크의 레이블을 다시 지정하는 데 걸리는 시간을 절약하기 위해 3단계에서
enforcing=0
옵션이 포함되어 있는 경우 이 단계를 생략할 수 있습니다.파일 시스템을 읽기 전용으로 다시 마운트합니다.
sh-4.2# mount -o remount,ro /
-
exit
명령을 입력하여chroot
환경을 종료합니다. exit
명령을 다시 입력하여 초기화를 재개하고 시스템 부팅을 완료합니다.이 시점에서는 암호화된 파일 시스템을 사용하는 경우 해당 텍스트 또는 문구가 필요합니다. 그러나 메시지를 로깅하여 모호하기 때문에 암호 프롬프트가 나타나지 않을 수 있습니다. 를 누르고 Backspace 키를 눌러 프롬프트를 확인할 수 있습니다. 로깅 메시지를 무시하는 동안 키를 해제하고 암호화된 파일 시스템의 암호를 입력합니다.
참고SELinux 레이블 지정 프로세스에는 시간이 오래 걸릴 수 있습니다. 프로세스가 완료되면 시스템 재부팅이 자동으로 수행됩니다.
3단계에서
enforcing=0
옵션을 추가하고 8 단계에서touch /.autorelabel
명령을 생략하면 다음 명령을 입력하여/etc/shadow
파일의 SELinux 보안 컨텍스트를 복원합니다.~]# restorecon /etc/shadow
다음 명령을 입력하여 SELinux 정책 실행을 다시 켜고 해당 명령이 켜져 있는지 확인합니다.
~]# setenforce 1 ~]# getenforce Enforcing
26.11. UEFI(Unified Extensible Firmware Interface) Secure Boot
UEFI( Unified Extensible Firmware Interface ) Secure Boot 기술을 사용하면 시스템 펌웨어가 펌웨어에 포함된 공개 키의 데이터베이스에서 인증하는 암호화 키로 서명되었는지 확인합니다. 다음 단계의 부트 로더와 커널의 서명 확인을 통해 신뢰할 수 있는 키로 서명되지 않은 커널 공간 코드의 실행을 방지할 수 있습니다.
신뢰 체인은 펌웨어에서 서명된 드라이버 및 커널 모듈로 다음과 같이 설정됩니다. first-stage boot loader, shim.efi
는 UEFI 개인 키로 서명하고 펌웨어 데이터베이스에 저장된 CA(인증 기관)에서 서명한 공개 키로 인증합니다. shim.efi
에는 GRUB 2 부트 로더, grubx64.efi
및 Red Hat 커널 모두를 인증하는 데 사용되는 Red Hat 공개 키 "Red Hat Secure Boot(CA 키 1)"가 포함되어 있습니다. 커널은 드라이버 및 모듈을 인증하는 공개 키가 포함되어 있습니다.
Secure Boot는 UEFI(Unified Extensible Firmware Interface) 사양의 부팅 경로 검증 구성 요소입니다. 사양은 다음을 정의합니다.
- 비휘발성 스토리지에서 암호로 보호되는 UEFI 변수를 위한 프로그래밍 인터페이스
- 신뢰할 수 있는 X.509 루트 인증서가 UEFI 변수에 저장되는 방법
- 부트 로더 및 드라이버와 같은 UEFI 애플리케이션 검증
- 알려진 인증서 및 애플리케이션 해시를 취소하는 절차입니다.
UEFI Secure Boot는 second-stage 부트 로더를 설치하거나 제거하는 것을 방지하지 않으며 이러한 변경 사항을 명시적으로 확인할 필요가 없습니다. 서명은 부트 로더가 설치 또는 업데이트될 때가 아닌 부팅 중에 확인됩니다. 따라서 UEFI Secure Boot는 부팅 경로 조작을 중지하지 않으며 무단 변경 사항을 감지하는 데 도움이 됩니다. 새로운 부트 로더 또는 커널은 시스템에서 신뢰하는 키로 서명하는 한 작동합니다.
26.11.1. Red Hat Enterprise Linux 7의 UEFI Secure Boot 지원
Red Hat Enterprise Linux 7은 UEFI Secure Boot 기능을 지원하므로 UEFI Secure Boot가 활성화된 시스템에서 Red Hat Enterprise Linux 7을 설치하고 실행할 수 있습니다. Secure Boot 기술이 활성화된 UEFI 기반 시스템에서는 로드된 모든 드라이버에 신뢰할 수 있는 키로 서명해야 합니다. 그렇지 않으면 시스템에서 허용하지 않습니다. Red Hat에서 제공하는 모든 드라이버는 Red Hat의 개인 키 중 하나에서 서명하고 커널에서 해당 Red Hat 공개 키로 인증합니다.
외부적으로 구축된 드라이버를 로드하려면 Red Hat Enterprise Linux DVD에서 제공되지 않는 드라이버도 로드해야 합니다. 이러한 드라이버도 서명되어 있어야 합니다.
사용자 정의 드라이버 서명에 대한 정보는 Red Hat Enterprise Linux 7 커널 관리 가이드에서 확인할 수 있습니다.
UEFI 보안 부팅으로 인한 제한 사항
Red Hat Enterprise Linux 7의 UEFI Secure Boot 지원은 서명이 올바르게 인증된 후 시스템이 커널 모드 코드만 실행하도록 설계되었습니다.
GRUB 2 모듈 로드는 GRUB 2 모듈에 서명하고 확인하는 인프라가 없기 때문에 비활성화되어 있습니다. 즉, 로드를 허용하면 Secure Boot에서 정의하는 보안 경계 내에서 신뢰할 수 없는 코드 실행이 구성됩니다. 대신 Red Hat은 Red Hat Enterprise Linux 7에서 지원되는 모든 모듈이 이미 포함되어 있는 서명된 GRUB 2 바이너리를 제공합니다.
자세한 내용은 Red Hat 지식베이스 문서 Restrictions Imposed by UEFI Secure Boot 에서 확인할 수 있습니다.
26.12. 추가 리소스
GRUB 2 부트 로더에 대한 자세한 내용은 다음 리소스를 참조하십시오.
설치된 문서
-
/usr/share/doc/grub2-tools- version-number /
- 이 디렉토리에는 GRUB 2 사용 및 설정에 대한 정보가 포함되어 있습니다. 버전 번호는 설치된 GRUB 2 패키지 버전에 해당합니다. -
info grub2
- GRUB 2 info 페이지에는 튜토리얼, 사용자 참조 설명서, 프로그래머 참조 설명서, GRUB 2 및 해당 사용에 대한 FAQ 문서가 포함되어 있습니다. -
grubby(8)
- GRUB 및 GRUB 2를 설정하기 위한 명령행 도구의 설명서 페이지. -
new-kernel-pkg(8)
- 커널 설치를 스크립팅하는 툴의 도움말 페이지.
설치 가능 및 외부 문서
/usr/share/doc/ kernel-doc -kernel_version/Documentation/serial-console.txt
- 이 파일은 직렬 콘솔에 대한 정보가 포함되어 있습니다. 커널 설명서에 액세스하기 전에root
로 다음 명령을 실행해야 합니다.~]# yum install kernel-doc
- Red Hat 설치 가이드 - 설치 가이드는 설치, 용어, 인터페이스 및 명령과 같은 GRUB 2에 대한 기본 정보를 제공합니다.
VIII 부. 시스템 백업 및 복구
이 부분에서는 Relax-and-Recover (ReaR) 재해 복구 및 시스템 마이그레이션 유틸리티를 사용하는 방법을 설명합니다.
27장. rest-and-Recover (ReaR)
소프트웨어 또는 하드웨어 장애가 시스템을 중단하면 시스템 관리자는 세 가지 작업에 연결하여 새 하드웨어 환경에서 완전히 작동하는 상태로 복원합니다.
- 새 하드웨어에서 복구 시스템 부팅
- 원래 스토리지 레이아웃 복제
- 사용자 및 시스템 파일 복원
대부분의 백업 소프트웨어는 세 번째 문제만 해결합니다. 첫 번째 및 두 번째 문제를 해결하려면 재해 복구 및 시스템 마이그레이션 유틸리티인 Relax-and-Recover (ReaR) 를 사용하십시오.
백업 소프트웨어는 백업을 생성합니다. 복구 시스템을 생성하여 백업 소프트웨어를 보완합니다. 새 하드웨어에서 복구 시스템을 부팅하면 복구 프로세스를 시작하는 복구
명령을 실행할 수 있습니다. 이 프로세스 중에 ReaR은 파티션 레이아웃과 파일 시스템을 복제하고, 백업 소프트웨어로 생성된 백업에서 사용자 및 시스템 파일을 복원하라는 메시지를 표시하고 마지막으로 부트 로더를 설치합니다. 기본적으로 ReaR에서 만든 복구 시스템은 스토리지 레이아웃과 부트 로더만 복원하지만 실제 사용자와 시스템 파일은 복원되지 않습니다.
이 장에서는 ReaR 사용 방법에 대해 설명합니다.
27.1. 기본 ReaR 사용
27.1.1. ReaR 설치
root로 다음 명령을 실행하여 rear 패키지를 설치합니다.
~]# yum install rear
27.1.2. ReaR 구성
rear은 /etc/rear/local.conf
파일에서 구성됩니다. 다음 행을 추가하여 복구 시스템 구성을 지정합니다.
OUTPUT=output format OUTPUT_URL=output location
부팅 가능한 USB
의 경우 ISO 또는 ISO 디스크 이미지 ISO
와 같은 복구 시스템 형식으로 출력 형식을 대체합니다.
출력 위치를 로컬 파일 시스템 디렉터리의 경우 file:///mnt/rescue_system/
로 대체하거나 SFTP 디렉터리의 경우 sftp://backup:.0.0/
로 바꿉니다.
예 27.1. 복구 시스템 형식 및 위치 구성
복구 시스템을 ISO 이미지로 /mnt/rescue_system/
디렉토리에 출력하도록 ReaR을 구성하려면 /etc/rear/local.conf
파일에 다음 행을 추가합니다.
OUTPUT=ISO OUTPUT_URL=file:///mnt/rescue_system/
모든 옵션 목록에 대한 rear(8) 도움말 페이지의 "Rescue Image Configuration" 섹션을 참조하십시오.
ISO별 구성
예 27.1. “복구 시스템 형식 및 위치 구성” 의 설정을 사용하면 두 위치에 동일한 출력 파일이 생성됩니다.
-
/var/lib/
- 기본 출력 위치를 다시 표시rear
/output/ -
/mnt/rescue_system/HOSTNAME/rear-localhost.iso
-OUTPUT_URL
에 지정된 출력 위치
그러나 일반적으로 하나의 ISO 이미지 만 필요합니다. ReaR이 사용자가 지정한 디렉터리에만 ISO 이미지를 만들려면 다음 행을 /etc/rear/local.conf
에 추가하십시오.
OUTPUT=ISO
BACKUP=NETFS
OUTPUT_URL=null
BACKUP_URL="iso:///backup"
ISO_DIR="output location"
출력 위치를 원하는 위치로 대체합니다.
27.1.3. 복구 시스템 생성
다음 예제에서는 자세한 출력이 있는 복구 시스템을 생성하는 방법을 보여줍니다.
~]# rear -v mkrescue Relax-and-Recover 1.17.2 / Git Using log file: /var/log/rear/rear-rhel7.log mkdir: created directory '/var/lib/rear/output' Creating disk layout Creating root filesystem layout TIP: To login as root via ssh you need to set up /root/.ssh/authorized_keys or SSH_ROOT_PASSWORD in your configuration file Copying files and directories Copying binaries and libraries Copying kernel modules Creating initramfs Making ISO image Wrote ISO image: /var/lib/rear/output/rear-rhel7.iso (124M) Copying resulting files to file location
예 27.1. “복구 시스템 형식 및 위치 구성” 의 설정을 통해 ReaR은 위의 출력을 출력합니다. 마지막 두 줄은 복구 시스템이 성공적으로 생성되고 구성된 백업 위치 /mnt/rescue_system/
에 복사되었는지 확인합니다. 시스템의 호스트 이름이 rhel7
이므로 백업 위치에 이제 복구 시스템 및 보조 파일이 있는 rhel7/
디렉터리가 포함되어 있습니다.
~]# ls -lh /mnt/rescue_system/rhel7/ total 124M -rw-------. 1 root root 202 Jun 10 15:27 README -rw-------. 1 root root 166K Jun 10 15:27 rear.log -rw-------. 1 root root 124M Jun 10 15:27 rear-rhel7.iso -rw-------. 1 root root 274 Jun 10 15:27 VERSION
재해 발생 시 복구 시스템을 손실하지 않도록 외부 미디어로 전송합니다.
27.1.4. ReaR 예약
rear 패키지에서 제공하는 /etc/cron.d/
crontab 파일은 복구 시스템을 정기적으로 생성하기 위한 Relax-and-Recover(ReaR) 유틸리티를 예약하기 위해 오전 1:30에 자동으로 rear
rear mkrescue
명령을 실행합니다. 명령은 데이터 백업이 아닌 복구 시스템만 생성합니다. 데이터의 주기적인 백업을 직접 예약해야 합니다. 예를 들면 다음과 같습니다.
-
rear mkbackuponly
명령을 예약하는 다른 crontab을 추가할 수 있습니다. -
기존 crontab을 변경하여 기본
/usr/sbin/rear checklayout || /usr/sbin/rear mkrescure
명령 대신rear mkbackup
명령을 실행할 수도 있습니다. - 외부 백업 방법이 사용 중인 경우 외부 백업을 예약할 수 있습니다. 자세한 내용은 ReaR에서 사용하는 백업 방법에 따라 다릅니다. 자세한 내용은 Integrating ReaR with Backup Software 를 참조하십시오.
rear 패키지에 제공된 /etc/cron.d/
crontab 파일은 기본적으로 백업을 수행하는 데 충분하지 않기 때문에 더 이상 사용되지 않습니다. 자세한 내용은 해당 더 이상 사용되지 않는 기능 쉘 및 명령줄 툴 을 참조하십시오.
rear
27.1.5. 시스템 복구 수행
복원 또는 마이그레이션을 수행하려면 다음을 수행합니다.
- 새 하드웨어에서 복구 시스템을 부팅합니다. 예를 들어, ISO 이미지를 DVD로 굽고 DVD에서 부팅합니다.
콘솔 인터페이스에서 "Recover" 옵션을 선택합니다.
프롬프트로 이동합니다.
그림 27.2. 복구 시스템: 프롬프트
주의다음 단계에서 복구를 시작한 후에는 취소할 수 없으며 시스템의 물리 디스크에 저장된 모든 항목이 손실될 수 있습니다.
rear recover
명령을 실행하여 복원 또는 마이그레이션을 수행합니다. 그런 다음 복구 시스템은 파티션 레이아웃과 파일 시스템을 다시 생성합니다.그림 27.3. 복구 시스템: "rear recover"를 실행합니다.
백업에서 사용자 및 시스템 파일을
/mnt/local/
디렉토리로 복원합니다.예 27.2. 사용자 및 시스템 파일 복원
이 예에서 백업 파일은 27.2.1.1절. “내부 백업 방법 구성” 의 지침에 따라 생성된 tar 아카이브입니다. 먼저 저장소에서 아카이브를 복사한 다음 파일을
/mnt/local/
에 압축 해제한 다음 아카이브를 삭제합니다.~]# scp root@192.168.122.7:/srv/backup/rhel7/backup.tar.gz /mnt/local/ ~]# tar xf /mnt/local/backup.tar.gz -C /mnt/local/ ~]# rm -f /mnt/local/backup.tar.gz
새 스토리지에는 아카이브와 추출된 파일 모두에 충분한 공간이 있어야 합니다.
파일이 복원되었는지 확인합니다.
~]# ls /mnt/local/
그림 27.4. 시스템 복구: 백업에서 사용자 및 시스템 파일 복원
SELinux가 다음 부팅 시 파일의 레이블을 다시 지정하도록 합니다.
~]# touch /mnt/local/.autorelabel
그렇지 않으면
/etc/passwd
파일에 잘못된 SELinux 컨텍스트가 있을 수 있으므로 시스템에 로그인할 수 없습니다.exit
를 입력하여 복구를 완료합니다. 그런 다음 부트 로더를 다시 설치합니다. 그런 다음 시스템을 재부팅합니다.그림 27.5. 복구 시스템: 복구 완료
재부팅 시 SELinux는 전체 파일 시스템의 레이블을 다시 지정합니다. 그러면 복구된 시스템에 로그인할 수 있습니다.
27.2. ReaR과 Backup Software 통합
ReaR의 주요 목적은 구조 시스템을 생성하는 것이지만 백업 소프트웨어와도 통합될 수 있습니다. 통합이란 기본 제공, 지원 및 지원되지 않는 백업 방법에 따라 다릅니다.
27.2.1. Built-in Backup 방법
Rear에는 내장 또는 내부 백업 방법이 포함됩니다. 이 방법은 다음과 같은 이점이 있는 ReaR과 완전히 통합됩니다.
-
복구 시스템 및 전체 시스템 백업을 단일
rear mkbackup
명령을 사용하여 생성할 수 있습니다. - 복구 시스템이 백업에서 파일을 자동으로 복원
결과적으로 ReaR은 구조 시스템과 전체 시스템 백업을 모두 생성하는 전체 프로세스를 처리할 수 있습니다.
27.2.1.1. 내부 백업 방법 구성
ReaR이 내부 백업 방법을 사용하도록 하려면 다음 행을 /etc/rear/local.conf
에 추가하십시오.
BACKUP=NETFS
BACKUP_URL=backup location
이 행은 tar
명령을 사용하여 전체 시스템 백업을 사용하여 아카이브를 생성하도록 ReaR을 구성합니다. 백업 위치를 rear(8) 매뉴얼 페이지의 "백업 소프트웨어 통합" 섹션의 옵션 중 하나로 대체합니다. 백업 위치에 충분한 공간이 있는지 확인합니다.
예 27.3. tar 백업 추가
27.1절. “기본 ReaR 사용” 에서 예제를 확장하려면 tar 전체 시스템 백업을 /srv/backup/
디렉토리에도 출력하도록 ReaR을 구성합니다.
OUTPUT=ISO OUTPUT_URL=file:///mnt/rescue_system/ BACKUP=NETFS BACKUP_URL=file:///srv/backup/
내부 백업 방법을 사용하면 추가 구성을 사용할 수 있습니다.
새 백업 아카이브를 만들 때 이전 백업 아카이브를 유지하려면 다음 행을 추가합니다.
NETFS_KEEP_OLD_BACKUP_COPY=y
기본적으로 ReaR은 각 실행에 대한 전체 백업을 생성합니다. 백업을 증분 방식으로 만들려면 변경된 파일만 각 실행 시 백업됩니다.
BACKUP_TYPE=incremental
이렇게 하면
NETFS_KEEP_OLD_BACKUP_COPY
가y
로 자동 설정됩니다.증분 백업 외에 전체 백업이 정기적으로 수행되도록 하려면 다음 행을 추가합니다.
FULLBACKUPDAY="Day"
"Day" 를 "Mon", "Tue", "Thu" 중 하나로 바꿉니다. "Fri", "Sat", "Sun".
또한 rear은 ISO 이미지에 복구 시스템과 백업을 모두 포함할 수 있습니다. 이를 위해서는
iso:///backup/
로 RuntimeClass_URL
지시문을 다음과 같이 설정합니다.BACKUP_URL=iso:///backup/
복구 중에 사용자가 백업을 가져올 필요가 없기 때문에 이는 전체 시스템 백업의 가장 간단한 방법입니다. 하지만 더 많은 스토리지가 필요합니다. 또한 단일 ISO 백업을 증분할 수 없습니다.
예 27.4. 단일 ISO 복구 시스템 및 백업 구성
이 구성에서는 복구 시스템 및 백업 파일을 단일 ISO 이미지로 생성하여
/srv/backup/
디렉토리에 저장합니다.OUTPUT=ISO OUTPUT_URL=file:///srv/backup/ BACKUP=NETFS BACKUP_URL=iso:///backup/
참고이 시나리오에서는 ISO 이미지가 클 수 있습니다. 따라서 Red Hat은 두 개의 ISO 이미지가 아니라 하나의 ISO 이미지만 생성하는 것이 좋습니다. 자세한 내용은 “ISO별 구성”의 내용을 참조하십시오.
tar
대신rsync
를 사용하려면 다음 행을 추가합니다.BACKUP_PROG=rsync
증분 백업은
tar
을 사용하는 경우에만 지원됩니다.
27.2.1.2. 내부 백업 방법을 사용하여 백업 생성
ReaR은 RuntimeClass=NETFS
세트를 사용하여 복구 시스템, 백업 파일 또는 둘 다를 생성할 수 있습니다.
복구 시스템만 생성하려면 다음을 실행합니다.
rear mkrescue
백업만 생성하려면 다음을 실행합니다.
rear mkbackuponly
복구 시스템 및 백업을 생성하려면 다음을 실행합니다.
rear mkbackup
ReaR을 사용하여 백업을 트리거하는 것은 NETFS 메서드를 사용하는 경우에만 가능합니다. Rear는 다른 백업 방법을 트리거할 수 없습니다.
복원할 때 복구 . NETFS
설정을 사용하여 만든 복구
시스템을 다시 실행하기 전에 백업이 존재할 것으로 예상합니다. 따라서 복구 시스템이 부팅되면 단일 ISO 이미지를 사용하지 않는 한 backup 파일을 SriovIBNetwork _URL
에 지정된 디렉터리에 복사합니다. 그런 다음 rear recover
를 실행합니다.
복구 시스템을 불필요하게 다시 생성하지 않으려면 다음 명령을 사용하여 마지막 복구 시스템이 생성된 이후 스토리지 레이아웃이 변경되었는지 확인할 수 있습니다.
~]# rear checklayout ~]# echo $?
0이 아닌 상태는 디스크 레이아웃의 변경을 나타냅니다. ReaR 구성이 변경된 경우에도 0이 아닌 상태도 반환됩니다.
rear checklayout
명령은 rescue 시스템이 현재 출력 위치에 있는지 확인하지 않으며, 없는 경우에도 0을 반환할 수 있습니다. 따라서 마지막 복구 시스템이 생성된 이후 레이아웃이 변경되지 않은 경우에만 복구 시스템을 사용할 수 있다고 보장하지 않습니다.
예 27.5. Rear checklayout 사용
복구 시스템을 생성하려면 레이아웃이 변경된 경우에만 다음 명령을 사용하십시오.
~]# rear checklayout || rear mkrescue
27.2.2. 지원되는 백업 방법
ReaR은 NETFS 내부 백업 방법 외에도 여러 외부 백업 방법을 지원합니다. 즉, 복구 시스템은 백업의 파일을 자동으로 복원하지만 ReaR을 사용하여 백업 생성을 트리거할 수 없습니다.
지원되는 외부 백업 방법의 목록 및 구성 옵션은 rear(8) 매뉴얼 페이지의 "Backup Software Integration" 섹션을 참조하십시오.
27.2.3. 지원되지 않는 백업 방법
지원되지 않는 백업 방법에는 다음 두 가지 옵션이 있습니다.
- 복구 시스템은 사용자에게 파일을 수동으로 복원하라는 메시지를 표시합니다. 이 시나리오는 백업 파일 형식을 제외하고 tar 아카이브와 다른 양식을 사용할 수 있는 "Basic ReaR Usage"에 설명된 것입니다.
-
Rear는 사용자가 제공한 사용자 지정 명령을 실행합니다. 이를 구성하려면 RuntimeClass 지시문
을
EXTERNAL
으로 설정합니다. 그런 다음EXTERNAL_BACKUP
및 EXTERNAL_ACCESSORE 지시문을 사용하여 백업 및 복원할 명령을 지정합니다.필요한 경우
EXTERNAL_IGNORE_ERRORS
및EXTERNAL_CHECK
지시문도 지정합니다. 설정 예는/usr/share/rear/conf/default.conf
를 참조하십시오.
27.2.4. 여러 백업 생성
버전 2.00에서 ReaR은 여러 백업 생성을 지원합니다. 이 기능을 지원하는 백업 방법은 다음과 같습니다.
-
RuntimeClass=NETFS
(내부 방법) -
RuntimeClass=BORG
(외부 메서드)
rear
명령의 -C
옵션을 사용하여 개별 백업을 지정할 수 있습니다. 인수는 /etc/rear/
디렉터리에 있는 추가 백업 구성 파일의 기본 이름입니다. 각 특정 백업의 메서드, 대상 및 옵션은 기본 구성 파일이 아닌 특정 구성 파일에 정의되어 있습니다.
시스템의 기본 복구를 수행하려면 다음을 수행합니다.
시스템의 기본 복구
기본 시스템의 파일 백업과 함께 ReaR 복구 시스템 ISO 이미지를 생성합니다.
~]# rear -C basic_system mkbackup
/home
디렉토리에서 파일을 백업하십시오.~]# rear -C home_backup mkbackuponly
지정된 구성 파일에는 시스템의 기본 복구(예: /boot
,/root
, /usr
)에 필요한 디렉터리가 포함되어야 합니다.
Rear 복구 쉘에서 시스템 복구
보조 복구 쉘에서 시스템을 복구하려면 다음 명령 시퀀스를 사용합니다.
~]# rear -C basic_system recover
~]# rear -C home_backup restoreonly
28장. Red Hat Customer Portal Labs Relevant to System Administration
Red Hat 고객 포털 랩은 성능을 개선하고, 문제를 해결하고, 보안 문제를 식별하고, 구성을 최적화할 수 있도록 설계된 툴입니다. 이 부록에서는 시스템 관리와 관련된 Red Hat 고객 포털에 대한 개요를 제공합니다. 모든 Red Hat 고객 포털 랩은 고객 포털 랩 을 통해 제공됩니다.
iSCSI Helper
iSCSI Helper 는 IP(Internet Protocol) 네트워크를 통한 블록 수준 스토리지를 제공하며 서버 가상화 내에서 스토리지 풀을 사용할 수 있습니다.
iSCSI Helper 를 사용하여 사용자가 제공하는 설정에 따라 구성된 iSCSI 대상(서버) 또는 iSCSI 이니시에이터(client)의 역할에 대해 시스템을 준비하는 스크립트를 생성합니다.
NTP 설정
NTP(Network Time Protocol) 구성을 사용하여 다음을 설정합니다.
- NTP 서비스를 실행하는 서버
- NTP 서버와 동기화된 클라이언트
Samba 설정 도우미
Samba 구성 도우미 는 Samba를 통해 기본 파일 및 프린터 공유를 제공하는 구성을 만듭니다.
- 를 클릭하여 기본 서버 설정을 지정합니다.
- 하려는 디렉터리를 추가하려면 공유를 클릭합니다.
- 를 클릭하여 연결된 프린터를 개별적으로 추가합니다.
VNC 구성기
VNC 구성 기는 Red Hat Enterprise Linux 서버에 VNC(Virtual Network Computing) 서버를 설치하고 구성하도록 설계되었습니다.
VNC 구성 기를 사용하여 Red Hat Enterprise Linux 서버에 VNC 서비스를 설치하고 구성하는 데 최적화된 올인원 스크립트를 생성합니다.
브릿지 설정
브리지 구성은 Red Hat Enterprise Linux 5.4 이상을 사용하는 KVM과 같은 애플리케이션에 대해 브리지된 네트워크 인터페이스를 구성하도록 설계되었습니다.
네트워크 연결 도우미
네트워크 본딩 도우미 를 사용하면 관리자가 bonding 커널 모듈과 본딩 네트워크 인터페이스를 사용하여 여러 네트워크 인터페이스 컨트롤러를 단일 채널로 연결할 수 있습니다.
네트워크 연결 도우미를 사용하여 두 개 이상의 네트워크 인터페이스가 하나의 본딩 인터페이스 역할을 하도록 합니다.
LVM RAID Calculator
LVM RAID 계산기 는 스토리지 옵션을 지정한 후 지정된 RAID 스토리지에 논리 볼륨(LVM)을 생성하기 위한 최적의 매개변수를 결정합니다.
LVM RAID 계산기 를 사용하여 지정된 RAID 스토리지에서 LVM을 생성하는 명령 시퀀스를 생성합니다.
NFS Helper
NFS 도우미를 사용하면 새 NFS 서버 또는 클라이언트 구성이 간소화됩니다. 단계에 따라 내보내기 및 마운트 옵션을 지정합니다. 그런 다음 다운로드 가능한 NFS 구성 스크립트를 생성합니다.
로드 밸런서 구성 도구
Load Balancer 구성 도구는 apache 기반 로드 밸런서와 JBoss/Tomcat 애플리케이션 서버 간의 최적의 균형을 만듭니다.
로드 밸런서 구성 도구를 사용하여 환경 성능을 향상시키는 방법에 대한 구성 파일과 조언을 생성합니다.
yum Repository Configuration Helper
YUM 리포지토리 구성 도우미 는 간단한 YUM 리포지토리를 설정하도록 설계되었습니다.
yum Repository Configuration Helper 를 사용하여 다음을 설정합니다.
- 로컬 YUM 리포지토리
- HTTP/ SFTP 기반 YUM 리포지토리
파일 시스템 레이아웃 계산기
파일 시스템 레이아웃 계산기 는 현재 또는 계획된 스토리지를 설명하는 스토리지 옵션을 제공한 후 ext3, ext4 및 xfs 파일 시스템을 생성하기 위한 최적의 매개 변수를 결정합니다.
파일 시스템 레이아웃 계산기 를 사용하여 지정된 RAID 스토리지에 제공된 매개 변수가 있는 파일 시스템을 생성하는 명령을 생성합니다.
RHEL 백업 및 복원 도우미
RHEL 백업 및 복원 도우미 는 백업 및 복원 도구, Linux 사용의 일반적인 시나리오에 대한 정보를 제공합니다.
관련 툴:
-
덤프 및 복원
: ext2, ext3 및 ext4 파일 시스템을 백업하는 데 사용됩니다. -
tar 및 cpio
: 파일 및 폴더를 보관하거나 복원하는 경우, 특히 minion 드라이브를 백업할 때 유용합니다. -
rsync
: 백업 작업을 수행하고 위치 간에 파일과 디렉터리를 동기화하기 위한 것입니다. -
DD
: 파일 시스템 또는 운영 체제와 관계없이 블록별로 소스에서 대상 블록으로 파일을 복사하는 것입니다.
설명된 시나리오:
- 재해 복구
- 하드웨어 마이그레이션
- 파티션 테이블 백업
- 중요한 폴더 백업
- 증분 백업
- 비차별 백업
DNS 도우미
DNS 도우미 는 다양한 유형의 DNS 서버 설정에 대한 지원을 제공합니다.
DNS Helper 를 사용하여 DNS 서버를 자동으로 만들고 구성하는 bash 스크립트를 생성합니다.
AD Integration Helper (Samba FS - winbind)
AD Integration Helperr 은 Samba 파일 시스템 서버를 AD(Active Directory) 서버에 연결하는 데 사용됩니다.
AD Integration Helper 를 사용하여 사용자가 제공하는 기본 AD 서버 정보를 기반으로 스크립트를 생성합니다. 생성된 스크립트는 Samba, Name Service Switch(NSS) 및 Pluggable Authentication Module(PAM)을 구성합니다.
Red Hat Enterprise Linux Upgrade Helper
Red Hat Enterprise Linux Upgrade Helper 는 Red Hat Enterprise Linux를 버전 6.5/6.6/6.7/6.8에서 버전 7.x로 업그레이드할 수 있도록 지원합니다.
registration Assistant
Registration Assistant 는 Red Hat Enterprise Linux 환경에 가장 적합한 등록 옵션을 선택할 수 있도록 설계되었습니다.
복구 모드 Assistant
Rescue Mode Assistant 는 Red Hat Enterprise Linux의 복구 모드에서 다음과 같은 문제를 해결할 수 있도록 설계되었습니다.
- 루트 암호 재설정
- SOS 보고서 생성
- 파일 시스템 검사(fsck) 수행
- GRUB를 다시 설치
- Initial Ramdisk 이미지 다시 빌드
- 루트 파일 시스템의 크기 축소
커널 Oops Analyzer
커널 Oops Analyzer 는 커널 충돌을 해결하는 데 도움이 되도록 설계되었습니다.
커널 Oops Analyzer 를 사용하여 하나 이상의 커널 oops 메시지를 포함한 텍스트 또는 파일을 입력하고 케이스에 적합한 솔루션을 찾습니다.
kdump Helper
Kdump Helper 는 Kdump 메커니즘을 설정하도록 설계되었습니다.
Kdump Helper 를 사용하여 메모리의 데이터를 vmcore라는 덤프 파일로 덤프하도록 Kdump를 설정합니다.
SCSI 디코더
SCSI 디코더 는 /log/*
파일 또는 로그 파일 조각에서 SCSI 오류 메시지를 디코딩하도록 설계되었습니다. 이러한 오류 메시지는 사용자에 대해 이해하기 어려울 수 있습니다.
SCSI 디코더 를 사용하여 각 SCSI 오류 메시지를 개별적으로 진단하고 해결 방법을 제공하여 문제를 효율적으로 해결합니다.
Red Hat Memory Analyzer
Red Hat Memory Analyzer 는 SAR 유틸리티에서 캡처한 정보를 기반으로 시스템의 메모리 사용량을 시각화합니다.
다중 경로 도움말기
Multipath Helper 는 Red Hat Enterprise Linux 5, 6, 7에서 다중 경로 장치에 대한 최적의 구성을 생성합니다.
Multipath Helper 를 사용하여 사용자 지정 별칭 또는 장치 블랙리스트와 같은 고급 다중 경로 구성을 생성합니다.
또한 Multipath Helper는 검토를 위해 multipath.conf
파일을 제공합니다. 필요한 구성을 수행할 때 설치 스크립트를 다운로드하여 서버에서 실행합니다.
다중 경로 구성 시각화기
Multipath Configuration Visualizer 는 SOS 보고서의 파일을 분석하고 다중 경로 구성을 시각화하는 다이어그램을 제공합니다. Multipath Configuration Visualizer 를 사용하여 다음을 표시합니다.
- 서버 측의 HBA(Host Bus Adapters), 로컬 장치 및 iSCSI 장치를 포함한 구성 요소
- 스토리지 측의 스토리지 구성 요소
- 서버와 스토리지 간 패브릭 또는 이더넷 구성 요소
- 언급된 모든 구성 요소의 경로
.xz, .gz 또는 .bz2 형식으로 압축된 SOS 보고서를 업로드하거나 클라이언트 측 분석을 위한 소스로 선택한 디렉터리에 SOS 보고서를 추출할 수 있습니다.
Red Hat I/O 사용 시각화기
Red Hat I/O Usage Visualizer 는 SAR 유틸리티에서 캡처한 I/O 장치 사용량 통계 시각화를 표시합니다.
스토리지 / LVM 구성 뷰어
Storage / LVM 구성 뷰어 는 SOS 보고서에 포함된 파일을 분석하고 다이어그램을 만들어 스토리지/LVM 구성을 시각화합니다.
29장. 개정 내역
0.14-26
2019년 8월 05일, Marie Doleovovtekton (mdolezel@redhat.commailto:mdolezel@redhat.com)
- 7.7 GA 게시에 대한 문서 준비.
0.14-23
2018년 10월 13일mailto:mdolezel@redhat.com
- 7.6 베타 게시에 대한 문서 준비.
0.14-19
2018년 3월 20일
- 7.5 GA 게시를 위한 문서 준비.
0.14-17
2017년 12월 5일, Marie Doleov RuntimeClass (mdolezel@redhat.commailto:mdolezel@redhat.com)
- Samba 섹션이 업데이트되었습니다. TLS를 사용하여 RELP 구성에 대한 섹션이 추가되었습니다. GRUB legacy에서 GRUB 2로 업그레이드에 대한 업데이트된 섹션.
0.14-16
2017년 8월 8일, Marie Doleov ProfileBundle (mdolezel@redhat.commailto:mdolezel@redhat.com)
- 가이드 전체의 작은 수정으로 사용자 지정 유닛 파일의 주문 및 종속 항목을 "사용자 지정 유닛 파일 생성" 장에 주문하기 위한 대상을 선택하는 방법에 대한 링크가 추가되었습니다.
0.14-14
2017년 3월 27일mailto:mdolezel@redhat.com
- 7.4 GA 게시용 문서 버전.
0.14-8
2016년 11월 3일 Maxim Svistunov (msvistun@redhat.com)
- 7.3 GA 게시 버전.
0.14-7
2016년 6월 20일 Maxim Svistunov (msvistun@redhat.commailto:msvistun@redhat.com)
- Relax-and-Recover (ReaR) 가 추가되었습니다.
0.14-6
Thu Mar 10 2016, Maxim Svistunov (msvistun@redhat.commailto:msvistun@redhat.com)
- 마이너 수정 및 업데이트
0.14-5
2016년 1월 21일 Lenka hierapakovtekton(
- 마이너 업데이트입니다.
0.14-3
2015년 11월 11일, Jana Heves (jheves@redhat.commailto:jheves@redhat.com)
- 7.2 GA 릴리스 버전.
0.14-1
2015년 11월 9일, Jana Heves (jheves@redhat.com)
- RH 교육 과정에 대한 마이너 수정, 추가 링크.
0.14-0.3
Fri Apr 3 2015, Stephen Wadeley (swadeley@redhat.com)
- 시스템 등록 및 서브스크립션 관리, Red Hat 지원 도구를 사용하여 액세스 지원, 업데이트된 로그 파일 보기 및 관리.
0.13-2
2015년 2월 24일, Stephen Wadeley (swadeley@redhat.com)
- 7.1 GA 릴리스의 버전입니다.
0.12-0.6
2014년 11월 18일, Stephen Wadeley (swadeley@redhat.com)
- 향상된 TigerVNC.
0.12-0.4
2014년 11월 10일, Stephen Wadeley (swadeley@redhat.com)
- 시스템 , OpenLDAP, 보기 및 관리 로그 파일 , OProfile, GRUB 2 Boot Loader를 사용하여 서비스 관리 , Managing Services with systemd, OpenLDAP , Viewing and Managing Log Files, and Working with the GRUB 2 Boot Loader
0.12-0
Tue 19 Aug 2014, Stephen Wadeley (swadeley@redhat.com)
- Red Hat Enterprise Linux 7.0 GA 릴리스의 시스템 관리자 가이드.
29.1. 감사 인사
이 텍스트의 특정 부분은 Red Hat Enterprise Linux 6 배포 가이드, 저작권 © 2010-2018 Red Hat, Inc.에 처음 기재된 내용은 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/index.html 에서 확인할 수 있습니다.
21.7절. “Net-SNMP를 사용하여 성능 모니터링” 마이클 스크레이터가 작성한 기사를 기반으로 합니다.