NFS 파일. NFS 서버 설치 및 구성

안녕하세요, 독자 여러분, 손님 여러분. 게시물 사이에 매우 긴 공백이 있었지만 다시 활동 중입니다.) 오늘 기사에서 살펴볼 내용은 NFS 프로토콜 작동, 그리고 Linux에서 NFS 서버 및 NFS 클라이언트 설정.

NFS 소개

NFS (네트워크 파일 시스템 - 회로망 파일 시스템 ) 내 생각에는 - 완벽한 솔루션빠른(SAMBA에 비해 빠르고 암호화된 원격 파일 시스템(sshfs, SFTP 등...)에 비해 리소스 집약적이지 않음) 데이터 교환이 필요하고 전송된 정보의 보안이 최우선이 아닌 로컬 네트워크에서 . NFS 프로토콜허용한다 네트워크를 통해 원격 파일 시스템을 로컬 디렉토리 트리에 마운트, 마치 마운트된 디스크 파일 시스템인 것처럼. 이를 통해 로컬 애플리케이션이 마치 로컬 파일 시스템인 것처럼 원격 파일 시스템에서 작동할 수 있습니다. 하지만 조심해야 할(!) NFS 설정, 특정 구성을 사용하면 끝없는 I/O를 기다리면서 클라이언트 운영 체제를 정지시킬 수 있기 때문입니다. NFS 프로토콜업무 기반 RPC 프로토콜, 이는 아직 제가 이해할 수 없는 부분입니다)) 따라서 기사의 내용은 약간 모호할 것입니다... 서버이든 클라이언트이든 NFS를 사용하기 전에 커널이 NFS 파일을 지원하는지 확인해야 합니다. 체계. 파일에 해당 행이 있는지 확인하여 커널이 NFS 파일 시스템을 지원하는지 확인할 수 있습니다. /proc/파일 시스템:

ARCHIV ~ # grep nfs /proc/filesystems nodev nfs nodev nfs4 nodev nfsd

파일에 지정된 줄이 있는 경우 /proc/파일 시스템나타나지 않으면 아래 설명된 패키지를 설치해야 합니다. 이를 통해 필요한 파일 시스템을 지원하기 위해 종속 커널 모듈을 설치할 수 있습니다. 패키지를 설치한 후 NFS 지원이 지정된 파일에 표시되지 않으면 이 기능을 활성화해야 합니다.

이야기 네트워크 파일 시스템

NFS 프로토콜 Sun Microsystems에서 개발했으며 역사상 4가지 버전이 있습니다. NFSv1 1989년에 개발되었으며 UDP 프로토콜에서 실행되는 실험적이었습니다. 버전 1에 대해서는 에 설명되어 있습니다. NFSv2동일한 1989년에 출시되었으며 동일한 RFC1094에 설명되어 있으며 UDP 프로토콜을 기반으로 하며 파일에서 2GB 이하를 읽을 수 있습니다. NFSv3 1995년에 완성되었으며 에 설명되어 있습니다. 세 번째 버전의 주요 혁신은 대용량 파일 지원, TCP 프로토콜 및 대용량 TCP 패킷에 대한 지원 추가로 기술 성능을 크게 가속화했습니다. NFSv4 2000년에 완성되었으며 RFC 3010에 설명되어 있고 2003년에 개정되었으며 에 설명되어 있습니다. 네 번째 버전에는 성능 개선, 다양한 인증 수단(특히 RPCSEC GSS 프로토콜을 사용하는 Kerberos 및 LIPKEY) 및 액세스 제어 목록(POSIX 및 Windows 유형 모두)에 대한 지원이 포함되었습니다. NFS 버전 v4.1 2010년 IESG의 승인을 받아 . 버전 4.1의 중요한 혁신은 여러 분산 NFS 서버의 데이터에 대한 병렬 NFS 클라이언트 액세스 메커니즘인 pNFS(병렬 NFS)의 사양입니다. 네트워크 파일 시스템 표준에 이러한 메커니즘이 있으면 분산된 "클라우드" 스토리지 및 정보 시스템을 구축하는 데 도움이 됩니다.

NFS 서버

우리가 가지고 있기 때문에 NFS- 이것 회로망파일 시스템이 필요합니다. (기사를 읽어보셔도 됩니다). 다음이 필요합니다. 데비안에서는 이것은 패키지입니다 nfs-커널-서버그리고 nfs-공통, RedHat에서는 이것은 패키지입니다 nfs-utils. 또한 필요한 OS 실행 수준에서 데몬이 실행되도록 허용해야 합니다(RedHat의 명령 - /sbin/chkconfig nfs 켜기, 데비안에서 - /usr/sbin/update-rc.d nfs-kernel-server 기본값).

Debian에 설치된 패키지는 다음 순서로 실행됩니다:

아카이브 ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx 1 루트 루트 20 10월 18일 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx 1 루트 루트 20 10월 22일 01:23 S16nfs-kernel-server -> ../init.d /nfs-커널-서버

즉, 먼저 시작됩니다. nfs-공통, 서버 자체 nfs-커널-서버. RedHat에서는 첫 번째 스크립트가 호출된다는 점만 제외하면 상황이 비슷합니다. nfslock, 그리고 서버는 간단히 호출됩니다 nfs. 에 대한 nfs-공통 데비안 웹사이트는 우리에게 다음과 같이 말해줍니다: NFS 클라이언트 및 서버용 공유 파일을 사용하려면 이 패키지를 NFS 클라이언트 또는 서버로 작동할 시스템에 설치해야 합니다. 패키지에는 lockd, statd, showmount, nfsstat, gssd 및 idmapd 프로그램이 포함되어 있습니다.. 시작 스크립트의 내용 보기 /etc/init.d/nfs-common다음 작업 순서를 추적할 수 있습니다. 스크립트는 실행 가능한 바이너리 파일이 있는지 확인합니다. /sbin/rpc.statd, 파일에 존재하는지 확인합니다. /etc/default/nfs-common, /etc/fstab그리고 /etc/exports데몬 실행이 필요한 매개변수 idmapd 그리고 gssd , 데몬을 시작합니다 /sbin/rpc.statd , 그런 다음 출시 전 /usr/sbin/rpc.idmapd그리고 /usr/sbin/rpc.gssd이러한 실행 가능한 바이너리 파일이 있는지 확인한 다음 데몬 /usr/sbin/rpc.idmapd가용성을 확인합니다 sunrpc,nfs그리고 nfsd, 파일 시스템 지원 rpc_pipefs커널에서(즉, 파일에 저장하는 것) /proc/파일 시스템) 모든 것이 성공하면 시작됩니다. /usr/sbin/rpc.idmapd . 게다가 악마에게 /usr/sbin/rpc.gssd 체크 무늬 커널 모듈 rpcsec_gss_krb5그리고 데몬을 시작합니다.

내용을 보시면 NFS 서버 시작 스크립트데비안( /etc/init.d/nfs-kernel-server), 다음 순서를 따를 수 있습니다. 시작 시 스크립트는 파일의 존재를 확인합니다. /etc/exports, 가용성 nfsd, 지원 가용성 NFS 파일 시스템(즉, 파일에서 /proc/파일 시스템), 모든 것이 제자리에 있으면 데몬이 시작됩니다. /usr/sbin/rpc.nfsd 그런 다음 매개변수가 지정되었는지 확인합니다. NEED_SVCGSD(서버 설정 파일에 설정됨 /etc/default/nfs-커널-서버) 그리고 주어진 경우 데몬을 시작합니다. /usr/sbin/rpc.svcgssd , 마지막으로 데몬을 시작합니다 /usr/sbin/rpc.mountd . 이 스크립트에서 다음이 분명해졌습니다. NFS 서버 운영은 다음과 같이 구성됩니다.데몬 rpc.nfsd, rpc.mountd 및 Kerberos 인증이 사용되는 경우 rcp.svcgssd 데몬. Red Hat에서는 rpc.rquotad 및 nfslogd 데몬이 여전히 실행 중입니다. (어떤 이유로 Debian에서는 이 데몬에 대한 정보와 해당 데몬이 없는 이유를 찾지 못했고 삭제된 것 같습니다...)

이것으로부터 다음이 분명해진다. 네트워크 파일 시스템 서버는 다음 프로세스로 구성됩니다(읽기: 데몬)., /sbin 및 /usr/sbin 디렉토리에 위치:

NFSv4에서는 Kerberos를 사용할 때 추가 데몬이 시작됩니다.

• rpc.gssd- NFSv4 데몬은 GSS-API(Kerberos 인증)를 통해 인증 방법을 제공합니다. 클라이언트와 서버에서 작동합니다.
• rpc.svcgssd- 서버측 클라이언트 인증을 제공하는 NFSv4 서버 데몬입니다.

포트맵 및 RPC 프로토콜(Sun RPC)

위 패키지 외에도 올바른 작동 NFSv2 및 v3 필요 추가 패키지 포트맵(최신 배포판에서는 다음으로 이름이 변경됨) rpcbind). 이 패키지는 일반적으로 NFS와 함께 종속 패키지로 자동 설치되며 RPC 서버의 작동을 구현합니다. 즉, RPC 서버에 등록된 일부 서비스에 대한 포트의 동적 할당을 담당합니다. 말 그대로 문서에 따르면 이는 RPC(Remote Procedure Call) 프로그램 번호를 TCP/UDP 포트 번호로 변환하는 서버입니다. portmap은 여러 엔터티에서 작동합니다. RPC 호출 또는 요청, TCP/UDP 포트,프로토콜 버전(TCP 또는 UDP), 프로그램 번호그리고 소프트웨어 버전. portmap 데몬은 NFS 서비스가 시작되기 전에 /etc/init.d/portmap 스크립트에 의해 시작됩니다.

간단히 말해서 RPC(원격 프로시저 호출) 서버의 작업은 로컬 및 원격 프로세스에서 RPC 호출(소위 RPC 프로시저)을 처리하는 것입니다. RPC 호출을 사용하여 서비스는 포트 매퍼(일명 포트 매퍼, 일명 portmap, 일명 portmapper, 일명 새 버전에서는 rpcbind)에 자신을 등록하거나 제거하고 클라이언트는 RPC 호출을 사용하여 portmapper get에 요청을 보냅니다. 필요한 정보. 프로그램 서비스의 사용자 친화적인 이름과 해당 번호는 /etc/rpc 파일에 정의되어 있습니다. 서비스가 해당 요청을 보내고 포트 매퍼의 RPC 서버에 등록되면 RPC 서버는 서비스가 시작된 TCP 및 UDP 포트를 서비스에 할당하고 매핑하며 해당 정보를 커널에 저장합니다. 실행 중인 서비스(이름), 고유 번호 서비스(/etc/rpc에 따름), 서비스가 실행되는 프로토콜 및 포트, 서비스 버전에 대한 정보를 제공하며 요청 시 클라이언트에 지정된 정보를 제공합니다. 포트 변환기 자체에는 프로그램 번호 (100000), 버전 번호 - 2, TCP 포트 111 및 UDP 포트 111이 있습니다. 위에서 NFS 서버 데몬의 구성을 지정할 때 기본 RPC 프로그램 번호를 표시했습니다. 아마도 이 단락으로 인해 여러분이 약간 혼란스러워했을 것입니다. 따라서 상황을 명확하게 하는 기본 문구를 말씀드리겠습니다. 포트 매퍼의 주요 기능은 RPC 프로그램 번호를 제공한 클라이언트의 요청에 따라 반환하는 것입니다( 또는 RPC 프로그램 번호) 및 버전을 그(클라이언트)에게 요청된 프로그램이 실행 중인 포트에 전달합니다. 따라서 클라이언트가 특정 프로그램 번호로 RPC에 액세스해야 하는 경우 먼저 서버 시스템의 portmap 프로세스에 접속하고 필요한 RPC 서비스가 있는 통신 포트 번호를 결정해야 합니다.

