27 votos

¿' Es la ventaja de la sincronización de UID/GID a través de máquinas Linux?

¿Antes que sumergirse en las profundidades de cómo sincronizar de UID / GID a través de mis diferentes máquinas Linux, me gustaría saber cuál es en realidad el beneficio?

Sé que esto mantiene sincronización de archivos relativamente fácil (como "naturalmente" se mantiene la propiedad). Sin embargo esto también se logra lo contrario según el servicio de transmisión.

¿Hay algo más que se beneficiarían de UIDs/GIDs consistentes?

33voto

Andrew B Puntos 9763

la deuda técnica

Por las razones que a continuación, es mucho más sencillo de abordar este problema desde el principio para evitar la acumulación de deuda técnica. Incluso si usted se encuentra ya en esta situación, es probablemente mejor para lidiar con ella en el futuro cercano que vamos a continuar con la construcción.

los sistemas de ficheros en red

Esta pregunta parece estar centrado en el estrecho ámbito de la transferencia de archivos entre equipos con los sistemas de ficheros locales, lo que permite que la máquina específicos de propiedad de los estados.

Red del sistema de ficheros consideraciones son fácilmente el caso más grande por tratar de mantener su UID/GID asignaciones en la sincronización, porque se puede tirar por lo general que "lograrse de otra manera" usted ha mencionado por la ventana al momento de entrar en la imagen. Claro, usted podría no tener en red de los sistemas de ficheros compartidos entre estos hosts ahora...pero ¿y el futuro? Puede decir honestamente que nunca habrá un caso de uso para un sistema de ficheros en red se introdujo entre sus anfitriones actuales, o los hosts a los que se crean en el futuro? No es muy progresistas para asumir lo contrario.

Suponga que /home es un sistema de ficheros en red compartida entre host1 y host2 en los siguientes ejemplos.

  • El desacuerdo de los permisos: /home/user1 es propiedad de un usuario diferente en cada sistema. Esto evita que un usuario pueda consistentemente acceder o modificar su directorio de inicio a través de los sistemas.
  • chown guerras: Es muy común que un usuario enviar un ticket solicitando que sus permisos de directorio principal se fija en un sistema específico. La fijación de este problema en host2 rompe los permisos en host1. A veces puede tardar varios de estos tickets para ser trabajado antes de que alguien pasos hacia atrás y se da cuenta de que un remolcador de la guerra está en juego. La única solución es arreglar el desacuerdo de los ID de las asignaciones. Lo que conduce a...
  • UID/GID de reequilibrio infierno: La complejidad de la corrección de los Identificadores más tarde aumenta exponencialmente con el número de remappings involucrados para corregir un solo usuario a través de múltiples máquinas. (user1 tiene el IDENTIFICADOR de user2, pero user2 tiene el IDENTIFICADOR de user17...y eso es sólo el primer sistema en el clúster) El tiempo de espera para solucionar el problema, el más complejo de estas cadenas puede llegar a ser, y a menudo requieren el tiempo de inactividad de aplicaciones en múltiples servidores con el fin de obtener las cosas correctamente sincronizados.
  • Problemas de seguridad: user2 a host2 tiene el mismo UID como user1 a host1, lo que les permite escribir a /home/user1 a host2 sin el conocimiento de user1. Estos cambios son evaluadas en host1 con los permisos de user1. ¿Qué podría salir mal? (si user1 es un usuario de la aplicación, alguien en dev se descubre que es modificable y se hacen los cambios. este es un tiempo hecho probado.)

Hay otros escenarios, y estos son sólo algunos ejemplos de los más comunes.

los nombres no siempre son una opción

Las secuencias de comandos o archivos de configuración escrito en contra de los Identificadores numéricos se vuelven inherentemente transportables dentro de su entorno. Generalmente no es un problema porque la mayoría de la gente no codificar estos a menos que sean absolutamente necesarios...pero a veces la herramienta que estás trabajando con no darle una opción en el asunto. En estos casos, usted está obligado a mantener n diferentes versiones de la secuencia de comandos o el archivo de configuración.

Ejemplo: pam_succeed_if le permite usar los campos de user, uidy gid...un "grupo" opción está visiblemente ausente. Si usted se pone en una posición en múltiples sistemas que se espera implementar algún tipo de grupo basado en la restricción de acceso, tendrías n diferentes variaciones de la PAM configs. (o al menos una sola GID que tienes que evitar colisiones)

gestión centralizada

natxo la respuesta ha esta cubierto bastante bien.

20voto

JatSing Puntos 166

una vez que alcanzan un cierto tamaño (y siempre antes de lo que piensas) te darás cuenta de que el cambio de sus contraseñas o deshabilitar cuentas para alguien en todos los hosts es un pan de PITA. Es por eso que el uso de los sistemas con las bases de datos LDAP (o NIS pero no hagas eso, no es seguro hoy en día) como openldap o hoy en día la excelente freeipa.

Mantener todas las cuentas/grupos de información en una base de datos central, todos los hosts compartir esa información. Usted puede hacer muchas más cosas de allí: el uso de la información de los usuarios para permisos de archivo, por supuesto, pero también crear usuarios virtuales para todas las aplicaciones que se han ldap enlaces en lugar de tener que crear tus usuarios (muchas de las aplicaciones web pueden utilizar ldap para su base de datos de usuario), mantener una central sudo reglas de la base de datos, distribuir su autofs medio ambiente, mantener las zonas dns, ...

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X