หนี้ทางเทคนิค
ด้วยเหตุผลดังต่อไปนี้มันเป็นเรื่องง่ายมากที่จะแก้ไขปัญหานี้ในช่วงต้นเพื่อหลีกเลี่ยงการสะสมของหนี้ทางเทคนิค แม้ว่าคุณจะพบว่าตัวเองมีอยู่แล้วในสถานการณ์นี้มันอาจจะดีกว่าที่จะจัดการกับมันในอนาคตอันใกล้กว่าปล่อยให้มันสร้างต่อไป
ระบบไฟล์เครือข่าย
คำถามนี้ดูเหมือนจะเน้นไปที่ขอบเขตที่แคบของการถ่ายโอนไฟล์ระหว่างเครื่องที่มีระบบไฟล์ในตัวเครื่องซึ่งช่วยให้ระบุสถานะความเป็นเจ้าของเครื่องโดยเฉพาะ
ข้อพิจารณาระบบไฟล์ในเครือข่ายนั้นเป็นกรณีที่ใหญ่ที่สุดในการพยายามทำการแมป UID / GID ของคุณให้ตรงกันได้ง่ายเพราะคุณมักจะโยน "ประสบความสำเร็จอย่างอื่น" ที่คุณพูดถึงหน้าต่างเมื่อพวกเขาเข้ามาในภาพ แน่นอนว่าคุณอาจไม่ได้แชร์ระบบไฟล์เครือข่ายระหว่างโฮสต์เหล่านี้ในตอนนี้ ... แต่อนาคตจะเป็นอย่างไร คุณสามารถพูดได้อย่างตรงไปตรงมาหรือไม่ว่าจะไม่มีกรณีการใช้งานสำหรับระบบไฟล์เครือข่ายที่ถูกนำเสนอระหว่างโฮสต์ปัจจุบันของคุณหรือโฮสต์ที่สร้างขึ้นในอนาคต มันไม่ได้คิดไปข้างหน้ามากที่จะคิดอย่างอื่น
สมมติว่า/homeเป็นระบบไฟล์เครือข่ายที่แชร์ระหว่างhost1และhost2ในตัวอย่างต่อไปนี้
- สิทธิ์ในการไม่อนุญาต :
/home/user1เป็นของผู้ใช้รายอื่นในแต่ละระบบ สิ่งนี้ป้องกันไม่ให้ผู้ใช้สามารถเข้าถึงหรือแก้ไขโฮมไดเร็กทอรีของพวกเขาข้ามระบบได้อย่างสม่ำเสมอ
- chown wars : เป็นเรื่องธรรมดามากที่ผู้ใช้จะต้องส่งตั๋วเพื่อขอสิทธิ์ไดเรกทอรีบ้านของพวกเขาในระบบที่เฉพาะเจาะจง การแก้ไขปัญหานี้ในการแบ่งสิทธิ์บน
host2 host1บางครั้งอาจต้องใช้ตั๋วหลายใบก่อนที่จะมีใครบางคนถอยกลับและตระหนักว่าสงครามชักเย่อ ทางออกเดียวคือการแก้ไขการแมป ID ที่ไม่เห็นด้วย ซึ่งนำไปสู่...
- UID / GID การปรับสมดุลนรก : ความซับซ้อนของการแก้ไขรหัสในภายหลังจะเพิ่มขึ้นแบบทวีคูณโดยจำนวนการปรับใช้ที่เกี่ยวข้องเพื่อแก้ไขผู้ใช้คนเดียวในหลาย ๆ เครื่อง (
user1มี ID ของuser2แต่user2มี ID ของuser17... และนั่นเป็นเพียงระบบแรกในคลัสเตอร์) ยิ่งคุณรอการแก้ไขปัญหานานเท่าไรโซ่ยิ่งซับซ้อนเหล่านี้ก็ยิ่งมากขึ้นซึ่งมักจะต้องหยุดทำงานของแอพพลิเคชันบนเซิร์ฟเวอร์หลายเครื่อง เพื่อให้ได้สิ่งที่ถูกต้องในซิงค์
- ปัญหาด้านความปลอดภัย :
user2บนhost2มี UID เดียวกับuser1ในการhost1ช่วยให้พวกเขาที่จะเขียนถึง/home/user1ในที่ไม่มีความรู้ของhost2 user1การเปลี่ยนแปลงเหล่านี้ได้รับการประเมินจากนั้นก็มีสิทธิ์ของhost1 user1สิ่งที่อาจจะผิดไป? (หากuser1เป็นผู้ใช้แอปบางคนใน dev จะค้นพบว่ามันเขียนได้และจะทำการเปลี่ยนแปลงนี่คือข้อเท็จจริงที่พิสูจน์แล้วว่าเป็นเวลา)
มีสถานการณ์อื่น ๆ และสิ่งเหล่านี้เป็นเพียงตัวอย่างของสถานการณ์ที่พบบ่อยที่สุด
ชื่อไม่ได้เป็นตัวเลือกเสมอไป
สคริปต์หรือไฟล์กำหนดค่าใด ๆ ที่เขียนด้วย ID ตัวเลขจะไม่สามารถโอนย้ายได้ภายในสภาพแวดล้อมของคุณ โดยทั่วไปจะไม่เกิดปัญหาเพราะคนส่วนใหญ่ไม่ได้ทำการ hardcode สิ่งเหล่านี้เว้นแต่ว่าพวกเขาจะต้อง ... แต่บางครั้งเครื่องมือที่คุณใช้งานไม่ได้ให้ทางเลือกแก่คุณ ในสถานการณ์เหล่านี้คุณกำลังถูกบังคับให้รักษาnรุ่นต่างๆของสคริปต์หรือการกำหนดค่าไฟล์
ตัวอย่าง: pam_succeed_ifช่วยให้คุณสามารถใช้เขตข้อมูลของuser, uidและgid... เป็น "กลุ่ม" ตัวเลือกจะผงาด หากคุณถูกวางในตำแหน่งที่หลายระบบที่คาดว่าจะใช้รูปแบบของการ จำกัด การเข้าถึงกลุ่มตามบางคุณต้องการมีnรูปแบบที่แตกต่างกันของการกำหนดค่าของ PAM (หรืออย่างน้อยหนึ่ง GID ที่คุณต้องหลีกเลี่ยงการชน)
การจัดการแบบรวมศูนย์
คำตอบของ natxo นี้ครอบคลุมค่อนข้างดี