10년 넘게 나는 소규모 사무실(현재 서버 1대, 사용자 7명, 데스크탑 3대, 노트북 4대)에서 전체 데비안 환경에서 일해 왔습니다. 인증은 Kerberos를 기반으로 하며 사용자 프로필은 LDAP에서 관리되며 $HOME은 pam_mount 또는 autofs의 도움으로 NFSv4를 통해 모든 클라이언트에 제공됩니다. 이 설정은 로컬 LAN에서 작업하는 데스크톱 사용자에게 이상적입니다.
2년 전 저는 랩톱 사용자를 위해 동일한 설정을 사용하기 시작했습니다. WiFi 연결로 인해 추가 속도 저하가 발생했으며, 확실히 사용자가 사무실 밖에서 노트북을 사용하려고 하면 속도가 매우 느려졌습니다. $XDG_{CACHE,DATA,CONFIG}_HOME을 최적화하고 NFS에서 Firefox에 대한 특정 최적화를 조사한 결과 상황이 조금 더 좋아졌습니다.
저는 이제 $HOMES를 노트북+데스크톱으로 옮기는 것을 고려하고 있습니다. 장치에 오류가 발생하면 사용자가 장치를 전환할 수 있다는 점은 좋지만 그런 일은 가끔씩만 발생합니다. 더 빠른 일상적인 사용자 경험을 위해 이러한 유연성을 희생하는 것은 좋은 결정처럼 보입니다. 시작 및 종료 시 로컬 $HOME을 중앙 서버에 양방향으로 동기화할 수 있다면 전혀 절충점이 없을 수 있습니다.
- "unison"은 로컬 $HOME을 중앙 복제본과 동기화하는 데 적합한 후보처럼 보이지만 서버와 클라이언트 간에 정확히 동일한 버전이 필요한 것 같습니다. 이에 대해서는 장담할 수 없습니다.
- "lsyncd"는 매우 좋은 후보인 것 같지만 $HOME 디렉토리에 해당 도구를 사용하는 사용자 스토리를 찾을 수 없는 것 같습니다...
- "GlusterFS"도 잠깐 살펴봤지만 그다지 중요한 대안은 아닌 것 같습니다. 공유할 경험이나 모범 사례가 있는 사람이 있나요? 약간의 실험은 상관 없지만 위의 명백한 단점 중 일부를 놓치고 있는 것 같습니다... 감사합니다!
답변1
나는 사용한다사물을 동기화이와 같은 설정의 경우 전체 홈 디렉토리 또는 홈 디렉토리의 하위 집합입니다. 파일을 양방향 또는 단방향으로 동기화할 수 있습니다. 사용자가 서로 다른 두 위치에서 동일한 파일을 변경하지 않는 경우 충돌하는 변경 사항이 있어도 투명하고 잘 처리됩니다. 데이터가 손실되지 않습니다.
어느 정도 기울어진 버전에서 작동합니다. 다양한 전화기와 컴퓨터에서 실행됩니다. 전화기는 자동으로 최신 버전을 추적하고 컴퓨터는 배포판에 설치된 모든 버전을 사용합니다. 전체 홈 디렉터리 동기화는 구성 파일 변경으로 인해 배포가 동일한 컴퓨터에서만 실제로 작동하지만 부분 동기화는 다른 설정에서 작동합니다.
Syncthing은 LAN에서 매우 잘 실행되지만 인터넷을 통한 동기화도 지원하며 관심 있는 신뢰 수준에 맞게 조정할 수 있도록 구성할 수 있습니다.
답변2
@marcus-müller가 지적했듯이 이 기능은 "로밍 사용자 프로필"로 널리 알려져 있으며 다음 두 가지 주요 요소를 중심으로 구축되었습니다.
- 사용자 자격 증명
- 사용자 $HOME 디렉터리
첫 번째 문제는 일반적으로 클라이언트의 LDAP+Kerberos 및 SSSD와 같은 중앙 집중식 시스템으로 해결됩니다. 두 번째 문제는 NFSv4 및 krb5/krb5i/krb5p를 사용하여 해결할 수 있지만 클라이언트가 WiFi를 사용하거나 원격 위치에 있는 경우 속도가 느려질 수 있습니다.
사용자를 위해 중앙 집중식 $HOME을 포기하고 싶지만 중앙 집중식 설정의 유연성을 완전히 포기하고 싶지 않은 경우 해결 방법은 다음과 같습니다.
- 로그인 후 rsync 스크립트를 실행합니다(없으면 로컬 $HOME 생성). 로컬 $HOME을 중앙 $HOME과 양방향으로 동기화합니다.
- 로그아웃한 후 rsync 스크립트를 실행하여 모든 로컬 변경 사항을 중앙 $HOME에 업로드합니다.
- (선택 사항) 간헐적인 동기화 수행
/etc/gdm/PostLogin/Default로그인( ) 및 로그아웃( ) 시 스크립트를 실행하도록 GDM을 설정할 수 있습니다 /etc/gdm/PostSession/Default. 간헐적인 동기화를 위해 cronjob 또는 systemd 타이머를 설정할 수 있습니다.
마음속에 떠오르는 몇 가지 참고 사항:
- $HOME 디렉토리의 크기를 제한해 보세요. 예를 들어 사용자가 공유 문서를 저장할 수 있는 별도의 디렉토리와 할당량을 사용합니다(전반적인 속도 저하 문제 없이 NFS를 통해 공유할 수 있음).
- 캐시 및 tmp 디렉토리를 생략하도록 rsync 스크립트를 최적화합니다. (또는 $XDG_CACHE_HOME 및 $XDG_DATA_HOME을 $HOME 외부로 재배치할 수도 있습니다.)
/편집: 로컬 $HOME을 원격 $HOME과 동기화하는 데 도움이 되는 쉘 스크립트를 게시했습니다.https://github.com/zenlord/vagabond.sh-댓글 환영합니다 :)
답변3
로그인 중에 중앙 서버에서 홈 디렉토리를 가져오고 로그아웃 시 다시 동기화하는 것도 PAM을 통해 수행할 수 있습니다.팸 스크립트모듈 - 적절한 rsync 명령을 호출하는 데 사용합니다.
답변4
"unison"은 로컬 $HOME을 중앙 복제본과 동기화하는 데 적합한 후보처럼 보이지만 서버와 클라이언트 간에 정확히 동일한 버전이 필요한 것 같습니다. 이에 대해서는 장담할 수 없습니다.
서버에 여러 버전을 설치할 수 있습니다. addversionno = true서버에서 실행되도록 Unison 구성 파일에 설정을 지정합니다 .unison-VERSION
서버에 여러 버전을 설치할 수 있습니다. 직접 만드는 번거로움을 원하지 않는다면공식 바이너리데비안 패키지는 Glibc에만 의존합니다. 공식 패키지는 현재 Ubuntu 18.04에 구축되어 있지만 실제로는 이전 시스템에서도 실행됩니다.
자체 버전을 설치하는 경우 보안 문제를 모니터링해야 합니다. 나는 데비안에서 보안 조언을 본 기억이 없으며 (비교적 새로운) 내용도 없습니다.Github 이슈 트래커하지만 그렇다고 해서 그런 일이 일어나지 않을 것이라는 의미는 아닙니다.
Unison 버전이 일치해야 할 뿐만 아니라 빌드된 OCaml 버전도 일치해야 할 수도 있습니다. 반면에 운영 체제와 CPU 아키텍처는 일치할 필요가 없습니다.
따라서 기술적인 관점에서 볼 때 Unison은 괜찮습니다. 그러나 이것이 사용자 관점에서 적절한지는 잘 모르겠습니다. 갈등이 발생하면 사용자는 화해하는 방법을 말해야 합니다. 이는 모든 양방향 동기화 시스템에 내재되어 있으므로 여기서 문제는 Unison을 사용할지 여부가 아니라 양방향 동기화를 사용할지 여부입니다. 사용자가 여러 장치에서 교대로 작업할 수 있도록 하는 것이 목표라면 실제로 양방향 동기화가 필요합니다. 그러나 단순히 장치가 손상된 경우 빠른 장애 조치를 허용하는 것이 목표라면 백업 및 복구가 더 나은 접근 방식입니다.