RPC 서버의 작동은 다음 단계로 나타낼 수 있습니다.

1. 일반적으로 시스템이 부팅될 때 포트 변환기가 먼저 시작되어야 합니다. 그러면 TCP 엔드포인트가 생성되고 TCP 포트 111이 열립니다. 또한 UDP 데이터그램이 UDP 포트 111에 도착할 때까지 기다리는 UDP 엔드포인트도 생성됩니다.
2. 시작 시 RPC 서버를 통해 실행되는 프로그램은 지원되는 각 프로그램 버전에 대한 TCP 끝점과 UDP 끝점을 만듭니다. (RPC 서버는 여러 버전을 지원할 수 있습니다. 클라이언트는 RPC 호출 시 필요한 버전을 지정합니다.) 동적으로 할당된 포트 번호는 서비스의 각 버전에 할당됩니다. 서버는 적절한 RPC 호출을 수행하여 각 프로그램, 버전, 프로토콜 및 포트 번호를 기록합니다.
3. RPC 클라이언트 프로그램이 필요한 정보를 얻어야 할 때 포트 확인 루틴을 호출하여 동적으로 할당된 포트 번호를 얻습니다. 주어진 프로그램, 버전 및 프로토콜.
4. 이 요청에 대한 응답으로 북쪽은 포트 번호를 반환합니다.
5. 클라이언트는 4단계에서 얻은 포트 번호로 RPC 요청 메시지를 보냅니다. UDP를 사용하는 경우 클라이언트는 요청된 서비스가 실행 중인 UDP 포트 번호로 RPC 챌린지 메시지가 포함된 UDP 데이터그램을 보냅니다. 이에 대한 응답으로 서비스는 RPC 응답 메시지가 포함된 UDP 데이터그램을 보냅니다. TCP가 사용되는 경우 클라이언트는 원하는 서비스의 TCP 포트 번호를 적극적으로 연 다음 설정된 연결을 통해 RPC 챌린지 메시지를 보냅니다. 서버는 연결 시 RPC 응답 메시지로 응답합니다.

RPC 서버에서 정보를 얻으려면 유틸리티를 사용하십시오. rpcinfo. 매개변수를 지정할 때 -p 호스트프로그램은 호스트 호스트에 등록된 모든 RPC 프로그램 목록을 표시합니다. 호스트를 지정하지 않으면 프로그램은 localhost에 서비스를 표시합니다. 예:

ARCHIV ~ # rpcinfo -p prog-ma vers proto 포트 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 59451 상태 100024 1 tcp 60872 상태 100021 1 udp 44310 nlockmgr 10002 1 3 UDP 44310 nlockmgr 100021 4 UDP 44310 nlockmgr 100021 1 tcp 44851 nlockmgr 100021 3 tcp 44851 nlockmgr 100021 4 tcp 44851 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100005 1 udp 51306 mountd 100005 1 tcp 41405 mountd 100005 2 udp 51306 mountd 100005 2 tcp 41405 mountd 100005 3 udp 51306 mountd 100005 3 tcp 41405 mountd

보시다시피 rpcinfo는 등록된 프로그램 번호, 버전, 프로토콜, 포트 및 이름을 왼쪽에서 오른쪽으로 표시합니다. rpcinfo를 사용하면 프로그램 등록을 제거하거나 특정 RPC 서비스에 대한 정보를 얻을 수 있습니다(man rpcinfo의 추가 옵션). 보시다시피, portmapper 데몬 버전 2는 udp 및 tcp 포트에, rpc.statd 버전 1은 udp 및 tcp 포트에, NFS 잠금 관리자 버전 1,3,4, nfs 서버 데몬 버전 2,3,4도 등록되어 있습니다. 마운트 데몬 버전 1,2,3.

NFS 서버(더 정확하게는 rpc.nfsd 데몬)는 포트 2049에서 UDP 데이터그램 형식으로 클라이언트로부터 요청을 받습니다. NFS는 서버가 동적으로 할당된 포트를 사용할 수 있도록 하는 포트 확인자와 함께 작동하지만 UDP 포트 2049는 대부분의 구현에서는 NFS로 하드코딩됩니다.

네트워크 파일 시스템 프로토콜 작동

원격 NFS 마운트

원격 NFS 파일 시스템을 마운트하는 프로세스는 다음 다이어그램으로 나타낼 수 있습니다.

원격 디렉터리를 마운트할 때 NFS 프로토콜에 대한 설명:

1. RPC 서버는 서버와 클라이언트에서 시작되고(보통 부팅 시) portmapper 프로세스에 의해 서비스되며 tcp/111 및 udp/111 포트에 등록됩니다.
2. RPC 서버에 등록되고 임의의 네트워크 포트에 등록되는 서비스(rpc.nfsd, rpc.statd 등)가 시작됩니다(서비스 설정에 정적 포트가 지정되지 않은 경우).
3. 클라이언트 컴퓨터의 mount 명령은 파일 시스템 유형, 호스트 및 디렉터리 자체를 나타내는 네트워크 디렉터리를 마운트하라는 요청을 커널에 보냅니다. 커널은 udp 포트의 NFS 서버에 있는 portmap 프로세스에 RPC 요청을 보내고 형성합니다. /111(tcp를 통한 작업 옵션이 클라이언트에 설정되지 않은 경우)
4. NFS 서버 커널은 RPC에 rpc.mountd 데몬이 있는지 쿼리하고 데몬이 실행 중인 네트워크 포트를 클라이언트 커널에 반환합니다.
5. mount는 rpc.mountd가 실행 중인 포트로 RPC 요청을 보냅니다. 이제 NFS 서버는 IP 주소와 포트 번호를 기반으로 클라이언트의 유효성을 검사하여 클라이언트가 지정된 파일 시스템을 마운트할 수 있는지 확인할 수 있습니다.
6. 마운트 데몬은 요청된 파일 시스템에 대한 설명을 반환합니다.
7. 클라이언트의 mount 명령은 mount 시스템 호출을 실행하여 5단계에서 얻은 파일 핸들을 클라이언트 호스트의 로컬 마운트 지점과 연결합니다. 파일 핸들은 클라이언트의 NFS 코드에 저장되며, 이제부터 사용자 프로세스가 서버 파일 시스템의 파일에 액세스할 때마다 파일 핸들을 시작점으로 사용합니다.

클라이언트와 NFS 서버 간의 통신

원격 파일 시스템에 대한 일반적인 액세스는 다음과 같이 설명할 수 있습니다.

NFS 서버에 있는 파일에 액세스하는 프로세스에 대한 설명:

1. 클라이언트(사용자 프로세스)는 로컬 파일에 액세스하는지 NFS 파일에 액세스하는지 상관하지 않습니다. 커널은 커널 모듈이나 내장 시스템 호출을 통해 하드웨어와 상호 작용합니다.
2. 커널 모듈 커널/fs/nfs/nfs.ko, NFS 클라이언트의 기능을 수행하며 TCP/IP 모듈을 통해 NFS 서버로 RPC 요청을 보냅니다. NFS는 일반적으로 UDP를 사용하지만 최신 구현에서는 TCP를 사용할 수도 있습니다.
3. NFS 서버는 포트 2049에서 UDP 데이터그램으로 클라이언트로부터 요청을 받습니다. NFS는 서버가 동적으로 할당된 포트를 사용할 수 있도록 하는 포트 확인자와 함께 작동할 수 있지만 UDP 포트 2049는 대부분의 구현에서 NFS에 하드 코딩됩니다.
4. NFS 서버가 클라이언트로부터 요청을 받으면 해당 요청은 서버의 로컬 디스크에 대한 액세스를 제공하는 로컬 파일 액세스 루틴으로 전달됩니다.
5. 디스크 액세스 결과가 클라이언트에 반환됩니다.

NFS 서버 설정

서버 튜닝일반적으로 원격 시스템이 파일에 마운트할 수 있는 로컬 디렉터리를 지정하는 것으로 구성됩니다. /etc/exports. 이 동작을 디렉토리 계층 내보내기. 내보낸 카탈로그에 대한 주요 정보 소스는 다음 파일입니다.

• /etc/exports- 내보낸 디렉터리의 구성을 저장하는 기본 구성 파일입니다. NFS를 시작할 때 및 importfs 유틸리티에 의해 사용됩니다.
• /var/lib/nfs/xtab- 원격 클라이언트가 마운트한 디렉토리 목록을 포함합니다. 클라이언트가 계층 구조 마운트를 시도할 때 rpc.mountd 데몬에서 사용됩니다(마운트 항목이 생성됨).
• /var/lib/nfs/etab- 내보낸 디렉터리의 모든 매개변수를 나타내는 원격 시스템에서 마운트할 수 있는 디렉터리 목록입니다.
• /var/lib/nfs/rmtab- 현재 내보내지지 않은 디렉터리 목록입니다.
• /proc/fs/nfsd- NFS 서버 관리를 위한 특수 파일 시스템(커널 2.6).
  • 수출- 내보낸 활성 계층 및 이를 내보낸 클라이언트 목록과 매개변수입니다. 코어는 수신 이 정보/var/lib/nfs/xtab에서.
  • 스레드- 스레드 수를 포함합니다(변경될 수도 있음).
  • 파일 핸들을 사용하면 파일에 대한 포인터를 얻을 수 있습니다
  • 등등...
• /proc/net/rpc- nfsstat을 사용하여 얻을 수 있는 "원시" 통계와 다양한 캐시가 포함되어 있습니다.
• /var/run/portmap_mapping- RPC에 등록된 서비스에 대한 정보

메모: 일반적으로 인터넷에는 xtab, etab, rmtab 파일의 목적에 대한 해석과 공식이 많이 있는데 누구를 믿어야할지 모르겠습니다. http://nfs.sourceforge.net/에서도 해석은 다음과 같습니다. 명확하지 않습니다.

/etc/exports 파일 설정

가장 간단한 경우 /etc/exports 파일은 NFS 서버를 구성하기 위해 편집이 필요한 유일한 파일입니다. 이 파일다음 측면을 관리합니다.

• 어떤 종류의 고객인가?서버의 파일에 액세스할 수 있습니다
• 어떤 계층구조인가요?서버의 디렉토리는 각 클라이언트에서 액세스할 수 있습니다.
• 맞춤 고객 이름은 어떻게 되나요? 표시되다로컬 사용자 이름으로

내보내기 파일의 각 줄 형식은 다음과 같습니다.

내보내기_포인트 클라이언트1(옵션) [클라이언트2(옵션) ...]

어디 수출_점 내보낸 디렉터리 계층 구조의 절대 경로, 클라이언트1 - n 마운트가 허용된 하나 이상의 클라이언트 이름 또는 IP 주소(공백으로 구분) 수출_점 . 옵션 마운트 규칙 설명 고객, 이전에 지정됨 옵션 .

다음은 전형적인 것입니다. 내보내기 파일 구성 예:

ARCHIV ~ # cat /etc/exports /archiv1 파일(rw,sync) 10.0.0.1(ro,sync) 10.0.230.1/24(ro,sync)

안에 이 예에서는컴퓨터 파일 및 10.0.0.1에는 내보내기 지점 /archiv1에 대한 액세스가 허용되는 반면 파일 호스트에는 읽기/쓰기 액세스 권한이 있고 호스트 10.0.0.1 및 서브넷 10.0.230.1/24에는 읽기 전용 액세스 권한이 있습니다.

/etc/exports의 호스트 설명은 다음 형식으로 허용됩니다.

