Прежде чем я углублюсь в то, как синхронизировать UID / GID на разных машинах Linux, я хотел бы знать, в чем собственно преимущество?
Я знаю, что это позволяет относительно легко синхронизировать файлы (поскольку право собственности сохраняется «естественным образом»). Однако это также может быть достигнуто другим способом в зависимости от услуги передачи.
Есть ли еще что-нибудь, что выиграет от согласованных UID / GID?
По причинам, указанным ниже, это намного проще решить эту проблему на раннем этапе, чтобы избежать накопления технический долг. Даже если вы уже оказались в такой ситуации, вероятно, лучше разобраться с ней в ближайшем будущем, чем позволить продолжать строительство.
Этот вопрос, по-видимому, сосредоточен на узкой сфере передачи файлов между машинами с локальными файловыми системами, что позволяет использовать конкретные состояния владения машиной.
Соображения по поводу сетевой файловой системы - это самый важный аргумент при попытке сохранить ваши сопоставления UID / GID в синхронизации, потому что вы обычно можете выбросить это «достигнутое в противном случае», о котором вы упомянули, из окна в тот момент, когда они входят в изображение. Конечно, у вас может не быть сетевых файловых систем, совместно используемых этими хостами. сейчас... а что насчет будущего? Можете ли вы честно сказать, что никогда не будет варианта использования сетевой файловой системы между вашими текущими хостами или хостами, которые будут созданы в будущем? Было бы не очень дальновидно предполагать иное.
Предположим, что /home это сетевая файловая система, совместно используемая host1 и host2 в следующих примерах.
/home/user1 принадлежит разному пользователю в каждой системе. Это препятствует тому, чтобы пользователь мог постоянно получать доступ или изменять свой домашний каталог в разных системах.host2 нарушает разрешения на host1. Иногда может потребоваться несколько таких билетов, прежде чем кто-то отступит и поймет, что идет перетягивание каната. Единственное решение - исправить несовпадающие сопоставления идентификаторов. Что приводит к...user1 имеет идентификатор user2, но user2 имеет идентификатор user17... и это всего лишь первая система в кластере) Чем дольше вы ждете, чтобы исправить проблему, тем сложнее могут стать эти цепочки, часто требующие простоя приложений на нескольких серверах для правильной синхронизации.user2 на host2 имеет тот же UID, что и user1 на host1, позволяя им писать на /home/user1 на host2 без ведома user1. Затем эти изменения оцениваются на host1 с разрешения user1. Что возможно могло пойти не так? (если user1 пользователь приложения, кто-то из разработчиков воля обнаружить, что он доступен для записи и воля вносить изменения. это факт проверенный временем.)Есть и другие сценарии, и это лишь примеры наиболее распространенных.
Любые сценарии или файлы конфигурации, написанные с использованием числовых идентификаторов, по своей сути становятся непереносимыми в вашей среде. Как правило, это не проблема, потому что большинство людей не кодируют их жестко, если только они этого не требуют ... но иногда инструмент, с которым вы работаете, не дает вам выбора в этом вопросе. В этих сценариях вы вынуждены поддерживать п разные версии скрипта или файла конфигурации.
Пример: pam_succeed_if позволяет использовать поля user, uid, и gid... "групповой" вариант явно отсутствует. Если бы вас поставили в положение, когда ожидается, что несколько систем будут реализовывать некоторую форму ограничения доступа на основе групп, у вас будет п разные варианты конфигов PAM. (или хотя бы один GID, с которым вы должны избегать коллизий)
Ответ natxo хорошо покрывает это.
как только вы достигнете определенного размера (и это всегда произойдет раньше, чем вы думаете), вы поймете, что изменение ваших паролей или отключение учетных записей для кого-то на всех хостах - это PITA. Вот почему люди используют системы с базами данных LDAP (или NIS, но не делают этого, в настоящее время небезопасно), такие как openldap или отличная в настоящее время freeipa.
Вы храните всю информацию об учетных записях / группах в центральной базе данных, все хосты разделяют эту информацию. Отсюда вы можете делать гораздо больше: использовать информацию о пользователях для прав доступа к файлам, но также создавать виртуальных пользователей для всех приложений с привязками ldap вместо того, чтобы создавать там своих пользователей (многие веб-приложения могут использовать ldap для своей пользовательской базы данных), поддерживать центральную базу данных правил sudo, распространять вашу среду autofs, сохранять свои зоны DNS, ...