технічна заборгованість
З причин, поданих нижче, набагато простіше вирішити цю проблему на початку, щоб уникнути накопичення технічної заборгованості . Навіть якщо ви опинилися вже в цій ситуації, напевно, краще впоратися з цим найближчим часом, ніж дозволити йому продовжувати будувати.
мережеві файлові системи
Це питання, схоже, зосереджено на вузькій області передачі файлів між машинами з локальними файловими системами, що дозволяє визначати стан власності, визначений для машини.
Міркування щодо мережевої файлової системи - це найбільший випадок, коли намагаються синхронізувати ваші відображення UID / GID, тому що зазвичай ви можете викинути те "досягнуте інакше", яке ви згадали у вікно в момент, коли вони входять у зображення. Звичайно, ви не могли б мати мережеві файлові системи розділені між цими хостами прямо зараз ... але що про майбутнє? Чи можете ви чесно сказати, що ніколи не буде випадку використання мережевої файлової системи між вашими поточними хостами або хостами, які будуть створені в майбутньому? Не думати вперед, щоб припустити інше.
Припустимо, що /homeце мережева файлова система, спільна між host1і host2в наступних прикладах.
- Дозволи на розбіжність :
/home/user1належить різному користувачеві в кожній системі. Це не дозволяє користувачеві мати можливість послідовно отримувати доступ або змінювати свій домашній каталог у всіх системах.
- Човен війни : Користувач дуже часто подає квиток, вимагаючи, щоб дозволи домашнього каталогу були зафіксовані на певній системі. Виправлення цієї проблеми на
host2розривах дозволів на host1. Іноді може бути відпрацьовано декілька цих квитків, перш ніж хтось відступить назад і зрозуміє, що в боротьбі буксир. Єдине рішення - виправити невідповідні відображення ідентифікаторів. Що призводить до ...
- Пекельне збалансування UID / GID : Складність виправлення ідентифікаторів пізніше зростає експоненціально за рахунок кількості переоформлень, задіяних для виправлення одного користувача на кількох машинах. (
user1має ідентифікатор user2, але user2має ідентифікатор user17... і це лише перша система в кластері) Чим довше ви чекаєте, щоб вирішити проблему, тим складнішими можуть стати ці ланцюги, що часто вимагають простоїв програм на декількох серверах щоб правильно синхронізувати справи.
- Проблеми із безпекою :
user2у він host2має той самий UID, що й user1у host1, що дозволяє їм писати /home/user1на, host2не знаючи user1. Потім ці зміни оцінюються за host1допомогою дозволів user1. Що може піти не так? (Якщо user1це користувач додатка, хто - то в розробника буде відкрити його для запису і буде вносити зміни. Цей час доведений факт.)
Є й інші сценарії, і це лише приклади найпоширеніших.
імена не завжди є варіантом
Будь-які скрипти або конфігураційні файли, написані проти числових ідентифікаторів, стають невід'ємними для вашого середовища. Як правило, це не проблема, тому що більшість людей не жорстко кодує їх, якщо їх абсолютно не потрібно ... але іноді інструмент, з яким ви працюєте, не дає вам вибору в цьому питанні. У цих сценаріях ви змушені підтримувати n різних версій сценарію чи файлу конфігурації.
Приклад: pam_succeed_ifдозволяє використовувати поля user, uidі gid... варіант «група» явно відсутня. Якщо б ви були поставлені в становище, коли очікувались, що кілька систем реалізують певну форму групового обмеження доступу, у вас буде n різних варіантів конфігурацій PAM. (або принаймні один GID, який потрібно уникати зіткнень)
централізоване управління
Відповідь natxo це досить добре висвітлює.