• 개별 노드의 이름은 파일 또는 files.DOMAIN.local로 설명됩니다.
• 도메인 마스크는 다음 형식으로 설명됩니다. *DOMAIN.local은 DOMAIN.local 도메인의 모든 노드를 포함합니다.
• 서브넷은 IP 주소/마스크 쌍으로 지정됩니다. 예: 10.0.0.0/255.255.255.0에는 주소가 10.0.0으로 시작하는 모든 노드가 포함됩니다.
• 리소스에 액세스할 수 있는 @myclients 네트워크 그룹의 이름 지정(NIS 서버를 사용하는 경우)

디렉터리 계층 내보내기를 위한 일반 옵션

내보내기 파일은 다음과 같은 일반 옵션을 사용합니다.(대부분의 시스템에서 기본적으로 사용되는 옵션이 먼저 나열되고, 기본값이 아닌 옵션은 괄호 안에 표시됩니다):

• auth_nlm(no_auth_nlm)또는 secure_locks(비보안 잠금)- 서버가 잠금 요청 인증을 요구해야 함을 지정합니다(NFS 잠금 관리자 프로토콜 사용).
• 숨기지 않음 (숨기기)- 서버가 두 개의 디렉터리 계층 구조를 내보내는 경우, 하나는 다른 하나 안에 중첩(마운트)됩니다. 클라이언트는 두 번째(하위) 계층을 명시적으로 마운트해야 합니다. 그렇지 않으면 하위 계층의 마운트 지점이 빈 디렉터리로 나타납니다. nohide 옵션을 사용하면 명시적인 마운트 없이 두 번째 디렉터리 계층 구조가 생성됩니다. ( 메모:이 옵션을 사용할 수 없었습니다...)
• 로(rw)- 읽기(쓰기) 요청만 허용합니다. (결국 읽기/쓰기 가능 여부는 파일 시스템 권한에 따라 결정되며, 서버는 파일 읽기 요청과 실행 요청을 구분하지 못하기 때문에 사용자가 읽은 경우에는 읽기를 허용합니다. 또는 권리를 행사할 수 있습니다.)
• 안전하다 (안전하지 않다)- 보안 포트에서 NFS 요청이 필요합니다(< 1024), чтобы программа без 루트 권한디렉터리 계층 구조를 마운트할 수 없습니다.
• 하위 트리_체크(no_subtree_check)- 파일 시스템의 하위 디렉터리만 내보내고 전체 파일 시스템을 내보내지 않는 경우 서버는 요청한 파일이 내보낸 하위 디렉터리에 있는지 확인합니다. 확인을 비활성화하면 보안은 약화되지만 데이터 전송 속도는 빨라집니다.
• 동기화(비동기)- 요청에 의한 변경 사항이 디스크에 기록된 후에만 서버가 요청에 응답해야 함을 지정합니다. 비동기 옵션은 정보가 디스크에 기록될 때까지 기다리지 않도록 서버에 지시합니다. 이는 성능을 향상시키지만 안정성을 떨어뜨립니다. 연결이 끊어지거나 장비에 장애가 발생하는 경우 정보가 손실될 수 있습니다.
• wdelay (no_wdelay)- 후속 쓰기 요청이 보류 중인 경우 쓰기 요청 실행을 지연하여 더 큰 블록에 데이터를 쓰도록 서버에 지시합니다. 이렇게 하면 대량의 쓰기 명령 대기열을 보낼 때 성능이 향상됩니다. no_wdelay는 쓰기 명령의 실행을 지연하지 않도록 지정합니다. 이는 서버가 관련되지 않은 명령을 많이 받는 경우 유용할 수 있습니다.

심볼릭 링크 및 장치 파일을 내보냅니다.기호 링크가 포함된 디렉토리 계층을 내보낼 때 링크 객체는 클라이언트(원격) 시스템에서 액세스할 수 있어야 합니다. 즉, 다음 규칙 중 하나가 충족되어야 합니다.

장치 파일은 인터페이스에 속합니다. 장치 파일을 내보내면 이 인터페이스가 내보내집니다. 클라이언트 시스템에 동일한 유형의 장치가 없으면 내보낸 장치가 작동하지 않습니다. 클라이언트 시스템에서는 NFS 객체를 마운트할 때 nodev 옵션을 사용하면 마운트된 디렉터리의 장치 파일이 사용되지 않도록 할 수 있습니다.

기본 옵션은 시스템마다 다를 수 있으며 /var/lib/nfs/etab에서 찾을 수 있습니다. /etc/exports에서 내보낸 디렉터리를 설명하고 NFS 서버를 다시 시작하면 누락된 모든 옵션(읽기: 기본 옵션)이 /var/lib/nfs/etab 파일에 반영됩니다.

사용자 ID 표시(매칭) 옵션

다음 내용을 더 잘 이해하려면 기사를 읽어 보시기 바랍니다. 각 Linux 사용자는 파일에 설명된 고유한 UID와 기본 GID를 가지고 있습니다. /etc/passwd그리고 /etc/그룹. NFS 서버는 원격 호스트의 운영 체제가 사용자를 인증하고 올바른 UID 및 GID를 할당했다고 가정합니다. 파일을 내보내면 클라이언트 시스템 사용자에게 마치 서버에 직접 로그인한 것처럼 해당 파일에 대한 동일한 액세스 권한이 부여됩니다. 따라서 NFS 클라이언트가 서버에 요청을 보내면 서버는 UID와 GID를 사용하여 로컬 시스템의 사용자를 식별하므로 몇 가지 문제가 발생할 수 있습니다.

• 사용자는 두 시스템 모두에서 동일한 식별자를 갖고 있지 않을 수 있으므로 다른 사용자의 파일에 액세스할 수 있습니다.
• 왜냐하면 루트 사용자의 ID가 항상 0인 경우 이 사용자는 지정된 옵션에 따라 로컬 사용자에 매핑됩니다.

다음 옵션은 원격 사용자를 로컬 사용자로 표시하는 규칙을 설정합니다.

• root_squash (no_root_squash)- 옵션이 지정된 경우 루트_스쿼시, 루트 사용자의 요청은 익명 uid/gid 또는 anonuid/anongid 매개변수에 지정된 사용자에 매핑됩니다.
• no_all_squash (모든_스쿼시)- 접속한 사용자의 UID/GID를 변경하지 않습니다. 옵션 all_squash루트뿐만 아니라 모든 사용자의 표시를 익명으로 설정하거나 anonuid/anongid 매개변수에 지정합니다.
• 익명= UID 그리고 anongid = GID - 익명 사용자의 UID/GID를 명시적으로 설정합니다.
• map_static= /etc/file_maps_users - 원격 UID/GID와 로컬 UID/GID의 매핑을 설정할 수 있는 파일을 지정합니다.

사용자 매핑 파일 사용 예:

ARCHIV ~ # cat /etc/file_maps_users # 사용자 매핑 # 원격 로컬 주석 uid 0-50 1002 # 원격 UID 0-50을 사용하여 사용자를 로컬 UID 1002에 매핑 gid 0-50 1002 # 원격 GID 0-50을 사용하여 사용자 매핑 로컬 GID 1002

NFS 서버 관리

NFS 서버는 다음 유틸리티를 사용하여 관리됩니다.

• nfsstat
• showmsecure(비보안)마운트

nfsstat: NFS 및 RPC 통계

nfsstat 유틸리티를 사용하면 RPC 및 NFS 서버의 통계를 볼 수 있습니다. 명령 옵션은 man nfsstat에서 찾을 수 있습니다.

showmount: NFS 상태 정보 표시

showmount 유틸리티마운트된 파일 시스템에 대해 원격 호스트의 rpc.mountd 데몬을 쿼리합니다. 기본적으로 정렬된 클라이언트 목록이 반환됩니다. 열쇠:

• --모두- 클라이언트가 디렉토리를 마운트한 위치를 나타내는 클라이언트 및 마운트 지점 목록이 표시됩니다. 이 정보는 신뢰할 수 없을 수도 있습니다.
• --디렉토리- 마운트 지점 목록이 표시됩니다.
• --수출- 내보낸 파일 시스템 목록이 nfsd 관점에서 표시됩니다.

인수 없이 showmount를 실행하면 마운트가 허용된 시스템에 대한 정보가 콘솔에 인쇄됩니다. 현지의카탈로그. 예를 들어 ARCHIV 호스트는 지정된 디렉터리를 마운트할 수 있는 호스트의 IP 주소와 함께 내보낸 디렉터리 목록을 제공합니다.

파일 ~ # showmount --exports archive 아카이브용 내보내기 목록: /archiv-big 10.0.0.2 /archiv-small 10.0.0.2

인수에 호스트 이름/IP를 지정하면 이 호스트에 대한 정보가 표시됩니다.

ARCHIV ~ # showmount 파일 clnt_create: RPC: 프로그램이 등록되지 않았습니다 # 이 메시지는 NFSd 데몬이 FILES 호스트에서 실행되고 있지 않음을 알려줍니다.

내보내기fs: 내보낸 디렉터리 관리

이 명령은 파일에 지정된 내보낸 디렉터리를 제공합니다. /etc/exports, 서비스하지 않지만 파일과 동기화한다고 쓰는 것이 더 정확할 것입니다 /var/lib/nfs/xtab xtab에서 존재하지 않는 항목을 제거합니다. -r 인수를 사용하여 nfsd 데몬이 시작되면 내보내기fs가 실행됩니다. 2.6 커널 모드의 importfs 유틸리티는 /var/lib/nfs/ 디렉토리의 파일을 통해 rpc.mountd 데몬과 통신하며 커널과 직접 통신하지 않습니다. 매개변수 없이 현재 내보낸 파일 시스템 목록을 표시합니다.

importfs 매개변수:

• [클라이언트:디렉토리 이름] - 지정된 클라이언트에 대해 지정된 파일 시스템을 추가하거나 제거합니다.
• -v - 추가 정보 표시
• -r - 모든 디렉터리를 다시 내보냅니다(/etc/exports 및 /var/lib/nfs/xtab 동기화).
• -u - 내보낸 목록에서 제거
• -a - 모든 파일 시스템을 추가하거나 제거합니다.
• -o - 쉼표로 구분된 옵션(/etc/exports에 사용된 옵션과 유사, 즉 이미 마운트된 파일 시스템의 옵션을 변경할 수 있음)
• -i - 추가 시 /etc/exports를 사용하지 않고 현재 명령줄 옵션만 사용합니다.
• -f - 커널 2.6에서 내보낸 시스템 목록을 재설정합니다.

NFS 클라이언트

원격 파일 시스템의 파일에 액세스하기 전에 클라이언트(클라이언트 OS)는 다음을 수행해야 합니다. 그것을 마운트서버로부터 수신 그것에 대한 포인터. NFS 마운트급증하는 자동 마운터(amd, autofs, automount, supermount, superpupermount) 중 하나를 사용하거나 이를 사용하여 수행할 수 있습니다. 설치 과정은 위의 그림에 잘 나와 있습니다.

~에 NFS 클라이언트데몬을 실행할 필요가 없습니다. 클라이언트 기능커널 모듈을 실행합니다 커널/fs/nfs/nfs.ko, 원격 파일 시스템을 마운트할 때 사용됩니다. 서버에서 내보낸 디렉터리는 다음과 같은 방법으로 클라이언트에 탑재될 수 있습니다.

• mount 명령을 사용하여 수동으로
• /etc/fstab에 설명된 파일 시스템을 마운트할 때 부팅 시 자동으로
• autofs 데몬을 사용하여 자동으로

정보가 방대하기 때문에 이 기사에서는 autofs를 사용하는 세 번째 방법을 고려하지 않겠습니다. 아마도 향후 기사에서는 별도의 설명이 있을 것입니다.

