기술 부채

아래의 이유로 인해 기술 부채 가 누적되는 것을 피하기 위해이 문제를 조기에 해결 하는 것이 훨씬 간단 합니다 . 이 상황에서 이미 자신을 발견하더라도 가까운 시일 내에 계속 구축하는 것보다 다루는 것이 좋습니다.

네트워크 파일 시스템

이 질문은 로컬 파일 시스템이있는 머신간에 파일을 전송하는 좁은 범위에 중점을 두어 머신 별 소유권 상태를 허용합니다.

네트워크 파일 시스템 고려 사항은 UID / GID 매핑을 동기화 상태로 유지하려는 가장 쉬운 경우입니다. 일반적으로 그림에 들어가는 순간 창에서 언급 한 “달리 달성”할 수 있기 때문입니다. 물론, 현재 호스트간에 네트워크 파일 시스템을 공유하지 않았을 수도 있습니다. 현재 호스트 또는 미래에 생성되는 호스트간에 네트워크 파일 시스템이 도입되지 않을 것이라고 정직하게 말할 수 있습니까? 그렇지 않다고 생각하는 것은 그리 앞선 생각이 아닙니다.

그 가정 /home에서 공유 네트워크 파일 시스템이다 host1및 host2하기 실시 예에서.

• 동의하지 않는 권한 : /home/user1각 시스템의 다른 사용자가 소유합니다. 이를 통해 사용자는 시스템 전체에서 홈 디렉토리에 지속적으로 액세스하거나 수정할 수 없습니다.
• chown wars : 사용자가 홈 디렉토리 권한을 특정 시스템에서 수정하도록 요청하는 티켓을 제출하는 것이 일반적입니다. 에이 문제를 해결하면에 host2대한 권한 이 중단됩니다 host1. 누군가가 물러서서 줄다리기가 진행되고 있음을 깨닫기 전에 이러한 티켓 중 일부가 작동해야 할 수도 있습니다. 유일한 해결책은 동의하지 않는 ID 매핑을 수정하는 것입니다. 어느 것이 …
• UID / GID 리 밸런싱 지옥 : ID 수정의 복잡성은 나중에 여러 컴퓨터에서 단일 사용자를 수정하는 데 필요한 재 매핑 횟수에 따라 기하 급수적 으로 증가 합니다. ( user1의 ID는 user2있지만 user2ID는 user17…이며 클러스터의 첫 번째 시스템 일뿐입니다.) 문제를 해결하기 위해 대기하는 시간이 길어질수록 체인이 더 복잡해져 여러 서버에서 응용 프로그램의 다운 타임이 종종 발생합니다. 동기화를 제대로하기 위해
• 보안 문제 : user2에 host2같은 UID가 user1에 host1그들을 쓸 수 있도록 /home/user1에서 host2의 지식 없이도을 user1. 이러한 변경 사항은 host1의 권한으로 평가됩니다 user1. 무엇이 잘못 될 수 있습니까? (경우 user1앱 사용자는, 개발의 사람이 됩니다 그것을 쓰기의 발견 됩니다 변경합니다.이 한 번 입증 된 사실이다.)

다른 시나리오가 있으며 가장 일반적인 시나리오의 예일뿐입니다.

이름이 항상 옵션은 아닙니다

숫자 ID로 작성된 스크립트 또는 구성 파일은 본질적으로 사용자 환경 내에서 이식 할 수 없게됩니다. 일반적으로 문제가되지 않습니다. 대부분의 사람들은 반드시 필요한 경우가 아니면 이들을 하드 코딩하지 않습니다. 그러나 때로는 작업중인 도구로 문제를 선택할 수 없습니다. 이 시나리오에서는 유지 수밖에 N 스크립트 또는 구성 파일의 다른 버전.

예 : pam_succeed_if당신의 필드를 사용할 수 있습니다 user, uid그리고 gid…는 “그룹”옵션이 눈에 띄게 결석입니다. 여러 시스템이 그룹 기반 액세스 제한의 형태를 구현할 것으로 예상 된 위치에 넣어한다면, 당신은 할 것 N 팸의 CONFIGS의 다른 유사합니다. (또는 충돌을 피해야하는 최소한 하나의 GID)

중앙 집중식 관리

natxo의 대답은 이것에 꽤 잘 적용되었습니다.

답변