| 탐색 링크 건너뛰기 | |
| 인쇄 보기 종료 | |
|
Oracle Solaris 관리: 네트워크 서비스 Oracle Solaris 11 Information Library (한국어) |
| 탐색 링크 건너뛰기 | |
| 인쇄 보기 종료 | |
|
|
Oracle Solaris 관리: 네트워크 서비스 Oracle Solaris 11 Information Library (한국어) |
autofs에서 탐색 프로세스를 시작하는 방법(마스터 맵)
autofs에서 클라이언트에 대해 가장 가까운 읽기 전용 파일을 선택하는 방법(여러 위치)
autofs가 네트워크를 탐색하는 방법 수정(맵 수정)
다음 절에서는 NFS 소프트웨어의 몇 가지 복잡한 기능에 대해 설명합니다. 이 절의 일부 기능 설명은 NFS 버전 4에 배타적입니다.
주 - 시스템에서 영역이 사용으로 설정된 경우 비전역 영역에서 이 기능을 사용하려면 Oracle Solaris 관리: Oracle Solaris Zones, Oracle Solaris 10 Zones 및 리소스 관리에서 자세한 내용을 참조하십시오.
NFS 초기화 프로세스에는 서버 및 클라이언트의 프로토콜 레벨 협상이 포함됩니다. 버전 레벨을 지정하지 않으면 최상의 레벨이 기본적으로 선택됩니다. 예를 들어 클라이언트와 서버가 모두 버전 3을 지원할 수 있으면 버전 3이 사용됩니다. 클라이언트나 서버 중 하나만 버전 3을 지원할 수 있으면 버전 2가 사용됩니다.
sharectl 명령을 사용하여 client_versmin , client_versmax, server_versmin 및 server_versmax 매개변수를 설정할 수 있습니다. 서버와 클라이언트에 대해 지정된 최소값 및 최대값은 이 키워드의 기본값을 교체합니다. 클라이언트와 서버 둘 다에 대해 기본 최소값은 2이고 기본 최대값은 4입니다. 서버에서 지원하는 버전을 찾기 위해 NFS 클라이언트는 먼저 client_versmax의 설정을 확인한 다음 client_versmin의 버전 설정에 도달할 때까지 각 버전을 계속 시도해 봅니다. 지원되는 버전을 찾는 즉시 프로세스가 종료됩니다. 예를 들어 client_versmax =4이고 client_versmin =2이면 클라이언트는 버전 4를 먼저 시도한 후에 버전 3, 버전 2 순으로 시도합니다. client_versmax 및 client_versmax를 같은 값으로 설정하면 클라이언트는 항상 해당 버전을 사용하며 다른 버전을 시도하지 않습니다. 서버에서 해당 버전을 제공하지 않으면 마운트가 실패합니다.
절차 정보는 NFS 서비스 설정을 참조하십시오.
NFS 버전 4에서는 다양한 항목이 변경되었습니다. 이 절에서는 이러한 새 기능에 대해 설명합니다.
주 - Solaris 10 릴리스부터는 NFS 버전 4가 LIPKEY/SPKM 보안 종류를 지원하지 않습니다. 또한 NFS 버전 4에서는 mountd, nfslogd 및 statd 데몬을 사용하지 않습니다.
NFS 버전 4 사용과 관련된 절차 정보는 NFS 서비스 설정을 참조하십시오.
NFS 버전 3 및 버전 4가 모두 있는 경우 클라이언트가 공유 해제된 파일 시스템에 액세스하려고 하면 서버가 오류 코드로 응답을 보냅니다. 그러나 NFS 버전 3에서는 파일 시스템 공유를 해제하기 전에 클라이언트가 얻은 잠금을 서버에서 유지 관리합니다. 따라서 파일 시스템을 다시 공유하면 NFS 버전 3 클라이언트는 파일 시스템 공유를 해제한 적이 없었던 것처럼 파일 시스템에 액세스할 수 있습니다.
NFS 버전 4를 사용하는 경우 파일 시스템 공유를 해제하면 해당 파일 시스템의 모든 파일 잠금 또는 열린 파일 상태가 삭제됩니다. 클라이언트가 이러한 파일 또는 잠금에 액세스하려고 하면 오류가 표시됩니다. 이 오류는 보통 응용 프로그램에 대한 I/O 오류로 보고됩니다. 그러나 옵션을 변경하기 위해 현재 공유된 파일 시스템을 다시 공유해도 서버의 상태가 삭제되지는 않습니다.
관련 정보는 NFS 버전 4의 클라이언트 복구 또는 unshare_nfs(1M) 매뉴얼 페이지를 참조하십시오.
NFS 버전 4 서버는 의사 파일 시스템을 만들고 유지 관리합니다. 따라서 클라이언트가 서버의 모든 내보낸 개체에 원활하게 액세스할 수 있습니다. NFS 버전 4 이전에는 의사 파일 시스템이 없었습니다. 즉, 클라이언트는 액세스할 각 공유 서버 파일 시스템을 강제로 마운트해야 했습니다. 다음 예를 고려하십시오.
그림 6-2 서버 파일 시스템 및 클라이언트 파일 시스템 보기
클라이언트는 payroll 디렉토리 및 nfs4x 디렉토리를 볼 수 없습니다. 이러한 디렉토리는 내보내기되지 않으므로 내보낸 디렉토리에 포함되지 않기 때문입니다. 그러나 local 디렉토리는 클라이언트에 표시됩니다. local은 내보낸 디렉토리이기 때문입니다. projects 디렉토리는 클라이언트에 표시됩니다. projects는 내보낸 디렉토리(nfs4)에 포함되기 때문입니다. 따라서 명시적으로 내보내지 않은 서버 네임스페이스 부분은 내보낸 디렉토리 및 서버 내보내기에 포함되는 디렉토리만 표시되는 의사 파일 시스템에 브릿지됩니다.
의사 파일 시스템은 디렉토리만 포함하는 구조로, 서버에서 만들어집니다. 의사 파일 시스템에서는 클라이언트가 내보낸 파일 시스템의 계층을 찾아볼 수 있도록 합니다. 따라서, 클라이언트의 의사 파일 시스템 보기는 내보낸 파일 시스템에 포함되는 경로로 한정됩니다.
이전 NFS 버전에서는 각 파일 시스템을 마운트하지 않으면 클라이언트가 서버 파일 시스템을 순회할 수 없습니다. 그러나 NFS 버전 4에서는 서버 네임스페이스가 다음을 수행합니다.
클라이언트의 파일 시스템 보기를 서버 내보내기에 포함되는 디렉토리로 제한합니다.
클라이언트가 각 기본 파일 시스템을 마운트하지 않고도 서버 내보내기에 원활하게 액세스할 수 있도록 합니다. 이전 예제를 참조하십시오. 그러나 각 운영 체제에 따라 클라이언트가 각 서버 파일 시스템을 마운트해야 할 수도 있습니다.
POSIX 관련 이유로 인해, Oracle Solaris NFS 버전 4 클라이언트에서는 서버 파일 시스템 경계를 교차하지 않습니다. 이러한 시도를 하는 경우 클라이언트는 디렉토리가 비어 있는 것으로 표시되도록 합니다. 이러한 상황을 완화하려면 서버의 각 파일 시스템에 대해 마운트를 수행해야 합니다.
파일 핸들은 서버에서 만들어지며 파일 및 디렉토리를 고유하게 식별하는 정보를 포함합니다. NFS 버전 2 및 3에서는 서버가 지속 파일 핸들을 반환합니다. 그러므로 클라이언트는 서버가 항상 동일 파일을 참조하는 파일 핸들을 생성하도록 보장할 수 있습니다. 예를 들면 다음과 같습니다.
파일을 삭제한 다음 이름이 같은 파일로 교체하는 경우네는 서버에서 새 파일에 대해 새 파일 핸들을 생성합니다. 클라이언트가 이전 파일 핸들을 사용한 경우에는 서버에서 파일 핸들이 사용되지 않는다는 오류를 반환합니다.
파일 이름을 바꾼 경우에도 파일 핸들이 동일하게 유지됩니다.
서버를 재부트해야 하는 경우에도 파일 핸들은 동일하게 유지됩니다.
그러므로 서버에서 파일 핸들을 포함하는 클라이언트로부터의 요청을 받은 경우 파일이 즉시 확인되며 파일 핸들이 항상 올바른 파일을 참조합니다.
대부분의 UNIX 기반 서버에서는 이와 같은 NFS 작업에 대한 파일 및 디렉토리 식별 방법을 사용할 수 있었습니다. 그러나 파일 경로 이름 등의 다른 식별 방법을 사용했던 서버에서는 이 방법을 구현할 수 없습니다. 이 문제를 해결하려면 NFS 버전 4 프로토콜에서는 서버가 해당 파일 핸들이 휘발성임을 선언하도록 허용합니다. 따라서 파일 핸들이 변경될 수 있습니다. 파일 핸들이 변경되면 클라이언트는 새 파일 핸들을 찾아야 합니다.
NFS 버전 2 및 3에서와 같이, Oracle Solaris NFS 버전 4 서버에서는 항상 지속 파일 핸들을 제공합니다. 그러나 Solaris NFS 버전 4 이외의 서버에 액세스하는 Oracle Solaris NFS 버전 4 클라이언트는 휘발성 파일 핸들(서버에서 사용하는 경우)을 지원해야 합니다. 구체적으로, 서버에서 파일 핸들이 휘발성임을 클라이언트에 알리면 클라이언트는 경로 이름과 파일 핸들 간 매핑을 캐시해야 합니다. 클라이언트는 휘발성 파일 핸들을 만료될 때까지 사용합니다. 핸들 만료 시에는 클라이언트가 다음을 수행합니다.
해당 파일 핸들을 참조하는 캐시된 정보를 비웁니다.
해당 파일의 새 파일 핸들을 검색합니다.
작업을 재시도합니다.
주 - 서버는 지속 파일 핸들과 휘발성 파일 핸들을 항상 클라이언트에 알려 줍니다.
휘발성 파일 핸들은 다음과 같은 이유로 만료될 수 있습니다.
파일을 닫을 때
파일 핸들의 파일 시스템을 마이그레이션할 때
클라이언트가 파일 이름을 바꿀 때
서버를 재부트할 때
클라이언트가 새 파일 핸들을 찾을 수 없으면 syslog 파일에 오류 메시지가 기록됩니다. 이 파일에 액세스하려는 추가 시도는 실패하고 I/O 오류가 발생합니다.
NFS 버전 4 프로토콜은 stateful 프로토콜입니다. 클라이언트와 서버가 모두 다음에 대한 현재 정보를 유지 관리하는 경우 프로토콜은 Stateful 상태입니다.
파일 열기
파일 잠금
서버 충돌 등의 오류가 발생하면 클라이언트와 서버가 함께 작동하여 오류 전에 존재했던 열기 및 잠금 상태를 재설정합니다.
서버가 충돌하여 재부트되면 서버 상태가 손실됩니다. 클라이언트는 서버가 재부트되었음을 감지하고 서버의 상태 재구성 지원 과정을 시작합니다. 클라이언트가 프로세스를 진행하므로 이 프로세스를 클라이언트 복구라고 합니다.
클라이언트는 서버가 재부트되었음을 확인하면 현재 작업을 즉시 일시 중지하고 클라이언트 복구 프로세스를 시작합니다. 복구 프로세스가 시작되면 다음과 같은 메시지가 시스템 오류 로그 /var/adm/messages에 표시됩니다.
NOTICE: Starting recovery server basil.example.company.com
복구 프로세스 중에 클라이언트는 이전 클라이언트 상태에 대한 정보를 서버로 보냅니다. 그러나 이 기간 중에 클라이언트는 서버로 새 요청을 보내지 않습니다. 파일을 열거나 파일 잠금을 설정하는 새 요청은 서버의 복구 기간이 완료될 때까지 기다린 후에 진행됩니다.
클라이언트 복구 프로세스가 완료되면 다음 메시지가 시스템 오류 로그 /var/adm/messages에 표시됩니다.
NOTICE: Recovery done for server basil.example.company.com
그러면 상태 메시지를 서버로 보내는 클라이언트의 작업이 정상적으로 완료된 것입니다. 그러나 클라이언트에서 이 프로세스를 완료했더라도 다른 클라이언트에서 서버로 상태 정보를 보내는 프로세스를 완료하지 않았을 수 있습니다. 따라서 일정 시간 동안 서버는 열기 또는 잠금 요청을 수락하지 않습니다. 이 기간(유예 기간이라고도 함)은 모든 클라이언트가 복구를 완료할 수 있도록 지정됩니다.
유예 기간 동안 클라이언트가 새 파일을 열거나 새 잠금을 설정하려고 시도하면 서버에서 요청을 거부하고 GRACE 오류 코드를 표시합니다. 이 오류를 받으면 클라이언트는 유예 기간이 종료될 때까지 기다렸다가 서버로 요청을 다시 보내야 합니다. 유예 기간 동안에는 다음 메시지가 표시됩니다.
NFS server recovering
유예 기간 동안에도 파일을 열지 않거나 파일 잠금을 설정하지 않는 명령은 계속 실행할 수 있습니다. 예를 들어 ls 및 cd 명령은 파일을 열거나 파일 잠금을 설정하지 않습니다. 따라서 이러한 명령은 일시 중지되지 않습니다. 그러나 파일을 여는 cat 등의 명령은 유예 기간이 종료될 때까지 일시 중지됩니다.
유예 기간이 종료되면 다음 메시지가 표시됩니다.
NFS server recovery ok.
그러면 클라이언트는 새 열기 및 잠금 요청을 서버로 보낼 수 있습니다.
클라이언트 복구는 여러 가지 이유로 실패할 수 있습니다. 예를 들어 서버 재부트 후 네트워크 파티션이 있는 경우 클라이언트가 유예 기간 종료 전에 서버와의 상태를 재설정하지 못할 수 있습니다. 유예 기간이 종료되어도 서버는 클라이언트가 상태를 재설정하도록 허용하지 않습니다. 새 상태 작업으로 인해 충돌이 발생할 수 있기 때문입니다. 예를 들어 새 파일 잠금이 클라이언트에서 복구하려고 하는 이전 파일 잠금과 충돌할 수 있습니다. 이러한 상황이 발생하면 서버에서는 NO_GRACE 오류 코드를 클라이언트로 반환합니다.
특정 파일에 대한 열기 작업 복구가 실패하면 클라이언트는 해당 파일을 사용할 수 없는 것으로 표시하며, 다음 메시지가 표시됩니다.
WARNING: The following NFS file could not be recovered and was marked dead (can't reopen: NFS status 70): file : filename
70이라는 숫자는 예제로만 사용됩니다.
복구 중에 파일 잠금 재설정이 실패하면 다음 오류 메시지가 게시됩니다.
NOTICE: nfs4_send_siglost: pid PROCESS-ID lost lock on server SERVER-NAME
이 경우 SIGLOST 신호가 프로세스에 게시됩니다. SIGLOST 신호의 기본 작업은 프로세스를 종료하는 것입니다.
이 상태에서 복구하려면 오류 시 파일을 열고 있던 응용 프로그램을 다시 시작해야 합니다. 이때 다음과 같은 현상이 발생할 수 있습니다.
파일을 다시 열지 않은 일부 프로세스에서 I/O 오류가 발생할 수 있습니다.
파일을 다시 열었거나 복구 실패 후 열기 작업을 수행한 다른 프로세스에서는 문제 없이 파일에 액세스할 수 있습니다.
따라서 일부 프로세스는 특정 파일에 액세스할 수 있는 반면 다른 프로세스는 액세스할 수 없습니다.
NFS 버전 4 프로토콜에서는 클라이언트가 다른 클라이언트의 파일 액세스를 제어하는 데 사용할 수 있는 다양한 파일 공유 모드를 제공합니다. 클라이언트는 다음을 지정할 수 있습니다.
DENY_NONE 모드는 다른 클라이언트의 파일 읽기 및 쓰기 액세스를 허용합니다.
DENY_READ 모드는 다른 클라이언트의 파일 읽기 액세스를 거부합니다.
DENY_WRITE 모드는 다른 클라이언트의 파일 쓰기 액세스를 거부합니다.
DENY_BOTH 모드는 다른 클라이언트의 파일 읽기 및 쓰기 액세스를 거부합니다.
Oracle Solaris NFS 버전 4 서버에서는 이러한 파일 공유 모드를 완전하게 구현합니다. 따라서 클라이언트가 현재 공유 모드와 충돌하는 방식으로 파일을 열려고 하면 서버에서 작업이 실패하도록 하여 해당 시도를 거부합니다. 열기 또는 만들기 작업을 시작할 때 이러한 시도가 실패하면 NFS 버전 4 클라이언트는 프로토콜 오류를 받게 됩니다. 이 오류는 응용 프로그램 오류 EACCES에 매핑됩니다.
프로토콜에서 여러 공유 모드를 제공하기는 하지만, 현재 Oracle Solaris에서 열기 작업을 수행하는 경우 여러 공유 모드가 제공되지 않습니다. 파일을 열 때 Oracle Solaris NFS 버전 4 클라이언트는 DENY_NONE 모드만 사용할 수 있습니다.
또한 fcntl 시스템 호출에는 파일 공유를 제어하는 F_SHARE 명령이 있지만, NFS 버전 4에서는 fcntl 명령을 올바르게 구현할 수 없습니다. NFS 버전 4 클라이언트에서 이러한 fcntl 명령을 사용하는 경우 클라이언트가 EAGAIN 오류를 응용 프로그램으로 반환합니다.
NFS 버전 4에서는 위임을 위한 클라이언트 지원과 서버 지원을 모두 제공합니다. 위임은 서버에서 파일 관리를 클라이언트에 위임하는 기술입니다. 예를 들어 서버에서 읽기 위임 또는 쓰기 위임을 클라이언트에 부여할 수 있습니다. 읽기 위임은 서로 충돌하지 않으므로 여러 클라이언트에게 동시에 부여할 수 있습니다. 쓰기 위임은 다른 클라이언트의 파일 액세스와 충돌하므로 한 클라이언트에게만 부여할 수 있습니다. 쓰기 위임을 보유한 클라이언트는 파일에 배타적으로 액세스할 수 있기 때문에 서버로 여러 작업을 보내지 않습니다. 마찬가지로, 읽기 위임을 보유한 클라이언트도 서버로 여러 작업을 보내지 않습니다. 서버에서 어떤 클라이언트도 쓰기 모드로 파일을 열지 못하도록 보장하기 때문입니다. 위임을 사용하는 경우 위임된 파일에 대해 서버와 클라이언트의 상호 작용이 크게 줄어듭니다. 따라서 네트워크 트래픽이 감소하고 클라이언트와 서버의 성능이 개선됩니다. 그러나 성능 개선 정도는 응용 프로그램에서 사용하는 파일 상호 작용의 종류와 네트워크 및 서버 혼잡 정도에 따라 달라집니다.
위임을 부여할지 여부는 전적으로 서버에서 결정합니다. 클라이언트는 위임을 요청하지 않습니다. 서버는 파일에 대한 액세스 패턴을 기반으로 위임을 부여할지 여부를 결정합니다. 서로 다른 여러 클라이언트에서 최근 쓰기 모드로 파일에 액세스한 경우 서버에서 위임을 부여하지 않았을 수 있습니다. 이 액세스 패턴은 이후 충돌 가능성을 나타내기 때문입니다.
클라이언트가 현재 파일에 대해 부여된 위임과 일치하지 않는 방식으로 해당 파일에 액세스하면 충돌이 발생합니다. 예를 들어 클라이언트가 파일에 대한 쓰기 위임을 보유하고 있는데 두번째 클라이언트가 읽기 또는 쓰기 액세스를 위해 해당 파일을 열면 서버에서 첫번째 클라이언트의 쓰기 위임을 회수합니다. 마찬가지로, 클라이언트에서 읽기 위임을 보유하고 있는데 다른 클라이언트가 쓰기를 위해 같은 파일을 열면 서버가 읽기 위임을 회수합니다. 두 상황에서 모두 충돌이 발생하므로 두번째 클라이언트에게는 위임이 부여되지 않습니다. 충돌이 발생하면 서버에서는 콜백 방식을 사용하여 현재 위임을 보유한 클라이언트에 연결합니다. 이 콜백을 받으면 클라이언트는 파일의 업데이트된 상태를 서버로 보내고 위임을 반환합니다. 클라이언트가 회수에 응답하지 못하면 서버에서 위임을 해지합니다. 이 경우 서버는 해당 파일에 대한 클라이언트의 모든 작업을 거부하며 클라이언트는 요청한 작업을 실패로 보고합니다. 일반적으로 이러한 실패는 응용 프로그램에 I/O 오류로 보고됩니다. 이 오류에서 복구하려면 파일을 닫았다가 다시 열어야 합니다. 클라이언트가 위임을 보유한 상태에서 클라이언트와 서버 간에 네트워크 파티션이 있으면 해지된 위임에서 오류가 발생할 수 있습니다.
서버는 다른 서버에 저장된 파일에 대한 액세스 충돌을 해결하지는 않습니다. 따라서 NFS 서버는 서버에 저장된 파일에 대해서만 충돌을 해결합니다. 또한, 여러 NFS 버전을 실행하는 클라이언트에서 발생하는 충돌에 대해 NFS 서버는 NFS 버전 4를 실행하는 클라이언트에 대한 회수만 시작합니다. NFS 서버는 이전 NFS 버전을 실행 중인 클라이언트에 대해 회수를 시작할 수 없습니다.
충돌 감지 프로세스는 상황에 따라 다릅니다. 예를 들어, NFS 버전 4와는 달리 버전 2와 버전 3에는 열기 절차가 없기 때문에 충돌은 클라이언트가 파일을 읽거나 쓰거나 잠그려고 시도한 후에만 감지됩니다. 이러한 충돌에 대한 서버의 응답도 다릅니다. 예를 들면 다음과 같습니다.
NFS 버전 3의 경우에는 서버에서 JUKEBOX 오류를 반환하며, 그러면 클라이언트가 액세스 요청을 정지했다가 나중에 다시 시도합니다. 클라이언트는 File unavailable 메시지를 인쇄합니다.
NFS 버전 2의 경우에는 JUKEBOX 오류에 해당하는 항목이 없기 때문에 서버에서 응답을 하지 않으며, 클라이언트는 기다렸다가 다시 시도합니다. 클라이언트는 NFS server not responding 메시지를 인쇄합니다.
위임 충돌이 해결되면 이러한 상황도 해결됩니다.
기본적으로 서버 위임은 사용으로 설정됩니다. server_delegation 매개변수를 none으로 설정하여 위임을 사용 안함으로 설정할 수 있습니다. 절차 정보는 서버에서 다른 NFS 버전을 선택하는 방법을 참조하십시오.
클라이언트 위임에는 키워드가 필요하지 않습니다. NFS 버전 4 콜백 데몬 nfs4cbd는 클라이언트에서 콜백 서비스를 제공합니다. 이 데몬은 NFS 버전 4에 대한 마운트를 사용으로 설정할 때마다 자동으로 시작됩니다. 기본적으로 클라이언트는 /etc/netconfig 시스템 파일에 나와 있는 모든 인터넷 전송에 대해 필요한 콜백 정보를 서버에 제공합니다. IPv6에 대해 클라이언트를 사용으로 설정하는 경우 클라이언트 이름의 IPv6 주소를 확인할 수 있으면 콜백 데몬은 IPv6 연결을 수락합니다.
콜백 데몬은 일시 프로그램 번호와 동적으로 지정된 포트 번호를 사용합니다. 이 정보는 서버에 제공되며, 서버는 위임을 부여하기 전에 콜백 경로를 테스트합니다. 콜백 경로 테스트가 실패하면 서버에서 위임을 부여하지 않습니다. 외부에서 확인 가능한 동작은 이 동작뿐입니다.
콜백 정보는 NFS 버전 4 요청 내에 내장되므로, 서버는 Network Address Translation(NAT)을 사용하는 장치를 통해 클라이언트에 연결할 수 없습니다. 또한 콜백 데몬은 동적 포트 번호를 사용합니다. 따라서 방화벽이 포트 2049에서 일반 NFS 트래픽을 사용으로 설정해도 서버가 방화벽을 순회하지 못할 수 있습니다. 이 경우에는 서버에서 위임을 할당하지 않습니다.
액세스 제어 목록(ACL)은 파일 소유자가 파일 소유자, 그룹 및 기타 특정 사용자/그룹의 파일 권한을 정의할 수 있도록 하여 보다 효율적인 파일 보안을 제공합니다. ZFS 파일 시스템에서 ACL은 chmod 명령을 사용하여 서버와 클라이언트에서 설정됩니다. UFS 파일 시스템에서는 setfacl 명령을 사용합니다. 자세한 내용은 chmod(1) 및 setfacl(1) 매뉴얼 페이지를 참조하십시오. NFS 버전 4에서는 ID 매퍼 nfsmapid를 사용하여 서버의 ACL 항목에 있는 사용자 또는 그룹 ID를 클라이언트의 ACL 항목에 있는 사용자 또는 그룹 ID로 매핑합니다. 그 반대의 경우도 마찬가지입니다. ACL 항목의 사용자 및 그룹 ID는 클라이언트와 서버에 모두 있어야 합니다.
다음과 같은 상황에서 ID 매핑이 실패할 수 있습니다.
서버의 ACL 항목에 있는 사용자 또는 그룹을 클라이언트의 유효한 사용자 또는 그룹에 매핑할 수 없는 경우 사용자가 ACL을 읽을 수는 있지만 일부 사용자 또는 그룹이 "알 수 없음"으로 표시됩니다.
예를 들어 ls -lv 또는 ls - lV 명령을 실행하면 일부 ACL 항목의 그룹 또는 사용자가 “알 수 없음”으로 표시됩니다. 이 명령에 대한 자세한 내용은 ls(1) 매뉴얼 페이지를 참조하십시오.
클라이언트에 설정되어 있는 ACL 항목의 사용자 또는 그룹 ID를 서버의 유효한 사용자 또는 그룹 ID에 매핑할 수 없는 경우 setfacl 또는chmod 명령이 실패할 수 있으며 권한이 거부됨 오류 메시지가 반환됩니다.
클라이언트와 서버의 nfsmapid_domain 값이 일치하지 않으면 ID 매핑은 실패합니다. 자세한 내용은 nfsmapid 데몬을 참조하십시오.
ID 매핑 문제를 방지하려면 다음을 수행합니다.
nfsmapid_domain의 값이 올바르게 설정되어 있는지 확인합니다.
ACL 항목의 모든 사용자 및 그룹 ID가 NFS 버전 4 클라이언트와 서버에 모두 있는지 확인합니다.
사용자 또는 그룹을 서버나 클라이언트에서 매핑할 수 없는지 확인하려면 다음 스크립트를 사용합니다.
#! /usr/sbin/dtrace -Fs
sdt:::nfs4-acl-nobody
{
printf("validate_idmapping: (%s) in the ACL could not be mapped!",
stringof(arg0));
}
주 - 이 스크립트에서 사용되는 검사 이름은 이후 변경될 수 있는 인터페이스입니다. 자세한 내용은 Solaris Dynamic Tracing Guide의 Stability Levels을 참조하십시오.
다음 항목을 참조하십시오.
시작 중에는 전송 프로토콜도 협상합니다. 기본적으로 클라이언트와 서버에서 모두 지원되는 첫번째 연결 지향 전송이 선택됩니다. 이러한 전송을 선택할 수 없으면 사용 가능한 첫번째 비연결 프로토콜이 사용됩니다. 시스템에서 지원되는 전송 프로토콜은 /etc/netconfig에 나와 있습니다. 이번 릴리스에서 지원되는 연결 지향 전송 프로토콜은 TCP입니다. 비연결 전송 프로토콜은 UDP입니다.
NFS 프로토콜 버전과 전송 프로토콜이 모두 협상을 통해 결정되면 NFS 프로토콜 버전이 전송 프로토콜보다 우선적으로 사용됩니다. UDP를 사용하는 NFS 버전 3 프로토콜의 우선 순위가 TCP를 사용하는 NFS 버전 2 프로토콜보다 높습니다. mount 명령을 사용하면 NFS 프로토콜 버전과 전송 프로토콜을 모두 수동으로 선택할 수 있습니다. mount_nfs(1M) 매뉴얼 페이지를 참조하십시오. 대부분의 경우에는 협상에서 최적의 옵션을 선택하도록 허용합니다.
파일 전송 크기는 클라이언트와 서버 간에 데이터를 전송할 때 사용되는 버퍼 크기를 설정합니다. 일반적으로는 전송 크기가 클수록 효율적입니다. NFS 버전 4 프로토콜에서는 전송 크기가 무제한입니다. 클라이언트는 필요한 경우 마운트 시에 더 작은 전송 크기를 사용할 수 있지만, 대부분의 경우에는 이렇게 할 필요가 없습니다.
NFS 버전 2 프로토콜을 사용하는 시스템과는 전송 크기를 협상하지 않습니다. 이 경우의 최대 전송 크기는 8KB로 설정됩니다.
mount 명령에서 -rsize 및 -wsize 옵션을 사용하여 전송 크기를 수동으로 설정할 수 있습니다. 일부 PC 클라이언트의 경우에는 전송 크기를 줄여야 할 수 있습니다. NFS 서버가 더 큰 전송 크기를 사용하도록 구성되어 있는 경우에도 전송 크기를 늘릴 수 있습니다.
주 - Solaris 10 릴리스부터는 유선 전송 크기 제한이 완화되었습니다. 전송 크기는 기본 전송 기능을 기반으로 합니다. 예를 들어 UDP에 대한 NFS 전송 제한은 여전히 32KB입니다. 그러나 TCP가 UDP의 데이터그램 제한이 없는 스트리밍 프로토콜이기 때문에 TCP를 통한 최대 전송 크기가 1MB로 늘어났습니다.
다음 설명은 NFS 버전 3 마운트에 적용됩니다. NFS 버전 4 마운트 프로세스에는 포트맵 서비스 및 MOUNT 프로토콜이 포함되지 않습니다.
클라이언트가 서버에서 파일 시스템을 마운트해야 하는 경우에는 서버로부터 파일 핸들을 가져와야 합니다. 파일 핸들은 파일 시스템에 해당해야 합니다. 이 프로세스를 수행하려면 클라이언트와 서버 간에 여러 트랜잭션을 수행해야 합니다. 이 예에서는 클라이언트가 서버에서 /home/terry를 마운트하려고 합니다. 그런 후에 이 트랜잭션에 대한 snoop 추적이 진행됩니다.
client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP server -> client PORTMAP R GETPORT port=33492 client -> server MOUNT3 C Null server -> client MOUNT3 R Null client -> server MOUNT3 C Mount /export/home9/terry server -> client MOUNT3 R Mount OK FH=9000 Auth=unix client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP server -> client PORTMAP R GETPORT port=2049 client -> server NFS C NULL3 server -> client NFS R NULL3 client -> server NFS C FSINFO3 FH=9000 server -> client NFS R FSINFO3 OK client -> server NFS C GETATTR3 FH=9000 server -> client NFS R GETATTR3 OK
이 추적에서 클라이언트는 먼저 NFS 서버의 포트맵 서비스에서 마운트 포트 번호를 요청합니다. 클라이언트가 마운트 포트 번호(33492)를 받으면 해당 번호를 사용하여 서버의 서비스 사용 가능 여부를 테스트합니다. 클라이언트는 서비스가 해당 포트 번호에서 실행 중임을 확인하고 나면 마운트 요청을 수행합니다. 서버는 이 요청에 응답할 때 마운트하려는 파일 시스템의 파일 핸들(9000)을 포함합니다. 그러면 클라이언트에서 NFS 포트 번호에 대한 요청을 보냅니다. 클라이언트는 서버로부터 번호를 받으면 NFS 서비스(nfsd)의 사용 가능 여부를 테스트합니다. 또한 클라이언트는 파일 핸들을 사용하는 파일 시스템에 대한 NFS 정보를 요청합니다.
다음 추적에서는 클라이언트가 public 옵션을 사용하여 파일 시스템을 마운트합니다.
client -> server NFS C LOOKUP3 FH=0000 /export/home9/terry server -> client NFS R LOOKUP3 OK FH=9000 client -> server NFS C FSINFO3 FH=9000 server -> client NFS R FSINFO3 OK client -> server NFS C GETATTR3 FH=9000 server -> client NFS R GETATTR3 OK
기본 공용 파일 핸들(0000)을 사용하면 포트맵 서비스에서 정보를 가져오고 NFS 포트 번호를 확인하는 모든 트랜잭션을 건너뜁니다.
-public 옵션을 사용하면 마운트가 실패하는 상황이 발생할 수 있습니다. NFS URL을 추가하는 경우에도 비슷한 상황이 발생할 수 있습니다. 다음 목록에서는 이러한 옵션을 사용하는 경우 파일 시스템을 마운트하는 방법을 구체적으로 설명합니다.
NFS URL의 public 옵션 – 공용 파일 핸들을 사용하도록 강제 지정합니다. 공용 파일 핸들이 지원되지 않으면 마운트는 실패합니다.
정규 경로의 public 옵션 – 공용 파일 핸들을 사용하도록 강제 지정합니다. 공용 파일 핸들이 지원되지 않으면 마운트는 실패합니다.
NFS URL만 – NFS 서버에서 공용 파일 핸들이 사용으로 설정된 경우에만 해당 파일 핸들을 사용합니다. 공용 파일 핸들 사용 시 마운트가 실패하면 MOUNT 프로토콜을 사용하여 마운트를 시도해 보십시오.
정규 경로만 – 공용 파일 핸들을 사용하지 않습니다. MOUNT 프로토콜이 사용됩니다.
NFS 클라이언트는 클라이언트측 페일오버를 사용하여 동일한 데이터를 제공하는 여러 서버를 파악하고 현재 서버를 사용할 수 없게 되면 대체 서버로 전환할 수 있습니다. 다음 중 하나가 발생하는 경우 파일 시스템을 사용하지 못할 수 있습니다.
파일 시스템이 연결된 서버가 충돌하는 경우
서버가 과부하되는 경우
네트워크 결함이 발생하는 경우
이러한 상황에서 페일오버는 일반적으로 사용자에게 투명하게 수행됩니다. 따라서 페일오버는 클라이언트에서 실행 중인 프로세스를 중단하지 않고 언제든지 수행될 수 있습니다.
페일오버를 수행하려면 파일 시스템이 읽기 전용으로 마운트되어 있어야 합니다. 파일 시스템이 동일해야 페일오버가 정상적으로 수행됩니다. 파일 시스템을 동일하게 만드는 요소에 대한 설명은 복제된 파일 시스템이란?을 참조하십시오. 정적 파일 시스템 또는 자주 변경되지 않는 파일 시스템이 페일오버를 수행하기에 가장 적합합니다.
같은 NFS 마운트에서 CacheFS와 클라이언트측 페일오버를 사용할 수는 없습니다. 각 CacheFS 파일 시스템에 대한 추가 정보가 저장됩니다. 페일오버 중에는 이 정보를 업데이트할 수 없으므로 파일 시스템을 마운트할 때는 이 두 기능 중 하나만 사용할 수 있습니다.
모든 파일 시스템에 대해 설정해야 하는 복제의 수는 여러 요인에 따라 달라집니다. 이상적으로는 최소 2개 서버가 있어야 합니다. 각 서버는 여러 서브넷을 지원해야 합니다. 각 서브넷에서 고유한 서버를 사용하는 것보다 이 설정이 효율적입니다. 프로세스를 수행하려면 나열된 각 서버를 확인해야 합니다. 따라서 나열된 서버의 수가 많으면 각 마운트 속도는 더 느려집니다.
프로세스를 완전하게 구현하려면 두 가지 용어를 이해해야 합니다.
페일오버 –복제된 파일 시스템을 지원하는 서버 목록에서 서버를 선택하는 프로세스입니다. 일반적으로 정렬된 목록에서 다음 서버가 사용됩니다(응답하지 못하는 경우는 제외).
다시 매핑 – 새 서버를 사용합니다. 정상 사용 시 클라이언트는 원격 파일 시스템에 있는 각 활성 파일의 경로 이름을 저장합니다. 다시 매핑 중에는 이러한 경로 이름을 평가하여 새 서버에서 파일을 찾습니다.
각 파일의 크기가 같고 파일 크기나 파일 형식이 원본 파일 시스템과 같으면 페일오버를 위해 파일 시스템을 복제로 사용할 수 있습니다. 이때 권한, 생성일 및 기타 파일 속성은 고려하지 않습니다. 파일 크기나 파일 형식이 다른 경우 다시 매핑이 실패하고 이전 서버를 사용할 수 있을 때까지 프로세스가 정지됩니다. NFS 버전 4에서는 동작이 다릅니다. NFS 버전 4의 클라이언트측 페일오버를 참조하십시오.
rsync, cpio 또는 다른 파일 전송 방식을 사용하여 복제된 파일 시스템을 유지 관리할 수 있습니다. 복제된 파일 시스템을 업데이트하면 불일치가 발생하므로 최선의 결과를 위해서는 다음 사항을 고려하십시오.
새 파일 버전을 설치하기 전에 이전 파일 버전의 이름 바꾸기
클라이언트 사용량이 낮은 야간에 업데이트 실행
업데이트를 소규모로 유지
복사본 수 최소화
일부 소프트웨어 패키지의 경우 파일에 대한 읽기 잠금이 필요합니다. 이러한 제품이 손상되지 않도록 하기 위해 읽기 전용 파일 시스템에 대한 읽기 잠금은 허용은 되지만 클라이언트측에서만 확인할 수 있습니다. 서버는 잠금을 확인할 수 없으므로 잠금은 다시 매핑 전체에서 지속됩니다. 파일은 변경되지 않아야 하므로 서버측에서는 파일을 잠글 필요가 없습니다.
NFS 버전 4에서는 파일 크기나 파일 형식이 달라 복제를 설정할 수 없으면 다음과 같은 현상이 발생합니다.
파일이 사용 불능으로 표시됩니다.
경고가 인쇄됩니다.
응용 프로그램에서 시스템 호출 오류를 받습니다.
주 - 응용 프로그램을 다시 시작한 후에 파일 액세스를 다시 시도하면 정상적으로 액세스할 수 있습니다.
NFS 버전 4에서는 크기가 다른 디렉토리에 대해 더 이상 복제 오류가 발생하지 않습니다. 이전 버전 NFS에서는 이러한 상황이 오류로 간주되어 다시 매핑 프로세스가 지연될 수 있습니다.
또한 NFS 버전 4에서는 디렉토리 읽기 작업이 실패하면 목록의 다음 서버에서 해당 작업을 수행합니다. 이전 버전 NFS에서는 읽기 작업이 실패하면 다시 매핑도 실패하고 원래 서버를 사용할 수 있을 때까지 프로세스가 정지되었습니다.
OS는 2GB보다 큰 파일을 지원합니다. 기본적으로 UFS 파일 시스템은 새 기능을 지원하기 위해 -largefiles 옵션을 사용하여 마운트됩니다. 필요한 경우 NFS 서버에서 큰 파일을 사용 안함으로 설정하는 방법에서 지침을 참조하십시오.
서버의 파일 시스템이 -largefiles 옵션을 사용하여 마운트된 경우 클라이언트는 변경을 수행하지 않아도 큰 파일에 액세스할 수 있습니다. 그러나 모든 명령이 이러한 큰 파일을 처리할 수 있는 것은 아닙니다. 큰 파일을 처리할 수 있는 명령 목록은 largefile(5)을 참조하십시오. 큰 파일 확장을 사용하는 NFS 버전 4 프로토콜을 지원할 수 없는 클라이언트는 큰 파일에 액세스할 수 없습니다.
NFS 서버 로깅에서는 NFS 읽기 및 쓰기 레코드와 파일 시스템을 수정하는 작업을 제공합니다. 이 데이터를 사용하여 정보에 대한 액세스를 추적할 수 있습니다. 또한 레코드를 통해 정보에 대한 관심도를 수량적으로 측정할 수 있습니다.
로깅이 사용으로 설정된 파일 시스템에 액세스하면 커널에서 버퍼 파일에 원시(raw) 데이터를 씁니다. 이 데이터에는 다음이 포함됩니다.
시간 기록
클라이언트 IP 주소
요청자의 UID
액세스 중인 파일 또는 디렉토리 객체의 파일 핸들
수행한 작업의 유형
nfslogd 데몬은 이 원시(raw) 데이터를 로그 파일에 저장되는 ASCII 레코드로 변환합니다. 사용으로 설정된 이름 서비스에서 일치 항목을 찾을 수 있는 경우 변환 중에 IP 주소는 호스트 이름으로 수정되고 UID는 로그인으로 수정됩니다. 파일 핸들도 경로 이름으로 변환됩니다. 변환을 수행하기 위해 데몬은 파일 핸들을 추적하고 별도의 파일 핸들-경로 테이블에 정보를 저장합니다. 이러한 방식이 사용되므로 파일 핸들에 액세스할 때마다 경로를 다시 식별하지 않아도 됩니다. nfslogd를 해제한 경우에는 파일 핸들-경로 테이블에서 매핑이 변경되지 않으므로 데몬을 계속 실행해야 합니다.
주 - NFS 버전 4에서는 서버 로깅이 지원되지 않습니다.
WebNFS 서비스는 공개 파일 핸들을 사용하여 클라이언트가 디렉토리의 파일을 사용할 수 있도록 합니다. 파일 핸들은 NFS 클라이언트에 대해 파일을 식별하는 커널에서 생성하는 주소입니다. 공개 파일 핸들에는 미리 정의된 값이 있으므로 서버에서 클라이언트용으로 파일 핸들을 생성하지 않아도 됩니다. 이 미리 정의된 파일 핸들을 사용할 수 있으므로 MOUNT 프로토콜을 사용할 필요가 없어 네트워크 트래픽이 감소합니다. 또한 이 기능을 통해 클라이언트의 프로세스 속도도 높일 수 있습니다.
기본적으로 NFS 서버의 공개 파일 핸들은 루트 파일 시스템에서 설정됩니다. 이러한 기본값이 사용되므로 WebNFS에서 이미 서버에 대한 마운트 권한이 있는 모든 클라이언트에 액세스할 수 있습니다. share 명령을 사용하면 임의의 파일 시스템을 가리키도록 공개 파일 핸들을 변경할 수 있습니다.
클라이언트에 파일 시스템용 파일 핸들이 있으면 LOOKUP이 실행되어 액세스할 파일의 파일 핸들을 확인합니다. NFS 프로토콜에서는 경로 이름 구성 요소를 한 번에 하나씩만 평가하도록 허용합니다. 각각의 추가 디렉토리 계층 레벨에는 다른 LOOKUP을 사용해야 합니다. LOOKUP이 공개 파일 핸들에 상대적이면 WebNFS 서버는 다중 구성 요소 조회 트랜잭션 하나를 사용하여 전체 경로 이름을 평가할 수 있습니다. WebNFS 서버에서는 다중 구성 요소 조회를 통해 경로 이름의 각 디렉토리 레벨에 대해 파일 핸들을 교환하지 않고도 파일 핸들을 원하는 파일로 배달할 수 있습니다.
또한 NFS 클라이언트는 단일 TCP 연결에 대한 동시 다운로드를 시작할 수 있습니다. 이 연결을 사용하면 여러 연결을 설정하면 발생하는 서버에 대한 추가 로드 없이 빠른 액세스가 가능합니다. 웹 브라우저 응용 프로그램은 여러 파일의 동시 다운로드를 지원하지만 각 파일에는 고유한 연결이 사용됩니다. WebNFS 소프트웨어에서는 연결 하나를 사용하므로 서버에 대한 오버헤드가 줄어듭니다.
경로 이름의 최종 구성 요소가 다른 파일 시스템에 대한 심볼릭 링크인 경우 정상 NFS 작업을 통해 이미 액세스 권한을 가지고 있는 클라이언트는 파일에 액세스할 수 있습니다.
일반적으로 NFS URL은 공개 파일 핸들에 상대적으로 평가됩니다. 경로 첫 부분에 슬래시를 더 추가하면 평가를 서버 루트 파일 시스템에 상대적으로 변경할 수 있습니다. 이 예제에서는 공용 파일 핸들이 /export/ftp 파일 시스템에서 설정된 경우 두 NFS URL은 동일합니다.
nfs://server/junk nfs://server//export/ftp/junk
주 - WebNFS 서비스보다 NFS 버전 4 프로토콜이 기본적으로 사용됩니다. NFS 버전 4에는 MOUNT 프로토콜 및 WebNFS 서비스에 추가된 모든 보안 협상 기능이 완전하게 통합되어 있습니다.
NFS 서비스에는 WebNFS 클라이언트가 선택한 보안 방식을 WebNFS 서버와 협상할 수 있도록 하는 프로토콜이 포함되어 있습니다. 새로운 프로토콜은 이전 버전 WebNFS 프로토콜에서 사용되었던 다중 구성 요소 조회의 확장인 보안 협상 다중 구성 요소 조회를 사용합니다.
WebNFS 클라이언트는 공개 파일 핸들을 사용하여 정규 다중 구성 요소 조회 요청을 수행함으로써 프로세스를 시작합니다. 클라이언트는 서버에서 경로를 보호하는 방법을 알 수 없으므로 기본 보안 방식이 사용됩니다. 기본 보안 방식이 충분하지 않으면 서버는 AUTH_TOOWEAK 오류로 회신합니다. 이 회신은 기본 방식이 유효하지 않음을 나타냅니다. 그러면 클라이언트는 보다 강력한 기본 방식을 사용해야 합니다.
클라이언트는 AUTH_TOOWEAK 오류를 받으면 필요한 보안 방식을 결정하라는 요청을 서버로 보냅니다. 요청이 성공하면 서버는 지정된 경로에 필요한 보안 방식 배열로 응답합니다. 보안 방식 배열의 크기에 따라 클라이언트가 추가 요청을 통해 전체 배열을 얻어야 할 수도 있습니다. 서버에서 WebNFS 보안 협상을 지원하지 않으면 요청은 실패합니다.
요청이 성공하고 나면 WebNFS 클라이언트는 클라이언트가 지원하는 배열에서 첫번째 보안 방식을 선택합니다. 그런 다음 클라이언트는 선택한 보안 방식을 사용해 정규 다중 구성 요소 조회 요청을 실행하여 파일 핸들을 가져옵니다. 모든 후속 NFS 요청은 선택한 보안 방식 및 파일 핸들을 사용하여 수행됩니다.
주 - WebNFS 서비스보다 NFS 버전 4 프로토콜이 기본적으로 사용됩니다. NFS 버전 4에는 MOUNT 프로토콜 및 WebNFS 서비스에 추가된 모든 보안 협상 기능이 완전하게 통합되어 있습니다.
WebNFS 소프트웨어는 HTTP를 사용하는 웹 사이트에서 제공할 수 있는 여러 기능을 지원하지 않습니다. 이와 같이 기능에 차이가 있는 것은, NFS 서버는 파일을 보내기만 하므로 특수한 처리는 클라이언트에서 수행해야 하기 때문입니다. WebNFS와 HTTP 액세스에 대해 웹 사이트 하나를 구성해야 하는 경우 다음 문제를 고려하십시오.
NFS 검색에서는 CGI 스크립트가 실행되지 않습니다. 따라서 CGI 스크립트를 많이 사용하는 활성 사이트가 포함된 파일 시스템은 NFS 검색용으로 적합하지 않을 수 있습니다.
브라우저에서 다른 파일 형식의 파일을 처리하기 위해 다른 뷰어가 시작될 수 있습니다. NFS URL을 통해 이러한 파일에 액세스하는 경우 파일 이름으로 파일 유형을 확인할 수 있으면 외부 브라우저가 시작됩니다. NFS URL을 사용하는 경우 브라우저는 표준 MIME 유형의 파일 이름 확장을 인식해야 합니다. WebNFS 소프트웨어는 파일 유형을 확인하기 위해 파일 내부를 확인하지 않습니다. 따라서 파일 이름 확장자를 통해서만 파일 유형을 확인할 수 있습니다.
NFS 검색에서는 서버측 이미지 맵(클릭 가능한 이미지)을 사용할 수 없습니다. 그러나 URL이 위치와 함께 정의되므로 NFS 검색에서 클라이언트측 이미지 맵(클릭 가능한 이미지)은 사용할 수 있습니다. 문서 서버로부터의 추가 응답은 필요하지 않습니다.
NFS 환경을 사용하면 서로 다른 여러 컴퓨터 구조와 운영 체제의 네트워크에서 파일 시스템을 효율적이고도 편리하게 공유할 수 있습니다. 그러나 NFS 작업을 통해 파일 시스템을 공유하는 동일 기능은 편리하기는 하지만 몇 가지 보안 문제를 야기합니다. 기존에는 대부분의 NFS 구현에서 UNIX 또는 AUTH_SYS 인증이 사용되었지만, AUTH_DH와 같은 보다 강력한 인증 방법도 사용할 수 있었습니다. UNIX 인증을 사용하는 경우 NFS 서버는 사용자가 아닌 파일 요청을 하는 컴퓨터를 인증하여 해당 요청을 인증합니다. 따라서 클라이언트 사용자는 su를 실행하여 파일 소유자를 가장할 수 있습니다. DH 인증을 사용하는 경우에는 NFS 서버에서 사용자를 인증하므로 이러한 종류의 가장이 훨씬 어려워집니다.
루트 액세스 권한과 네트워크 프로그래밍에 대한 지식이 있는 모든 사람이 임의의 데이터를 네트워크로 가져와서 네트워크에서 데이터를 추출할 수 있습니다. 이와 같이 데이터를 가져오는 공격이 가장 위험한 공격입니다. 올바른 패킷을 생성하거나 "대화"를 기록했다가 나중에 재생하여 사용자를 가장하는 경우를 예로 들 수 있습니다. 이러한 공격은 데이터 무결성에 영향을 줍니다. 수동적 도청(사용자를 가장하지는 않고 네트워크 트래픽만 수신함)을 포함하는 공격의 경우에는 데이터 무결성이 손상되지 않으므로 그만큼 위험하지 않습니다. 사용자는 네트워크를 통해 보내는 데이터를 암호화하여 중요한 정보의 프라이버시를 보호할 수 있습니다.
네트워크 보안 문제에 대한 일반적인 해결 방식은 각 응용 프로그램에서 문제를 해결하도록 하는 것입니다. 이보다 효율적인 방식은 모든 응용 프로그램이 포함되는 레벨에서 표준 인증 시스템을 구현하는 것입니다.
Oracle Solaris 운영 체제의 RPC(원격 프로시저 호출) 레벨에는 인증 시스템이 포함되어 있으며, 이 시스템은 NFS 작업의 기반이 되는 방식입니다. 보안 RPC라고도 하는 이 시스템은 네트워크 환경의 보안을 크게 개선하며 NFS 시스템과 같은 서비스에 추가적인 보안 기능을 제공합니다. 보안 RPC에서 제공하는 기능을 사용하는 NFS 시스템을 보안 NFS 시스템이라고 합니다.
보안 RPC는 보안 NFS 시스템의 기반이 되는 요소입니다. 보안 RPC는 최소한 시간 공유 시스템 레벨의 보안이 유지되는 시스템을 작성하는 데 사용됩니다. 시간 공유 시스템에서는 모든 사용자가 컴퓨터 한 대를 공유합니다. 시간 공유 시스템은 로그인 암호를 통해 사용자를 인증합니다. 데이터 암호화 표준(DES) 인증에서는 동일한 인증 프로세스가 완료됩니다. 사용자는 로컬 터미널에 로그인하는 것처럼 원격 컴퓨터에 로그인할 수 있습니다. 사용자의 로그인 암호는 네트워크 보안을 적용하는 수단입니다. 시간 공유 환경에서 시스템 관리자에게는 암호를 변경하여 사용자를 가장하지 않아야 한다는 윤리적 책임이 있습니다. 보안 RPC에서 네트워크 관리자는 공개 키가 저장되는 데이터베이스의 항목을 변경하지 않는 것으로 신뢰됩니다.
RPC 인증 시스템을 이해하려면 자격 증명과 검증기의 두 가지 용어를 숙지하고 있어야 합니다. ID 배치를 예로 사용하는 경우 자격 증명은 이름, 주소, 생일 등 사용자를 식별하는 수단입니다. 검증기는 배지에 첨부된 사진입니다. 배지의 사진을 배지 소유자와 비교 확인하여 배지가 도용되는 것이 아닌지를 확인할 수 있습니다. RPC에서 클라이언트 프로세스는 자격 증명과 검증기를 모두 각 RCP 요청과 함께 서버로 보냅니다. 클라이언트가 서버의 자격 증명을 이미 알고 있으므로 서버는 검증기만 다시 보냅니다.
RPC의 인증은 개방형이므로 UNIX, DH, KERB 등의 다양한 인증 시스템을 연결할 수 있습니다.
네트워크 서비스에서 UNIX 인증을 사용하는 경우 자격 증명에는 클라이언트의 호스트 이름, UID, GUID 및 그룹 액세스 목록이 포함됩니다. 그러나 검증기는 아무런 작업을 수행하지 않습니다. 이처럼 검증기가 없으므로 수퍼 유저는 su와 같은 명령을 사용하여 적절한 자격 증명을 위조할 수 있습니다. UNIX 인증의 또 다른 문제는 네트워크의 모든 컴퓨터가 UNIX 컴퓨터라고 가정하는 것입니다. 이기종 네트워크의 다른 운영 체제에 적용하는 경우 UNIX 인증은 손상됩니다.
UNIX 인증의 문제를 해결하기 위해 보안 RPC는 DH 인증을 사용합니다.
DH 인증은 데이터 암호화 표준(DES) 및 Diffie-Hellman 공개 키 암호화를 사용하여 네트워크의 사용자 및 컴퓨터를 모두 인증합니다. DES는 표준 암호화 방식입니다. Diffie-Hellman 공개 키 암호화는 두 개의 키(공개 키 하나, 보안 키 하나)가 포함된 암호화 시스템입니다. 공개 키와 보만 키는 이름 공간에 저장됩니다. NIS는 공개 키 맵에 키를 저장합니다. 이러한 맵에는 모든 잠재적 사용자에 대한 공개 키 및 보안 키가 포함됩니다. 맵을 설정하는 방법에 대한 자세한 내용은 Oracle Solaris Administration: Naming and Directory Services 를 참조하십시오.
DH 인증의 보안은 보낸 사람이 현재 시간을 암호화하는 기능을 기반으로 합니다. 그러면 받는 사람이 시간을 암호 해독하여 자신의 시계와 비교 확인할 수 있습니다. 시간 기록은 DES를 통해 암호화됩니다. 이 체계가 작동하는 데 필요한 요구 사항은 다음과 같습니다.
두 에이전트가 현재 시간에 동의해야 합니다.
보낸 사람과 받는 사람이 같은 암호화 키를 사용 중이어야 합니다.
네트워크에서 시간 동기화 프로그램을 실행하는 경우 클라이언트와 서버의 시간이 자동으로 동기화됩니다. 시간 동기화 프로그램을 사용할 수 없는 경우에는 네트워크 시간이 아닌 서버의 시간을 사용하여 시간 기록을 계산할 수 있습니다. 클라이언트는 RPC 세션을 시작하기 전에 서버에 시간을 물은 다음 자체 시계와 서버 시계 간의 시간 차이를 계산합니다. 이 차이를 사용하여 시간 기록 계산 시 클라이언트 시계를 오프셋합니다. 클라이언트 및 서버의 시계가 동기화되지 않은 상태이면 서버는 클라이언트 요청을 거부합니다. 클라이언트의 DH 인증 시스템은 서버와 재동기화됩니다.
클라이언트와 서버는 임의의 대화 키(세션 키라고도 함)를 생성하고 공개 키 암호화를 통해 공통 키를 추론함으로써 동일한 암호화 키를 사용하게 됩니다. 공통 키는 클라이언트와 서버만 추론할 수 있는 키입니다. 대화 키는 클라이언트 시간 기록을 암호화하고 암호 해독하는 데 사용됩니다. 공통 키는 대화 키를 암호화하고 암호 해독하는 데 사용됩니다.
Kerberos는 MIT에서 개발된 인증 시스템입니다. Kerberos는 DES를 비롯한 여러 암호화 유형을 제공합니다. Kerberos 지원은 더 이상 보안 RPC의 일부분으로 제공하지 않지만, 서버측 및 클라이언트측 구현은 릴리스에 포함되어 있습니다. Kerberos 인증 구현에 대한 자세한 내용은 Oracle Solaris 관리: 보안 서비스의 19 장, Kerberos 서비스 소개를 참조하십시오.
보안 RPC를 사용하려는 경우 다음 사항에 유의하십시오.
정전 이후 등과 같이 사용자가 없는데 서버가 충돌하는 경우 시스템에 저장된 모든 보안 키가 삭제됩니다. 그러면 프로세스에서 보안 네트워크 서비스에 액세스하거나 NFS 파일 시스템을 마운트할 수 없습니다. 재부트 중의 중요한 프로세스는 보통 root로 실행됩니다. 따라서 루트의 보안 키를 외부에 저장한 경우에는 이러한 프로세스가 작동하지만 해당 키의 암호를 해독하는 암호를 입력할 사용자가 없기 때문에 문제가 됩니다. 이 경우 keylogin -r은 root를 통해 일반 보안 키를 /etc/.rootkey(keyserv에서 읽을 수 있음)에 저장하도록 허용합니다.
일부 시스템은 단일 사용자 모드로 부트됩니다. 이때 콘솔의 루트 로그인 셸이 사용되며 암호 프롬프트는 표시되지 않습니다. 이러한 경우에는 물리적 보안을 반드시 적용해야 합니다.
디스크가 없는 컴퓨터 부트는 완벽하게 안전하지 않습니다. 즉, 누군가가 부트 서버를 가장해 우회 커널을 부트하여 원격 컴퓨터에서 보안 키 레코드를 만드는 등의 작업을 수행할 수 있습니다. 보안 NFS 시스템에서는 커널 및 키 서버를 실행한 후에만 보호 기능을 제공합니다. 그 외에는 부트 서버에서 제공하는 회신을 인증할 방법이 없습니다. 이러한 제한은 심각한 문제가 될 수 있지만 이 제한으로 인해 커널 소스 코드를 사용한 복잡은 공격을 수행해야 합니다. 또한 범죄의 증거가 남게 됩니다. 부트 서버에 대해 네트워크를 폴링한 경우 우회 부트 서버 위치를 확인할 수 있습니다.
대부분의 setuid 프로그램은 root에서 소유합니다. root의 보안 키가 /etc/.rootkey에 저장되는 경우 이러한 프로그램은 이전과 동일하게 동작합니다. 그러나 사용자 소유의 setuid 프로그램은 작동하지 않을 수도 있습니다. 예를 들어 setuid 프로그램을dave가 소유하고 있으며 dave가 컴퓨터 부트 후 컴퓨터에 로그인하지 않았다고 가정하겠습니다. 그러면 프로그램에서 보안 네트워크 서비스에 액세스할 수 없습니다.
login, rlogin , 또는 telnet을 사용하여 원격 컴퓨터에 로그인하고 keylogin을 사용하여 액세스 권한을 얻는 경우에는 계정 액세스 권한이 부여됩니다. 보안 키가 해당 컴퓨터의 키 서버로 전달되며, 이 서버에 보안 키가 저장되기 때문입니다. 이 프로세스는 원격 컴퓨터를 신뢰하지 않는 경우에만 문제가 됩니다. 의심스러운 부분이 있는 경우 원격 컴퓨터에 암호가 필요하면 원격 컴퓨터에 로그인하지 마십시오. 대신 NFS 환경을 사용하여 원격 컴퓨터에서 공유하는 파일 시스템을 마운트합니다. 또한 keylogout을 사용하여 키 서버에서 보안 키를 삭제할 수도 있습니다.
-o sec=dh 옵션을 사용하여 홈 디렉토리를 공유하는 경우 원격 로그인 시 문제가 발생할 수 있습니다. 암호 프롬프트를 표시하도록 /etc/hosts.equiv 또는 ~/.rhosts 파일이 설정되어 있지 않으면 로그인은 성공합니다. 그러나 로컬에서 인증이 수행되지 않았으므로 사용자는 홈 디렉토리에 액세스할 수 없습니다. 사용자에게 암호 프롬프트가 표시되는 경우 암호가 네트워크 암호와 일치하면 사용자는 홈 디렉토리 액세스 권한을 얻습니다.
|