mount 명령을 사용하여 네트워크 파일 시스템 마운트

mount 명령을 사용하는 예가 게시물에 나와 있습니다. 여기서는 NFS 파일 시스템을 마운트하기 위한 mount 명령의 예를 살펴보겠습니다.

파일 ~ # mount -t nfs archivev:/archiv-small /archivs/archiv-small 파일 ~ # mount -t nfs -o ro archivev:/archiv-big /archivs/archiv-big 파일 ~ # 마운트 ..... .. archivev:/archiv-small /archivs/archiv-small 유형 nfs(rw,addr=10.0.0.6) archivev:/archiv-big /archivs/archiv-big 유형 nfs(ro,addr=10.0.0.6)

첫 번째 명령은 내보낸 디렉터리를 마운트합니다. /archiv-작은서버에서 보관소로컬 마운트 지점으로 /archivs/archiv-small기본 옵션(예: 읽기 및 쓰기)이 있습니다. 하지만 마운트 명령최신 배포판에서는 유형을 지정하지 않고도 어떤 유형의 파일 시스템이 사용되는지 이해할 수 있지만 여전히 매개변수를 나타냅니다. -t nfs바람직한. 두 번째 명령은 내보낸 디렉터리를 마운트합니다. /archiv-big서버에서 보관소로컬 디렉토리로 /archivs/archiv-big읽기 전용 옵션 사용( 로). 마운트 명령매개변수가 없으면 장착 결과가 명확하게 표시됩니다. 읽기 전용 옵션(ro) 외에 다른 옵션도 지정할 수 있습니다. NFS 마운트 시 기본 옵션:

• 노수드- 이 옵션은 마운트된 디렉터리에서 프로그램을 실행하는 것을 금지합니다.
• 노드(장치 없음 - 장치 아님) - 이 옵션은 문자 및 블록 특수 파일을 장치로 사용하는 것을 금지합니다.
• 잠금 (잠금)- NFS 잠금을 허용합니다(기본값). nolock은 NFS 잠금을 비활성화하고(lockd 데몬을 시작하지 않음) NFS 잠금을 지원하지 않는 이전 서버에서 작업할 때 유용합니다.
• 마운트호스트=이름- NFS 마운트 데몬이 실행 중인 호스트의 이름 - mountd.
• 마운트포트=n - mountd 데몬이 사용하는 포트입니다.
• 포트=n- NFS 서버에 연결하는 데 사용되는 포트(rpc.nfsd 데몬이 RPC 서버에 등록되지 않은 경우 기본값은 2049입니다). n=0(기본값)이면 NFS는 서버의 포트맵을 쿼리하여 포트를 결정합니다.
• 크기=n(읽기 블록 크기 - 읽기 블록 크기) - NFS 서버에서 한 번에 읽는 바이트 수입니다. 표준 - 4096.
• w크기=n(쓰기 블록 크기 - 쓰기 블록 크기) - NFS 서버에 한 번에 쓰는 바이트 수입니다. 표준 - 4096.
• TCP또는 UDP- NFS를 탑재하려면 각각 TCP 또는 UDP 프로토콜을 사용합니다.
• bg- 서버 접속이 불가능할 경우, 다시 시도해 주세요. 배경, 시스템 부팅 프로세스를 차단하지 않도록 합니다.
• fg- 서버 접속이 불가능할 경우 우선순위 모드로 다시 시도해 보세요. 이 옵션은 마운트 시도를 반복하여 시스템 부팅 프로세스를 차단할 수 있습니다. 이러한 이유로 fg 매개변수는 주로 디버깅에 사용됩니다.

NFS 마운트의 속성 캐싱에 영향을 주는 옵션

파일 속성수정 시간, 크기, 하드 링크, 소유자 등 (inode)에 저장된 정보는 일반적으로 일반 파일의 경우 자주 변경되지 않고 디렉터리의 경우 훨씬 덜 자주 변경됩니다. ls와 같은 많은 프로그램은 읽기 전용으로 파일에 액세스하고 파일 속성이나 내용을 변경하지 않지만 비용이 많이 드는 네트워크 작업으로 시스템 리소스를 낭비합니다. 자원 낭비를 방지하기 위해 다음을 수행할 수 있습니다. 이러한 속성을 캐시합니다.. 커널은 파일의 수정 시간을 이용하여 캐시 내의 수정 시간과 파일 자체의 수정 시간을 비교하여 캐시가 오래되었는지 여부를 판단합니다. 속성 캐시는 지정된 매개변수에 따라 주기적으로 업데이트됩니다.

• AC (노악) (속성 캐시- 속성 캐싱) - 속성 캐싱을 허용합니다(기본값). noac 옵션을 사용하면 서버 속도가 느려지지만 여러 클라이언트가 공통 계층 구조에 정보를 적극적으로 기록할 때 속성이 오래되는 것을 방지할 수 있습니다.
• acdirmax=n (속성 캐시 디렉터리 파일 최대값- 디렉터리 파일에 대한 최대 속성 캐싱) - NFS가 디렉터리 속성을 업데이트하기 전에 기다리는 최대 시간(기본값 60초)
• acdirmin=n (속성 캐시 디렉터리 파일 최소- 디렉터리 파일에 대한 최소 속성 캐싱) - NFS가 디렉터리 속성을 업데이트하기 전에 기다리는 최소 시간(기본값 30초)
• 에이커최대=n (속성 캐시 일반 파일 최대값- 일반 파일의 속성 캐싱 최대값) - 일반 파일의 속성을 업데이트하기 전에 NFS가 대기하는 최대 시간(초)(기본값 60초)
• 아크레그민=n (속성 캐시 일반 파일 최소값- 일반 파일의 최소 속성 캐싱) - 일반 파일의 속성을 업데이트하기 전에 NFS가 대기하는 최소 시간(기본값 3초)
• 액티메오=n (속성 캐시 시간 초과- 속성 캐싱 시간 초과) - 위의 모든 옵션에 대한 값을 대체합니다. actimeo를 지정하지 않으면 위의 값은 기본값을 사용합니다.

NFS 오류 처리 옵션

다음 옵션은 서버로부터 응답이 없거나 I/O 오류가 발생할 때 NFS가 수행하는 작업을 제어합니다.

• fg(bg) (전경- 전경, 배경- 백그라운드) - 포그라운드/백그라운드에서 실패한 NFS를 마운트하려고 시도합니다.
• 단단한 (부드러운)- 시간 초과에 도달하면 "서버가 응답하지 않습니다"라는 메시지를 콘솔에 표시하고 계속해서 마운트를 시도합니다. 옵션이 주어지면 부드러운- 시간 초과 동안 작업을 호출한 프로그램에 I/O 오류에 대해 알립니다. (소프트 옵션은 사용하지 않는 것이 좋습니다)
• nointr (intr) (인터럽트 없음- 중단하지 않음) - 큰 시간 초과에 도달한 경우 하드 마운트된 디렉터리 계층 구조의 파일 작업을 중단하는 신호를 허용하지 않습니다. 내부- 중단을 활성화합니다.
• 재전송=n (재전송 값- 재전송 값) - n개의 작은 시간 초과 이후 NFS는 큰 시간 초과(기본값 3)를 생성합니다. 시간 초과가 크면 하드/소프트 옵션 지정 여부에 따라 작업이 중지되거나 "서버 응답 없음" 메시지가 콘솔에 인쇄됩니다.
• 재시도=n (재시도 값- 재시도 값) - NFS 서비스가 포기하기 전에 마운트 작업을 반복하는 시간(분)입니다(기본값 10000).
• 시간=n (시간 초과 값- 시간 초과 값) - RPC 또는 작은 시간 초과(기본값 7)의 경우 NFS 서비스가 재전송하기 전에 대기하는 10분의 1초입니다. 이 값은 최대 60초까지 또는 큰 시간 초과가 발생할 때까지 각 시간 초과마다 증가합니다. 네트워크 사용량이 많거나 서버 속도가 느리거나 요청이 여러 라우터나 게이트웨이를 통과하는 경우 이 값을 늘리면 성능이 향상될 수 있습니다.

부팅 시 자동 NFS 마운트(/etc/fstab의 파일 시스템에 대한 설명)

ping 명령을 사용하여 전송된 패킷의 특정 값(rsize/wsize 값)에 대한 최적의 시간을 선택할 수 있습니다.

파일 ~ # ping -s 32768 archive PING archive.DOMAIN.local (10.0.0.6) 32768(32796) 바이트의 데이터. archivev.domain.local(10.0.0.6)에서 32776바이트: icmp_req=1 ttl=64 time=0.931 ms archivev.domain.local(10.0.0.6)에서 32776바이트: icmp_req=2 ttl=64 time=0.958 ms 32776바이트 archivev.domain.local(10.0.0.6)에서: icmp_req=3 ttl=64 time=1.03 ms 32776바이트 archivev.domain.local(10.0.0.6)에서: icmp_req=4 ttl=64 time=1.00 ms 아카이브에서 32776바이트 .domain.local (10.0.0.6): icmp_req=5 ttl=64 time=1.08 ms ^C --- archive.DOMAIN.local ping 통계 --- 전송된 패킷 5개, 수신된 패킷 5개, 패킷 손실 0%, 시간 4006ms rtt 최소/평균/최대/mdev = 0.931/1.002/1.083/0.061ms

보시다시피 크기 32768(32Kb)의 패킷을 보낼 때 클라이언트에서 서버로 그리고 다시 돌아오는 데 걸리는 이동 시간은 약 1밀리초입니다. 만약에 주어진 시간 200ms 동안 규모를 벗어나면 교환 값을 3~4배 초과하도록 timeo 값을 높이는 것을 고려해야 합니다. 따라서 이 테스트는 네트워크 부하가 높을 때 수행하는 것이 좋습니다.

NFS 시작 및 방화벽 설정

이 메모는 블로그 http://bog.pp.ru/work/NFS.html에서 복사되었습니다. 많은 분들께 감사드립니다!!!

"올바른" 포트(방화벽용)를 사용하여 NFS 서버, 마운트, 차단, 할당량 및 상태를 실행합니다.

• 먼저 클라이언트의 모든 리소스를 마운트 해제하는 것이 좋습니다.
• NFSv4를 사용하지 않으려는 경우 rpcidmapd 시작을 중지하고 비활성화합니다. chkconfig --level 345 rpcidmapd off service rpcidmapd stop
• 필요한 경우 portmap, nfs 및 nfslock 서비스가 시작되도록 허용합니다. chkconfig --levels 345 portmap/rpcbind on chkconfig --levels 345 nfs on chkconfig --levels 345 nfslock on
• 필요한 경우 nfslock 및 nfs 서비스를 중지하고, portmap/rpcbind를 시작하고, 모듈을 언로드하십시오. service nfslock stop service nfs stop service portmap start # service rpcbind start umount /proc/fs/nfsd service rpcidmapd stop rmmod nfsd service autofs stop # 나중에 어딘가에 시작해야 합니다 rmmod nfs rmmod nfs_acl rmmod lockd
• 열린 포트
  • RPC의 경우: UDP/111, TCP/111
  • NFS의 경우: UDP/2049, TCP/2049
  • rpc.statd의 경우: UDP/4000, TCP/4000
  • lockd의 경우: UDP/4001, TCP/4001
  • 마운트용: UDP/4002, TCP/4002
  • rpc.rquota의 경우: UDP/4003, TCP/4003
