Menu Close
Settings Close

Language and Page Formatting Options

Red Hat Training

A Red Hat training course is available for RHEL 8

다양한 유형의 서버 배포

Red Hat Enterprise Linux 8

Red Hat Enterprise Linux 8에서 다양한 유형의 서버 배포 가이드

초록

이 문서에서는 Apache HTTP 웹 서버, Samba 서버, NFS 서버, 사용 가능한 데이터베이스 서버 및 CUPS 서버를 포함하여 Red Hat Enterprise Linux 8에서 다양한 유형의 서버를 구성하고 실행하는 방법을 설명합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서 및 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견에 감사드립니다. 어떻게 개선할 수 있는지 알려주십시오.

특정 문구에 대한 의견 제출

  1. Multi-page HTML 형식으로 설명서를 보고 페이지가 완전히 로드된 후 오른쪽 상단 모서리에 피드백 버튼이 표시되는지 확인합니다.
  2. 커서를 사용하여 주석 처리할 텍스트 부분을 강조 표시합니다.
  3. 강조 표시된 텍스트 옆에 표시되는 피드백 추가 버튼을 클릭합니다.
  4. 의견을 추가하고 제출을 클릭합니다.

Bugzilla를 통해 피드백 제출 (등록 필요)

  1. Bugzilla 웹 사이트에 로그인합니다.
  2. 버전 메뉴에서 올바른 버전을 선택합니다.
  3. 요약 필드에 설명 제목을 입력합니다.
  4. 설명 필드에 개선을 위한 제안을 입력합니다. 문서의 관련 부분에 대한 링크를 포함합니다.
  5. 버그 제출을 클릭합니다.

1장. Apache HTTP 웹 서버 설정

1.1. Apache HTTP 웹 서버 개요

웹 서버는 웹을 통해 클라이언트에 콘텐츠를 제공하는 네트워크 서비스입니다. 이는 일반적으로 웹 페이지를 의미하지만 다른 모든 문서도 될 수 있습니다. 웹 서버는 하이퍼텍스트 전송 프로토콜 (HTTP)을 사용하므로 HTTP 서버라고도 합니다.

Apache HTTP ServerhttpdApache Software Foundation에서 개발한 오픈 소스 웹 서버입니다.

이전 Red Hat Enterprise Linux 릴리스에서 업그레이드하는 경우 그에 따라 httpd 서비스 구성을 업데이트해야 합니다. 이 섹션에서는 새로 추가된 일부 기능을 살펴보고 이전 구성 파일의 업데이트에 대해 설명합니다.

1.2. Apache HTTP Server에서 주요 변경 사항

Apache HTTP Server 가 RHEL 7의 2.4.6 버전에서 RHEL 8의 2.4.37 버전으로 업데이트되었습니다. 이 업데이트된 버전에는 몇 가지 새로운 기능이 포함되어 있지만 외부 모듈 구성 및 ABI(Application Binary Interface) 수준에서는 RHEL 7 버전과의 역호환성을 유지합니다.

새로운 기능은 다음과 같습니다.

  • HTTP/2 지원은 이제 httpd 모듈의 일부인 mod_http2 패키지를 통해 제공됩니다.
  • systemd 소켓 활성화가 지원됩니다. 자세한 내용은 httpd.socket(8) 도움말 페이지를 참조하십시오.
  • 여러 새 모듈이 추가되었습니다.

    • mod_proxy_hcheck - 프록시 상태 확인 모듈
    • mod_proxy_uwsgi - WSGI(Web Server Gateway Interface) 프록시
    • mod_proxy_fdpass - 클라이언트의 소켓을 다른 프로세스에 전달하는 기능을 제공
    • mod_cache_socache - HTTP 캐시 (예: memcache 백엔드를 사용)
    • mod_md - ACME 프로토콜의 SSL/TLS 인증서 서비스
  • 이제 기본적으로 다음 모듈이 로드됩니다.

    • mod_request
    • mod_macro
    • mod_watchdog
  • 디렉터리에 대한 올바른 권한을 포함하여 Apache HTTP Server의 기본 디렉터리 레이아웃이 포함된 새 하위 패키지 httpd-filesystem이 추가되었습니다.
  • 인스턴스화된 서비스 지원 httpd@.service가 도입되었습니다. 자세한 내용은 httpd.service 도움말 페이지를 참조하십시오.
  • httpd-init.service는 자체 서명된 mod_ssl 키 쌍을 생성하기 위해 %post script를 대체합니다.
  • ACME(Automatic Certificate Management Environment) 프로토콜을 사용하는 자동화된 TLS 인증서 프로비저닝 및 업데이트가 이제 mod_md 패키지와 함께 지원됩니다(Let’s Encrypt와 같은 인증 기관을 통해 사용).
  • 이제 Apache HTTP Server에서는 PKCS#11 모듈에서 직접 하드웨어 보안 토큰의 TLS 인증서 및 개인 키를 로드하는 기능을 지원합니다. 결과적으로 이제 mod_ssl 구성에서 PKCS#11 URL을 사용하여 TLS 개인키를 식별할 수 있으며, 선택적으로 SSLCertificateKeyFileSSLCertificateFile 지시문으로 TLS 인증서를 식별할 수 있습니다.
  • /etc/httpd/conf/httpd.conf 파일에 있는 새 ListenFree 지시문이 지원됩니다.

    Listen 지시문과 마찬가지로 ListenFree는 서버가 수신 대기하는 IP 주소, 포트 또는 IP 주소 및 포트 조합에 대한 정보를 제공합니다. 그러나 ListenFree를 사용하면 IP_FREEBIND 소켓 옵션이 기본적으로 활성화됩니다. 따라서 httpd는 비로컬 IP 주소 또는 아직 존재하지 않는 IP 주소에 바인딩할 수 있습니다. 이렇게 하면 httpd가 기본 네트워크 인터페이스나 지정된 동적 IP 주소가 httpd에 바인딩하려고 할 때 소켓에서 수신 대기할 수 있습니다.

    ListenFree 지시문은 현재 RHEL 8에서만 사용할 수 있습니다.

    ListenFree에 대한 자세한 내용은 다음 표를 참조하십시오.

    표 1.1. ListenFree 지시문의 구문, 상태 및 모듈

    구문상태모듈

    ListenFree [IP-address:]portnumber [protocol]

    MPM

    event, worker, prefork, mpm_winnt, mpm_netware, mpmt_os2

기타 주요 변경 사항은 다음과 같습니다.

  • 다음 모듈이 제거되었습니다.

  • RHEL 8의 Apache HTTP Server에서 사용하는 DBM 인증 데이터베이스의 기본 유형이 SDBM에서 db5로 변경되었습니다.
  • Apache HTTP Servermod_wsgi 모듈이 Python 3으로 업데이트되었습니다. WSGI 애플리케이션은 이제 Python 3에서만 지원되며 Python 2에서 마이그레이션해야 합니다.
  • Apache HTTP Server 와 함께 기본적으로 구성된 멀티프로세싱 모듈(MPM)은 멀티 프로세스 분기 모델( prefork라고도 함)에서 고성능 멀티 스레드 모델 event로 변경되었습니다.

    스레드로부터 안전하지 않은 타사 모듈은 교체하거나 제거해야 합니다. 설정된 MPM을 변경하려면 /etc/httpd/conf.modules.d/00-mpm.conf 파일을 편집합니다. 자세한 내용은 httpd.service(8) 도움말 페이지를 참조하십시오.

  • suEXEC에서 사용자에게 허용되는 최소 UID 및 GID는 각각 1000 및 500입니다(이전에는 100 및 100).
  • /etc/sysconfig/httpd 파일은 httpd 서비스의 환경 변수를 설정하기 위해 지원되는 인터페이스가 아닙니다. systemd 서비스에 httpd.service(8) 도움말 페이지가 추가되었습니다.
  • 이제 httpd 서비스를 중지하면 기본적으로 "중지"가 사용됩니다.
  • mod_auth_kerb 모듈이 mod_auth_gssapi 모듈로 교체되었습니다.

1.3. 설정 업데이트

Red Hat Enterprise Linux 7에 사용된 Apache HTTP Server 버전에서 구성 파일을 업데이트하려면 다음 옵션 중 하나를 선택하십시오.

  • /etc/sysconfig/httpd를 사용하여 환경 변수를 설정하는 경우 대신 systemd 드롭인 파일을 만듭니다.
  • 타사 모듈을 사용하는 경우 스레드 MPM과 호환되는지 확인하십시오.
  • suexec를 사용하는 경우 사용자 및 그룹 ID가 새 최소값을 충족하는지 확인합니다.

다음 명령을 사용하여 구성에 오류가 있는지 확인할 수 있습니다.

# apachectl configtest
Syntax OK

1.4. Apache 구성 파일

httpd 는 기본적으로 시작 후 구성 파일을 읽습니다. 아래 표에서 구성 파일 위치 목록을 확인할 수 있습니다.

표 1.2. httpd 서비스 구성 파일

경로설명

/etc/httpd/conf/httpd.conf

기본 구성 파일입니다.

/etc/httpd/conf.d/

기본 구성 파일에 포함된 구성 파일의 보조 디렉토리입니다.

/etc/httpd/conf.modules.d/

Red Hat Enterprise Linux에 패키징된 설치된 동적 모듈을 로드하는 구성 파일의 보조 디렉토리입니다. 기본 구성에서 이러한 구성 파일이 먼저 처리됩니다.

기본 구성은 대부분의 상황에 적합하지만 다른 구성 옵션도 사용할 수 있습니다. 변경 사항을 적용하려면 먼저 웹 서버를 다시 시작합니다.

구성에 가능한 오류가 있는지 확인하려면 쉘 프롬프트에서 다음을 입력합니다.

# apachectl configtest
Syntax OK

실수로부터 더 쉽게 복구하려면 편집하기 전에 원본 파일의 복사본을 만드십시오.

1.5. httpd 서비스 관리

이 섹션에서는 httpd 서비스를 시작, 중지 및 다시 시작하는 방법을 설명합니다.

사전 요구 사항

  • Apache HTTP Server가 설치되어 있어야 합니다.

절차

  • httpd 서비스를 시작하려면 다음을 입력합니다.

    # systemctl start httpd
  • httpd 서비스를 중지하려면 다음을 입력합니다.

    # systemctl stop httpd
  • httpd 서비스를 다시 시작하려면 다음을 입력합니다.

    # systemctl restart httpd

1.6. 단일 인스턴스 Apache HTTP Server 설정

이 섹션에서는 정적 HTML 콘텐츠를 제공하기 위해 단일 인스턴스 Apache HTTP Server를 설정하는 방법을 설명합니다.

웹 서버가 서버와 연결된 모든 도메인에 동일한 콘텐츠를 제공해야 하는 경우 이 섹션의 절차를 따릅니다. 도메인마다 다른 콘텐츠를 제공하려면 이름 기반 가상 호스트를 설정합니다. 자세한 내용은 Apache 이름 기반 가상 호스트 구성을 참조하십시오.

절차

  1. httpd 패키지를 설치합니다.

    # yum install httpd
  2. 로컬 방화벽에서 TCP 포트 80을 엽니다.

    # firewall-cmd --permanent --add-port=80/tcp
    # firewall-cmd --reload
  3. httpd 서비스를 활성화하고 시작합니다.

    # systemctl enable --now httpd
  4. 선택 사항: HTML 파일을 /var/www/html/ 디렉터리에 추가합니다.

    참고

    콘텐츠를 /var/www/html/에 추가할 때 기본적으로 httpd가 실행되는 사용자가 파일 및 디렉터리를 읽을 수 있어야 합니다. 콘텐츠 소유자는 root 사용자 및 root 사용자 그룹 또는 다른 사용자 또는 관리자가 선택한 그룹일 수 있습니다. 콘텐츠 소유자가 root 사용자 및 root 사용자 그룹인 경우 다른 사용자가 파일을 읽을 수 있어야 합니다. 모든 파일 및 디렉터리에 대한 SELinux 컨텍스트는 기본적으로 /var/www 디렉터리 내의 모든 콘텐츠에 적용되는 httpd_sys_content_t이어야 합니다.

검증 단계

  • 웹 브라우저와 함께 http://server_IP_or_host_name/에 연결합니다.

    /var/www/html/ 디렉터리가 비어 있거나 index.html 또는 index.htm 파일이 포함되어 있지 않은 경우 Apache에서 Red Hat Enterprise Linux Test Page를 표시합니다. /var/www/html/에 다른 이름의 HTML 파일이 포함된 경우 http://server_IP_or_host_name/example.html과 같은 URL을 해당 파일에 입력하여 로드할 수 있습니다.

추가 리소스

1.7. Apache 이름 기반 가상 호스트 구성

이름 기반 가상 호스트를 사용하면 Apache가 서버의 IP 주소로 해석되는 다양한 도메인에 다양한 콘텐츠를 제공할 수 있습니다.

이 섹션의 절차에서는 별도의 문서 루트 디렉터리를 사용하여 example.comexample.net 도메인의 가상 호스트 설정에 대해 설명합니다. 두 가상 호스트는 모두 정적 HTML 콘텐츠를 제공합니다.

사전 요구 사항

  • 클라이언트 및 웹 서버는 example.comexample.net 도메인을 웹 서버의 IP 주소로 확인합니다.

    이러한 항목을 DNS 서버에 수동으로 추가해야 합니다.

절차

  1. httpd 패키지를 설치합니다.

    # yum install httpd
  2. /etc/httpd/conf/httpd.conf 파일을 편집합니다.

    1. example.com 도메인에 다음 가상 호스트 구성을 추가합니다.

      <VirtualHost *:80>
          DocumentRoot "/var/www/example.com/"
          ServerName example.com
          CustomLog /var/log/httpd/example.com_access.log combined
          ErrorLog /var/log/httpd/example.com_error.log
      </VirtualHost>

      이러한 설정은 다음을 구성합니다.

      • <VirtualHost *:80> 지시문의 모든 설정은 이 가상 호스트에 따라 다릅니다.
      • DocumentRoot는 가상 호스트의 웹 콘텐츠 경로를 설정합니다.
      • ServerName은 이 가상 호스트가 콘텐츠를 제공하는 도메인을 설정합니다.

        여러 도메인을 설정하려면 ServerAlias 매개 변수를 구성에 추가하고 이 매개 변수에서 공백으로 구분된 추가 도메인을 지정합니다.

      • CustomLog는 가상 호스트의 액세스 로그 경로를 설정합니다.
      • ErrorLog는 가상 호스트의 오류 로그 경로를 설정합니다.

        참고

        Apache는 ServerNameServerAlias 매개 변수에 설정된 도메인과 일치하지 않는 요청에도 구성에 있는 첫 번째 가상 호스트를 사용합니다. 여기에는 서버의 IP 주소로 전송된 요청도 포함됩니다.

  3. example.net 도메인에 대해 유사한 가상 호스트 구성을 추가합니다.

    <VirtualHost *:80>
        DocumentRoot "/var/www/example.net/"
        ServerName example.net
        CustomLog /var/log/httpd/example.net_access.log combined
        ErrorLog /var/log/httpd/example.net_error.log
    </VirtualHost>
  4. 두 가상 호스트 모두에 대한 문서 루트를 생성합니다.

    # mkdir /var/www/example.com/
    # mkdir /var/www/example.net/
  5. /var/www/ 내에 없는 DocumentRoot 매개변수에서 경로를 설정한 경우 두 문서 루트에서 httpd_sys_content_t 컨텍스트를 설정합니다.

    # semanage fcontext -a -t httpd_sys_content_t "/srv/example.com(/.*)?"
    # restorecon -Rv /srv/example.com/
    # semanage fcontext -a -t httpd_sys_content_t "/srv/example.net(/.\*)?"
    # restorecon -Rv /srv/example.net/

    이러한 명령은 /srv/example.com//srv/example.net/ 디렉터리에 httpd_sys_content_t 컨텍스트를 설정합니다.

    restorecon 명령을 실행하려면 policycoreutils-python-utils 패키지를 설치해야 합니다.

  6. 로컬 방화벽에서 포트 80을 엽니다.

    # firewall-cmd --permanent --add-port=80/tcp
    # firewall-cmd --reload
  7. httpd 서비스를 활성화하고 시작합니다.

    # systemctl enable --now httpd

검증 단계

  1. 각 가상 호스트의 문서 루트에 다른 예제 파일을 생성합니다.

    # echo "vHost example.com" > /var/www/example.com/index.html
    # echo "vHost example.net" > /var/www/example.net/index.html
  2. 브라우저를 사용하고 http://example.com에 연결합니다. 웹 서버는 example.com 가상 호스트의 예제 파일을 보여줍니다.
  3. 브라우저를 사용하고 http://example.net에 연결합니다. 웹 서버는 example.net 가상 호스트의 예제 파일을 보여줍니다.

1.8. Apache HTTP 웹 서버에 대한 Kerberos 인증 구성

Apache HTTP 웹 서버에서 Kerberos 인증을 수행하기 위해 RHEL 8에서는 mod_auth_gssapi Apache 모듈을 사용합니다. GSSAPI(Generic Security Services API)는 Kerberos와 같은 보안 라이브러리 사용을 요청하는 애플리케이션의 인터페이스입니다. gssproxy 서비스를 사용하면 httpd 서버에 대해 권한 분리를 구현하여 보안 관점에서 이 프로세스를 최적화할 수 있습니다.

참고

mod_auth_gssapi 모듈은 제거된 mod_auth_kerb 모듈을 대체합니다.

사전 요구 사항

  • httpdgssproxy 패키지가 설치됩니다.
  • Apache 웹 서버가 설정되고 httpd 서비스가 실행 중입니다.

1.8.1. IdM 환경에서 GSS-Proxy 설정

다음 절차에서는 Apache HTTP 웹 서버에서 Kerberos 인증을 수행하기 위해 GSS-Proxy를 설정하는 방법을 설명합니다.

절차

  1. 서비스 주체를 생성하여 HTTP/<SERVER_NAME>@realm 주체의 keytab 파일에 대한 액세스를 활성화합니다.

    # ipa service-add HTTP/<SERVER_NAME>
  2. /etc/gssproxy/http.keytab 파일에 저장된 keytab 탭을 검색합니다.

    # ipa-getkeytab -s $(awk '/^server =/ {print $3}' /etc/ipa/default.conf) -k /etc/gssproxy/http.keytab -p HTTP/$(hostname -f)

    이 단계에서는 권한을 400으로 설정하면 root 사용자만 keytab 파일에 액세스할 수 있습니다. apache 사용자는 그렇지 않습니다.

  3. 다음 콘텐츠를 사용하여 /etc/gssproxy/80-httpd.conf 파일을 만듭니다.

    [service/HTTP]
      mechs = krb5
      cred_store = keytab:/etc/gssproxy/http.keytab
      cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
      euid = apache
  4. gssproxy 서비스를 재시작하고 활성화합니다.

    # systemctl restart gssproxy.service
    # systemctl enable gssproxy.service

추가 리소스

  • gssproxy(8) 매뉴얼 페이지
  • gssproxy-mech(8) 매뉴얼 페이지
  • gssproxy.conf(5) 매뉴얼 페이지

1.8.2. Apache HTTP 웹 서버에서 공유하는 디렉터리에 대한 Kerberos 인증 구성

다음 절차에서는 /var/www/html/private/ 디렉터리에 대한 Kerberos 인증을 구성하는 방법을 설명합니다.

사전 요구 사항

  • gssproxy 서비스가 구성되어 실행 중입니다.

절차

  1. /var/www/html/private/ 디렉터리를 보호하도록 mod_auth_gssapi 모듈을 구성합니다.

    <Location /var/www/html/private>
      AuthType GSSAPI
      AuthName "GSSAPI Login"
      Require valid-user
    </Location>
  2. 다음 콘텐츠를 사용하여 /etc/systemd/system/httpd.service 파일을 만듭니다.

    .include /lib/systemd/system/httpd.service
    [Service]
    Environment=GSS_USE_PROXY=1
  3. systemd 구성을 다시 로드합니다.

    # systemctl daemon-reload
  4. httpd 서비스를 다시 시작합니다.

    # systemctl restart httpd.service

검증 단계

  1. Kerberos 티켓을 받습니다.

    # kinit
  2. 브라우저에서 보호된 디렉터리의 URL을 엽니다.

1.9. Apache HTTP Server에서 TLS 암호화 구성

기본적으로 Apache는 암호화되지 않은 HTTP 연결을 사용하여 클라이언트에 콘텐츠를 제공합니다. 이 섹션에서는 TLS 암호화를 활성화하고 Apache HTTP Server에서 자주 사용하는 암호화 관련 설정을 구성하는 방법에 대해 설명합니다.

사전 요구 사항

  • Apache HTTP Server가 설치되어 실행 중입니다.

1.9.1. Apache HTTP Server에 TLS 암호화 추가

이 섹션에서는 example.com 도메인의 Apache HTTP Server에서 TLS 암호화를 활성화하는 방법을 설명합니다.

사전 요구 사항

  • Apache HTTP Server가 설치되어 실행 중입니다.
  • 개인 키는 /etc/pki/tls/private/example.com.key 파일에 저장됩니다.

    개인 키 및 CSR(인증서 서명 요청) 생성 및 CA(인증 기관)에서 인증서를 요청하는 방법에 대한 자세한 내용은 CA 문서를 참조하십시오. 또는 CA에서 ACME 프로토콜을 지원하는 경우 mod_md 모듈을 사용하여 TLS 인증서 검색 및 프로비저닝을 자동화할 수 있습니다.

  • TLS 인증서는 /etc/pki/tls/certs/example.com.crt 파일에 저장됩니다. 다른 경로를 사용하는 경우 절차의 해당 단계를 조정합니다.
  • CA 인증서는 /etc/pki/tls/certs/ca.crt 파일에 저장됩니다. 다른 경로를 사용하는 경우 절차의 해당 단계를 조정합니다.
  • 클라이언트 및 웹 서버는 서버의 호스트 이름을 웹 서버의 IP 주소로 확인합니다.

절차

  1. mod_ssl 패키지를 설치합니다.

    # yum install mod_ssl
  2. /etc/httpd/conf.d/ssl.conf 파일을 편집하고 다음 설정을 <VirtualHost _default_:443> 지시문에 추가합니다.

    1. 서버 이름을 설정합니다.

      ServerName example.com
      중요

      서버 이름은 인증서의 Common Name 필드에 설정된 항목과 일치해야 합니다.

    2. 선택 사항: 인증서에 SAN(Subject Alt Names) 필드에 추가 호스트 이름이 포함된 경우 이러한 호스트 이름에도 TLS 암호화를 제공하도록 mod_ssl을 구성할 수 있습니다. 이를 구성하려면 해당 이름으로 ServerAliases 매개변수를 추가합니다.

      ServerAlias www.example.com server.example.com
    3. 개인 키, 서버 인증서 및 CA 인증서에 대한 경로를 설정합니다.

      SSLCertificateKeyFile "/etc/pki/tls/private/example.com.key"
      SSLCertificateFile "/etc/pki/tls/certs/example.com.crt"
      SSLCACertificateFile "/etc/pki/tls/certs/ca.crt"
  3. 보안상의 이유로 root 사용자만 개인 키 파일에 액세스할 수 있도록 구성합니다.

    # chown root:root /etc/pki/tls/private/example.com.key
    # chmod 600 /etc/pki/tls/private/example.com.key
    주의

    권한이 없는 사용자가 개인 키에 액세스한 경우 인증서를 취소하고 새 개인 키를 만들고 새 인증서를 요청합니다. 그렇지 않으면 TLS 연결이 더 이상 안전하지 않습니다.

  4. 로컬 방화벽에서 443 포트를 엽니다.

    # firewall-cmd --permanent --add-port=443/tcp
    # firewall-cmd --reload
  5. httpd 서비스를 다시 시작합니다.

    # systemctl restart httpd
    참고

    개인 키 파일을 암호로 보호한 경우 httpd 서비스가 시작될 때마다 이 암호를 입력해야 합니다.

검증 단계

  • 브라우저를 사용하고 https://example.com에 연결합니다.

1.9.2. Apache HTTP Server에서 지원되는 TLS 프로토콜 버전 설정

기본적으로 RHEL의 Apache HTTP Server는 최신 브라우저와 호환되는 안전한 기본값을 정의하는 시스템 전체 암호화 정책을 사용합니다. 예를 들어 DEFAULT 정책은 apache에서 TLSv1.2TLSv1.3 프로토콜 버전만 사용하도록 정의합니다.

이 섹션에서는 Apache HTTP Server에서 지원하는 TLS 프로토콜 버전을 수동으로 구성하는 방법을 설명합니다. 환경에서 특정 TLS 프로토콜 버전만 활성화해야 하는 경우 절차를 따르십시오. 예를 들면 다음과 같습니다.

  • 환경에 해당 클라이언트가 클라이언트가 취약한 TLS1 (TLSv1.0) 또는 TLS1.1 프로토콜을 사용할 수도 있어야 하는 경우
  • Apache가 TLSv1.2 또는 TLSv1.3 프로토콜만 지원하도록 구성하려는 경우

절차

  1. /etc/httpd/conf/httpd.conf 파일을 편집하고 다음 설정을 TLS 프로토콜 버전을 설정하려는 <VirtualHost> 지시문에 추가합니다. 예를 들어 TLSv1.3 프로토콜만 활성화하려면 다음을 수행합니다.

    SSLProtocol -All TLSv1.3
  2. httpd 서비스를 다시 시작합니다.

    # systemctl restart httpd

검증 단계

  1. 다음 명령을 사용하여 서버가 TLSv1.3을 지원하는지 확인합니다:

    # openssl s_client -connect example.com:443 -tls1_3
  2. 다음 명령을 사용하여 서버가 TLSv1.2를 지원하지 않는지 확인합니다.

    # openssl s_client -connect example.com:443 -tls1_2

    서버가 프로토콜을 지원하지 않으면 명령에서 오류를 반환합니다.

    140111600609088:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1543:SSL alert number 70
  3. 선택 사항: 다른 TLS 프로토콜 버전에 대해 명령을 반복합니다.

추가 리소스

1.9.3. Apache HTTP Server에서 지원되는 암호 설정

기본적으로 Apache HTTP 서버는 최근 브라우저와 호환되는 안전한 기본값을 정의하는 시스템 전체 암호화 정책을 사용합니다. 시스템 전체에서 허용하는 암호 목록은 /etc/crypto-policies/back-ends/openssl.config 파일을 참조하십시오.

이 섹션에서는 Apache HTTP Server에서 지원하는 암호를 수동으로 구성하는 방법을 설명합니다. 환경에 특정 암호가 필요한 경우 절차를 따르십시오.

절차

  1. /etc/httpd/conf/httpd.conf 파일을 편집하고 SSLCipherSuite 매개변수를 TLS 암호를 설정하려는 <VirtualHost> 지시문에 추가합니다.

    SSLCipherSuite "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!SHA1:!SHA256"

    이 예제에서는 EECDH+AESGCM,EDH+AESGCM,AES256+EECDHAES256+EDH 암호만 활성화하며 SHA1SHA256 메시지 인증 코드(MAC)를 사용하는 모든 암호를 비활성화합니다.

  2. httpd 서비스를 다시 시작합니다.

    # systemctl restart httpd

검증 단계

  1. Apache HTTP Server에서 지원하는 암호 목록을 표시하려면 다음을 수행합니다.

    1. nmap 패키지를 설치합니다.

      # yum install nmap
    2. nmap 유틸리티를 사용하여 지원되는 암호를 표시합니다.

      # nmap --script ssl-enum-ciphers -p 443 example.com
      ...
      PORT    STATE SERVICE
      443/tcp open  https
      | ssl-enum-ciphers:
      |   TLSv1.2:
      |     ciphers:
      |       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
      |       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
      |       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
      ...

추가 리소스

1.10. TLS 클라이언트 인증서 인증 구성

관리자는 클라이언트 인증서 인증을 통해 인증서를 사용하여 인증한 사용자만 웹 서버의 리소스에 액세스할 수 있도록 허용할 수 있습니다. 이 섹션에서는 /var/www/html/Example/ 디렉터리에 대한 클라이언트 인증서 인증을 구성하는 방법을 설명합니다.

Apache HTTP Server에서 TLS 1.3 프로토콜을 사용하는 경우 특정 클라이언트에 추가 구성이 필요합니다. 예를 들어 Firefox에서 about:config 메뉴의 security.tls.enable_post_handshake_auth 매개 변수를 true로 설정합니다. 자세한 내용은 Red Hat Enterprise Linux 8의 전송 계층 보안 버전 1.3을 참조하십시오.

절차

  1. /etc/httpd/conf/httpd.conf 파일을 편집하고 다음 설정을 클라이언트 인증을 구성하려는 <VirtualHost> 지시문에 추가합니다.

    <Directory "/var/www/html/Example/">
      SSLVerifyClient require
    </Directory>

    SSLverifyClient require를 설정해야 클라이언트가 /var/www/html/Example/ 디렉터리의 콘텐츠에 액세스하기 전에 서버가 클라이언트 인증서의 유효성을 검사해야 합니다.

  2. httpd 서비스를 다시 시작합니다.

    # systemctl restart httpd

검증 단계

  1. curl 유틸리티를 사용하여 클라이언트 인증 없이 https://example.com/Example/ URL에 액세스합니다.

    $ curl https://example.com/Example/
    curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 **alert certificate required**, errno 0

    이 오류는 웹 서버에 클라이언트 인증서 인증이 필요함을 나타냅니다.

  2. 클라이언트 개인 키 및 인증서와 CA 인증서를 curl에 전달하여 클라이언트 인증으로 동일한 URL에 액세스합니다.

    $ curl --cacert ca.crt --key client.key --cert client.crt https://example.com/Example/

    요청이 성공하면 curl/var/www/html/Example/ 디렉터리에 저장된 index.html 파일을 표시합니다.

추가 리소스

1.11. ModSecurity을 사용하여 웹 서버에서 웹 애플리케이션 보안

ModSecurity는 Apache, Nginx 및 IIS와 같은 다양한 웹 서버에서 지원하는 오픈 소스 웹 애플리케이션 방화벽입니다. ModSecurity는 서버 구성을 위해 사용자 정의 가능한 규칙 세트를 제공합니다.

mod_security-crs 패키지에는 웹 사이트 간 스크립팅, 잘못된 사용자 에이전트, SQL 인젝션, 트로이 목마, 세션 hijacking 및 기타 악용에 대한 규칙이 있는 핵심 규칙 세트(CRS)가 포함되어 있습니다.

1.11.1. Apache용 ModSecurity 웹 기반 애플리케이션 방화벽 배포

ModSecurity을 배포하여 웹 서버에서 웹 기반 애플리케이션을 실행하는 것과 관련된 위험을 줄이려면 Apache HTTP 서버에 대한 mod_securitymod_security_crs 패키지를 설치하십시오. mod_security_crs 패키지는 ModSecurity 웹 기반 애플리케이션 방화벽(WAF) 모듈에 대한 핵심 규칙 세트(CRS)를 제공합니다.

절차

  1. mod_security,mod_security_crs, httpd 패키지를 설치합니다.

    # yum install -y mod_security mod_security_crs httpd
  2. httpd 서버를 시작합니다.

    # systemctl restart httpd

검증

  1. Apache HTTP 서버에서 ModSecurity 웹 기반 애플리케이션 방화벽이 활성화되어 있는지 확인합니다.

    # httpd -M | grep security
     security2_module (shared)
  2. /etc/httpd/modsecurity.d/activated_rules/ 디렉터리에 mod_security_crs 에서 제공하는 규칙이 포함되어 있는지 확인합니다.

    # ls /etc/httpd/modsecurity.d/activated_rules/
    ...
    REQUEST-921-PROTOCOL-ATTACK.conf
    REQUEST-930-APPLICATION-ATTACK-LFI.conf
    ...

1.11.2. ModSecurity에 사용자 정의 규칙 추가

ModSecurity 코어 규칙 세트(CRS)에 포함된 규칙이 시나리오에 맞지 않고 가능한 추가 공격을 방지하려면 사용자 지정 규칙을 ModSecurity 웹 기반 애플리케이션 방화벽에서 사용하는 규칙 세트에 추가할 수 있습니다. 다음 예제에서는 간단한 규칙을 추가하는 방법을 보여줍니다. 더 복잡한 규칙을 만들려면 ModSecurity Wiki 웹 사이트의 참조 설명서를 참조하십시오.

사전 요구 사항

  • Apache용 ModSecurity가 설치 및 활성화되어 있습니다.

절차

  1. 선택한 텍스트 편집기에서 /etc/httpd/conf.d/mod_security.conf 파일을 엽니다. 예를 들면 다음과 같습니다.

    # vi /etc/httpd/conf.d/mod_security.conf
  2. SecRuleEngine On:로 시작하는 행 다음에 다음 예제 규칙을 추가합니다.

    SecRule ARGS:data "@contains evil" "deny,status:403,msg:'param data contains evil data',id:1"

    이전 규칙은 data 매개 변수에 잘못된 문자열이 포함된 경우 사용자에게 리소스 사용 을 금지 합니다.

  3. 변경 사항을 저장하고 편집기를 종료합니다.
  4. httpd 서버를 다시 시작합니다.

    # systemctl restart httpd

검증

  1. 테스트.html 페이지를 생성합니다.

    # echo "mod_security test" > /var/www/html/test.html
  2. httpd 서버를 다시 시작합니다.

    # systemctl restart httpd
  3. HTTP 요청의 GET 변수에 악성 데이터 없이 test.html 을 요청합니다.

    $ curl http://localhost/test.html?data=good
    
    mod_security test
  4. HTTP 요청의 GET 변수에 악의적인 데이터를 사용하여 test.html 을 요청합니다.

    $ curl localhost/test.html?data=xxxevilxxx
    
    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
    <html><head>
    <title>403 Forbidden</title>
    </head><body>
    <h1>Forbidden</h1>
    <p>You don't have permission to access this resource.</p>
    </body></html>
  5. /var/log/httpd/error_log 파일을 확인하고 악한 데이터 메시지가 포함된 param 데이터로 액세스를 거부하는 것에 대한 로그 항목을 찾습니다.

    [Wed May 25 08:01:31.036297 2022] [:error] [pid 5839:tid 139874434791168] [client ::1:45658] [client ::1] ModSecurity: Access denied with code 403 (phase 2). String match "evil" at ARGS:data. [file "/etc/httpd/conf.d/mod_security.conf"] [line "4"] [id "1"] [msg "param data contains evil data"] [hostname "localhost"] [uri "/test.html"] [unique_id "Yo4amwIdsBG3yZqSzh2GuwAAAIY"]

추가 리소스

1.12. Apache HTTP Server 수동 설치

이 섹션에서는 Apache HTTP Server 설명서를 설치하는 방법을 설명합니다. 이 설명서는 다음과 같은 자세한 문서를 제공합니다. 예를 들면 다음과 같습니다.

  • 구성 매개변수 및 지시문
  • 성능 튜닝
  • 인증 설정
  • 모듈
  • 컨텐츠 캐싱
  • 보안 팁
  • TLS 암호화 구성

설명서를 설치한 후 웹 브라우저를 사용하여 표시할 수 있습니다.

사전 요구 사항

  • Apache HTTP Server가 설치되어 실행 중입니다.

절차

  1. httpd-manual 패키지를 설치합니다.

    # yum install httpd-manual
  2. 선택 사항: 기본적으로 Apache HTTP 서버에 연결하는 모든 클라이언트는 설명서를 표시할 수 있습니다. 192.0.2.0/24 서브넷과 같은 특정 IP 범위에 대한 액세스를 제한하려면 /etc/httpd/conf.d/manual.conf 파일을 편집하고 Require ip 192.0.2.0/24 설정을 <Directory "/usr/share/httpd/manual"> 지시문에 추가합니다.

    <Directory "/usr/share/httpd/manual">
    ...
        **Require ip 192.0.2.0/24**
    ...
    </Directory>
  3. httpd 서비스를 다시 시작합니다.

    # systemctl restart httpd

검증 단계

  1. Apache HTTP Server 설명서를 표시하려면 웹 브라우저로 http://host_name_or_IP_address/manual/에 연결합니다.

1.13. Apache 모듈 작업

httpd 서비스는 모듈식 애플리케이션이며 다양한DSO( Dynamic Shared Objects )로 확장할 수 있습니다. 동적 공유 오브젝트 는 필요에 따라 런타임에 동적으로 로드 또는 언로드할 수 있는 모듈입니다. 이러한 모듈은 /usr/lib64/httpd/modules/ 디렉토리에서 찾을 수 있습니다.

1.13.1. DSO 모듈 로드

관리자는 서버를 로드할 모듈을 구성하여 서버에 포함할 기능을 선택할 수 있습니다. 특정 DSO 모듈을 로드하려면 LoadModule 지시문을 사용합니다. 별도의 패키지에서 제공하는 모듈에는 /etc/httpd/conf.modules.d/ 디렉터리에 고유한 구성 파일이 있는 경우가 많습니다.

사전 요구 사항

  • httpd 패키지가 설치되어 있습니다.

절차

  1. /etc/httpd/conf.modules.d/ 디렉터리의 구성 파일에서 모듈 이름을 검색합니다.

    # grep mod_ssl.so /etc/httpd/conf.modules.d/*
  2. 모듈 이름을 찾은 구성 파일을 편집하고 모듈의 LoadModule 지시문의 주석을 해제합니다.

    LoadModule ssl_module modules/mod_ssl.so
  3. 예를 들어 RHEL 패키지에서 모듈을 제공하지 않기 때문에 모듈이 없는 경우 다음 지시문을 사용하여 /etc/httpd/conf.modules.d/30-example.conf 와 같은 구성 파일을 만듭니다.

    LoadModule ssl_module modules/<custom_module>.so
  4. httpd 서비스를 다시 시작합니다.

    # systemctl restart httpd

1.13.2. 사용자 정의 Apache 모듈 컴파일

고유한 모듈을 생성하고 httpd-devel 패키지의 도움을 받아 빌드할 수 있습니다. 여기에는 포함 파일, 헤더 파일, 모듈을 컴파일하는 데 필요한 APache eXtenSion (apxs) 유틸리티가 포함됩니다.

사전 요구 사항

  • httpd-devel 패키지가 설치되어 있어야 합니다.

절차

  • 다음 명령을 사용하여 사용자 정의 모듈을 빌드합니다.

    # apxs -i -a -c module_name.c

1.14. Apache 웹 서버 구성에서 사용하기 위해 NSS 데이터베이스에서 개인 키 및 인증서 내보내기

RHEL 8에서는 더 이상 Apache 웹 서버에 mod_nss 모듈을 제공하지 않으며, Red Hat은 mod_ssl 모듈을 사용하는 것이 좋습니다. 예를 들어 웹 서버를 RHEL 7에서 RHEL 8로 마이그레이션했기 때문에 개인 키와 인증서를 NSS(Network Security Services) 데이터베이스에 저장하는 경우 다음 절차에 따라 PEM(개인 정보 보호 보안 메일) 형식으로 키와 인증서를 추출합니다. 그런 다음 Apache HTTP 서버에서 TLS 암호화 구성에 설명된 대로 mod_ssl 구성에서 파일을 사용할 수 있습니다.

이 절차에서는 NSS 데이터베이스가 /etc/httpd/alias/에 저장되고 내보낸 개인 키와 인증서를 /etc/pki/tls/ 디렉터리에 저장하는 것으로 가정합니다.

사전 요구 사항

  • 개인 키, 인증서 및 CA(인증 기관) 인증서는 NSS 데이터베이스에 저장됩니다.

절차

  1. NSS 데이터베이스의 인증서를 나열합니다.

    # certutil -d /etc/httpd/alias/ -L
    Certificate Nickname           Trust Attributes
                                   SSL,S/MIME,JAR/XPI
    
    Example CA                     C,,
    Example Server Certificate     u,u,u

    다음 단계에서 인증서의 닉네임이 필요합니다.

  2. 개인 키를 추출하려면 일시적으로 PKCS #12 파일로 키를 내보내야 합니다.

    1. 개인 키와 연결된 인증서의 닉네임을 사용하여 PKCS #12 파일로 키를 내보냅니다.

      # pk12util -o /etc/pki/tls/private/export.p12 -d /etc/httpd/alias/ -n "Example Server Certificate"
      Enter password for PKCS12 file: password
      Re-enter password: password
      pk12util: PKCS12 EXPORT SUCCESSFUL

      PKCS #12 파일에 암호를 설정해야 합니다. 다음 단계에서 이 암호가 필요합니다.

    2. PKCS #12 파일에서 개인 키를 내보냅니다.

      # openssl pkcs12 -in /etc/pki/tls/private/export.p12 -out /etc/pki/tls/private/server.key -nocerts -nodes
      Enter Import Password: password
      MAC verified OK
    3. 임시 PKCS #12 파일을 삭제합니다.

      # rm /etc/pki/tls/private/export.p12
  3. root 사용자만 이 파일에 액세스할 수 있도록 /etc/pki/tls/private/server.key에 대한 권한을 설정합니다.

    # chown root:root /etc/pki/tls/private/server.key
    # chmod 0600 /etc/pki/tls/private/server.key
  4. NSS 데이터베이스에서 서버 인증서의 닉네임을 사용하여 CA 인증서를 내보냅니다.

    # certutil -d /etc/httpd/alias/ -L -n "Example Server Certificate" -a -o /etc/pki/tls/certs/server.crt
  5. root 사용자만 이 파일에 액세스할 수 있도록 /etc/pki/tls/certs/server.crt에 대한 권한을 설정합니다.

    # chown root:root /etc/pki/tls/certs/server.crt
    # chmod 0600 /etc/pki/tls/certs/server.crt
  6. NSS 데이터베이스에서 CA 인증서의 닉네임을 사용하여 CA 인증서를 내보냅니다.

    # certutil -d /etc/httpd/alias/ -L -n "Example CA" -a -o /etc/pki/tls/certs/ca.crt
  7. Apache HTTP 서버에서 TLS 암호화 구성 을 따라 Apache 웹 서버를 구성합니다.

    • SSLCertificateKeyFile 매개변수를 /etc/pki/tls/private/server.key로 설정합니다.
    • SSLCertificateFile 매개변수를 /etc/pki/tls/certs/server.crt로 설정합니다.
    • SSLCACertificateFile 매개변수를 /etc/pki/tls/certs/ca.crt로 설정합니다.

추가 리소스

  • certutil(1) 매뉴얼 페이지
  • pk12util(1) 매뉴얼 페이지
  • pkcs12(1ssl) 매뉴얼 페이지

1.15. 추가 리소스

2장. NGINX 설정 및 구성

NGINX는 다음과 같이 사용할 수 있는 고성능 모듈식 서버입니다.

  • 웹 서버
  • 역방향 프록시
  • 로드 밸런서

이 섹션에서는 이러한 시나리오에서 NGINX를 수행하는 방법을 설명합니다.

2.1. NGINX 설치 및 준비

Red Hat은 애플리케이션 스트림을 사용하여 다양한 버전의 NGINX를 제공합니다. 이 섹션에서는 다음을 수행하는 방법에 대해 설명합니다.

  • 스트림 선택 및 NGINX를 설치
  • 방화벽에서 필요한 포트를 열기
  • nginx 서비스 활성화 및 시작

기본 구성을 사용하여 NGINX는 포트 80의 웹 서버로 실행되며 /usr/share/nginx/html/ 디렉터리에서 콘텐츠를 제공합니다.

사전 요구 사항

  • RHEL 8이 설치되어 있습니다.
  • 호스트가 Red Hat 고객 포털에 가입되어 있습니다.
  • firewalld 서비스가 활성화 및 시작됩니다.

절차

  1. 사용 가능한 NGINX 모듈 스트림을 표시합니다.

    # yum module list nginx
    Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
    Name        Stream        Profiles        Summary
    nginx       1.14 [d]      common [d]      nginx webserver
    nginx       1.16          common [d]      nginx webserver
    ...
    
    Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled
  2. 기본값과 다른 스트림을 설치하려면 스트림을 선택합니다.

    # yum module enable nginx:stream_version
  3. nginx 패키지를 설치합니다.

    # yum install nginx
  4. NGINX가 방화벽에 서비스를 제공해야 하는 포트를 엽니다. 예를 들어 firewalld에서 HTTP(포트 80) 및 HTTPS(포트 443)의 기본 포트를 열려면 다음을 입력합니다.

    # firewall-cmd --permanent --add-port={80/tcp,443/tcp}
    # firewall-cmd --reload
  5. 시스템이 부팅될 때 nginx 서비스가 자동으로 시작되도록 활성화합니다.

    # systemctl enable nginx
  6. 선택적으로 nginx 서비스를 시작합니다.

    # systemctl start nginx

    기본 구성을 사용하지 않으려면 서비스를 시작하기 전에 이 단계를 건너뛰고 그에 따라 NGINX를 구성합니다.

검증 단계

  1. yum 유틸리티를 사용하여 nginx 패키지가 설치되었는지 확인합니다.

    # yum list installed nginx
    Installed Packages
    nginx.x86_64    1:1.14.1-9.module+el8.0.0+4108+af250afe    @rhel-8-for-x86_64-appstream-rpms
  2. NGINX가 서비스를 제공해야 하는 포트가 firewalld에 열려 있는지 확인합니다.

    # firewall-cmd --list-ports
    80/tcp 443/tcp
  3. nginx 서비스가 활성화되었는지 확인합니다.

    # systemctl is-enabled nginx
    enabled

추가 리소스

2.2. 다른 도메인에 다른 콘텐츠를 제공하는 웹 서버로 NGINX 구성

기본적으로 NGINX는 서버의 IP 주소와 연결된 모든 도메인 이름에 대해 클라이언트에 동일한 콘텐츠를 제공하는 웹 서버 역할을 합니다. 다음 절차에서는 NGINX를 구성하는 방법을 설명합니다.

  • /var/www/example.com/ 디렉터리의 콘텐츠를 사용하여 example.com도메인에 요청을 처리하는 방법
  • /var/www/example.net/ 디렉터리의 콘텐츠를 사용하여 example.net 도메인에 요청을 제공하는 방법
  • 다른 모든 요청(예: 서버의 IP 주소 또는 서버의 IP 주소와 연관된 다른 도메인)에 /usr/share/nginx/html/ 대한 디렉터리의 콘텐츠를 제공하는 방법

사전 요구 사항

  • NGINX 설치
  • 클라이언트 및 웹 서버는 example.comexample.net 도메인을 웹 서버의 IP 주소로 확인합니다.

    이러한 항목을 DNS 서버에 수동으로 추가해야 합니다.

절차

  1. /etc/nginx/nginx.conf 파일을 편집합니다.

    1. 기본적으로 /etc/nginx/nginx.conf 파일에는 catch-all 구성이 이미 포함되어 있습니다. 구성에서 이 부분을 삭제한 경우 /etc/nginx/nginx.conf 파일의 http 블록에 다음 server 블록을 다시 추가합니다.

      server {
          listen       80 default_server;
          listen       [::]:80 default_server;
          server_name  _;
          root         /usr/share/nginx/html;
      }

      이러한 설정은 다음을 구성합니다.

      • listen 지시문은 서비스에서 수신 대기하는 IP 주소와 포트를 정의합니다. 이 경우 NGINX는 모든 IPv4 및 IPv6 주소의 포트 80에서 수신 대기합니다. default_server 매개 변수는 NGINX가 이 server 블록을 IP 주소 및 포트와 일치하는 요청의 기본값으로 사용함을 나타냅니다.
      • server_name 매개 변수는 이 server 블록을 담당하는 호스트 이름을 정의합니다. server_name_로 설정하여 이 server 블록의 모든 호스트 이름을 수락하도록 NGINX를 구성합니다.
      • root 지시문은 이 server 블록의 웹 콘텐츠 경로를 설정합니다.
    2. example.com 도메인에 대한 유사한 server 블록을 http 블록에 추가합니다.

      server {
          server_name  example.com;
          root         /var/www/example.com/;
          access_log   /var/log/nginx/example.com/access.log;
          error_log    /var/log/nginx/example.com/error.log;
      }
      • access_log 지시문은 이 도메인에 대한 별도의 액세스 로그 파일을 정의합니다.
      • error_log 지시문은 이 도메인에 대한 별도의 오류 로그 파일을 정의합니다.
    3. example.net 도메인에 대한 유사한 server 블록을 http 블록에 추가합니다.

      server {
          server_name  example.net;
          root         /var/www/example.net/;
          access_log   /var/log/nginx/example.net/access.log;
          error_log    /var/log/nginx/example.net/error.log;
      }
  2. 두 도메인의 root 디렉터리를 생성합니다.

    # mkdir -p /var/www/example.com/
    # mkdir -p /var/www/example.net/
  3. 두 root 디렉터리에 httpd_sys_content_t 컨텍스트를 설정합니다.

    # semanage fcontext -a -t httpd_sys_content_t "/var/www/example.com(/.*)?"
    # restorecon -Rv /var/www/example.com/
    # semanage fcontext -a -t httpd_sys_content_t "/var/www/example.net(/.\*)?"
    # restorecon -Rv /var/www/example.net/

    이러한 명령은 /var/www/example.com//var/www/example.net/ 디렉터리에 httpd_sys_content_t 컨텍스트를 설정합니다.

    restorecon 명령을 실행하려면 policycoreutils-python-utils 패키지를 설치해야 합니다.

  4. 두 도메인의 로그 디렉터리를 생성합니다.

    # mkdir /var/log/nginx/example.com/
    # mkdir /var/log/nginx/example.net/
  5. nginx 서비스를 다시 시작합니다.

    # systemctl restart nginx

검증 단계

  1. 각 가상 호스트의 문서 루트에 다른 예제 파일을 생성합니다.

    # echo "Content for example.com" > /var/www/example.com/index.html
    # echo "Content for example.net" > /var/www/example.net/index.html
    # echo "Catch All content" > /usr/share/nginx/html/index.html
  2. 브라우저를 사용하고 http://example.com에 연결합니다. 웹 서버는 /var/www/example.com/index.html 파일의 예제 콘텐츠를 표시합니다.
  3. 브라우저를 사용하고 http://example.net에 연결합니다. 웹 서버는 /var/www/example.net/index.html 파일의 예제 콘텐츠를 표시합니다.
  4. 브라우저를 사용하고 http://IP_address_of_the_server 에 연결합니다. 웹 서버는 /usr/share/nginx/html/index.html 파일의 예제 콘텐츠를 표시합니다.

2.3. NGINX 웹 서버에 TLS 암호화 추가

이 섹션에서는 example.com 도메인의 NGINX 웹 서버에서 TLS 암호화를 활성화하는 방법을 설명합니다.

사전 요구 사항

  • NGINX가 설치되어 있습니다.
  • 개인 키는 /etc/pki/tls/private/example.com.key 파일에 저장됩니다.

    개인 키 및 CSR(인증서 서명 요청) 생성 및 CA(인증 기관)에서 인증서를 요청하는 방법에 대한 자세한 내용은 CA 문서를 참조하십시오.

  • TLS 인증서는 /etc/pki/tls/certs/example.com.crt 파일에 저장됩니다. 다른 경로를 사용하는 경우 절차의 해당 단계를 조정합니다.
  • CA 인증서가 서버의 TLS 인증서 파일에 추가되었습니다.
  • 클라이언트 및 웹 서버는 서버의 호스트 이름을 웹 서버의 IP 주소로 확인합니다.
  • 포트 443은 로컬 방화벽에서 열려 있습니다.

절차

  1. /etc/nginx/nginx.conf 파일을 편집하고 다음 server 블록을 구성의 http 블록에 추가합니다.

    server {
        listen              443 ssl;
        server_name         example.com;
        root                /usr/share/nginx/html;
        ssl_certificate     /etc/pki/tls/certs/example.com.crt;
        ssl_certificate_key /etc/pki/tls/private/example.com.key;
    }
  2. 보안상의 이유로 root 사용자만 개인 키 파일에 액세스할 수 있도록 구성합니다.

    # chown root:root /etc/pki/tls/private/example.com.key
    # chmod 600 /etc/pki/tls/private/example.com.key
    주의

    권한이 없는 사용자가 개인 키에 액세스한 경우 인증서를 취소하고 새 개인 키를 만들고 새 인증서를 요청합니다. 그렇지 않으면 TLS 연결이 더 이상 안전하지 않습니다.

  3. nginx 서비스를 다시 시작합니다.

    # systemctl restart nginx

검증 단계

  • 브라우저를 사용하고 https://example.com에 연결

2.4. NGINX를 HTTP 트래픽의 역방향 프록시로 구성

HTTP 트래픽의 역방향 프록시로 작동하도록 NGINX 웹 서버를 구성할 수 있습니다. 예를 들어 이 기능을 사용하여 요청을 원격 서버의 특정 하위 디렉터리에 전달할 수 있습니다. 클라이언트 화면에서 클라이언트는 액세스하는 호스트에서 콘텐츠를 로드합니다. 그러나 NGINX는 원격 서버에서 실제 콘텐츠를 로드하여 클라이언트로 전달합니다.

이 절차에서는 웹 서버의 /example 디렉터리로 트래픽을 URL https://example.com으로 전달하는 방법을 설명합니다.

사전 요구 사항

  • NGINX 설치
  • 선택 사항: TLS 암호화는 역방향 프록시에서 활성화됩니다.

절차

  1. /etc/nginx/nginx.conf 파일을 편집하고 역방향 프록시를 제공해야 하는 server 블록에 다음 설정을 추가합니다.

    location /example {
        proxy_pass https://example.com;
    }

    location 블록은 NGINX가 /example 디렉터리의 모든 요청을 https://example.com으로 전달하도록 정의합니다.

  2. SELinux가 NGINX가 트래픽을 전달할 수 있도록 httpd_can_network_connect SELinux 부울 매개변수를 1로 설정합니다.

    # setsebool -P httpd_can_network_connect 1
  3. nginx 서비스를 다시 시작합니다.

    # systemctl restart nginx

검증 단계

  • 브라우저를 사용하여 http://host_name/example에 연결하면 https://example.com 내용이 표시됩니다.

2.5. NGINX를 HTTP 로드 밸런서로 구성

NGINX 역방향 프록시 기능을 사용하여 트래픽을 로드 밸런싱할 수 있습니다. 이 절차에서는 NGINX를 활성 연결 수가 가장 적은 다른 서버에 요청을 보내는 HTTP 로드 밸런서 장치로 구성하는 방법을 설명합니다. 두 서버를 모두 사용할 수 없는 경우 절차에서는 폴백 이유로 세 번째 호스트도 정의합니다.

사전 요구 사항

  • NGINX 설치

절차

  1. /etc/nginx/nginx.conf 파일을 편집하고 다음 설정을 추가합니다.

    http {
        upstream backend {
            least_conn;
            server server1.example.com;
            server server2.example.com;
            server server3.example.com backup;
        }
    
        server {
            location / {
                proxy_pass http://backend;
            }
        }
    }

    backend라는 호스트 그룹의 least_conn 지시문은 활성 연결 수가 가장 적은 호스트에 따라 NGINX가 server1.example.com 또는 server2.example.com에 요청을 보냅니다. NGINX에서는 다른 두 호스트를 사용할 수 없는 경우에만 server3.example.com을 백업으로 사용합니다.

    proxy_pass 지시문을 http://backend 로 설정하면 NGINX는 역방향 프록시 역할을 하며 backend 호스트 그룹을 사용하여 이 그룹의 설정에 따라 요청을 분산합니다.

    least_conn 로드 밸런싱 방법 대신 다음을 지정할 수 있습니다.

    • 라운드 로빈을 사용하고 서버 간에 요청을 균등하게 배포하는 방법은 없습니다.
    • ip_hash는 IPv4 주소의 처음 세 옥텟 또는 클라이언트의 전체 IPv6 주소에서 계산된 해시를 기반으로 한 클라이언트 주소에서 동일한 서버로 요청을 전송합니다.
    • 문자열, 변수 또는 둘 다 조합일 수 있는 사용자 정의 키를 기반으로 서버를 결정하는 hash 입니다. consistent 매개 변수는 사용자 정의 해시 키 값을 기반으로 NGINX가 모든 서버에 요청을 배포하도록 구성합니다.
    • random은 무작위로 선택된 서버로 요청을 보냅니다.
  2. nginx 서비스를 다시 시작합니다.

    # systemctl restart nginx

2.6. 추가 리소스

3장. 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 버전이 있는 기존 설치에서만 PDC 및 BDC 모드를 지원합니다. Windows 7 및 Windows Server 2008 R2 이외의 Microsoft 운영 체제에서 NT4 도메인을 지원하지 않기 때문에 새 Samba NT4 도메인을 설정하지 않는 것이 좋습니다.

    Red Hat은 Samba를 AD DC(Domain Controller)로 실행하는 것을 지원하지 않습니다.

설치 모드와는 독립적으로 디렉터리와 프린터를 선택적으로 공유할 수 있습니다. 그러면 Samba가 파일 및 인쇄 서버로 작동할 수 있습니다.

3.1. 다양한 Samba 서비스 및 모드 이해

이 섹션에서는 Samba에 포함된 다양한 서비스와 다양한 모드를 설명합니다.

3.1.1. Samba 서비스

Samba는 다음 서비스를 제공합니다.

smbd

이 서비스는 SMB 프로토콜을 사용하여 파일 공유 및 인쇄 서비스를 제공합니다. 또한 서비스는 리소스 잠금을 담당하고 사용자 연결을 인증합니다. 도메인 멤버를 인증하기 위해 smbd 에는 winbindd 가 필요합니다. smb systemd 서비스는 smbd 데몬을 시작하고 중지합니다.

smbd 서비스를 사용하려면 samba 패키지를 설치합니다.

nmbd

이 서비스는 NetBIOS over IPv4 프로토콜을 사용하여 호스트 이름 및 IP 확인을 제공합니다. 이름 확인 외에도 nmbd 서비스를 사용하면 SMB 네트워크를 검색하여 도메인, 작업 그룹, 호스트, 파일 공유 및 프린터를 찾을 수 있습니다. 이를 위해 서비스는 이 정보를 브로드캐스트 클라이언트에 직접 보고하거나 로컬 또는 마스터 브라우저로 전달합니다. nmb systemd 서비스는 nmbd 데몬을 시작하고 중지합니다.

최신 SMB 네트워크는 DNS를 사용하여 클라이언트 및 IP 주소를 확인합니다. Kerberos의 경우 작동 중인 DNS 설정이 필요합니다.

nmbd 서비스를 사용하려면 samba 패키지를 설치합니다.

winbindd

이 서비스는 로컬 시스템에서 AD 또는 NT4 도메인 사용자 및 그룹을 사용할 수 있도록 NSS(Name Service Switch)에 대한 인터페이스를 제공합니다. 예를 들어, 도메인 사용자는 Samba 서버 또는 다른 로컬 서비스에 호스팅된 서비스에 대해 인증할 수 있습니다. winbind systemd 서비스는 winbindd 데몬을 시작하고 중지합니다.

Samba를 도메인 멤버로 설정하는 경우, smbd 서비스보다 먼저 winbindd를 시작해야 합니다. 그렇지 않으면 도메인 사용자 및 그룹을 로컬 시스템에서 사용할 수 없습니다.

winbindd 서비스를 사용하려면 samba-winbind 패키지를 설치합니다.

중요

Red Hat은 도메인 사용자 및 그룹을 로컬 시스템에 제공하기 위해 winbindd 서비스가 있는 서버로만 Samba 실행을 지원합니다. ACL(Windows Access Control List) 지원 및 NTLM(NT LAN Manager) 대체와 같은 특정 제한 사항으로 인해 SSSD는 지원되지 않습니다.

3.1.2. Samba 보안 서비스

/etc/samba/smb.conf 파일의 [global] 섹션에 있는 security 매개 변수는 Samba가 서비스에 연결하는 사용자를 인증하는 방법을 관리합니다. Samba를 설치하는 모드에 따라 매개 변수를 다른 값으로 설정해야 합니다.

AD 도메인 구성원에서 security = ads를 설정

이 모드에서 Samba는 Kerberos를 사용하여 AD 사용자를 인증합니다.

Samba를 도메인 멤버로 설정하는 방법에 대한 자세한 내용은 Setting up Samba as an AD domain member server 를 참조하십시오.

독립 실행형 서버에서 security = user 설정

이 모드에서 Samba는 로컬 데이터베이스를 사용하여 연결 사용자를 인증합니다.

Samba를 독립 실행형 서버로 설정하는 방법에 대한 자세한 내용은 Samba를 독립 실행형 서버로 설정을 참조하십시오.

NT4 PDC 또는 BDC에서 security = user를 설정
이 모드에서 Samba는 로컬 또는 LDAP 데이터베이스로 사용자를 인증합니다.
NT4 도메인 멤버에서 security = domain설정

이 모드에서 Samba는 사용자를 NT4 PDC 또는 BDC에 연결하는 것을 인증합니다. AD 도메인 구성원에서는 이 모드를 사용할 수 없습니다.

Samba를 도메인 멤버로 설정하는 방법에 대한 자세한 내용은 Setting up Samba as an AD domain member server 를 참조하십시오.

추가 리소스

  • smb.conf(5) 도움말 페이지의 security 매개변수

3.1.3. Samba 서비스 및 Samba 클라이언트 유틸리티가 구성을 로드 및 다시 로드하는 시나리오

다음은 Samba 서비스 및 유틸리티가 설정을 로드하고 다시 로드하는 경우를 설명합니다.

  • Samba 서비스는 설정을 다시 로드합니다.

    • 자동으로 3분마다
    • 예를 들어, manual 요청에서 smbcontrol all reload-config 명령을 실행하는 경우입니다.
  • Samba 클라이언트 유틸리티는 처음 시작할 때만 구성을 읽습니다.

security 등의 특정 매개 변수를 사용하려면 smb 서비스를 다시 시작해야 하며 다시 로드하는 것만으로는 충분하지 않습니다.

추가 리소스

  • smb.conf(5) 도움말 페이지의 구성 변경 내용 적용 방법
  • smbd(8), nmbd(8)winbindd(8) 도움말 페이지

3.1.4. 안전한 방식으로 Samba 구성 편집

Samba 서비스는 3분마다 구성을 자동으로 다시 로드합니다. 이 절차에서는 testparm 유틸리티를 사용하여 구성을 확인하기 전에 서비스가 변경 사항을 다시 로드하지 못하도록 Samba 구성을 편집하는 방법을 설명합니다.

사전 요구 사항

  • Samba가 설치되어 있어야 합니다.

절차

  1. /etc/samba/smb.conf 파일의 사본을 생성합니다.

    # cp /etc/samba/smb.conf /etc/samba/samba.conf.copy
  2. 복사한 파일을 편집하고 원하는 대로 변경합니다.
  3. /etc/samba/samba.conf.copy 파일에서 구성을 확인합니다.

    # testparm -s /etc/samba/samba.conf.copy

    testparm이 오류를 보고하면 오류를 수정하고 명령을 다시 실행합니다.

  4. /etc/samba/smb.conf 파일을 새 구성으로 재정의합니다.

    # mv /etc/samba/samba.conf.copy /etc/samba/smb.conf
  5. Samba 서비스가 구성을 자동으로 다시 로드하거나 구성을 수동으로 다시 로드할 때까지 기다립니다.

    # smbcontrol all reload-config

3.2. testparm 유틸리티를 사용하여 smb.conf 파일 확인

testparm 유틸리티는 /etc/samba/smb.conf 파일의 Samba 구성이 올바른지 확인합니다. 유틸리티는 잘못된 매개 변수와 값을 감지하지만 ID 매핑과 같은 잘못된 설정도 탐지합니다. testparm이 문제를 보고하지 않으면 Samba 서비스가 /etc/samba/smb.conf 파일을 로드합니다. testparm은 구성된 서비스가 사용 가능한지 또는 예상대로 작동하는지 확인할 수 없습니다.

중요

Red Hat은 이 파일을 수정한 후 testparm을 사용하여 /etc/samba/smb.conf 파일을 확인하는 것이 좋습니다.

사전 요구 사항

  • Samba가 설치되어 있어야 합니다.
  • /etc/samba/smb.conf 파일을 종료합니다.

절차

  1. testparm 유틸리티를 root 사용자로 실행합니다.

    # 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]
    	...

    이전 예제 출력에서는 존재하지 않는 매개 변수와 잘못된 ID 매핑 구성을 보고합니다.

  2. testparm이 구성에 잘못된 매개 변수, 값 또는 기타 오류를 보고하면 문제를 수정하고 유틸리티를 다시 실행합니다.

3.3. 독립 실행형 서버로 Samba 설정

Samba를 도메인의 멤버가 아닌 서버로 설정할 수 있습니다. 이 설치 모드에서 Samba는 중앙 DC가 아니라 로컬 데이터베이스로 사용자를 인증합니다. 또한 게스트 액세스를 활성화하여 사용자가 인증 없이 하나 이상의 서비스에 연결할 수 있습니다.

3.3.1. 독립 실행형 서버에 대한 서버 구성 설정

이 섹션에서는 Samba 독립 실행형 서버에 대한 서버 구성을 설정하는 방법을 설명합니다.

절차

  1. samba 패키지를 설치합니다.

    # yum install samba
  2. /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 이름으로 확장합니다. 이를 통해 각 클라이언트에 대한 개별 로그 파일이 활성화됩니다.

  3. 선택적으로 파일 또는 프린터 공유를 구성합니다. 다음 내용을 참조하십시오.

  4. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  5. 인증이 필요한 공유를 설정하면 사용자 계정을 생성합니다.

    자세한 내용은 로컬 사용자 계정 생성 및 활성화를 참조하십시오.

  6. 필요한 포트를 열고 firewall-cmd 유틸리티를 사용하여 방화벽 구성을 다시 로드합니다.

    # firewall-cmd --permanent --add-service=samba
    # firewall-cmd --reload
  7. smb 서비스를 활성화하고 시작합니다.

    # systemctl enable --now smb

추가 리소스

  • smb.conf(5) man page

3.3.2. 로컬 사용자 계정 생성 및 활성화

사용자가 공유에 연결할 때 인증할 수 있도록 하려면 운영 체제와 Samba 데이터베이스에서 Samba 호스트에 계정을 만들어야 합니다. Samba는 파일 시스템 개체 및 Samba 계정에서 연결 사용자를 인증하기 위해 운영 체제 계정이 ACL(액세스 제어 목록)의 유효성을 검사해야 합니다.

passdb backend = tdbsam 기본 설정을 사용하는 경우 Samba는 사용자 계정을 /var/lib/samba/private/passdb.tdb 데이터베이스에 저장합니다.

이 섹션의 절차에서는 example 이라는 로컬 Samba 사용자를 만드는 방법을 설명합니다.

사전 요구 사항

  • Samba는 독립 실행형 서버로 설치 및 구성됩니다.

절차

  1. 운영 체제 계정을 생성합니다.

    # useradd -M -s /sbin/nologin example

    이 명령은 홈 디렉터리를 생성하지 않고 example 계정을 추가합니다. 계정이 Samba로 인증하는 데만 사용되는 경우 계정이 로컬에 로그인하지 못하도록 /sbin/nologin 명령을 쉘로 할당합니다.

  2. 활성화하려면 암호를 운영 체제 계정으로 설정합니다.

    # passwd example
    Enter new UNIX password: password
    Retype new UNIX password: password
    passwd: password updated successfully

    Samba는 운영 체제 계정에 설정된 암호를 사용하여 인증하지 않습니다. 그러나 계정을 활성화하려면 암호를 설정해야 합니다. 계정이 비활성화되어 있으면 Samba는 이 사용자가 연결하면 액세스를 거부합니다.

  3. 사용자를 Samba 데이터베이스에 추가하고 암호를 계정으로 설정합니다.

    # smbpasswd -a example
    New SMB password: password
    Retype new SMB password: password
    Added user example.

    이 계정을 사용하여 Samba 공유에 연결할 때 인증하려면 이 암호를 사용합니다.

  4. Samba 계정을 활성화합니다.

    # smbpasswd -e example
    Enabled user example.

3.4. Samba ID 매핑 이해 및 구성

Windows 도메인은 고유한 SID(보안 식별자)를 통해 사용자와 그룹을 구분합니다. 그러나 Linux에는 사용자 및 그룹마다 고유한 UID와 GID가 필요합니다. 도메인 구성원으로 Samba를 실행하는 경우 winbindd 서비스는 도메인 사용자 및 그룹에 대한 정보를 운영 체제에 제공합니다.

winbindd 서비스를 활성화하여 Linux에 사용자와 그룹에 고유한 ID를 제공하려면 /etc/samba/smb.conf 파일에 ID 매핑을 구성해야 합니다.

  • 로컬 데이터베이스(기본 도메인)
  • Samba 서버가 멤버인 AD 또는 NT4 도메인
  • 사용자가 이 Samba 서버의 리소스에 액세스할 수 있어야 하는 각 신뢰할 수 있는 도메인

Samba는 특정 구성에 대해 다양한 ID 매핑 백엔드를 제공합니다. 가장 자주 사용되는 백엔드는 다음과 같습니다.

백엔드사용 사례

tdb

* 기본 도메인만 해당

ad

AD 도메인만 해당

rid

AD 및 NT4 도메인

autorid

AD, NT4 및 * 기본 도메인

3.4.1. Samba ID 범위 계획

Linux UID 및 GID를 AD에 저장하는지 여부 또는 이를 생성하도록 Samba를 구성하는지 여부에 관계없이 각 도메인 설정에는 다른 도메인과 겹치지 않아야 하는 고유한 ID 범위가 필요합니다.

주의

중복 ID 범위를 설정하면 Samba가 올바르게 작동하지 않습니다.

예 3.1. 고유 ID 범위

다음은 기본값(*), AD-DOM, 및 TRUST-DOM 도메인에 대한 인수 이외의 ID 매핑 범위를 보여줍니다.

[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
중요

도메인당 하나의 범위만 할당할 수 있습니다. 따라서 도메인 범위 사이에 충분한 공간을 남겨 두십시오. 이렇게 하면 나중에 도메인이 확장되는 경우 범위를 확장할 수 있습니다.

나중에 도메인에 다른 범위를 할당하면 이러한 사용자와 그룹이 이전에 만든 파일과 디렉터리의 소유권이 손실됩니다.

3.4.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

자세한 내용은 TDB ID 매핑 백엔드 사용을 참조하십시오.

autorid

autorid 백엔드를 사용하도록 기본 도메인을 구성하는 경우 도메인에 대한 ID 매핑 구성을 추가하는 것은 선택 사항입니다.

예를 들어 /etc/samba/smb.conf 파일의 [global] 섹션에서 다음을 설정합니다.

idmap config * : backend = autorid
idmap config * : range = 10000-999999

자세한 내용은 Autorid ID 매핑 백엔드 사용을 참조하십시오.

3.4.3. tdb ID 매핑 백엔드 사용

winbindd 서비스는 기본적으로 쓰기 가능한 tdb ID 매핑 백엔드를 사용하여 SID(보안 식별자), UID 및 GID 매핑 테이블을 저장합니다. 여기에는 로컬 사용자, 그룹 및 기본 제공 주체가 포함됩니다.

이 백엔드는 * 기본 도메인에만 사용합니다. 예를 들면 다음과 같습니다.

idmap config * : backend = tdb
idmap config * : range = 10000-999999

추가 리소스

3.4.4. ad ID 매핑 백엔드 사용

이 섹션에서는 ad ID 매핑 백엔드를 사용하도록 Samba AD 멤버를 구성하는 방법을 설명합니다.

ad ID 매핑 백엔드는 읽기 전용 API를 구현하여 AD에서 계정 및 그룹 정보를 읽습니다. 이는 다음과 같은 이점을 제공합니다.

  • 모든 사용자 및 그룹 설정은 AD에 중앙에 저장됩니다.
  • 이 백엔드를 사용하는 모든 Samba 서버에서 사용자 및 그룹 ID가 일관되게 유지됩니다.
  • ID는 손상될 수 있는 로컬 데이터베이스에 저장되지 않으므로 파일 소유권을 분실할 수 없습니다.
참고

ad ID 매핑 백엔드는 단방향 트러스트가 있는 Active Directory 도메인을 지원하지 않습니다. 단방향 트러스트를 사용하여 Active Directory에 도메인 멤버를 구성하는 경우 tdb, rid, autorid와 같은 ID 매핑 백엔드 중 하나를 대신 사용합니다.

애드혹 백엔드는 AD에서 다음 속성을 읽습니다.

AD 속성 이름오브젝트 유형매핑 대상

sAMAccountName

사용자 및 그룹

사용자 또는 그룹 이름 (오브젝트에 따라)

uidNumber

사용자

사용자 ID(UID)

gidNumber

Group

그룹 ID(GID)

loginShell [a]

사용자

사용자 쉘의 경로

unixHomeDirectory [a]

사용자

사용자의 홈 디렉터리 경로

primaryGroupID [b]

사용자

기본 그룹 ID

[a] Samba는 idmap config DOMAIN:unix_nss_info = yes를 설정하는 경우에만 이 속성을 읽습니다.
[b] Samba는 idmap config DOMAIN:unix_primary_group = yes를 설정하는 경우에만 이 속성을 읽습니다.

사전 요구 사항

  • 사용자와 그룹 모두 AD에 고유한 ID를 설정해야 하며 ID는 /etc/samba/smb.conf 파일에 구성된 범위 내에 있어야 합니다. 범위를 벗어나는 ID가 있는 개체는 Samba 서버에서 사용할 수 없습니다.
  • 사용자와 그룹은 AD에서 모든 필수 속성을 설정해야 합니다. 필수 속성이 없으면 Samba 서버에서 사용자 또는 그룹을 사용할 수 없습니다. 필수 속성은 구성에 따라 다릅니다. . 전제 조건
  • Samba가 설치되어 있어야 합니다.
  • ID 매핑을 제외한 Samba 구성이 /etc/samba/smb.conf 파일에 있습니다.

절차

  1. /etc/samba/smb.conf 파일에서 [global] 섹션을 편집합니다.

    1. 없는 경우 기본 도메인 (*)의 ID 매핑 구성을 추가합니다. 예를 들면 다음과 같습니다.

      idmap config * : backend = tdb
      idmap config * : range = 10000-999999
    2. AD 도메인의 ad ID 매핑 백엔드를 활성화합니다.

      idmap config DOMAIN : backend = ad
    3. AD 도메인의 사용자와 그룹에 할당된 ID 범위를 설정합니다. 예를 들면 다음과 같습니다.

      idmap config DOMAIN : range = 2000000-2999999
      중요

      범위는 이 서버의 다른 도메인 구성과 겹치지 않아야 합니다. 또한 범위는 나중에 할당되는 모든 ID를 포함할 만큼 충분히 커야 합니다. 자세한 내용은 Planning Samba ID 범위를 참조하십시오.

    4. AD에서 속성을 읽을 때 Samba가 RFC 2307 스키마를 사용하도록 설정합니다.

      idmap config DOMAIN : schema_mode = rfc2307
    5. Samba가 해당 AD 속성에서 로그인 쉘 및 사용자 홈 디렉터리 경로를 읽을 수 있도록 하려면 다음을 설정합니다.

      idmap config DOMAIN : unix_nss_info = yes

      또는 모든 사용자에게 적용되는 균일한 도메인 전체 홈 디렉터리 경로 및 로그인 쉘을 설정할 수 있습니다. 예를 들면 다음과 같습니다.

      template shell = /bin/bash
      template homedir = /home/%U
    6. 기본적으로 Samba는 사용자 오브젝트의 primaryGroupID 속성을 Linux의 사용자 기본 그룹으로 사용합니다. 또는 대신 gidNumber 특성에 설정된 값을 사용하도록 Samba를 구성할 수 있습니다.

      idmap config DOMAIN : unix_primary_group = yes
  2. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  3. Samba 구성을 다시 로드합니다.

    # smbcontrol all reload-config

추가 리소스

  • * 기본 도메인
  • smb.conf(5)idmap_ad(8) man 페이지
  • smb.conf(5) 도움말 페이지의 VARIABLE SUBSTITUTIONS 섹션

3.4.5. 제거 ID 매핑 백엔드 사용

이 섹션에서는 rid ID 매핑 백엔드를 사용하도록 Samba 도메인 멤버를 구성하는 방법에 대해 설명합니다.

Samba는 Windows SID의 상대 식별자(RID)를 사용하여 Red Hat Enterprise Linux에서 ID를 생성할 수 있습니다.

참고

RID는 SID의 마지막 부분입니다. 예를 들어 사용자의 SID가 S-1-5-21-5421822485-11512151-421485315-30014 이면 30014 가 해당하는 RID입니다.

rid ID 매핑 백엔드는 AD 및 NT4 도메인의 알고리즘 매핑 체계를 기반으로 계정과 그룹 정보를 계산하는 읽기 전용 API를 구현합니다. 백엔드를 구성할 때 idmap config DOMAIN : range 매개변수에서 가장 낮고 가장 높은 RID를 설정해야 합니다. Samba는 이 매개 변수에 설정된 것보다 낮은 RID를 가진 사용자 또는 그룹을 매핑하지 않습니다.

중요

읽기 전용 백엔드인 ridBUILTIN 그룹과 같은 새 ID를 할당할 수 없습니다. 따라서 * 기본 도메인에 이 백엔드를 사용하지 마십시오.

rid 백엔드 사용의 이점

  • 구성된 범위 내에 RID가 있는 모든 도메인 사용자 및 그룹은 도메인 멤버에서 자동으로 사용할 수 있습니다.
  • ID, 홈 디렉터리 및 로그인 쉘을 수동으로 할당할 필요가 없습니다.

rid 백엔드 사용의 단점

  • 모든 도메인 사용자는 동일한 로그인 쉘 및 홈 디렉터리가 할당됩니다. 그러나 변수를 사용할 수 있습니다.
  • 사용자 및 그룹 ID는 모두 동일한 ID 범위 설정으로 rid 백엔드를 사용하는 경우 Samba 도메인 멤버에서만 동일합니다.
  • 도메인 구성원에서 개별 사용자 또는 그룹을 사용할 수 없는 경우 제외할 수 없습니다. 구성된 범위를 벗어난 사용자 및 그룹만 제외됩니다.
  • winbindd 서비스에서 ID를 계산하는 데 사용하는 공식에 따라 다른 도메인의 오브젝트에 동일한 RID가 있는 경우 다중 도메인 환경에서 중복 ID가 발생할 수 있습니다.

사전 요구 사항

  • Samba가 설치되어 있어야 합니다.
  • ID 매핑을 제외한 Samba 구성이 /etc/samba/smb.conf 파일에 있습니다.

절차

  1. /etc/samba/smb.conf 파일에서 [global] 섹션을 편집합니다.

    1. 없는 경우 기본 도메인 (*)의 ID 매핑 구성을 추가합니다. 예를 들면 다음과 같습니다.

      idmap config * : backend = tdb
      idmap config * : range = 10000-999999
    2. 도메인에 대해 rid ID 매핑 백엔드를 활성화합니다.

      idmap config DOMAIN : backend = rid
    3. 향후 할당될 모든 RID를 포함할 만큼 큰 범위를 설정합니다. 예를 들면 다음과 같습니다.

      idmap config DOMAIN : range = 2000000-2999999

      Samba는 이 도메인의 RID가 범위에 속하지 않는 사용자와 그룹을 무시합니다.

      중요

      범위는 이 서버의 다른 도메인 구성과 겹치지 않아야 합니다. 또한 범위는 나중에 할당되는 모든 ID를 포함할 만큼 충분히 커야 합니다. 자세한 내용은 Planning Samba ID 범위를 참조하십시오.

    4. 매핑된 모든 사용자에게 할당될 쉘 및 홈 디렉터리 경로를 설정합니다. 예를 들면 다음과 같습니다.

      template shell = /bin/bash
      template homedir = /home/%U
  2. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  3. Samba 구성을 다시 로드합니다.

    # smbcontrol all reload-config

추가 리소스

  • * 기본 도메인
  • smb.conf(5) 도움말 페이지의 VARIABLE SUBSTITUTIONS 섹션
  • RID에서 로컬 ID 계산은 idmap_rid(8) 매뉴얼 페이지를 참조하십시오.

3.4.6. 자동 덮어쓰기 ID 매핑 백엔드 사용

이 섹션에서는 autorid ID 매핑 백엔드를 사용하도록 Samba 도메인 멤버를 구성하는 방법에 대해 설명합니다.

autorid 백엔드는 rid ID 매핑 백엔드와 유사하게 작동하지만 다른 도메인에 대한 ID를 자동으로 할당할 수 있습니다. 이를 통해 다음과 같은 상황에서 autorid 백엔드를 사용할 수 있습니다.

  • * 기본 도메인 전용
  • * 기본 도메인 및 추가 도메인의 경우 각 추가 도메인에 대한 ID 매핑 구성을 생성할 필요가 없습니다.
  • 특정 도메인 전용
참고

기본 도메인에 autorid를 사용하는 경우 도메인에 대한 ID 매핑 구성을 추가하는 것은 선택 사항입니다.

이 섹션의 일부는 Samba Wiki에 게시된 idmap config autorid 문서에서 채택되었습니다. 라이센스: CC BY 4.0. 작성자 및 기여자: Wiki 페이지의 기록 탭을 참조하십시오.

autorid 백엔드 사용의 이점

  • 계산된 UID 및 GID가 구성된 범위 내에 있는 모든 도메인 사용자와 그룹은 도메인 멤버에서 자동으로 사용할 수 있습니다.
  • ID, 홈 디렉터리 및 로그인 쉘을 수동으로 할당할 필요가 없습니다.
  • 다중 도메인 환경의 여러 오브젝트에 동일한 RID가 있는 경우에도 중복 ID가 없습니다.

단점

  • 사용자 및 그룹 ID는 Samba 도메인 구성원에서 동일하지 않습니다.
  • 모든 도메인 사용자는 동일한 로그인 쉘 및 홈 디렉터리가 할당됩니다. 그러나 변수를 사용할 수 있습니다.
  • 도메인 구성원에서 개별 사용자 또는 그룹을 사용할 수 없는 경우 제외할 수 없습니다. 계산된 UID 또는 GID가 구성된 범위를 벗어나는 사용자와 그룹만 제외됩니다.

사전 요구 사항

  • Samba가 설치되어 있어야 합니다.
  • ID 매핑을 제외한 Samba 구성이 /etc/samba/smb.conf 파일에 있습니다.

절차

  1. /etc/samba/smb.conf 파일에서 [global] 섹션을 편집합니다.

    1. * 기본 도메인의 autorid ID 매핑 백엔드를 활성화합니다.

      idmap config * : backend = autorid
    2. 모든 기존 및 향후 객체에 ID를 할당할 수 있을 만큼 큰 범위를 설정합니다. 예를 들면 다음과 같습니다.

      idmap config * : range = 10000-999999

      Samba는 이 도메인에서 계산된 ID가 범위에 속하지 않는 사용자와 그룹을 무시합니다.

      주의

      범위를 설정하고 Samba가 사용을 시작한 후 범위의 상한값만 늘릴 수 있습니다. 범위에 대한 다른 모든 변경으로 인해 새 ID 할당이 발생할 수 있으므로 파일 소유권이 손실될 수 있습니다.

    3. 선택적으로 범위 크기를 설정합니다. 예를 들면 다음과 같습니다.

      idmap config * : rangesize = 200000

      Samba는 idmap 구성 * : range 매개변수에 설정된 범위의 모든 ID를 가져올 때까지 각 도메인의 개체에 대해 이 개수의 연속 ID를 할당합니다.

      참고

      범위 크기를 설정하는 경우 그에 따라 범위를 조정해야 합니다. 범위는 rangesize의 여러 개여야 합니다.

    4. 매핑된 모든 사용자에게 할당될 쉘 및 홈 디렉터리 경로를 설정합니다. 예를 들면 다음과 같습니다.

      template shell = /bin/bash
      template homedir = /home/%U
    5. 필요한 경우 도메인에 대한 ID 매핑 구성을 추가합니다. 개별 도메인에 대한 구성이 없는 경우 Samba는 이전에 구성된 * 기본 도메인에서 자동 만료 백엔드 설정을 사용하여 ID를 계산합니다.

      중요

      범위는 이 서버의 다른 도메인 구성과 겹치지 않아야 합니다. 또한 범위는 나중에 할당되는 모든 ID를 포함할 만큼 충분히 커야 합니다. 자세한 내용은 Planning Samba ID 범위를 참조하십시오.

  2. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  3. Samba 구성을 다시 로드합니다.

    # smbcontrol all reload-config

추가 리소스

  • idmap_autorid(8) 도움말 페이지의 MAPPING FORMULAS 섹션
  • idmap_autorid(8) 도움말 페이지의 rangesize 매개 변수 설명
  • smb.conf(5) 도움말 페이지의 VARIABLE SUBSTITUTIONS 섹션

3.5. AD 도메인 멤버 서버로 Samba 설정

AD 또는 NT4 도메인을 실행하는 경우 Samba를 사용하여 Red Hat Enterprise Linux 서버를 도메인에 멤버로 추가하여 다음을 얻습니다.

  • 다른 도메인 구성원의 도메인 리소스에 액세스
  • sshd와 같은 로컬 서비스에 도메인 사용자를 인증합니다
  • 서버에서 파일 및 인쇄 서버 역할을 할 디렉터리와 프린터 공유

3.5.1. AD 도메인에 RHEL 시스템 연결

Samba Winbind는 RHEL(Red Hat Enterprise Linux) 시스템을 AD(Active Directory)와 연결하기 위한 SSSD(System Security Services Daemon)의 대안입니다. 이 섹션에서는 realmd 를 사용하여 Samba Winbind를 구성하여 RHEL 시스템을 AD 도메인에 추가하는 방법을 설명합니다.

절차

  1. AD에 Kerberos 인증을 위한 더 이상 사용되지 않는 RC4 암호화 유형이 필요한 경우 RHEL에서 이러한 암호에 대한 지원을 활성화합니다.

    # update-crypto-policies --set DEFAULT:AD-SUPPORT
  2. 다음 패키지를 설치합니다.

    # yum install realmd oddjob-mkhomedir oddjob samba-winbind-clients \
           samba-winbind samba-common-tools samba-winbind-krb5-locator
  3. 도메인 구성원에서 디렉터리 또는 프린터를 공유하려면 samba 패키지를 설치합니다.

    # yum install samba
  4. 기존 /etc/samba/smb.conf Samba 구성 파일을 백업합니다.

    # mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
  5. 도메인에 가입합니다. 예를 들어 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 서비스를 시작하고 시스템이 부팅될 때 서비스가 시작됩니다.
  6. 선택적으로 /etc/samba/smb.conf 파일에서 대체 ID 매핑 백엔드 또는 사용자 지정된 ID 매핑 설정을 설정합니다. 자세한 내용은 Samba ID 매핑 이해 및 구성을 참조하십시오.
  7. winbind 서비스가 실행 중인지 확인합니다.

    # systemctl status winbind
    ...
       Active: active (running) since Tue 2018-11-06 19:10:40 CET; 15s ago
    중요

    Samba를 활성화하여 도메인 사용자 및 그룹 정보를 쿼리하려면 smb 를 시작하기 전에 winbind 서비스를 실행해야 합니다.

  8. 디렉터리 및 프린터를 공유하는 samba 패키지를 설치한 경우 smb 서비스를 활성화하고 시작합니다.

    # systemctl enable --now smb
  9. 선택적으로 Active Directory에 로컬 로그인을 인증하는 경우 winbind_krb5_localauth 플러그인을 활성화합니다. MIT Kerberos용 로컬 인증 플러그인 사용을 참조하십시오.

검증 단계

  1. AD 도메인의 AD 관리자 계정과 같은 AD 사용자의 세부 정보를 표시합니다.

    # getent passwd "AD\administrator"
    AD\administrator:*:10000:10000::/home/administrator@AD:/bin/bash
  2. AD 도메인에서 도메인 사용자 그룹의 멤버를 쿼리합니다.

    # getent group "AD\Domain Users"
        AD\domain users:x:10000:user1,user2
  3. 선택적으로 파일 및 디렉터리에 대한 권한을 설정할 때 도메인 사용자와 그룹을 사용할 수 있는지 확인합니다. 예를 들어 /srv/samba/example.txt 파일의 소유자를 AD\administrator로 설정하고 그룹을 AD\Domain Users로 설정하려면 다음을 수행합니다.

    # chown "AD\administrator":"AD\Domain Users" /srv/samba/example.txt
  4. Kerberos 인증이 예상대로 작동하는지 확인합니다.

    1. AD 도메인 멤버에서 administrator@AD.EXAMPLE.COM 주체에 대한 티켓을 받습니다.

      # kinit administrator@AD.EXAMPLE.COM
    2. 캐시된 Kerberos 티켓을 표시합니다.

      # klist
      Ticket cache: KCM:0
      Default principal: administrator@AD.EXAMPLE.COM
      
      Valid starting       Expires              Service principal
      01.11.2018 10:00:00  01.11.2018 20:00:00  krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM
              renew until 08.11.2018 05:00:00
  5. 사용 가능한 도메인을 표시합니다.

    # wbinfo --all-domains
    BUILTIN
    SAMBA-SERVER
    AD

추가 리소스

3.5.2. MIT Kerberos용 로컬 인증 플러그인 사용

winbind 서비스는 Active Directory 사용자를 도메인 구성원에게 제공합니다. 관리자는 특정 상황에서 도메인 사용자가 도메인 구성원에서 실행 중인 SSH 서버와 같은 로컬 서비스에 인증할 수 있도록 설정하려고 합니다. Kerberos를 사용하여 도메인 사용자를 인증하는 경우 winbind_krb5_localauth 플러그인을 활성화하여 winbind 서비스를 통해 Kerberos 주체를 Active Directory 계정에 올바르게 매핑합니다.

예를 들어 Active Directory 사용자의 sAMAccountName 속성이 EXAMPLE로 설정되고 사용자가 사용자 이름을 소문자로 로그를 시도하는 경우 Kerberos는 대문자로 사용자 이름을 반환합니다. 결과적으로 항목이 일치하지 않고 인증이 실패합니다.

winbind_krb5_localauth 플러그인을 사용하면 계정 이름이 올바르게 매핑됩니다. 이는 GSSAPI 인증에만 적용되며 초기 티켓 부여 티켓(TGT)을 받는 데만 적용되지 않습니다.

사전 요구 사항

  • Samba는 Active Directory의 멤버로 구성되어 있습니다.
  • Red Hat Enterprise Linux는 Active Directory에 대한 로그인 시도를 인증합니다.
  • winbind 서비스가 실행 중입니다.

절차

/etc/krb5.conf 파일을 편집하고 다음 섹션을 추가합니다.

[plugins]
localauth = {
     module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so
     enable_only = winbind
}

추가 리소스

  • winbind_krb5_localauth(8) man page.

3.6. IdM 도메인 멤버에서 Samba 설정

이 섹션에서는 Red Hat IdM(Identity Management) 도메인에 연결된 호스트에서 Samba를 설정하는 방법을 설명합니다. 신뢰할 수 있는 Active Directory(AD) 도메인에서 IdM 및 또한 사용 가능한 경우 Samba에서 제공하는 공유 및 프린터 서비스에 액세스할 수 있습니다.

중요

IdM 도메인 멤버에서 Samba를 사용하는 것은 지원되지 않는 기술 프리뷰 기능이며 특정 제한 사항이 포함되어 있습니다. 예를 들어, IdM 신뢰 컨트롤러는 Active Directory 글로벌 카탈로그 서비스를 지원하지 않으며 DMCE/원격 프로시저 호출(DCE/RPC) 프로토콜을 사용하여 IdM 그룹 해결을 지원하지 않습니다. 결과적으로 AD 사용자는 다른 IdM 클라이언트에 로그인할 때 IdM 클라이언트에서 호스팅되는 Samba 공유 및 프린터에만 액세스할 수 있습니다. Windows 시스템에 로그인한 AD 사용자는 IdM 도메인 멤버에서 호스팅되는 Samba 공유에 액세스할 수 없습니다.

IdM 도메인 구성원에 Samba를 배포하는 고객은 Red Hat에 피드백을 제공하는 것이 좋습니다.

사전 요구 사항

  • 호스트는 IdM 도메인에 클라이언트로 결합됩니다.
  • IdM 서버와 클라이언트는 모두 RHEL 8.1 이상에서 실행해야 합니다.

3.6.1. 도메인 구성원에 Samba 설치를 위한 IdM 도메인 준비

IdM 클라이언트에 Samba를 설정하려면 IdM 서버에서 ipa-adtrust-install 유틸리티를 사용하여 IdM 도메인을 준비해야 합니다.

참고

ipa-adtrust-install 명령을 자동으로 실행하는 시스템은 AD 신뢰 컨트롤러가 됩니다. 그러나 IdM 서버에서 ipa-adtrust-install 을 한 번만 실행해야 합니다.

사전 요구 사항

  • IdM 서버가 설치되어 있어야 합니다.
  • 패키지를 설치하고 IdM 서비스를 다시 시작하려면 루트 권한이 필요합니다.

절차

  1. 필수 패키지를 설치합니다.

    [root@ipaserver ~]# yum install ipa-server-trust-ad samba-client
  2. IdM 관리자로 인증합니다.

    [root@ipaserver ~]# kinit admin
  3. ipa-adtrust-install 유틸리티를 실행합니다.

    [root@ipaserver ~]# ipa-adtrust-install

    IdM이 통합된 DNS 서버와 함께 설치된 경우 DNS 서비스 레코드가 자동으로 생성됩니다.

    통합된 DNS 서버 없이 IdM을 설치한 경우, ipa-adtrust-install 은 DNS에 수동으로 추가해야 하는 서비스 레코드 목록을 인쇄합니다.

  4. 스크립트에서 /etc/samba/smb.conf가 이미 존재하고 다시 작성됨을 묻는 메시지를 표시합니다.

    WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration.
    
    Do you wish to continue? [no]: yes
  5. 스크립트에서 이전 Linux 클라이언트가 신뢰할 수 있는 사용자로 작업할 수 있는 호환성 플러그인인 slapi-nis 플러그인을 구성하도록 프롬프트를 표시합니다.

    Do you want to enable support for trusted domains in Schema Compatibility plugin?
    This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users.
    
    Enable trusted domains support in slapi-nis? [no]: yes
  6. 메시지가 표시되면 IdM 도메인의 NetBIOS 이름을 입력하거나 Enter 를 눌러 제안된 이름을 수락합니다.

    Trust is configured but no NetBIOS domain name found, setting it now.
    Enter the NetBIOS name for the IPA domain.
    Only up to 15 uppercase ASCII letters, digits and dashes are allowed.
    Example: EXAMPLE.
    
    NetBIOS domain name [IDM]:
  7. SID 생성 작업을 실행하여 기존 사용자의 SID를 생성하라는 메시지가 표시됩니다.

    Do you want to run the ipa-sidgen task? [no]: yes

    이는 리소스 집약적인 작업이므로 사용자가 많은 경우 한 번에 이 작업을 실행할 수 있습니다.

  8. (선택 사항) 기본적으로 Dynamic RPC 포트 범위는 Windows Server 2008 이상에서는 49152-65535 로 정의됩니다. 환경에 대해 다른 Dynamic RPC 포트 범위를 정의해야 하는 경우 다른 포트를 사용하도록 Samba를 구성하고 방화벽 설정에서 해당 포트를 엽니다. 다음 예제에서는 포트 범위를 55000-65000으로 설정합니다.

    [root@ipaserver ~]# net conf setparm global 'rpc server dynamic port range' 55000-65000
    [root@ipaserver ~]# firewall-cmd --add-port=55000-65000/tcp
    [root@ipaserver ~]# firewall-cmd --runtime-to-permanent
  9. ipa 서비스를 다시 시작하십시오.

    [root@ipaserver ~]# ipactl restart
  10. smbclient 유틸리티를 사용하여 Samba가 IdM 측에서 Kerberos 인증에 응답하는지 확인합니다.

    [root@ipaserver ~]# smbclient -L server.idm.example.com -U user_name --use-kerberos=required
    lp_load_ex: changing to config backend registry
        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       IPC Service (Samba 4.15.2)
    ...

3.6.2. GPO를 사용하여 Active Directory의 AES 암호화 유형 활성화

이 섹션에서는 그룹 정책 개체(GPO)를 사용하여 AD(Active Directory)의 AES 암호화 유형을 활성화하는 방법을 설명합니다. IdM 클라이언트에서 Samba 서버를 실행하는 등의 RHEL의 특정 기능에는 이 암호화 유형이 필요합니다.

RHEL은 더 이상 약한 DES 및 RC4 암호화 유형을 지원하지 않습니다.

사전 요구 사항

  • 그룹 정책을 편집할 수 있는 사용자로 AD에 로그인되어 있습니다.
  • 그룹 정책 관리 콘솔이 컴퓨터에 설치되어 있습니다.

절차

  1. 그룹 정책 관리 콘솔을 엽니다.
  2. 기본 도메인 정책에서 마우스 오른쪽 버튼으로 클릭하여 편집을 선택합니다. 그룹 정책 관리 편집기가 열립니다.
  3. 컴퓨터 구성정책Windows 설정보안 설정로컬 정책보안 옵션으로 이동합니다.
  4. 네트워크 보안을 두 번 클릭합니다. Kerberos 정책에 허용된 암호화 유형을 구성합니다.
  5. AES256_HMAC_SHA1을 선택하고 선택적으로 Future 암호화 유형을 선택합니다.
  6. OK를 클릭합니다.
  7. 그룹 정책 관리 편집기 를 닫습니다.
  8. 기본 도메인 컨트롤러 정책에 대한 단계를 반복합니다.
  9. Windows 도메인 컨트롤러(DC)가 그룹 정책을 자동으로 적용할 때까지 기다립니다. 또는 DC에서 GPO를 수동으로 적용하려면 관리자 권한이 있는 계정을 사용하여 다음 명령을 입력합니다.

    C:\> gpupdate /force /target:computer

3.6.3. IdM 클라이언트에 Samba 서버 설치 및 구성

이 섹션에서는 IdM 도메인에 등록된 클라이언트에 Samba를 설치하고 구성하는 방법을 설명합니다.

사전 요구 사항

절차

  1. ipa-client-samba 패키지를 설치합니다.

    [root@idm_client]# yum install ipa-client-samba
  2. ipa-client-samba 유틸리티를 사용하여 클라이언트를 준비하고 초기 Samba 구성을 생성합니다.

    [root@idm_client]# ipa-client-samba
    Searching for IPA server...
    IPA server: DNS discovery
    Chosen IPA master: idm_server.idm.example.com
    SMB principal to be created: cifs/idm_client.idm.example.com@IDM.EXAMPLE.COM
    NetBIOS name to be used: IDM_CLIENT
    Discovered domains to use:
    
     Domain name: idm.example.com
    NetBIOS name: IDM
             SID: S-1-5-21-525930803-952335037-206501584
        ID range: 212000000 - 212199999
    
     Domain name: ad.example.com
    NetBIOS name: AD
             SID: None
        ID range: 1918400000 - 1918599999
    
    Continue to configure the system with these values? [no]: yes
    Samba domain member is configured. Please check configuration at /etc/samba/smb.conf and start smb and winbind services
  3. 기본적으로 ipa-client-samba는 사용자가 연결할 때 사용자의 홈 디렉토리를 동적으로 공유하는 /etc/samba/smb.conf 파일에 [homes] 섹션을 자동으로 추가합니다. 이 서버에 홈 디렉터리가 없거나 공유하려는 경우 /etc/samba/smb.conf에서 다음 행을 제거하십시오.

    [homes]
        read only = no
  4. 디렉토리와 프린터를 공유합니다. 자세한 내용은 다음을 참조하십시오.

  5. 로컬 방화벽에서 Samba 클라이언트에 필요한 포트를 엽니다.

    [root@idm_client]# firewall-cmd --permanent --add-service=samba-client
    [root@idm_client]# firewall-cmd --reload
  6. smbwinbind 서비스를 활성화하고 시작합니다.

    [root@idm_client]# systemctl enable --now smb winbind

검증 단계

samba-client 패키지가 설치된 다른 IdM 도메인 멤버에서 다음 확인 단계를 실행합니다.

  • Kerberos 인증을 사용하여 Samba 서버의 공유를 나열합니다.

    $ smbclient -L idm_client.idm.example.com -U user_name --use-kerberos=required
    lp_load_ex: changing to config backend registry
    
        Sharename       Type      Comment
        ---------       ----      -------
        example         Disk
        IPC$            IPC       IPC Service (Samba 4.15.2)
    ...

추가 리소스

  • ipa-client-ECDHE(1) 매뉴얼 페이지

3.6.4. IdM이 새 도메인을 신뢰하는 경우 ID 매핑 구성 수동 추가

Samba에는 사용자가 리소스에 액세스하는 각 도메인에 대한 ID 매핑 구성이 필요합니다. IdM 클라이언트에서 실행 중인 기존 Samba 서버에서 관리자가 Active Directory(AD) 도메인에 새 신뢰를 추가한 후 ID 매핑 구성을 수동으로 추가해야 합니다.

사전 요구 사항

  • IdM 클라이언트에 Samba가 구성되어 있습니다. 이후에 새로운 신뢰가 IdM에 추가되었습니다.
  • Kerberos에 대한 DES 및 RC4 암호화 유형은 신뢰할 수 있는 AD 도메인에서 비활성화해야 합니다. 보안상의 이유로 RHEL 8은 이러한 약한 암호화 유형을 지원하지 않습니다.

절차

  1. 호스트의 keytab을 사용하여 인증합니다.

    [root@idm_client]# kinit -k
  2. ipa idrange-find 명령을 사용하여 새 도메인의 기본 ID와 ID 범위 크기를 모두 표시합니다. 예를 들어 다음 명령은 ad.example.com 도메인의 값을 표시합니다.

    [root@idm_client]# ipa idrange-find --name="AD.EXAMPLE.COM_id_range" --raw
    ---------------
    1 range matched
    ---------------
      cn: AD.EXAMPLE.COM_id_range
      ipabaseid: 1918400000
      ipaidrangesize: 200000
      ipabaserid: 0
      ipanttrusteddomainsid: S-1-5-21-968346183-862388825-1738313271
      iparangetype: ipa-ad-trust
    ----------------------------
    Number of entries returned 1
    ----------------------------

    다음 단계에서 ipabaseidipaidrangesize 속성의 값이 필요합니다.

  3. 사용 가능한 가장 높은 ID를 계산하려면 다음 공식을 사용합니다.

    maximum_range = ipabaseid + ipaidrangesize - 1

    이전 단계의 값을 사용하여 ad.example.com 도메인에 사용 가능한 가장 높은 ID는 1918599999 (1918400000 + 200000 - 1)입니다.

  4. /etc/samba/smb.conf 파일을 편집하고 도메인의 ID 매핑 구성을 [global] 섹션에 추가합니다.

    idmap config AD : range = 1918400000 - 1918599999
    idmap config AD : backend = sss

    ipabaseid 특성의 값을 가장 낮은 값으로 지정하고 이전 단계의 계산된 값을 가장 높은 범위 값으로 지정합니다.

  5. smbwinbind 서비스를 다시 시작합니다.

    [root@idm_client]# systemctl restart smb winbind

검증 단계

  • Kerberos 인증을 사용하여 Samba 서버의 공유를 나열합니다.

    $ smbclient -L idm_client.idm.example.com -U user_name --use-kerberos=required
    lp_load_ex: changing to config backend registry
    
        Sharename       Type      Comment
        ---------       ----      -------
        example         Disk
        IPC$            IPC       IPC Service (Samba 4.15.2)
    ...

3.6.5. 추가 리소스

3.7. POSIX ACL을 사용하는 Samba 파일 공유 설정

Samba는 Linux 서비스로 POSIX ACL과의 공유를 지원합니다. chmod와 같은 유틸리티를 사용하여 Samba 서버에서 권한을 로컬로 관리할 수 있습니다. 공유가 확장된 속성을 지원하는 파일 시스템에 저장된 경우 여러 사용자 및 그룹으로 ACL을 정의할 수 있습니다.

참고

대신 미세한 Windows ACL을 사용해야 하는 경우 Windows ACL을 사용하는 공유 설정을 참조하십시오.

이 섹션의 일부는 Samba Wiki에 게시된 POSIX ACL을 사용하여 공유 설정 설명서에서 채택되었습니다. 라이센스: CC BY 4.0. 작성자 및 기여자: Wiki 페이지의 기록 탭을 참조하십시오.

3.7.1. POSIX ACL을 사용하는 공유 추가

이 섹션에서는 /srv/samba/example/ 디렉터리의 콘텐츠를 제공하고 POSIX ACL을 사용하는 example 이라는 공유를 생성하는 방법을 설명합니다.

사전 요구 사항

Samba는 다음 모드 중 하나로 설정되었습니다.

절차

  1. 폴더가 없는 경우 해당 폴더를 생성합니다. 예를 들면 다음과 같습니다.

    # mkdir -p /srv/samba/example/
  2. enforcing 모드에서 SELinux를 실행하는 경우 디렉터리에 samba_share_t 컨텍스트를 설정합니다.

    # semanage fcontext -a -t samba_share_t "/srv/samba/example(/.*)?"
    # restorecon -Rv /srv/samba/example/
  3. 디렉터리에 파일 시스템 ACL을 설정합니다. 자세한 내용은 다음을 참조하십시오.

  4. 예제 공유를 /etc/samba/smb.conf 파일에 추가합니다. 예를 들어, 쓰기 가능 공유를 추가하려면 다음을 수행합니다.

    [example]
    	path = /srv/samba/example/
    	read only = no
    참고

    파일 시스템 ACL에 관계없이 read only = no를 설정하지 않으면 Samba는 읽기 전용 모드로 디렉토리를 공유합니다.

  5. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  6. 필요한 포트를 열고 firewall-cmd 유틸리티를 사용하여 방화벽 구성을 다시 로드합니다.

    # firewall-cmd --permanent --add-service=samba
    # firewall-cmd --reload
  7. smb 서비스를 다시 시작하십시오.

    # systemctl restart smb

3.7.2. POSIX ACL을 사용하는 Samba 공유에 표준 Linux ACL 설정

Linux의 표준 ACL은 한 명의 소유자, 하나의 그룹 및 기타 모든 정의되지 않은 사용자에 대한 권한 설정을 지원합니다. chown,chgrpchmod 유틸리티를 사용하여 ACL을 업데이트할 수 있습니다. 정확한 제어가 필요한 경우 보다 복잡한 POSIX ACL을 사용하십시오.

POSIX ACL을 사용하는 Samba 공유에서 확장 ACL 설정.

다음 절차에서는 /srv/samba/example/ 디렉터리의 소유자를 root 사용자로 설정하고, Domain Users 그룹에 읽기 및 쓰기 권한을 부여하며, 다른 모든 사용자에 대한 액세스를 거부합니다.

사전 요구 사항

  • ACL을 설정하려는 Samba 공유가 있습니다.

절차

# chown root:"Domain Users" /srv/samba/example/
# chmod 2770 /srv/samba/example/

참고

디렉토리에서 set-group-ID(SGID) 비트를 활성화하면 새 디렉토리 항목을 생성한 사용자의 기본 그룹으로 설정하는 일반적인 동작이 아니라 모든 새 파일 및 하위 디렉터리의 기본 그룹을 디렉토리 그룹의 기본 그룹으로 자동으로 설정합니다.

추가 리소스

  • chown(1)chmod(1) 매뉴얼 페이지

3.7.3. POSIX ACL을 사용하는 Samba 공유에 확장 ACL 설정

공유 디렉터리가 확장 ACL을 지원하는 경우 파일 시스템을 사용하여 복잡한 권한을 설정할 수 있습니다. 확장 ACL에는 여러 사용자와 그룹에 대한 권한이 포함될 수 있습니다.

확장 POSIX ACL을 사용하면 여러 사용자 및 그룹으로 복잡한 ACL을 구성할 수 있습니다. 그러나 다음 권한만 설정할 수 있습니다.

  • 액세스 권한 없음
  • 읽기 액세스
  • 쓰기 액세스
  • 전체 제어

Create folder / append data와 같은 세분화된 Windows 권한이 필요한 경우 Windows ACL을 사용하도록 공유를 구성합니다. Windows ACL을 사용하는 공유 설정을 참조하십시오.

다음 절차는 공유에서 확장 ACL을 활성화하는 방법을 보여줍니다. 또한 확장 ACL 설정에 대한 예제도 포함되어 있습니다.

사전 요구 사항

  • ACL을 설정하려는 Samba 공유가 있습니다.

절차

  1. /etc/samba/smb.conf 파일의 공유 섹션에서 다음 매개 변수를 활성화하여 확장 ACL의 ACL 상속을 활성화합니다.

    inherit acls = yes

    자세한 내용은 smb.conf(5) 도움말 페이지의 매개 변수 설명을 참조하십시오.

  2. smb 서비스를 다시 시작하십시오.

    # systemctl restart smb
  3. 디렉터리에 ACL을 설정합니다. 예를 들면 다음과 같습니다.

    예 3.2. 확장 ACL 설정

    다음 절차에서는 Domain Admins 그룹에 대한 읽기, 쓰기, 실행 권한을 설정하고, Domain Users 그룹에 대한 읽기, 실행 권한을 설정하고, /srv/samba/example/ 디렉터리의 다른 모든 사용자에 대한 액세스를 거부합니다.

    1. 기본 사용자 계정 그룹에 자동 부여 권한을 비활성화합니다.

      # setfacl -m group::--- /srv/samba/example/
      # setfacl -m default:group::--- /srv/samba/example/

      디렉터리의 기본 그룹은 동적 CREATOR GROUP 주체에 추가로 매핑됩니다. Samba 공유에 확장 POSIX ACL을 사용하면 이 주체가 자동으로 추가되며 제거할 수 없습니다.

    2. 디렉터리에 대한 권한을 설정합니다.

      1. Domain Admins 그룹에 읽기, 쓰기 및 실행 권한을 부여합니다.

        # setfacl -m group:"DOMAIN\Domain Admins":rwx /srv/samba/example/
      2. Domain Users 그룹에 읽기 및 실행 권한을 부여합니다.

        # setfacl -m group:"DOMAIN\Domain Users":r-x /srv/samba/example/
      3. other ACL 항목과 일치하지 않는 사용자에 대한 액세스를 거부하도록 다른 ACL 항목에 대한 권한을 설정합니다.

        # setfacl -R -m other::--- /srv/samba/example/

      이러한 설정은 이 디렉터리에만 적용됩니다. Windows에서는 이러한 ACL이 This folder only에만 매핑됩니다.

    3. 이전 단계에서 설정한 권한을 이 디렉터리에 생성된 새 파일 시스템 개체에서 상속하려면 다음을 수행합니다.

      # setfacl -m default:group:"DOMAIN\Domain Admins":rwx /srv/samba/example/
      # setfacl -m default:group:"DOMAIN\Domain Users":r-x /srv/samba/example/
      # setfacl -m default:other::--- /srv/samba/example/

      이러한 설정에서 보안 주체의 이 폴더만 이 폴더, 하위 폴더 및 파일로 설정됩니다.

    Samba는 절차에 설정된 권한을 다음 Windows ACL에 매핑합니다.

    Principal액세스적용 대상

    도메인\Domain 관리자

    전체 제어

    이 폴더, 하위 폴더 및 파일

    도메인\Domain 사용자

    읽기 및 실행

    이 폴더, 하위 폴더 및 파일

    Everyone [a]

    없음

    이 폴더, 하위 폴더 및 파일

    소유자 (Unix 사용자\소유자) [b]

    전체 제어

    이 폴더만

    primary_group (Unix 사용자\primary_group) [c]

    없음

    이 폴더만

    CREATOR OWNER [d] [e]

    전체 제어

    하위 폴더 및 파일만

    CREATOR 그룹 [e] [f]

    없음

    하위 폴더 및 파일만

    [a] Samba는 이 주체에 대한 권한을 other ACL 항목에서 매핑합니다.
    [b] Samba는 디렉터리의 소유자를 이 항목에 매핑합니다.
    [c] Samba는 디렉터리의 기본 그룹을 이 항목에 매핑합니다.
    [d] 새 파일 시스템 개체에서 작성자는 이 주체의 권한을 자동으로 상속합니다.
    [e] POSIX ACL을 사용하는 공유에서 지원되지 않는 ACL에서 이러한 주체를 구성하거나 제거합니다.
    [f] 새 파일 시스템 개체에서 작성자의 기본 그룹은 이 주체의 권한을 자동으로 상속합니다.

3.8. POSIX ACL을 사용하는 공유에 대한 권한 설정

선택적으로 Samba 공유에 대한 액세스를 제한하거나 부여하려면 /etc/samba/smb.conf 파일의 공유 섹션에 특정 매개 변수를 설정할 수 있습니다.

참고

공유 기반 권한은 사용자, 그룹 또는 호스트가 공유에 액세스할 수 있는 경우 관리합니다. 이러한 설정은 파일 시스템 ACL에 영향을 미치지 않습니다.

공유 기반 설정을 사용하여 공유 액세스를 제한합니다(예: 특정 호스트의 액세스를 거부합니다.

사전 요구 사항

  • POSIX ACL과의 공유가 설정되었습니다.

3.8.1. 사용자 및 그룹 기반 공유 액세스 구성

사용자 및 그룹 기반 액세스 제어를 사용하면 특정 사용자 및 그룹의 공유에 대한 액세스 권한을 부여하거나 거부할 수 있습니다.

사전 요구 사항

  • 사용자 또는 그룹 기반 액세스를 설정하려는 Samba 공유가 있습니다.

절차

  1. 예를 들어, 사용자 계정에 대한 액세스가 거부되는 동안 Domain Users 그룹의 모든 구성원이 공유에 액세스할 수 있도록 하려면 공유의 구성에 다음 매개변수를 추가합니다.

    valid users = +DOMAIN\"Domain Users"
    invalid users = DOMAIN\user

    잘못된 users 매개변수는 유효한 users 매개변수보다 우선 순위가 높습니다. 예를 들어 사용자 계정이 Domain Users 그룹의 멤버인 경우 이전 예제를 사용할 때 이 계정에 대한 액세스가 거부됩니다.

  2. Samba 구성을 다시 로드합니다.

    # smbcontrol all reload-config

추가 리소스

  • smb.conf(5) man page

3.8.2. 호스트 기반 공유 액세스 구성

호스트 기반 액세스 제어를 사용하면 클라이언트의 호스트 이름, IP 주소 또는 IP 범위에 따라 공유에 대한 액세스 권한을 부여하거나 거부할 수 있습니다.

다음 절차에서는 127.0.0.1 IP 주소, 192.0.2.0/24 IP 범위 및 client1.example.com 호스트에서 공유에 액세스하는 방법을 활성화하고 client2.example.com 호스트에 대한 액세스를 추가적으로 거부하는 방법을 설명합니다.

사전 요구 사항

  • 호스트 기반 액세스를 설정하려는 Samba 공유가 있습니다.

절차

  1. /etc/samba/smb.conf 파일에 있는 공유 구성에 다음 매개변수를 추가합니다.

    hosts allow = 127.0.0.1 192.0.2.0/24 client1.example.com
    hosts deny = client2.example.com

    hosts deny 매개 변수는 호스트 허용 보다 우선 순위가 높습니다. 예를 들어 client1.example.comhosts allow 매개 변수에 나열된 IP 주소로 확인되면 이 호스트에 대한 액세스가 거부됩니다.

  2. Samba 구성을 다시 로드합니다.

    # smbcontrol all reload-config

추가 리소스

  • smb.conf(5) man page

3.9. Windows ACL을 사용하는 공유 설정

Samba는 공유 및 파일 시스템 개체에서 Windows ACL 설정을 지원합니다. 이를 통해 다음을 수행할 수 있습니다.

  • 세분화된 Windows ACL 사용
  • Windows를 사용하여 공유 권한 및 파일 시스템 ACL 관리

또는 POSIX ACL을 사용하도록 공유를 구성할 수 있습니다. 자세한 내용은 POSIX ACL을 사용하는 Samba 파일 공유 설정을 참조하십시오.

이 섹션의 일부는 Samba Wiki에 게시 된 Windows ACL을 사용하여 공유 설정 설명서에서 채택되었습니다. 라이센스: CC BY 4.0. 작성자 및 기여자: Wiki 페이지의 기록 탭을 참조하십시오.

3.9.1. SeDiskOperatorPrivilege 권한 부여

SeDiskOperatorPrivilege 권한이 부여된 사용자 및 그룹만 Windows ACL을 사용하는 공유에 대한 권한을 구성할 수 있습니다.

절차

  1. 예를 들어, DOMAIN\Domain Admins 그룹에 SeDiskOperatorPrivilege 권한을 부여하려면 다음을 수행합니다.

    # net rpc rights grant "DOMAIN\Domain Admins" SeDiskOperatorPrivilege -U "DOMAIN\administrator"
    Enter DOMAIN\administrator's password:
    Successfully granted rights.
    참고

    도메인 환경에서 도메인 그룹에 SeDiskOperatorPrivilege 을 부여합니다. 이를 통해 사용자의 그룹 멤버십을 업데이트하여 권한을 중앙에서 관리할 수 있습니다.

  2. SeDiskOperatorPrivilege 이 부여된 모든 사용자 및 그룹을 나열하려면 다음을 수행하십시오.

    # net rpc rights list privileges SeDiskOperatorPrivilege -U "DOMAIN\administrator"
    Enter administrator's password:
    SeDiskOperatorPrivilege:
      BUILTIN\Administrators
      DOMAIN\Domain Admins

3.9.2. Windows ACL 지원 활성화

Windows ACL을 지원하는 공유를 구성하려면 Samba에서 이 기능을 활성화해야 합니다.

사전 요구 사항

  • 사용자 공유는 Samba 서버에 구성됩니다.

절차

  1. 모든 공유에 대해 전역적으로 활성화하려면 /etc/samba/smb.conf 파일의 [global] 섹션에 다음 설정을 추가합니다.

    vfs objects = acl_xattr
    map acl inherit = yes
    store dos attributes = yes

    대신 공유의 섹션에 동일한 매개 변수를 추가하여 개별 공유에 대해 Windows ACL 지원을 활성화할 수 있습니다.

  2. smb 서비스를 다시 시작하십시오.

    # systemctl restart smb

3.9.3. Windows ACL을 사용하는 공유 추가

이 섹션에서는 /srv/samba/example/ 디렉터리의 콘텐츠를 공유하고 Windows ACL을 사용하는 example 이라는 공유를 생성하는 방법을 설명합니다.

절차

  1. 폴더가 없는 경우 해당 폴더를 생성합니다. 예를 들면 다음과 같습니다.

    # mkdir -p /srv/samba/example/
  2. enforcing 모드에서 SELinux를 실행하는 경우 디렉터리에 samba_share_t 컨텍스트를 설정합니다.

    # semanage fcontext -a -t samba_share_t "/srv/samba/example(/.*)?"
    # restorecon -Rv /srv/samba/example/
  3. 예제 공유를 /etc/samba/smb.conf 파일에 추가합니다. 예를 들어, 쓰기 가능 공유를 추가하려면 다음을 수행합니다.

    [example]
    	path = /srv/samba/example/
    	read only = no
    참고

    파일 시스템 ACL에 관계없이 read only = no를 설정하지 않으면 Samba는 읽기 전용 모드로 디렉토리를 공유합니다.

  4. [global] 섹션에서 모든 공유에 대해 Windows ACL 지원을 활성화하지 않은 경우 [example] 섹션에 다음 매개변수를 추가하여 이 공유에 대해 이 기능을 활성화합니다.

    vfs objects = acl_xattr
    map acl inherit = yes
    store dos attributes = yes
  5. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  6. 필요한 포트를 열고 firewall-cmd 유틸리티를 사용하여 방화벽 구성을 다시 로드합니다.

    # firewall-cmd --permanent --add-service=samba
    # firewall-cmd --reload
  7. smb 서비스를 다시 시작하십시오.

    # systemctl restart smb

3.9.4. Windows ACL을 사용하는 공유 권한 및 파일 시스템 ACL 관리

Windows ACL을 사용하는 Samba 공유에서 공유 권한 및 파일 시스템 ACL을 관리하려면 컴퓨터 관리와 같은 Windows 애플리케이션을 사용합니다. 자세한 내용은 Windows 설명서를 참조하십시오. 또는 smbcacls 유틸리티를 사용하여 ACL을 관리합니다.

참고

Windows에서 파일 시스템 권한을 수정하려면 SeDiskOperatorPrivilege 권한이 부여된 계정을 사용해야 합니다.

3.10. smbcacls를 사용하여 SMB 공유에서 ACL 관리

smbcacls 유틸리티는 SMB 공유에 저장된 파일 및 디렉터리의 ACL을 나열, 설정 및 삭제할 수 있습니다. smbcacls를 사용하여 파일 시스템 ACL을 관리할 수 있습니다.

  • 고급 Windows ACL 또는 POSIX ACL을 사용하는 로컬 또는 원격 Samba 서버에서
  • Red Hat Enterprise Linux에서 Windows에서 호스팅되는 공유 영역에서 ACL을 원격으로 관리합니다.

3.10.1. 액세스 제어 항목

파일 시스템 오브젝트의 각 ACL 항목에는 다음 형식의 ACE(액세스 제어 항목)가 포함되어 있습니다.

security_principal:access_right/inheritance_information/permissions

예 3.3. 액세스 제어 항목

AD\Domain Users 그룹에 이 폴더, 하위 폴더 및 Windows의 파일에 적용되는 수정 권한이 있는 경우 ACL에 다음 ACE가 포함됩니다.

AD\Domain Users:ALLOWED/OI|CI/CHANGE

ACE에는 다음 부분이 포함됩니다.

보안 주체
보안 주체는 ACL의 권한이 적용되는 사용자, 그룹 또는 SID입니다.
액세스 권한
개체에 대한 액세스 권한이 부여되거나 거부되었는지 여부를 정의합니다. 값은 ALLOWED 또는 DENIED 일 수 있습니다.
상속 정보

다음 값이 있습니다.

표 3.1. 상속 설정

현재의설명매핑 대상

OI

오브젝트 Inherit

이 폴더 및 파일

CI

컨테이너 Inherit

이 폴더 및 하위 폴더

IO

상속 만

ACE가 현재 파일이나 디렉토리에는 적용되지 않습니다.

ID

상속됨

ACE는 상위 디렉터리에서 상속되었습니다.

또한 값은 다음과 같이 결합할 수 있습니다.

표 3.2. 상속 설정 조합

값 조합Windows Applies에 매핑되어 설정

OI|CI

이 폴더, 하위 폴더 및 파일

OI|CI|IO

하위 폴더 및 파일만

CI|IO

하위 폴더만

OI|IO

파일만

권한

이 값은 하나 이상의 Windows 권한 또는 smbcacls 별칭을 나타내는 16진수 값일 수 있습니다.

  • 하나 이상의 Windows 권한을 나타내는 16진수 값입니다.

    다음 표에는 고급 Windows 권한 및 해당 값이 16진수 형식으로 표시됩니다.

    표 3.3. Windows 권한 및 16진수 형식의 해당 smbcacls 값

    Windows 권한16진수 값

    전체 제어

    0x001F01FF

    폴더를 트래버스/실행 파일

    0x00100020

    디렉토리 표시 / 데이터 읽기

    0x00100001

    속성 읽기

    0x00100080

    확장 속성 읽기

    0x00100008

    파일 만들기 / 데이터 쓰기

    0x00100002

    폴더 생성 / 데이터 추가

    0x00100004

    쓰기 속성

    0x00100100

    확장 속성 쓰기

    0x00100010

    하위 폴더 및 파일 삭제

    0x00100040

    delete

    0x00110000

    읽기 권한

    0x00120000

    권한 변경

    0x00140000

    소유권 얻기

    0x00180000

    여러 권한을 비트 단위로 OR 작업을 사용하여 단일 16진수 값으로 결합할 수 있습니다. 자세한 내용은 ACE 마스크 계산을 참조하십시오.

  • smbcacls 별칭. 다음 테이블에는 사용 가능한 별칭이 표시됩니다.

    표 3.4. 기존 smbcacls 별칭 및 해당 Windows 권한

    smbcacls 별칭Windows 권한에 매핑

    R

    읽기

    READ

    읽기 및 실행

    W

    특수:

    • 파일 만들기 / 데이터 쓰기
    • 폴더 생성 / 데이터 추가
    • 쓰기 속성
    • 확장 속성 쓰기
    • 읽기 권한

    D

    delete

    P

    권한 변경

    O

    소유권 얻기

    X

    트래버스/실행

    변경

    수정

    FULL

    전체 제어

    참고

    권한을 설정할 때 단일 문자 별칭을 결합할 수 있습니다. 예를 들어 RD 를 설정하여 Windows 권한 Read and Delete 를 적용할 수 있습니다. 그러나 여러 개의 비 단일 문자 별칭을 결합하거나 별칭과 16진수 값을 결합할 수 없습니다.

3.10.2. smbcacls를 사용하여 ACL 표시

SMB 공유에 ACL을 표시하려면 smbcacls 유틸리티를 사용합니다. 작업 매개 변수(예: --add ) 없이 smbcacls 를 실행하면 유틸리티에 파일 시스템 오브젝트의 ACL이 표시됩니다.

절차

예를 들어----- server/example 공유의 루트 디렉토리의 ACL을 나열하려면 다음을 수행합니다.

# smbcacls //server/example / -U "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
REVISION:1
CONTROL:SR|PD|DI|DP
OWNER:AD\Administrators
GROUP:AD\Domain Users
ACL:AD\Administrator:ALLOWED/OI|CI/FULL
ACL:AD\Domain Users:ALLOWED/OI|CI/CHANGE
ACL:AD\Domain Guests:ALLOWED/OI|CI/0x00100021

명령의 출력이 표시됩니다.

  • REVISION: 보안 설명자의 내부 Windows NT ACL 개정
  • CONTROL: 보안 설명자 제어
  • OWNER: 보안 설명자 소유자의 이름 또는 SID
  • GROUP: 보안 설명자 그룹의 이름 또는 SID
  • ACL 항목. 자세한 내용은 액세스 제어 항목을 참조하십시오.

3.10.3. ACE 마스크 계산

대부분의 경우 ACE를 추가하거나 업데이트할 때 ExistingScopecacls 별칭 및 해당 Windows 권한 에 나열된 smbcacls 별칭을 사용합니다.

그러나 Windows 권한에 나열된 고급 Windows 권한 및 hex 형식으로 해당 smbcacls 값을 설정하려면 비트 단위 OR 작업을 사용하여 올바른 값을 계산해야 합니다. 다음 쉘 명령을 사용하여 값을 계산할 수 있습니다.

# echo $(printf '0x%X' $(( hex_value_1 | hex_value_2 | ... )))

예 3.4. ACE 마스크 계산

다음 권한을 설정하려고 합니다.

  • 폴더 통과/실행 파일(0x00100020)
  • 폴더 표시 / 읽기 데이터 (0x00100001)
  • 읽기 속성 (0x00100080)

이전 권한의 16진수 값을 계산하려면 다음을 입력합니다.

# echo $(printf '0x%X' $(( 0x00100020 | 0x00100001 | 0x00100080 )))
0x1000A1

ACE를 설정하거나 업데이트할 때 반환된 값을 사용합니다.

3.10.4. smbcacls를 사용하여 ACL 추가, 업데이트 및 제거

smbcacls 유틸리티에 전달하는 매개변수에 따라 파일 또는 디렉터리에서 ACL을 추가, 업데이트 및 제거할 수 있습니다.

ACL 추가

이 폴더, 하위 폴더 및 파일에 대한 CHANGE 권한을 부여하는 0.0.0.0/0 서버 /example 공유의 루트에 ACL을 추가하려면 AD\Domain Users 그룹에 다음을 수행합니다.

# smbcacls //server/example / -U "DOMAIN\administrator --add ACL:"AD\Domain Users":ALLOWED/OI|CI/CHANGE
ACL 업데이트

ACL 업데이트는 새 ACL을 추가하는 것과 유사합니다. 기존 보안 주체와 함께 --modify 매개 변수를 사용하여 ACL을 재정의하여 ACL을 업데이트합니다. smbcacls 가 ACL 목록에서 보안 주체를 찾는 경우 유틸리티는 권한을 업데이트합니다. 그렇지 않으면 명령이 오류와 함께 실패합니다.

ACL for SID principal_name not found

예를 들어 AD\Domain Users 그룹의 권한을 업데이트하고 이 폴더, 하위 폴더 및 파일의 READ 로 설정하려면 다음을 수행합니다.

# smbcacls //server/example / -U "DOMAIN\administrator --modify ACL:"AD\Domain Users":ALLOWED/OI|CI/READ
ACL 삭제

ACL을 삭제하려면 정확한 ACL을 사용하는 --delete 매개 변수를 smbcacls 유틸리티에 전달합니다. 예를 들면 다음과 같습니다.

# smbcacls //server/example / -U "DOMAIN\administrator --delete ACL:"AD\Domain Users":ALLOWED/OI|CI/READ

3.11. 사용자가 Samba 서버에서 디렉토리를 공유 가능

Samba 서버에서는 사용자가 루트 권한 없이 디렉터리를 공유할 수 있도록 구성할 수 있습니다.

3.11.1. 사용자 공유 기능 활성화

사용자가 디렉토리를 공유할 수 있으려면 관리자가 Samba에서 사용자 공유를 활성화해야 합니다.

예를 들어 로컬 example 그룹의 멤버만 활성화하여 사용자 공유를 생성하려면 다음을 수행합니다.

절차

  1. 로컬 example 그룹이 없는 경우 해당 그룹을 생성합니다.

    # groupadd example
  2. Samba에서 사용자 공유 정의를 저장하고 권한을 올바르게 설정하도록 디렉터리를 준비합니다. 예를 들면 다음과 같습니다.

    1. 디렉터리를 만듭니다.

      # mkdir -p /var/lib/samba/usershares/
    2. example 그룹에 대한 쓰기 권한을 설정합니다.

      # chgrp example /var/lib/samba/usershares/
      # chmod 1770 /var/lib/samba/usershares/
    3. 사용자가 이 디렉터리의 다른 사용자가 저장한 파일의 이름을 변경하거나 삭제하지 않도록 Sticky bit를 설정합니다.
  3. /etc/samba/smb.conf 파일을 편집하고 [global] 섹션에 다음을 추가합니다.

    1. 사용자 공유 정의를 저장하도록 구성한 디렉터리의 경로를 설정합니다. 예를 들면 다음과 같습니다.

      usershare path = /var/lib/samba/usershares/
    2. 이 서버에서 Samba를 만들 수 있는 사용자 공유 수를 설정합니다. 예를 들면 다음과 같습니다.

      usershare max shares = 100

      usershare max shares 매개변수에 기본값 0을 사용하는 경우 사용자 공유가 비활성화됩니다.

    3. 선택적으로 절대 디렉토리 경로 목록을 설정합니다. 예를 들어 Samba가 /data 및 / srv 디렉토리의 하위 디렉터리만 공유할 수 있도록 허용하려면 다음을 설정합니다.

      usershare prefix allow list = /data /srv

    설정할 수 있는 추가 사용자 공유 관련 매개변수 목록은 smb.conf(5) 도움말 페이지의 USERSHARES 섹션을 참조하십시오.

  4. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  5. Samba 구성을 다시 로드합니다.

    # smbcontrol all reload-config

    이제 사용자가 사용자 공유를 생성할 수 있습니다.

3.11.2. 사용자 공유 추가

Samba에서 사용자 공유 기능을 활성화한 후 사용자는 net usershare add 명령을 실행하여 root 권한 없이 Samba 서버의 디렉토리를 공유할 수 있습니다.

net usershare add 명령의 개요:

net usershare add share_name path [[ comment ] | [ ACLs ]] [ guest_ok=y|n ]

중요

사용자 공유를 생성할 때 ACL을 설정하는 경우 ACL보다 먼저 주석 매개변수를 지정해야 합니다. 빈 주석을 설정하려면 큰따옴표로 빈 문자열을 사용합니다.

관리자가 /etc/samba/smb.conf 파일의 [global] 섹션에서 관리자 집합 usershare에서 guest = yes를 허용하는 경우 사용자는 사용자 공유에서만 게스트 액세스를 활성화할 수 있습니다.

예 3.5. 사용자 공유 추가

사용자가 Samba 서버에서 /srv/samba/ 디렉터리를 공유하려고 합니다. 공유 이름은 example 이고, 주석을 설정하지 않으며, 게스트 사용자가 액세스할 수 있어야 합니다. 또한 공유 권한은 AD\Domain Users 그룹에 대한 전체 액세스 권한과 기타 사용자의 읽기 권한으로 설정해야 합니다. 이 공유를 추가하려면 사용자로 실행합니다.

$ net usershare add example /srv/samba/ "" "AD\Domain Users":F,Everyone:R guest_ok=yes

3.11.3. 사용자 공유의 설정 업데이트

사용자 공유의 설정을 업데이트하려면 net usershare add 명령을 동일한 공유 이름 및 새 설정으로 사용하여 공유를 재정의합니다. 사용자 공유 추가를 참조하십시오.

3.11.4. 기존 사용자 공유에 대한 정보 표시

사용자는 Samba 서버에 net usershare info 명령을 입력하여 사용자 공유 및 해당 설정을 표시할 수 있습니다.

사전 요구 사항

  • 사용자 공유는 Samba 서버에 구성됩니다.

절차

  1. 사용자가 만든 모든 사용자 공유를 표시하려면 다음을 수행하십시오.

    $ net usershare info -l
    [share_1]
    path=/srv/samba/
    comment=
    usershare_acl=Everyone:R,host_name\user:F,
    guest_ok=y
    ...

    명령을 실행하는 사용자가 생성한 공유만 나열하려면 -l 매개 변수를 생략합니다.

  2. 특정 공유에 대한 정보만 표시하려면 공유 이름 또는 와일드카드를 명령에 전달합니다. 예를 들어 share_ 로 시작하는 공유의 정보를 표시하려면 다음을 수행합니다.

    $ net usershare info -l share_* 

3.11.5. 사용자 공유 나열

Samba 서버에서의 설정 없이 사용 가능한 사용자 공유만 나열하려면 net usershare list 명령을 사용합니다.

사전 요구 사항

  • 사용자 공유는 Samba 서버에 구성됩니다.

절차

  1. 사용자가 생성한 공유를 나열하려면 다음을 수행합니다.

    $ net usershare list -l
    share_1
    share_2
    ...

    명령을 실행하는 사용자가 생성한 공유만 나열하려면 -l 매개 변수를 생략합니다.

  2. 특정 공유만 나열하려면 공유 이름 또는 와일드카드를 명령에 전달합니다. 예를 들어, share_ 로 시작하는 이름의 공유만 나열하려면 다음을 실행합니다.

    $ net usershare list -l share_* 

3.11.6. 사용자 공유 삭제

사용자 공유를 삭제하려면 net usershare delete 명령을 공유를 만든 사용자 또는 root 사용자로 사용합니다.

사전 요구 사항

  • 사용자 공유는 Samba 서버에 구성됩니다.

절차

$ net usershare delete share_name

3.12. 인증 없이 액세스를 허용하도록 공유 구성

특정 상황에서는 사용자가 인증 없이 연결할 수 있는 디렉터리를 공유하려고 합니다. 이를 구성하려면 공유에서 게스트 액세스를 활성화합니다.

주의

인증이 필요하지 않은 공유는 보안 위험이 될 수 있습니다.

3.12.1. 공유에 대한 게스트 액세스 활성화

공유에서 게스트 액세스가 활성화된 경우 Samba는 게스트 연결을 guest account 매개변수에 설정된 운영 체제 계정에 매핑합니다. 게스트 사용자는 다음 조건 중 하나 이상이 충족되면 이 공유에 있는 파일에 액세스할 수 있습니다.

  • 계정은 파일 시스템 ACL에 나열됩니다.
  • 다른 사용자의 POSIX 권한에서 허용

예 3.6. 게스트 공유 권한

게스트 계정을 nobody (기본값)에 매핑하도록 Samba를 구성한 경우 다음 예의 ACL을 사용합니다.

  • 게스트 사용자가 file1.txt를 읽을 수 있도록 허용
  • 게스트 사용자가 file2.txt를 읽고 수정할 수 있도록 허용
  • 게스트 사용자가 file3.txt를 읽거나 수정하지 못하게 합니다.
-rw-r--r--. 1 root       root      1024 1. Sep 10:00 file1.txt
-rw-r-----. 1 nobody     root      1024 1. Sep 10:00 file2.txt
-rw-r-----. 1 root       root      1024 1. Sep 10:00 file3.txt

절차

  1. /etc/samba/smb.conf 파일을 편집합니다.

    1. 이 서버에서 설정한 첫 번째 게스트 공유인 경우:

      1. [global] 섹션에서 guest = Bad User에 map을 설정합니다.

        [global]
                ...
                map to guest = Bad User

        이 설정에서 Samba는 사용자 이름이 존재하지 않는 한 잘못된 암호를 사용하는 로그인 시도를 거부합니다. 지정된 사용자 이름이 없고 공유에서 게스트 액세스가 활성화된 경우 Samba는 연결을 게스트 로그인으로 처리합니다.

      2. 기본적으로 Samba는 게스트 계정을 Red Hat Enterprise Linux의 nobody 계정에 매핑합니다. 또는 다른 계정을 설정할 수 있습니다. 예를 들면 다음과 같습니다.

        [global]
                ...
                guest account = user_name

        이 매개 변수에 설정된 계정은 Samba 서버에 로컬로 존재해야 합니다. 보안상의 이유로 유효한 쉘이 할당되지 않은 계정을 사용하는 것이 좋습니다.

    2. 게스트 ok = yes 설정을 [example] 공유 섹션에 추가합니다.

      [example]
              ...
              guest ok = yes
  2. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  3. Samba 구성을 다시 로드합니다.

    # smbcontrol all reload-config

3.13. macOS 클라이언트에 대해 Samba 구성

가상 파일 시스템(VFS) Samba 모듈은 Apple 서버 메시지 블록(SMB) 클라이언트와의 향상된 호환성을 제공합니다.

3.13.1. macOS 클라이언트에 파일 공유를 제공하기 위한 Samba 구성 최적화

이 섹션에서는 macOS 클라이언트에 대해 Samba 파일 공유를 최적화하기 위해 서버에서 호스팅되는 모든 Samba 공유에 대해 반복 모듈을 구성하는 방법에 대해 설명합니다.

참고

Red Hat은 전역에 있는 모듈을 활성화 할 것을 권장합니다. macOS를 사용하는 클라이언트는 클라이언트가 서버에 대한 첫 번째 연결을 설정할 때 서버 서버 메시지 블록 버전 2(APL) 프로토콜 확장을 협상합니다. 클라이언트가 AAPL 확장을 활성화하지 않고 공유에 먼저 연결하면 클라이언트는 서버의 공유에 확장을 사용하지 않습니다.

사전 요구 사항

  • Samba는 파일 서버로 구성됩니다.

절차

  1. /etc/samba/smb.conf 파일을 편집하고 [global] 섹션에서 advertise streams_xattr VFS 모듈을 활성화합니다.

    vfs objects = fruit streams_xattr
    중요

    streams_xattr활성화하기 전에 coding 모듈을 활성화해야 합니다. popular 모듈은 대체 데이터 스트림(ADS)을 사용합니다. 이러한 이유로 streams_xattr 모듈도 활성화해야 합니다.

  2. 선택적으로 공유에서 macOS Time Machine 지원을 제공하려면 /etc/samba/smb.conf 파일의 공유 구성에 다음 설정을 추가합니다.

    fruit:time machine = yes
  3. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  4. Samba 구성을 다시 로드합니다.

    # smbcontrol all reload-config

추가 리소스

3.14. smbclient 유틸리티를 사용하여 SMB 공유에 액세스

smbclient 유틸리티를 사용하면 명령줄 FTP 클라이언트와 마찬가지로 SMB 서버의 파일 공유에 액세스할 수 있습니다. 예를 들어 이를 사용하여 공유에 파일을 업로드하고 다운로드할 수 있습니다.

사전 요구 사항

  • samba-client 패키지가 설치되어 있습니다.

3.14.1. smbclient 대화형 모드 작동 방식

예를 들어 DOMAIN\user 계정을 사용하여 서버에서 호스팅되는 예제 공유로 인증하려면 다음을 수행합니다.

# smbclient -U "DOMAIN\user" //server/example
Enter domain\user's password:
Try "help" to get a list of possible commands.
smb: \>

smbclient 가 공유에 성공적으로 연결되면 유틸리티는 대화형 모드로 전환되고 다음 프롬프트가 표시됩니다.

smb: \>

대화형 쉘에서 사용 가능한 모든 명령을 표시하려면 다음을 입력합니다.

smb: \> help

특정 명령에 대한 도움말을 표시하려면 다음을 입력합니다.

smb: \> help command_name

추가 리소스

  • sambaclient(1) 도움말 페이지

3.14.2. 대화형 모드에서 smbclient 사용

smbclient-c 매개 변수 없이 사용하는 경우 유틸리티는 대화형 모드로 들어갑니다. 다음 절차에서는 SMB 공유에 연결하고 하위 디렉터리에서 파일을 다운로드하는 방법을 보여줍니다.

절차

  1. 공유에 연결합니다.

    # smbclient -U "DOMAIN\user_name" //server_name/share_name
  2. /example/ 디렉터리로 변경합니다.

    smb: \> d /example/
  3. 디렉터리에 파일을 나열합니다.

    smb: \example\> ls
      .                    D         0  Thu Nov 1 10:00:00 2018
      ..                   D         0  Thu Nov 1 10:00:00 2018
      example.txt          N   1048576  Thu Nov 1 10:00:00 2018
    
             9950208 blocks of size 1024. 8247144 blocks available
  4. 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)
  5. 공유에서 연결을 끊습니다.

    smb: \example\> exit

3.14.3. 스크립팅 모드에서 smbclient 사용

c 매개 변수를 smbclient 에 전달하는 경우 원격 SMB 공유에서 명령을 자동으로 실행할 수 있습니다. 이를 통해 스크립트에서 smbclient를 사용할 수 있습니다.

다음 절차에서는 SMB 공유에 연결하고 하위 디렉터리에서 파일을 다운로드하는 방법을 보여줍니다.

절차

  • 다음 명령을 사용하여 공유에 연결하고 예제 디렉터리로 변경하고 example .txt 파일을 다운로드합니다.
# smbclient -U DOMAIN\user_name //server_name/share_name -c "cd /example/ ; get example.txt ; exit"

3.15. Samba를 인쇄 서버로 설정

Samba를 출력 서버로 설정하면 네트워크의 클라이언트가 Samba를 사용하여 출력할 수 있습니다. 또한 Windows 클라이언트가 구성된 경우 Samba 서버에서 드라이버를 다운로드할 수 있습니다.

이 섹션의 일부는 Samba Wiki에 게시된 인쇄 서버 설명서로 Samba 설정에서 채택되었습니다. 라이센스: CC BY 4.0. 작성자 및 기여자: Wiki 페이지의 기록 탭을 참조하십시오.

사전 요구 사항

Samba는 다음 모드 중 하나로 설정되었습니다.

3.15.1. Samba에서 인쇄 서버 지원 활성화

기본적으로 인쇄 서버 지원은 Samba에서 활성화되어 있지 않습니다. Samba를 인쇄 서버로 사용하려면 그에 따라 Samba를 구성해야 합니다.

참고

출력 작업 및 프린터 작업에는 원격 프로시저 호출(RPC)이 필요합니다. 기본적으로 Samba는 RPC를 관리하기 위해 필요에 따라 rpcd_spool s 서비스를 시작합니다. 첫 번째 RPC 호출 중 또는 CUPS에서 프린터 목록을 업데이트할 때 Samba는 CUPS에서 프린터 정보를 검색합니다. 이 경우 프린터당 약 1초가 걸릴 수 있습니다. 따라서 50개 이상의 프린터가 있는 경우 rpcd_spools 설정을 조정하십시오.

사전 요구 사항

  • 프린터는 CUPS 서버에서 구성됩니다.

    CUPS에서 프린터를 구성하는 방법에 대한 자세한 내용은 인쇄 서버의 CUPS 웹 콘솔(https://printserver:631/help)에 제공된 설명서를 참조하십시오.

절차

  1. /etc/samba/smb.conf 파일을 편집합니다.

    1. [ECDHEs] 섹션을 추가하여 Samba에서 출력 백엔드를 활성화합니다.

      [printers]
              comment = All Printers
              path = /var/tmp/
              printable = yes
              create mask = 0600
      중요

      [printers] 공유 이름은 하드 코딩되며 변경할 수 없습니다.

    2. CUPS 서버가 다른 호스트 또는 포트에서 실행되는 경우 [ECDHEs] 섹션에서 설정을 지정합니다.

      cups server = printserver.example.com:631
    3. 프린터가 많으면 CUPS에 연결된 프린터 수보다 유휴 초의 수를 더 높은 값으로 설정합니다. 예를 들어 프린터가 100개 있는 경우 [global] 섹션에 설정합니다.

      rpcd_spoolss:idle_seconds = 200

      이 설정이 환경에서 확장되지 않는 경우 [global] 섹션의 rpcd_spools 작업자 수도 늘립니다.

      rpcd_spoolss:num_workers = 10

      기본적으로 rpcd_spools는 5개의 작업자를 시작합니다.

  2. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  3. 필요한 포트를 열고 firewall-cmd 유틸리티를 사용하여 방화벽 구성을 다시 로드합니다.

    # firewall-cmd --permanent --add-service=samba
    # firewall-cmd --reload
  4. smb 서비스를 다시 시작하십시오.

    # systemctl restart smb

    서비스를 다시 시작한 후 Samba는 CUPS 백엔드에 구성된 모든 프린터를 자동으로 공유합니다. 특정 프린터만 수동으로 공유하려면 특정 프린터 수동 공유를 참조하십시오.

검증

  • 출력 작업을 제출합니다. 예를 들어pdf 파일을 인쇄하려면 다음을 입력합니다.

    # smbclient -Uuser //sambaserver.example.com/printer_name -c "print example.pdf"

3.15.2. 수동으로 특정 프린터 공유

Samba를 출력 서버로 구성한 경우 기본적으로 Samba는 CUPS 백엔드에 구성된 모든 프린터를 공유합니다. 다음 절차에서는 특정 프린터만 공유하는 방법을 설명합니다.

사전 요구 사항

  • Samba가 인쇄 서버로 설정됨

절차

  1. /etc/samba/smb.conf 파일을 편집합니다.

    1. [global] 섹션에서 설정을 설정하여 자동 프린터 공유를 비활성화합니다.

      load printers = no
    2. 공유할 각 프린터에 대해 섹션을 추가합니다. 예를 들어 Samba 에서 CUPS 백엔드의 example 라는 프린터를 Example- printer로 공유하려면 다음 섹션을 추가합니다.

      [Example-Printer]
              path = /var/tmp/
              printable = yes
              printer name = example

      각 프린터에 대해 개별 스풀 디렉토리가 필요하지 않습니다. [printers] 섹션에 설정한 것과 동일한 스풀 디렉토리를 프린터 매개변수에 설정할 수 있습니다.

  2. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  3. Samba 구성을 다시 로드합니다.

    # smbcontrol all reload-config

3.16. Samba 인쇄 서버에서 Windows 클라이언트에 대한 자동 프린터 드라이버 다운로드 설정

Windows 클라이언트용 Samba 출력 서버를 실행하는 경우 드라이버 및 사전 설정 프린터를 업로드할 수 있습니다. 사용자가 프린터에 연결하면 Windows가 자동으로 드라이버를 다운로드하여 클라이언트에 로컬로 설치합니다. 사용자는 설치에 대한 로컬 관리자 권한이 필요하지 않습니다. 또한 Windows는 트레이 수와 같이 사전 구성된 드라이버 설정을 적용합니다.

이 섹션의 일부는 Samba Wiki에 게시된 Windows 클라이언트용 자동 프린터 드라이버 다운로드 설정 설명서에서 채택되었습니다. 라이센스: CC BY 4.0. 작성자 및 기여자: Wiki 페이지의 기록 탭을 참조하십시오.

사전 요구 사항

  • Samba가 인쇄 서버로 설정됨

3.16.1. 프린터 드라이버에 대한 기본 정보

이 섹션에서는 프린터 드라이버에 대한 일반적인 정보를 제공합니다.

지원되는 드라이버 모델 버전

Samba는 Windows 2000 이상 및 Windows Server 2000 이상에서 지원되는 프린터 드라이버 모델 버전 3만 지원합니다. Samba는 Windows 8 및 Windows Server 2012에 도입된 드라이버 모델 버전 4를 지원하지 않습니다. 그러나 이러한 버전과 이후 버전의 Windows 버전도 버전 3 드라이버를 지원합니다.

패키지 인식 드라이버

Samba는 패키지 인식 드라이버를 지원하지 않습니다.

업로드할 프린터 드라이버 준비

드라이버를 Samba 인쇄 서버에 업로드하려면 다음을 수행하십시오.

  • 압축된 형식으로 제공되는 경우 드라이버의 압축을 풉니다.
  • 일부 드라이버에서는 Windows 호스트에서 로컬로 드라이버를 설치하는 설정 애플리케이션을 시작해야 합니다. 특정 상황에서 설치 프로그램은 설치를 실행하는 동안 개별 파일을 운영 체제의 임시 폴더로 추출합니다. 드라이버 파일을 업로드에 사용하려면 다음을 수행합니다.

    1. 설치 프로그램을 시작합니다.
    2. 임시 폴더에서 새 위치로 파일을 복사합니다.
    3. 설치를 취소합니다.

프린터 제조업체에 인쇄 서버 업로드를 지원하는 드라이버를 요청합니다.

클라이언트에 프린터를 위한 32비트 및 64비트 드라이버 제공

32비트 및 64비트 Windows 클라이언트 모두에 대해 프린터용 드라이버를 제공하려면 두 아키텍처에서 정확히 동일한 이름으로 드라이버를 업로드해야 합니다. 예를 들어 Example PostScript라는 32비트 드라이버와 Example PostScript (v1.0) 라는 64비트 드라이버를 업로드하는 경우 이름이 일치하지 않습니다. 따라서 프린터에 드라이버 중 하나만 할당할 수 있으며 두 아키텍처에서는 드라이버를 모두 사용할 수 없습니다.

3.16.2. 사용자가 드라이버를 업로드하고 사전 구성 가능

프린터 드라이버를 업로드하고 사전 구성할 수 있으려면 사용자 또는 그룹에 SeprintOperatorPrivilege 권한이 부여되어야 합니다. 사용자를 printadmin 그룹에 추가해야 합니다. Red Hat Enterprise Linux는 samba 패키지를 설치할 때 이 그룹을 자동으로 생성합니다. printadmin 그룹에는 1000 미만의 사용 가능한 가장 낮은 동적 시스템 GID가 할당됩니다.

절차

  1. 예를 들어, printadmin 그룹에 Se print OperatorPrivilege 권한을 부여하려면 다음을 수행합니다.

    # net rpc rights grant "printadmin" SePrintOperatorPrivilege -U "DOMAIN\administrator"
    Enter DOMAIN\administrator's password:
    Successfully granted rights.
    참고

    도메인 환경에서 도메인 그룹에 Se printOperatorPrivilege 을 부여합니다. 이를 통해 사용자의 그룹 멤버십을 업데이트하여 권한을 중앙에서 관리할 수 있습니다.

  2. SePrintOperatorPrivilege 이 부여된 모든 사용자 및 그룹을 나열하려면 다음을 수행하십시오.

    # net rpc rights list privileges SePrintOperatorPrivilege -U "DOMAIN\administrator"
    Enter administrator's password:
    SePrintOperatorPrivilege:
      BUILTIN\Administrators
      DOMAIN\printadmin

3.16.3. print$ 공유 설정

Windows 운영 체제는 인쇄 서버에서 print$ 공유에서 프린터 드라이버를 다운로드합니다. 이 공유 이름은 Windows에서 하드 코딩되며 변경할 수 없습니다.

다음 절차에서는 /var/lib/samba/drivers/ 디렉터리를 print$로 공유하고 로컬 print admin 그룹의 멤버가 프린터 드라이버를 업로드할 수 있도록 하는 방법을 설명합니다.

절차

  1. [print$] 섹션을 /etc/samba/smb.conf 파일에 추가합니다.

    [print$]
            path = /var/lib/samba/drivers/
            read only = no
            write list = @printadmin
            force group = @printadmin
            create mask = 0664
            directory mask = 2775

    다음 설정을 사용합니다.

    • printadmin 그룹의 구성원만 프린터 드라이버를 공유에 업로드할 수 있습니다.
    • 새로 생성된 파일과 디렉토리의 그룹이 printadmin으로 설정됩니다.
    • 새 파일의 권한은 664로 설정됩니다.
    • 새 디렉터리의 권한은 2775로 설정됩니다.
  2. 모든 프린터에 대해 64비트 드라이버만 업로드하려면 /etc/samba/smb.conf 파일의 [global] 섹션에 이 설정을 포함하십시오.

    spoolss: architecture = Windows x64

    이 설정이 없으면 Windows에는 최소 32비트 버전을 업로드한 드라이버만 표시됩니다.

  3. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  4. Samba 구성 다시 로드

    # smbcontrol all reload-config
  5. printadmin 그룹이 없는 경우 해당 그룹을 생성합니다.

    # groupadd printadmin
  6. printadmin 그룹에 Se print OperatorPrivilege 권한을 부여합니다.

    # net rpc rights grant "printadmin" SePrintOperatorPrivilege -U "DOMAIN\administrator"
    Enter DOMAIN\administrator's password:
    Successfully granted rights.
  7. enforcing 모드에서 SELinux를 실행하는 경우 디렉터리에 samba_share_t 컨텍스트를 설정합니다.

    # semanage fcontext -a -t samba_share_t "/var/lib/samba/drivers(/.)?" # *restorecon -Rv /var/lib/samba/drivers/
  8. /var/lib/samba/drivers/ 디렉터리에 대한 권한을 설정합니다.

    • POSIX ACL을 사용하는 경우 다음을 설정합니다.

      # chgrp -R "printadmin" /var/lib/samba/drivers/
      # chmod -R 2775 /var/lib/samba/drivers/
    • Windows ACL을 사용하는 경우 다음을 설정합니다.

      Principal액세스적용 대상

      CREATOR OWNER

      전체 제어

      하위 폴더 및 파일만

      Authenticated Users

      읽기 및 실행, 폴더 내용 나열, 읽기

      이 폴더, 하위 폴더 및 파일

      printadmin

      전체 제어

      이 폴더, 하위 폴더 및 파일

      Windows에서 ACL 설정에 대한 자세한 내용은 Windows 설명서를 참조하십시오.

3.16.4. 클라이언트가 Samba 출력 서버를 신뢰할 수 있도록 GPO 만들기

보안상의 이유로 최신 Windows 운영 체제는 클라이언트가 신뢰할 수 없는 서버에서 패키지 인식 프린터 드라이버를 다운로드하지 못하도록 합니다. 인쇄 서버가 AD의 멤버인 경우 도메인에 그룹 정책 오브젝트(GPO)를 만들어 Samba 서버를 신뢰할 수 있습니다.

사전 요구 사항

  • Samba 인쇄 서버는 AD 도메인의 멤버입니다.
  • GPO를 생성하는 데 사용하는 Windows 컴퓨터에는 Windows RSAT(원격 서버 관리 도구)가 설치되어 있어야 합니다. 자세한 내용은 Windows 설명서를 참조하십시오.

절차

  1. AD 도메인 Administrator 사용자와 같은 그룹 정책을 편집할 수 있는 계정을 사용하여 Windows 컴퓨터에 로그인합니다.
  2. Group Policy Management Console을 엽니다.
  3. AD 도메인을 마우스 오른쪽 버튼으로 클릭하고 Create a GPO in this domain(이 도메인에서 GPO 만들기)을 선택하고 여기에 연결합니다.

    Samba에서 새 GPO 생성
  4. Legacy Printer Driver Policy 와 같은 GPO 이름을 입력하고 OK(확인 )를 클릭합니다. 새 GPO가 도메인 항목에 표시됩니다.
  5. 새로 만든 GPO를 마우스 오른쪽 버튼으로 클릭하고 Edit(편집 )를 선택하여 그룹 정책 관리 편집기 를 엽니다.
  6. Computer ConfigurationPoliciesTemplates Printers(관리 템플릿 프린터) 로 이동합니다.

    Samba, 프린터 GPO 그룹 선택
  7. 창 오른쪽에서 Point and Print Restriction 을 두 번 클릭하여 정책을 편집합니다.

    1. 정책을 활성화하고 다음 옵션을 설정합니다.

      1. Users(사용자)는 이러한 서버를 가리키고 출력할 수 있으며 Samba 인쇄 서버의 FQDN(정규화된 도메인 이름)을 이 옵션 옆에 있는 필드에 입력합니다.
      2. Security Prompts (보안 프롬프트) 아래에 있는 두 확인란 모두에서 Do not show warning or elevation prompt(경고 또는 승격 프롬프트 표시 안 함)를 선택합니다.

        Samba GPO 포인트 및 인쇄
    2. OK(확인)를 클릭합니다.
  8. Package Point and Print - Approved servers 를 두 번 클릭하여 정책을 편집합니다.

    1. 정책을 활성화하고 Show (표시) 버튼을 클릭합니다.
    2. Samba 출력 서버의 FQDN을 입력합니다.

      Samba GPO 승인 서버
    3. OK (확인)를 클릭하여 Show Contents (콘텐츠 표시) 및 정책의 속성 창을 둘 다 닫습니다.
  9. 그룹 정책 관리 편집기 를 닫습니다.
  10. 그룹 정책 관리 콘솔 을 닫습니다.

Windows 도메인 멤버가 그룹 정책을 적용한 후에는 사용자가 프린터에 연결하면 Samba 서버에서 프린터 드라이버를 자동으로 다운로드합니다.

추가 리소스

  • 그룹 정책을 사용하는 경우 Windows 설명서를 참조하십시오.

3.16.5. 드라이버 업로드 및 프린터 사전 구성

Windows 클라이언트에서 Print Management 애플리케이션을 사용하여 Samba 인쇄 서버에서 호스팅되는 드라이버 및 사전 설정 프린터를 업로드합니다. 자세한 내용은 Windows 설명서를 참조하십시오.

3.17. FIPS 모드가 활성화된 서버에서 Samba 실행

이 섹션에서는 FIPS 모드가 활성화된 상태에서 Samba를 실행할 때의 제한 사항을 간략하게 설명합니다. 또한 Samba를 실행하는 Red Hat Enterprise Linux 호스트에서 FIPS 모드를 활성화하는 절차를 수행합니다.

3.17.1. FIPS 모드에서 Samba 사용 제한

다음 Samba 모드 및 기능은 표시된 조건에서 FIPS 모드에서 작동합니다.

  • 도메인 구성원인 Samba는 AES 암호를 사용하는 Kerberos 인증이 있는 AD(Active Directory) 또는 IdM(Red Hat Identity Management) 환경에서만 사용됩니다.
  • Active Directory 도메인 멤버의 파일 서버로서의 Samba. 그러나 이 경우 클라이언트가 Kerberos를 사용하여 서버에 인증해야 합니다.

FIPS 모드가 활성화된 경우 다음 Samba 기능 및 모드가 작동하지 않습니다.

  • RC4 암호화가 차단되어 NT LAN Manager(NTLM) 인증
  • 서버 메시지 블록 버전 1 (SMB1) 프로토콜
  • NTLM 인증을 사용하므로 독립 실행형 파일 서버 모드
  • NT4 스타일 도메인 컨트롤러
  • NT4 스타일 도메인 구성원. Red Hat은 백그라운드에서 사용하는 기본 도메인 컨트롤러(PDC) 기능을 계속 지원합니다.
  • Samba 서버에 대한 암호 변경. Active Directory 도메인 컨트롤러에 대해 Kerberos를 사용하여 암호 변경만 수행할 수 있습니다.

다음 기능은 FIPS 모드에서 테스트되지 않았으므로 Red Hat에서 지원하지 않습니다.

  • Samba를 프린트 서버로 실행

3.17.2. FIPS 모드에서 Samba 사용

이 섹션에서는 Samba를 실행하는 RHEL 호스트에서 FIPS 모드를 활성화하는 방법을 설명합니다.

사전 요구 사항

  • Samba는 Red Hat Enterprise Linux 호스트에서 구성됩니다.
  • Samba는 FIPS 모드에서 지원되는 모드에서 실행됩니다.

절차

  1. RHEL에서 FIPS 모드를 활성화합니다.

    # fips-mode-setup --enable
  2. 서버를 재부팅합니다.

    # reboot
  3. testparm 유틸리티를 사용하여 구성을 확인합니다.

    # testparm -s

    명령에서 오류 또는 비호환성을 표시하는 경우 이를 수정하여 Samba가 올바르게 작동하는지 확인합니다.

3.18. Samba 서버의 성능 튜닝

이 장에서는 특정 상황에서 Samba의 성능을 향상시킬 수 있는 설정과 성능에 부정적인 영향을 줄 수 있는 설정을 설명합니다.

이 섹션의 일부는 Samba Wiki에 게시된 Performance Tuning 설명서에서 채택되었습니다. 라이센스: CC BY 4.0. 작성자 및 기여자: Wiki 페이지의 기록 탭을 참조하십시오.

사전 요구 사항

  • Samba가 파일 또는 인쇄 서버로 설정됨

3.18.1. SMB 프로토콜 버전 설정

각 새 SMB 버전은 기능을 추가하고 프로토콜의 성능을 향상시킵니다. 최신 Windows 및 Windows Server 운영 체제는 항상 최신 프로토콜 버전을 지원합니다. Samba도 최신 프로토콜 버전을 사용하는 경우 Samba에 연결하는 Windows 클라이언트는 성능 개선을 활용합니다. Samba에서 서버 최대 프로토콜의 기본값은 지원되는 최신 SMB 프로토콜 버전으로 설정됩니다.

참고

안정적인 최신 SMB 프로토콜 버전을 항상 활성화하려면 server max protocol 매개 변수를 설정하지 마십시오. 매개 변수를 수동으로 설정한 경우 최신 프로토콜 버전을 활성화하려면 새 버전의 SMB 프로토콜로 설정을 수정해야 합니다.

다음 절차에서는 server max protocol 매개 변수에서 기본값을 사용하는 방법을 설명합니다.

절차

  1. /etc/samba/smb.conf 파일의 [global] 섹션에서 server max protocol 매개 변수를 제거합니다.
  2. Samba 구성 다시 로드

    # smbcontrol all reload-config

3.18.2. 많은 수의 파일이 포함된 디렉터리로 공유 튜닝

Linux는 대소문자를 구분하지 않는 파일 이름을 지원합니다. 따라서 Samba는 파일을 검색하거나 액세스할 때 디렉토리를 검색하거나 소문자로 검색해야 합니다. 소문자 또는 대문자로만 새 파일을 만들어 성능을 개선하도록 공유를 구성할 수 있습니다.

사전 요구 사항

  • Samba는 파일 서버로 구성됩니다.

절차

  1. 공유의 모든 파일의 이름을 소문자로 바꿉니다.

    참고

    이 절차의 설정을 사용하면 소문자 이외의 이름이 있는 파일이 더 이상 표시되지 않습니다.

  2. 공유의 섹션에서 다음 매개변수를 설정합니다.

    case sensitive = true
    default case = lower
    preserve case = no
    short preserve case = no

    매개 변수에 대한 자세한 내용은 smb.conf(5) 도움말 페이지에서 설명을 참조하십시오.

  3. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  4. Samba 구성을 다시 로드합니다.

    # smbcontrol all reload-config

이러한 설정을 적용한 후에는 이 공유에 새로 생성된 모든 파일의 이름이 소문자를 사용합니다. 이러한 설정으로 인해 Samba에서 더 이상 대문자 및 소문자로 디렉터리를 스캔할 필요가 없으므로 성능이 향상됩니다.

3.18.3. 성능에 부정적인 영향을 줄 수 있는 설정

기본적으로 Red Hat Enterprise Linux의 커널은 높은 네트워크 성능을 위해 조정됩니다. 예를 들어 커널은 버퍼 크기에 자동 튜닝 메커니즘을 사용합니다. /etc/samba/smb.conf 파일에서 socket options 매개 변수를 설정하면 이러한 커널 설정이 재정의됩니다. 결과적으로 이 매개 변수를 설정하면 대부분의 경우 Samba 네트워크 성능이 저하됩니다.

커널에서 최적화된 설정을 사용하려면 /etc/samba/smb.conf[global] 섹션에서 소켓 옵션 매개 변수를 제거합니다.

3.19. SMB 버전이 기본값보다 낮은 SMB 버전이 필요한 클라이언트와 호환되도록 Samba 구성

Samba는 지원하는 최소 SMB(서버 메시지 블록) 버전에 적절하고 안전한 기본값을 사용합니다. 그러나 이전 SMB 버전이 필요한 클라이언트가 있는 경우 Samba를 구성하여 지원할 수 있습니다.

3.19.1. Samba 서버에서 지원하는 최소 SMB 프로토콜 버전 설정

Samba에서 /etc/samba/smb.conf 파일의 server min protocol 매개 변수는 Samba 서버가 지원하는 최소 SMB(서버 메시지 블록) 프로토콜 버전을 정의합니다. 이 섹션에서는 최소 SMB 프로토콜 버전을 변경하는 방법에 대해 설명합니다.

참고

기본적으로 RHEL 8.2 이상의 Samba는 SMB2 및 최신 프로토콜 버전만 지원합니다. Red Hat은 더 이상 사용되지 않는 SMB1 프로토콜을 사용하지 않을 것을 권장합니다. 그러나 환경에 SMB1이 필요한 경우 수동으로 server min protocol 매개 변수를 NT1로 설정하여 SMB1 을 다시 활성화할 수 있습니다.

사전 요구 사항

  • Samba가 설치 및 구성되어 있습니다.

절차

  1. /etc/samba/smb.conf 파일을 편집하고 server min protocol 매개 변수를 추가하고, 매개 변수를 서버가 지원해야 하는 최소 SMB 프로토콜 버전으로 설정합니다. 예를 들어 최소 SMB 프로토콜 버전을 SMB3 로 설정하려면 다음을 추가합니다.

    server min protocol = SMB3
  2. smb 서비스를 다시 시작하십시오.

    # systemctl restart smb

추가 리소스

  • smb.conf(5) man page

3.20. 자주 사용되는 Samba 명령줄 유틸리티

이 장에서는 Samba 서버를 사용할 때 자주 사용되는 명령에 대해 설명합니다.

3.20.1. 순 광고 조인 및 net rpc 조인 명령 사용

net 유틸리티의 조인 하위 명령을 사용하여 Samba를 AD 또는 NT4 도메인에 연결할 수 있습니다. 도메인에 가입하려면 /etc/samba/smb.conf 파일을 수동으로 생성하고 PAM과 같은 추가 구성을 선택적으로 업데이트해야 합니다.

중요

도메인 가입을 위해 realm 유틸리티를 사용하는 것이 좋습니다. realm 유틸리티는 관련된 모든 구성 파일을 자동으로 업데이트합니다.

절차

  1. 다음 설정으로 /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
  2. * 기본 도메인과 /etc/samba/smb.conf 파일의 [global] 섹션에 참여할 도메인에 대한 ID 매핑 구성을 추가합니다.
  3. /etc/samba/smb.conf 파일을 확인합니다.

    # testparm
  4. 도메인에 도메인 관리자로 가입합니다.

    • AD 도메인에 가입하려면 다음을 수행합니다.

      # net ads join -U "DOMAIN\administrator"
    • NT4 도메인에 가입하려면 다음을 수행합니다.

      # net rpc join -U "DOMAIN\administrator"
  5. winbind 소스를 /etc/nsswitch.conf 파일의 passwd그룹 database 항목에 추가합니다.

    passwd:     files winbind
    group:      files winbind
  6. winbind 서비스를 활성화하고 시작합니다.

    # systemctl enable --now winbind
  7. 선택적으로 authselect 유틸리티를 사용하여 PAM을 구성합니다.

    자세한 내용은 authselect(8) 도움말 페이지를 참조하십시오.

  8. AD 환경에 선택적으로 Kerberos 클라이언트를 구성합니다.

    자세한 내용은 Kerberos 클라이언트 설명서를 참조하십시오.

3.20.2. net rpc 권한 명령 사용

Windows에서는 공유 또는 업로드 프린터 드라이버에 ACL을 설정하는 등의 특수 작업을 수행할 수 있도록 계정과 그룹에 권한을 할당할 수 있습니다. Samba 서버에서는 net rpc rights 명령을 사용하여 권한을 관리할 수 있습니다.

설정할 수 있는 권한 나열

사용 가능한 모든 권한 및 소유자를 나열하려면 net rpc rights list 명령을 사용합니다. 예를 들면 다음과 같습니다.

# net rpc rights list -U "DOMAIN\administrator"
Enter DOMAIN\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.
권한 박탈

계정 또는 그룹의 권한을 취소하려면 net rpc rights revoke 명령을 사용합니다.

예를 들어 DOMAIN\printadmin 그룹에서 Seprint OperatorPrivilege 권한을 취소하려면 다음을 수행합니다.

# net rpc rights remoke "DOMAIN\printadmin" SePrintOperatorPrivilege -U "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
Successfully revoked rights.

3.20.3. net rpc share 명령 사용

net rpc share 명령은 로컬 또는 원격 Samba 또는 Windows 서버에서 공유를 나열, 추가 및 제거하는 기능을 제공합니다.

공유 나열

SMB 서버의 공유를 나열하려면 net rpc share list 명령을 사용합니다. 선택적으로 -S server_name 매개 변수를 명령에 전달하여 원격 서버의 공유를 나열합니다. 예를 들면 다음과 같습니다.

# net rpc share list -U "DOMAIN\administrator" -S server_name
Enter DOMAIN\administrator's password:
IPC$
share_1
share_2
...
참고

/etc/samba/smb.conf 파일의 섹션에 browseable = no set이 있는 Samba 서버에서 호스팅되는 공유는 출력에 표시되지 않습니다.

공유 추가

net rpc share add 명령을 사용하면 SMB 서버에 공유를 추가할 수 있습니다.

예를 들어 C:\example\ 디렉터리를 공유하는 원격 Windows 서버에 예제 공유를 추가하려면 다음을 수행합니다.

# net rpc share add example="C:\example" -U "DOMAIN\administrator" -S server_name
참고

Windows 디렉토리 이름을 지정할 때 경로에서 후행 역슬래시를 생략해야 합니다.

명령을 사용하여 Samba 서버에 공유를 추가하려면 다음을 수행합니다.

  • -U 매개 변수에 지정된 사용자에게는 대상 서버에 SeDiskOperatorPrivilege 권한이 부여되어야 합니다.
  • /etc/samba/smb.conf 파일에 공유 섹션을 추가하고 Samba를 다시 로드하는 스크립트를 작성해야 합니다. 스크립트는 /etc/samba/smb.conf[global] 섹션에서 add share 명령 매개 변수에 설정해야 합니다. 자세한 내용은 smb.conf(5) 도움말 페이지의 공유 명령 추가 설명을 참조하십시오.
공유 제거

net rpc share delete 명령을 사용하면 SMB 서버에서 공유를 제거할 수 있습니다.

예를 들어 원격 Windows 서버에서 example이라는 공유를 제거하려면 다음을 수행합니다.

# net rpc share delete example -U "DOMAIN\administrator" -S server_name

명령을 사용하여 Samba 서버에서 공유를 제거하려면 다음을 수행합니다.

  • -U 매개 변수에 지정된 사용자에게는 SeDiskOperatorPrivilege 권한이 부여되어 있어야 합니다.
  • /etc/samba/smb.conf 파일에서 공유 섹션을 제거하고 Samba를 다시 로드하는 스크립트를 작성해야 합니다. 스크립트는 /etc/samba/smb.conf[global] 섹션에서 delete share 명령 매개 변수에 설정해야 합니다. 자세한 내용은 smb.conf(5) 도움말 페이지의 delete share 명령 설명을 참조하십시오.

3.20.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 계정을 도메인에 추가합니다.

  1. 계정을 추가합니다.

    # net user add user password -U "DOMAIN\administrator"
    User user added
  2. 선택적으로, 원격 프로시저 호출(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

3.20.5. rpcclient 유틸리티 사용

rpcclient 유틸리티를 사용하면 로컬 또는 원격 SMB 서버에서 클라이언트측 MS-RPC 기능을 수동으로 실행할 수 있습니다. 그러나 대부분의 기능은 Samba에서 제공하는 별도의 유틸리티로 통합됩니다. rpcclient 는 MS-PRC 함수를 테스트하는 경우에만 사용합니다.

사전 요구 사항

  • samba-client 패키지가 설치되어 있습니다.

예를 들어 rpcclient 유틸리티를 사용하여 다음을 수행할 수 있습니다.

  • 프린터 스풀 하위 시스템(SPOOLSS) 관리.

    예 3.7. 프린터에 드라이버 할당

    # rpcclient server_name -U "DOMAIN\administrator" -c 'setdriver "printer_name" "driver_name"'
    Enter DOMAIN\administrators password:
    Successfully set printer_name to driver driver_name.
  • SMB 서버에 대한 정보를 검색합니다.

    예 3.8. 모든 파일 공유 및 공유 프린터 나열

    # rpcclient server_name -U "DOMAIN\administrator" -c 'netshareenum'
    Enter DOMAIN\administrators 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) 프로토콜을 사용하여 작업을 수행합니다.

    예 3.9. SMB 서버에 사용자 나열

    # rpcclient server_name -U "DOMAIN\administrator" -c 'enumdomusers'
    Enter DOMAIN\administrators password:
    user:[user1] rid:[0x3e8]
    user:[user2] rid:[0x3e9]

    독립 실행형 서버 또는 도메인 구성원에 대해 명령을 실행하면 로컬 데이터베이스의 사용자가 나열됩니다. AD DC 또는 NT4 PDC에 대해 명령을 실행하면 도메인 사용자가 나열됩니다.

추가 리소스

  • haproxyclient(1) 도움말 페이지

3.20.6. samba-regedit 애플리케이션 사용

프린터 구성과 같은 특정 설정은 Samba 서버의 레지스트리에 저장됩니다. ncurses 기반 samba-regedit 애플리케이션을 사용하여 Samba 서버의 레지스트리를 편집할 수 있습니다.

samba regedit

사전 요구 사항

  • samba-client 패키지가 설치되어 있습니다.

절차

애플리케이션을 시작하려면 다음을 입력합니다.

# samba-regedit

다음 키를 사용합니다.

  • 커서가 이동한 후 커서가 삭제됩니다. 레지스트리 트리와 값을 탐색합니다.
  • Enter: 키를 열거나 값을 편집합니다.
  • : Key (키)와 Value(값 ) 창 사이를 전환합니다.
  • Ctrl+C: 애플리케이션을 닫습니다.

3.20.7. smbcontrol 유틸리티 사용

smbcontrol 유틸리티를 사용하면 smbd,nmbd,winbindd 또는 모든 서비스에 명령 메시지를 보낼 수 있습니다. 이러한 제어 메시지는 서비스(예:)에서 구성을 다시 로드하도록 지시합니다.

이 섹션의 절차에서는 reload-config 메시지 유형을 all 대상으로 보내 smbd,nmbd,winbindd 서비스의 구성을 다시 로드하는 방법을 보여줍니다.

사전 요구 사항

  • samba-common-tools 패키지가 설치되어 있습니다.

절차

# smbcontrol all reload-config

추가 리소스

  • smbcontrol(1) 도움말 페이지

3.20.8. smbpasswd 유틸리티 사용

smbpasswd 유틸리티는 로컬 Samba 데이터베이스에서 사용자 계정과 암호를 관리합니다.

사전 요구 사항

  • samba-common-tools 패키지가 설치되어 있습니다.

절차

  1. 명령을 사용자로 실행하는 경우 smbpasswd 는 명령을 실행하는 사용자의 Samba 암호를 변경합니다. 예를 들면 다음과 같습니다.

    [user@server ~]$ smbpasswd
    New SMB password: password
    Retype new SMB password: password
  2. root 사용자로 smbpasswd를 실행하는 경우 유틸리티를 사용하여 다음을 수행할 수 있습니다.

    • 새 사용자를 생성합니다.

      [root@server ~]# smbpasswd -a user_name
      New SMB password: password
      Retype new SMB password: password
      Added user user_name.
      참고

      사용자를 Samba 데이터베이스에 추가하려면 로컬 운영 체제에서 계정을 만들어야 합니다. 기본 시스템 설정 구성 가이드 의 명령줄에서 새 사용자 추가를 참조하십시오.

    • 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.

추가 리소스

  • sambapasswd(8) 도움말 페이지

3.20.9. smbstatus 유틸리티 사용

smbstatus 유틸리티는 다음에 대해 보고합니다.

  • smbd 데몬의 PID당 Samba 서버에 대한 연결. 이 보고서에는 사용자 이름, 기본 그룹, SMB 프로토콜 버전, 암호화 및 서명 정보가 포함됩니다.
  • Samba 공유별 연결. 이 보고서에는 smbd 데몬의 PID, 연결 시스템의 IP, 연결이 설정된 타임스탬프, 암호화 및 서명 정보가 포함됩니다.
  • 잠긴 파일 목록. 보고서 항목에는 opportunistic 잠금 (oplock) 유형과 같은 추가 세부 정보가 포함됩니다.

사전 요구 사항

  • samba 패키지가 설치되어 있습니다.
  • smbd 서비스가 실행 중입니다.

절차

# smbstatus

Samba version 4.15.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  Thu Nov  1 10:00:00 2018 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  Thu Nov  1 10:00:00 2018

추가 리소스

  • smbstatus(1) 도움말 페이지

3.20.10. smbtar 유틸리티 사용

smbtar 유틸리티는 SMB 공유 또는 하위 디렉터리의 콘텐츠를 백업하고 tar 아카이브에 콘텐츠를 저장합니다. 또는 테이프 장치에 콘텐츠를 작성할 수 있습니다.

사전 요구 사항

  • samba-client 패키지가 설치되어 있습니다.

절차

  • 다음 명령을 사용하여 0.0.0.0/0 server/example/ 공유에 있는 demo 디렉터리의 콘텐츠를 백업하고 해당 콘텐츠를 /root/example.tar 아카이브에 저장합니다.

    # smbtar -s server -x example -u user_name -p password -t /root/example.tar

추가 리소스

  • sambatar(1) 도움말 페이지

3.20.11. wbinfo 유틸리티 사용

wbinfo 유틸리티는 winbindd 서비스에서 생성 및 사용하는 정보를 쿼리하고 반환합니다.

사전 요구 사항

  • samba-winbind-clients 패키지가 설치되어 있습니다.

절차

예를 들어 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) 도움말 페이지

3.21. 추가 리소스

4장. BIND DNS 서버 설정 및 구성

BIND는 IETF(Internet Engineering Task Force) DNS 표준 및 초안 표준을 완벽하게 준수하는 기능이 풍부한 DNS 서버입니다. 예를 들어 관리자는 다음과 같이 BIND를 자주 사용합니다.

  • 로컬 네트워크에서 DNS 서버 캐싱
  • 영역에 대한 권한 있는 DNS 서버
  • 영역에 고가용성을 제공하는 보조 서버

4.1. SELinux를 통한 BIND 보호 또는 변경 루트 환경에서 BIND 실행에 대한 고려 사항

BIND 설치를 보호하려면 다음을 수행할 수 있습니다.

  • 변경 루트 환경 없이 named 서비스를 실행합니다. 이 경우 강제 모드의 SELinux는 알려진 BIND 보안 취약점의 악용을 방지합니다. 기본적으로 Red Hat Enterprise Linux는 SELinux를 강제 모드로 사용합니다.

    중요

    SELinux를 강제 모드로 RHEL에서 BIND를 실행하는 것은 변경 루트 환경에서 BIND를 실행하는 것보다 더 안전합니다.

  • change-root 환경에서 named-chroot 서비스를 실행합니다.

    관리자는 change-root 기능을 사용하여 프로세스의 루트 디렉터리와 하위 프로세스가 / 디렉토리와 다른 것을 정의할 수 있습니다. named-chroot 서비스를 시작하면 BIND에서 루트 디렉터리를 /var/named/chroot/ 로 전환합니다. 결과적으로 서비스는 mount --bind 명령을 사용하여 /var/named/chroot/ 에서 /etc/named-chroot.files 에 나열된 파일과 디렉터리를 만들고, 프로세스는 /var/named/chroot/ 외부의 파일에 액세스할 수 없습니다.

BIND를 사용하려면 다음을 수행합니다.

  • 일반 모드에서는 named 서비스를 사용합니다.
  • 변경 루트 환경에서는 named-chroot 서비스를 사용합니다. 이를 위해서는 named-chroot 패키지를 설치, 추가로 설치해야 합니다.

추가 리소스

  • named(8) 도움말 페이지의 Red Hat SELinux BIND 보안 프로필 섹션

4.2. BIND 관리자 참조 설명서

bind 패키지에 포함된 포괄적인 BIND 관리자 참조 설명서 는 다음을 제공합니다.

  • 구성 예
  • 고급 기능 문서
  • 구성 참조
  • 보안 고려 사항

bind 패키지가 설치된 호스트에 BIND 관리자 참조 설명서를 표시하려면 브라우저에서 /usr/share/doc/bind/Bv9ARM.html 파일을 엽니다.

4.3. BIND를 캐싱 DNS 서버로 구성

기본적으로 BIND DNS 서버는 성공 및 실패한 조회를 확인하고 캐시합니다. 그러면 서비스에서 캐시의 동일한 레코드에 대한 요청에 응답합니다. 이를 통해 DNS 조회 속도가 크게 향상됩니다.

사전 요구 사항

  • 서버의 IP 주소는 고정입니다.

절차

  1. bindbind-utils 패키지를 설치합니다.

    # yum install bind bind-utils

    이러한 패키지는 BIND 9.11을 제공합니다. BIND 9.16이 필요한 경우 bind9.16bind9.16-utils 패키지를 설치하십시오.

  2. change-root 환경에서 BIND를 실행하려면 bind-chroot 패키지를 설치합니다.

    # yum install bind-chroot

    SELinux가 강제 모드에서 호스트에서 BIND를 실행하면 기본값이 더 안전합니다.

  3. /etc/named.conf 파일을 편집하고 options 문에서 다음과 같이 변경합니다.

    1. listen-onlisten-on-v6 문을 업데이트하여 BIND에서 수신 대기해야 하는 IPv4 및 IPv6 인터페이스를 지정합니다.

      listen-on port 53 { 127.0.0.1; 192.0.2.1; };
      listen-on-v6 port 53 { ::1; 2001:db8:1::1; };
    2. allow-query 문을 업데이트하여 클라이언트가 이 DNS 서버를 쿼리할 수 있는 IP 주소 및 범위를 구성합니다.

      allow-query { localhost; 192.0.2.0/24; 2001:db8:1::/64; };
    3. allow-recursion 문을 추가하여 BIND에서 재귀 쿼리를 수락하는 IP 주소 및 범위를 정의합니다.

      allow-recursion { localhost; 192.0.2.0/24; 2001:db8:1::/64; };
      주의

      서버의 공용 IP 주소에 재귀를 허용하지 마십시오. 그렇지 않으면 서버가 대규모 DNS 확장 공격의 일부가 될 수 있습니다.

    4. 기본적으로 BIND는 루트 서버에서 권한 있는 DNS 서버로 반복적으로 쿼리를 확인하여 쿼리를 해결합니다. 또는 공급자와 같은 다른 DNS 서버에 쿼리를 전달하도록 BIND를 구성할 수 있습니다. 이 경우 BIND에서 쿼리를 전달해야 하는 DNS 서버의 IP 주소 목록이 포함된 전달자 문을 추가합니다.

      forwarders { 198.51.100.1; 203.0.113.5; };

      BIND는 전달자 서버가 응답하지 않는 경우 대체 동작으로 쿼리를 재귀적으로 해결합니다. 이 동작을 비활성화하려면 forward only; 문을 추가합니다.

  4. /etc/named.conf 파일의 구문을 확인합니다.

    # named-checkconf

    명령에서 출력이 표시되지 않으면 구문이 올바르게 표시됩니다.

  5. 들어오는 DNS 트래픽을 허용하도록 firewalld 규칙을 업데이트합니다.

    # firewall-cmd --permanent --add-service=dns
    # firewall-cmd --reload
  6. BIND를 시작하고 활성화합니다.

    # systemctl enable --now named

    change-root 환경에서 BIND를 실행하려면 systemctl enable --now named-chroot 명령을 사용하여 서비스를 활성화하고 시작합니다.

검증

  1. 새로 설정된 DNS 서버를 사용하여 도메인을 확인합니다.

    # dig @localhost www.example.org
    ...
    www.example.org.    86400    IN    A    198.51.100.34
    
    ;; Query time: 917 msec
    ...

    이 예에서는 BIND가 동일한 호스트에서 실행되고 localhost 인터페이스의 쿼리에 응답하는 것으로 가정합니다.

    레코드를 처음 쿼리한 후 BIND에서 해당 캐시에 항목을 추가합니다.

  2. 이전 쿼리를 반복합니다.

    # dig @localhost www.example.org
    ...
    www.example.org.    85332    IN    A    198.51.100.34
    
    ;; Query time: 1 msec
    ...

    캐시된 항목으로 인해 항목이 만료될 때까지 동일한 레코드에 대한 추가 요청이 훨씬 더 빨라집니다.

다음 단계

  • 이 DNS 서버를 사용하도록 네트워크의 클라이언트를 구성합니다. DHCP 서버가 클라이언트에 DNS 서버 설정을 제공하는 경우 DHCP 서버의 구성을 적절하게 업데이트합니다.

추가 리소스

4.4. BIND DNS 서버에서 로깅 구성

bind 패키지에서 제공하는 기본 /etc/named.conf 파일의 구성은 default_debug 채널을 사용하고 메시지를 /var/named/data/named.run 파일에 기록합니다. default_debug 채널은 서버의 디버그 수준이 0이 아닌 경우에만 항목을 기록합니다.

다양한 채널 및 카테고리를 사용하여 BIND를 구성하여 파일을 분리하는 데 정의된 심각도가 있는 다양한 이벤트를 작성할 수 있습니다.

사전 요구 사항

  • BIND는 예를 들어 캐싱 이름 서버로 이미 구성되어 있습니다.
  • named 또는 named-chroot 서비스가 실행 중입니다.

절차

  1. /etc/named.conf 파일을 편집하고 카테고리채널 구문을 logging 문에 추가합니다. 예를 들면 다음과 같습니다.

    logging {
        ...
    
        category notify { zone_transfer_log; };
        category xfer-in { zone_transfer_log; };
        category xfer-out { zone_transfer_log; };
        channel zone_transfer_log {
            file "/var/named/log/transfer.log" versions 10 size 50m;
            print-time yes;
            print-category yes;
            print-severity yes;
            severity info;
         };
    
         ...
    };

    이 예제 구성으로 BIND는 /var/named/log/transfer.log 로 영역 전송과 관련된 메시지를 기록합니다. BIND에서는 최대 10 개의 로그 파일을 생성하고 최대 50 MB에 도달하면 순환합니다.

    카테고리 는 BIND에서 카테고리 메시지를 전송하는 채널을 정의합니다.

    채널 구문은 버전 수, 최대 파일 크기, 심각도 수준 BIND가 채널에 로그해야 하는 로그 메시지 대상을 정의합니다. 이벤트 타임 스탬프, 카테고리 및 심각도 기록 활성화와 같은 추가 설정은 선택 사항이지만 디버깅 목적에 유용합니다.

  2. 로그 디렉터리가 없는 경우 로그 디렉터리를 생성하고 이 디렉터리의 named 사용자에게 쓰기 권한을 부여합니다.

    # mkdir /var/named/log/
    # chown named:named /var/named/log/
    # chmod 700 /var/named/log/
  3. /etc/named.conf 파일의 구문을 확인합니다.

    # named-checkconf

    명령에서 출력이 표시되지 않으면 구문이 올바르게 표시됩니다.

  4. BIND를 다시 시작합니다.

    # systemctl restart named

    변경 루트 환경에서 BIND를 실행하는 경우 systemctl restart named-chroot 명령을 사용하여 서비스를 다시 시작합니다.

검증

  • 로그 파일의 내용을 표시합니다.

    # cat /var/named/log/transfer.log
    ...
    06-Jul-2022 15:08:51.261 xfer-out: info: client @0x7fecbc0b0700 192.0.2.2#36121/key example-transfer-key (example.com): transfer of 'example.com/IN': AXFR started: TSIG example-transfer-key (serial 2022070603)
    06-Jul-2022 15:08:51.261 xfer-out: info: client @0x7fecbc0b0700 192.0.2.2#36121/key example-transfer-key (example.com): transfer of 'example.com/IN': AXFR ended

추가 리소스

4.5. BIND ACL 작성

BIND의 특정 기능에 대한 액세스를 제어하면 서비스 거부(DoS)와 같은 인증되지 않은 액세스 및 공격을 방지할 수 있습니다. BIND 액세스 제어 목록(acl) 구문은 IP 주소 및 범위 목록입니다. 각 ACL에는 지정된 IP 주소 및 범위를 참조하기 위해 allow-query 와 같은 여러 문에 사용할 수 있는 닉네임이 있습니다.

주의

BIND에서는 ACL에서 첫 번째로 일치하는 항목만 사용합니다. 예를 들어 ACL { 192.0.2/24; !192.0.2.1; } 및 IP 주소가 192.0.2.1 인 호스트에 연결된 경우 두 번째 항목이 이 주소를 제외하더라도 액세스 권한이 부여됩니다.

BIND에는 다음과 같은 기본 제공 ACL이 있습니다.

  • 제공되지 않음: 호스트와 일치하지 않습니다.
  • 참고: 모든 호스트와 일치합니다.
  • localhost: 루프백 주소 127.0.0.1::1 과 BIND를 실행하는 서버에서 모든 인터페이스의 IP 주소와 일치합니다.
  • localnets: 루프백 주소는 127.0.0.1::1 과 일치하며 BIND를 실행하는 모든 서브넷은 직접 연결됩니다.

사전 요구 사항

  • BIND는 예를 들어 캐싱 이름 서버로 이미 구성되어 있습니다.
  • named 또는 named-chroot 서비스가 실행 중입니다.

절차

  1. /etc/named.conf 파일을 편집하고 다음과 같이 변경합니다.

    1. 파일에 acl 문을 추가합니다. 예를 들어 127.0.0.1,192.0.2.0/24, 2001:db8:1::/64 에 대해 internal-networks 라는 ACL을 생성하려면 다음을 입력합니다.

      acl internal-networks { 127.0.0.1; 192.0.2.0/24; 2001:db8:1::/64; };
      acl dmz-networks { 198.51.100.0/24; 2001:db8:2::/64; };
    2. ACL의 nickname을 지원하는 문에 사용합니다. 예를 들면 다음과 같습니다.

      allow-query { internal-networks; dmz-networks; };
      allow-recursion { internal-networks; };
  2. /etc/named.conf 파일의 구문을 확인합니다.

    # named-checkconf

    명령에서 출력이 표시되지 않으면 구문이 올바르게 표시됩니다.

  3. BIND를 다시 로드합니다.

    # systemctl reload named

    변경 루트 환경에서 BIND를 실행하는 경우 systemctl reload named-chroot 명령을 사용하여 서비스를 다시 로드합니다.

검증

  • 구성된 ACL을 사용하는 기능을 트리거하는 작업을 실행합니다. 예를 들어 이 절차의 ACL은 정의된 IP 주소의 재귀 쿼리만 허용합니다. 이 경우 ACL 정의 내에 없는 호스트에 다음 명령을 입력하여 외부 도메인을 확인합니다.

    # dig +short @192.0.2.1 www.example.com

    명령에서 출력이 반환되지 않으면 BIND에서 액세스를 거부하고 ACL이 작동합니다. 클라이언트에 대한 자세한 출력의 경우 +short 옵션 없이 명령을 사용합니다.

    # dig @192.0.2.1 www.example.com
    ...
    ;; WARNING: recursion requested but not available
    ...

추가 리소스

4.6. BIND DNS 서버에서 영역 구성

DNS 영역은 도메인 공간의 특정 하위 트리에 대한 리소스 레코드가 있는 데이터베이스입니다. 예를 들어 example.com 도메인을 담당하는 경우 BIND에서 영역을 설정할 수 있습니다. 결과적으로 클라이언트는 www.example.com 을 이 영역에 구성된 IP 주소로 확인할 수 있습니다.

4.6.1. 영역 파일의 SOA 레코드

권한 시작(SOA) 레코드는 DNS 영역에 필요한 레코드입니다. 예를 들어 영역과 관련하여 여러 DNS 서버에 대한 권한이 있고 DNS 확인자에게도 적용되는 경우 이 레코드가 중요합니다.

BIND의 SOA 레코드에는 다음과 같은 구문이 있습니다.

name class type mname rname serial refresh retry expire minimum

읽기 쉽도록 관리자는 일반적으로 영역 파일의 레코드를ECDHE(;;)로 시작하는 주석으로 여러 행으로 분할합니다. SOA 레코드를 분할하면 해당 레코드를 함께 유지합니다.

@ IN SOA ns1.example.com. hostmaster.example.com. (
                          2022070601 ; serial number
                          1d         ; refresh period
                          3h         ; retry period
                          3d         ; expire time
                          3h )       ; minimum TTL
중요

FQDN(정규화된 도메인 이름)의 끝에 있는 후행 점을 기록해 둡니다. FQDN은 점으로 구분된 여러 도메인 레이블로 구성됩니다. DNS 루트에는 빈 레이블이 있으므로 FQDN은 점으로 끝납니다. 따라서 BIND는 후행 점 없이 이름에 영역 이름을 추가합니다. 후행 점이 없는 호스트 이름(예: ns1.example.com )은 기본 이름 서버의 올바른 주소가 아닌 ns1.example.com.com으로 확장됩니다.

다음은 SOA 레코드의 필드입니다.

  • name: 영역의 이름, 즉 원본 이라고 합니다. 이 필드를 @ 로 설정하면 BIND에서 /etc/named.conf 에 정의된 영역 이름으로 확장됩니다.
  • 클래스: SOA 레코드에서 이 필드를 항상 인터넷(IN)으로 설정해야 합니다.
  • 유형: SOA 레코드에서 이 필드를 항상 SOA 로 설정해야 합니다.
  • mname (마스터 이름): 이 영역의 기본 이름 서버의 호스트 이름입니다.
  • R NAME (응답할 수 있는 이름): 이 영역을 담당하는 사용자의 이메일 주소입니다. 형식은 다릅니다. at 기호(@)를 점(.)으로 교체해야 합니다.
  • serial: 이 영역 파일의 버전 번호입니다. 보조 이름 서버는 기본 서버의 일련 번호가 더 높은 경우에만 영역 복사본을 업데이트합니다.

    형식은 모든 숫자 값일 수 있습니다. 일반적으로 사용되는 형식은 < year><month><day><two-digit-number >입니다. 이 형식을 사용하면 이론적으로 영역 파일을 하루에 한 번까지 변경할 수 있습니다.

  • 새로 고침: 영역이 업데이트되었는지 기본 서버를 확인하기 전에 보조 서버의 시간을 기다려야 합니다.
  • 재시도: 보조 서버가 실패한 후 주 서버를 쿼리하기 위해 재시도한 후의 시간입니다.
  • 만료: 이전 시도가 모두 실패한 경우 보조 서버가 주 서버 쿼리를 중지한 후의 시간입니다.
  • 최소: RFC 2308에서는 이 필드의 의미가 음수 캐싱 시간으로 변경되었습니다. 호환 확인자는 이를 사용하여 NXDOMAIN 이름 오류를 캐시하는 기간을 결정합니다.
참고

새로 고침 의 숫자 값,재시도,만료, 최소 필드는 시간(초)을 정의합니다. 그러나 가독성을 높이기 위해 m for minute, h for hours, d 와 같은 시간 접미사를 사용합니다. 예를 들어, 3h 는 3 시간 동안 지속됩니다.

추가 리소스

  • RFC 1035: 도메인 이름 - 구현 및 사양
  • RFC 1034: 도메인 이름 - 개념과 기능
  • RFC 2308: DNS 쿼리의 음수 캐싱(DNS 캐시)

4.6.2. BIND 기본 서버에서 전달 영역 설정

영역은 이름을 IP 주소 및 기타 정보에 매핑합니다. 예를 들어 example.com 도메인의 책임이 있는 경우 BIND에서 전달 영역을 설정하여 이름을 확인할 수 있습니다(예: www.example.com ).

사전 요구 사항

  • BIND는 예를 들어 캐싱 이름 서버로 이미 구성되어 있습니다.
  • named 또는 named-chroot 서비스가 실행 중입니다.

절차

  1. /etc/named.conf 파일에 영역 정의를 추가합니다.

    zone "example.com" {
        type master;
        file "example.com.zone";
        allow-query { any; };
        allow-transfer { none; };
    };

    이러한 설정은 다음과 같이 정의됩니다.

    • example.com 영역의 기본 서버(유형 master)로 이 서버입니다.
    • /var/named/example.com.zone 파일은 영역 파일입니다. 이 예에서와 같이 상대 경로를 설정하는 경우 이 경로는 options 문에서 디렉터리에 설정한 디렉터리를 기준으로 합니다.
    • 모든 호스트는 이 영역을 쿼리할 수 있습니다. 또는 IP 범위 또는 BIND 액세스 제어 목록(ACL)을 지정하여 액세스를 제한합니다.
    • 어떤 호스트도 영역을 전송할 수 없습니다. 보조 서버를 설정하는 경우에만 영역 전송을 허용하고 보조 서버의 IP 주소에 대해서만 전송할 수 있습니다.
  2. /etc/named.conf 파일의 구문을 확인합니다.

    # named-checkconf

    명령에서 출력이 표시되지 않으면 구문이 올바르게 표시됩니다.

  3. 예를 들어 다음 콘텐츠를 사용하여 /var/named/example.com.zone 파일을 만듭니다.

    $TTL 8h
    @ IN SOA ns1.example.com. hostmaster.example.com. (
                              2022070601 ; serial number
                              1d         ; refresh period
                              3h         ; retry period
                              3d         ; expire time
                              3h )       ; minimum TTL
    
                      IN NS   ns1.example.com.
                      IN MX   10 mail.example.com.
    
    www               IN A    192.0.2.30
    www               IN AAAA 2001:db8:1::30
    ns1               IN A    192.0.2.1
    ns1               IN AAAA 2001:db8:1::1
    mail              IN A    192.0.2.20
    mail              IN AAAA 2001:db8:1::20

    이 영역 파일:

    • 리소스 레코드에 대한 기본 TTL(Time-to-live) 값을 8시간으로 설정합니다. 시간별 h 와 같은 시간 접미사가 없으면 BIND에서 값을 초로 해석합니다.
    • 영역에 대한 세부 정보가 포함된 필수 SOA 리소스 레코드를 포함합니다.
    • ns1.example.com 을 이 영역에 대한 권한 있는 DNS 서버로 설정합니다. 기능을 사용하려면 영역에 하나 이상의 이름 서버(NS) 레코드가 필요합니다. 그러나 RFC 1912를 준수하려면 두 개 이상의 이름 서버가 필요합니다.
    • example.com 도메인의 mail.example.com 을 메일 교환기(MX)로 설정합니다. 호스트 이름 앞에 있는 숫자 값은 레코드의 우선 순위입니다. 값이 낮은 항목은 우선 순위가 높습니다.
    • www.example.com,mail.example.comns1.example.com 의 IPv4 및 IPv6 주소를 설정합니다.
  4. named 그룹만 읽을 수 있는 영역 파일에 보안 권한을 설정합니다.

    # chown root:named /var/named/example.com.zone
    # chmod 640 /var/named/example.com.zone
  5. /var/named/example.com.zone 파일의 구문을 확인합니다.

    # named-checkzone example.com /var/named/example.com.zone
    zone example.com/IN: loaded serial 2022070601
    OK
  6. BIND를 다시 로드합니다.

    # systemctl reload named

    변경 루트 환경에서 BIND를 실행하는 경우 systemctl reload named-chroot 명령을 사용하여 서비스를 다시 로드합니다.

검증

  • example.com 영역의 다른 레코드를 쿼리하고 출력이 영역 파일에서 구성한 레코드와 일치하는지 확인합니다.

    # dig +short @localhost AAAA www.example.com
    2001:db8:1::30
    
    # dig +short @localhost NS example.com
    ns1.example.com.
    
    # dig +short @localhost A ns1.example.com
    192.0.2.1

    이 예에서는 BIND가 동일한 호스트에서 실행되고 localhost 인터페이스의 쿼리에 응답하는 것으로 가정합니다.

4.6.3. BIND 기본 서버에서 역방향 영역 설정

역방향 영역은 IP 주소를 이름에 매핑합니다. 예를 들어, IP 범위 192.0.2.0/24 를 담당하는 경우 BIND에서 역방향 영역을 설정하여 이 범위에서 IP 주소를 호스트 이름으로 확인할 수 있습니다.

참고

전체 클래스 네트워크의 역방향 영역을 생성하는 경우 그에 따라 영역 이름을 지정합니다. 예를 들어 C 네트워크 192.0.2.0/24 클래스의 경우 영역 이름은 2.0.192.in-addr.arpa 입니다. 다른 네트워크 크기에 대한 역방향 영역을 생성하려는 경우(예: 190.0.2.0/28 ) 영역 이름은 28-2.0.192.in-addr.arpa 입니다.

사전 요구 사항

  • BIND는 예를 들어 캐싱 이름 서버로 이미 구성되어 있습니다.
  • named 또는 named-chroot 서비스가 실행 중입니다.

절차

  1. /etc/named.conf 파일에 영역 정의를 추가합니다.

    zone "2.0.192.in-addr.arpa" {
        type master;
        file "2.0.192.in-addr.arpa.zone";
        allow-query { any; };
        allow-transfer { none; };
    };

    이러한 설정은 다음과 같이 정의됩니다.

    • 2.0.192.in-addr.arpa 역방향 영역에 대한 기본 서버(예:master)로 이 서버입니다.
    • /var/named/2.0.192.in-addr.arpa.zone 파일은 영역 파일입니다. 이 예에서와 같이 상대 경로를 설정하는 경우 이 경로는 options 문에서 디렉터리에 설정한 디렉터리를 기준으로 합니다.
    • 모든 호스트는 이 영역을 쿼리할 수 있습니다. 또는 IP 범위 또는 BIND 액세스 제어 목록(ACL)을 지정하여 액세스를 제한합니다.
    • 어떤 호스트도 영역을 전송할 수 없습니다. 보조 서버를 설정하는 경우에만 영역 전송을 허용하고 보조 서버의 IP 주소에 대해서만 전송할 수 있습니다.
  2. /etc/named.conf 파일의 구문을 확인합니다.

    # named-checkconf

    명령에서 출력이 표시되지 않으면 구문이 올바르게 표시됩니다.

  3. 예를 들어 다음 콘텐츠를 사용하여 /var/named/2.0.192.in-addr.arpa.zone 파일을 만듭니다.

    $TTL 8h
    @ IN SOA ns1.example.com. hostmaster.example.com. (
                              2022070601 ; serial number
                              1d         ; refresh period
                              3h         ; retry period
                              3d         ; expire time
                              3h )       ; minimum TTL
    
                      IN NS   ns1.example.com.
    
    1                 IN PTR  ns1.example.com.
    30                IN PTR  www.example.com.

    이 영역 파일:

    • 리소스 레코드에 대한 기본 TTL(Time-to-live) 값을 8시간으로 설정합니다. 시간별 h 와 같은 시간 접미사가 없으면 BIND에서 값을 초로 해석합니다.
    • 영역에 대한 세부 정보가 포함된 필수 SOA 리소스 레코드를 포함합니다.
    • ns1.example.com 을 이 역방향 영역에 대해 권한 있는 DNS 서버로 설정합니다. 기능을 사용하려면 영역에 하나 이상의 이름 서버(NS) 레코드가 필요합니다. 그러나 RFC 1912를 준수하려면 두 개 이상의 이름 서버가 필요합니다.
    • 192.0.2.1192.0.2.30 주소에 대한 포인터(PTR) 레코드를 설정합니다.
  4. 명명된 그룹만 읽을 수 있는 영역 파일에 대한 보안 권한을 설정합니다.

    # chown root:named /var/named/2.0.192.in-addr.arpa.zone
    # chmod 640 /var/named/2.0.192.in-addr.arpa.zone
  5. /var/named/2.0.192.in-addr.arpa.zone 파일의 구문을 확인합니다.

    # named-checkzone 2.0.192.in-addr.arpa /var/named/2.0.192.in-addr.arpa.zone
    zone 2.0.192.in-addr.arpa/IN: loaded serial 2022070601
    OK
  6. BIND를 다시 로드합니다.

    # systemctl reload named

    변경 루트 환경에서 BIND를 실행하는 경우 systemctl reload named-chroot 명령을 사용하여 서비스를 다시 로드합니다.

검증

  • 역방향 영역과 다른 레코드를 쿼리하고 출력이 영역 파일에서 구성한 레코드와 일치하는지 확인합니다.

    # dig +short @localhost -x 192.0.2.1
    ns1.example.com.
    
    # dig +short @localhost -x 192.0.2.30
    www.example.com.

    이 예에서는 BIND가 동일한 호스트에서 실행되고 localhost 인터페이스의 쿼리에 응답하는 것으로 가정합니다.

4.6.4. BIND 영역 파일 업데이트

특정 상황에서는 예를 들어 서버의 IP 주소가 변경되는 경우 영역 파일을 업데이트해야 합니다. 여러 DNS 서버가 영역을 담당하는 경우 기본 서버에서만 이 절차를 수행합니다. 영역 사본을 저장하는 기타 DNS 서버는 영역 전송을 통해 업데이트를 받습니다.

사전 요구 사항

  • 영역이 구성되어 있습니다.
  • named 또는 named-chroot 서비스가 실행 중입니다.

절차

  1. 선택 사항: /etc/named.conf 파일에서 영역 파일의 경로를 확인합니다.

    options {
        ...
        directory       "/var/named";
    }
    
    zone "example.com" {
        ...
        file "example.com.zone";
    };

    영역의 정의의 file 문에서 zone 파일의 경로를 찾습니다. 상대 경로는 options 문에서 디렉터리에 설정된 디렉터리를 기준으로 합니다.

  2. 영역 파일을 편집합니다.

    1. 필요한 변경을 수행합니다.
    2. 권한 시작(SOA) 레코드의 일련 번호를 늘립니다.

      중요

      일련 번호가 이전 값과 같거나 작으면 보조 서버에서 영역의 복사본을 업데이트하지 않습니다.

  3. 영역 파일의 구문을 확인합니다.

    # named-checkzone example.com /var/named/example.com.zone
    zone example.com/IN: loaded serial 2022062802
    OK
  4. BIND를 다시 로드합니다.

    # systemctl reload named

    변경 루트 환경에서 BIND를 실행하는 경우 systemctl reload named-chroot 명령을 사용하여 서비스를 다시 로드합니다.

검증

  • 추가, 수정 또는 제거한 레코드를 쿼리합니다. 예를 들면 다음과 같습니다.

    # dig +short @localhost A ns2.example.com
    192.0.2.2

    이 예에서는 BIND가 동일한 호스트에서 실행되고 localhost 인터페이스의 쿼리에 응답하는 것으로 가정합니다.

4.6.5. 자동화된 키 생성 및 영역 유지 관리 기능을 사용한 DNSSEC 영역 서명

DNSSEC(Domain name system security extensions)로 영역에 서명하여 인증 및 데이터 무결성을 보장할 수 있습니다. 이러한 영역에는 추가 리소스 레코드가 포함되어 있습니다. 클라이언트는 이를 사용하여 영역 정보의 진위 여부를 확인할 수 있습니다.

영역에 DNSSEC 정책 기능을 활성화하면 BIND에서 다음 작업을 자동으로 수행합니다.

  • 키를 만듭니다.
  • 영역에 서명
  • 키를 다시 서명하고 주기적으로 교체하는 등 영역을 유지 관리합니다.
중요

외부 DNS 서버를 활성화하여 영역의 진위 여부를 확인하려면 영역의 공개 키를 상위 영역에 추가해야 합니다. 도메인 공급자 또는 레지스트리에 문의하여 이 작업을 수행하는 방법에 대한 자세한 내용을 확인하십시오.

이 절차에서는 BIND에서 기본 제공 기본 DNSSEC 정책을 사용합니다. 이 정책은 단일 ECDSAP256SHA 키 서명을 사용합니다. 또는 사용자 지정 키, 알고리즘 및 타이밍을 사용하는 자체 정책을 만듭니다.

사전 요구 사항

  • BIND 9.16 이상이 설치되어 있습니다. 이 요구 사항을 충족하려면 bind9.16 패키지 대신 bind 9.16 패키지를 설치합니다.
  • DNSSEC를 활성화하려는 영역이 구성됩니다.
  • named 또는 named-chroot 서비스가 실행 중입니다.
  • 서버는 시간을 시간 서버와 동기화합니다. DNSSEC 검증을 위해서는 정확한 시스템 시간이 중요합니다.

절차

  1. /etc/named.conf 파일을 편집하고 DNSSEC를 활성화하려는 영역에 dnssec-policy default 를 추가합니다.

    zone "example.com" {
        ...
        dnssec-policy default;
    };
  2. BIND를 다시 로드합니다.

    # systemctl reload named

    변경 루트 환경에서 BIND를 실행하는 경우 systemctl reload named-chroot 명령을 사용하여 서비스를 다시 로드합니다.

  3. BIND는 공개 키를 /var/named/K <zone_name > .+ <algorithm> + <key_ID > .key 파일에 저장합니다. 이 파일을 사용하여 상위 영역에 필요한 형식으로 영역의 공개 키를 표시합니다.

    • DS 레코드 형식:

      # dnssec-dsfromkey /var/named/Kexample.com.+013+61141.key
      example.com. IN DS 61141 13 2 3E184188CF6D2521EDFDC3F07CFEE8D0195AACBD85E68BAE0620F638B4B1B027
    • DNSKEY 형식:

      # grep DNSKEY /var/named/Kexample.com.+013+61141.key
      example.com. 3600 IN DNSKEY 257 3 13 sjzT3jNEp120aSO4mPEHHSkReHUf7AABNnT8hNRTzD5cKMQSjDJin2I3 5CaKVcWO1pm+HltxUEt+X9dfp8OZkg==
  4. 영역의 공개 키를 상위 영역에 추가하도록 요청합니다. 도메인 공급자 또는 레지스트리에 문의하여 이 작업을 수행하는 방법에 대한 자세한 내용을 확인하십시오.

검증

  1. DNSSEC 서명을 활성화한 영역에서 자신의 DNS 서버에서 레코드를 쿼리합니다.

    # dig +dnssec +short @localhost A www.example.com
    192.0.2.30
    A 13 3 28800 20220718081258 20220705120353 61141 example.com. e7Cfh6GuOBMAWsgsHSVTPh+JJSOI/Y6zctzIuqIU1JqEgOOAfL/Qz474 M0sgi54m1Kmnr2ANBKJN9uvOs5eXYw==

    이 예에서는 BIND가 동일한 호스트에서 실행되고 localhost 인터페이스의 쿼리에 응답하는 것으로 가정합니다.

  2. 공개 키가 상위 영역에 추가되고 다른 서버로 전달된 후 서버에서 인증된 데이터(ad) 플래그를 서명된 영역으로 설정하는지 확인합니다.

    #  dig @localhost example.com +dnssec
    ...
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    ...

4.7. BIND DNS 서버 간 영역 전송 구성

영역 전송을 통해 영역의 사본이 있는 모든 DNS 서버가 최신 데이터를 사용할 수 있습니다.

사전 요구 사항

  • 향후 기본 서버에서 영역 전송을 설정할 영역이 이미 구성되어 있습니다.
  • 향후 보조 서버에서 BIND는 이미 캐싱 이름 서버로 구성되어 있습니다.
  • 두 서버 모두에서 이름이 지정되거나 named -chroot 서비스가 실행 중입니다.

절차

  1. 기존 기본 서버에서 다음을 수행합니다.

    1. 공유 키를 만들고 /etc/named.conf 파일에 추가합니다.

      # tsig-keygen example-transfer-key | tee -a /etc/named.conf
      key "example-transfer-key" {
              algorithm hmac-sha256;
              secret "q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ=";
      };

      이 명령은 tsig-keygen 명령의 출력을 표시하고 자동으로 /etc/named.conf 에 추가합니다.

      보조 서버에서도 나중에 명령의 출력이 필요합니다.

    2. /etc/named.conf 파일에서 zone 정의를 편집합니다.

      1. allow-transfer 문에서 서버가 영역을 전송하기 위해 example-transfer-key 문에 지정된 키를 제공해야 함을 정의합니다.

        zone "example.com" {
            ...
            allow-transfer { key example-transfer-key; };
        };

        또는 allow-transfer 문에서 BIND ACL(액세스 제어 목록) nicknames를 사용합니다.

      2. 기본적으로 영역이 업데이트되면 BIND에서 이 영역에 이름 서버(NS) 레코드가 있는 모든 이름 서버에 알립니다. 보조 서버의 NS 레코드를 영역에 추가하지 않으려면 BIND에서 이 서버에 알릴 수 있도록 구성할 수 있습니다. 이를 위해 이 보조 서버의 IP 주소를 포함하는 also-notify 문을 영역에 추가합니다.

        zone "example.com" {
            ...
            also-notify { 192.0.2.2; 2001:db8:1::2; };
        };
    3. /etc/named.conf 파일의 구문을 확인합니다.

      # named-checkconf

      명령에서 출력이 표시되지 않으면 구문이 올바르게 표시됩니다.

    4. BIND를 다시 로드합니다.

      # systemctl reload named

      변경 루트 환경에서 BIND를 실행하는 경우 systemctl reload named-chroot 명령을 사용하여 서비스를 다시 로드합니다.

  2. 향후 보조 서버에서 다음을 수행합니다.

    1. 다음과 같이 /etc/named.conf 파일을 편집합니다.

      1. 기본 서버에서와 동일한 키 정의를 추가합니다.

        key "example-transfer-key" {
                algorithm hmac-sha256;
                secret "q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ=";
        };
      2. /etc/named.conf 파일에 영역 정의를 추가합니다.

        zone "example.com" {
            type slave;
            file "slaves/example.com.zone";
            allow-query { any; };
            allow-transfer { none; };
            masters {
              192.0.2.1 key example-transfer-key;
              2001:db8:1::1 key example-transfer-key;
            };
        };

        이러한 설정 상태:

        • 이 서버는 example.com 영역의 보조 서버(유형 슬레이브)입니다.
        • /var/named/slaves/example.com.zone 파일은 영역 파일입니다. 이 예에서와 같이 상대 경로를 설정하는 경우 이 경로는 options 문에서 디렉터리에 설정한 디렉터리를 기준으로 합니다. 이 서버가 보조 항목인 영역 파일을 기본 항목과 분리하려면 해당 파일을 /var/named/slaves/ 디렉터리에 저장할 수 있습니다.
        • 모든 호스트는 이 영역을 쿼리할 수 있습니다. 또는 IP 범위 또는 ACL 별 이름을 지정하여 액세스를 제한합니다.
        • 어떤 호스트도 이 서버에서 영역을 전송할 수 없습니다.
        • 이 영역의 기본 서버의 IP 주소는 192.0.2.12001:db8:1::2 입니다. 또는 ACL nicknames를 지정할 수 있습니다. 이 보조 서버는 example-transfer-key 라는 키를 사용하여 주 서버에 인증합니다.
    2. /etc/named.conf 파일의 구문을 확인합니다.

      # named-checkconf
    3. BIND를 다시 로드합니다.

      # systemctl reload named

      변경 루트 환경에서 BIND를 실행하는 경우 systemctl reload named-chroot 명령을 사용하여 서비스를 다시 로드합니다.

  3. 선택 사항: 기본 서버에서 영역 파일을 수정하고 새 보조 서버에 대한 NS 레코드를 추가합니다.

검증

보조 서버에서 다음을 수행합니다.

  1. 이름이 지정된 서비스의 systemd 저널 항목을 표시합니다.

    # journalctl -u named
    ...
    Jul 06 15:08:51 ns2.example.com named[2024]: zone example.com/IN: Transfer started.
    Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: connected using 192.0.2.2#45803
    Jul 06 15:08:51 ns2.example.com named[2024]: zone example.com/IN: transferred serial 2022070101
    Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: Transfer status: success
    Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: Transfer completed: 1 messages, 29 records, 2002 bytes, 0.003 secs (667333 bytes/sec)

    변경 루트 환경에서 BIND를 실행하는 경우 journalctl -u named-chroot 명령을 사용하여 저널 항목을 표시합니다.

  2. BIND에서 영역 파일을 생성했는지 확인합니다.

    # ls -l /var/named/slaves/
    total 4
    -rw-r--r--. 1 named named 2736 Jul  6 15:08 example.com.zone

    기본적으로 보조 서버는 영역 파일을 바이너리 원시 형식으로 저장합니다.

  3. 보조 서버에서 전송된 영역의 레코드를 쿼리합니다.

    # dig +short @192.0.2.2 AAAA www.example.com
    2001:db8:1::30

    이 예에서는 이 프로세스에서 설정한 보조 서버가 IP 주소 192.0.2.2 에서 수신 대기한다고 가정합니다.

4.8. DNS 레코드를 재정의하도록 BIND에서 응답 정책 영역 구성

관리자는 DNS 차단 및 필터링을 사용하여 특정 도메인 또는 호스트에 대한 액세스를 차단하도록 DNS 응답을 다시 작성할 수 있습니다. BIND에서 응답 정책 영역(RPZ)은 이 기능을 제공합니다. NXDOMAIN 오류를 반환하거나 쿼리에 응답하지 않는 등 차단된 항목에 대해 다른 작업을 구성할 수 있습니다.

환경에 여러 DNS 서버가 있는 경우 이 절차를 사용하여 기본 서버에서 RPZ를 구성하고 나중에 보조 서버에서 RPZ를 사용하도록 영역 전송을 구성합니다.

사전 요구 사항

  • BIND는 예를 들어 캐싱 이름 서버로 이미 구성되어 있습니다.
  • named 또는 named-chroot 서비스가 실행 중입니다.

절차

  1. /etc/named.conf 파일을 편집하고 다음과 같이 변경합니다.

    1. options 문에 response-policy 정의를 추가합니다.

      options {
          ...
      
          response-policy {
              zone "rpz.local";
          };
      
          ...
      }

      response-policy 에서 zone 문에서 RPZ의 사용자 지정 이름을 설정할 수 있습니다. 그러나 다음 단계의 영역 정의에서 동일한 이름을 사용해야 합니다.

    2. 이전 단계에서 설정한 RPZ의 영역 정의를 추가합니다.

      zone "rpz.local" {
          type master;
          file "rpz.local";
          allow-query { localhost; 192.0.2.0/24; 2001:db8:1::/64; };
          allow-transfer { none; };
      };

      이러한 설정 상태:

      • 이 서버는 rpz.local 이라는 RPZ의 기본 서버(type master)입니다.
      • /var/named/rpz.local 파일은 영역 파일입니다. 이 예에서와 같이 상대 경로를 설정하는 경우 이 경로는 options 문에서 디렉터리에 설정한 디렉터리를 기준으로 합니다.
      • allow-query 에 정의된 모든 호스트는 이 RPZ를 쿼리할 수 있습니다. 또는 IP 범위 또는 BIND 액세스 제어 목록(ACL)을 지정하여 액세스를 제한합니다.
      • 어떤 호스트도 영역을 전송할 수 없습니다. 보조 서버를 설정하는 경우에만 영역 전송을 허용하고 보조 서버의 IP 주소에 대해서만 전송할 수 있습니다.
  2. /etc/named.conf 파일의 구문을 확인합니다.

    # named-checkconf

    명령에서 출력이 표시되지 않으면 구문이 올바르게 표시됩니다.

  3. 예를 들어 다음 콘텐츠를 사용하여 /var/named/rpz.local 파일을 만듭니다.

    $TTL 10m
    @ IN SOA ns1.example.com. hostmaster.example.com. (
                              2022070601 ; serial number
                              1h         ; refresh period
                              1m         ; retry period
                              3d         ; expire time
                              1m )       ; minimum TTL
    
                     IN NS    ns1.example.com.
    
    example.org      IN CNAME .
    *.example.org    IN CNAME .
    example.net      IN CNAME rpz-drop.
    *.example.net    IN CNAME rpz-drop.

    이 영역 파일:

    • 리소스 레코드에 대한 기본 TTL(Time-to-live) 값을 10분으로 설정합니다. 시간별 h 와 같은 시간 접미사가 없으면 BIND에서 값을 초로 해석합니다.
    • 영역에 대한 세부 정보와 함께 필요한 권한 시작(SOA) 리소스 레코드가 포함되어 있습니다.
    • ns1.example.com 을 이 영역에 대한 권한 있는 DNS 서버로 설정합니다. 기능을 사용하려면 영역에 하나 이상의 이름 서버(NS) 레코드가 필요합니다. 그러나 RFC 1912를 준수하려면 두 개 이상의 이름 서버가 필요합니다.
    • 이 도메인의 example.org 및 host로 쿼리하는 NXDOMAIN 오류를 반환합니다.
    • 이 도메인의 example.net 및 호스트에 대한 쿼리를 삭제합니다.

    전체 작업 및 예제 목록은 IETF 초안을 참조하십시오. DNS 응답 정책 영역(RPZ).

  4. /var/named/rpz.local 파일의 구문을 확인합니다.

    # named-checkzone rpz.local /var/named/rpz.local
    zone rpz.local/IN: loaded serial 2022070601
    OK
  5. BIND를 다시 로드합니다.

    # systemctl reload named

    변경 루트 환경에서 BIND를 실행하는 경우 systemctl reload named-chroot 명령을 사용하여 서비스를 다시 로드합니다.

검증

  1. RPZ에 구성된 example.org 에서 호스트 문제를 해결하여 NXDOMAIN 오류를 반환합니다.

    # dig @localhost www.example.org
    ...
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30286
    ...

    이 예에서는 BIND가 동일한 호스트에서 실행되고 localhost 인터페이스의 쿼리에 응답하는 것으로 가정합니다.

  2. RPZ에 구성된 example.net 도메인에서 호스트 확인을 시도하여 쿼리를 삭제합니다.

    # dig @localhost www.example.net
    ...
    ;; connection timed out; no servers could be reached
    ...

5장. NFS 공유 내보내기

시스템 관리자는 NFS 서버를 사용하여 네트워크를 통해 시스템의 디렉터리를 공유할 수 있습니다.

5.1. NFS 소개

이 섹션에서는 NFS 서비스의 기본 개념을 설명합니다.

NFS(네트워크 파일 시스템)를 사용하면 원격 호스트에서 네트워크를 통해 파일 시스템을 마운트하고 로컬로 마운트된 파일 시스템과 상호 작용할 수 있습니다. 이를 통해 네트워크의 중앙 집중식 서버에 리소스를 통합할 수 있습니다.

NFS 서버는 /etc/exports 구성 파일을 참조하여 내보낸 파일 시스템에 클라이언트에서 액세스할 수 있는지 여부를 확인합니다. 확인되면 모든 파일 및 디렉터리 작업을 사용자가 사용할 수 있습니다.

5.2. 지원되는 NFS 버전

이 섹션에는 Red Hat Enterprise Linux에서 지원되는 NFS 버전과 해당 기능이 나열되어 있습니다.

현재 Red Hat Enterprise Linux 8은 다음과 같은 주요 버전의 NFS를 지원합니다.

  • NFS 버전 3(NFSv3)은 안전한 비동기 쓰기를 지원하며 이전 NFSv2보다 오류 처리 시 더 강력합니다. 64비트 파일 크기 및 오프셋도 지원하므로 클라이언트가 2GB 이상의 파일 데이터에 액세스할 수 있습니다.
  • NFS 버전 4(NFSv4)는 방화벽 및 인터넷에서 작동하며 더 이상 rpcbind 서비스가 필요하지 않으며 ACL(액세스 제어 목록)을 지원하며 상태 저장 작업을 활용합니다.

NFS 버전 2(NFSv2)는 Red Hat에서 더 이상 지원하지 않습니다.

기본 NFS 버전

Red Hat Enterprise Linux 8의 기본 NFS 버전은 4.2입니다. NFS 클라이언트는 기본적으로 NFSv4.2를 사용하여 마운트를 시도하고 서버가 NFSv4.2를 지원하지 않는 경우 NFSv4.1로 대체합니다. 나중에 마운트는 NFSv4.0으로 대체되고 NFSv3로 대체됩니다.

마이너 NFS 버전의 기능

다음은 Red Hat Enterprise Linux 8의 NFSv4.2의 기능입니다.

서버 측 복사
copy _file_range() 시스템 호출을 사용하여 NFS 클라이언트가 네트워크 리소스를 낭비하지 않고 데이터를 효율적으로 복사할 수 있습니다.
스파스 파일
파일에는 0으로만 구성된 할당되지 않았거나 초기화되지 않은 데이터 블록이 있는 하나 이상의 취약점이 있습니다. NFSv4.2의 lseek() seek_ data() 작업은 애플리케이션이 스파스 파일의 취약점 위치를 매핑할 수 있도록 합니다.
공간 예약
스토리지 서버가 여유 공간을 예약하도록 허용하여 서버가 공간이 부족해지는 것을 금지합니다. NFSv4.2에서는 공간을 예약하기 위한 assign () 작업, 공간을 예약 해제하는 deallocate() 작업, fallocate() 작업을 지원하여 파일의 공간을 사전 할당하거나 배분 할 수 있습니다.
레이블이 지정된 NFS
데이터 액세스 권한을 적용하고 NFS 파일 시스템의 개별 파일에 대해 클라이언트와 서버 간에 SELinux 레이블을 활성화합니다.
레이아웃 개선 사항
일부 병렬 NFS(pNFS) 서버가 더 나은 성능 통계를 수집할 수 있도록 하는 layoutstats() 작업을 제공합니다.

NFSv4.1의 기능은 다음과 같습니다.

  • 네트워크의 성능 및 보안을 향상시키고 pNFS에 대한 클라이언트측 지원도 포함합니다.
  • 콜백에 대해 더 이상 별도의 TCP 연결이 필요하지 않으므로, NFS 서버가 클라이언트에 연결할 수 없는 경우에도 위임을 허용할 수 있습니다(예: NAT 또는 방화벽이 방해하는 경우).
  • 은 의미 체계(부팅 작업 제외)를 정확히 한 번 제공합니다. 이전 문제로 인해 응답이 손실되고 작업이 두 번 전송된 경우 특정 작업에서 부정확한 결과를 반환하는 경우가 있었습니다.

5.3. NFSv3 및 NFSv4의 TCP 및 UDP 프로토콜

NFSv4에는 IP 네트워크를 통해 실행되는 TCP(Transmission Control Protocol)가 필요합니다.

NFSv3에서는 이전 Red Hat Enterprise Linux 버전에서 UDP(User Datagram Protocol)를 사용할 수도 있습니다. Red Hat Enterprise Linux 8에서는 UDP를 통한 NFS가 더 이상 지원되지 않습니다. 기본적으로 UDP는 NFS 서버에서 비활성화되어 있습니다.

5.4. NFS에 필요한 서비스

이 섹션에는 NFS 서버 실행 또는 NFS 공유 마운트에 필요한 시스템 서비스가 나열되어 있습니다. Red Hat Enterprise Linux는 이러한 서비스를 자동으로 시작합니다.

Red Hat Enterprise Linux는 커널 수준 지원 및 서비스 프로세스의 조합을 사용하여 NFS 파일 공유를 제공합니다. 모든 NFS 버전은 클라이언트와 서버 간에 RPC(원격 프로시저 호출)를 사용합니다. NFS 파일 시스템을 공유하거나 마운트하기 위해 구현된 NFS 버전에 따라 다음 서비스가 함께 작동합니다.

nfsd
공유 NFS 파일 시스템에 요청하는 NFS 서버 커널 모듈입니다.
rpcbind
로컬 RPC 서비스에서 포트 예약을 허용합니다. 그런 다음 이러한 포트가 사용 가능하게 만들어 해당 원격 RPC 서비스에서 액세스할 수 있습니다. rpcbind 서비스는 RPC 서비스에 대한 요청에 응답하고 요청된 RPC 서비스에 대한 연결을 설정합니다. NFSv4에서는 사용되지 않습니다.
rpc.mountd
이 프로세스는 NFS 서버가 NFSv3 클라이언트의 MOUNT 요청을 처리하는 데 사용됩니다. 요청된 NFS 공유를 현재 NFS 서버에서 내보내고 있고 클라이언트가 액세스할 수 있는지 확인합니다. 마운트 요청이 허용되는 경우 nfs 마운트 서비스가 Success 상태로 응답하고 이 NFS 공유에 대한 File-Handle을 다시 NFS 클라이언트로 제공합니다.
rpc.nfsd
이 프로세스를 통해 서버에서 알리는 명시적 NFS 버전 및 프로토콜을 사용할 수 있습니다. NFS 클라이언트가 연결할 때마다 서버 스레드를 제공하는 등 NFS 클라이언트의 동적 요구를 충족하기 위해 Linux 커널과 호환됩니다. 이 프로세스는 nfs-server 서비스에 해당합니다.
lockd
클라이언트와 서버에서 모두 실행되는 커널 스레드입니다. NFSv3 클라이언트가 서버의 파일을 잠글 수 있는 NLM(Network Lock Manager) 프로토콜을 구현합니다. NFS 서버가 실행될 때마다 NFS 파일 시스템이 마운트될 때마다 자동으로 시작됩니다.
rpc.statd
이 프로세스에서는 정상적으로 중단되지 않고 NFS 서버를 다시 시작할 때 NFS 클라이언트에 알리는 NSM(Network Status Monitor) RPC 프로토콜을 구현합니다. rpc-statd 서비스는 nfs-server 서비스에 의해 자동으로 시작되며 사용자 구성이 필요하지 않습니다. NFSv4에서는 사용되지 않습니다.
rpc.rquotad
이 프로세스는 원격 사용자에 대한 사용자 할당량 정보를 제공합니다. quota-rpc 패키지에서 제공하는 RuntimeClass-rquotad 서비스는 nfs-server 가 시작될 때 사용자가 시작해야 합니다.
rpc.idmapd

이 프로세스는 유선 NFSv4 이름( 사용자@도메인형식의 문자열)과 로컬 UID 및 GID 간에 매핑되는 NFSv4 클라이언트 및 서버 upcall을 제공합니다. NFSv4에서 idmapd 가 작동하려면 /etc/idmapd.conf 파일을 구성해야 합니다. NFSv4 매핑 도메인을 정의하는 Domain 매개 변수를 최소한 지정해야 합니다. NFSv4 매핑 도메인이 DNS 도메인 이름과 같은 경우 이 매개 변수를 건너뛸 수 있습니다. ID 매핑이 제대로 작동하려면 클라이언트와 서버가 NFSv4 매핑 도메인에 동의해야 합니다.

NFSv4 서버만 rpc.idmapd 를 사용하며 nfs-idmapd 서비스에 의해 시작됩니다. NFSv4 클라이언트는 ID 매핑을 수행하기 위해 온디맨드 커널에서 호출하는 인증 키 기반 nfsidmap 유틸리티를 사용합니다. nfsidmap 에 문제가 있는 경우 클라이언트는 rpc.idmapd를 사용하도록 대체합니다.

NFSv4를 사용한 RPC 서비스

마운트 및 잠금 프로토콜이 NFSv4 프로토콜에 통합되었습니다. 서버는 또한 잘 알려진 TCP 포트 2049에서 수신 대기합니다. 따라서 NFSv4는 rpcbind,lockd, rpc -statd 서비스와 상호 작용할 필요가 없습니다. NFS 서버에서 내보내기를 설정하려면 nfs-mountd 서비스가 계속 필요하지만 유선 작업에는 적용되지 않습니다.

5.5. NFS 호스트 이름 형식

이 섹션에서는 NFS 공유를 마운트하거나 내보낼 때 호스트를 지정하는 데 사용할 수 있는 다양한 형식을 설명합니다.

다음 형식으로 호스트를 지정할 수 있습니다.

단일 머신

다음 중 하나:

  • 정규화된 도메인 이름(서버가 확인할 수 있음)
  • 호스트 이름(서버가 확인할 수 있음)
  • IP 주소.
IP 네트워크

다음 형식 중 하나가 유효합니다.

  • a.b.c.d/z. 여기서 a.b.c.d 는 네트워크이고 z 는 넷마스크의 비트 수입니다(예: 192.168.0.0/24 ).
  • a.b.c.d/netmask (예: a.b.c.d 는 네트워크이고 넷마스크 는 넷마스크입니다(예: 192.168.100.8/255.255.255.0 ).
넷그룹
@group-name 형식 . 여기서 group-name 은 NIS 네트워크 그룹 이름입니다.

5.6. NFS 서버 구성

이 섹션에서는 NFS 서버에서 내보내기를 구성하는 두 가지 방법의 구문과 옵션에 대해 설명합니다.

  • /etc/exports 설정 파일 수동 편집
  • 명령줄에서 exportfs 유틸리티 사용

5.6.1. /etc/exports 구성 파일

/etc/exports 파일은 원격 호스트로 내보낼 파일 시스템을 제어하고 옵션을 지정합니다. 다음 구문 규칙을 따릅니다.

  • 빈 행은 무시됩니다.
  • 주석을 추가하려면 해시 표시(#)로 행을 시작합니다.
  • 긴 줄을 백슬래시(\)로 래핑할 수있습니다.
  • 내보낸 각 파일 시스템은 개별 행에 있어야 합니다.
  • 내보낸 파일 시스템 다음에 배치된 권한 있는 호스트 목록은 공백 문자로 구분해야 합니다.
  • 각 호스트에 대한 옵션은 호스트 및 첫 번째 괄호를 구분하는 공백 없이 호스트 식별자 뒤에 직접 괄호 안에 배치해야 합니다.
내보내기 항목

내보낸 파일 시스템의 각 항목에는 다음과 같은 구조가 있습니다.

export host(options)

또한 각 호스트에 대한 특정 옵션과 함께 여러 호스트를 지정할 수도 있습니다. 이렇게 하려면 다음과 같이 각 호스트 이름과 해당 옵션( 괄호 안 포함)을 공백으로 구분된 목록과 같은 행에 나열합니다.

export host1(options1) host2(options2) host3(options3)

이 구조에서 다음을 수행합니다.

export
디렉토리를 내보내고 있습니다
호스트
내보내기를 공유할 호스트 또는 네트워크
옵션
호스트에 사용할 옵션

예 5.1. 간단한 /etc/exports 파일

가장 간단한 형식의 /etc/exports 파일은 내보낸 디렉토리만 지정하고 호스트는 액세스하도록 허용했습니다.

/exported/directory bob.example.com

여기에서 bob.example.com 은 NFS 서버에서 /exported/directory/ 를 마운트할 수 있습니다. 이 예에서는 옵션을 지정하지 않으므로 NFS는 기본 옵션을 사용합니다.

중요

/etc/exports 파일의 형식은 특히 공백 문자를 사용하는 것과 관련하여 매우 정확합니다. 공백 문자를 사용하여 호스트와 호스트에서 내보낸 파일 시스템을 항상 분리해야 합니다. 그러나 주석 행을 제외하고 파일에 다른 공백 문자가 없어야 합니다.

예를 들어 다음 두 행은 동일한 것을 의미하지 않습니다.

/home bob.example.com(rw)
/home bob.example.com (rw)

첫 번째 줄에서는 bob.example.com 의 사용자만 /home 디렉토리에 대해 읽고 쓸 수 있습니다. 두 번째 행에서는 bob.example.com 의 사용자가 디렉토리를 읽기 전용(기본값)으로 마운트할 수 있지만 나머지 world는 읽기/쓰기로 마운트할 수 있습니다.

기본 옵션

내보내기 항목의 기본 옵션은 다음과 같습니다.

ro
내보낸 파일 시스템은 읽기 전용입니다. 원격 호스트는 파일 시스템에서 공유된 데이터를 변경할 수 없습니다. 호스트가 파일 시스템(즉, 읽기 및 쓰기)을 변경할 수 있도록 하려면 rw 옵션을 지정합니다.
sync
이전 요청의 변경 사항을 디스크에 작성하기 전에 NFS 서버는 요청에 응답하지 않습니다. 대신 비동기 쓰기를 활성화하려면 async 옵션을 지정합니다.
Wdelay
다른 쓰기 요청이 임박한 것으로 의심되는 경우 NFS 서버는 디스크에 쓰기를 지연합니다. 이렇게 하면 별도의 쓰기 명령으로 디스크에 액세스해야 하는 횟수가 줄어들기 때문에 성능이 향상되어 쓰기 오버헤드가 줄어듭니다. 이 설정을 비활성화하려면 기본 동기화 옵션도 지정된 경우에만 사용할 수 있는 no_wdelay 옵션을 지정합니다.
root_squash

이렇게 하면 로컬에서 원격으로 연결된 root 사용자가 root 권한을 가지지 못하도록 합니다. 대신 NFS 서버는 사용자 ID nobody 를 할당합니다. 이를 통해 원격 루트 사용자의 기능과 가장 낮은 로컬 사용자에 대한 강력한 기능을 효과적으로 "비지정"하여 원격 서버에서 무단 쓰기를 방지합니다. 루트 스쿼시를 비활성화하려면 no_root_squash 옵션을 지정합니다.

모든 원격 사용자(root 포함)를 스쿼시하려면 all_squash 옵션을 사용합니다. NFS 서버가 특정 호스트의 원격 사용자에게 할당해야 하는 사용자 및 그룹 ID를 지정하려면 다음과 같이 anonuidanongid 옵션을 각각 사용합니다.

export host(anonuid=uid,anongid=gid)

여기서 uidgid 는 각각 사용자 ID 번호와 그룹 ID 번호입니다. anonuidanongid 옵션을 사용하면 원격 NFS 사용자가 공유할 수 있는 특수 사용자 및 그룹 계정을 만들 수 있습니다.

기본적으로 ACL(액세스 제어 목록)은 Red Hat Enterprise Linux의 NFS에서 지원합니다. 이 기능을 비활성화하려면 파일 시스템을 내보낼 때 no_acl 옵션을 지정합니다.

기본 및 재정의된 옵션

내보낸 모든 파일 시스템에 대한 각 기본값은 명시적으로 재정의해야 합니다. 예를 들어 rw 옵션이 지정되지 않은 경우 내보낸 파일 시스템은 읽기 전용으로 공유됩니다. 다음은 두 가지 기본 옵션을 재정의하는 /etc/exports 의 샘플 행입니다.

/another/exported/directory 192.168.0.3(rw,async)

이 예에서 192.168.0.3/another/exported/directory/ 읽기 및 쓰기를 마운트할 수 있으며 디스크에 대한 모든 쓰기는 비동기식입니다.

5.6.2. exportfs 유틸리티

exportfs 유틸리티를 사용하면 루트 사용자가 NFS 서비스를 다시 시작하지 않고 선택적으로 디렉토리를 내보내거나 내보내기 해제할 수 있습니다. 적절한 옵션이 지정된 경우 exportfs 유틸리티는 내보낸 파일 시스템을 /var/lib/nfs/xtab 에 씁니다. nfs-mountd 서비스는 파일 시스템에 대한 액세스 권한을 결정할 때 xtab 파일을 참조하므로 내보낸 파일 시스템 목록에 대한 변경 사항이 즉시 적용됩니다.

공통 exportfs 옵션

다음은 exportfs 에 일반적으로 사용되는 옵션 목록입니다.

-r
/ var/lib/nfs/etab에 새 내보내기 목록을 구성하여 /etc/ exports 에 나열된 모든 디렉토리를 내보냅니다. 이 옵션은 /etc/exports 에 대한 변경 사항을 적용하여 내보내기 목록을 효과적으로 새로 고칩니다.
-a
export fs로 전달되는 다른 옵션에 따라 모든 디렉토리를 내보내거나 내보내기 해제합니다. 다른 옵션을 지정하지 않으면 exportfs/etc/exports 에 지정된 모든 파일 시스템을 내보냅니다.
-o file-systems
/etc/exports 에 나열되지 않은 내보낼 디렉토리를 지정합니다. file-systems 를 내보낼 추가 파일 시스템으로 바꿉니다. 이러한 파일 시스템은 /etc/exports 에 지정된 것과 동일한 방식으로 포맷해야 합니다. 이 옵션은 내보낸 파일 시스템 목록에 영구적으로 추가하기 전에 내보낸 파일 시스템을 테스트하는 데 주로 사용됩니다.
-i
/etc/exports 를 무시합니다. 명령줄에서 제공되는 옵션만 내보낸 파일 시스템을 정의하는 데 사용됩니다.
-u
모든 공유 디렉토리 내보내기 해제. exportfs - solve 명령은 모든 NFS 서비스를 유지하면서 NFS 파일 공유를 일시 중지합니다. NFS 공유를 다시 활성화하려면 exportfs -r 을 사용합니다.
-v
exportfs 명령을 실행할 때 파일 시스템을 내보내거나 내보내지 않은 파일 시스템을 자세히 표시하는 자세한 작업입니다.

옵션을 exportfs 유틸리티로 전달하지 않으면 현재 내보낸 파일 시스템 목록이 표시됩니다.

추가 리소스

5.7. NFS 및 rpcbind

이 섹션에서는 NFSv3에 필요한 rpcbind 서비스의 목적에 대해 설명합니다.

rpcbind 서비스는 RPC(원격 프로시저 호출) 서비스를 수신 대기하는 포트에 매핑합니다. RPC 프로세스는 시작 시 rpcbind에 알리고, 수신 대기 중인 포트를 등록하고, 제공할 것으로 예상되는 RPC 프로그램 번호를 등록합니다. 클라이언트 시스템은 서버의 rpcbind 에 특정 RPC 프로그램 번호를 사용하여 연결합니다. rpcbind 서비스는 클라이언트를 적절한 포트 번호로 리디렉션하여 요청된 서비스와 통신할 수 있도록 합니다.

RPC 기반 서비스는 들어오는 클라이언트 요청과 관련된 모든 연결을 만들기 위해 rpcbind 를 사용하므로 이러한 서비스가 시작되기 전에 rpcbind 를 사용할 수 있어야 합니다.

rpcbind 의 액세스 제어 규칙은 모든 RPC 기반 서비스에 영향을 미칩니다. 또는 각 NFS RPC 데몬에 대한 액세스 제어 규칙을 지정할 수도 있습니다.

추가 리소스

  • rpc.mountd(8) man page
  • rpc.statd(8) man page

5.8. NFS 설치

이 절차에서는 NFS 공유를 마운트하거나 내보내는 데 필요한 모든 패키지를 설치합니다.

절차

  • nfs-utils 패키지를 설치합니다.

    # yum install nfs-utils

5.9. NFS 서버 시작

다음 절차에서는 NFS 공유를 내보내는 데 필요한 NFS 서버를 시작하는 방법을 설명합니다.

사전 요구 사항

  • NFSv3 연결을 지원하는 서버의 경우 N etNamespacebind 서비스가 실행되고 있어야 합니다. rpcbind 가 활성 상태인지 확인하려면 다음 명령을 사용합니다.

    $ systemctl status rpcbind

    서비스가 중지되면 서비스를 시작하고 활성화합니다.

    $ systemctl enable --now rpcbind

절차

  • NFS 서버를 시작하고 부팅 시 자동으로 시작되도록 활성화하려면 다음 명령을 사용합니다.

    # systemctl enable --now nfs-server

추가 리소스

5.10. NFS 및 rpcbind 문제 해결

rpcbind 서비스는 RPC 서비스와 통신에 사용되는 포트 번호 간의 조정을 제공하므로 문제 해결 시 rpcbind 를 사용하여 현재 RPC 서비스의 상태를 확인하는 것이 유용합니다. rpcinfo 유틸리티는 포트 번호, RPC 프로그램 번호, 버전 번호 및 IP 프로토콜 유형(TCP 또는 UDP)이 있는 각 RPC 기반 서비스를 보여줍니다.

절차

  1. rpcbind 에 적절한 NFS RPC 기반 서비스가 활성화되어 있는지 확인하려면 다음 명령을 사용합니다.

    # rpcinfo -p

    예 5.2. rpcinfo -p 명령 출력

    다음은 이 명령의 샘플 출력입니다.

       program vers proto   port  service
        100000    4   tcp    111  portmapper
        100000    3   tcp    111  portmapper
        100000    2   tcp    111  portmapper
        100000    4   udp    111  portmapper
        100000    3   udp    111  portmapper
        100000    2   udp    111  portmapper
        100005    1   udp  20048  mountd
        100005    1   tcp  20048  mountd
        100005    2   udp  20048  mountd
        100005    2   tcp  20048  mountd
        100005    3   udp  20048  mountd
        100005    3   tcp  20048  mountd
        100024    1   udp  37769  status
        100024    1   tcp  49349  status
        100003    3   tcp   2049  nfs
        100003    4   tcp   2049  nfs
        100227    3   tcp   2049  nfs_acl
        100021    1   udp  56691  nlockmgr
        100021    3   udp  56691  nlockmgr
        100021    4   udp  56691  nlockmgr
        100021    1   tcp  46193  nlockmgr
        100021    3   tcp  46193  nlockmgr
        100021    4   tcp  46193  nlockmgr

    NFS 서비스 중 하나가 올바르게 시작되지 않으면 rpcbind 는 클라이언트의 RPC 요청을 해당 서비스에 대한 RPC 요청을 올바른 포트에 매핑할 수 없습니다.

  2. 대부분의 경우 NFS가 rpcinfo 출력에 없는 경우 NFS를 다시 시작하면 서비스가 rpcbind 에 올바르게 등록되고 작업을 시작합니다.

    # systemctl restart nfs-server

추가 리소스

5.11. 방화벽 뒤에서 실행되도록 NFS 서버 구성

NFS에는 RPC 서비스에 대한 포트를 동적으로 할당하고 방화벽 규칙을 구성하는 문제를 일으킬 수 있는 rpcbind 서비스가 필요합니다. 다음 섹션에서는 지원하려는 경우 방화벽에서 작동하도록 NFS 버전을 구성하는 방법을 설명합니다.

  • NFSv3

    여기에는 NFSv3를 지원하는 모든 서버가 포함됩니다.

    • NFSv3- 전용 서버
    • NFSv3 및 NFSv4를 모두 지원하는 서버
  • NFSv4-전용

5.11.1. 방화벽 뒤에서 실행되도록 NFSv3- 사용 서버 구성

다음 절차에서는 방화벽 뒤에서 실행되도록 NFSv3를 지원하는 서버를 구성하는 방법을 설명합니다. 여기에는 NFSv3 및 NFSv4를 모두 지원하는 NFSv3 전용 서버 및 서버가 포함됩니다.

절차

  1. 클라이언트가 방화벽 뒤에서 NFS 공유에 액세스할 수 있도록 하려면 NFS 서버에서 다음 명령을 실행하여 방화벽을 구성합니다.

    firewall-cmd --permanent --add-service mountd
    firewall-cmd --permanent --add-service rpc-bind
    firewall-cmd --permanent --add-service nfs
  2. 다음과 같이 /etc/nfs.conf 파일에서 RPC 서비스 nlockmgr 에서 사용할 포트를 지정합니다.

    [lockd]
    
    port=tcp-port-number
    udp-port=udp-port-number

    또는 /etc/modprobe.d/lockd.conf 파일에 nlm_tcpportnlm_udpport를 지정할 수 있습니다.

  3. NFS 서버에서 다음 명령을 실행하여 방화벽에서 지정된 포트를 엽니다.

    firewall-cmd --permanent --add-port=<lockd-tcp-port>/tcp
    firewall-cmd --permanent --add-port=<lockd-udp-port>/udp
  4. 다음과 같이 /etc/nfs . conf 파일의 [statd] 섹션을 편집하여 alice.statd에 대한 정적 포트를 추가합니다.

    [statd]
    
    port=port-number
  5. NFS 서버에서 다음 명령을 실행하여 방화벽에서 추가된 포트를 엽니다.

    firewall-cmd --permanent --add-port=<statd-tcp-port>/tcp
    firewall-cmd --permanent --add-port=<statd-udp-port>/udp
  6. 방화벽 구성을 다시 로드합니다.

    firewall-cmd --reload
  7. 먼저 rpc-statd 서비스를 다시 시작한 다음 nfs-server 서비스를 다시 시작합니다.

    # systemctl restart rpc-statd.service
    # systemctl restart nfs-server.service

    또는 /etc/modprobe.d/lockd.conf 파일에 lockd 포트를 지정한 경우:

    1. /proc/sys/fs/nfs/nlm_tcpport/proc/sys/fs/nfs/nlm_udpport 의 현재 값을 업데이트합니다.

      # sysctl -w fs.nfs.nlm_tcpport=<tcp-port>
      # sysctl -w fs.nfs.nlm_udpport=<udp-port>
    2. rpc-statdnfs-server 서비스를 다시 시작합니다.

      # systemctl restart rpc-statd.service
      # systemctl restart nfs-server.service

5.11.2. 방화벽 뒤에서 실행되도록 NFSv4 전용 서버 구성

다음 절차에서는 방화벽 뒤에서 실행되도록 NFSv4 전용 서버를 구성하는 방법을 설명합니다.

절차

  1. 클라이언트가 방화벽 뒤에서 NFS 공유에 액세스할 수 있도록 하려면 NFS 서버에서 다음 명령을 실행하여 방화벽을 구성합니다.

    firewall-cmd --permanent --add-service nfs
  2. 방화벽 구성을 다시 로드합니다.

    firewall-cmd --reload
  3. nfs-server를 다시 시작합니다.

    # systemctl restart nfs-server

5.11.3. 방화벽 뒤에서 실행되도록 NFSv3 클라이언트 구성

방화벽 뒤에서 실행되도록 NFSv3 클라이언트를 구성하는 절차는 방화벽 뒤에서 실행되도록 NFSv3 서버를 구성하는 절차와 유사합니다.

구성 중인 시스템이 NFS 클라이언트와 NFS 서버 둘 다인 경우, NFSv3- 사용 서버 구성에 설명된 절차에 따라 방화벽 뒤에서 실행됩니다.

다음 절차에서는 방화벽 뒤에서 실행하기 위해서만 NFS 클라이언트인 시스템을 구성하는 방법을 설명합니다.

절차

  1. 클라이언트가 방화벽 뒤에 있을 때 NFS 서버가 NFS 클라이언트에 콜백을 수행할 수 있도록 하려면 NFS 클라이언트에서 다음 명령을 실행하여 방화벽에 CHAP -bind 서비스를 추가합니다.

    firewall-cmd --permanent --add-service rpc-bind
  2. 다음과 같이 /etc/nfs.conf 파일에서 RPC 서비스 nlockmgr 에서 사용할 포트를 지정합니다.

    [lockd]
    
    port=port-number
    udp-port=upd-port-number

    또는 /etc/modprobe.d/lockd.conf 파일에 nlm_tcpportnlm_udpport를 지정할 수 있습니다.

  3. NFS 클라이언트에서 다음 명령을 실행하여 방화벽에서 지정된 포트를 엽니다.

    firewall-cmd --permanent --add-port=<lockd-tcp-port>/tcp
    firewall-cmd --permanent --add-port=<lockd-udp-port>/udp
  4. 다음과 같이 /etc/nfs . conf 파일의 [statd] 섹션을 편집하여 alice.statd에 대한 정적 포트를 추가합니다.

    [statd]
    
    port=port-number
  5. NFS 클라이언트에서 다음 명령을 실행하여 방화벽에서 추가된 포트를 엽니다.

    firewall-cmd --permanent --add-port=<statd-tcp-port>/tcp
    firewall-cmd --permanent --add-port=<statd-udp-port>/udp
  6. 방화벽 구성을 다시 로드합니다.

    firewall-cmd --reload
  7. rpc-statd 서비스를 다시 시작합니다.

    # systemctl restart rpc-statd.service

    또는 /etc/modprobe.d/lockd.conf 파일에 lockd 포트를 지정한 경우:

    1. /proc/sys/fs/nfs/nlm_tcpport/proc/sys/fs/nfs/nlm_udpport 의 현재 값을 업데이트합니다.

      # sysctl -w fs.nfs.nlm_tcpport=<tcp-port>
      # sysctl -w fs.nfs.nlm_udpport=<udp-port>
    2. rpc-statd 서비스를 다시 시작합니다.

      # systemctl restart rpc-statd.service

5.11.4. 방화벽 뒤에서 실행되도록 NFSv4 클라이언트 구성

클라이언트가 NFSv4.0을 사용하는 경우에만 이 절차를 수행하십시오. 이 경우 NFSv4.0 콜백용 포트를 열어야 합니다.

이후 프로토콜 버전에서는 서버가 클라이언트에서 시작한 동일한 연결에서 콜백을 수행하기 때문에 NFSv4.1 이상에는 이 절차가 필요하지 않습니다.

절차

  1. NFSv4.0 콜백이 방화벽을 통과하도록 허용하려면 /proc/sys/fs/nfs_callback_tcpport를 설정하고 서버가 다음과 같이 클라이언트의 해당 포트에 연결할 수 있습니다.

    # echo "fs.nfs.nfs_callback_tcpport = <callback-port>" >/etc/sysctl.d/90-nfs-callback-port.conf
    # sysctl -p /etc/sysctl.d/90-nfs-callback-port.conf
  2. NFS 클라이언트에서 다음 명령을 실행하여 방화벽에서 지정된 포트를 엽니다.

    firewall-cmd --permanent --add-port=<callback-port>/tcp
  3. 방화벽 구성을 다시 로드합니다.

    firewall-cmd --reload

5.12. 방화벽을 통해 RPC 할당량 내보내기

디스크 할당량을 사용하는 파일 시스템을 내보내는 경우 할당량 RPC(원격 프로시저 호출) 서비스를 사용하여 NFS 클라이언트에 디스크 할당량 데이터를 제공할 수 있습니다.

절차

  1. rpc-rquotad 서비스를 활성화하고 시작합니다.

    # systemctl enable --now rpc-rquotad
    참고

    rpc-rquotad 서비스는 활성화된 경우 nfs-server 서비스를 시작한 후 자동으로 시작됩니다.

  2. 할당량 RPC 서비스를 방화벽 뒤에서 액세스할 수 있도록 하려면 TCP(또는 UDP가 활성화된 경우 UDP) 포트 875를 열어야 합니다. 기본 포트 번호는 /etc/services 파일에 정의됩니다.

    /etc/sysconfig/rpc -rquotad 파일의 RPCRQUOTADOPTS 변수에 -p port- number 를 추가하여 기본 포트 번호를 재정의할 수 있습니다.

  3. 기본적으로 원격 호스트는 할당량만 읽을 수 있습니다. 클라이언트가 할당량을 설정할 수 있도록 허용하려면 /etc/sysconfig/rpc-rquotad 파일의 RPCRQUOTADOPTS 변수에 -S 옵션을 추가합니다.
  4. /etc/sysconfig/rpc-rquotad 파일의 변경 사항을 적용하려면 rpc-rquotad를 다시 시작하십시오.

    # systemctl restart rpc-rquotad

5.13. NFSoRDMA(NFS over RDMA) 활성화

RDMA(Remote Direct Memory Access) 서비스는 Red Hat Enterprise Linux 8의 RDMA 가능 하드웨어에서 자동으로 작동합니다.

절차

  1. rdma-core 패키지를 설치합니다.

    # yum install rdma-core
  2. /etc/rdma/modules/rdma.conf 파일에서 xprtrdmasvcrdma 가 있는 행을 주석 처리했는지 확인합니다.

    # NFS over RDMA client support
    xprtrdma
    # NFS over RDMA server support
    svcrdma
  3. NFS 서버에서 디렉토리 /mnt/nfsordma 를 만들고 /etc/exports 로 내보냅니다.

    # mkdir /mnt/nfsordma
    # echo "/mnt/nfsordma *(fsid=0,rw,async,insecure,no_root_squash)" >> /etc/exports
  4. NFS 클라이언트에서 서버 IP 주소(예: 172.31.0.186)를 사용하여 nfs-share를 마운트합니다.

    # mount -o rdma,port=20049 172.31.0.186:/mnt/nfs-share /mnt/nfs
  5. nfs-server 서비스를 다시 시작합니다.

    # systemctl restart nfs-server

추가 리소스

5.14. 추가 리소스

6장. NFS 보안

NFS 보안 위험을 최소화하고 서버에서 데이터를 보호하려면 서버에서 NFS 파일 시스템을 내보내거나 클라이언트에 마운트할 때 다음 섹션을 고려하십시오.

6.1. AUTH_SYS 및 내보내기 컨트롤을 사용한 NFS 보안

NFS는 내보낸 파일에 대한 액세스를 제어하기 위해 다음과 같은 기존 옵션을 제공합니다.

  • 서버는 IP 주소 또는 호스트 이름으로 파일 시스템을 마운트할 수 있는 호스트를 제한합니다.
  • 서버는 로컬 사용자에 대해 수행하는 것과 동일한 방식으로 NFS 클라이언트의 사용자에 대해 파일 시스템 권한을 적용합니다. 일반적으로 NFS는 클라이언트에 따라 사용자의 UID 및 GID를 명시하는 AUTH_SYS호출 메시지(AUTH_UNIX 라고도 함)를 사용하여 이 작업을 수행합니다. 이는 악의적이거나 잘못 구성된 클라이언트가 이 문제를 쉽게 해결할 수 있으며 사용자가 그렇지 않아야 하는 파일에 액세스할 수 있음을 의미합니다.

잠재적인 위험을 제한하기 위해 관리자는 액세스를 일반 사용자 및 그룹 ID로 읽기 전용 또는 스쿼시 사용자 권한으로 제한하는 경우가 많습니다. 안타깝게도 이러한 솔루션은 원래 의도했던 방식으로 NFS 공유를 사용하지 못하게 합니다.

또한 공격자가 NFS 파일 시스템을 내보내는 시스템에서 사용하는 DNS 서버를 제어하는 경우 특정 호스트 이름 또는 정규화된 도메인 이름과 관련된 시스템을 무단 시스템으로 가리킬 수 있습니다. 이 시점에서는 NFS 마운트에 대한 추가 보안을 제공하기 위해 사용자 이름 또는 암호 정보가 교환되지 않으므로 NFS 공유를 마운트할 수 있는 시스템이 허용되지 않습니다.

NFS를 통해 디렉토리를 내보낼 때 와일드카드를 사용하여 의도한 것보다 더 많은 시스템을 포함시킬 수 있으므로 와일드카드를 사용해야 합니다.

추가 리소스

  • NFS 및 rpcbind 를 보호하려면 다음을 사용합니다 (예: nftablesfirewalld ).
  • nft(8) 매뉴얼 페이지
  • firewalld-cmd(1) 매뉴얼 페이지

6.2. AUTH_GSS를 사용한 NFS 보안

모든 버전의 NFS는 RPCSEC_GSS 및 Kerberos 메커니즘을 지원합니다.

AUTH_SYS와 달리 RPCSEC_GSS Kerberos 메커니즘과 달리 서버는 클라이언트에 의존하지 않고 어떤 사용자가 파일에 액세스하는지 올바르게 나타냅니다. 대신 암호화는 서버에 사용자를 인증하는 데 사용되며 악의적인 클라이언트가 사용자의 Kerberos 자격 증명을 사용하지 않고도 사용자를 가장하지 못하게 합니다. RPCSEC_GSS Kerberos 메커니즘을 사용하는 것은 Kerberos를 설정한 후 추가 설정이 필요하지 않기 때문에 마운트를 보호하는 가장 간단한 방법입니다.

6.3. Kerberos를 사용하도록 NFS 서버 및 클라이언트 구성

Kerberos는 대칭 암호화와 신뢰할 수 있는 타사인 KDC를 사용하여 클라이언트와 서버가 서로 인증할 수 있는 네트워크 인증 시스템입니다. Red Hat은 IdM(Identity Management)을 사용하여 Kerberos를 설정하는 것이 좋습니다.

사전 요구 사항

  • KDC(Kerberos Key Distribution Centre)가 설치 및 구성되어 있습니다.

절차

    • NFS 서버 측에서 nfs/hostname.domain@REALM 주체를 생성합니다.
    • 서버와 클라이언트 측 모두에서 host/hostname.domain@REALM 주체를 생성합니다.
    • 클라이언트 및 서버의 키탭에 해당 키를 추가합니다.
  1. 서버 측에서 sec= 옵션을 사용하여 원하는 보안 플레이버를 활성화합니다. 모든 보안 플레이버 및 비 암호화 마운트를 활성화하려면 다음을 수행합니다.

    /export *(sec=sys:krb5:krb5i:krb5p)

    sec= 옵션과 함께 사용할 유효한 보안 플레이버는 다음과 같습니다.

    • sys: 암호화 보호 없음, 기본값
    • krb5: 인증 전용
    • krb5i: 무결성 보호

      • 사용자 인증에 Kerberos V5를 사용하고 데이터 변조를 방지하기 위해 보안 체크섬을 사용하여 NFS 작업의 무결성 검사를 수행합니다.
    • krb5p: 개인 정보 보호

      • Kerberos V5를 사용하여 사용자 인증, 무결성 검사 및 NFS 트래픽을 암호화하여 트래픽 스니핑을 방지합니다. 이는 가장 안전한 설정이지만 성능 오버헤드가 가장 많습니다.
  2. 클라이언트 측에서 마운트 옵션에 sec=krb5 (또는 sec=krb5i 또는 sec=krb5p )를 마운트합니다.

    # mount -o sec=krb5 server:/export /mnt

추가 리소스

6.4. NFSv4 보안 옵션

NFSv4에는 Microsoft Windows NT 모델의 기능과 광범위한 배포로 인해 POSIX 모델이 아닌 Microsoft Windows NT 모델을 기반으로 하는 ACL 지원이 포함되어 있습니다.

NFSv4의 또 다른 중요한 보안 기능은 파일 시스템 마운트에 MOUNT 프로토콜 사용을 제거하는 것입니다. MOUNT 프로토콜은 프로토콜에서 파일을 처리하는 방식 때문에 보안 위험이 발생했습니다.

6.5. 마운트된 NFS 내보내기에 대한 파일 권한

NFS 파일 시스템이 원격 호스트에서 읽기 또는 쓰기로 마운트되면 각 공유 파일에 있는 각 공유 파일에 대한 권한만 보호됩니다. 동일한 사용자 ID 값을 공유하는 두 사용자가 다른 클라이언트 시스템에 동일한 NFS 파일 시스템을 마운트하는 경우 서로의 파일을 수정할 수 있습니다. 또한 클라이언트 시스템에서 root로 로그인한 사용자는 su - 명령을 사용하여 NFS 공유의 모든 파일에 액세스할 수 있습니다.

기본적으로 ACL(액세스 제어 목록)은 Red Hat Enterprise Linux의 NFS에서 지원합니다. Red Hat은 이 기능을 계속 사용하도록 권장합니다.

기본적으로 NFS는 파일 시스템을 내보낼 때 루트 스쿼시를 사용합니다. 이렇게 하면 로컬 시스템의 root 사용자로 NFS 공유에 액세스하는 사용자의 사용자 ID를 nobody 로 설정합니다. 루트 스쿼시는 기본 옵션 root_squash 에 의해 제어됩니다. 이 옵션에 대한 자세한 내용은 NFS 서버 구성을 참조하십시오.

NFS 공유를 읽기 전용으로 내보내는 경우 all_squash 옵션을 사용하는 것이 좋습니다. 이 옵션을 사용하면 내보낸 파일 시스템에 액세스하는 모든 사용자가 nobody 사용자의 사용자 ID를 사용할 수 있습니다.

7장. NFS에서 pNFS SCSI 레이아웃 활성화

pNFS SCSI는 데이터에 액세스하는 데 pNFS SCSI 레이아웃을 사용하도록 NFS 서버와 클라이언트를 구성할 수 있습니다. pNFS SCSI는 파일에 대한 장기적 단일 클라이언트 액세스가 필요한 사용 사례에 유용합니다.

사전 요구 사항

  • 클라이언트와 서버 모두 동일한 블록 장치에 SCSI 명령을 보낼 수 있어야 합니다. 즉, 블록 장치는 공유 SCSI 버스에 있어야 합니다.
  • 블록 장치에는 XFS 파일 시스템이 포함되어야 합니다.
  • SCSI 장치는 SCSI-3 기본 명령 사양에 설명된 대로 SCSI 영구 예약을 지원해야 합니다.

7.1. pNFS 기술

pNFS 아키텍처는 NFS의 확장성을 향상시킵니다. 서버가 pNFS를 구현하면 클라이언트는 동시에 여러 서버를 통해 데이터에 액세스할 수 있습니다. 이로 인해 성능이 향상될 수 있습니다.

pNFS는 RHEL에서 다음과 같은 스토리지 프로토콜 또는 레이아웃을 지원합니다.

  • Files
  • Flexfiles
  • SCSI

7.2. pNFS SCSI 레이아웃

SCSI 레이아웃은 pNFS 블록 레이아웃 작업에 따라 빌드됩니다. 레이아웃은 SCSI 장치 간에 정의됩니다. SCSI 영구 예약을 지원할 수 있어야 하는 일련의 고정 크기 블록을 논리 단위(LU)로 포함합니다. LU 장치는 SCSI 장치 식별으로 식별됩니다.

pNFS SCSI는 파일에 대해 시간이 오래 걸리는 단일 클라이언트 액세스를 포함하는 사용 사례에서 효과적입니다. 예를 들어 메일 서버 또는 클러스터가 있는 가상 시스템이 있을 수 있습니다.

클라이언트와 서버 간의 작업

NFS 클라이언트가 파일에서 읽거나 여기에 쓰는 경우 클라이언트는 LAYOUTGET 작업을 수행합니다. 서버는 SCSI 장치에 있는 파일의 위치로 응답합니다. 클라이언트는 GETDEVICEINFO 의 추가 작업을 수행하여 사용할 SCSI 장치를 결정해야 할 수 있습니다. 이러한 작업이 올바르게 작동하는 경우 클라이언트는 READWRITE 작업을 서버로 보내는 대신 I/O 요청을 SCSI 장치로 직접 실행할 수 있습니다.

클라이언트 간의 오류 또는 경합으로 인해 서버가 레이아웃을 불러오거나 클라이언트에 발행하지 못할 수 있습니다. 이러한 경우 클라이언트는 I/O 요청을 SCSI 장치로 직접 보내는 대신 READWRITE 작업을 서버에 실행하기 위해 대체됩니다.

작업을 모니터링하려면 pNFS SCSI 레이아웃 기능 모니터링 을 참조하십시오.

장치 예약

pNFS SCSI는 예약을 할당하여 펜싱을 처리합니다. 서버가 클라이언트에 레이아웃을 발행하기 전에 등록된 클라이언트만 장치에 액세스할 수 있도록 SCSI 장치를 예약합니다. 클라이언트에서 해당 SCSI 장치에 대해 명령을 실행할 수 있지만 장치에 등록되지 않은 경우 해당 장치의 클라이언트에서 많은 작업이 실패합니다. 예를 들어 서버에 클라이언트에 해당 장치의 레이아웃이 지정되지 않은 경우 클라이언트의 blkid 명령은 XFS 파일 시스템의 UUID를 표시하지 못합니다.

서버에서 자체 영구 예약을 제거하지 않습니다. 이렇게 하면 클라이언트 및 서버를 다시 시작할 때마다 장치의 파일 시스템 내의 데이터를 보호합니다. SCSI 장치를 다시 사용하려면 NFS 서버에서 영구 예약을 수동으로 제거해야 할 수 있습니다.

7.3. pNFS와 호환되는 SCSI 장치 확인

이 절차에서는 SCSI 장치가 pNFS SCSI 레이아웃을 지원하는지 확인합니다.

사전 요구 사항

  • sg3_utils 패키지를 설치합니다.

    # yum install sg3_utils

절차

  • 서버와 클라이언트 모두에서 적절한 SCSI 장치 지원이 있는지 확인합니다.

    # sg_persist --in --report-capabilities --verbose path-to-scsi-device

    Persist through Power losts Active(PTP L_A) 비트가 설정되었는지 확인합니다.

    예 7.1. pNFS SCSI를 지원하는 SCSI 장치

    다음은 pNFS SCSI를 지원하는 SCSI 장치의 sg_persist 출력 예입니다. POST PL_A 비트는 1 을 보고합니다.

        inquiry cdb: 12 00 00 00 24 00
        Persistent Reservation In cmd: 5e 02 00 00 00 00 00 20 00 00
      LIO-ORG   block11           4.0
      Peripheral device type: disk
    Report capabilities response:
      Compatible Reservation Handling(CRH): 1
      Specify Initiator Ports Capable(SIP_C): 1
      All Target Ports Capable(ATP_C): 1
      Persist Through Power Loss Capable(PTPL_C): 1
      Type Mask Valid(TMV): 1
      Allow Commands: 1
      Persist Through Power Loss Active(PTPL_A): 1
        Support indicated in Type mask:
          Write Exclusive, all registrants: 1
          Exclusive Access, registrants only: 1
          Write Exclusive, registrants only: 1
          Exclusive Access: 1
          Write Exclusive: 1
          Exclusive Access, all registrants: 1

추가 리소스

  • sg_persist(8) 매뉴얼 페이지

7.4. 서버에서 pNFS SCSI 설정

이 절차에서는 pNFS SCSI 레이아웃을 내보내도록 NFS 서버를 구성합니다.

절차

  1. 서버에서 SCSI 장치에 생성된 XFS 파일 시스템을 마운트합니다.
  2. NFS 버전 4.1 이상을 내보내도록 NFS 서버를 구성합니다. /etc/ nfs.conf 파일의 [nfsd] 섹션에 다음 옵션을 설정합니다.

    [nfsd]
    
    vers4.1=y
  3. pnfs 옵션을 사용하여 NFS를 통해 XFS 파일 시스템을 내보내도록 NFS 서버를 구성합니다.

    예 7.2. pNFS SCSI를 내보낼 /etc/exports의 항목

    /etc/exports 구성 파일의 다음 항목은 /exported/directory/ 에 마운트된 파일 시스템을 pNFS SCSI 레이아웃으로 allowed.example.com 클라이언트에 내보냅니다.

    /exported/directory allowed.example.com(pnfs)
    참고

    내보낸 파일 시스템은 파티션뿐만 아니라 전체 블록 장치에 생성해야 합니다.

추가 리소스

7.5. 클라이언트에서 pNFS SCSI 설정

이 절차에서는 pNFS SCSI 레이아웃을 마운트하도록 NFS 클라이언트를 구성합니다.

사전 요구 사항

절차

  • 클라이언트에서 NFS 버전 4.1 이상을 사용하여 내보낸 XFS 파일 시스템을 마운트합니다.

    # mount -t nfs -o nfsvers=4.1 host:/remote/export /local/directory

    NFS 없이 직접 XFS 파일 시스템을 마운트하지 마십시오.

추가 리소스

7.6. 서버에서 pNFS SCSI 예약 해제

이 절차에서는 NFS 서버가 SCSI 장치에 보유하는 영구 예약을 해제합니다. 이렇게 하면 더 이상 pNFS SCSI를 내보낼 필요가 없는 경우 SCSI 장치를 다시 사용할 수 있습니다.

서버에서 예약을 제거해야 합니다. 다른 IT Nexus에서 제거할 수 없습니다.

사전 요구 사항

  • sg3_utils 패키지를 설치합니다.

    # yum install sg3_utils

절차

  1. 서버에서 기존 예약을 쿼리합니다.

    # sg_persist --read-reservation path-to-scsi-device

    예 7.3. /dev/sda에 예약 쿼리

    # *sg_persist --read-reservation /dev/sda*
    
      LIO-ORG   block_1           4.0
      Peripheral device type: disk
      PR generation=0x8, Reservation follows:
        Key=0x100000000000000
        scope: LU_SCOPE,  type: Exclusive Access, registrants only
  2. 서버에서 기존 등록을 제거합니다.

    # sg_persist --out \
                 --release \
                 --param-rk=reservation-key \
                 --prout-type=6 \
                 path-to-scsi-device

    예 7.4. /dev/sda에서 예약 제거

    # sg_persist --out \
                 --release \
                 --param-rk=0x100000000000000 \
                 --prout-type=6 \
                 /dev/sda
    
      LIO-ORG   block_1           4.0
      Peripheral device type: disk

추가 리소스

  • sg_persist(8) 매뉴얼 페이지

8장. Squid 캐싱 프록시 서버 구성

Squid는 콘텐츠를 캐시하여 대역폭과 부하 웹 페이지를 더 빠르게 줄이는 프록시 서버입니다. 이 장에서는 HTTP, HTTPS 및 FTP 프로토콜에 대한 프록시로 Squid를 설정하는 방법과 인증 및 액세스 제한에 대해 설명합니다.

8.1. 인증 없이 캐싱 프록시로 Squid 설정

이 섹션에서는 인증 없이 캐싱 프록시로 Squid의 기본 구성에 대해 설명합니다. 이 절차에서는 IP 범위를 기반으로 프록시에 대한 액세스를 제한합니다.

사전 요구 사항

  • 이 절차에서는 /etc/squid/squid.conf 파일이 squid 패키지에서 제공하는 것으로 가정합니다. 이전에 이 파일을 편집한 경우 파일을 제거하고 패키지를 다시 설치합니다.

절차

  1. squid 패키지를 설치합니다.

    # yum install squid
  2. /etc/squid/squid.conf 파일을 편집합니다.

    1. 프록시를 사용할 수 있어야 하는 IP 범위와 일치하도록 localnet ACL(액세스 제어 목록)을 조정합니다.

      acl localnet src 192.0.2.0/24
      acl localnet 2001:db8:1::/64

      기본적으로 /etc/squid/squid.conf 파일에는 localnet ACL에 지정된 모든 IP 범위의 프록시를 사용할 수 있는 http_access allow localnet 규칙이 포함되어 있습니다. http_access allow localnet 규칙 전에 모든 localnet ACL을 지정해야 합니다.

      중요

      사용자 환경과 일치하지 않는 기존 acl localnet 항목을 모두 제거합니다.

    2. 다음 ACL은 기본 구성에 존재하며 HTTPS 프로토콜을 사용하는 포트로 443 을 정의합니다.

      acl SSL_ports port 443

      사용자가 다른 포트에서도 HTTPS 프로토콜을 사용할 수 있어야 하는 경우 다음 각 포트에 대한 ACL을 추가합니다.

      acl SSL_ports port port_number
    3. acl Safe_ports 규칙 목록을 업데이트하여 Squid가 연결을 설정할 수 있는 포트를 구성합니다. 예를 들어 프록시를 사용하여 클라이언트가 포트 21(FTP), 80(HTTP) 및 443(HTTPS)의 리소스에만 액세스할 수 있도록 구성하려면 구성의 다음 acl Safe_ports 문만 유지합니다.

      acl Safe_ports port 21
      acl Safe_ports port 80
      acl Safe_ports port 443

      기본적으로 구성에는 Safe_ports ACL에 정의되지 않은 포트에 대한 액세스 거부를 정의하는 http_access deny! Safe_ports 규칙이 포함됩니다.

    4. cache_dir 매개변수의 캐시 유형, 캐시 크기 및 추가 캐시 유형별 설정을 구성합니다.

      cache_dir ufs /var/spool/squid 10000 16 256

      다음 설정이 필요합니다.

      • squid는 ufs 캐시 유형을 사용합니다.
      • squid는 해당 캐시를 /var/spool/squid/ 디렉터리에 저장합니다.
      • 캐시가 10000 MB까지 증가합니다.
      • squid는 /var/spool/squid/ 디렉터리에 16 level-1 하위 디렉터리를 생성합니다.
      • squid는 각 level-1 디렉토리에 256 개의 하위 디렉터리를 생성합니다.

        cache_dir 지시문을 설정하지 않으면 Squid가 캐시를 메모리에 저장합니다.

  3. cache_dir 매개변수에서 /var/spool/squid/ 와 다른 캐시 디렉터리를 설정하는 경우:

    1. 캐시 디렉토리를 생성합니다.

      # mkdir -p path_to_cache_directory
    2. 캐시 디렉토리에 대한 권한을 구성합니다.

      # chown squid:squid path_to_cache_directory
    3. 강제 모드에서 SELinux를 실행하는 경우 캐시 디렉터리에 squid_cache_t 컨텍스트를 설정합니다.

      # semanage fcontext -a -t squid_cache_t "path_to_cache_directory(/.*)?"
      # restorecon -Rv path_to_cache_directory

      시스템에서 semanage 유틸리티를 사용할 수 없는 경우 policycoreutils-python-utils 패키지를 설치합니다.

  4. 방화벽에서 3128 포트를 엽니다.

    # firewall-cmd --permanent --add-port=3128/tcp
    # firewall-cmd --reload
  5. squid 서비스를 활성화하고 시작합니다.

    # systemctl enable --now squid

검증 단계

프록시가 올바르게 작동하는지 확인하려면 curl 유틸리티를 사용하여 웹 페이지를 다운로드합니다.

# curl -O -L "https://www.redhat.com/index.html" -x "proxy.example.com:3128"

curl 에 오류가 표시되지 않고 index.html 파일이 현재 디렉터리로 다운로드된 경우 프록시가 작동합니다.

8.2. LDAP 인증을 사용하여 Squid를 캐싱 프록시로 설정

이 섹션에서는 LDAP를 사용하여 사용자를 인증하는 캐싱 프록시로 Squid의 기본 구성에 대해 설명합니다. 이 절차에서는 인증된 사용자만 프록시를 사용할 수 있도록 구성됩니다.

사전 요구 사항

  • 이 절차에서는 /etc/squid/squid.conf 파일이 squid 패키지에서 제공하는 것으로 가정합니다. 이전에 이 파일을 편집한 경우 파일을 제거하고 패키지를 다시 설치합니다.
  • LDAP 디렉터리에 uid=proxy_user,cn=users,cn=accounts,dc=example,dc=com 과 같은 서비스 사용자가 있습니다. Squid는 이 계정을 인증 사용자를 검색하기 위해서만 사용합니다. 인증 사용자가 있는 경우 Squid는 이 사용자로 을 디렉터리에 바인딩하여 인증을 확인합니다.

절차

  1. squid 패키지를 설치합니다.

    # yum install squid
  2. /etc/squid/squid.conf 파일을 편집합니다.

    1. basic_ldap_auth helper 유틸리티를 구성하려면 /etc/squid/squid.conf 상단에 다음 설정 항목을 추가합니다.

      auth_param basic program /usr/lib64/squid/basic_ldap_auth -b "cn=users,cn=accounts,dc=example,dc=com" -D "uid=proxy_user,cn=users,cn=accounts,dc=example,dc=com" -W /etc/squid/ldap_password -f "(&(objectClass=person)(uid=%s))" -ZZ -H ldap://ldap_server.example.com:389

      다음은 위의 예제에서 basic_ldap_auth 도우미 유틸리티에 전달된 매개변수를 설명합니다.

      • -B base_DN 은 LDAP 검색 기반을 설정합니다.
      • -d proxy_service_user_DN 은 Squid가 디렉터리에서 인증 사용자를 검색하는 데 사용하는 계정의 DN(고유 이름)을 설정합니다.
      • -W path_to_password_file 은 프록시 서비스 사용자의 암호가 포함된 파일의 경로를 설정합니다. 암호 파일을 사용하면 운영 체제의 프로세스 목록에 암호가 표시되지 않습니다.
      • -F LDAP_filter 는 LDAP 검색 필터를 지정합니다. squid는 인증 사용자가 제공한 사용자 이름으로 %s 변수를 대체합니다.

        예제의 (&(objectClass=person)(uid=%s) 필터는 사용자 이름이 uid 특성에 설정된 값과 디렉터리 항목에 사람 오브젝트 클래스가 포함되어 있어야 함을 정의합니다.

      • -ZZSTARTTLS 명령을 사용하여 LDAP 프로토콜을 통해 TLS 암호화 연결을 적용합니다. 다음과 같은 경우에는 -ZZ 를 생략하십시오.

        • LDAP 서버는 암호화된 연결을 지원하지 않습니다.
        • URL에 지정된 포트는 LDAPS 프로토콜을 사용합니다.
      • H LDAP_URL 매개 변수는 프로토콜, 호스트 이름 또는 IP 주소, LDAP 서버의 포트를 URL 형식으로 지정합니다.
    2. Squid가 인증된 사용자만 프록시를 사용하도록 허용하는 다음 ACL 및 규칙을 추가합니다.

      acl ldap-auth proxy_auth REQUIRED
      http_access allow ldap-auth
      중요

      http_access deny 모든 규칙을 거부하기 전에 이러한 설정을 지정합니다.

    3. localnet ACL에 지정된 IP 범위에서 프록시 인증을 바이패스하려면 다음 규칙을 제거합니다.

      http_access allow localnet
    4. 다음 ACL은 기본 구성에 존재하며 HTTPS 프로토콜을 사용하는 포트로 443 을 정의합니다.

      acl SSL_ports port 443

      사용자가 다른 포트에서도 HTTPS 프로토콜을 사용할 수 있어야 하는 경우 다음 각 포트에 대한 ACL을 추가합니다.

      acl SSL_ports port port_number
    5. acl Safe_ports 규칙 목록을 업데이트하여 Squid가 연결을 설정할 수 있는 포트를 구성합니다. 예를 들어 프록시를 사용하여 클라이언트가 포트 21(FTP), 80(HTTP) 및 443(HTTPS)의 리소스에만 액세스할 수 있도록 구성하려면 구성의 다음 acl Safe_ports 문만 유지합니다.

      acl Safe_ports port 21
      acl Safe_ports port 80
      acl Safe_ports port 443

      기본적으로 구성에는 Safe_ports ACL에 정의되지 않은 포트에 대한 액세스 거부를 정의하는 http_access deny! Safe_ports 규칙이 포함됩니다.

    6. cache_dir 매개변수의 캐시 유형, 캐시 크기 및 추가 캐시 유형별 설정을 구성합니다.

      cache_dir ufs /var/spool/squid 10000 16 256

      다음 설정이 필요합니다.

      • squid는 ufs 캐시 유형을 사용합니다.
      • squid는 해당 캐시를 /var/spool/squid/ 디렉터리에 저장합니다.
      • 캐시가 10000 MB까지 증가합니다.
      • squid는 /var/spool/squid/ 디렉터리에 16 level-1 하위 디렉터리를 생성합니다.
      • squid는 각 level-1 디렉토리에 256 개의 하위 디렉터리를 생성합니다.

        cache_dir 지시문을 설정하지 않으면 Squid가 캐시를 메모리에 저장합니다.

  3. cache_dir 매개변수에서 /var/spool/squid/ 와 다른 캐시 디렉터리를 설정하는 경우:

    1. 캐시 디렉토리를 생성합니다.

      # mkdir -p path_to_cache_directory
    2. 캐시 디렉토리에 대한 권한을 구성합니다.

      # chown squid:squid path_to_cache_directory
    3. 강제 모드에서 SELinux를 실행하는 경우 캐시 디렉터리에 squid_cache_t 컨텍스트를 설정합니다.

      # semanage fcontext -a -t squid_cache_t "path_to_cache_directory(/.*)?"
      # restorecon -Rv path_to_cache_directory

      시스템에서 semanage 유틸리티를 사용할 수 없는 경우 policycoreutils-python-utils 패키지를 설치합니다.

  4. LDAP 서비스 사용자의 암호를 /etc/squid/ldap_password 파일에 저장하고 파일에 대한 적절한 권한을 설정합니다.

    # echo "password" > /etc/squid/ldap_password
    # chown root:squid /etc/squid/ldap_password
    # chmod 640 /etc/squid/ldap_password
  5. 방화벽에서 3128 포트를 엽니다.

    # firewall-cmd --permanent --add-port=3128/tcp
    # firewall-cmd --reload
  6. squid 서비스를 활성화하고 시작합니다.

    # systemctl enable --now squid

검증 단계

프록시가 올바르게 작동하는지 확인하려면 curl 유틸리티를 사용하여 웹 페이지를 다운로드합니다.

# curl -O -L "https://www.redhat.com/index.html" -x "user_name:password@proxy.example.com:3128"

curl에서 오류를 표시하지 않고 index.html 파일이 현재 디렉터리로 다운로드된 경우 프록시가 작동합니다.

문제 해결 단계

도우미 유틸리티가 올바르게 작동하는지 확인하려면 다음을 수행하십시오.

  1. auth_param 매개변수에 사용한 것과 동일한 설정으로 도우미 유틸리티를 수동으로 시작합니다.

    # /usr/lib64/squid/basic_ldap_auth -b "cn=users,cn=accounts,dc=example,dc=com" -D "uid=proxy_user,cn=users,cn=accounts,dc=example,dc=com" -W /etc/squid/ldap_password -f "(&(objectClass=person)(uid=%s))" -ZZ -H ldap://ldap_server.example.com:389
  2. 유효한 사용자 이름과 암호를 입력하고 Enter 키를 누릅니다.

    user_name password

    도우미 유틸리티에서 OK 를 반환하는 경우 인증이 성공했습니다.

8.3. kerberos 인증을 사용하여 캐싱 프록시로 Squid 설정

이 섹션에서는 Kerberos를 사용하여 사용자를 AD(Active Directory) 인증하는 캐싱 프록시로 Squid의 기본 구성에 대해 설명합니다. 이 절차에서는 인증된 사용자만 프록시를 사용할 수 있도록 구성됩니다.

사전 요구 사항

  • 이 절차에서는 /etc/squid/squid.conf 파일이 squid 패키지에서 제공하는 것으로 가정합니다. 이전에 이 파일을 편집한 경우 파일을 제거하고 패키지를 다시 설치합니다.
  • Squid를 설치할 서버는 AD 도메인의 멤버입니다. 자세한 내용은 Red Hat Enterprise Linux 8의 다른 유형의 서버 문서 배포를 참조하십시오.

절차

  1. 다음 패키지를 설치합니다.

    # yum install squid krb5-workstation
  2. AD 도메인 관리자로 인증합니다.

    # kinit administrator@AD.EXAMPLE.COM
  3. Squid의 키탭을 생성하여 /etc/squid/HTTP.keytab 파일에 저장하십시오.

    # export KRB5_KTNAME=FILE:/etc/squid/HTTP.keytab
    # net ads keytab CREATE -U administrator
  4. keytab에 HTTP 서비스 주체를 추가합니다.

    # net ads keytab ADD HTTP -U administrator
  5. keytab 파일의 소유자를 squid 사용자로 설정합니다.

    # chown squid /etc/squid/HTTP.keytab
  6. 필요한 경우 keytab 파일에 프록시 서버의 FQDN(정규화된 도메인 이름)에 대한 HTTP 서비스 주체가 포함되어 있는지 확인합니다.

      klist -k /etc/squid/HTTP.keytab
    Keytab name: FILE:/etc/squid/HTTP.keytab
    KVNO Principal
    ---- ---------------------------------------------------
    ...
       2 HTTP/proxy.ad.example.com@AD.EXAMPLE.COM
    ...
  7. /etc/squid/squid.conf 파일을 편집합니다.

    1. negotiate_kerberos_auth 도우미 유틸리티를 구성하려면 /etc/squid/squid.conf 의 상단에 다음 설정 항목을 추가하십시오.

      auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -k /etc/squid/HTTP.keytab -s HTTP/proxy.ad.example.com@AD.EXAMPLE.COM

      다음은 위의 예제에서 negotiate_kerberos_auth 도우미 유틸리티로 전달되는 매개변수를 설명합니다.

      • -K 파일은 키 탭 파일의 경로를 설정합니다. squid 사용자는 이 파일에 대한 읽기 권한이 있어야 합니다.
      • -s HTTP/host_name@kerberos_realm 은 Squid가 사용하는 Kerberos 주체를 설정합니다.

        선택적으로 다음 매개변수 중 하나 또는 둘 다를 도우미 유틸리티에 전달하여 로깅을 활성화할 수 있습니다.

      • - 인증 사용자와 같은 정보 메시지를 기록합니다.
      • -D는 디버그 로깅을 활성화합니다.

        squid는 도우미 유틸리티의 디버깅 정보를 /var/log/squid/cache.log 파일에 기록합니다.

    2. Squid가 인증된 사용자만 프록시를 사용하도록 허용하는 다음 ACL 및 규칙을 추가합니다.

      acl kerb-auth proxy_auth REQUIRED
      http_access allow kerb-auth
      중요

      http_access deny 모든 규칙을 거부하기 전에 이러한 설정을 지정합니다.

    3. localnet ACL에 지정된 IP 범위에서 프록시 인증을 바이패스하려면 다음 규칙을 제거합니다.

      http_access allow localnet
    4. 다음 ACL은 기본 구성에 존재하며 HTTPS 프로토콜을 사용하는 포트로 443 을 정의합니다.

      acl SSL_ports port 443

      사용자가 다른 포트에서도 HTTPS 프로토콜을 사용할 수 있어야 하는 경우 다음 각 포트에 대한 ACL을 추가합니다.

      acl SSL_ports port port_number
    5. acl Safe_ports 규칙 목록을 업데이트하여 Squid가 연결을 설정할 수 있는 포트를 구성합니다. 예를 들어 프록시를 사용하여 클라이언트가 포트 21(FTP), 80(HTTP) 및 443(HTTPS)의 리소스에만 액세스할 수 있도록 구성하려면 구성의 다음 acl Safe_ports 문만 유지합니다.

      acl Safe_ports port 21
      acl Safe_ports port 80
      acl Safe_ports port 443

      기본적으로 구성에는 Safe_ports ACL에 정의되지 않은 포트에 대한 액세스 거부를 정의하는 http_access deny! Safe_ports 규칙이 포함됩니다.

    6. cache_dir 매개변수의 캐시 유형, 캐시 크기 및 추가 캐시 유형별 설정을 구성합니다.

      cache_dir ufs /var/spool/squid 10000 16 256

      다음 설정이 필요합니다.

      • squid는 ufs 캐시 유형을 사용합니다.
      • squid는 해당 캐시를 /var/spool/squid/ 디렉터리에 저장합니다.
      • 캐시가 10000 MB까지 증가합니다.
      • squid는 /var/spool/squid/ 디렉터리에 16 level-1 하위 디렉터리를 생성합니다.
      • squid는 각 level-1 디렉토리에 256 개의 하위 디렉터리를 생성합니다.

        cache_dir 지시문을 설정하지 않으면 Squid가 캐시를 메모리에 저장합니다.

  8. cache_dir 매개변수에서 /var/spool/squid/ 와 다른 캐시 디렉터리를 설정하는 경우:

    1. 캐시 디렉토리를 생성합니다.

      # mkdir -p path_to_cache_directory
    2. 캐시 디렉토리에 대한 권한을 구성합니다.

      # chown squid:squid path_to_cache_directory
    3. 강제 모드에서 SELinux를 실행하는 경우 캐시 디렉터리에 squid_cache_t 컨텍스트를 설정합니다.

      # semanage fcontext -a -t squid_cache_t "path_to_cache_directory(/.*)?"
      # restorecon -Rv path_to_cache_directory

      시스템에서 semanage 유틸리티를 사용할 수 없는 경우 policycoreutils-python-utils 패키지를 설치합니다.

  9. 방화벽에서 3128 포트를 엽니다.

    # firewall-cmd --permanent --add-port=3128/tcp
    # firewall-cmd --reload
  10. squid 서비스를 활성화하고 시작합니다.

    # systemctl enable --now squid

검증 단계

프록시가 올바르게 작동하는지 확인하려면 curl 유틸리티를 사용하여 웹 페이지를 다운로드합니다.

# curl -O -L "https://www.redhat.com/index.html" --proxy-negotiate -u : -x "proxy.ad.example.com:3128"

curl 에서 오류를 표시하지 않고 index.html 파일이 현재 디렉터리에 있는 경우 프록시가 작동합니다.

문제 해결 단계

Kerberos 인증을 수동으로 테스트하려면 다음을 수행합니다.

  1. AD 계정에 대한 Kerberos 티켓을 받습니다.

    # kinit user@AD.EXAMPLE.COM
  2. 선택적으로 티켓을 표시합니다.

    # klist
  3. negotiate_kerberos_auth_test 유틸리티를 사용하여 인증을 테스트합니다.

    # /usr/lib64/squid/negotiate_kerberos_auth_test proxy.ad.example.com

    도우미 유틸리티에서 토큰을 반환하면 인증이 성공했습니다.

    Token: YIIFtAYGKwYBBQUCoIIFqDC...

8.4. Squid에서 도메인 거부 목록 구성

관리자는 특정 도메인에 대한 액세스를 차단하려는 경우가 많습니다. 이 섹션에서는 Squid에서 도메인 거부 목록을 구성하는 방법을 설명합니다.

사전 요구 사항

  • Squid가 구성되어 있으며 사용자는 프록시를 사용할 수 있습니다.

절차

  1. /etc/squid/squid.conf 파일을 편집하고 다음 설정을 추가합니다.

    acl domain_deny_list dstdomain "/etc/squid/domain_deny_list.txt"
    http_access deny all domain_deny_list
    중요

    사용자 또는 클라이언트에 대한 액세스를 허용하는 첫 번째 http_access allow 문 앞에 이러한 항목을 추가합니다.

  2. /etc/squid/domain_deny_list.txt 파일을 만들고 차단하려는 도메인을 추가합니다. 예를 들어 하위 도메인을 포함한 example.com 에 대한 액세스를 차단하고 example.net 을 차단하려면 다음을 추가합니다.

    .example.com
    example.net
    중요

    squid 구성에서 /etc/squid/domain_deny_list.txt 파일을 참조하는 경우 이 파일은 비워서는 안 됩니다. 파일이 비어 있으면 Squid가 시작되지 않습니다.

  3. squid 서비스를 다시 시작하십시오.

    # systemctl restart squid

8.5. 특정 포트 또는 IP 주소에서 수신 대기하도록 Squid 서비스 구성

기본적으로 Squid 프록시 서비스는 모든 네트워크 인터페이스의 3128 포트에서 수신 대기합니다. 이 섹션에서는 포트를 변경하고 특정 IP 주소에서 수신 대기하도록 Squid를 구성하는 방법에 대해 설명합니다.

사전 요구 사항

  • squid 패키지가 설치되어 있습니다.

절차

  1. /etc/squid/squid.conf 파일을 편집합니다.

    • Squid 서비스가 수신 대기하는 포트를 설정하려면 http_port 매개 변수에 포트 번호를 설정합니다. 예를 들어 포트를 8080 으로 설정하려면 다음을 설정합니다.

      http_port 8080
    • Squid 서비스가 수신 대기하는 IP 주소를 구성하려면 http_port 매개변수에서 IP 주소 및 포트 번호를 설정합니다. 예를 들어 Squid가 포트 3128192.0.2.1 IP 주소에서만 수신 대기하도록 구성하려면 다음을 설정합니다.

      http_port 192.0.2.1:3128

      구성 파일에 여러 http_port 매개 변수를 추가하여 Squid가 여러 포트 및 IP 주소에서 수신 대기하도록 구성합니다.

      http_port 192.0.2.1:3128
      http_port 192.0.2.1:8080
  2. Squid가 기본값(3128)으로 다른 포트를 사용하도록 구성한경우:

    1. 방화벽에서 포트를 엽니다.

      # firewall-cmd --permanent --add-port=port_number/tcp
      # firewall-cmd --reload
    2. 강제 모드에서 SELinux를 실행하는 경우 포트를 squid_port_t 포트 유형 정의에 할당합니다.

      # semanage port -a -t squid_port_t -p tcp port_number

      시스템에서 semanage 유틸리티를 사용할 수 없는 경우 policycoreutils-python-utils 패키지를 설치합니다.

  3. squid 서비스를 다시 시작하십시오.

    # systemctl restart squid

8.6. 추가 리소스

  • 설정 매개변수 ECDHE/share/doc/squid-<version>/squid.conf.documented

9장. 데이터베이스 서버

9.1. 데이터베이스 서버 소개

데이터베이스 서버는 DBMS(데이터베이스 관리 시스템)의 기능을 제공하는 서비스입니다. DBMS는 데이터베이스 관리를 위한 유틸리티를 제공하며 최종 사용자, 애플리케이션 및 데이터베이스와 상호 작용합니다.

Red Hat Enterprise Linux 8은 다음과 같은 데이터베이스 관리 시스템을 제공합니다.

  • MariaDB 10.3
  • MariaDB 10.5 - RHEL 8.4 이후 사용 가능
  • MySQL 8.0
  • PostgreSQL 10
  • PostgreSQL 9.6
  • PostgreSQL 12 - RHEL 8.1.1 이후 사용 가능
  • PostgreSQL 13 - RHEL 8.4 이후 사용 가능

9.2. MariaDB 사용

MariaDB 서버는 MySQL 기술을 기반으로 하는 오픈 소스 빠르고 강력한 데이터베이스 서버입니다. 이 부분에서는 RHEL 시스템에 MariaDB 를 설치 및 구성하는 방법, MariaDB 데이터를 백업하는 방법, 이전 MariaDB 버전에서 마이그레이션하는 방법 및 MariaDB Galera Cluster 를 사용하여 데이터베이스를 복제하는 방법을 설명합니다.

9.2.1. MariaDB 시작하기

MariaDB 는 데이터를 구조화된 정보로 변환하고 데이터에 액세스하기 위한 SQL 인터페이스를 제공하는 관계형 데이터베이스입니다. 여기에는 여러 스토리지 엔진 및 플러그인, GIS(지리적 정보 시스템) 및 JSON(JavaScript Object Notation) 기능이 포함됩니다.

Red Hat Enterprise Linux 8의 경우 다음 사항에 대해 설명합니다.

  • MariaDB 설치에 MariaDB 서버를 설치하는 방법 .
  • MariaDB 구성에서 MariaDB 구성 을 조정하는 방법.
  • MariaDB 데이터 백업에서 MariaDB 데이터를 백업하는 방법.
  • MariaDB 10.3으로 마이그레이션 시 RHEL 7 기본 버전인 MariaDB 5.5 에서 RHEL 8 기본 버전인 MariaDB 10.3 으로 마이그레이션하는 방법.
  • MariaDB 10.3 에서 MariaDB 10.5 로 업그레이드하여 RHEL 8 내에서 MariaDB 10.3에서 MariaDB 10.5로 업그레이드하는 방법
  • Galera를 사용하여 MariaDB 복제에서 MariaDB Galera 클러스터를 사용하여 데이터베이스를 복제하는 방법.

9.2.2. MariaDB 설치

RHEL 8에서 MariaDB 서버는 다음 버전에서 사용할 수 있으며 각각 별도의 스트림에서 제공됩니다.

  • MariaDB 10.3
  • MariaDB 10.5 - RHEL 8.4 이후 사용 가능

MariaDB 를 설치하려면 다음 절차를 사용합니다.

절차

  1. mariadb 모듈에서 스트림(버전)을 선택하고 서버 프로필을 지정하여 MariaDB 서버 패키지를 설치합니다. 예를 들면 다음과 같습니다.

    # yum module install mariadb:10.3/server
  2. mariadb 서비스를 시작합니다.

    # systemctl start mariadb.service
  3. 부팅 시 시작되도록 mariadb 서비스를 활성화합니다.

    # systemctl enable mariadb.service
  4. 권장 사항: MariaDB 를 설치할 때 보안을 개선하려면 다음 명령을 실행합니다.

    $ mysql_secure_installation

    명령은 완전히 대화형 스크립트를 시작하여 프로세스의 각 단계에 대한 메시지를 표시합니다. 이 스크립트를 사용하면 다음과 같은 방법으로 보안을 강화할 수 있습니다.

    • root 계정의 암호 설정
    • 익명 사용자 제거
    • 원격 root 로그인 허용 (로컬 호스트 내부)
참고

충돌하는 RPM 패키지로 인해 MariaDBMySQL 데이터베이스 서버를 RHEL 8에서 병렬로 설치할 수 없습니다. RHEL 7용 Red Hat Software Collections에서는 구성 요소의 병렬 설치가 가능합니다. RHEL 8에서는 컨테이너에서 다른 버전의 데이터베이스 서버를 사용할 수 있습니다.

9.2.3. MariaDB 구성

네트워킹에 사용할 MariaDB 서버를 구성하려면 다음 절차를 사용합니다.

절차

  1. /etc/my.cnf. d/mariadb-server.cnf 파일의 [mysqld ] 섹션을 편집합니다. 다음 구성 지시문을 설정할 수 있습니다.

    • bind-address - 서버가 수신 대기하는 주소입니다. 가능한 옵션은 다음과 같습니다.

      • 호스트 이름
      • IPv4 주소
      • IPv6 주소
    • skip-networking - 서버가 TCP/IP 연결을 수신하는지 여부를 제어합니다. 가능한 값은 다음과 같습니다.

      • 0 - 모든 클라이언트 수신 대기
      • 1 - 로컬 클라이언트만 수신 대기
    • 포트 - MariaDB 가 TCP/IP 연결을 수신 대기하는 포트입니다.
  2. mariadb 서비스를 다시 시작합니다.

    # systemctl restart mariadb.service

9.2.4. MariaDB 서버에서 TLS 암호화 설정

기본적으로 MariaDB 는 암호화되지 않은 연결을 사용합니다. 보안 연결을 위해 MariaDB 서버에서 TLS 지원을 활성화하고 암호화된 연결을 설정하도록 클라이언트를 구성합니다.

9.2.4.1. MariaDB 서버에 CA 인증서, 서버 인증서 및 개인 키 배치

MariaDB 서버에서 TLS 암호화를 활성화하려면 MariaDB 서버에 인증 기관(CA) 인증서, 서버 인증서 및 개인 키를 저장할 수 있습니다.

사전 요구 사항

  • Privacy Enhanced Mail (PEM) 형식의 다음 파일이 서버에 복사되었습니다.

    • 서버의 개인 키: server.example.com.key.pem
    • 서버 인증서: server.example.com.crt.pem
    • CA(인증 기관) 인증서: ca.crt.pem

    개인 키 및 CSR(인증서 서명 요청) 생성 및 CA에서 인증서 요청에 대한 자세한 내용은 CA 문서를 참조하십시오.

절차

  1. CA 및 서버 인증서를 /etc/pki/tls/certs/ 디렉터리에 저장합니다.

    # mv <path>/server.example.com.crt.pem /etc/pki/tls/certs/
    # mv <path>/ca.crt.pem /etc/pki/tls/certs/
  2. MariaDB 서버가 파일을 읽을 수 있도록 CA 및 서버 인증서에 대한 권한을 설정합니다.

    # chmod 644 /etc/pki/tls/certs/server.example.com.crt.pem /etc/pki/tls/certs/ca.crt.pem

    인증서는 보안 연결을 설정하기 전에 통신의 일부이므로 모든 클라이언트는 인증 없이 검색할 수 있습니다. 따라서 CA 및 서버 인증서 파일에 대한 엄격한 권한을 설정할 필요가 없습니다.

  3. 서버의 개인 키를 /etc/pki/tls/private/ 디렉터리에 저장합니다.

    # mv <path>/server.example.com.key.pem /etc/pki/tls/private/
  4. 서버의 개인 키에 보안 권한을 설정합니다.

    # chmod 640 /etc/pki/tls/private/server.example.com.key.pem
    # chgrp mysql /etc/pki/tls/private/server.example.com.key.pem

    권한이 없는 사용자가 개인 키에 액세스할 수 있는 경우 MariaDB 서버에 대한 연결이 더 이상 안전하지 않습니다.

  5. SELinux 컨텍스트를 복원하십시오.

    #  restorecon -Rv /etc/pki/tls/

9.2.4.2. MariaDB 서버에서 TLS 구성

보안을 개선하기 위해 MariaD 서버에서 TLS 지원을 활성화합니다. 결과적으로 클라이언트는 TLS 암호화를 사용하여 서버로 데이터를 전송할 수 있습니다.

사전 요구 사항

  • MariaDB 서버를 설치했습니다.
  • mariadb 서비스가 실행 중입니다.
  • Privacy Enhanced Mail (PEM) 형식의 다음 파일은 서버에 있으며 mysql 사용자가 읽을 수 있습니다.

    • 서버의 개인 키: /etc/pki/tls/private/server.example.com.key.pem
    • 서버 인증서: /etc/pki/tls/certs/server.example.com.crt.pem
    • CA(인증 기관) 인증서 /etc/pki/tls/certs/ca.crt.pem
  • 서버 인증서의 주체 고유 이름(DN) 또는 subject alternatives name(SAN) 필드는 서버의 호스트 이름과 일치합니다.

절차

  1. /etc/my.cnf.d/mariadb-server-tls.cnf 파일을 생성합니다.

    1. 다음 콘텐츠를 추가하여 개인 키, 서버 및 CA 인증서에 대한 경로를 구성합니다.

      [mariadb]
      ssl_key = /etc/pki/tls/private/server.example.com.key.pem
      ssl_cert = /etc/pki/tls/certs/server.example.com.crt.pem
      ssl_ca = /etc/pki/tls/certs/ca.crt.pem
    2. CRL(인증서 해지 목록)이 있는 경우 이를 사용하도록 MariaDB 서버를 구성합니다.

      ssl_crl = /etc/pki/tls/certs/example.crl.pem
    3. 선택 사항: MariaDB 10.5.2 이상을 실행하는 경우 암호화 없이 연결 시도를 거부할 수 있습니다. 이 기능을 활성화하려면 다음을 추가합니다.

      require_secure_transport = on
    4. 선택 사항: MariaDB 10.4.6 이상을 실행하는 경우 서버에서 지원할 TLS 버전을 설정할 수 있습니다. 예를 들어 TLS 1.2 및 TLS 1.3을 지원하려면 다음을 추가합니다.

      tls_version = TLSv1.2,TLSv1.3

      기본적으로 서버는 TLS 1.1, TLS 1.2 및 TLS 1.3을 지원합니다.

  2. mariadb 서비스를 다시 시작합니다.

    # systemctl restart mariadb

검증

문제 해결을 간소화하려면 TLS 암호화를 사용하도록 로컬 클라이언트를 구성하기 전에 MariaDB 서버에서 다음 단계를 수행합니다.

  1. MariaDB 에 TLS 암호화가 활성화되어 있는지 확인합니다.

    # mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'have_ssl';"
    +---------------+-----------------+
    | Variable_name | Value           |
    +---------------+-----------------+
    | have_ssl      | YES             |
    +---------------+-----------------+

    have_ssl 변수를 yes 로 설정하면 TLS 암호화가 활성화됩니다.

  2. 특정 TLS 버전만 지원하도록 MariaDB 서비스를 구성한 경우 tls_version 변수를 표시합니다.

    # mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'tls_version';"
    +---------------+-----------------+
    | Variable_name | Value           |
    +---------------+-----------------+
    | tls_version   | TLSv1.2,TLSv1.3 |
    +---------------+-----------------+

9.2.4.3. 특정 사용자 계정에 대해 TLS 암호화 연결 필요

중요한 데이터에 액세스할 수 있는 사용자는 항상 TLS 암호화 연결을 사용하여 네트워크를 통해 암호화되지 않은 데이터를 전송하지 않도록 해야 합니다.

모든 연결(에서 required_secure_transport =)에 보안 전송이 필요한서버에서 를 구성할 수 없는 경우 TLS 암호화가 필요하도록 개별 사용자 계정을 구성합니다.

사전 요구 사항

  • MariaDB 서버에는 TLS 지원이 활성화되어 있습니다.
  • 보안 전송을 요구하도록 구성하는 사용자가 있습니다.

절차

  1. 관리자로 MariaDB 서버에 연결합니다.

    # mysql -u root -p -h server.example.com

    관리자가 서버에 원격으로 액세스할 수 있는 권한이 없는 경우 MariaDB 서버에서 명령을 수행하고 localhost 에 연결합니다.

  2. REQUIRE SSL 절을 사용하여 사용자가 TLS 암호화 연결을 사용하여 연결해야 함을 적용합니다.

    MariaDB [(none)]> **ALTER USER __'example__'@__'%'__ REQUIRE SSL;**

검증

  1. TLS 암호화를 사용하여 서버에 예제 사용자로 연결합니다.

    # mysql -u example -p -h server.example.com --ssl
    ...
    MariaDB [(none)]>

    오류가 표시되지 않고 대화형 MariaDB 콘솔에 액세스할 수 있는 경우 TLS와의 연결이 성공합니다.

  2. TLS가 비활성화된 예제 사용자로 연결을 시도합니다.

    # mysql -u example -p -h server.example.com --skip-ssl
    ERROR 1045 (28000): Access denied for user 'example'@'server.example.com' (using password: YES)

    TLS는 이 사용자에 대해 필요하지만 비활성화(--skip-ssl)이므로 서버에서 로그인 시도를 거부했습니다.

9.2.5. MariaDB 클라이언트에서 전역적으로 TLS 암호화 활성화

MariaDB 서버가 TLS 암호화를 지원하는 경우 보안 연결만 설정하고 서버 인증서를 확인하도록 클라이언트를 구성합니다. 다음 절차에서는 서버에 있는 모든 사용자에 대해 TLS 지원을 활성화하는 방법을 설명합니다.

9.2.5.1. 기본적으로 TLS 암호화를 사용하도록 MariaDB 클라이언트 구성

RHEL에서는 MariaDB 클라이언트가 TLS 암호화를 사용하도록 구성하고 서버 인증서의 CN(Common Name)이 사용자가 연결하는 호스트 이름과 일치하는지 확인할 수 있습니다. 따라서 메시지 가로채기(man-in-the-middle) 공격을 방지합니다.

사전 요구 사항

  • MariaDB 서버에는 TLS 지원이 활성화되어 있습니다.
  • 서버의 인증서를 발급한 CA(인증 기관)가 RHEL에서 신뢰할 수 없는 경우 CA 인증서가 클라이언트에 복사됩니다.

절차

  1. RHEL이 서버의 인증서를 발급한 CA를 신뢰하지 않는 경우:

    1. CA 인증서를 /etc/pki/ca-trust/source/anchors/ 디렉터리에 복사합니다.

      # cp <path>/ca.crt.pem /etc/pki/ca-trust/source/anchors/
    2. 모든 사용자가 CA 인증서 파일을 읽을 수 있도록 권한을 설정합니다.

      # chmod 644 /etc/pki/ca-trust/source/anchors/ca.crt.pem
    3. CA 신뢰 데이터베이스를 다시 빌드합니다.

      # update-ca-trust
  2. 다음 콘텐츠를 사용하여 /etc/my.cnf.d/mariadb-client-tls.cnf 파일을 생성합니다.

    [client-mariadb]
    ssl
    ssl-verify-server-cert

    이러한 설정은 MariaDB 클라이언트가 TLS 암호화(ssl)를 사용하고 클라이언트가 서버 인증서의 CN과 호스트 이름을 비교하는 것을 정의합니다(ssl-verify-server-cert).

검증

  • 호스트 이름을 사용하여 서버에 연결하고 서버 상태를 표시합니다.

    # mysql -u root -p -h server.example.com -e status
    ...
    SSL:        Cipher in use is TLS_AES_256_GCM_SHA384

    SSL 항목에 사용 중 암호화가 있는 경우..., 연결이 암호화됩니다.

    이 명령에서 사용하는 사용자에게는 원격으로 인증할 수 있는 권한이 있습니다.

    연결하는 호스트 이름이 서버의 TLS 인증서의 호스트 이름과 일치하지 않으면 ssl-verify-server-cert 매개변수로 인해 연결이 실패합니다. 예를 들어 localhost 에 연결하는 경우 :

    # mysql -u root -p -h localhost -e status
    ERROR 2026 (HY000): SSL connection error: Validation of SSL server certificate failed

추가 리소스

  • mysql(1) 도움말 페이지의 --ssl* 매개 변수 설명.

9.2.6. MariaDB 데이터 백업

Red Hat Enterprise Linux 8의 MariaDB 데이터베이스에서 데이터를 백업하는 방법에는 두 가지가 있습니다.

  • 논리적 백업
  • 물리적 백업

논리적 백업 은 데이터를 복원하는 데 필요한 SQL 문으로 구성됩니다. 이러한 유형의 백업은 일반 텍스트 파일로 정보와 레코드를 내보냅니다.

물리적 백업보다 논리적 백업의 주요 장점은 이식성과 유연성입니다. 데이터는 물리적 백업에서 사용할 수 없는 다른 하드웨어 구성, MariaDB 버전 또는 DBMS(데이터베이스 관리 시스템)에서 복원할 수 있습니다.

mariadb.service 가 실행 중인 경우 논리적 백업을 수행할 수 있습니다. 논리적 백업에는 로그 및 구성 파일이 포함되지 않습니다.

물리적 백업 은 콘텐츠를 저장하는 파일과 디렉토리의 복사본으로 구성됩니다.

물리적 백업은 논리적 백업과 비교하여 다음과 같은 이점이 있습니다.

  • 출력이 더 작습니다.
  • 백업은 크기가 작습니다.
  • 백업 및 복원 속도가 빨라집니다.
  • 백업에는 로그 및 구성 파일이 포함됩니다.

물리적 백업은 mariadb.service 가 실행 중이 아니거나 백업 중 변경을 방지하기 위해 데이터베이스의 모든 테이블이 잠겨 있는 경우 수행해야 합니다.

다음 MariaDB 백업 방법 중 하나를 사용하여 MariaDB 데이터베이스에서 데이터를 백업할 수 있습니다.

  • mysqldump를 사용한 논리적 백업
  • Mariabackup 유틸리티를 사용한 물리적 온라인 백업
  • 파일 시스템 백업
  • 백업 솔루션으로의 복제

9.2.6.1. mysqldump를 사용하여 논리적 백업 수행

mysqldump 클라이언트는 백업 또는 다른 데이터베이스 서버로 전송을 위해 데이터베이스 또는 데이터베이스 컬렉션을 덤프하는 데 사용할 수 있는 백업 유틸리티입니다. mysqldump 의 출력은 일반적으로 서버 테이블 구조를 다시 생성하거나 데이터로 채우거나 둘 다로 채워지는 SQL 문으로 구성됩니다. mysqldump 는 CSV와 같은 XML 및 구분된 텍스트 형식을 포함하여 다른 형식의 파일을 생성할 수도 있습니다.

mysqldump 백업을 수행하려면 다음 옵션 중 하나를 사용할 수 있습니다.

  • 하나 이상의 선택된 데이터베이스 백업
  • 모든 데이터베이스 백업
  • 하나의 데이터베이스에서 테이블의 하위 집합 백업

절차

  • 단일 데이터베이스를 덤프하려면 다음을 실행합니다.

    # mysqldump [options] --databases db_name > backup-file.sql
  • 한 번에 여러 데이터베이스를 덤프하려면 다음을 실행합니다.

    # mysqldump [options] --databases db_name1 [db_name2 …​] > backup-file.sql
  • 모든 데이터베이스를 덤프하려면 다음을 실행합니다.

    # mysqldump [options] --all-databases > backup-file.sql
  • 하나 이상의 덤프된 전체 데이터베이스를 서버에 다시 로드하려면 다음을 실행합니다.

    # mysql < backup-file.sql
  • 데이터베이스를 원격 MariaDB 서버에 로드하려면 다음을 실행합니다.

    # mysql --host=remote_host < backup-file.sql
  • 하나의 데이터베이스의 테이블 하위 집합을 덤프하려면 mysqldump 명령 끝에 선택한 테이블 목록을 추가합니다.

    # mysqldump [options] db_name [tbl_name …​] > backup-file.sql
  • 하나의 데이터베이스에서 덤프된 테이블의 하위 집합을 로드하려면 다음을 실행합니다.

    # mysql db_name < backup-file.sql
    참고

    db_name 데이터베이스는 이 시점에 있어야 합니다.

  • mysqldump 에서 지원하는 옵션 목록을 보려면 다음을 실행합니다.

    $ mysqldump --help

추가 리소스

9.2.6.2. Mariabackup 유틸리티를 사용하여 물리적 온라인 백업 수행

mariabackup 은 Percona XtraBackup 기술을 기반으로 하는 유틸리티로서 InnoDB, Aria, MyISAM 테이블의 물리적 온라인 백업을 수행할 수 있습니다. 이 유틸리티는 AppStream 리포지토리에서 mariadb-backup 패키지에서 제공합니다.

mariabackup 은 암호화 및 압축된 데이터를 포함하는 MariaDB 서버에 대한 전체 백업 기능을 지원합니다.

사전 요구 사항

  • mariadb-backup 패키지가 시스템에 설치됩니다.

    # yum install mariadb-backup
  • 백업이 실행될 사용자 자격 증명이 포함된 Mariabackup 을 제공해야 합니다. 명령줄 또는 구성 파일을 통해 자격 증명을 제공할 수 있습니다.
  • Mariabackup 사용자는 RELOAD,LOCK TABLESREPLICATION CLIENT 권한이 있어야 합니다.

Mariabackup 을 사용하여 데이터베이스 백업을 만들려면 다음 절차를 따르십시오.

절차

  • 명령줄에서 자격 증명을 제공하는 동안 백업을 만들려면 다음을 실행합니다.

    $ mariabackup --backup --target-dir <backup_directory> --user <backup_user> --password <backup_passwd>

    target-dir 옵션은 백업 파일이 저장되는 디렉터리를 정의합니다. 전체 백업을 수행하려면 대상 디렉터리가 비어 있거나 존재하지 않아야 합니다.

    사용자 이름 및 암호 옵션을 사용하여 사용자 이름과 암호를 구성할 수 있습니다.

  • 구성 파일에 인증 정보가 설정된 백업을 생성하려면 다음을 수행합니다.

    1. /etc/my.cnf.d/ 디렉터리에 구성 파일을 만듭니다(예: /etc/my.cnf.d/mariabackup.cnf ).
    2. 새 파일의 [xtrabackup] 또는 [mysqld] 섹션에 다음 행을 추가합니다.

      [xtrabackup]
      user=myuser
      password=mypassword
    3. 백업을 수행합니다.

      $ mariabackup --backup --target-dir <backup_directory>
중요

mariabackup 은 구성 파일의 [mariadb] 섹션에서 옵션을 읽지 않습니다. MariaDB 서버에 기본이 아닌 데이터 디렉터리가 지정된 경우 Mariabackup이 데이터 디렉터리를 찾을 수 있도록 구성 파일의 [xtrabackup] 또는 [mysqld] 섹션에서 이 디렉터리를 지정해야 합니다.

기본이 아닌 데이터 디렉터리를 지정하려면 MariaDB 구성 파일의 [xtrabackup] 또는 [mysqld] 섹션에 다음 행을 포함합니다.

datadir=/var/mycustomdatadir

9.2.6.3. Mariabackup 유틸리티를 사용하여 데이터 복원

백업이 완료되면 다음 옵션 중 하나와 함께 mariabackup 명령을 사용하여 백업에서 데이터를 복원할 수 있습니다.

  • --copy-back 을 사용하면 원본 백업 파일을 유지할 수 있습니다.
  • --move-back 은 백업 파일을 데이터 디렉터리로 이동하고 원래 백업 파일을 제거합니다.

Mariabackup 유틸리티를 사용하여 데이터를 복원하려면 다음 절차를 따르십시오.

사전 요구 사항

  • mariadb 서비스가 실행 중이 아닌지 확인합니다.

    # systemctl stop mariadb.service
  • 데이터 디렉터리가 비어 있는지 확인합니다.
  • Mariabackup 사용자는 RELOAD,LOCK TABLESREPLICATION CLIENT 권한이 있어야 합니다.

절차

  1. mariabackup 명령을 실행합니다.

    • 데이터를 복원하고 원본 백업 파일을 유지하려면 --copy-back 옵션을 사용합니다.

      $ mariabackup --copy-back --target-dir=/var/mariadb/backup/
    • 데이터를 복원하고 원본 백업 파일을 제거하려면 --move-back 옵션을 사용합니다.

      $ mariabackup --move-back --target-dir=/var/mariadb/backup/
  2. 파일 권한을 수정합니다.

    데이터베이스를 복원할 때 Mariabackup 은 백업의 파일 및 디렉토리 권한을 보존합니다. 그러나 Mariabackup 은 파일을 디스크에 쓰는 사용자 및 그룹으로 데이터베이스를 복원합니다. 백업을 복원한 후 일반적으로 MariaDB 서버의 사용자 및 그룹과 일치하도록 데이터 디렉터리의 소유자(일반적으로 mysql )를 조정해야 할 수 있습니다.

    예를 들어 파일의 소유권을 mysql 사용자 및 그룹으로 재귀적으로 변경하려면 다음을 수행합니다.

    # chown -R mysql:mysql /var/lib/mysql/
  3. mariadb 서비스를 시작합니다.

    # systemctl start mariadb.service

9.2.6.4. 파일 시스템 백업 수행

MariaDB 데이터 파일의 파일 시스템 백업을 생성하려면 MariaDB 데이터 디렉터리의 콘텐츠를 백업 위치에 복사합니다.

현재 구성 또는 로그 파일도 백업하려면 다음 절차의 선택적 단계를 사용하십시오.

절차

  1. mariadb 서비스를 중지합니다.

    # systemctl stop mariadb.service
  2. 필요한 위치에 데이터 파일을 복사합니다.

    # cp -r /var/lib/mysql /backup-location
  3. 필요한 경우 구성 파일을 필요한 위치에 복사합니다.

    # cp -r /etc/my.cnf /etc/my.cnf.d /backup-location/configuration
  4. 필요한 경우 로그 파일을 필요한 위치에 복사합니다.

    # cp /var/log/mariadb/ /backup-location/logs*
  5. mariadb 서비스를 시작합니다.

    # systemctl start mariadb.service
  6. 백업 위치에서 /var/lib/mysql 디렉터리에 백업 데이터를 로드할 때 mysql:mysql/var/lib/mysql 에 있는 모든 데이터의 소유자인지 확인하십시오.

    # chown -R mysql:mysql /var/lib/mysql

9.2.6.5. 백업 솔루션으로의 복제

복제는 소스 서버를 위한 대체 백업 솔루션입니다. 소스 서버에서 복제본 서버에 복제하는 경우 소스에 영향을 주지 않고 복제본에서 백업을 실행할 수 있습니다. 복제본을 종료하는 동안 계속 소스를 실행하고 복제본에서 데이터를 백업할 수 있습니다.

주의

복제 자체는 충분한 백업 솔루션이 아닙니다. 복제는 하드웨어 장애로부터 소스 서버를 보호하지만 데이터 손실에 대한 보호는 보장하지 않습니다. 이 메서드와 함께 복제본에서 다른 백업 솔루션을 사용하는 것이 좋습니다.

9.2.7. MariaDB 10.3으로 마이그레이션

RHEL 7에는 MySQL 데이터베이스 제품군의 서버 기본 구현으로 MariaDB 5.5 가 포함되어 있습니다. MariaDB 데이터베이스 서버의 이후 버전은 RHEL 7용 Software Collections로 사용할 수 있습니다. RHEL 8에서는 MariaDB 10.3,MariaDB 10.5MySQL 8.0 을 제공합니다.

이 부분에서는 RHEL 7 또는 Red Hat Software Collections 버전의 MariaDB에서 MariaDB 10.3 로의 마이그레이션에 대해 설명합니다. RHEL 8에서 MariaDB 10.3에서 MariaDB 10.5 로 마이그레이션하려면 대신 MariaDB 10.3에서 MariaDB 10.5로 업그레이드를 참조하십시오.

9.2.7.1. RHEL 7과 RHEL 8 버전의 MariaDB 간 주요 차이점

MariaDB 5.5와 MariaDB 10.3 의 가장 중요한 변경 사항은 다음과 같습니다.

  • 동기식 멀티 소스 클러스터인 MariaDB Galera Cluster 는 10.1 이후 MariaDB 의 표준 부분입니다.
  • ARCHIVE 스토리지 엔진은 더 이상 기본적으로 활성화되어 있지 않으며 플러그인을 구체적으로 활성화해야 합니다.
  • BLACKHOLE 스토리지 엔진은 기본적으로 활성화되어 있지 않으며 플러그인을 구체적으로 활성화해야 합니다.
  • InnoDB는 MariaDB 10.1 및 이전 버전에서 사용된 XtraDB 대신 기본 스토리지 엔진으로 사용됩니다.

    자세한 내용은 XtraDB 대신 MariaDB 10.2가 InnoDB를 사용하는 이유를 참조하십시오.

  • 새로운 mariadb-connector-c 패키지에서 는 MySQL 및 MariaDB의 공통 클라이언트 라이브러리를 제공합니다. 이 라이브러리는 MySQLMariaDB 데이터베이스 서버의 모든 버전에서 사용할 수 있습니다. 결과적으로 사용자는 Red Hat Enterprise Linux 8과 함께 배포된 MySQL 및 MariaDB 서버에 애플리케이션 빌드를 연결할 수 있습니다.

MariaDB 5.5 에서 MariaDB 10.3 으로 마이그레이션하려면 MariaDB로 마이그레이션에 설명된 대로 여러 구성 변경을 수행해야 합니다.

9.2.7.2. 설정 변경

MariaDB 5.5에서 MariaDB 10.3 으로의 마이그레이션 권장 마이그레이션 경로는 먼저 MariaDB 10.0 으로 업그레이드한 다음 하나의 버전으로 연속적으로 업그레이드하는 것입니다.

한 번에 하나의 마이너 버전을 업그레이드하는 주요 장점은 데이터와 구성을 포함한 데이터베이스를 변경 사항에 맞게 더 효과적으로 조정하는 것입니다. 업그레이드는 RHEL 8(MariaDB 10.3)에서 사용할 수 있는 것과 동일한 주요 버전에서 종료되므로 구성 변경이나 기타 문제가 크게 줄어듭니다.

MariaDB 5.5에서 MariaDB 10.0 으로 마이그레이션할 때 구성 변경 사항에 대한 자세한 내용은 Red Hat Software Collections 설명서의 MariaDB 10.0으로 마이그레이션 을 참조하십시오.

다음 후속 버전의 MariaDB 로 마이그레이션 및 필요한 구성 변경 사항은 다음 문서에 설명되어 있습니다.

참고

MariaDB 5.5에서 MariaDB 10.3 으로 직접 마이그레이션할 수도 있지만 위의 마이그레이션 문서에 설명된 차이점에 필요한 모든 구성 변경 사항을 수행해야 합니다.

9.2.7.3. mysql_upgrade 유틸리티를 사용한 즉각적 업그레이드

데이터베이스 파일을 RHEL 8로 마이그레이션하려면 RHEL 7의 MariaDB 사용자가 mysql_upgrade 유틸리티를 사용하여 즉각적 업그레이드를 수행해야 합니다. mysql_upgrade 유틸리티는 mariadb-server 패키지의 종속성으로 설치된 mariadb-server- utils 하위 패키지에서 제공합니다.

즉각적 업그레이드를 수행하려면 바이너리 데이터 파일을 RHEL 8 시스템의 /var/lib/mysql/ 데이터 디렉터리에 복사하고 mysql_upgrade 유틸리티를 사용해야 합니다.

다음에서 데이터를 마이그레이션하는 데 이 방법을 사용할 수 있습니다.

  • Red Hat Enterprise Linux 7 버전의 MariaDB 5.5
  • Red Hat Software Collections 버전:

    • MariaDB 5.5 (더 이상 지원되지 않음)
    • MariaDB 10.0 (더 이상 지원되지 않음)
    • MariaDB 10.1 (더 이상 지원되지 않음)
    • MariaDB 10.2 (더 이상 지원되지 않음)
    • MariaDB 10.3

      하나의 버전으로 영구적으로 MariaDB 10.3 으로 업그레이드하는 것이 좋습니다. Red Hat Software Collections 릴리스 노트 에서 각 마이그레이션 장을 참조하십시오.

참고

RHEL 7 버전의 MariaDB 에서 업그레이드하는 경우 소스 데이터는 /var/lib/mysql/ 디렉터리에 저장됩니다. Red Hat Software Collections 버전의 MariaDB 의 경우 소스 데이터 디렉터리는 /var/opt/rh/<collection_name>/lib/mysql/(/ opt/rh/mariadb55/root/var/lib/mysql/ 데이터 디렉터리를 사용하는 mariadb55 제외)입니다.

mysql_upgrade 유틸리티를 사용하여 업그레이드를 수행하려면 다음 절차를 사용합니다.

사전 요구 사항

  • 업그레이드를 수행하기 전에 MariaDB 데이터베이스에 저장된 모든 데이터를 백업합니다.

절차

  1. mariadb-server 패키지가 RHEL 8 시스템에 설치되어 있는지 확인합니다.

    # yum install mariadb-server
  2. 데이터를 복사할 때 mariadb 서비스가 소스 및 대상 시스템에서 실행되지 않는지 확인합니다.

    # systemctl stop mariadb.service
  3. 소스 위치의 데이터를 RHEL 8 대상 시스템의 /var/lib/mysql/ 디렉터리로 복사합니다.
  4. 대상 시스템에서 복사된 파일에 대한 적절한 권한 및 SELinux 컨텍스트를 설정합니다.

    # restorecon -vr /var/lib/mysql
  5. 대상 시스템에서 MariaDB 서버를 시작합니다.

    # systemctl start mariadb.service
  6. mysql_upgrade 명령을 실행하여 내부 테이블을 확인하고 복구합니다.

    $ mysql_upgrade
  7. 업그레이드가 완료되면 /etc/my.cnf.d/ 디렉터리에 있는 모든 구성 파일에 MariaDB 10.3 에 유효한 옵션만 포함되어 있는지 확인합니다.
중요

즉각적 업그레이드와 관련하여 특정 위험 및 알려진 문제가 있습니다. 예를 들어 일부 쿼리가 작동하지 않거나 업그레이드 전과 다른 순서로 실행됩니다. 이러한 위험 및 문제에 대한 자세한 내용과 인플레이스 업그레이드에 대한 일반적인 내용은 MariaDB 10.3 릴리스 노트 를 참조하십시오.

9.2.8. MariaDB 10.3에서 MariaDB 10.5로 업그레이드

이 부분에서는 RHEL 8 내의 MariaDB 10.3 에서 MariaDB 10.5 로의 마이그레이션에 대해 설명합니다.

9.2.8.1. MariaDB 10.3과 MariaDB 10.5의 주요 차이점

MariaDB 10.3과 MariaDB 10.5 간의 중요한 변경 사항은 다음과 같습니다.

  • 이제 MariaDB 에서 기본적으로 unix_socket 인증 플러그인을 사용합니다. 플러그인을 사용하면 로컬 UNIX 소켓 파일을 통해 MariaDB 에 연결할 때 운영 체제 자격 증명을 사용할 수 있습니다.
  • MariaDBmariadb-* 바이너리를 가리키는 바이너리와 mysql* 심볼릭 링크라는 mariadb-* 를 추가합니다. 예를 들어 mysqladmin,mysqlaccessmysqlshow symlink는 mariadb-admin,mariadb-accessmariadb-show 바이너리를 각각 가리킵니다.
  • SUPER 권한이 각 사용자 역할에 맞게 여러 권한으로 분할되었습니다. 결과적으로 특정 문이 필수 권한이 변경되었습니다.
  • 병렬 복제에서 slave_parallel_mode 는 이제 기본적으로 fake로 설정됩니다.
  • InnoDB 스토리지 엔진에서 다음 변수의 기본값이 변경되었습니다. innodb_adaptive_hash_indexOFF 로, innodb_checksum_algorithm에서 full_ crc32 로 변경되었습니다.
  • MariaDB 는 이전에 사용된 읽기라인 라이브러리 대신 MariaDB 명령 기록( .mysql_history 파일)을 관리하는 기본 소프트웨어의 libedit 구현을 사용합니다. 이 변경 사항은 .mysql_history 파일을 직접 사용하는 사용자에게 영향을 미칩니다. .mysql_historyMariaDB 또는 MySQL 애플리케이션에서 관리하는 파일이며 사용자는 파일에서 직접 작업해서는 안 됩니다. 사람이 읽을 수 있는 모양은 무의미합니다.

    참고

    보안을 강화하기 위해 기록 파일을 유지하지 않는 것이 좋습니다. 명령 기록 기록을 비활성화하려면 다음을 수행합니다.

    1. 있는 경우 .mysql_history 파일을 제거합니다.
    2. 다음 방법 중 하나를 사용합니다.

      • MYSQL_HISTFILE 변수를 /dev/null 로 설정하고 이 설정을 쉘의 시작 파일에 포함합니다.
      • /dev/null 로 심볼릭 링크로 .mysql_history 파일을 변경합니다.

        $ ln -s /dev/null $HOME/.mysql_history

MariaDB Galera Cluster 가 다음과 같은 주요 변경 사항으로 버전 4로 업그레이드되었습니다.

  • Galera 는 무제한 크기의 트랜잭션 복제를 지원하는 새로운 스트리밍 복제 기능을 추가합니다. 스트리밍 복제를 실행하는 동안 클러스터는 작은 조각으로 트랜잭션을 복제합니다.
  • Galera 는 이제 글로벌 트랜잭션 ID(GTID)를 완벽하게 지원합니다.
  • /etc/my.cnf.d/galera.cnf 파일의 wsrep_on 옵션의 기본값이 1 에서 0 으로 변경되어 추가 옵션을 구성하지 않고 최종 사용자가 wsrep 복제를 시작하지 않습니다.

MariaDB 10.5 의 PAM 플러그인 변경 사항은 다음과 같습니다.

  • MariaDB 10.5 에서는 새 버전의 PAM(Pluggable Authentication Modules) 플러그인을 추가합니다. PAM 플러그인 버전 2.0은 MariaDB 에서 추가 PAM 모듈을 사용할 수 있도록 별도의 setuid 루트 도우미 바이너리를 사용하여 PAM 인증을 수행합니다.
  • 도우미 바이너리는 mysql 그룹의 사용자만 실행할 수 있습니다. 기본적으로 그룹에는 mysql 사용자만 포함되어 있습니다. Red Hat은 이 도우미 유틸리티를 통해 액세스하거나 로깅하지 않고 관리자가 mysql 그룹에 사용자를 추가하지 않도록 권장합니다.
  • MariaDB 10.5 에서는 PAM(Pluggable Authentication Modules) 플러그인과 관련 파일이 새 패키지 mariadb-pam 으로 이동되었습니다. 결과적으로 MariaDB 에 PAM 인증을 사용하지 않는 새로운 setuid root 바이너리가 시스템에 소개되지 않았습니다.
  • mariadb-pam 패키지에는 PAM 플러그인 버전이 모두 포함되어 있습니다. 버전 2.0은 기본값이며 버전 1.0은 auth_pam_v1 공유 오브젝트 라이브러리로 사용할 수 있습니다.
  • mariadb-pam 패키지는 기본적으로 MariaDB 서버와 함께 설치되지 않습니다. MariaDB 10.5 에서 PAM 인증 플러그인을 사용하려면 mariadb-pam 패키지를 수동으로 설치합니다.

9.2.8.2. RHEL 8 버전의 MariaDB 10.3에서 MariaDB 10.5로 업그레이드

이 절차에서는 yummariadb -upgrade 유틸리티를 사용하여 mariadb:10.3 모듈 스트림에서 mariadb:10.5 모듈 스트림으로의 업그레이드를 설명합니다.

mariadb-upgrade 유틸리티는 mariadb-server 패키지의 종속성으로 설치된 mariadb-server- utils 하위 패키지에서 제공합니다.

사전 요구 사항

  • 업그레이드를 수행하기 전에 MariaDB 데이터베이스에 저장된 모든 데이터를 백업합니다.

절차

  1. MariaDB 서버를 중지합니다.

    # systemctl stop mariadb.service
  2. 다음 명령을 실행하여 시스템이 이후 스트림으로 전환할 준비가 되었는지 확인합니다.

    # yum distro-sync

    이 명령은 필요한 작업 없음 메시지로 끝나야 합니다. 완료되었습니다! 자세한 내용은 다음 스트림으로 전환을 참조하십시오.

  3. 시스템에서 mariadb 모듈을 재설정합니다.

    # yum module reset mariadb
  4. mariadb:10.5 모듈 스트림을 활성화합니다.

    # yum module enable mariadb:10.5
  5. 설치된 패키지를 동기화하여 스트림 간 변경을 수행합니다.

    # yum distro-sync

    그러면 설치된 모든 MariaDB 패키지가 업데이트됩니다.

  6. /etc/my.cnf.d/ 에 있는 옵션 파일에 MariaDB 10.5 에 유효한 옵션만 포함하도록 구성을 조정합니다. 자세한 내용은 MariaDB 10.4 및 MariaDB 10.5 의 업스트림 문서를 참조하십시오.
  7. MariaDB 서버를 시작합니다.

    • 독립 실행형으로 데이터베이스를 업그레이드하는 경우:

      # systemctl start mariadb.service
    • Galera 클러스터 노드를 업그레이드하는 경우 다음을 수행합니다.

      # galera_new_cluster

      mariadb 서비스가 자동으로 시작됩니다.

  8. mariadb-upgrade 유틸리티를 실행하여 내부 테이블을 확인하고 복구합니다.

    • 독립 실행형으로 데이터베이스를 업그레이드하는 경우:

      # mariadb-upgrade
    • Galera 클러스터 노드를 업그레이드하는 경우 다음을 수행합니다.

      # mariadb-upgrade --skip-write-binlog
중요

즉각적 업그레이드와 관련하여 특정 위험 및 알려진 문제가 있습니다. 예를 들어 일부 쿼리가 작동하지 않거나 업그레이드 전과 다른 순서로 실행됩니다. 이러한 위험 및 문제에 대한 자세한 내용과 인플레이스 업그레이드에 대한 일반적인 내용은 MariaDB 10.5 릴리스 노트 를 참조하십시오.

9.2.9. Galera를 사용하여 MariaDB 복제

이 섹션에서는 Red Hat Enterprise Linux 8에서 Galera 솔루션을 사용하여 MariaDB 데이터베이스를 복제하는 방법을 설명합니다.

9.2.9.1. MariaDB Galera 클러스터 소개

Galera 복제는 여러 MariaDB 서버로 구성된 동기 다중 소스 MariaDB Galera 클러스터 생성을 기반으로 합니다. 일반적으로 복제본이 읽기 전용인 기존의 기본/복제 설정과 달리 MariaDB Galera Cluster의 노드는 모두 쓸 수 있습니다.

Galera 복제와 MariaDB 데이터베이스 간의 인터페이스는 쓰기 세트 복제 API(wsrep API)로 정의됩니다.

MariaDB Galera 클러스터의 주요 기능은 다음과 같습니다.

  • 동기 복제
  • 액티브-액티브 멀티 소스 토폴로지
  • 클러스터 노드에 읽기 및 쓰기
  • 자동 멤버십 제어, 클러스터에서 실패한 노드 삭제
  • 자동 노드 결합
  • 행 수준에서 병렬 복제
  • 직접 클라이언트 연결: 사용자가 클러스터 노드에 로그온하고 복제가 실행되는 동안 노드에서 직접 작업할 수 있습니다.

동기 복제는 서버와 관련된 쓰기 집합을 클러스터의 모든 노드에 브로드캐스트하여 커밋 시 트랜잭션을 복제함을 의미합니다. 클라이언트(사용자 애플리케이션)는 기본 MariaDB 와 유사한 DBMS(데이터베이스 관리 시스템)에 직접 연결됩니다.

동기 복제를 사용하면 클러스터의 한 노드에서 동시에 발생한 변경 사항이 클러스터의 다른 노드에서 동시에 수행됩니다.

따라서 동기 복제는 비동기 복제에 비해 다음과 같은 이점이 있습니다.

  • 특정 클러스터 노드 간의 변경 사항을 전파하는 데 지연 없음
  • 모든 클러스터 노드는 항상 일관성이 유지됩니다.
  • 클러스터 노드 중 하나가 충돌하면 최신 변경 사항이 손실되지 않습니다.
  • 모든 클러스터 노드의 트랜잭션이 병렬로 실행됩니다.
  • 전체 클러스터의 원인

9.2.9.2. MariaDB Galera Cluster를 빌드하기 위한 구성 요소

MariaDB Galera 클러스터를 빌드하려면 시스템에 다음 패키지를 설치해야 합니다.

  • mariadb-server-galera - MariaDB Galera 클러스터에 대한 지원 파일 및 스크립트를 포함합니다.
  • mariadb-server - 쓰기 세트 복제 API(wsrep API)를 포함하도록 MariaDB 업스트림에서 패치합니다. 이 API는 Galera 복제와 MariaDB 간의 인터페이스를 제공합니다.
  • Galera - MariaDB를 완벽하게 지원하기 위해 MariaDB 업스트림에서 패치했습니다. galera 패키지에는 다음이 포함됩니다.

    • Galera Replication Library 는 전체 복제 기능을 제공합니다.
    • Galera Arbitrator 유틸리티를 분리 장애 시나리오의 투표에 참여하는 클러스터 멤버로 사용할 수 있습니다. 그러나 Galera Arbitrator 는 실제 복제에 참여할 수 없습니다.
    • Galera Systemd 서비스Galera 래퍼 스크립트 ( Galera), Galera Arbitrator 유틸리티를 배포하는 데 사용됩니다. RHEL 8의 MariaDB 10.3 및 MariaDB 10.5에는 각각 /usr/lib/systemd/system/garbd.service/usr/sbin/garbd-wrapper 파일의 Red Hat 버전의 garbd systemd 서비스 및 래퍼 스크립트가 포함되어 있습니다. RHEL 8.6, MariaDB 10.3 및 MariaDB 10.5부터 이제 /usr/share/doc/galera/garb-systemd/usr/share/doc/galera/garbd.service 에 있는 이러한 파일의 업스트림 버전도 제공합니다.

9.2.9.3. MariaDB Galera 클러스터 배포

사전 요구 사항

  • mariadb 모듈에서 스트림(버전)을 선택하고 galera 프로필을 지정하여 MariaDB Galera Cluster 패키지를 설치합니다. 예를 들면 다음과 같습니다.

    # {PackageManagerCommand} module install mariadb:10.3/galera

    결과적으로 다음 패키지가 설치됩니다.

    • mariadb-server-galera
    • mariadb-server
    • galera

      mariadb-server-galera 패키지는 mariadb-servergalera 패키지를 종속성으로 가져옵니다.

      MariaDB Galera Cluster 를 빌드하기 위해 설치해야 하는 패키지에 대한 자세한 내용은 MariaDB 클러스터 를 빌드하는 구성 요소를 참조하십시오.

  • MariaDB 서버 복제 구성은 시스템을 클러스터에 처음 추가하기 전에 업데이트해야 합니다.

    기본 구성은 /etc/my.cnf.d/galera.cnf 파일에 배포됩니다.

    MariaDB Galera 클러스터를 배포하기 전에 /etc/my.cnf.d/galera.cnf 파일에서 다음 문자열로 시작하도록 wsrep_cluster_address 옵션을 설정합니다.

    gcomm://
    • 초기 노드의 경우 wsrep_cluster_address 를 빈 목록으로 설정할 수 있습니다.

      wsrep_cluster_address="gcomm://"
    • 다른 모든 노드의 경우 실행 중인 클러스터의 일부인 모든 노드의 주소를 포함하도록 wsrep_cluster_address 를 설정합니다. 예를 들면 다음과 같습니다.

      wsrep_cluster_address="gcomm://10.0.0.10"

      Galera 클러스터 주소를 설정하는 방법에 대한 자세한 내용은 Galera Cluster Address 를 참조하십시오.

절차

  1. 해당 노드에서 다음 래퍼를 실행하여 새 클러스터의 첫 번째 노드를 부트스트랩합니다.

    # *galera_new_cluster*

    이 래퍼는 MariaDB 서버 데몬(mysqld)이 --wsrep-new-cluster 옵션과 함께 실행되도록 합니다. 이 옵션은 연결할 기존 클러스터가 없는 정보를 제공합니다. 따라서 노드는 새 클러스터를 식별하기 위해 새 UUID를 만듭니다.

    참고

    mariadb 서비스는 여러 MariaDB 서버 프로세스와 상호 작용하는 systemd 방법을 지원합니다. 따라서 MariaDB 서버가 여러 개 있는 경우 인스턴스 이름을 접미사로 지정하여 특정 인스턴스를 부트스트랩할 수 있습니다.

    # galera_new_cluster mariadb@node1
  2. 각 노드에서 다음 명령을 실행하여 다른 노드를 클러스터에 연결합니다.

    # systemctl start mariadb

    결과적으로 노드가 클러스터에 연결되고 클러스터 상태와 자체 동기화됩니다.

9.2.9.4. MariaDB Galera 클러스터에 새 노드 추가

MariaDB Galera 클러스터에 새 노드를 추가하려면 다음 절차를 사용합니다.

이 절차를 사용하여 기존 노드를 다시 연결할 수도 있습니다.

절차

  • 특정 노드에서 /etc/my.cnf.d/galera.cnf 구성 파일의 [mariadb] 섹션에 있는 wsrep_cluster_address 옵션에 있는 하나 이상의 기존 클러스터 구성원에게 주소를 제공하십시오.

    [mariadb]
    wsrep_cluster_address="gcomm://192.168.0.1"

    새 노드가 기존 클러스터 노드 중 하나에 연결되면 클러스터의 모든 노드를 볼 수 있습니다.

    그러나 클러스터의 모든 노드를 wsrep_cluster_address 에 나열하는 것이 좋습니다.

    결과적으로 하나 이상의 클러스터 노드가 중단된 경우에도 모든 노드가 다른 클러스터 노드에 연결하여 클러스터에 참여할 수 있습니다. 모든 멤버가 멤버십에 동의하면 클러스터 상태가 변경됩니다. 새 노드의 상태가 클러스터 상태와 다른 경우 새 노드는 증분 상태 전송(IST) 또는 SST(상태 스냅샷 전송)를 요청하여 다른 노드와 일관성을 보장합니다.

9.2.9.5. MariaDB Galera 클러스터 재시작

동시에 모든 노드를 종료하면 클러스터를 중지하고 실행 중인 클러스터가 더 이상 존재하지 않습니다. 그러나 클러스터의 데이터는 여전히 존재합니다.

클러스터를 다시 시작하려면 MariaDB Galera 클러스터 구성에 설명된 대로 첫 번째 노드를 부트스트랩합니다.

주의

클러스터가 부트스트랩되지 않고 첫 번째 노드의 mysqldsystemctl start mariadb 명령으로 시작된 경우 노드는 /etc/my.cnf.d/galera.cnf 파일의 wsrep_cluster_address 옵션에 나열된 노드 중 하나 이상에 연결하려고 합니다. 현재 실행 중인 노드가 없으면 재시작이 실패합니다.

9.3. MySQL 사용

MySQL 서버는 빠르고 강력한 오픈 소스 데이터베이스 서버입니다. 이 부분에서는 RHEL 시스템에 MySQL 을 설치하고 구성하는 방법, MySQL 데이터를 백업하는 방법, 이전 MySQL 버전에서 마이그레이션하는 방법 및 MySQL 을 복제하는 방법에 대해 설명합니다.

9.3.1. MySQL 시작하기

MySQL 은 데이터를 구조화된 정보로 변환하고 데이터에 액세스하기 위한 SQL 인터페이스를 제공하는 관계형 데이터베이스입니다. 여기에는 여러 스토리지 엔진 및 플러그인, GIS(지리적 정보 시스템) 및 JSON(JavaScript Object Notation) 기능이 포함됩니다.

이 부분에서는 다음을 설명합니다.

9.3.2. MySQL 설치

RHEL 8에서 MySQL 8.0 서버는 mysql:8.0 모듈 스트림으로 사용할 수 있습니다.

MySQL 을 설치하려면 다음 절차를 사용하십시오.

절차

  1. mysql 모듈에서 8.0 스트림(버전)을 선택하고 server 프로필을 지정하여 MySQL 서버 패키지를 설치합니다.

    # yum module install mysql:8.0/server
  2. mysqld 서비스를 시작합니다.

    # systemctl start mysqld.service
  3. 부팅 시 mysqld 서비스가 시작되도록 활성화합니다.

    # systemctl enable mysqld.service
  4. 권장 사항: MySQL 을 설치할 때 보안을 강화하려면 다음 명령을 실행합니다.

    $ mysql_secure_installation

    명령은 완전히 대화형 스크립트를 시작하여 프로세스의 각 단계에 대한 메시지를 표시합니다. 이 스크립트를 사용하면 다음과 같은 방법으로 보안을 강화할 수 있습니다.

    • root 계정의 암호 설정
    • 익명 사용자 제거
    • 원격 root 로그인 허용 (로컬 호스트 내부)
참고

충돌하는 RPM 패키지로 인해 RHEL 8에서 MySQLMariaDB 데이터베이스 서버를 병렬로 설치할 수 없습니다. RHEL 7용 Red Hat Software Collections에서는 구성 요소의 병렬 설치가 가능합니다. RHEL 8에서는 컨테이너에서 다른 버전의 데이터베이스 서버를 사용할 수 있습니다.

9.3.3. MySQL 구성

네트워킹을 위해 MySQL 서버를 구성하려면 다음 절차를 사용하십시오.

절차

  1. /etc/my.cnf.d/mysql-server.cnf 파일의 [mysqld] 섹션을 편집합니다. 다음 구성 지시문을 설정할 수 있습니다.

    • bind-address - 서버가 수신 대기하는 주소입니다. 가능한 옵션은 다음과 같습니다.

      • 호스트 이름
      • IPv4 주소
      • IPv6 주소
    • skip-networking - 서버가 TCP/IP 연결을 수신하는지 여부를 제어합니다. 가능한 값은 다음과 같습니다.

      • 0 - 모든 클라이언트 수신 대기
      • 1 - 로컬 클라이언트만 수신 대기
    • 포트 - MySQL 이 TCP/IP 연결을 수신 대기하는 포트입니다.
  2. mysqld 서비스를 다시 시작합니다.

    # systemctl restart mysqld.service

9.3.4. MySQL 데이터 백업

Red Hat Enterprise Linux 8의 MySQL 데이터베이스에서 데이터를 백업하는 방법에는 두 가지가 있습니다.

  • 논리적 백업
  • 물리적 백업

논리적 백업 은 데이터를 복원하는 데 필요한 SQL 문으로 구성됩니다. 이러한 유형의 백업은 일반 텍스트 파일로 정보와 레코드를 내보냅니다.

물리적 백업보다 논리적 백업의 주요 장점은 이식성과 유연성입니다. 데이터는 물리적 백업에서 사용할 수 없는 다른 하드웨어 구성, MySQL 버전 또는 DBMS(데이터베이스 관리 시스템)에서 복원할 수 있습니다.

mysqld.service 가 실행 중인 경우 논리적 백업을 수행할 수 있습니다. 논리적 백업에는 로그 및 구성 파일이 포함되지 않습니다.

물리적 백업 은 콘텐츠를 저장하는 파일과 디렉토리의 복사본으로 구성됩니다.

물리적 백업은 논리적 백업과 비교하여 다음과 같은 이점이 있습니다.

  • 출력이 더 작습니다.
  • 백업은 크기가 작습니다.
  • 백업 및 복원 속도가 빨라집니다.
  • 백업에는 로그 및 구성 파일이 포함됩니다.

mysqld.service 가 실행 중이 아니거나 백업 중 변경되지 않도록 데이터베이스의 모든 테이블이 잠길 때 물리적 백업을 수행해야 합니다.

다음 MySQL 백업 접근법 중 하나를 사용하여 MySQL 데이터베이스에서 데이터를 백업할 수 있습니다.

  • mysqldump를 사용한 논리적 백업
  • 파일 시스템 백업
  • 백업 솔루션으로의 복제

9.3.4.1. mysqldump를 사용하여 논리적 백업 수행

mysqldump 클라이언트는 백업 또는 다른 데이터베이스 서버로 전송을 위해 데이터베이스 또는 데이터베이스 컬렉션을 덤프하는 데 사용할 수 있는 백업 유틸리티입니다. mysqldump 의 출력은 일반적으로 서버 테이블 구조를 다시 생성하거나 데이터로 채우거나 둘 다로 채워지는 SQL 문으로 구성됩니다. mysqldump 는 CSV와 같은 XML 및 구분된 텍스트 형식을 포함하여 다른 형식의 파일을 생성할 수도 있습니다.

mysqldump 백업을 수행하려면 다음 옵션 중 하나를 사용할 수 있습니다.

  • 하나 이상의 선택된 데이터베이스 백업
  • 모든 데이터베이스 백업
  • 하나의 데이터베이스에서 테이블의 하위 집합 백업

절차

  • 단일 데이터베이스를 덤프하려면 다음을 실행합니다.

    # mysqldump [options] --databases db_name > backup-file.sql
  • 한 번에 여러 데이터베이스를 덤프하려면 다음을 실행합니다.

    # mysqldump [options] --databases db_name1 [db_name2 ...] > backup-file.sql
  • 모든 데이터베이스를 덤프하려면 다음을 실행합니다.

    # mysqldump [options] --all-databases > backup-file.sql
  • 하나 이상의 덤프된 전체 데이터베이스를 서버에 다시 로드하려면 다음을 실행합니다.

    # mysql < backup-file.sql
  • 데이터베이스를 원격 MySQL 서버에 로드하려면 다음을 실행합니다.

    # mysql --host=remote_host < backup-file.sql
  • 하나의 데이터베이스의 테이블 하위 집합을 덤프하려면 mysqldump 명령 끝에 선택한 테이블 목록을 추가합니다.

    # mysqldump [options] db_name [tbl_name ...] > backup-file.sql
  • 하나의 데이터베이스에서 덤프된 테이블의 하위 집합을 로드하려면 다음을 실행합니다.

    # mysql db_name < backup-file.sql
    참고

    db_name 데이터베이스는 이 시점에 있어야 합니다.

  • mysqldump 에서 지원하는 옵션 목록을 보려면 다음을 실행합니다.

    $ mysqldump --help

9.3.4.2. 파일 시스템 백업 수행

MySQL 데이터 파일의 파일 시스템 백업을 생성하려면 MySQL 데이터 디렉터리의 내용을 백업 위치에 복사합니다.

현재 구성 또는 로그 파일도 백업하려면 다음 절차의 선택적 단계를 사용하십시오.

절차

  1. mysqld 서비스를 중지합니다.

    # systemctl stop mysqld.service
  2. 필요한 위치에 데이터 파일을 복사합니다.

    # cp -r /var/lib/mysql /backup-location
  3. 필요한 경우 구성 파일을 필요한 위치에 복사합니다.

    # cp -r /etc/my.cnf /etc/my.cnf.d /backup-location/configuration
  4. 필요한 경우 로그 파일을 필요한 위치에 복사합니다.

    # cp /var/log/mysql/* /backup-location/logs
  5. mysqld 서비스를 시작합니다.

    # systemctl start mysqld.service
  6. 백업 위치에서 /var/lib/mysql 디렉터리에 백업 데이터를 로드할 때 mysql:mysql/var/lib/mysql 에 있는 모든 데이터의 소유자인지 확인하십시오.

    # chown -R mysql:mysql /var/lib/mysql

9.3.4.3. 백업 솔루션으로의 복제

복제는 소스 서버를 위한 대체 백업 솔루션입니다. 소스 서버에서 복제본 서버에 복제하는 경우 소스에 영향을 주지 않고 복제본에서 백업을 실행할 수 있습니다. 복제본을 종료하는 동안 계속 소스를 실행하고 복제본에서 데이터를 백업할 수 있습니다.

MySQL 데이터베이스를 복제하는 방법에 대한 지침은 MySQL 복제를 참조하십시오.

주의

복제 자체는 충분한 백업 솔루션이 아닙니다. 복제는 하드웨어 장애로부터 소스 서버를 보호하지만 데이터 손실에 대한 보호는 보장하지 않습니다. 이 메서드와 함께 복제본에서 다른 백업 솔루션을 사용하는 것이 좋습니다.

추가 리소스

9.3.5. RHEL 8 버전의 MySQL 8.0으로 마이그레이션

RHEL 7에는 MariaDB 5.5MySQL 데이터베이스 제품군에서 서버의 기본 구현으로 포함되어 있습니다. RHEL 7용 Red Hat Software Collections는 MySQL 8.0 과 여러 버전의 MariaDB 를 제공합니다. RHEL 8에서는 MySQL 8.0,MariaDB 10.3MariaDB 10.5 를 제공합니다.

다음 절차에서는 mysql_upgrade 유틸리티를 사용하여 MySQL 8.0 의 Red Hat Software Collections 버전에서 RHEL 8 버전의 MySQL 8.0 으로 마이그레이션하는 방법을 설명합니다. mysql_upgrade 유틸리티는 mysql-server 패키지에서 제공합니다.

참고

MySQL 의 Red Hat Software Collections 버전에서 소스 데이터 디렉터리는 /var/opt/rh/rh-mysql80/lib/mysql/ 입니다. RHEL 8에서 MySQL 데이터는 /var/lib/mysql/ 디렉터리에 저장됩니다.

사전 요구 사항

  • 업그레이드를 수행하기 전에 MySQL 데이터베이스에 저장된 모든 데이터를 백업합니다.

절차

  1. mysql-server 패키지가 RHEL 8 시스템에 설치되었는지 확인합니다.

    # yum install mysql-server
  2. 데이터를 복사할 때 mysqld 서비스가 소스 및 대상 시스템에서 실행되고 있지 않은지 확인합니다.

    # systemctl stop mysqld.service
  3. RHEL 7 소스 시스템의 /var/opt/rh/rh-mysql80/mysql/ 디렉터리에서 RHEL 8 대상 시스템의 /var/lib/mysql/ 디렉터리에 데이터를 복사합니다.
  4. 대상 시스템에서 복사된 파일에 대한 적절한 권한 및 SELinux 컨텍스트를 설정합니다.

    # restorecon -vr /var/lib/mysql
  5. mysql:mysql/var/lib/mysql 디렉터리에 있는 모든 데이터의 소유자인지 확인합니다.

    # chown -R mysql:mysql /var/lib/mysql
  6. 대상 시스템에서 MySQL 서버를 시작합니다.

    # systemctl start mysqld.service

    참고: 이전 버전의 MySQL 에서는 내부 테이블을 확인하고 복구하는 데 mysql_upgrade 명령이 필요했습니다. 이제 서버를 시작할 때 자동으로 수행됩니다.

9.3.6. MySQL 복제

MySQL 은 기본에서 고급까지 복제를 위한 다양한 구성 옵션을 제공합니다. 이 섹션에서는 GTID(Global transaction Identifiers)를 사용하여 새로 설치된 MySQL 서버에서 MySQL 에서 복제하는 트랜잭션 기반 방법에 대해 설명합니다. GTID를 사용하면 트랜잭션 식별 및 일관성 확인이 간소화됩니다.

MySQL 에서 복제를 설정하려면 다음을 수행해야 합니다.

중요

복제에 기존 MySQL 서버를 사용하려면 먼저 데이터를 동기화해야 합니다. 자세한 내용은 업스트림 문서 를 참조하십시오.

9.3.6.1. MySQL 소스 서버 구성

이 섹션에서는 MySQL 소스 서버가 올바르게 실행하고 데이터베이스 서버에서 수행된 모든 변경 사항을 복제하는 데 필요한 구성 옵션에 대해 설명합니다.

사전 요구 사항

  • 소스 서버가 설치되어 있어야 합니다.

절차

  1. [mysqld] 섹션의 /etc/my.cnf.d/mysql-server.cnf 파일에 다음 옵션을 포함합니다.

    • bind-address=source_ip_adress

      이 옵션은 복제본에서 소스로 구성된 연결에 필요합니다.

    • server-id=id

      id 는 고유해야 합니다.

    • log_bin=path_to_source_server_log

      이 옵션은 MySQL 소스 서버의 바이너리 로그 파일의 경로를 정의합니다. 예: log_bin=/var/log/mysql/mysql-bin.log.

    • gtid_mode=ON

      이 옵션을 사용하면 서버에서 글로벌 트랜잭션 식별자(GTID)를 사용할 수 있습니다.

    • enforce-gtid-consistency=ON

      서버는 GTID를 사용하여 안전하게 로깅할 수 있는 문만 실행할 수 있도록 하여 GTID 일관성을 적용합니다.

    • Optional: binlog_do_db=db_name

      선택한 데이터베이스만 복제하려면 이 옵션을 사용합니다. 두 개 이상의 선택된 데이터베이스를 복제하려면 각 데이터베이스를 별도로 지정합니다.

      binlog_do_db=db_name1
      binlog_do_db=db_name2
      binlog_do_db=db_name3
    • Optional: binlog_ignore_db=db_name

      복제에서 특정 데이터베이스를 제외하려면 이 옵션을 사용합니다.

  2. mysqld 서비스를 다시 시작합니다.

    # systemctl restart mysqld.service

9.3.6.2. MySQL 복제본 서버 구성

이 섹션에서는 성공적인 복제를 위해 MySQL 복제본 서버에 필요한 구성 옵션에 대해 설명합니다.

사전 요구 사항

  • 복제본 서버가 설치되어 있어야 합니다.

절차

  1. [mysqld] 섹션의 /etc/my.cnf.d/mysql-server.cnf 파일에 다음 옵션을 포함합니다.

    • server-id=id

      id 는 고유해야 합니다.

    • relay-log=path_to_replica_server_log

      릴레이 로그는 복제 중에 MySQL 복제본 서버에서 생성한 로그 파일 집합입니다.

    • log_bin=path_to_replica_sever_log

      이 옵션은 MySQL 복제본 서버의 바이너리 로그 파일에 대한 경로를 정의합니다. 예: log_bin=/var/log/mysql/mysql-bin.log.

      이 옵션은 복제본에 필요하지 않지만 강력히 권장됩니다.

    • gtid_mode=ON

      이 옵션을 사용하면 서버에서 글로벌 트랜잭션 식별자(GTID)를 사용할 수 있습니다.

    • enforce-gtid-consistency=ON

      서버는 GTID를 사용하여 안전하게 로깅할 수 있는 문만 실행할 수 있도록 하여 GTID 일관성을 적용합니다.

    • log-replica-updates=ON

      이 옵션을 사용하면 소스 서버에서 수신한 업데이트가 복제본의 바이너리 로그에 기록됩니다.

    • skip-replica-start=ON

      이 옵션을 사용하면 복제본 서버가 복제 서버가 시작될 때 복제 스레드를 시작하지 않습니다.

    • Optional: binlog_do_db=db_name

      특정 데이터베이스만 복제하려면 이 옵션을 사용합니다. 두 개 이상의 데이터베이스를 복제하려면 각 데이터베이스를 별도로 지정합니다.

      binlog_do_db=db_name1
      binlog_do_db=db_name2
      binlog_do_db=db_name3
    • Optional: binlog_ignore_db=db_name

      복제에서 특정 데이터베이스를 제외하려면 이 옵션을 사용합니다.

  2. mysqld 서비스를 다시 시작합니다.

    # systemctl restart mysqld.service

9.3.6.3. MySQL 소스 서버에서 복제 사용자 생성

복제 사용자를 생성하고 복제 트래픽에 필요한 이 사용자 권한을 부여해야 합니다. 다음 절차에서는 적절한 권한이 있는 복제 사용자를 만드는 방법을 설명합니다. 소스 서버에서만 이 단계를 실행합니다.

사전 요구 사항

절차

  1. 복제 사용자를 생성합니다.

    mysql> CREATE USER 'replication_user'@'replica_server_ip' IDENTIFIED WITH mysql_native_password BY 'password';
  2. 사용자 복제 권한을 부여합니다.

    mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'replica_server_ip';
  3. MySQL 데이터베이스에서 부여 테이블을 다시 로드합니다.

    mysql> FLUSH PRIVILEGES;
  4. 소스 서버를 읽기 전용 상태로 설정합니다.

    mysql> SET @@GLOBAL.read_only = ON;

9.3.6.4. 소스 서버에 복제본 서버 연결

MySQL 복제본 서버에서는 소스 서버의 자격 증명과 주소를 구성해야 합니다. 다음 절차에 따라 복제본 서버를 구현합니다.

사전 요구 사항

절차

  1. 복제본 서버를 읽기 전용 상태로 설정합니다.

    mysql> SET @@GLOBAL.read_only = ON;
  2. 복제 소스를 구성합니다.

    mysql> CHANGE REPLICATION SOURCE TO
        -> SOURCE_HOST='source_ip_address',
        -> SOURCE_USER='replication_user',
        -> SOURCE_PASSWORD='password',
        -> SOURCE_AUTO_POSITION=1;
  3. MySQL 복제본 서버에서 복제본 스레드를 시작합니다.

    mysql> START REPLICA;
  4. 소스 및 복제본 서버 둘 다에서 읽기 전용 상태를 설정 해제합니다.

    mysql> SET @@GLOBAL.read_only = OFF;
  5. 선택 사항: 디버깅 목적으로 복제본 서버의 상태를 검사합니다.

    mysql> SHOW REPLICA STATUS\G;
    참고

    복제본 서버가 시작하거나 연결하는 데 실패하면 SHOW MASTER STATUS 명령의 출력에 표시된 바이너리 로그 파일 위치에 따라 특정 이벤트 수를 건너뛸 수 있습니다. 예를 들어 정의된 위치에서 첫 번째 이벤트를 건너뛰십시오.

    mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;

    복제 서버를 다시 시작합니다.

  6. 선택 사항: 복제본 서버에서 복제본 스레드를 중지합니다.

    mysql> STOP REPLICA;

9.3.6.5. 검증 단계

  1. 소스 서버에서 예제 데이터베이스를 생성합니다.

    mysql> CREATE DATABASE test_db_name;
  2. test_db_name 데이터베이스가 복제본 서버에 복제되는지 확인합니다.
  3. 소스 또는 복제본 서버에서 다음 명령을 실행하여 MySQL 서버의 바이너리 로그 파일에 대한 상태 정보를 표시합니다.

    mysql> SHOW MASTER STATUS;

    소스에서 실행되는 트랜잭션에 대한 GTID 집합을 표시하는 Executed_Gtid_Set 열은 비어 있지 않아야 합니다.

    참고

    복제본 서버에서 SHOW SLAVE STATUS 를 사용할 때 동일한 GTID 세트가 Executed_Gtid_Set 행에 표시됩니다.

9.3.6.6. 추가 리소스

9.4. PostgreSQL 사용

PostgreSQL 서버는 SQL 언어를 기반으로 하는 강력하고 확장성이 뛰어난 오픈 소스 데이터베이스 서버입니다. 이 부분에서는 RHEL 시스템에 PostgreSQL 을 설치 및 구성하는 방법, PostgreSQL 데이터를 백업하는 방법 및 이전 PostgreSQL 버전에서 마이그레이션하는 방법을 설명합니다.

9.4.1. PostgreSQL 시작하기

PostgreSQL 서버는 오브젝트 관계형 데이터베이스 시스템을 제공하므로 광범위한 데이터 세트와 다수의 동시 사용자를 관리할 수 있습니다. 이러한 이유로 클러스터에서 PostgreSQL 서버를 사용하여 많은 양의 데이터를 관리할 수 있습니다.

PostgreSQL 서버에는 데이터 무결성을 보장하고 내결함성 환경을 구축하며 애플리케이션을 구축하는 기능이 포함되어 있습니다. 사용자가 데이터베이스를 다시 컴파일할 필요 없이 사용자의 데이터 형식, 사용자 지정 함수 또는 다른 프로그래밍 언어에서 코드를 사용하여 데이터베이스를 확장할 수 있습니다.

이 부분에서는 다음을 설명합니다.

9.4.2. PostgreSQL 설치

RHEL 8에서는 PostgreSQL 서버가 여러 버전에서 사용할 수 있으며 각각 별도의 스트림에서 제공됩니다.

  • PostgreSQL 10 - 기본 스트림
  • PostgreSQL 9.6
  • PostgreSQL 12 - RHEL 8.1.1 이후 사용 가능
  • PostgreSQL 13 - RHEL 8.4 이후 사용 가능
참고

설계상 동일한 모듈의 두 개 이상 버전(스트림)을 병렬로 설치할 수 없습니다. 따라서 postgresql 모듈에서 사용 가능한 스트림 중 하나만 선택해야 합니다. RHEL 7용 Red Hat Software Collections에서는 구성 요소의 병렬 설치가 가능합니다. RHEL 8에서는 컨테이너에서 다른 버전의 데이터베이스 서버를 사용할 수 있습니다.

PostgreSQL 을 설치하려면 다음 절차를 사용합니다.

절차

  1. postgresql 모듈에서 스트림(버전)을 선택하고 서버 프로필을 지정하여 PostgreSQL 서버 패키지를 설치합니다. 예를 들면 다음과 같습니다.

    # yum module install postgresql:13/server

    postgres 수퍼유저가 자동으로 생성됩니다.

  2. 데이터베이스 클러스터를 초기화합니다.

    # postgresql-setup --initdb

    Red Hat은 기본 /var/lib/pgsql/data 디렉터리에 데이터를 저장하는 것이 좋습니다.

  3. postgresql 서비스를 시작합니다.

    # systemctl start postgresql.service
  4. 부팅 시 시작되도록 postgresql 서비스를 활성화합니다.

    # systemctl enable postgresql.service

모듈 스트림 사용에 대한 자세한 내용은 사용자 공간 구성 요소 설치, 관리 및 제거를 참조하십시오.

중요

RHEL 8에서 이전 postgresql 스트림에서 업그레이드하려면 이후 스트림으로 전환에 설명된 두 절차를 따르십시오. 9.4.7절. “RHEL 8 버전의 PostgreSQL으로 마이그레이션”

9.4.3. PostgreSQL 사용자 생성

PostgreSQL 사용자는 다음과 같은 유형입니다.

  • postgres UNIX 시스템 사용자 - pg_dump 와 같은 PostgreSQL 서버 및 클라이언트 애플리케이션을 실행하는 데만 사용해야 합니다. 데이터베이스 생성 및 사용자 관리와 같은 PostgreSQL 관리에서는 postgres 시스템 사용자를 사용하지 마십시오.
  • 데이터베이스 슈퍼유저 - 기본 postgres PostgreSQL 슈퍼유저는 postgres 시스템 사용자와 관련이 없습니다. pg_hba.conf 파일에서 postgres 슈퍼 유저에 대한 액세스를 제한할 수 있고, 그렇지 않으면 다른 권한 제한은 없습니다. 다른 데이터베이스 수퍼유저도 만들 수 있습니다.
  • 특정 데이터베이스 액세스 권한이 있는 역할:

    • 데이터베이스 사용자 - 기본적으로 로그인할 수 있는 권한이 있습니다.
    • 사용자 그룹 - 그룹 전체에 대한 권한 관리를 활성화합니다.

역할은 데이터베이스 개체(예: 테이블 및 함수)를 소유하고 SQL 명령을 사용하여 다른 역할에 개체 권한을 할당할 수 있습니다.

표준 데이터베이스 관리 권한에는 SELECT,INSERT,UPDATE,DELETE,TRUNCATE,REFERENCES,TRIGGER,CREATE,CONNECT,TEMPORARY, EXECUTE, USAGE 등이 있습니다.

역할 속성은 LOGIN,SUPERUSER,CREATEDB 및 CREATE ROLE 과 같은 특수 권한입니다.

중요

대부분의 작업을 수퍼유저가 아닌 역할로 수행하는 것이 좋습니다. 일반적인 방법은 CREATEDB 및 CREATE ROLE 권한이 있는 역할을 생성하고 이 역할을 데이터베이스 및 역할의 모든 일상적인 관리에 사용하는 것입니다.

사전 요구 사항

  • PostgreSQL 서버가 설치되어 있어야 합니다.
  • 데이터베이스 클러스터가 초기화됩니다.

절차

  • 사용자를 만들려면 사용자의 암호를 설정하고 CREATEROLECREATEDB 권한을 사용자에게 할당합니다.

    postgres=# CREATE USER mydbuser WITH PASSWORD 'mypasswd' CREATEROLE CREATEDB;

    mydbuser 를 사용자 이름으로 바꾸고 mypasswd 를 사용자 암호로 교체합니다.

예 9.1. PostgreSQL 데이터베이스 초기화, 생성 및 연결

이 예제에서는 PostgreSQL 데이터베이스를 초기화하고 일상적인 데이터베이스 관리 권한이 있는 데이터베이스 사용자를 만드는 방법, 관리 권한이 있는 데이터베이스 사용자를 통해 모든 시스템 계정에서 액세스할 수 있는 데이터베이스를 만드는 방법을 보여줍니다.

  1. PosgreSQL 서버를 설치합니다.

    # yum module install postgresql:13/server
  2. 데이터베이스 클러스터를 초기화합니다.

    # postgresql-setup --initdb
    * Initializing database in '/var/lib/pgsql/data'
    * Initialized, logs are in /var/lib/pgsql/initdb_postgresql.log
  3. 암호 해시 알고리즘을 scram-sha-256 로 설정합니다.

    1. /var/lib/pgsql/data/postgresql.conf 파일에서 다음 행을 변경합니다.

      #password_encryption = md5              # md5 or scram-sha-256

      다음으로 변경합니다.

      password_encryption = scram-sha-256
    2. /var/lib/pgsql/data/pg_hba.conf 파일에서 IPv4 로컬 연결에 대해 다음 행을 변경합니다.

      host    all             all             127.0.0.1/32            ident

      다음으로 변경합니다.

      host    all             all             127.0.0.1/32            scram-sha-256
  4. postgresql 서비스를 시작합니다.

    # systemctl start postgresql.service
  5. postgres 라는 시스템 사용자로 로그인합니다.

    # su - postgres
  6. PostgreSQL 대화형 터미널을 시작합니다.

    $ psql
    psql (13.7)
    Type "help" for help.
    
    postgres=#
  7. 선택 사항: 현재 데이터베이스 연결에 대한 정보를 가져옵니다.

    postgres=# \conninfo
    You are connected to database "postgres" as user "postgres" via socket in "/var/run/postgresql" at port "5432".
  8. mydbuser 라는 사용자를 만들고, mydbuser 의 암호를 설정하고, mydbuserCREATEROLECREATEDB 권한을 할당합니다.

    postgres=# CREATE USER mydbuser WITH PASSWORD 'mypasswd' CREATEROLE CREATEDB;
    CREATE ROLE

    이제 mydbuser 사용자는 일상적인 데이터베이스 관리 작업을 수행할 수 있습니다: 데이터베이스를 생성하고 사용자 인덱스를 관리합니다.

  9. \q meta 명령을 사용하여 대화형 터미널에서 로그아웃합니다.

    postgres=# \q
  10. postgres 사용자 세션에서 로그아웃합니다.

    $ logout
  11. PostgreSQL 터미널에 mydbuser 로 로그인하고 호스트 이름을 지정하고 초기화 중에 생성된 기본 postgres 데이터베이스에 연결합니다.

    # psql -U mydbuser -h 127.0.0.1 -d postgres
    Password for user mydbuser:
    Type the password.
    psql (13.7)
    Type "help" for help.
    
    postgres=>
  12. mydatabase 라는 데이터베이스를 만듭니다.

    postgres=> CREATE DATABASE mydatabase;
    CREATE DATABASE
    postgres=>
  13. 세션에서 로그아웃합니다.

    postgres=# \q
  14. mydbuser 로 mydatabase에 연결합니다.

    # psql -U mydbuser -h 127.0.0.1 -d mydatabase
    Password for user mydbuser:
    psql (13.7)
    Type "help" for help.
    mydatabase=>
  15. 선택 사항: 현재 데이터베이스 연결에 대한 정보를 가져옵니다.

    mydatabase=> \conninfo
    You are connected to database "mydatabase" as user "mydbuser" on host "127.0.0.1" at port "5432".

9.4.4. PostgreSQL 구성

PostgreSQL 데이터베이스에서 모든 데이터 및 구성 파일은 데이터베이스 클러스터라는 단일 디렉터리에 저장됩니다. Red Hat은 기본 /var/lib/pgsql/data/ 디렉토리에 설정 파일을 포함한 모든 데이터를 저장할 것을 권장합니다.

PostgreSQL 구성은 다음 파일로 구성됩니다.

  • PostgreSQL.conf - 데이터베이스 클러스터 매개 변수를 설정하는 데 사용됩니다.
  • PostgreSQL .auto.conf - postgresql. conf 와 유사한 기본 PostgreSQL 설정을 보유합니다. 그러나 이 파일은 서버 제어 아래에 있습니다. 이 파일은SYSTEM 쿼리에 의해 편집되며 수동으로 편집할 수 없습니다.
  • pg_ident.conf - 외부 인증 메커니즘의 사용자 ID를 PostgreSQL 사용자 ID로 매핑하는 데 사용됩니다.
  • pg_hba.conf - PostgreSQL 데이터베이스의 클라이언트 인증을 구성하는 데 사용됩니다.

PostgreSQL 구성을 변경하려면 다음 절차를 사용하십시오.

절차

  1. 해당 구성 파일(예: /var/lib/pgsql/data/postgresql.conf )을 편집합니다.
  2. 변경 사항이 적용되도록 postgresql 서비스를 다시 시작합니다.

    # systemctl restart postgresql.service

예 9.2. PostgreSQL 데이터베이스 클러스터 매개변수 구성

이 예제에서는 /var/lib/pgsql/data/postgresql.conf 파일에서 데이터베이스 클러스터 매개변수의 기본 설정을 보여줍니다.

# This is a comment
log_connections = yes
log_destination = 'syslog'
search_path = '"$user", public'
shared_buffers = 128MB
password_encryption = scram-sha-256

예 9.3. PostgreSQL에서 클라이언트 인증 설정

이 예제에서는 /var/lib/pgsql/data/pg_hba.conf 파일에서 클라이언트 인증을 설정하는 방법을 보여줍니다.

# TYPE    DATABASE       USER        ADDRESS              METHOD
local     all            all                              trust
host      postgres       all         192.168.93.0/24      ident
host      all            all         .example.com         scram-sha-256

9.4.5. PostgreSQL 서버에서 TLS 암호화 구성

기본적으로 PostgreSQL 은 암호화되지 않은 연결을 사용합니다. 보다 안전한 연결의 경우 PostgreSQL 서버에서 TLS(Transport Layer Security) 지원을 활성화하고 암호화된 연결을 설정하도록 클라이언트를 구성할 수 있습니다.

사전 요구 사항

  • PostgreSQL 서버가 설치되어 있어야 합니다.
  • 데이터베이스 클러스터가 초기화됩니다.

절차

  1. OpenSSL 라이브러리를 설치합니다.

    # yum install openssl
  2. TLS 인증서 및 키를 생성합니다.

    # openssl req -new -x509 -days 365 -nodes -text -out server.crt \
      -keyout server.key -subj "/CN=dbhost.yourdomain.com"

    dbhost.yourdomain.com을 데이터베이스 호스트 및 도메인 이름으로 교체합니다.

  3. 서명된 인증서와 개인 키를 데이터베이스 서버의 필수 위치에 복사합니다.

    # cp server.{key,crt} /var/lib/pgsql/data/.
  4. 서명된 인증서와 개인 키의 소유자 및 그룹 소유권을 postgres 사용자로 변경합니다.

    # chown postgres:postgres /var/lib/pgsql/data/server.{key,crt}
  5. 소유자만 읽을 수 있도록 개인 키에 대한 권한을 제한합니다.

    # chmod 0400 /var/lib/pgsql/data/server.key
  6. /var/lib/pgsql/data/postgresql.conf 파일에서 다음 행을 변경하여 암호 해시 알고리즘을 scram-sha-256 으로 설정합니다.

    #password_encryption = md5              # md5 or scram-sha-256

    다음으로 변경합니다.

    password_encryption = scram-sha-256
  7. /var/lib/pgsql/data/postgresql.conf 파일에서 다음 행을 변경하여 SSL/TLS를 사용하도록 PostgreSQL을 구성합니다.

    #ssl = off

    다음으로 변경합니다.

    ssl=on
  8. /var/lib/pgsql/data/pg_hba.conf 파일에서 IPv4 로컬 연결에 대해 다음 행을 변경하여 TLS를 사용하는 클라이언트의 연결만 허용하도록 모든 데이터베이스에 대한 액세스를 제한합니다.

    host		all		all		127.0.0.1/32		ident

    다음으로 변경합니다.

    hostssl 	all		all		127.0.0.1/32		scram-sha-256

    또는 다음 새 행을 추가하여 단일 데이터베이스 및 사용자에 대한 액세스를 제한할 수 있습니다.

    hostssl	mydatabase	mydbuser	127.0.0.1/32		scram-sha-256

    mydatabase 를 데이터베이스 이름으로 바꾸고 mydbuser 를 사용자 이름으로 바꿉니다.

  9. postgresql 서비스를 다시 시작하여 변경 사항을 적용합니다.

    # systemctl restart postgresql.service

검증

  • 연결이 암호화되었는지 수동으로 확인하려면 다음을 수행하십시오.

    1. mydbuser 사용자로 PostgreSQL 데이터베이스에 연결하고 호스트 이름과 데이터베이스 이름을 지정합니다.

      $ psql -U mydbuser -h 127.0.0.1 -d mydatabase
      Password for user mydbuser:

      mydatabase 를 데이터베이스 이름으로 바꾸고 mydbuser 를 사용자 이름으로 바꿉니다.

    2. 현재 데이터베이스 연결에 대한 정보를 가져옵니다.

      mydbuser=> \conninfo
      You are connected to database "mydatabase" as user "mydbuser" on host "127.0.0.1" at port "5432".
      SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
  • PostgreSQL 에 대한 연결이 암호화되었는지 여부를 확인하는 간단한 애플리케이션을 작성할 수 있습니다. 이 예제에서는 libpq-devel 패키지에서 제공하는 libpq 클라이언트 라이브러리를 사용하는 C로 작성된 애플리케이션을 보여줍니다.

    #include <stdio.h>
    #include <stdlib.h>
    #include <libpq-fe.h>
    
    int main(int argc, char* argv[])
    {
    //Create connection
    PGconn* connection = PQconnectdb("hostaddr=127.0.0.1 password=mypassword port=5432 dbname=mydatabase user=mydbuser");
    
    if (PQstatus(connection) ==CONNECTION_BAD)
        {
        printf("Connection error\n");
        PQfinish(connection);
        return -1; //Execution of the program will stop here
        }
        printf("Connection ok\n");
        //Verify TLS
        if (PQsslInUse(connection)){
         printf("TLS in use\n");
         printf("%s\n", PQsslAttribute(connection,"protocol"));
        }
        //End connection
        PQfinish(connection);
        printf("Disconnected\n");
        return 0;
    }

    mypassword 를 암호, mydatabase 를 데이터베이스 이름으로, mydbuser 를 사용자 이름으로 바꿉니다.

    참고

    -l pq 옵션을 사용하여 컴파일할 pq 라이브러리를 로드해야 합니다. 예를 들어 GCC 컴파일러를 사용하여 애플리케이션을 컴파일하려면 다음을 수행합니다.

    $ gcc source_file.c -lpq -o myapplication

    여기서 source_file.c 에는 위의 예제 코드가 포함되어 있으며 myapplication 은 보안 PostgreSQL 연결을 확인하는 애플리케이션의 이름입니다.

예 9.4. TLS 암호화를 사용하여 PostgreSQL 데이터베이스 초기화, 생성 및 연결

이 예제에서는 PostgreSQL 데이터베이스를 초기화하고, 데이터베이스 사용자와 데이터베이스를 생성하며, 보안 연결을 사용하여 데이터베이스에 연결하는 방법을 보여줍니다.

  1. PosgreSQL 서버를 설치합니다.

    # yum module install postgresql:13/server
  2. 데이터베이스 클러스터를 초기화합니다.

    # postgresql-setup --initdb
    * Initializing database in '/var/lib/pgsql/data'
    * Initialized, logs are in /var/lib/pgsql/initdb_postgresql.log
  3. OpenSSL 라이브러리를 설치합니다.

    # yum install openssl
  4. TLS 인증서 및 키를 생성합니다.

    # openssl req -new -x509 -days 365 -nodes -text -out server.crt \
      -keyout server.key -subj "/CN=dbhost.yourdomain.com"

    dbhost.yourdomain.com을 데이터베이스 호스트 및 도메인 이름으로 교체합니다.

  5. 서명된 인증서와 개인 키를 데이터베이스 서버의 필수 위치에 복사합니다.

    # cp server.{key,crt} /var/lib/pgsql/data/.
  6. 서명된 인증서와 개인 키의 소유자 및 그룹 소유권을 postgres 사용자로 변경합니다.

    # chown postgres:postgres /var/lib/pgsql/data/server.{key,crt}
  7. 소유자만 읽을 수 있도록 개인 키에 대한 권한을 제한합니다.

    # chmod 0400 /var/lib/pgsql/data/server.key
  8. 암호 해시 알고리즘을 scram-sha-256 로 설정합니다. /var/lib/pgsql/data/postgresql.conf 파일에서 다음 행을 변경합니다.

    #password_encryption = md5              # md5 or scram-sha-256

    다음으로 변경합니다.

    password_encryption = scram-sha-256
  9. SSL/TLS를 사용하도록 PostgreSQL을 구성합니다. /var/lib/pgsql/data/postgresql.conf 파일에서 다음 행을 변경합니다.

    #ssl = off

    다음으로 변경합니다.

    ssl=on
  10. postgresql 서비스를 시작합니다.

    # systemctl start postgresql.service
  11. postgres 라는 시스템 사용자로 로그인합니다.

    # su - postgres
  12. postgres 사용자로 PostgreSQL 대화형 터미널을 시작합니다.

    $ psql -U postgres
    psql (13.7)
    Type "help" for help.
    
    postgres=#
  13. mydbuser 라는 사용자를 생성하고 mydbuser 의 암호를 설정합니다.

    postgres=# CREATE USER mydbuser WITH PASSWORD 'mypasswd';
    CREATE ROLE
    postgres=#
  14. mydatabase 라는 데이터베이스를 만듭니다.

    postgres=# CREATE DATABASE mydatabase;
    CREATE DATABASE
    postgres=#
  15. mydbuser 사용자에게 모든 권한을 부여합니다.

    postgres=# GRANT ALL PRIVILEGES ON DATABASE mydatabase TO mydbuser;
    GRANT
    postgres=#
  16. 대화형 터미널에서 로그아웃합니다.

    postgres=# \q
  17. postgres 사용자 세션에서 로그아웃합니다.

    $ logout
  18. /var/lib/pgsql/data/pg_hba.conf 파일에서 IPv4 로컬 연결에 대해 다음 행을 변경하여 TLS를 사용하는 클라이언트의 연결만 허용하도록 모든 데이터베이스에 대한 액세스를 제한합니다.

    host		all		all		127.0.0.1/32		ident

    다음으로 변경합니다.

    hostssl 	all		all		127.0.0.1/32		scram-sha-256
  19. postgresql 서비스를 다시 시작하여 변경 사항을 적용합니다.

    # systemctl restart postgresql.service
  20. mydbuser 사용자로 PostgreSQL 데이터베이스에 연결하고 호스트 이름과 데이터베이스 이름을 지정합니다.

    $ psql -U mydbuser -h 127.0.0.1 -d mydatabase
    Password for user mydbuser:
    psql (13.7)
    SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
    Type "help" for help.
    
    mydatabase=>

9.4.6. PostgreSQL 데이터 백업

PostgreSQL 데이터를 백업하려면 다음 방법 중 하나를 사용합니다.

SQL dump
SQL 덤프로 백업 을 참조하십시오.
파일 시스템 수준 백업
파일 시스템 수준 백업을 참조하십시오.
연속 보관
연속 보관을 참조하십시오.

9.4.6.1. SQL 덤프를 사용하여 PostgreSQL 데이터 백업

SQL 덤프 방법은 SQL 명령으로 덤프 파일을 생성하는 방법을 기반으로 합니다. 덤프가 데이터베이스 서버에 다시 업로드되면 덤프 시와 동일한 상태로 데이터베이스를 다시 생성합니다.

SQL 덤프는 다음 PostgreSQL 클라이언트 애플리케이션에서 확인합니다.

  • pg_dump 는 역할 또는 테이블 공간에 대한 클러스터 전체 정보 없이 단일 데이터베이스를 덤프합니다.
  • pg_dumpall 은 지정된 클러스터의 각 데이터베이스를 덤프하고 역할 및 테이블 공간 정의와 같은 클러스터 전체 데이터를 유지합니다.

기본적으로 pg_dumppg_dumpall 명령은 결과를 표준 출력에 씁니다. 덤프를 파일에 저장하려면 출력을 SQL 파일로 리디렉션합니다. 결과 SQL 파일은 병렬 처리를 허용하는 텍스트 형식 또는 다른 형식으로 되어 있고 개체 복원을 보다 자세히 제어할 수 있습니다.

데이터베이스에 액세스할 수 있는 모든 원격 호스트에서 SQL 덤프를 수행할 수 있습니다.

9.4.6.1.1. SQL 덤프의 장점 및 단점

SQL 덤프에는 다른 PostgreSQL 백업 방법과 비교하여 다음과 같은 이점이 있습니다.

  • SQL 덤프는 서버 버전별이 아닌 유일한 PostgreSQL 백업 방법입니다. pg_dump 유틸리티의 출력은 파일 시스템 수준 백업 또는 연속 아카이브에서는 사용할 수 없는 최신 버전의 PostgreSQL 로 다시 로드할 수 있습니다.
  • SQL 덤프는 32비트에서 64비트 서버로 이동하는 등 데이터베이스를 다른 시스템 아키텍처로 전송할 때 작동하는 유일한 방법입니다.
  • SQL 덤프는 내부적으로 일관된 덤프를 제공합니다. 덤프는 pg_dump 가 실행을 시작한 시점에 데이터베이스의 스냅샷을 나타냅니다.
  • pg_dump 유틸리티는 실행 시 데이터베이스의 다른 작업을 차단하지 않습니다.

SQL 덤프의 단점은 파일 시스템 수준 백업에 비해 더 많은 시간이 필요하다는 것입니다.

9.4.6.1.2. pg_dump를 사용하여 SQL 덤프 수행

클러스터 전체 정보 없이 단일 데이터베이스를 덤프하려면 pg_dump 유틸리티를 사용합니다.

사전 요구 사항

  • 덤프하려는 모든 테이블에 대한 읽기 액세스 권한이 있어야 합니다. 전체 데이터베이스를 덤프하려면 postgres superuser 또는 데이터베이스 관리자 권한이 있는 사용자로 명령을 실행해야 합니다.

절차

  • 클러스터 전체 정보가 없는 데이터베이스를 덤프합니다.

    $ pg_dump dbname > dumpfile

연결할 데이터베이스 서버 pg_dump 를 지정하려면 다음 명령줄 옵션을 사용합니다.

  • 호스트를 정의하는 -h 옵션.

    기본 호스트는 로컬 호스트이거나 PPP HOST 환경 변수에 의해 지정된 항목입니다.

  • 포트를 정의하는 -p 옵션.

    기본 포트는 PPP PORT 환경 변수 또는 컴파일된 기본값에 의해 표시됩니다.

9.4.6.1.3. pg_dumpall을 사용하여 SQL 덤프 수행

지정된 데이터베이스 클러스터에서 각 데이터베이스를 덤프하고 클러스터 전체 데이터를 보존하려면 pg_dumpall 유틸리티를 사용합니다.

사전 요구 사항

  • postgres 수퍼유저 또는 데이터베이스 관리자 권한이 있는 사용자로 명령을 실행해야 합니다.

절차

  • 데이터베이스 클러스터의 모든 데이터베이스를 덤프하고 클러스터 전체 데이터를 보존합니다.

    $ pg_dumpall > dumpfile

연결할 데이터베이스 서버 pg_dumpall 을 지정하려면 다음 명령줄 옵션을 사용합니다.

  • 호스트를 정의하는 -h 옵션.

    기본 호스트는 로컬 호스트이거나 PPP HOST 환경 변수에 의해 지정된 항목입니다.

  • 포트를 정의하는 -p 옵션.

    기본 포트는 PPP PORT 환경 변수 또는 컴파일된 기본값에 의해 표시됩니다.

  • 기본 데이터베이스를 정의하는 -l 옵션.

    이 옵션을 사용하면 초기화 중에 자동으로 생성된 postgres 데이터베이스와 다른 기본 데이터베이스를 선택할 수 있습니다.

9.4.6.1.4. pg_dump를 사용하여 덤프된 데이터베이스 복원

pg_dump 유틸리티를 사용하여 덤프한 SQL 덤프에서 데이터베이스를 복원하려면 아래 단계를 수행하십시오.

사전 요구 사항

  • postgres 수퍼유저 또는 데이터베이스 관리자 권한이 있는 사용자로 명령을 실행해야 합니다.

절차

  1. 새 데이터베이스를 생성합니다.

    $ createdb dbname
  2. 덤프된 데이터베이스의 오브젝트에 대한 권한을 소유하고 있거나 권한이 부여된 모든 사용자에게 이미 있는지 확인합니다. 이러한 사용자가 없는 경우 복원에서 원래 소유권 및 권한을 가진 오브젝트를 다시 생성할 수 없습니다.
  3. psql 유틸리티를 실행하여 pg_dump 유틸리티에서 생성한 텍스트 파일 덤프를 복원합니다.

    $ psql dbname < dumpfile

    여기에서 dumpfilepg_dump 명령의 출력입니다. 텍스트가 아닌 파일 덤프를 복원하려면 대신 pg_restore 유틸리티를 사용합니다.

    $ pg_restore non-plain-text-file
9.4.6.1.5. pg_dumpall을 사용하여 덤프된 데이터베이스 복원

pg_dumpall 유틸리티를 사용하여 덤프한 데이터베이스 클러스터에서 데이터를 복원하려면 아래 단계를 따르십시오.

사전 요구 사항

  • postgres 수퍼유저 또는 데이터베이스 관리자 권한이 있는 사용자로 명령을 실행해야 합니다.

절차

  1. 덤프된 데이터베이스의 개체에 대한 권한을 소유하고 있거나 권한이 부여된 모든 사용자가 이미 있는지 확인합니다. 이러한 사용자가 없는 경우 복원에서 원래 소유권 및 권한을 가진 오브젝트를 다시 생성할 수 없습니다.
  2. psql 유틸리티를 실행하여 pg_dumpall 유틸리티로 생성된 텍스트 파일 덤프를 복원합니다.

    $ psql < dumpfile

    여기에서 dumpfilepg_dumpall 명령의 출력입니다.

9.4.6.1.6. 다른 서버에서 데이터베이스의 SQL 덤프 수행

pg_dumppsql 은 파이프로 쓰고 읽을 수 있기 때문에 한 서버에서 다른 서버로 직접 데이터베이스를 덤프할 수 있습니다.

절차

  • 한 서버에서 다른 서버로 데이터베이스를 덤프하려면 다음을 실행합니다.

    $ pg_dump -h host1 dbname | psql -h host2 dbname
9.4.6.1.7. 복원 중 SQL 오류 처리

기본적으로 SQL 오류가 발생하는 경우 psql 이 계속 실행되므로 데이터베이스가 부분적으로만 복원됩니다.

기본 동작을 변경하려면 덤프를 복원할 때 다음 방법 중 하나를 사용합니다.

사전 요구 사항

  • postgres 수퍼유저 또는 데이터베이스 관리자 권한이 있는 사용자로 명령을 실행해야 합니다.

절차

  • ON_ERROR_STOP 변수를 설정하여 SQL 오류가 발생하는 경우 psql 종료 상태로 3을 종료합니다.

    $ psql --set ON_ERROR_STOP=on dbname < dumpfile

  • 복원이 완전히 완료되거나 취소되도록 전체 덤프가 단일 트랜잭션으로 복원되도록 지정합니다.

    • psql 유틸리티를 사용하여 텍스트 파일 덤프를 복원하는 경우:

      $ psql -1
    • pg_restore 유틸리티를 사용하여 텍스트가 아닌 파일 덤프를 복원하는 경우:

      $ pg_restore -e

      이 방법을 사용할 때 사소한 오류도 여러 시간 동안 이미 실행된 복원 작업을 취소할 수 있습니다.

9.4.6.1.8. 추가 리소스

9.4.6.2. 파일 시스템 수준 백업을 사용하여 PostgreSQL 데이터 백업

파일 시스템 수준 백업을 생성하려면 PostgreSQL 데이터베이스 파일을 다른 위치에 복사합니다. 예를 들어 다음 방법을 사용할 수 있습니다.

  • tar 유틸리티를 사용하여 아카이브 파일을 만듭니다.
  • rsync 유틸리티를 사용하여 파일을 다른 위치에 복사합니다.
  • 데이