deuda técnica
Por las siguientes razones, es mucho más simple abordar este problema desde el principio para evitar la acumulación de deuda técnica . Incluso si ya se encuentra en esta situación, probablemente sea mejor tratarlo en un futuro cercano que dejar que continúe creciendo.
sistemas de archivos en red
Esta pregunta parece centrarse en el alcance limitado de la transferencia de archivos entre máquinas con sistemas de archivos locales, lo que permite estados de propiedad específicos de la máquina.
Las consideraciones del sistema de archivos en red son fácilmente el caso más importante para tratar de mantener sincronizadas sus asignaciones de UID / GID, porque generalmente puede arrojar lo "logrado de otra manera" que mencionó en la ventana en el momento en que ingresan a la imagen. Claro, es posible que no tenga sistemas de archivos en red compartidos entre estos hosts en este momento ... pero ¿qué pasa con el futuro? ¿Puede decir honestamente que nunca habrá un caso de uso para un sistema de archivos en red introducido entre sus hosts actuales o hosts que se creen en el futuro? No es muy avanzado pensar asumir lo contrario.
Suponga que /homees un sistema de archivos en red compartido entre host1y host2en los siguientes ejemplos.
- Permisos en desacuerdo :
/home/user1es propiedad de un usuario diferente en cada sistema. Esto evita que un usuario pueda acceder o modificar constantemente su directorio de inicio en los sistemas.
- Guerras chown : es muy común que un usuario envíe un ticket solicitando que los permisos de su directorio principal se arreglen en un sistema específico. La solución de este problema
host2rompe los permisos en host1. A veces puede tomar varios de estos boletos para trabajar antes de que alguien retroceda y se dé cuenta de que hay un tira y afloja en juego. La única solución es arreglar las asignaciones de ID en desacuerdo. Lo que lleva a...
- UID / GID reequilibrando el infierno : la complejidad de corregir IDs luego aumenta exponencialmente por el número de reasignaciones involucradas para corregir un solo usuario en múltiples máquinas. (
user1tiene la ID de user2, pero user2tiene la ID de user17... y ese es solo el primer sistema en el clúster) Cuanto más espere para solucionar el problema, más complejas pueden volverse estas cadenas, que a menudo requieren el tiempo de inactividad de las aplicaciones en múltiples servidores con el fin de sincronizar las cosas correctamente.
- Los problemas de seguridad :
user2el host2tiene la misma UID que user1el host1, lo que les permite escribir en /home/user1el host2sin el conocimiento de user1. Estos cambios luego se evalúan host1con los permisos de user1. ¿Qué podría salir mal? (si user1es un usuario de la aplicación, alguien en desarrollo descubrirá que se puede escribir y hará cambios. Esto es un hecho comprobado).
Hay otros escenarios, y estos son solo ejemplos de los más comunes.
los nombres no siempre son una opción
Cualquier script o archivo de configuración escrito con ID numéricos se vuelve inherentemente inportable dentro de su entorno. En general, no es un problema porque la mayoría de las personas no las codifica a menos que sea absolutamente necesario ... pero a veces la herramienta con la que está trabajando no le da una opción al respecto. En estos escenarios, se ve obligado a mantener n versiones diferentes del script o archivo de configuración.
Ejemplo: le pam_succeed_ifpermite usar campos de user, uidy gid... una opción de "grupo" está notablemente ausente. Si lo pusieran en una posición en la que se esperaba que varios sistemas implementaran alguna forma de restricción de acceso basada en grupos, tendría n variaciones diferentes de las configuraciones de PAM. (o al menos un único GID en el que debe evitar colisiones)
gestión centralizada
La respuesta de natxo ha cubierto esto bastante bien.