• rpc.nfsd 서버의 경우 /etc/sysconfig/nfs에 RPCNFSDARGS="--port 2049" 줄을 추가합니다.
• 마운트 서버의 경우 /etc/sysconfig/nfs에 MOUNTD_PORT=4002 줄을 추가합니다.
• 새 버전에 대해 rpc.rquota를 구성하려면 /etc/sysconfig/nfs에 RQUOTAD_PORT=4003 행을 추가해야 합니다.
• rpc.rquota를 구성하려면 이전 버전에 필요합니다(단, 할당량 패키지 3.08 이상이 있어야 함) /etc/services rquotad 4003/tcp rquotad 4003/udp에 추가
• /etc/exports의 적절성을 확인합니다.
• rpc.nfsd, mountd 및 rpc.rquota 서비스를 실행하십시오(삭제해야 하는 경우 rpcsvcgssd 및 rpc.idmapd는 동시에 시작됩니다). service nfsd start 또는 새 버전에서는 service nfs start
• 새 시스템에 대한 차단 서버의 경우 /etc/sysconfig/nfs에 LOCKD_TCPPORT=4001 LOCKD_UDPPORT=4001 줄을 추가합니다.
• 이전 시스템용 잠금 서버의 경우 /etc/modprobe[.conf]에 직접 추가합니다. options lockd nlm_udpport=4001 nlm_tcpport=4001
• rpc.statd 상태 서버를 포트 4000에 바인딩합니다(이전 시스템의 경우 /etc/init.d/nfslock에서 -p 4000 스위치를 사용하여 rpc.statd를 실행) STATD_PORT=4000
• lockd 및 rpc services.statd 서비스를 시작하십시오. nfslock start
• "lsof -i -n -P" 및 "netstat -a -n"을 사용하여 모든 포트가 정상적으로 바인딩되었는지 확인하십시오(일부 포트는 lsof가 볼 수 없는 커널 모듈에서 사용됨).
• "재구축" 전에 클라이언트가 서버를 사용했지만 마운트 해제할 수 없는 경우 클라이언트에서 자동 마운트 서비스(am-utils, autofs)를 다시 시작해야 합니다.

NFS 서버 및 클라이언트 구성 예

서버 구성

NFS 공유 디렉토리를 열고 쓰기 가능하게 만들려면 다음 옵션을 사용할 수 있습니다. all_squash옵션과 함께 무형의그리고 무생물. 예를 들어 "nobody" 그룹의 "nobody" 사용자에 대한 권한을 설정하려면 다음을 수행할 수 있습니다.

ARCHIV ~ # cat /etc/exports # 192.168.0.100의 클라이언트에 대한 읽기 및 쓰기 액세스 권한, gid 99 /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99) ) 사용자 99에 대한 rw 액세스 권한 포함 # 192.168.0.100의 클라이언트에 대한 읽기 및 쓰기 액세스, gid 99 /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99)) 사용자 99에 대한 rw 액세스

이는 또한 지정된 디렉터리에 대한 액세스를 허용하려면 누구도 공유 디렉터리의 소유자여야 함을 의미합니다.

남자 마운트
남자 수출
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm - IBM의 NFS 성능.

감사합니다, McSim!

쉽고 빠르게 키울 수 있는 방법을 알려드립니다. NFS Ubuntu Linux Server 14-04.1에 서버를 설치하고 NFS 프로토콜의 작동 원리를 이해하고 이론을 고려합니다.

이론

약어 NFS니드포 스피드 - 네트워크 파일 시스템을 의미합니다. 이것은 서버에 원격 디렉터리를 마운트할 수 있는 분산 네트워크 파일 시스템에 액세스하기 위한 프로토콜입니다. 이를 통해 다른 서버의 디스크 공간을 사용하여 파일을 저장하고 여러 서버에서 정기적으로 데이터를 쓸 수 있습니다.

프로토콜에는 클라이언트-서버 모델이 있습니다. 즉, NFS 패키지가 설치된 하나의 서버(공유라는 단어에서 "공유"라고도 함)가 해당 디렉터리와 파일에 대한 액세스를 제공하고 클라이언트 컴퓨터는 회로망. 우리가 읽은 내용을 다이어그램으로 통합해 보겠습니다.

NFS 서버에 대한 호출은 프로토콜 패킷 형태로 이루어집니다. RPC(원격 호출 절차), 다른 네트워크 공간, 즉 원격 서버에서 다양한 기능이나 절차를 수행할 수 있습니다.

서버에 연결하는 사용자의 인증은 IP 주소와 특수 사용자 식별자를 통해 수행됩니다. UID및 그룹 GID. 아니다 가장 좋은 방법기존의 "로그인/비밀번호" 모델과 비교하여 저장된 파일의 보안과 관련하여. 그러나 이 아키텍처와 NFS가 세션을 설정하지 않고 UDP 프로토콜을 사용했다는 사실 덕분에 네트워크 및 클라이언트 컴퓨터 자체의 오류로부터 실질적으로 영향을 받지 않습니다. 따라서 오류가 발생하면 파일 전송이 일시 중지되고, 연결이 설정되면 재구성할 필요 없이 전송이 재개됩니다.

설정

이론은 확실하다고 생각하므로 실습으로 넘어가겠습니다. 말했듯이 모든 설정은 Ubuntu 14.04.1에서 수행됩니다.

먼저 NFS 서버 역할을 할 컴퓨터에 필요한 구성 요소를 설치해야 합니다.

따라서 액세스(“공유”) 디렉터리를 배포할 수 있는 nfs-kernel-server 패키지를 다운로드합니다. 이렇게 하려면 향후 NFS 서버에 다음 명령을 입력하십시오.

Sudo apt-get 업데이트 sudo apt-get 설치 nfs-커널-서버

이제 액세스를 배포하려는 실제 디렉터리를 만듭니다. 서버에 이미 존재하는 디렉토리를 "공유"할 수도 있다는 점은 주목할 가치가 있지만 새 디렉토리를 생성하겠습니다.

Sudo chown 아무도:nogroup /var/nfs

이 명령은 사용자가 직접 생성한 디렉터리에만 입력하고 기존 디렉터리(예: /home)에는 입력하지 마십시오.

다음 단계는 NFS 자체의 구성을 변경하는 것입니다. 해당 구성은 /etc/exports 파일에 있으며, 즐겨 사용하는 편집기로 열어 편집할 수 있습니다.

Sudo nano /etc/exports

다양한 NFS 버전에 대한 구성 예가 포함된 주석 처리된 줄이 포함된 구성 파일이 표시됩니다.

주석이 달린 것은 기호로 시작하는 것입니다. # , 이는 여기에 지정된 매개변수가 유효하지 않음을 의미합니다.

이 파일에 주석 처리되지 않은 다음 줄을 추가해야 합니다.

/var/nfs 10.10.0.10/24(rw,sync,no_subtree_check)

• /var/nfs- 공유하고 싶은 디렉토리
• 10.10.0.10 - 디렉터리에 대한 액세스 권한을 부여해야 하는 클라이언트 컴퓨터의 IP 주소 및 마스크
• rw- 클라이언트가 디렉터리에 있는 파일을 읽고(r) 쓸 수 있도록(w) 허용합니다.
• 동조- 이 옵션을 사용하면 NFS가 클라이언트에 응답하기 전에 변경 사항을 디스크에 기록합니다.
• no_subtree_check- 이 옵션은 사용자가 특정 하위 디렉터리의 파일에 액세스하고 있는지 확인하는 기능을 비활성화합니다. 이 검사를 활성화하면 파일이나 하위 디렉터리의 이름이 변경되어 사용자가 이에 액세스하려고 할 때 문제가 발생할 수 있습니다.

그런 다음 공유 디렉터리와 클라이언트 간의 대응 테이블을 생성한 다음 NFS 서비스를 시작해야 합니다. 이렇게 하려면 다음 명령을 입력하십시오.

"NFC"(근거리 무선 통신) 조합은 최신 스마트폰 및 태블릿 사양에서 점점 더 많이 발견되고 있습니다. 이 기사에서는 이 인터페이스를 실제 사용의 관점에서 고려하여 독자가 휴대폰에서 이 인터페이스를 사용해야 하는지에 대해 독립적으로 결론을 내릴 수 있도록 노력할 것입니다.

테스트에서는 이미 리소스에서 자세히 검토한 두 가지 스마트폰 모델인 Acer CloudMobile S500과 Sony Xperia acro S를 사용했습니다. 또한 설명된 프로그램 및 사용 시나리오를 포함한 대부분의 정보는 실행 중인 스마트폰에만 적용된다는 점을 지적하고 싶습니다. 안드로이드 기반. NFC 작업과 관련하여 오늘날 가장 "친숙한" 운영 체제는 바로 이 운영 체제입니다.

소개

언뜻 보면 오늘날 수많은 무선 인터페이스가 이미 가능한 모든 인기 있는 작업과 시나리오를 포괄하는 것처럼 보일 수 있으므로 다른 옵션은 필요하지 않습니다. 그런데 발전과정을 보면 현대 기술, 에너지 소비 문제에 점점 더 많은 관심이 집중되고 있음을 알 수 있습니다. 특히 다음과 같은 경우에는 더욱 그렇습니다. 우리 얘기 중이야영형 모바일 장치. 특히 잘 알려진 Bluetooth 프로토콜 제품군의 버전 4.0은 배터리 비용 절감을 목표로 하고 있습니다. 두 번째로 언급할 가치가 있는 점은 모든 작업에 장거리가 필요한 것은 아니라는 것입니다. 반대의 경우에도 발생합니다. 즉, 상호 작용하는 장치 간의 거리를 명시적으로 제한하려고 합니다. 명백한 소비 감소 외에도 이는 안전에도 영향을 미칩니다. 전송되는 데이터의 양에 대해서도 비슷한 설명을 할 수 있습니다. 따라서 단거리에서 작동하고 낮은 전력 소비를 특징으로 하는 느린 무선 인터페이스에 대한 아이디어는 존재할 권리가 있습니다.

NFC 개발의 역사는 2004년 노키아, 필립스, 소니가 다양한 기기 간 인터페이스를 개발하고 표준화할 목적으로 다양한 기기 상호작용을 위한 터치 기반 인터페이스 개발을 발표하면서 시작됐다. 그러나 사양의 첫 번째 버전은 조금 더 일찍 생성되었습니다. 아마도 현대 표준에 따르면 이 기술은 매우 초기 단계로 간주될 수 있지만(RFID의 역사를 고려하지 않으면) 이미 실제 제품과 서비스에서 자주 발견됩니다. 특히 2월 말에 개최된 모바일 월드 콩그레스 2013에서는 이 주제를 주제로 한 많은 스탠드와 시연이 이루어졌습니다.

이 표시는 NFC 기술이 탑재된 장치에서 찾을 수 있습니다.

인터페이스의 형식적 특성은 다음과 같습니다: 수 센티미터 거리에서의 작동, 최대 속도정보 교환은 약 400Kbps, 전이중 데이터 교환이 지원되고 작동 주파수는 13.56MHz이며 연결 설정 시간은 0.1초를 초과하지 않으며 작동 모드는 지점 간입니다. 이러한 매개변수는 NFC를 다른 널리 사용되는 무선 인터페이스와 근본적으로 구별한다는 것을 알 수 있습니다.

장치에 대해 이야기하면 NFC의 활성 컨트롤러 외에도 전원을 공급받는 수동 옵션(일반적으로 태그라고 함)도 있습니다. 무선으로활성 컨트롤러에서. 한 가지 예는 대중교통 여행을 위한 최신 카드입니다. 태그는 단순한 데이터 저장소이며 일반적으로 크기가 4KB 미만입니다. 대부분 읽기 모드만 제공하지만 쓰기를 지원하는 옵션도 있습니다.

패시브 NFC 태그에 대한 가장 간단한 옵션 중 하나

