технический долг
По причинам, изложенным ниже, гораздо проще решить эту проблему на раннем этапе, чтобы избежать накопления технического долга . Даже если вы уже оказались в такой ситуации, вероятно, лучше разобраться с этим в ближайшем будущем, чем позволить ему продолжить строительство.
сетевые файловые системы
Этот вопрос, по-видимому, сосредоточен на узкой области передачи файлов между компьютерами с локальными файловыми системами, которая допускает конкретные состояния владения машиной.
Соображения, касающиеся сетевой файловой системы, - это, пожалуй, самый большой случай, когда вы пытаетесь синхронизировать ваши UID / GID-сопоставления, потому что вы обычно можете выбросить это «достигнутое иначе», которое вы упомянули в окне в тот момент, когда они входят в изображение. Конечно, вы не могли бы иметь сетевые файловые системы разделены между этими хостами прямо сейчас ... но что о будущем? Можете ли вы честно сказать, что никогда не будет прецедента использования сетевой файловой системы между вашими текущими хостами или хостами, которые будут созданы в будущем? Это не очень дальновидно, чтобы думать иначе.
Предположим, что /homeэто сетевая файловая система, используемая совместно host1и host2в следующих примерах.
- Несогласие разрешений :
/home/user1принадлежит каждому пользователю в каждой системе. Это лишает пользователя возможности иметь постоянный доступ или изменять свой домашний каталог в разных системах.
- chown wars : пользователь очень часто отправляет заявку с требованием, чтобы его права доступа к домашнему каталогу были зафиксированы в конкретной системе. Исправление этой проблемы
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 достаточно хорошо освещен.