컨트롤러의 컴팩트한 크기와 낮은 소비전력 덕분에 SIM 카드나 카드와 같은 작은 디자인에도 NFC를 구현할 수 있습니다. 마이크로SD 메모리. 그러나 완전한 작동을 위해서는 특수 안테나를 사용해야 합니다. 휴대폰에서는 일반적으로 배터리 커버 뒷면에 있거나 배터리 커버에 내장되어 있습니다. 후면 패널, 장치에 탈착식 배터리가 없는 경우.

NFC 안테나는 종종 다음 위치에 배치됩니다. 뒷 표지스마트 폰

짧은 범위는 태블릿을 사용할 때 부정적인 영향을 미칠 수 있습니다. "포지셔닝"할 올바른 위치를 찾는 것이 원하는 만큼 쉽지 않을 수 있습니다. 이 문제를 해결하기 위해 일부 제조업체에서는 특수 기호로 안테나 위치를 표시합니다. 범위에 관해서는 우리의 경우 연결은 전화기 사이와 수동 태그 모두에서 4cm 이하의 거리에서 작동했습니다.

보안 관점에서 개발자는 가로채기 및 릴레이 공격에 대한 보호 요소를 구현하지 않았습니다. 물론 구현하기가 어렵습니다. 보안 솔루션, 애플리케이션 자체를 더 높은 수준에서 보호해야 하기 때문입니다. 실제로 TCP/IP와 같이 잘 알려진 프로토콜은 유사하게 작동합니다. 따라서 실용적인 관점에서 볼 때, 맞춤형 결제 시스템 프로그램을 통한 추가 보호 없이 휴대폰을 분실하는 것은 통신을 가로채는 것보다 더 위험해 보입니다.

아마도 오늘날 NFC에 대해 알아야 할 가장 중요한 점은 인터페이스 자체가 실제 실제 사용 사례나 솔루션을 제공하지 않는다는 것입니다. 예를 들어 파일 전송 방법, 헤드셋 연결 방법, 네트워크 액세스 제공 방법을 명확하게 설명하는 프로필이 있는 Bluetooth와 달리 NFC는 기반일 뿐이며 NFC를 통해 작동하는 추가 소프트웨어에 의해 직접 작동 시나리오가 제공됩니다. 한편으로는 이는 개발자에게 큰 기회를 제공하지만 다른 한편으로는 다양한 애플리케이션과 장치의 상호 작용을 보장할 때 문제가 됩니다.

흥미롭게도 스마트폰이나 태블릿에 설치된 모든 프로그램은 운영 체제에 NFC 관련 이벤트 핸들러로 등록할 수 있으며, 외부에서 호출하면 다음과 같이 표시됩니다. 표준 메뉴“이 작업을 어떻게 수행하시겠습니까?” 일부 NFC 사용 사례에는 편리한 작업 자동화가 포함되므로 이러한 유틸리티로 장치에 과부하를 주지 않는 것이 좋습니다.

NFC 포럼은 특정 시나리오(특히 태그에 짧은 메시지를 저장하기 위한 NDEF 및 장치 간 정보 교환을 위한 SNEP(Simple NDEF Exchange Protocol))에 대한 프로토콜 표준화를 제안함으로써 이러한 불확실성을 해결하려고 노력하지만 실제로 특정 장치의 호환성을 결정하는 것은 대개 부족함으로 인해 방해를 받습니다. 자세한 정보제조업체 및 진단 도구에서. 또 다른 비서로는 Google이 있는데, 최근 몇 년 동안 안드로이드 버전 Android Beam 자체 개발. 이를 통해 호환 장치 간에 특정 유형의 정보를 교환할 수 있습니다.

안드로이드 빔

먼저 두 기기 모두 NFC가 활성화되어 있고 Android Beam이 활성화되어 있으며 화면이 잠금 해제되어 있는지 확인해야 합니다. 테스트한 모델에서 NFC는 화면이 켜져 있고 장치가 완전히 잠금 해제된 경우에만 작동합니다. 그러나 아마도 다른 장치에서는 다른 알고리즘을 사용할 수도 있습니다. 어쨌든 활성 인터페이스는 작동하는 데 배터리 전원이 거의 필요하지 않으며 지금까지 설명된 접근 방식은 상당히 합리적으로 보입니다. 작업을 단순화하는 한 가지 옵션은 잠금 화면을 비활성화하는 것입니다. 이 경우 태그를 식별하려면 스마트폰을 켜는 것만으로도 충분합니다. 또 다른 불편함은 기기들이 서로를 찾은 후 화면을 터치해 동작을 확인해야 한다는 점이다. 통신을 방해하지 않고 이를 수행하는 것이 항상 쉬운 것은 아니며, 특히 두 장치를 서로 다른 두 사람이 손에 들고 있는 경우에는 더욱 그렇습니다.

다음 단계는 전송하려는 장치의 애플리케이션 중 하나를 선택하는 것입니다. 특히 다음과 같습니다.

• Google Chrome - 현재 열려 있는 링크를 전송합니다.
• YouTube 클라이언트 - 비디오 클립 전송(링크로)
• 구글지도- 장소나 경로의 이전;
• 연락처 - 연락처 카드를 전송합니다.
• 구글 플레이— 신청서 전송;
• 갤러리 - 사진 전송.

그런 다음 장치를 서로 더 가깝게 가져옵니다. 파트너가 감지되면 전송 장치에서 신호음이 들리고 데스크톱 이미지가 축소됩니다. 이 순간 화면 이미지를 터치하고 성공적인 전송에 대한 두 번째 신호가 들릴 때까지 손가락을 누르고 있어야 합니다.

우리는 나열된 옵션을 시도했고 거의 모든 옵션이 실제로 작동했습니다. 우리 장치가 다른 제조업체에서 생산되었다는 사실조차도 그들이 찾는 것을 방해하지 않았습니다. 공통 언어. 그러나 몇 가지 의견은 여전히 ​​할만한 가치가 있습니다. Google 지도의 경로에는 문제가 없지만 현재 지도 표시만 전송되기 때문에 장소 옵션은 그다지 흥미롭지 않습니다. 원래 휴대폰 화면에 표시된 점은 수신자에게 도달하지 않습니다. 데이터를 올바르게 전송하는 주소 애플리케이션을 사용하면 상황을 수정할 수 있습니다. 연락처를 보낼 때 기술적인 관점에서 전송 형식은 vcf 텍스트 파일에 해당하므로 사진이 손실됩니다. 애플리케이션에 대해 이야기하면 휴대폰에 설치된 애플리케이션뿐만 아니라 Google Play에서 카드를 열 수도 있습니다. 스토어의 도서 및 기타 콘텐츠도 유사하게 지원됩니다. 당연히 우리는 다운로드했거나 특히 구매한 요소 자체가 아니라 링크 전송에 대해 이야기하고 있습니다. 사진 전송에 문제가 발생했습니다. Sony 장치에서는 이러한 유형의 데이터를 사용할 수 없습니다. 공식적인 표현은 '수신자의 기기가 Android Beam을 통한 대용량 데이터 전송을 지원하지 않습니다.'입니다. 젊은 인터페이스 또는 세부 사항 부족의 첫 번째 징후는 다음과 같습니다. 기술 사양장치. 공식적으로 두 장치에 NFC와 Android Beam이 모두 있지만 실제로는 실제 기능이 크게 다르며 이는 확인을 통해서만 알 수 있습니다. 덜 유명한 제조업체에 대해 무엇을 말할 수 있습니까? 이 기술을 구현하는 버전은 완전히 예측할 수 없습니다.

그건 그렇고, Android Beam 자체의 작업에 관해서. 기술에 대한 설명에서는 NFC를 통한 초기 설정 조정 후 데이터 전송이 Bluetooth 통신을 사용함을 나타냅니다. 모든 작업 형식에 매우 적은 양의 데이터 전송이 필요하다는 점을 고려하면 NFC 속도는 충분했지만 사진의 경우 분명히 충분하지 않았을 것입니다. 따라서 Sony가 더 빠른 인터페이스로의 전환을 구현하지 않았다고 가정할 수 있습니다. 이 문제가 소프트웨어(이 장치에는 Android 4.0.4가 설치되어 있음을 기억하세요)인지 하드웨어인지 이해하는 것은 불가능합니다.

저희도 각자의 앱에서 같은 방법으로 저희가 만든 음악과 영상을 보내려고 했으나 수신자에는 아무 것도 나타나지 않았습니다.

태그 읽기 및 쓰기

설명된 Android Beam은 짧은 전송 및 처리 기능을 사용합니다. 정보 메시지. 그러나 실제로는 휴대폰에서 전송할 수 있을 뿐만 아니라 패시브 태그에서도 읽을 수도 있습니다. 어떤 면에서 이 기술은 휴대폰 카메라로 판독되는 잘 알려진 QR 코드와 유사합니다. 여기서 유용한 정보(예를 들어 웹 사이트 페이지 링크)은 말 그대로 수십 바이트를 차지합니다. 예를 들어 회사에서는 제품이나 서비스를 홍보하기 위해 태그를 사용할 수 있습니다. 패시브 태그의 컴팩트한 크기를 고려하면(더 정확하게는 두께가 종이 한 장과 비슷합니다. 안테나로 인해 면적은 여전히 ​​상당하며 5루블 동전 이상입니다) 거의 모든 위치에 배치할 수 있습니다. : 제품이 담긴 상자, 잡지, 정보지, 카운터 및 기타 장소.

패시브 NFC 태그는 전자열쇠로 제조 가능

우리 손으로 태그를 만드는 것에 대해 이야기한다면 이것은 완전히 실현 가능한 시나리오입니다. 이렇게 하려면 깨끗한 공백을 구입하고 휴대폰용 특수 프로그램을 사용하여 필요한 정보를 적어야 합니다. 예를 들어, 우리는 최소 두께의 스티커, 보호되는 플라스틱 원 및 열쇠 고리 등 여러 가지 옵션을 구입했습니다. 그들 모두는 매우 적은 양의 메모리를 가지고 있었습니다. 단지 144바이트에 불과했습니다(시중에는 4KB 옵션도 있습니다). 재작성 주기 수는 지정되지 않았지만 대부분의 애플리케이션 시나리오에서는 이 매개변수가 중요하지 않습니다. 태그 작업을 위해 NXP Semiconductors 프로그램(TagInfo 및 TagWriter)을 권장할 수 있습니다.

첫 번째를 사용하면 태그에서 데이터를 읽고 NDEF 표준에 따라 정보를 해독할 수 있으며, 두 번째는 자신만의 태그를 만드는 데 도움이 됩니다. 연락처, 링크, 문자, SMS 등 여러 NDEF 하위 옵션이 지원됩니다. 우편 메시지, 전화 번호, 블루투스 연결, 지리적 위치, 로컬 파일 링크, 애플리케이션 실행, URI. 레코드를 생성할 때 저장된 데이터의 양을 고려해야 한다는 점에 유의하세요. 예를 들어, 연락처 사진은 몇 킬로바이트를 차지할 수 있고, 메시지나 텍스트도 쉽게 144바이트를 초과할 수 있습니다. 그건 그렇고, 특수 플러그인이 포함된 NFC 연구소의 NFC TagInfo 프로그램은 생체 인식 여권의 컬러 사진을 읽고 보여줄 수 있습니다. 데이터 용량이 15킬로바이트에 달하면 NFC를 통해 읽는 데 약 20초가 걸린다. 이 경우 칩에서 데이터를 읽기 위해 일부 여권 세부 정보를 지정해야 하므로 추가 보호 수준이 제공됩니다.

읽기 태그의 자동 처리는 내용에 따라 다릅니다. 특히, 작업 자체를 수행하기 위해 추가 확인이 필요한 경우도 있습니다. 예를 들어 SMS의 경우 완성된 메시지 양식이 열리지만 사용자가 실제로 전송을 확인해야 합니다. 하지만 기록된 웹 링크는 브라우저에서 즉시 열릴 수 있습니다. 모든 자동화는 통제력 상실과 연관되어 있으므로 설명된 기능을 주의 깊게 사용해야 합니다. 단순히 태그를 교체하거나 다시 프로그래밍하는 것만으로도 공격자가 사용자를 원래 사이트 대신 가짜 사이트로 리디렉션할 수 있기 때문입니다. 이러한 자동 실행을 제한하는 표준 OS 설정을 찾지 못했습니다(NFC 자체를 비활성화하지 않는 한).

공공 장소에서 태그를 사용할 때 또 다른 중요한 점은 덮어쓰기 방지입니다. 태그를 기록할 때 정보 변경 시도를 모두 차단하는 보호 플래그를 설정할 수 있지만 더 이상 제거할 수는 없습니다. 따라서 레이블은 나중에 읽기 전용 모드로 사용됩니다. 가정용으로 사용하는 경우 대부분의 경우 이는 그다지 중요하지 않습니다.

태그 기록을 위한 몇 가지 프로그램을 더 언급해 보겠습니다.

기성 태그를 사용하여 장치 제어

NFC 구현 프로세스에 적극적으로 참여하는 사람 중 하나는 Sony입니다. 해당 장치는 사전 설치되어 제공됩니다. 스마트 프로그램 Connect, 오리지널 Sony 태그로 작업을 지원합니다. 원하는 경우 SmartTag Maker 유틸리티를 사용하여 빈 공백에서 직접 만들 수 있습니다. 시스템은 텍스트 링크의 라벨 번호/색상 인코딩과 함께 NDEF URI 형식을 사용합니다. 전체적으로 시스템은 "집", "사무실", "자동차", "침실", "듣기", "놀이", "활동", "시계"로 지정된 최대 8개의 태그를 제공합니다.

원래 Sony SmartTags의 변형

Smart Connect 프로그램 자체는 NFC 태그뿐만 아니라 헤드셋, 전원 공급 장치, 블루투스 장치. 표준 설정이 이미 위의 시나리오와 잘 일치한다는 것은 매우 편리합니다. 이 경우 사용자는 모든 회로를 다시 프로그래밍할 수 있습니다. 각각은 일련의 조건과 작업을 지정합니다.

조건으로 태그 식별이나 장치 연결을 사용할 수 있으며 회로의 작동 시간을 추가로 제한할 수 있습니다. 일련의 작업에는 애플리케이션 실행, 브라우저에서 링크 열기, 음악 실행, 볼륨 및 모드 조정, Bluetooth 오디오 장치 연결 등이 포함되어 매우 광범위합니다. SMS 보내기, 통화, 무선 인터페이스 제어, 밝기 및 기타 작업 조정. 또한 태그의 반복적인 인식, 새로운 이벤트/태그 또는 지정된 시간 간격의 만료에 의해 수행되는 이 모드를 종료하도록 할당할 수도 있습니다.

그러나 실제로 Sony 브랜드 태그를 사용할 필요는 없습니다. 정보 덮어쓰기를 허용하지 않는 기성 태그를 사용할 수도 있습니다. 예를 들어 교통 카드를 사용할 수 있습니다. 사실 각 항목에는 특수 프로그램을 사용하여 특정 작업과 연결될 수 있는 고유한 식별자가 있습니다. 가능한 반응에는 프로필 변경, 인터페이스 활성화/비활성화 등과 같은 작업이 포함될 수 있습니다.

Play 스토어에는 이 시나리오에 대한 여러 유틸리티가 있습니다. 그 중 몇 가지를 언급하겠습니다.

한 번에 여러 유사한 프로그램을 설치해서는 안된다는 점을 상기시켜 드리겠습니다. 이 모드는 전화기 화면에서 태그가 감지되면 처리할 프로그램을 선택하라는 대화 상자가 나타나기 때문에 편의성을 추가하지 않습니다.

태그 작업을 위한 프로그램을 검색하는 동안 기록 가능한 태그가 있는 경우 흥미로울 수 있는 또 다른 클래스의 유틸리티도 발견했습니다. 이러한 프로그램은 해당 프로그램에서만 사용할 수 있는 고유한 원본 녹음 형식을 사용합니다. 이 경우 가능한 조치 세트는 위에서 설명한 조치와 거의 다르지 않습니다.

현재로서는 장치가 잠금 해제된 경우에만 태그를 읽을 수 있다는 점을 상기시켜 드리겠습니다. 따라서 "집에 와서 휴대전화를 침대 옆 탁자 위에 올려놓고 자동으로 프로필을 전환하고 통화와 블루투스를 끄고 알람을 설정하는" 시나리오에는 사용자의 몇 가지 작업이 필요합니다. 이 동작은 여전히 ​​프로그램의 기능을 약간 제한합니다.

장치 간 정보 교환

Android Beam을 제외하고 위에 설명된 시나리오에서는 태그가 있는 단일 전화기 또는 특수 단말기의 작동을 가정합니다. 장치를 서로 직접 연결하는 경우 여기서 가장 중요한 문제는 호환성입니다. 물론, 한 제조업체의 제품, 특히 대규모 제조업체의 경우 해당 제조업체는 펌웨어에 적절한 프로그램을 간단히 설치할 수 있습니다. 그러나 장치가 다른 제조업체에서 생산된 경우 모든 사람이 동일한 유틸리티를 사용해야 합니다. 그리고 귀하의 파트너가 귀하와 동일한 프로그램을 설치한다는 것은 전혀 사실이 아닙니다.

NFC 자체 속도가 매우 느린 점을 고려하면 파일을 빠르게 전송하기 위해 일반적으로 블루투스나 Wi-Fi를 사용하며, NFC는 연결 매개변수를 협상하고 통신을 설정하는 단계에서만 작동합니다. 이 시나리오를 테스트하기 위해 우리는 장치에서 NFC를 지원한다고 주장하는 여러 파일 전송 프로그램을 시도했습니다.

보내다! 파일 전송(NFC) 무료 버전사진, 음악, 비디오를 공유할 수 있습니다. NFC 또는 QR 코드를 사용하여 통신을 설정할 수 있습니다. 전송은 Bluetooth 또는 Wi-Fi를 통해 수행됩니다(두 장치 모두 Wi-Fi Direct를 지원하지만 우리가 사용한 Sony 휴대폰에는 지원되지 않는 경우). 그 결과, 65KB/s의 속도를 볼 수 있었는데, 이는 물론 사진으로도 보기에는 너무 느린 속도입니다.

Blue NFC는 이름에서 알 수 있듯이 전원 켜기, 검색, 페어링 단계를 터치 및 NFC 공유로 대체하여 Bluetooth를 통한 파일 공유도 단순화합니다. 위에서 언급한 프로그램 수준에서는 작동 속도가 그리 높지 않습니다.

File Expert HD도 Bluetooth를 사용하지만 속도는 이미 100~200KB/s입니다. 사실, 공평하게 말하면 이 프로그램에는 다른 많은 파일 공유 모드가 있다는 점은 주목할 가치가 있습니다.

결론

2013년 봄 현재 NFC 기술은 이미 최신 고급 및 중급 스마트폰에서 자신있게 자리를 차지하고 있다고 말할 수 있습니다. 이에 대한 관심은 Play 스토어의 프로그램 수로 간접적으로 평가할 수 있습니다. 이미 수백 개의 무료 프로젝트가 있습니다. Android 플랫폼의 시장 지배력(특히 모델 수)을 고려하면 오늘날 NFC 장치에 가장 인기 있는 플랫폼입니다. iOS는 NFC에 대한 표준 도구를 제공하지 않지만 윈도우 폰 8에는 타사 애플리케이션에 대한 NFC 기능이 상당히 제한되어 있습니다.

NFC 기술 자체에는 고유한 위치를 차지할 수 있는 여러 기능이 있습니다.

• 비접촉식 데이터 전송;
• 단거리에서만 일하십시오.
• 다른 장치 또는 수동 태그와 정보를 교환하는 기능;
• 저가 솔루션;
• 저전력 소비;
• 느린 속도데이터 전송.

현재 스마트폰과 태블릿의 경우 NFC를 사용하는 데 가장 관련성이 높은 세 가지 옵션이 있습니다. 기기 간 데이터 교환(연락처, 애플리케이션, 링크, 사진 및 기타 파일), 특수 정보가 포함된 태그 읽기, 기기 모드/설정/프로필 변경, 빠른 페어링 주변 장치(예: 헤드셋)와 함께. 첫 번째 경우에는 표준으로 작업해 볼 수 있습니다. 안드로이드 프로그램대체 옵션을 빔으로 설치하거나 설치하십시오. Wi-Fi를 통해 빠른 전송 속도가 필요하지만 각 장치에 동일한 프로그램이 필요한 경우 유용할 수 있습니다.

패시브 태그는 포스터부터 잡지, 제품 태그까지 거의 모든 곳에서 사용할 수 있습니다. 여기에는 제품에 대한 정보, 웹사이트 링크, Wi-Fi 설정, 연락처 정보, 지리 좌표 또는 기타 소량의 데이터. 이 정보 교환 방법의 확산은 사용자가 보유한 호환 장치 수에 따라 직접적으로 달라집니다. 이 시나리오는 오늘날 구현 측면에서 여전히 더 간단하고 더 인기가 있는 일반적인 QR 코드와 비교할 수 있습니다.

변화를 위해 환경 설정기록 기능이 없는 태그라도 일부 프로그램에서는 사용할 수 있으므로 많은 사용자가 이 시나리오를 시도해 볼 수 있습니다. 그러나 이 경우 옵션 세트는 다음과 같이 작성됩니다. 특정 장치, 다른 장치로 전송하는 것은 어려울 수 있습니다. 이 목적을 위한 대부분의 유틸리티에는 여전히 자체적으로 기록된 태그가 필요합니다. 이를 통해 필요한 모든 정보를 인코딩된 형식으로 태그(또는 클라우드)에 직접 저장할 수 있으므로 이러한 설정을 다른 장치에서 사용하는 것으로 충분합니다. 같은 프로그램이 있어요.

이 기사에서는 결제 시스템, 전자 지갑 및 소액 결제, 티켓 및 쿠폰, 교통 카드 및 패스와 같은 NFC 사용 사례를 고려하지 않았습니다. 이러한 주제, 특히 첫 번째 주제는 별도로 고려할 가치가 있습니다. 독자의 관심이 있고 그러한 솔루션이 확산되면 다시 답변하도록 노력하겠습니다.

NFS(네트워크 파일 시스템)- Linux/UNIX OS 제품군과 다양한 스토리지 시스템에서 널리 사용되는 NFS 서버의 파일 및 파일 시스템에 액세스하기 위한 네트워크 액세스 프로토콜입니다. 또한 Microsoft는 경쟁업체보다 뒤처지기를 원하지 않기 때문에 Windows Server 2003 R2에 기본 NFS 서버 기능을 다시 도입했습니다. Microsoft 서버 플랫폼의 후속 버전에서는 내장된 NFS Windows 서버의 기능이 확장되었고 새로운 기능과 관리 도구가 나타났습니다. Windows Server 2012의 NFS 서버는 이 기술 개발의 또 다른 이정표입니다.

Microsoft 개발자는 이 제품에서 어떤 새로운 기능을 제공합니까? Windows Server 2012의 새로운 NFS 서버 기능:

1. NFS v4.1 표준 지원. 최신 버전의 NFS 4.1에 대한 지원은 Windows Server 2012의 주요 혁신 중 하나입니다. NFS v3과 비교하여 이 프로토콜은 RFC 5661의 모든 측면을 완벽하게 구현하여 향상된 보안, 성능 및 호환성을 제공합니다.
2. 즉시 사용 가능한 성능.새로운 RPC-XDR 전송 인프라를 사용하면 시스템 매개변수를 미세 조정할 필요 없이 즉시 최적의 NFS 서버 성능을 달성할 수 있습니다. 자동으로 캐시를 조정하고, 작업자 프로세스를 풀로 나누고, 로드에 따라 풀을 동적으로 관리함으로써 최적의 성능을 얻을 수 있습니다.
3. 단순화된 배포 및 관리. 이 사실은 다음으로 인해 달성되었습니다.
   • — NFS 서버 설정 및 공유 폴더 관리를 위한 40개 이상의 PowerShell cmdlet
   • - SMB 및 NFS 공유는 물론 파일 차단 설정을 동시에 관리할 수 있는 간단한 그래픽 관리 인터페이스입니다.
   • — 손쉬운 방화벽 설정을 위해 RPC 포트(포트 2049) 수정
   • - 새로운 WMI v2 공급자
   • — 플랫 매핑 파일로 인해 식별이 단순화되었습니다.
4. NFSv3의 개선 사항. NSM(네트워크 상태 모니터)을 통해 클라이언트에 오류 알림을 신속하게 전송함으로써 레거시 NFS 클라이언트는 장애 조치를 더 빠르고 효율적으로 처리하므로 가동 중지 시간이 줄어듭니다.

요약하면, Windows Server 2012의 NFS 서버는 배포 용이성, 확장성, 안정성, 가용성, 신뢰성, 보안 및 호환성 측면에서 크게 향상되었습니다. 공유 폴더는 SMB 및 NFS 프로토콜을 통해 동시에 액세스할 수 있습니다. 즉, Windows Server 2012를 이기종 네트워크에서 스토리지로 사용할 수 있습니다.

Windows Server 2012의 NFS 서버는 GUI 및 Powershell을 사용하여 설치할 수 있습니다. GUI를 사용하여 NFS 서버를 설치하려면 파일 서버 역할(파일 및 스토리지 서비스)을 열고 내부에서 구성 요소를 확인하세요. NFS용 서버.

NFS 구성요소 설치를 완료한 후 서버를 재부팅해야 합니다.

Powershell을 사용하여 동일한 역할을 설치하는 것도 쉽습니다. 다음 명령을 실행하기만 하면 됩니다.

추가 Windows 기능 "FS-NFS-서비스"

Windows Server 2012에서 NFS 공유 설정

다음으로 우리가 설치한 역할을 사용하여 NFS 공유(공유 폴더)를 생성하는 방법을 보여드리겠습니다. 윈도우 서버. 그래픽 인터페이스나 Powershell을 사용하여 여러 가지 방법으로 NFS 공유를 다시 생성할 수 있습니다.

서버 관리자 콘솔을 사용하여 NFS 공유 만들기

콘솔을 엽니다 서버 매니저, 섹션으로 이동 주식관리(역할 내부에 위치 파일 및 스토리지 서비스).
상황에 맞는 메뉴에서 새 공유 디렉터리 만들기 마법사를 실행하세요. 새 공유…

풍선 종류 선택 NFS공유하다 -빠른

그런 다음 NFS 클라이언트에 대한 인증 유형을 설정해야 합니다. Kerberos 인증과 익명을 모두 사용할 수 있습니다.

생성되는 NFS 리소스의 소비자가 NFS 연결을 인증하는 기능이 없는 ESXi 가상화 서버라고 가정해 보겠습니다(ESXi는 NFSv4를 지원하지 않음). 따라서 인증 유형은 다음과 같습니다. 서버 인증 없음, 옵션도 참고하세요 매핑되지 않은 사용자 액세스 활성화그리고 UID/GID로 매핑되지 않은 사용자 액세스 허용.

생성된 NFS 공유를 제3자의 액세스로부터 약간 보호하기 위해 클라이언트의 IP 주소로 NFS 리소스에 대한 액세스를 제한합니다.

주인: 192.168.1.100
언어 인코딩: 빅5
공유 권한: 읽기/쓰기
루트 액세스 허용: 예

다음으로, NTFS 수준에서 연결 사용자가 매핑된 사용자에게 읽기/쓰기 액세스 권한이 있는지 확인해야 합니다(익명 액세스를 사용하기로 결정한 경우 다음 단계에서 모든 사용자에게 전체 읽기/쓰기 권한을 부여해야 합니다). NTFS 수준).

Powershell을 사용하여 NFS 공유를 만드는 방법

새 NFS 공유를 생성해 보겠습니다.

New-NfsShare -이름 "NFS" -Path "d:\shares\nfr" -AllowRootAccess $true -권한 읽기 쓰기 -인증 sys

IP 주소 192.168.1.100에 대한 공유에 대한 액세스를 허용하고 BIG5 인코딩(ESXi 클라이언트에 대한 NFS 공유의 내용을 볼 수 있는 기능)을 설정해 보겠습니다.

Grant-NfsSharePermission -이름 “NFS” -ClientName 192.168.1.100 -ClientType 호스트 -LanguageEncoding BIG5

생성된 NFS 공유는 예를 들어 가상화 환경에서 NFS 데이터 저장소로 사용되거나 다른 Unix 계열 클라이언트의 데이터에 액세스하는 데 사용될 수 있습니다. Windows 클라이언트에 NFS 공유를 마운트하는 방법은 문서에 설명되어 있습니다.

UNIX 시스템에서 파일 시스템은 논리적으로 단일 지점에 연결된 물리적 파일 시스템의 모음이라는 것을 누구나 알고 있습니다. 제 생각에는 이러한 조직의 주요 장점 중 하나는 기존 파일 시스템의 구조를 동적으로 수정하는 기능입니다. 또한 개발자들의 노력 덕분에 오늘날 우리는 거의 모든 유형의 파일 시스템을 편리한 방법으로 연결할 수 있는 기회를 갖게 되었습니다. "방법"이란 무엇보다도 OS 커널이 네트워크 연결을 통해 파일 시스템과 작동하는 능력을 강조하고 싶습니다.

한 무리의 네트워크 프로토콜 FTP, SMB, Telnet 또는 SSH 등 원격 파일로 작업할 수 있는 기능을 제공합니다. 연결된 파일 시스템의 유형에 궁극적으로 의존하지 않는 커널의 능력 덕분에 우리는 마운트 프로그램을 사용하여 원하는 대로 무엇이든 연결할 수 있습니다.

오늘은 NFS(Network File System)에 대해 이야기하겠습니다. 이 기술을 사용하면 원격 컴퓨터의 개별 FS 포인트를 파일 시스템에 연결할 수 있습니다 로컬 컴퓨터. NFS 프로토콜 자체를 사용하면 매우 빠르고 안전하며 안정적으로 파일 작업을 수행할 수 있습니다. 또 무엇이 필요합니까? :-)

이것이 작동하려면 무엇이 필요합니까?

NFS 버전과 다양한 커널 지원에 대해 오랫동안 호언장담하지 않기 위해 우리는 즉시 귀하의 커널 버전이 2.2.18 이상이라고 가정하겠습니다. 공식 문서에서 개발자는 이 커널 및 이후 버전에서 NFS 버전 3 기능을 완벽하게 지원할 것을 약속합니다.

설치

내 Ubuntu 7.10(Gutsy Gibbon)에서 NFS 서버를 실행하려면 nfs-common 및 nfs-kernel-server 패키지를 설치해야 했습니다. NFS 클라이언트만 필요한 경우 nfs-kernel-server를 설치할 필요가 없습니다.

서버 튜닝

모든 패키지가 성공적으로 설치된 후 NFS 데몬이 실행 중인지 확인해야 합니다.

/etc/init.d/nfs-kernel-server 상태

데몬이 실행되고 있지 않으면 다음 명령으로 시작해야 합니다.

/etc/init.d/nfs-kernel-server 시작

모든 작업이 성공적으로 시작된 후 파일 시스템 내보내기를 시작할 수 있습니다. 프로세스 자체는 매우 간단하며 최소한의 시간이 걸립니다.

기본 NFS 서버 구성 파일은 /etc/exports에 있으며 형식은 다음과 같습니다.

디렉터리 머신1(옵션11,옵션12) 머신2(옵션21,옵션22)

예배 규칙서— 액세스 권한을 부여해야 하는 FS 서버 디렉토리의 절대 경로

머신X— 액세스가 허용되는 클라이언트 컴퓨터의 DNS 이름 또는 IP 주소

옵션XX— 가장 일반적으로 사용되는 FS 내보내기 매개변수:

• 로- 파일 액세스는 읽기 전용입니다.
• rw— 읽기/쓰기 액세스 권한이 부여됩니다.
• no_root_squash— 기본적으로 NFS 리소스에 루트로 연결하면 보안을 위해 서버 측에서는 none 사용자로 파일에 액세스합니다. 그러나 이 옵션을 활성화하면 서버 측 파일에 루트로 액세스됩니다. 이 옵션에 주의하세요.
• no_subtree_check— 기본적으로 서버의 전체 파티션이 아닌 파일 시스템의 일부만 내보내는 경우 데몬은 요청한 파일이 물리적으로 동일한 파티션에 있는지 여부를 확인합니다. 전체 파티션을 내보내거나 내보낸 파일 시스템의 마운트 지점이 다른 물리 볼륨의 파일에 영향을 주지 않는 경우 이 옵션을 활성화할 수 있습니다. 이를 통해 서버 속도가 향상됩니다.
• 동조— 갑작스러운 연결 손실이나 서버 정전이 발생할 가능성이 있는 경우 이 옵션을 활성화합니다. 이 옵션을 활성화하지 않으면 NFS 서버가 갑자기 중지될 경우 데이터 손실 위험이 매우 높습니다.

따라서 ashep-laptop 컴퓨터의 /var/backups 디렉토리에 ashep-desktop 컴퓨터에 대한 액세스 권한을 부여해야 한다고 가정해 보겠습니다. 복사하려면 디렉터리 액세스가 필요합니다. 백업 복사본 ashep-desktop의 파일. 내 파일은 다음과 같이 나타났습니다.

/var/backups ashep-desktop(rw,no_subtree_check,sync)

/etc/exports에 행을 추가한 후 변경 사항을 적용하려면 NFS 서버를 다시 시작해야 합니다.

/etc/init.d/nfs-kernel-server 재시작

그게 다야. 클라이언트 컴퓨터에서 내보낸 FS 연결을 시작할 수 있습니다.

클라이언트 설정

~에 고객 입장에서원격 파일 시스템은 다른 모든 파일 시스템과 동일한 방식으로 - mount 명령을 사용하여 마운트됩니다. 또한 OS가 부팅될 때 FS를 자동으로 연결해야 하는 경우 /etc/fstab을 사용하는 것을 누구도 금지하지 않습니다. 따라서 마운트 옵션은 다음과 같습니다.

Mount -t nfs ashep-laptop:/var/backups/ /mnt/ashep-laptop/backups/

모든 것이 순조롭게 진행되어 부팅 시 자동으로 원격 FS에 연결해야 하는 경우 /etc/fstab에 다음 줄을 추가하면 됩니다.

Ashep-laptop:/var/backups /mnt/ashep-laptop/backups nfs 자동 0 0

또 뭐야?

따라서 우리는 NFS 기능에 대한 실용적이고 작은 개요를 갖게 되었습니다. 물론 이는 NFS가 수행할 수 있는 작업의 일부일 뿐입니다. 집이나 소규모 사무실에서 사용하기에 충분합니다. 이것이 충분하지 않다면 먼저 읽어 보는 것이 좋습니다