Administración de Celerra para un entorno de

Administración de EMC Celerra para un
entorno de múltiples protocolos
P/N 300-008-087
Rev A02
Versión 5.6
Octubre de 2008
Contenido
Introducción al entorno Celerra de múltiples protocolos . . . . . . . . . . . . .3
Documentación de múltiples protocolos y Windows . . . . . . . . . . . . .3
Terminología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Conceptos del entorno Celerra de múltiples protocolos. . . . . . . . . . . . . .6
Requerimientos del sistema para un entorno Celerra
de múltiples protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
E-Lab Interoperability Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Opciones de interfaz de usuario para el entorno
Celerra de múltiples protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Guía para la administración de Celerra en un entorno
de múltiples protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Consideraciones de interoperabilidad. . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Uso de convenciones de nombres de archivos NFS y CIFS . . . . . .16
Resolución de conflictos de nombres de archivos . . . . . . . . . . . . . .16
Uso de enlaces simbólicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Enlace de file systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Selección de una política de control de acceso . . . . . . . . . . . . . . . . . . . .25
Uso de MIXED y MIXED_COMPAT. . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Reglas de herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Backups y restores de objetos de file systems . . . . . . . . . . . . . . . . .31
Configuración de una política de control de acceso. . . . . . . . . . . . .32
Migración a MIXED y MIXED_COMPAT. . . . . . . . . . . . . . . . . . . . . . . .32
Restablecimiento de MIXED y MIXED_COMPAT . . . . . . . . . . . . . . . .35
Generación de una credencial de Windows NT . . . . . . . . . . . . . . . . . . . .36
Procesamiento de una credencial de Windows NT . . . . . . . . . . . . . .36
Acceso a un dominio confiable mediante Windows 2000 . . . . . . . .37
Configuración del dominio predeterminado de Windows . . . . . . . .38
Definición de memoria caché para credenciales de
Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Configuración del vencimiento del registro de fecha y hora . . . . . .39
Generación de credenciales de Windows NT . . . . . . . . . . . . . . . . . .39
Inclusión de grupos UNIX en una credencial de Windows NT . . . . .40
Uso exclusivo de permisos UNIX para control de acceso. . . . . . . . . . . .41
Configuración de política de bloqueo de archivos. . . . . . . . . . . . . . . . . .42
Montaje del file system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Visualización y configuración de permisos UNIX desde un
cliente Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
1 de 80
Consideraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
Activación de capacidades especiales para la
administración de ACLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Configuración y administración de soporte de DFS . . . . . . . . . . . . . . . .47
Activación y desactivación de soporte de DFS . . . . . . . . . . . . . . . . .52
Uso de wide links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Pasos del proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Establecimiento de wide links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Visualización y configuración de ACLs de Windows
desde un cliente UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Recuperación de emcgetsd y emcsetsd. . . . . . . . . . . . . . . . . . . . . . .61
Visualización de ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Modificación de ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Resolución de problemas del entorno Celerra
de múltiples protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
Dónde obtener ayuda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
Construcción de mensajes de error de server_log . . . . . . . . . . . . . .68
Códigos de error Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
Códigos de estado NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
Problemas y limitaciones conocidos . . . . . . . . . . . . . . . . . . . . . . . . .70
Mensajes de error del entorno de múltiples protocolos
de Celerra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Información relacionada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
Programas de capacitación para clientes . . . . . . . . . . . . . . . . . . . . .74
Índice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
2 de 80
Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Introducción al entorno Celerra de múltiples protocolos
En un entorno UNIX, se utiliza el protocolo Network File System (NFS) para acceder
a los file systems. En un entorno Windows, se utiliza el protocolo Common Internet
File System (CIFS) para acceder a los file systems. EMC® Celerra® Network Server
soporta un entorno NFS y CIFS combinado mediante la provisión de capacidades
de acceso a múltiples protocolos, como políticas de control de acceso y mecanismos
de bloqueo que permiten que a los usuarios de UNIX y Windows compartir los
mismos file systems.
Este documento forma parte de la documentación de Celerra Network Server y
está dirigido a los administradores de sistemas responsables de la implementación
del Celerra Network Server en su entorno combinado Windows y UNIX.
Documentación de múltiples protocolos y Windows
Los siguientes documentos de Celerra Network Server explican cómo configurar y
administrar Celerra en un entorno Windows y en un entorno de múltiples protocolos:
◆
Configuring and Managing CIFS on EMC Celerra explica cómo configurar una
configuración básica CIFS en Celerra Network Server mediante la interfaz de
línea de comandos (CLI). Este entorno inicial también se puede configurar
mediante Celerra Manager.
◆
Configuring and Managing CIFS on EMC Celerra contiene procedimientos
avanzados que se podrían requerir después de la configuración inicial de CIFS
en Celerra Network Server e instrucciones para modificar y administrar Celerra
en un entorno Windows.
◆
Configuring NFS on EMC Celerra explica cómo configurar y administrar NFS
(versiones 2, 3 y 4) en Celerra Network Server.
Terminología
Esta sección define términos importantes para comprender las capacidades de
Administración de EMC Celerra para un entorno de múltiples protocolos en Celerra
Network Server. El EMC Celerra Glossary proporciona una lista completa de
terminología de Celerra.
Active Directory (AD): servicio de directorio avanzado que se incluye con Windows
2000 y Windows Server 2003. Almacena información de los objetos en una red y
permite que dicha información esté disponible para los usuarios y los administradores
de la red mediante un protocolo como LDAP.
Autenticación: proceso para verificar la identidad de un usuario que intente obtener
acceder a un recurso, objeto o servicio, por ejemplo, un archivo o un directorio.
Common Internet File System (CIFS): protocolo de uso compartido de archivos
basado en Microsoft Server Message Block (SMB). Permite a los usuarios compartir
file systems mediante Internet e intranets.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
3 de 80
Controlador de dominio: servidor que autentica los inicios de sesión y mantiene la
política de seguridad y la base de datos maestra de la cuenta de seguridad para un
dominio de Windows. Los controladores de dominio administran el acceso de
los usuarios a la red, incluidos el inicio de sesión, la autenticación y el acceso al
directorio y a los recursos compartidos. Consulte además dominio de Windows
2000 o Windows Server 2003 y dominio de Windows NT.
Data Mover: en un Celerra Network Server, un componente del gabinete que ejecuta
su propio sistema operativo que recupera archivos desde un dispositivo de
almacenamiento y permite que estén disponibles para un cliente de la red. También
se denomina blade. A veces al Data Mover se lo denomina internamente ‘DART’,
ya que DART es el software que se ejecuta en la plataforma.
Data Mover virtual (VDM): función del software Celerra que permite a los usuarios la
separación administrativa de servidores CIFS, la replicación de entornos CIFS y la
transferencia de servidores CIFS de un Data Mover a otro.
Domain Name System (DNS): Software de resolución de nombres que permite a
los usuarios ubicar computadoras en una red UNIX o red TCP/IP por el nombre de
dominio. El servidor DNS mantiene una base de datos de los nombres de dominio,
los nombre de host y sus direcciones de IP correspondientes, y los servicios que
prestan estos hosts. Consulte ntxmap.
Dominio: agrupación lógica de servidores de Microsoft Windows y de otras
computadoras que comparten seguridad común e información de cuentas de
usuarios. Todos los recursos como las computadoras y los usuarios son números
de dominio y poseen una cuenta en el dominio que los identifica como exclusivos.
El administrador de dominio crea una cuenta de usuario para cada usuario del
dominio y los usuarios inician sesión en el dominio una vez. Los usuarios no inician
sesión en cada servidor individual.
Dominio de Windows 2000 o Windows Server 2003: dominio de Microsoft Windows
controlado y administrado por Microsoft Windows 2000 o por Windows Server 2003
mediante Active Directory para administrar todos los recursos del sistema. Emplea
DNS para resolución de nombres.
Dominio de Windows NT: dominio de Microsoft Windows controlado y administrado
por un servidor de Microsoft Windows NT mediante una base de datos SAM para
administrar las cuentas de usuarios y grupos, y un namespace de NetBIOS. En un
dominio de Windows NT, existen un controlador de dominio primario (PDC) con
una copia de lectura/escritura de SAM y, posiblemente, varios controladores de
dominio de backup (BDCs) con copias de solo lectura de SAM.
File system: método para catalogar y administrar los archivos y los directorios en
un sistema de almacenamiento.
ID de usuario (UID): identificador numérico que corresponde a un usuario específico.
Identificador de grupo (GID): identificador numérico asignado a un grupo específico
de usuarios.
Identificador de seguridad (SID): identificador exclusivo que define a un usuario o a un
grupo en un entorno Microsoft Windows. Cada usuario o grupo posee su propio SID.
Lista de control de acceso (ACL): lista de entradas de control de acceso (ACEs)
que proporciona información sobre los usuarios y los grupos que poseen acceso
a un objeto.
4 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Microsoft Distributed File System (DFS): servicio de Windows 2000 y Windows
Server 2003 basado en software residente en servidores de red y en clientes que
enlaza de manera transparente las carpetas compartidas en los diferentes file servers
en un solo namespace.
Network Basic Input/Output System (NetBIOS): Interfaz y protocolo de programación
de red desarrollado para computadoras personales IBM.
Nombre de recurso compartido: nombre otorgado a un file system o a un recurso de
un file system disponible desde un servidor CIFS específico para usuarios CIFS.
Es posible contar con múltiples recursos compartidos con el mismo nombre,
compartidos desde servidores CIFS diferentes.
Nombre NetBIOS: nombre reconocido por WINS, que asigna el nombre a una
dirección IP.
Objetos de Política de Grupo (GPO): en Windows 2000 o Windows Server 2003,
los administradores pueden utilizar la política de grupo para definir las opciones de
configuración para los grupo de usuarios y computadoras. Los objetos de políticas
de grupo de Windows pueden controlar elementos como la configuración local, de
dominio y de seguridad de red.
Protocolo Ligero de Acceso a Directorio (LDAP): protocolo de acceso a la información
estándar de la industria que se ejecuta directamente mediante TCP/IP. Es el protocolo
de acceso primario para Active Directory y para los servidores de directorio basados
en LDAP. La versión 3 de LDAP se define mediante un conjunto de documentos
estándar propuestos en Internet Engineering Task Force (IETF) RFC 2251.
Server Message Block (SMB): protocolo subyacente utilizado por el protocolo CISS,
mejorado para uso en Internet para solicitud de servicios de comunicación, archivos
e impresiones desde un servidor por medio de la red. El protocolo CIFS emplea
SMB para brindar seguridad en el acceso y la transferencia de archivos para varios
tipos de hosts de red, como LANs, intranets e Internet.
Servicio de CIFS: el proceso del servidor CIFS que se ejecuta en el Data Mover que
presenta recursos compartidos en una red y en computadoras basadas en Microsoft
Windows.
Servidor CIFS: servidor lógico que utiliza el protocolo CIFS para la transferencia
de archivos. Un Data Mover puede albergar muchas instancias de un servidor
CIFS. Cada instancia se denomina servidor CIFS.
Servidor CIFS predeterminado: el servidor CIFS que se crea al agregar un servidor
CIFS sin especificar ninguna interfaz (con la opción interfaces= del comando
server_cifs -add). El servidor CIFS predeterminado utiliza todas las interfaces
no asignadas a otros servidores CIFS en el Data Mover.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
5 de 80
Conceptos del entorno Celerra de múltiples protocolos
Cada usuario de Celerra Network Server, ya sea un usuario de Windows o de
UNIX, debe ser identificado por un identificador de grupo (GID) y un identificador
de usuario (UID) numérico exclusivo. Sin embargo, Windows no utiliza IDs numéricos
para identificar usuarios. En lugar de esto, emplea cadenas llamadas identificadores
de seguridad (SIDs).
Resolución del IDs de usuarios CIFS
Antes de configurar el servicio de uso compartido de archivos de Windows
(denominado CIFS) en Celerra Network Server, se debe seleccionar un método de
mapping de SIDs de Windows para UIDs y GIDs. El método empleado dependerá
de la existencia de un entorno solo de Windows o UNIX, o de un entorno Windows
de múltiples protocolos. Dichos métodos incluyen:
◆
Active Directory
◆
Directorio LDAP
◆
Archivos locales
◆
Network Information Service (NIS)
◆
Usermapper (interno o externo)
EMC recomienda la utilización de Usermapper interno en entornos que sean
solamente de Windows. El Usermapper interno también puede utilizarse en
entornos de múltiples protocolos en los que los usuarios posean solamente
cuentas de usuario de Windows.
Configuración de mapping de usuario EMC Celerra proporciona una lista de las
herramientas y los métodos que pueden utilizarse para asignar usuarios de Windows
a UIDs y GIDs estilo UNIX, y las herramientas que se pueden utilizar para migrar
usuarios desde un entorno de protocolo único a un entorno de múltiples protocolos.
Seguridad de los objetos de los file systems
En un entorno de múltiples protocolos, Celerra Network Server emplea sus políticas
de seguridad para administrar el control de acceso de sus file systems.
Modelo de seguridad de UNIX
Los derechos de acceso de UNIX se conocen como bits de modo de un objeto de file
system. Se representan mediante una cadena de bits en la cual cada bit representa
un modo o un privilegio de acceso otorgado al usuario que posee el archivo, al grupo
asociado con el objeto del file system y a todos los demás usuarios.
Los bits de modo UNIX se representan como tres conjuntos triples de permisos rwx
(read, write, execute) concatenados para cada categoría de usuario (User, Group,
Other), como se muestra en el siguiente directorio de file system:
lrwxrwxrwx 1 kcb ing 10 Dic 9 13:42 xyz.doc -> xyz.html
-rw-r--r-- 1 kcb ing 1862 Ene 2 14:32 abc.html
drwxr-xr-x 2 kcb ing 5096 Mar 9 11:30 programa
Usuario
Otros
Grupo
CNS-000537
6 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
En el ejemplo anterior:
◆
El primer caracter de cada línea indica el tipo de archivo, que puede ser “d” para
un directorio, 1 para un enlace simbólico o guión (-) para un archivo regular.
◆
Los siguientes nueve caracteres de cada línea corresponden a los conjuntos
de permisos read/write o execute para el usuario, para el grupo o para otros.
◆
kcb corresponde al usuario y eng, al grupo.
◆
xyz.doc es un enlace simbólico que cualquier persona usar para recuperar el
archivo xyz.html.
◆
abc.html es un archivo regular que cualquier persona puede leer, pero solo el
usuario kcb puede escribirlo.
◆
schedule es un directorio que cualquier persona puede buscar y leer, pero solo
el usuario kcb puede insertar y borrar archivos en él.
Modelo de seguridad de Windows
Gracias a los diversos permisos de acceso y a las opciones Allow (Permitir) o Deny
(Denegar), el modelo de seguridad de Windows ofrece una estructura de seguridad
más flexible que el modelo de UNIX, como se muestra en la Figura 1 en la página 7.
Figura 1 Ejemplo de permisos de acceso de Windows
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
7 de 80
El acceso a un objeto del file system se concede o se deniega mediante un descriptor
de seguridad (SD). Un SD contiene información acerca de:
◆
El propietario del objeto, que es el creador del objeto del file system y tiene el
privilegio de modificar permisos en dicho objeto, como Owner SID y Primary
Group SID.
◆
Lista de control de acceso (ACL): Incluye información acerca del propietario del
objeto, ACL discrecional (DACL) que describe los permisos de acceso, y ACL
del sistema (SACL) que describe el criterio de información de auditorías. Para
el DACL, cada derecho de acceso se define en la entrada de control de acceso
(ACE), que de manera explícita concede o deniega acciones específicas para
un objeto de file system. Cada cuenta de grupo y de usuario especificada
posee un ACE en la ACL que representa los privilegios concedidos o denegados.
Celerra Network Server soporta ACLs en los niveles de archivos, directorios
y recursos compartidos.
Credenciales de usuario y control de acceso
Se genera una credencial de usuario de Windows que se almacena en la memoria
caché cuando un usuario se conecta por primera vez a Celerra Network Server por
medio del protocolo CIFS. La credencial contiene el SID del usuario y todos los
SIDs de los grupos a los que pertenece el usuario. Cuando se utiliza una autenticación
regular de UNIX (AUTH_SYS), se envía la credencial de usuario de UNIX con la
solicitud de protocolo Remote Procedure Calling (RPC). Dicha credencial está
compuesta por un UID y hasta 16 GIDs a los que pertenece el usuario. En un
entorno NFS seguro, la credencial de usuario de UNIX se genera durante la
autenticación Kerberos y está compuesta por el UID del usuario y los GIDs de
todos los grupos a los cuales pertenece el usuario. Cuando el usuario solicita
acceso a un objeto de file system, Celerra Network Server compara las
credenciales del usuario con los permisos de ese objeto de file system.
Para un usuario de FTP que provee un dominio y un nombre de usuario, Celerra
Network Server se contacta con el controlador del dominio para efectuar una
verificación y luego genera una credencial de Windows. Para un usuario FTP que
provee un nombre de usuario no calificado, Celerra Network Server genera una
credencial estilo UNIX que se basa en la información de contraseña local y en los
archivos de grupo, en NIS o en el servicio de directorios LDAP.
Políticas de control de acceso de Celerra
En un entorno de múltiples protocolos, Celerra Network Server debe decidir qué
conjunto de atributos de permisos utilizar en un archivo o en un directorio para
determinar el acceso de usuario que se concede a un objeto de file system. Este
proceso se denomina autorización de usuario y se controla por medio de la política
de control de acceso del file system.
Cuando se monta un file system con el comando server_mount, puede especificarse
una de las políticas de control de acceso que se explican en la Tabla 1 en la página 9.
Como opción predeterminada, cuando se crea un file system por primera vez
mediante el uso de la Control Station, no existe una ACL en la raíz de dicho file
system. El propietario UNIX es el usuario root y es el único que posee acceso de
escritura a este file system. El sistema Celerra configura de manera automática los
permisos de ACL como FULL CONTROL for EVERYONE en el directorio raíz del
recurso compartido de CIFS del file system una vez que se establece la primera
conexión con este recurso compartido.
8 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Las políticas de control de acceso se aplican solo cuando la autenticación de
usuarios del Data Mover se encuentra configurada con la opción predeterminada
recomendada, NT. Esta opción se configura mediante la opción -add security del
comando server_cifs.
Tabla 1
Políticas de control de acceso de Celerra (página 1 de 2)
Política de
Descripción
control de acceso
NATIVE (opción
predeterminada)
• El acceso a un archivo o a un directorio por medio de un FTP autenticado
con NFS o UNIX se concede solamente si los permisos UNIX del archivo
o directorio lo permiten.
• El acceso por medio de un FTP autenticado con CIFS o Windows se
concede solamente si los permisos Windows del archivo o directorio lo
permiten.
• Los permisos ACL y UNIX se mantienen para cada archivo y para cada
directorio.
• Una modificación en los permisos de un objeto de file system en NFS no
afecta los permisos en CIFS y una modificación en los permisos de un
objeto del file system en CIFS no afecta los permisos en NFS.
NT
• El acceso a un archivo o a un directorio por medio de un FTP autenticado
con NFS o UNIX se concede solamente si los permisos UNIX y Windows
lo permiten.
• El acceso por medio de un FTP autenticado con CIFS o Windows se
concede solamente si los permisos Windows lo permiten (los permisos
UNIX no tienen efecto).
• Los permisos ACL y UNIX se mantienen para cada archivo y para cada
directorio.
• Una modificación en los permisos de un objeto de file system en NFS no
afecta los permisos en CIFS y una modificación en los permisos de un
objeto del file system en CIFS no afecta los permisos en NFS.
UNIX
• El acceso a un archivo o a un directorio por medio de un FTP autenticado
con NFS o UNIX se concede solamente si los permisos UNIX lo permiten
(los permisos de Windows no tienen efecto).
• El acceso por medio de un FTP autenticado con CIFS o Windows se
concede solamente si los permisos UNIX y Windows del archivo o
directorio lo permiten.
• Los permisos ACL y UNIX se mantienen para cada archivo y para cada
directorio.
• Una modificación en los permisos de un objeto de file system en NFS no
afecta los permisos en CIFS y una modificación en los permisos de un
objeto del file system en CIFS no afecta los permisos en NFS.
SECURE
• Proporciona el mayor nivel de seguridad para CIFS y NFS.
• El acceso a un archivo o a un directorio por medio de NFS, FTP o CIFS
se concede solamente si los permisos UNIX del archivo o directorio lo
permiten.
• Los permisos ACL y UNIX se mantienen para cada archivo y para cada
directorio.
• Una modificación en los permisos de un objeto de file system en NFS no
afecta los permisos en CIFS y una modificación en los permisos de un
objeto del file system en CIFS no afecta los permisos en NFS.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
9 de 80
Tabla 1
Políticas de control de acceso de Celerra (página 2 de 2)
Política de
Descripción
control de acceso
MIXED
• El acceso a un archivo o a un directorio por medio de NFS, FTP o CIFS lo
determina siempre la ACL.
• Los permisos ACL y UNIX se mantienen para cada archivo y para cada
directorio.
• Las ACLs para archivos y directorios se crean a partir del último protocolo
que haya configurado o modificado los permisos. Por ejemplo, si un cliente
NFS configura o modifica permisos en un archivo o en un directorio, se
vuelve a generar la ACL basada en los bits de modo UNIX. Si un cliente
CIFS configura o modifica permisos en un archivo o en un directorio, la ACL
se genera basada en los permisos estándar de Windows.
• En todos los casos, la ACL determina el acceso a los archivos y a los
directorios sin importar si el cliente utiliza un protocolo NFS, CIFS o FTP.
• Los permisos de ACL son más granulares que los bits de modo UNIX; en
consecuencia, no todos los permisos que se configuran en una ACL se
podrán traducir a bits de modo UNIX. En algunos casos, es posible que
los bits de modo muestren más permisos que los que posee un usuario
realmente. Consulte "Uso de MIXED y MIXED_COMPAT" en la página 27
para obtener una descripción detallada.
MIXED_COMPAT
• El acceso a un archivo o a un directorio por medio de NFS, FTP o CIFS lo
determina el último protocolo (NFS o CIFS) que haya configurado o
modificado los permisos.
• Los permisos ACL y UNIX se mantienen para cada archivo y para cada
directorio.
• Si los permisos de un archivo o directorio se configuran o se modifican
desde un cliente CIFS, el acceso lo determinará la ACL (EXPLICIT ACL).
Los bits de modo UNIX se generan basados en la ACL, pero no se utilizan
para el control de acceso.
• Si los permisos de un archivo o directorio se configuran o se modifican
desde un cliente UNIX, los bits de modo UNIX determinan el acceso.
Igualmente se crea una ACL, pero no se utiliza para el control de acceso.
• Los permisos de ACL son más granulares que los bits de modo UNIX; en
consecuencia, no todos los permisos que se configuran en una ACL se
podrán traducir a bits de modo UNIX. En algunos casos, es posible que
los bits de modo muestren más permisos que los que posee un usuario
realmente. Consulte "Uso de MIXED y MIXED_COMPAT" en la página 27
para obtener más información.
Nota: No establezca una raíz de DFS en un objeto del file system con una política de control
de acceso de UNIX o SECURE, ya que ninguno de los componentes del enlace de DFS se
crea con derechos UNIX.
La configuración del parámetro cifs acl.unixCheckAcl=0 altera el comportamiento
de la política de acceso al file system UNIX para que solo se utilicen los bits de
modo UNIX de los directorios y los archivos para determinar el acceso de los usuarios
a los archivos, independientemente del protocolo que usen para acceder al file
system. El file system igualmente almacenará la ACL configurada, pero no aplicará
los derechos de acceso del usuario.
Nota: Si utiliza este parámetro, también podría considerar configurar el bit 1 del parámetro
del servidor cifs acl.extacl en ‘2’. Esto expone los bits de modo UNIX de los directorios
y archivos como ACEs adicionales en las ACLs de los directorios y archivos.
10 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Credencial estilo Windows para usuarios UNIX
En un entorno de múltiples protocolos, algunos usuarios o todos los usuarios tendrán
identidades de usuario UNIX y Windows y podrán usar cualquiera de las dos
identidades para acceder a los datos almacenados por el sistema Celerra. La
característica de credencial de Windows NT permite a Celerra Network Server
tomar en cuenta las membresías de grupo de un usuario Windows en el momento
de controlar una ACL para el acceso mediante NFS. Cuando un usuario UNIX inicia
una solicitud de un objeto de un file system, Celerra Network Server asigna el UID
de UNIX al SID de Windows y, a continuación, fusiona los grupos UNIX y Windows
del usuario para generar una credencial de Windows NT.
La credencial de Windows NT es muy similar a una credencial de Windows, excepto
por el hecho de que no contiene grupos locales porque un usuario UNIX no puede
recuperar dichos grupos desde la computadora local. Una vez generada la credencial
de Windows NT, se amplía la credencial UNIX proporcionada en la solicitud NFS
RPC para control de acceso de NFS.
La credencial de Windows NT proporciona lo siguiente:
◆
Permisos consistentes en un objeto de file system independientes del protocolo
de acceso.
◆
Caché para almacenamiento de credenciales de Windows NT, con menos
tiempo de procesamiento de control de acceso.
◆
Administración de acceso a los datos mediante ACLs, independientemente
del protocolo que emplee el cliente.
◆
Mejora la limitación de credenciales de UNIX de 16 grupos por usuario que
imponen las versiones 2 y 3 de NFS.
El uso de la característica de credenciales de Windows NT en un entorno de
múltiples protocolos puede resultar muy conveniente, ya que toma en cuenta
las membresías de grupos de Windows al controlar una ACL mediante NFS.
Uso del Data Mover como servidor DFS
Microsoft Distributed File System (DFS) permite a los administradores agrupar
carpetas compartidas en diferentes servidores dentro de un namespace de DFS
lógico. Un namespace de DFS es una vista virtual de estas carpetas compartidas
que se muestran en una estructura de árbol de directorios. Mediante el uso de
DFS, los administradores pueden elegir qué carpetas compartidas mostrar en el
namespace, asignar nombres a dichas carpetas y diseñar la jerarquía del árbol en
el que aparecen las carpetas. Los usuarios pueden navegar en el namespace sin
necesidad de conocer los nombres de los servidores ni la cantidad exacta de
carpetas compartidas que albergan los datos.
Cada estructura de árbol de DFS posee un destino raíz que es el servidor host que
ejecuta el servicio DFS y alberga el namespace. Una raíz de DFS contiene enlaces
que hacen referencia a las carpetas compartidas (un recurso compartido en sí y los
directorios contenido en él) de la red. Estas carpetas se denominan destinos DFS.
Servidores raíz de DFS
Microsoft ofrece dos tipos de servidores raíz de DFS: el servidor raíz de DFS de
dominio y el servidor raíz de DFS independiente. El servidor de DFS de dominio
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
11 de 80
almacena la jerarquía de DFS en el Active Directory. El servidor raíz de DFS
independiente almacena la jerarquía de DFS en una ubicación local. Celerra
Network Server ofrece la misma funcionalidad que un servidor raíz de DFS
independiente Windows 2000 o Windows Server 2003.
Para obtener una descripción detallada de DFS, visite el sitio Web de Microsoft
en http://www.microsoft.com
Wide links
La función de wide links de Celerra Network Server utiliza la funcionalidad de
Microsoft DFS para resolver los enlaces simbólicos absolutos de UNIX para los
clientes Windows. Para esto, se crea una raíz de DFS en un recurso compartido
de CIFS y luego se establece un enlace en la raíz de DFS que asigna el punto de
montaje UNIX al servidor Windows:\share\path. Este mapping se realiza con la
herramienta MMC DFS. Resulta difícil para un cliente Windows abrir un path a un
objeto del file system cuando el path contiene un enlace simbólico absoluto. El
cliente Windows le solicita al servidor que realice una función en un objeto del file
system basado en un path determinado. A diferencia de Windows, los clientes
UNIX emplean un path de destino asociado a su punto de montaje. Dicho path
puede conducir a un objeto de file system en un servidor remoto.
Ejemplo
Un cliente UNIX posee los siguientes dos file systems montados:
server1:/ufs1 montado en /first
server2:/ufs2 montado en /second
En el ufs1, hay un enlace de directorio simbólico absoluto a /second/home. El
cliente UNIX puede acceder a este enlace de manera sencilla desde ufs1. Sin
embargo, dado que este path existe solo en el cliente UNIX y no en el servidor
local, el cliente Windows no puede seguir este path.
Mediante el uso de wide links, los clientes Windows pueden seguir un enlace
simbólico absoluto para acceder a archivos desde el mismo directorio que los
clientes UNIX. Para esto, el sistema Celerra emplea la funcionalidad raíz de DFS
del Data Mover.
La traducción de wide links facilita la creación y el mantenimiento de un único
namespace de file system de múltiples protocolos que abarca varios file servers
y reduce la carga asociada con la consistencia que se debe mantener entre las
definiciones de estructuras de namespace de NFS y CIFS (por ejemplo, tabla de
montaje automático NFS y DFS). "Uso de wide links" en la página 53 proporciona
información más detallada.
12 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Requerimientos del sistema para un entorno Celerra
de múltiples protocolos
Para obtener información acerca de los requerimientos del sistema, consulte:
◆
Configuring and Managing CIFS on EMC Celerra para requerimientos de
acceso de CIFS.
◆
Configuring NFS on EMC Celerra para requerimientos de acceso de NFS.
◆
"E-Lab Interoperability Navigator" en la página 13 para obtener un listado de los
clientes NFS y CIFS soportados.
E-Lab Interoperability Navigator
EMC E-LabTM Interoperability Navigator es una aplicación basada en Web en la
que se pueden hacer búsquedas que brinda acceso a matrices de soporte de
interoperabilidad de EMC. Se encuentra disponible en el sitio Web de EMC
Powerlink® en http://Powerlink.EMC.com. Inicie sesión en Powerlink y haga clic en
Soporte > Información de Interoperabilidad y de Ciclo de Vida de Productos >
E-Lab Interoperability Navigator.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
13 de 80
Opciones de interfaz de usuario para el entorno
Celerra de múltiples protocolos
Celerra Network Server ofrece flexibilidad para administración de networked
storage basado en su entorno de soporte y sus preferencias de interfaz. Este
documento describe cómo configurar Celerra Network Server en un entorno de
múltiples protocolos mediante la interfaz de línea de comandos (CLI). También
podrá realizar algunas de estas tareas mediante las aplicaciones de administración
de Celerra:
◆
Celerra Manager: Basic Edition
◆
Celerra Manager: Advanced Edition
◆
Snap-ins de Microsoft Management Console (MMC)
◆
Extensiones de usuarios y computadoras de Active Directory (ADUC)
Para obtener información adicional acerca de la administración de Celerra, consulte:
◆
Learning about EMC Celerra en el EMC Celerra Network Server
Documentation CD
◆
Ayuda en línea de Celerra Manager
◆
El sistema de ayuda en línea de la aplicación incluido en el EMC Celerra
Network Server Documentation CD
El documento Installing EMC Celerra Management Applications incluye
instrucciones para iniciar Celerra Manager y para instalar los snap-ins de MMC y
las extensiones de ADUC.
14 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Guía para la administración de Celerra en un entorno
de múltiples protocolos
Las tareas que se requieren para administrar Celerra en un entorno de múltiples
protocolos son las siguientes:
◆
"Consideraciones de interoperabilidad" en la página 16
◆
"Selección de una política de control de acceso" en la página 25
◆
"Generación de una credencial de Windows NT" en la página 36
◆
"Uso exclusivo de permisos UNIX para control de acceso" en la página 41
◆
"Configuración de política de bloqueo de archivos" en la página 42
◆
"Visualización y configuración de permisos UNIX desde un cliente Windows" en
la página 45
◆
"Configuración y administración de soporte de DFS" en la página 47
◆
"Uso de wide links" en la página 53
◆
"Visualización y configuración de ACLs de Windows desde un cliente UNIX" en
la página 61
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
15 de 80
Consideraciones de interoperabilidad
Aunque el uso compartido de archivos de múltiples protocolos suele ser transparente
para los usuarios finales, existen consideraciones especiales que se deben tener
en cuenta para el soporte de un entorno de múltiples protocolos.
Esta sección describe:
◆
"Uso de convenciones de nombres de archivos NFS y CIFS" en la página 16
◆
"Resolución de conflictos de nombres de archivos" en la página 16
◆
"Uso de enlaces simbólicos" en la página 17
◆
"Enlace de file systems" en la página 20
Uso de convenciones de nombres de archivos NFS y CIFS
La Tabla 2 en la página 16 explica las diferencias que existen entre los protocolos
NFS y CISS en cuanto a las convenciones de nombres de archivos.
Tabla 2
convenciones de nombres de archivos NFS y CIFS
Nombres de NFS
Nombres de CIFS
Distinguen entre mayúsculas y minúsculas.
No distinguen entre mayúsculas y minúsculas,
pero las preservan.
Permiten que un directorio contenga
archivos con nombres iguales, pero con
diferencias en el uso de mayúsculas y
minúsculas.
No permiten que un directorio contenga dos
archivos con un mismo nombre y diferencias en
el uso de mayúsculas y minúsculas, e identifican
dichos nombres como nombres duplicados.
Nota
Al crear nombres UID y GID para clientes Windows, los nombres de Windows (nombres de
grupos globales, nombres de dominio y nombres de usuario) deben escribirse en minúsculas en
NIS, en los archivos con contraseña y en los archivos UNIX de grupo. Deberá ser cuidadoso al
realizar mapping explícito de usuarios y grupos; Celerra Network Server no reconoce nombres
como Windows.
Resolución de conflictos de nombres de archivos
Debido a las diferencias en las convenciones de nombres de archivos, es posible
que los archivos creados por un usuario NFS eventualmente presenten conflictos
para un usuario CIFS. Esto ocurre cuando un usuario NFS crea archivos en un solo
directorio con nombres que únicamente presentan diferencias en el uso de mayúsculas
y minúsculas.
Para resolver los conflictos de nombres, Celerra Network Server diferencia el
nombre del archivo CIFS anexando un identificador numérico. Por ejemplo:
16 de 80 Versión 5.6
◆
Un archivo NFS, Aaa, en un directorio NFS y CIFS se muestra a los usuarios
CIFS como Aaa.
◆
Un segundo archivo NFS, aAA, en el mismo directorio es exclusivo para los
usuarios NFS, pero se muestra a los usuarios CIFS como aAA~1.
◆
Un tercer archivo NFS, aAa, es exclusivo para los usuarios NFS, pero se
mostrará a los usuarios CIFS como aAa~2.
Administración de EMC Celerra para un entorno de múltiples protocolos
Uso de enlaces simbólicos
Los enlaces simbólicos son nodos especiales creados por los clientes UNIX que
hacen referencia a otro nodo (un archivo o directorio denominado nodo de destino).
El nodo destino se define en un nodo de enlace simbólico como un nombre de path.
Normalmente, los enlaces simbólicos de NFS no son pertinentes para los clientes
Windows, ya que el cliente debe resolver (seguir) el enlace simbólico a su destino.
Sin embargo, en ciertas circunstancias, Celerra Network Server resuelve enlaces
simbólicos para clientes Windows con el objeto de que dichos clientes puedan acceder
a los mismos archivos y directorios como clientes UNIX mediante un enlace simbólico.
Nota: Para asegurarse que se haya hecho backup de los enlaces simbólicos al utilizar
herramientas de backup basadas en Windows (como NTbackup), configure el bit 3 del
parámetro cifs acl.extacl. "Visualización y configuración de ACLs de Windows desde un
cliente UNIX" en la página 61 explica el parámetro cifs acl.extacl.
Si Celerra Data Mover puede acceder al destino en nombre del usuario CIFS, el
usuario visualiza el destino del enlace simbólico y no enlace mismo, y desconoce que
ha seguido un enlace simbólico. Si el destino es inaccesible, el usuario visualiza el
enlace simbólico como un archivo pero no puede acceder a dicho archivo.
Como opción predeterminada, Celerra Network Server resuelve los enlaces simbólicos
para clientes Windows únicamente si el destino:
◆
No contiene un path absoluto (nombre de path completo). En otras palabras, el
path de destino no comienza con una barra diagonal (/).
◆
No asocia el directorio que contiene el enlace simbólico con el directorio principal
(no cuenta con un nombre de path al que pueda hacer referencia de manera
ascendente por medio del componente ‘..’).
Ejemplos de enlaces simbólicos válidos y no válidos
El Data Mover puede seguir un enlace simbólico que haga referencia a dir2/dir3 en
nombre de los clientes Windows, ya que el destino depende del directorio en el que
reside el enlace mismo.
A menos que se configure el parámetro oculto followabsolute, los clientes Windows
no podrán seguir un enlace simbólico que haga referencia a /dir1/dir2/dir3. Esto se
debe a que el destino depende de la raíz del file system y, por lo tanto, no puede
resolverse.
!
!
PRECAUCIÓN
Cuando un Data Mover resuelve enlaces simbólicos en nombre de los clientes CIFS,
dichos clientes no pueden establecer una distinción entre el enlace simbólico en sí y
el destino del enlace simbólico. Por lo tanto, si un enlace simbólico hace referencia a
un directorio y un usuario Windows intenta eliminar el enlace simbólico, se eliminan
el enlace y el contenido del directorio al que hace referencia el enlace
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
17 de 80
!
!
PRECAUCIÓN
No utilice las aplicaciones de Microsoft Office en archivos representados por enlaces
simbólicos. Cuando se actualiza un archivo, Microsoft Office crea el archivo actualizado
en el directorio que contiene el enlace simbólico y no en el directorio de destino del
enlace simbólico.
!
!
PRECAUCIÓN
Cuando no se puede acceder al destino, no se puede eliminar el enlace simbólico
mediante un cliente Windows. Durante el proceso de eliminación, Microsoft Explorer
intenta abrir el archivo (que no se puede localizar) y se produce un error.
El Data Mover no puede seguir un enlace simbólico que haga referencia a ../file en
nombre de los clientes Windows a menos que se configure el parámetro shadow
followdotdot. Aun así, el enlace puede traducirse solamente si el destino se encuentra
dentro del mismo recurso compartido que el enlace mismo.
Cambio del comportamiento predeterminado del enlace simbólico
Los siguientes parámetros del sistema modifican el comportamiento predeterminado
de los enlaces simbólicos:
shadow followdotdot: si se soportan enlaces simbólicos con paths destino que
hagan referencia a directorios principales, cambie el parámetro followdotdot oculto.
Aunque cambie el parámetro, igualmente es necesario ubicar el nodo destino en el
mismo espacio compartido (no es posible hacer referencia a una ubicación fuera
del recurso compartido) a menos que se active el parámetro shadow followabsolutpath.
"Cambio del parámetro shadow followdotdot" en la página 18 proporciona
información más detallada.
shadow followabsolutpath: si se deben soportar los enlaces simbólicos que utilicen
paths absolutos como destino, cambie el parámetro followabsolutpath. "Activación
de enlaces simbólicos con paths absolutos" en la página 20 proporciona
información más detallada.
Cuando se activa el parámetro shadow followabsolutpath para seguir paths
absolutos, el Data Mover el interpreta destino. El Data Mover solo puede resolver
paths que dependan del file system raíz en el Data Mover. Si se trata de un Data
Mover virtual, este path debe ser la raíz del VDM (por ejemplo, /mountpoint/directory);
de lo contrario, el cliente Windows no podrá acceder al destino.
Con NFS, los clientes leen un path destino del enlace simbólico y tratan de acceder
al destino por medio de una búsqueda local en el cliente. Los clientes NFS solo
pueden acceder a los destinos con paths absolutos si los clientes poseen el mismo
punto de montaje que el Data Mover.
Cambio del parámetro shadow followdotdot
Como opción predeterminada, el Data Mover no sigue en nombre de los clientes
Windows enlaces simbólicos que contengan pathnames que hagan referencia
ascendente a directorios principales. Si se altera el parámetro shadow followdotdot,
el Data Mover sigue en nombre de los clientes Windows los enlaces simbólicos que
contengan el componente ‘..’.
18 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
!
!
PRECAUCIÓN
La activación del parámetro shadow followdotdot apuntada a que el Data Mover siga
los enlaces simbólicos de manera ascendente en nombre de los clientes Windows
podría crear loops infinitos en el namespace que se presenta a los clientes Windows.
Las aplicaciones que realizan búsquedas del namespace corren el riesgo de bloquearse
en un loop infinito.
Acción
Para permitir que el Data Mover siga en nombre de los clientes Windows los enlaces
simbólicos con el componente ‘..’ en los pathnames de destino, use la siguiente sintaxis
de comandos:
$ server_param <movername> -facility shadow -modify followdotdot
-value 1
donde:
<movername> = nombre del Data Mover
Ejemplo:
$ server_param server_2 -facility shadow -modify followdotdot value 1
Salida
server_2 : done
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
19 de 80
Activación de enlaces simbólicos con paths absolutos
Como opción predeterminada, el Data Mover no sigue en nombre de los clientes
Windows enlaces simbólicos que contengan paths absolutos (pathnames completos).
Si se altera el parámetro shadow followabsolutpath, el Data Mover no seguirá
enlaces simbólicos que contengan pathnames completos.
Nota: Si se configura el Bit 1, se crea un problema de seguridad potencial para el acceso
NFS, ya que el cliente NFS puede crear un enlace simbólico absoluto para cualquier
ubicación del Data Mover. Si no se configura el Bit 1, solo se seguirán los enlaces
que posea el la raíz (uid 0).
Acción
Para permitir que el Data Mover siga en nombre de los clientes Windows los enlaces
simbólicos cuando el destino sea un path absoluto, use la siguiente sintaxis de
comandos:
$ server_param <movername> -facility shadow -modify
followabsolutpath -value <new_value>
donde:
<movername> = nombre del Data Mover
<new_value> = lista de bits
Bit 0:
0 = no permite enlaces simbólicos que contengan un path absoluto
1= permite seguir enlaces simbólicos que contengan un path absoluto
Bit 1:
0 = permite seguir solo enlaces simbólicos absolutos que pertenezcan a la raíz
(UID 0)
1= permite seguir cualquier enlace simbólico absoluto
Ejemplo:
$ server_param server_2 -facility shadow -modify
followabsolutpath -value 1
Salida
server_2 : done
Enlace de file systems
Mediante el uso de enlaces simbólicos, los clientes CIFS pueden tener acceso a
file systems múltiples en un Data Mover desde un único recurso compartido. Esto
le brinda la apariencia de un gran namespace cuando en realidad está compuesto
por file systems individuales que se enlazan mediante enlaces simbólicos. Una vez
activado el parámetro shadow followabsolutpath, es posible crear un único recurso
compartido CIFS que brinde acceso a file systems múltiples en un Data Mover.
"Activación de enlaces simbólicos con paths absolutos" en la página 20
proporciona información más detallada.
20 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Para enlazar file systems mediante un enlace simbólico:
Paso
Acción
1.
Active el shadow followabsolutpath. Como opción predeterminada, este parámetro no
se activa en el Data Mover. "Cambio del comportamiento predeterminado del enlace
simbólico" en la página 18 proporciona información más detallada.
2.
Monte los file systems.
3.
Cree un recurso compartido en el file system de nivel superior (el que posee enlaces
simbólicos).
4.
Monte el file system de nivel superior en un cliente NFS.
5.
Cree un enlace simbólico al file system en el directorio en el que se accederá al enlace.
Acceso a enlaces simbólicos por medio de clientes CIFS
El siguiente ejemplo muestra los pasos que se requieren para montar dos file
systems, crear un recurso compartido en el file system de nivel superior y, luego,
enlazar el segundo file system al recurso compartido mediante un enlace simbólico:
Nota: Es posible realizar los siguientes pasos únicamente mediante el uso de la Control
Station y de un cliente NFS.
Paso
Acción
1.
Configure el parámetro shadow followabsolutpath en 1 (activar).
2.
Monte los dos file systems, ufs1 y ufs2:
$ server_mount server_2
server_2 :
root_fs_2 on / uxfs,perm,rw
root_fs_common on /.etc_common uxfs,perm,ro
ufs1 on /ufs1 uxfs,perm,rw
ufs2 on /ufs2 uxfs,perm,rw
3.
Cree un recurso compartido para ufs1 (file system de nivel superior):
$ server_export server_2
server_2 :
export "/ufs1"
share "ufs1" "/ufs1" netbios=NS700-JB1 maxusr=4294967295 umask=22
4.
Monte el file system de nivel superior, ufs1, en un cliente NFS:
# mount 192.168.101.238:/ufs1 /ufs1
# montaje
192.168.101.238:/ufs1 on /ufs1 type nfs (rw,addr=192.168.101.238)
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
21 de 80
Paso
5.
Acción
El enlace simbólico sigue el path absoluto en relación al Data Mover. Este path es un path
absoluto que depende del file system raíz en el Data Mover.
Nota: Debe contar con privilegios de usuario root para crear un enlace simbólico.
Cree un enlace simbólico al segundo file system, ufs2, en el directorio en el que se
accederá al enlace (en este ejemplo, /ufs1).
# ln -s /ufs2 fslink2
# ls -l
total 8
lrwxrwxrwx
1 root
root
5 Jun 10 2004 fslink2 ->
/ufs2
drwxr-xr-x
2 root
root
8192 Jun 9 12:14 lost+found
Nota: Los puntos de comprobación de un file system enlazado no aparecerán debajo del
file system de nivel superior (en este ejemplo, usf1). Para visualizar estos puntos de
comprobación, deberá ubicarse en el directorio correspondiente al file system enlazado.
En el paso anterior, el comando ln -s /ufs2 fslink2 enlaza fslink2 al path /ufs2 de
la misma manera que al Data Mover. Los clientes CIFS que accedan al recurso
compartido ufs1 podrán visualizar fslink2 como uno de sus directorios, como se
muestra en la Figura 2 en la página 22.
Figura 2 Ejemplo de enlace simbólico
Acceso a enlaces simbólicos por medio de clientes NFS
Los clientes NFS no pueden acceder al enlace fslink2 porque no conocen este path
en el Data Mover, el cual se muestra a continuación:
# ls -l
total 8
lrwxrwxrwx
1 root
root
5 Jun 10 13:20 fslink2 -> /ufs2
drwxr-xr-x
2 root
root
8192 Jun 9 12:14 lost+found
# cd fslink2
bash: cd: fslink2: No such file or directory
Para que los clientes NFS tengan acceso a enlaces simbólicos, se deben realizar los
pasos adicionales de exportar el file system, crear y montar el directorio, y, finalmente,
montar el file system a dicho directorio.
22 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
El siguiente ejemplo muestra los pasos que se requieren para exportar /ufs2 en el
Data Mover, crear y montar el directorio /ufs2 en el cliente NFS y, finalmente, montar
el ufs2 a dicho directorio:
Paso
Acción
1.
Exporte el file system en el Data Mover:
# server_export server_2 -o anon=0 /ufs2
server_2 : done
2.
Cree el directorio y monte el file system en el cliente NFS:
# mkdir /ufs2
# mount 192.168.101.238:/ufs2 /ufs2
# cd /ufs1
# ls -l
total 8
lrwxrwxrwx
1 root
root
5 Jun 10 13:20 fslink2 ->
/ufs2
drwxr-xr-x
2 root
root
8192 Jun 9 12:14 lost+found
3.
Una vez que se crea el directorio /ufs2 en el cliente NFS y se monta el file system en dicho
directorio, el cliente puede seguir el enlace simbólico que se presenta a continuación:
# cd fslink2
# ls -l
total 32
drwxr-xr-x
2 root
root
8192 Jun 9 12:15 lost+found
-rw-r--r-1 32769
32771
24064 Jun 10 09:52 test1.doc
Limitaciones de enlace de archivos
Las limitaciones de enlace de archivos son las siguientes:
◆
Cuando un usuario sigue un enlace desde el file system de nivel superior
a un file system subordinado, se aplica la política de control de acceso del file
system de nivel superior al file system subordinado.
◆
El tamaño del file system de nivel superior (desde el cual se conecta el usuario)
no refleja el tamaño de los file systems subordinados.
◆
Las cuotas siempre se informan por cada file system. Si existen usuarios,
grupos o árboles en file systems subordinados, cada file system se informa
de manera individual.
◆
Si se configuran las solicitudes de notificación en el sistema de nivel superior
con el bit WatchTree, las modificaciones de los file systems subordinados no
generarán notificaciones.
◆
Algunas solicitudes arrojan el pathname completo de los archivos abiertos. Si
un archivo abierto se encuentra en un file system al que se accede por medio
de un enlace simbólico, es posible que el path que arroje no sea el path
esperado.
◆
Al recorrer file systems mediante enlaces simbólicos, es posible que el comando
cd .. no arroje el directorio que contiene el enlace simbólico (desde Microsoft
Windows Explorer, esto no constituye un problema).
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
23 de 80
24 de 80 Versión 5.6
◆
Al realizar restores de archivos desde backups en file systems enlazados,
siempre se deben realizar restores de los enlaces simbólicos en primer lugar;
de lo contrario, el restore completo se realiza en el file system de nivel superior.
◆
Si un file system subordinado no se monta en un Data Mover, los clientes CIFS
verán el enlace simbólico como un directorio. Este directorio es el file system
raíz del Data Mover.
Administración de EMC Celerra para un entorno de múltiples protocolos
Selección de una política de control de acceso
La Figura 3 en la página 25 ayuda a decidir qué política de control de acceso es
más apropiada para el entorno.
Inicio
¿Es un file
system de
protocolos
múltiples?
No
Sí
¿Se
requiere
sincronización
automática de
permisos Windows
y UNIX o
NFSv4?
Sí
No
¿Se
requiere
seguridad
entre los
protocolos?
No
Sí
UNIX
NATIVO
UNIX
¿Es el sistema
operativo
predominante?
Windows
NT
MIXTO
O
MIXTO_COMPAT
Igualmente
Windows
y UNIX
SEGURO
CNS-000542
Figura 3 Árbol de toma de decisiones para políticas de control de acceso
Nota: Se denomina sincronización automática a la traducción de bits de modo UNIX en
ACLs cuando se configuran los permisos de un cliente NFS y, en sentido opuesto, hace
alusión a la traducción de ACLs en bits de modo UNIX en los objetos del file system cuando
se configuran permisos de un cliente CIFS. "Sincronización automática" en la página 27
explica la manera en que ocurre esto en Celerra Network Server.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
25 de 80
La Tabla 3 en la página 26 muestra la manera en que interactúan las políticas de
acceso de Celerra con los clientes CIFS y NFS para controlar los permisos de un
objeto de file system en un entorno de múltiples protocolos.
Tabla 3 Control de permisos en un entorno de múltiples protocolos.
Política de
control de
acceso
Atributos de
permisos
NATIVE (opción
predeterminada)
UNIX
NT
Clientes NFS
Se controla la ACL.
Dos atributos de
permisos: ACL
y bits de modo
UNIX.
SECURE
MIXED
Clientes CIFS
¿Las modificaciones
efectuadas en un
conjunto de
permisos se reflejan
en otro conjunto de
permisos?
Se controlan los
derechos UNIX
y la ACL.
Se controlan los
derechos UNIX.
No
Se controla la ACL.
Se controlan los
derechos UNIX y la ACL.
Se controlan los
derechos UNIX y la ACL.
Debido a la
sincronización
automática, se
aplica un
conjunto de
atributos de
permisos
independienteme
nte del protocolo.
Se controla la ACL. Si no existe una ACL, se crea
una basada en los bits de modo UNIX. El acceso
también lo determina la ACL.
Una modificación en la
ACL vuelve a generar
los bits de modo UNIX,
pero no se controlan los
derechos UNIX.
Una modificación en los
bits de modo UNIX
vuelve a generar los
permisos de ACL, pero
no se controlan los
derechos UNIX.
Debido a la
sincronización
automática, se
aplica un
conjunto de
atributos de
permisos
independienteme
nte del protocolo.
Si un cliente CIFS
configuró o modificó por
última vez los permisos
de un archivo o
directorio, se controla
la ACL y se vuelven a
generar los derechos
UNIX, pero no se
controlan. Si un cliente
NFS configuró o
modificó por última vez
los permisos de un
archivo o directorio, se
controlan los derechos
UNIX y se vuelve a
generar la ACL, pero no
se controla.
Si un cliente NFS
configuró o modificó por
última vez los permisos
de un archivo o
directorio, se controlan
los derechos UNIX y se
vuelve a generar la ACL,
pero no se controla.
Si un cliente CIFS
configuró o modificó por
última vez los permisos
de un archivo o
directorio, se controla
la ACL y se vuelven a
generar los derechos
UNIX, pero no se
controlan.
Los clientes NFSv4
pueden administrar
la ACL.
Los clientes NFSv4
pueden administrar
la ACL.
Los clientes NFSv4 pueden administrar la ACL.
Sí
MIXED_COMPAT
26 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Nota: Al acceder a las ACLs desde un cliente Windows, estas se controlan solo si
el método de autenticación de usuario CIFS se configura en el modo predeterminado
recomendado, NT. Esto se configura mediante la opción -add security del comando server_cifs.
Todas las solicitudes de acceso que se controlan con los permisos UNIX pueden forzarse
mediante la modificación del parámetro cifs acl.checkacl. "Uso exclusivo de permisos UNIX
para control de acceso" en la página 41 proporciona información más detallada.
Uso de MIXED y MIXED_COMPAT
UNIX y Windows administran el control de acceso de modos muy diferentes,
lo que dificultan la configuración de los mismos parámetros de seguridad para un
objeto de file system en un entorno de múltiples protocolos. La política MIXED
y MIXED_COMPAT de Celerra sincroniza los permisos UNIX y Windows de la
manera más similar posible mediante un algoritmo que traduce los derechos UNIX
en entradas de ACL y, asimismo, las entradas ACL en derechos UNIX.
Las políticas MIXED y MIXED_COMPAT difieren en la manera en que traducen un
grupo UNIX en una ACE y en la manera en que ejecutan el control de acceso.
Como se explica en el siguiente ejemplo, la política MIXED siempre realiza el control
de acceso con una ACL, independientemente del protocolo que se emplee para
acceder a un objeto del file system. La política MIXED_COMPAT utiliza los permisos
de protocolo que hayan configurado o modificado los permisos por última vez en
un objeto del file system.
Ejemplo de MIXED
Se asignan los bits de modo de rwxrw-r- al archivo FileX. Si se modifica la ACL del
archivo FileX de manera tal que se conceda acceso de lectura, escritura y ejecución
del archivo a user1, que no es el propietario del archivo, la ACL muestra que el
propietario del archivo tiene acceso de lectura, escritura y ejecución del archivo FileX.
Los miembros del grupo propietario poseen acceso de lectura y escritura, otros tienen
acceso de lectura y user1 tiene acceso de lectura, escritura y ejecución. Sin embargo,
los bits de modo UNIX muestran rwxr-xrwx, lo que significa que al menos un usuario
que no es el propietario del archivo tiene acceso de lectura, escritura y ejecución.
Aunque parezca que todos los demás usuarios cuentan con acceso completo al
archivo FileX, únicamente user1 dispone de acceso completo, ya que es el único
acceso de control es la ACL, no los bits de modo UNIX.
Sincronización automática
Cuando se activan las políticas MIXED y MIXED_COMPAT para un objeto del file
system, se sincronizan automáticamente la ACL y los bits de modo UNIX. Los cambios
en una ACL generan modificaciones en los bits de modo y los cambios en los bits
de modo regeneran la ACL.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
27 de 80
La Tabla 4 en la página 28 explica la manera en que la política de control de acceso
MIXED traduce las ACLs y los bits de modo UNIX durante la sincronización.
Tabla 4
Política de control de acceso MIXED
Traducción de bits de modo UNIX en ACLs
Traducción de ACLs en bits de modo
UNIX
Crea entradas de ACL para File Owner, Group
y Everyone basadas en los bits de modo de
Owner, Group y Other.
Traduce la opción ACL Allow, pero no la opción
ACL Deny.
Configura los permisos Delete o Change y
aplica la opción Take Ownership para el Owner
pero no para Everyone ni para otros grupos.
Genera los bits de modo de Owner a partir
de la entrada Owner, la ACE del archivo
o el directorio, y la ACE Everyone.
La Tabla 5 en la página 28 explica la manera en que la política de control de
acceso MIXED_COMPAT traduce las ACLs de Windows y los bits de modo UNIX
durante la sincronización automática.
Tabla 5
Política de control de acceso MIXED_COMPAT
Traducción de bits de modo UNIX en ACLs
Traducción de ACLs en bits de modo
UNIX
Crea solo dos entradas en la ACL: Owner
y Everyone.
Traduce la opción ACL Allow, pero no la opción
ACL Deny.
Crea una ACE Everyone a partir de los bits
de modo de Group, ya que los grupos no se
traducen con esta política.
Genera las ACEs None, Owner y Granted
en los bits de modo de Group y Other.
Ignora los bits de modo de Other y no los utiliza
para generar la ACL.
Configura los permisos Delete o Change y
aplica la opción Take Ownership para el File
Owner pero no para el grupo Everyone.
Mapping de permisos de ACL a bits de modo UNIX
La Tabla 6 en la página 29 muestra la manera en que las políticas de acceso MIXED
y MIXED_COMPAT asignan los permisos de archivos y directorios de ACL a los
derechos de archivos y directorios UNIX.
28 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Nota: Para MIXED y MIXED_COMPAT, asegúrese de que esté configurado el grupo
predeterminado de Windows, ya que Celerra Network Server usa este grupo para decidir
qué grupo primario UNIX le asignará al objeto del file system creado mediante CIFS.
Tabla 6
Traducción de permisos de archivos y directorios de ACL a derechos UNIX
Permisos de archivos
Permisos de directorios
R
R
W
Traverse Folder/Execute File
X
W
X
X
Read Data
X
Read Attributes
X
X
Read Extended Attributes
X
X
X
Write Data
X
Append Data
X
Write Attributes
X
X
Write Extended Attributes
X
X
Delete
X
X
Read Permissions
X
X
List Folders
X
Create Files
X
Create Folders
X
Delete Subfolders and Files
X
Nota: Cuando se utiliza Celerra como servidor NFSv4, algunos clientes NFSv4 pueden
colocar un signo más en la salida ls -l cuando el objeto del file system cuente con una ACL.
Ejemplo: rwxrw-r +
Mapping de bits de modo UNIX a permisos de ACL
La Tabla 7 en la página 29 muestra la manera en que las políticas de control de
acceso MIXED y MIXED_COMPAT asignan los bits de modo UNIX a los permisos de
ACL.
Tabla 7
Traducción de derechos UNIX a una ACL (página 1 de 2)
R
Traverse Folder/Execute File
List Folder
W
X
X
X
Administración de EMC Celerra para un entorno de múltiples protocolos
X
Versión 5.6
29 de 80
Tabla 7
Traducción de derechos UNIX a una ACL (página 2 de 2)
R
Read Data
X
Read Attributes
X
Read Extended Attributes
X
W
Create Files/Write Data
X
Create Folders/Append Data
X
Write Attributes
X
Write Extended Attributes
X
Delete Subfolders and Files
X
X
Delete
Read Permissions
X
X
X
Change Permissions
Take Ownership
Reglas de herencia
La Tabla 8 en la página 30 explica las reglas de herencia para las políticas de
acceso NATIVE, UNIX, NT y SECURE.
Tabla 8
Reglas de herencia de NATIVE, UNIX, NT y SECURE
Protocolo
Reglas
CIFS
Cuando un cliente CIFS crea un objeto de file system:
• Se hereda la ACL del directorio principal (si la hubiere).
• El conjunto umask determina los bits de modo UNIX del recurso
compartido. La umask del recurso compartido se configura mediante
la opción umask del comando server_export.
NFS
Cuando un cliente NFS crea un objeto de file system:
• Se hereda la ACL del directorio principal (si la hubiere).
• La umask del usuario determina los bits de modo UNIX.
Nota: Los clientes NFS v4 pueden configurar los bits de modo o la ACL,
o ambos, en el momento en que crean el archivo o el directorio; dicha
configuración prevalecerá sobre la herencia y la umask.
30 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Tabla 8
Reglas de herencia de NATIVE, UNIX, NT y SECURE
Protocolo
Reglas
Nota: El valor umask se especifica como un valor octal y se determina mediante operaciones XOR
con los permisos de 644 para archivos y 755 para directorios. Los valores comunes incluyen 002,
que brinda acceso completo al usuario, al propietario o al grupo (y capacidad de búsqueda en
directorios) y acceso de lectura a otros, o 022 (opción predeterminada), que brinda acceso total al
usuario o al propietario y permisos de lectura (y capacidad de búsqueda en directorios), pero no de
escritura, al grupo o a otros. Para cambiar el valor umask predeterminado, use el parámetro
share.default.umask.
La Tabla 9 en la página 31 explica las reglas de herencia para las políticas de control
de acceso MIXED y MIXED_COMPAT.
Tabla 9
Reglas de herencia MIXED y MIXED_COMPAT
Protocolo
Reglas
CIFS
• Cuando un cliente CIFS crea un objeto de file system, si se encuentra
configurado el indicador de herencia y el directorio principal del objeto
cuenta con una ACL, el objeto del file system heredará la ACL y se crearán
permisos de bits de modo UNIX basados en la traducción de ACL.
• Si el directorio principal no cuenta con una ACL, los permisos UNIX se
configuran en función del valor umask* y se genera una ACL basada en
dichos valores.
NFS
• Los bits de modo UNIX se basan en el valor umask.1
• Se crea una ACL a partir de los bits de modo UNIX.
Nota: Los clientes NFS v4 pueden configurar los bits de modo o la ACL en
el momento en que crean el archivo o el directorio; dicha configuración
prevalecerá sobre la herencia y la umask.
1El valor umask se especifica como un valor octal y se determina mediante operaciones XOR con
los permisos predeterminados de 644 para archivos y 755 para directorios.
Backups y restores de objetos de file systems
Las herramientas de backup de file systems guardan las ACLs y los derechos UNIX
con sus respectivos atributos, y realizan restores de ellos. Para los backups de
Network Data Management Protocol (NDMP) y los backups de red CIFS, solo se
realizan backups y restores de los permisos de ACLs, que determinan los derechos
UNIX. Para un backup de NFS, solo se realizan backups y restores de los derechos
UNIX, que determinan los permisos de ACLs. En consecuencia, es posible que las
ACEs más complejas de las ACLs se pierdan durante un backup de NFS.
Use NDMP para realizar backups y restores de file systems de múltiples
protocolos, ya que los backups de red realizados mediante NFS o CIFS solo
capturan un conjunto de metadatos de un file system de múltiples protocolos.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
31 de 80
Configuración de una política de control de acceso
Si el file system actualmente cuenta con una política de control de acceso de
NATIVE, NT, UNIX o SECURE y se vuelve a montar con MIXED o MIXED_COMPAT,
realice una "Migración a MIXED y MIXED_COMPAT" en la página 32 después de
completar la ejecución de este comando.
Nota: Siempre controle las políticas activas de control de acceso antes de ejecutar este comando.
Acción
Para configurar la política de control de acceso para un file system, utilice la siguiente sintaxis de
comandos:
$ server_mount <movername> -o
accesspolicy=NT|UNIX|SECURE|NATIVE|MIXED|MIXED_COMPAT <fs_name>
<mount_point>
donde:
<movername> = nombre del Data Mover o VDM
<fs_name> = nombre del file system que se monta
<mount_point> = nombre del punto de montaje
Un <mount_point> debe comenzar con una barra diagonal (/).
Ejemplo:
Para configurar la política de control de acceso en NT para el file system ufs1 en server_2, escriba:
$ server_mount server_2 -o accesspolicy=NT ufs1 /ufs1
Salida
server_2 : done
Migración a MIXED y MIXED_COMPAT
Con las políticas de acceso NATIVE, NT, UNIX y SECURE, Celerra Network Server
puede almacenar permisos UNIX y Windows para cada archivo y cada directorio
de un file system. Con estas políticas, una modificación realizada en un conjunto
de permisos no afecta el otro conjunto. En consecuencia resultado, es improbable
que los permisos Windows y UNIX sean consistentes entre sí.
Cuando se vuelve a montar un file system con MIXED o MIXED_COMPAT con una
política de control de acceso original de NATIVE, NT, UNIX o SECURE, es posible
que sus archivos y directorios existentes aún tengan permisos no sincronizados.
El comando nas_fs -translate permite que el file system sincronice los permisos
UNIX y Windows de cada archivo y directorio del file system, como se explica en
"Mapping de permisos de ACL a bits de modo UNIX" en la página 28 y en
"Mapping de bits de modo UNIX a permisos de ACL" en la página 29.
32 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
!
!
PRECAUCIÓN
Es posible que la migración a MIXED o a MIXED_COMPAT cambie los derechos
existentes en algunos objetos del file system. Ejecute la función de traducción
únicamente si el entorno de múltiples protocolos requiere la sincronización
automática de los bits de modo UNIX y las entradas de ACL, o si emplea NFSv4
para acceder a los datos.
La Tabla 10 en la página 33 explica la manera en que se traducen los permisos
Windows y UNIX a MIXED o MIXED_COMPAT mediante NT, UNIX, NATIVE o
SECURE como política de origen. La política de origen le indica a Celerra cuál es
el conjunto de atributos de permisos (ACL o bits de modo) desde el que deben
derivarse los permisos al migrar a MIXED o MIXED_COMPAT. No necesariamente
establece una asociación con la política empleada anteriormente por el objeto del
file system.
La política de origen se especifica en la opción -from del comando nas_fs -translate.
Por ejemplo, si se especifica UNIX para la opción -from, se vuelven a generar
todas las ACLs a partir de los bits de modo.
Tabla 10 Migración a MIXED o MIXED_COMPAT
Políticade origen
Acción de sincronización
NATIVE y NT
Si el objeto del file system cuenta con una ACL, los derechos UNIX se
derivan de la ACL, como se muestra en la Tabla 6 en la página 29. Si un
objeto no cuenta con una ACL, la ACL se genera a partir de los bits de
modo, que no presentan modificaciones.
UNIX
Todas las ACLs se vuelven a generar a partir de los bits de modo. El
control de acceso no se cambia para los usuarios UNIX. Dado que el
modelo de seguridad de UNIX no es tan flexible como el modelo de
seguridad de Windows, es posible que se pierda información de ACL
durante la migración.
SECURE
Se comprueban y se almacenan las ACLs y los bits de modo. Se
fusionan los bits de modo con la ACL mediante la adición de tres ACEs:
OWNER, GROUP y OTHER, en caso de que no existan. Si existe alguna
de estas ACEs, se fusiona con los derechos UNIX correspondientes.
Antes de realizar la sincronización
Dado que no es posible deshacer el proceso de sincronización, primero realice
un backup del file system. Siempre compruebe la política de control de acceso
configurada en el file system antes y después de ejecutar el comando de
traducción. El file system se debe montar como MIXED o MIXED_COMPAT antes
de ejecutar este comando. De lo contrario, se rechaza el comando. El file system
que se traducirá debe ser un objeto del file system UXFS montado como
lectura/escritura.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
33 de 80
Ejecución de la sincronización
Después de volver a montar un objeto de file system a MIXED o MIXED_COMPAT,
ejecute el comando nas_fs -translate para sincronizar los permisos UNIX y Windows
en un file system.
La migración se realiza desde:
◆
NT, NATIVE, UNIX o SECURE a MIXED o MIXED_COMPAT
◆
MIXED a MIXED_COMPAT
◆
MIXED_COMPAT a MIXED
Nota: La política de control de acceso que se especifica en la opción -from le indica a Celerra qué
permisos (UNIX o Windows) utilizar como política maestra durante la traducción, como se explica en
la Tabla 10 en la página 33.
Acción
Para sincronizar los permisos UNIX y Windows en un file system, utilice la siguiente sintaxis
de comandos:
$ nas_fs -traduce <fs_name> -access_policy start -to {MIXED}
-from {NT|NATIVE|UNIX|SECURE}
donde:
<fs_name> = nombre del file system
Ejemplo:
Para sincronizar los permisos UNIX y Windows para ufs1 en server_2 y volver a generar las
ACLs basadas en bits de modo UNIX, escriba:
$ nas_fs -translate ufs1 access_policy start -to MIXED -from UNIX
Salida
server_2 : done
34 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Comprobación del estado de traducción
Acción
Para configurar el estado de traducción de un file system, utilice la siguiente sintaxis de
comandos:
$ nas_fs -translate <fs_name> -access_policy status
donde:
<fs_name> = nombre del file system traducido
Ejemplo:
Para comprobar el estado de traducción de ufs1, escriba:
$ nas_fs -translate ufs1 -a status
Salida
Notas
status=In progress
percent_inode_scanned=68
1097154093: ADMIN: 4: Command
succeeded: acl database=/ufs1
convertAccessPolicy status
• Si se produjo un error en la traducción,
compruebe si el file system se montó como
MIXED o como MIXED_COMPAT.
• Si la traducción no se completa debido a una
falla del sistema, vuelva a ejecutar el comando.
Restablecimiento de MIXED y MIXED_COMPAT
Es posible restablecer en NT, NATIVE, UNIX o SECURE la política de control de
acceso MIXED o MIXED_COMPAT de un objeto de file system; para eso, se debe
volver a montar el objeto del file system con la política de acceso deseada. No se
producen modificaciones en los permisos de las ACLs ni en los bis de modo UNIX,
a menos que se aplique la nueva política derechos de acceso y que las ACLs y los
bits de modo se vuelvan independientes con la primera modificación..
Acción
Para restablecer la política de control de acceso MIXED o MIXED_COMPAT de un file system,
utilice la siguiente sintaxis de comandos:
$ server_mount <movername> -o
accesspolicy=NT|UNIX|SECURE|NATIVE|MIXED|MIXED_COMPAT <fs_name>
<mount_point>
donde:
<movername> = nombre del Data Mover
<fs_name> = nombre del file system que se monta
<mount_point> = nombre del punto de montaje, que comienza con una barra diagonal (/)
Ejemplo:
Para restablecer la política de control de acceso en UNIX para el file system ufs1 en server_2,
escriba:
$ server_mount server_2 -o accesspolicy=UNIX ufs1 /ufs1
Salida
server_2 : done
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
35 de 80
Generación de una credencial de Windows NT
La Figura 4 en la página 36 detalla la manera en que Celerra Network Server
genera una credencial de Windows NT después de que un cliente UNIX solicita
acceso a un objeto del file system.
¿Está
el UID/GID
en la memoria
caché de
credenciales
NT?
Sí
¿Caducó
el registro
de fecha y
hora TTL?
No
Realice
verificación de
acceso
No
Sí
¿Hay un
UID/GID que
coincida con
el SID?
Sí
Cree
credenciales NT
Inserte una
nueva credencial
NT en la
memoria caché
No
Busque el
nombre asociado
al UID
¿Puede
recuperar el
SID del DC?
Sí
No
Inserte la
entrada “mapping
failed” en la
memoria caché
CNS-000536
Figura 4 Creación de una credencial de Windows NT
Procesamiento de una credencial de Windows NT
Para procesar una credencial de Windows NT, Celerra Network Server realiza los
siguientes pasos:
Paso
1.
Acción
Comprueba si el ID de usuario de UNIX se encuentra en la memoria caché de la
credencial de Windows NT:
Si el ID de usuario no se encuentra en la memoria caché, continúa con el paso 2.
Si el ID de usuario se encuentra en la memoria caché, comprueba el vencimiento del
registro de fecha y hora de la credencial de Windows NT. Si ya venció, continúa con el
paso 2; si no, continúa con el paso 7.
2.
36 de 80 Versión 5.6
Intenta asignar el ID de usuario al SID de Windows.
Administración de EMC Celerra para un entorno de múltiples protocolos
Paso
Acción
3.
Si no encuentra una coincidencia:
• Busca un nombre asociado con el UID. Este nombre ayuda a recuperar el SID de su
controlador de dominio mediante el uso del dominio predeterminado de Windows del
parámetro nfs NTcred.winDomain o la extensión de dominio recuperada del NIS, o el
archivo de contraseña local del Data Mover.
• Si no encuentra un SID, inserta una entrada de mapping fallido en la memoria caché.
En este caso, se usa la credencial de UNIX enviada en la solicitud de NFS para control
de acceso. Esto previene que el sistema acceda continuamente al controlador de
dominio en busca de una coincidencia de SID.
4.
Cuando encuentra una coincidencia, recupera la lista de grupos del usuario del Domain
Controller. Este puede ser el dominio del Data Mover o un dominio confiable.
5.
Reemplaza la credencial de UNIX con la nueva credencial de Windows NT.
6.
Inserta la credencial de Windows NT en la memoria caché para que los clientes UNIX
realicen control de acceso.
7.
Realiza control de acceso.
Acceso a un dominio confiable mediante Windows 2000
Para Windows 2000, el acceso a un dominio confiable requiere la configuración de
derechos adicionales para el servidor CIFS que recupera la lista de grupos a los que
pertenece un usuario. Este servidor debe obtener el contenido de la lista y derechos
de lectura para todas las propertiedades.
Lleve a cabo la siguiente tarea para configurar los derechos del servidor CIFS:
Paso
Acción
1.
Use la MMC para usuarios y computadoras de Active Directory de Microsoft en el modo
experto.
2.
Desde el menú, seleccione las funciones View (Ver) > Advanced (Avanzadas).
3.
Haga clic con el botón secundario en el nombre del domino y seleccione Security
(Seguridad) > Advanced (Avanzadas).
4.
Conceda los siguientes derechos:
• Para un nombre NetBIOS del Data Mover: Everyone (Todos) o Anonymous
(Anónimo)
• Para un nombre de computadora del Data Mover: serverDomain\Domain Computers
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
37 de 80
Configuración del dominio predeterminado de Windows
El parámetro nfs NTcred.winDomain especifica el nombre del dominio predeterminado
de Windows que usarán los usuarios de NFS que accedan a un file system en el
que se use la opción ntcredential. Se usa el nombre si existen diversos SIDs que
coincidan con el UID de UNIX del usuario o si el mapping inverso de UID a nombre
arroja un nombre de usuario ambiguo.
Nota: Los nombres de parámetros y funcionalidades distinguen mayúsculas y minúsculas. Este
parámetro no se aplica NFSv4, pero se puede usar con NFSv2 y NFSv3.
Acción
Para configurar el dominio predeterminado de Windows, utilice la siguiente sintaxis de comandos:
$ server_param <movername> -facility nfs -modify NTcred.winDomain -value
<new_value>
donde:
<movername> = nombre del Data Mover
<new_value> = un nombre de dominio NETBIOS válido
Ejemplo:
Para configurar el dominio predeterminado de Windows en nasdocs.emc.com, escriba:
$ server_param server_2 -facility nfs -modify NTcred.winDomain
-value nasdocs.emc.com
Salida
server_2 : done
Definición de memoria caché para credenciales de Windows NT
La memoria caché para credenciales de NT es una memoria caché de espacio limitado
que contiene credenciales de Windows NT y todas las entradas de UID que no es
posible asignar a SIDs.
Cada entrada posee un vencimiento de registro de fecha y hora. El tamaño de la
memoria caché (la cantidad máxima de entradas) se configura con el parámetro nfs
NTcred.size.
Nota: Si se detiene el servicio de CIFS, los usuarios conectados pueden seguir
usando la memoria caché durante 20 minutos. Al reiniciar CIFS, se eliminan todas
las entradas de mapping fallido de la memoria caché.
Acción
Para configurar el tamaño de la memoria caché para credenciales de Windows NT, utilice la
siguiente sintaxis de comandos:
$ server_param <movername> -facility nfs -modify NTcred.size -value
<new_value>
donde:
<movername> = nombre del Data Mover
<new_value> = la cantidad máxima de entradas en la memoria caché. El valor predeterminado
es 1009.
Ejemplo:
Para configurar en 1.000 el tamaño de la memoria caché para credenciales de Windows NT, escriba:
$ server_param server_2 -facility nfs -modify NTcred.size
-value 1009
38 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Salida
server_2 : done
Configuración del vencimiento del registro de fecha y hora
Los nombres de parámetros y funcionalidades distinguen mayúsculas y minúsculas.
Este parámetro no se aplica NFSv4, pero se puede usar con NFSv2 y NFSv3.
Acción
Para configurar el vencimiento del registro de fecha y hora de una entrada de Windows NT
en la memoria caché para credenciales de NT, utilice la siguiente sintaxis de comandos:
$ server_param <movername> -facility nfs -modify NTcred.TTL -value
<new_value>
donde:
<movername> = nombre del Data Mover
<new_value> = la cantidad de minutos. El valor predeterminado es 20 minutos.
Ejemplo:
Para configurar el vencimiento del registro de fecha y hora de las credenciales de Windows NT
en 30 minutos, escriba:
$ server_param server_2 -facility nfs -modify NTcred.TTL
-value 30
Salida
server_2 : done
Generación de credenciales de Windows NT
La función de credenciales de Windows NT es para file systems de múltiples
protocolos. Utilice esta función únicamente con políticas de control de acceso
de MIXED y MIXED_COMPAT, NT y SECURE.
Acción
Para generar credenciales de Windows NT para un objeto de file system, utilice la siguiente
sintaxis de comandos:
$ server_mount <movername> -o
accesspolicy=NT|UNIX|SECURE|NATIVE|MIXED|MIXED_COMPAT,ntcredential
<fs_name> <mount_point>
donde:
<movername> = nombre del Data Mover o VDM
<fs_name> = nombre del file system que se monta
<mount_point> = nombre del punto de montaje
Ejemplo:
Para configurar la política de control de acceso en NT y generar la credencial de Windows NT
para el file system ufs1 en server_2, escriba:
$ server_mount server_2 -o accesspolicy=NT,ntcredential ufs1 /ufs1
Salida
server_2 : done
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
39 de 80
Inclusión de grupos UNIX en una credencial de Windows NT
Cuando el usuario accede a Celerra por medio de CIFS, es posible configurar el
sistema Celerra para incluir los grupos de UNIX del usuario en su credencial de
Windows. Esta es una adición a sus grupos de Windows. Celerra incluirá los
grupos de UNIX del usuario en su credencial de Windows si se configura en 1 el
parámetro cifs acl.extendExtraGid. No existe un límite para la cantidad de grupos
que puede contener una credencial de Windows NT.
Este parámetro se aplica únicamente en entornos de múltiples protocolos con un
archivo NIS o un archivo .etc/group en el Data Mover. Los grupos UNIX se recuperan
desde los servicios de nombres de UNIX configurados en el Data Mover, algunos
ejemplos de archivos de grupos locales, NIS, LDAP, etc., mediante el uso del nombre
de usuario sin la extensión .domain.
Nota: Los nombres de parámetros y funcionalidades distinguen mayúsculas y minúsculas.
Acción
Para incluir el grupo UNIX del usuario en su credencial de Windows NT, utilice la siguiente sintaxis
de comandos:
$ server_param <movername> -facility cifs -modify acl.extendExtraGID value <new_value>
donde:
<movername> = nombre del Data Mover
<new_value> = 1 (para activar el mapping) o 0 (para desactivar el mapping).
Ejemplo:
Para combinar los grupos de UNIX y Windows del usuario a fin de para generar una credencial
de Windows NT, escriba:
$ server_param server_2 -facility cifs -modify acl.extendExtraGid
-value 1
Salida
server_2 : done
40 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Uso exclusivo de permisos UNIX para control de
acceso
Se debe configurar el comando cifs acl.unixCheckAcl para realizar el control de
acceso en los permisos UNIX solo cuando la política de acceso del file system esté
configurada para UNIX. Cuando este parámetro se configura en cero para un Data
Mover, las ACLs de Windows nunca se activan cuando la política de acceso del file
system se encuentra configurada para UNIX.
Utilice este comando para asegurarse de que:
◆
Nunca se controlen las ACLs de Windows cuando la política de acceso del file
system esté configurada para UNIX.
Nota: Los nombres de parámetros y funcionalidades distinguen mayúsculas y minúsculas. El
parámetro cifs acl.unixCheckAcl afecta solo los file systems de un Data Mover configurados para
utilizar la política de acceso UNIX.
Acción
Para especificar que solo se controlen los permisos UNIX (cuando la política de acceso se
encuentre configurada para UNIX), utilice la siguiente sintaxis de comandos:
$ server_param <movername> -facility cifs -modify ac1.unixCheckAc1 value <new_value>
donde:
<movername> = nombre del Data Mover
<new_value> = 0 (para descartar controles de ACLs) o 1 (para controlar ACLs)
Ejemplo:
Para asegurarse de que solo se controlen los permisos UNIX (cuando la política de acceso se
encuentre configurada para UNIX), esbriba:
$server_param server_2 -facility cifs -modify acl.unixCheckAcl
-value 0
Salida
server_2 : done
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
41 de 80
Configuración de política de bloqueo de archivos
El bloqueo de archivos garantiza la integridad de los archivos cuando más de un
usuario intenta acceder a un mismo archivo. Los bloqueos de archivos administran
los intentos de lectura, escritura o bloqueo de los archivos que se encuentran en
uso por otros usuarios.
Los protocolos NFS y CIFS implementan las funciones del bloqueo de archivos de
diferentes maneras, como se muestra en la Tabla 11 en la página 42.
Tabla 11 Diferencias entre la versión 2 o la versión 3 de NFS y bloqueos de CIFS o NFSv4
Bloqueos en un entorno de versión
2 o versión 3 de NFS
Bloqueos en un entorno CIFS o NFSv4
Utilizan bloqueo de lectura y bloqueos
exclusivos (de escritura).
CIFS utiliza bloqueos oportunistas (oplocks) y
modos de denegación de acceso. Las delegaciones
son el equivalente de oplocks en NFSv4.
Los bloqueos de NFS son bloqueos de
advertencia, pero no obligatorios. Un bloqueo
de advertencia no es un bloqueo activado
(por lo tanto, no afecta el acceso de lectura y
escritura), pero advierte a los demás clientes
que el archivo ya se encuentra en uso.
Los protocolos CIFS y NFSv4 activan bloqueo
estricto de archivos y acceso sin bloqueo a
archivos. Los bloqueos de CIFS y NFSv4 son
obligatorios. Cuando un proceso de CIFS o NFSv4
bloquea un archivo, no se permiten a otros usuarios
ciertos tipos de acceso a archivos, según el tipo de
bloqueo impuesto.
Un cliente CIFS o NFSv4 puede bloquear un archivo
mediante:
• Una denegación de acceso de lectura o escritura
en todo el archivo.
• Un rango de bloqueo en una porción del archivo.
En un entorno de múltiples protocolos, los usuarios de CIFS y NFS pueden configurar
los bloqueos de un archivo. Debido a que los bloqueos de NFS (versión 2 o versión
3) y los modos de denegación, los oplocks o las delegaciones de CIFS o NFSv4 no
son directamente equivalentes, Celerra Network Server debe traducir los modos de
denegación, los oplocks y las delegaciones de CIFS o NFSv4 a bloqueos de NFS
(versión 2 o versión 3) y, asimismo, los bloqueos de NFS (versión 2 o versión 3) se
deben traducir a los modos de denegación, los oplocks o las delegaciones de CIFS
o NFSv4. Por ejemplo:
◆
Una solicitud de modo de denegación de lectura o escritura de CIFS se traduce
en un bloqueo exclusivo de lectura o escritura de NFS (versión 2 o versión 3).
◆
Un bloqueo de lectura compartida de NFS (versión 2 o versión 3) se traduce en
un modo de denegación de escritura de CIFS.
Para controlar la interacción del bloqueo de archivos de CIFS y NFS, Celerra Network
Server brinda tres políticas de bloqueo diferentes que pueden especificarse al
montar un file system. Estas políticas se definen en la Tabla 12 en la página 43.
Estas políticas se utilizan para un entorno de múltiples protocolos e indican el
impacto del comportamiento del bloqueo sobre los clientes NFS para el caso del
bloqueo simultáneo de archivos NFS y CIFS.
42 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Tabla 12 Políticas de bloqueo de archivos de Celerra Network Server
nolock1
wlock2
rwlock3
Sin bloqueo: trata todos los
bloqueos como bloqueos de
advertencia para clientes NFS
(v2 o v3) (configuración
predeterminada, menor nivel
de seguridad).
Bloqueo de escritura: activa
los bloqueos de escritura de
CIFS o NFSv4 para el acceso
de clientes NFSv2 o NFSv3.
Bloqueo de lectura o
escritura: activa los bloqueos
de lectura y escritura d CIFS o
NFSv4 para el acceso de
clientes NFSv2 o NFSv3
(mayor nivel de seguridad).
Solicitudes de bloqueo: Si un
cliente CIFS o NFS bloquea
un archivo, ningún otro cliente
puede bloquear dicho archivo.
Solicitudes de bloqueo: Si un
cliente CIFS o NFS bloquea
un archivo, ningún otro cliente
puede bloquear dicho archivo.
Solicitudes de bloqueo: Si un
cliente CIFS o NFS bloquea
un archivo, ningún otro cliente
puede bloquear dicho archivo.
Solicitudes de acceso:
• Los clientes CIFS ignoran
los bloqueos configurados
por NFS.
• Los clientes NFSv2 o
NFSv3 pueden leer o
escribir los archivos
bloqueados por CIFS o
NFSv4.
Solicitudes de acceso:
• Los clientes CIFS que
deniegan acceso
simultáneo de escritura no
pueden abrir los archivos
bloqueados por NFS para
acceso exclusivo.
• Los clientes NFSv2 o
NFSv3 pueden leer los
archivos bloqueados por
CIFS o NFSv4, pero no
escribirlos ni eliminarlos.
Solicitudes de acceso:
• Los clientes CIFS que
deniegan acceso
simultáneo de lectura o
escritura no pueden abrir
los archivos bloqueados
por NFS para acceso
exclusivo o compartido.
• Los clientes NFSv2 o NFSv3
no pueden leer, escribir ni
eliminar los archivos
bloqueados por CIFS.
1. Nolock es la única política de bloqueo que soportan los file systems MPFS.
2. Podrían tener problemas las aplicaciones NFSv2 o NFSv3 que no esperan conflictos de bloqueo (permiso
denegado) en las operaciones de lectura o escritura.
3. Podrían tener problemas las aplicaciones NFSv2 o NFSv3 que no esperan conflictos de bloqueo (permiso
denegado) en las operaciones de lectura o escritura.
Nota: Celerra Network Server solo activa los bloqueos de archivos (cuando está configurado
para hacerlo) si la aplicación del cliente utiliza bloqueos. Algunas aplicaciones simples,
como Windows Notepad o Wordpad, UNIX more y vi no utilizan bloqueo de archivos. Los
archivos creados con estas aplicaciones no se bloquean y pueden abrirse y editarse por
otra aplicación aun cuando se monta un file system con wlock o rwlock.
Montaje del file system
Cuando se monta un file system, se puede especificar la política para controlar la
interacción del bloqueo de CIFS y NFS. La opción de bloqueo de archivos elegida
dependerá de los requerimientos del negocio y de si el entorno de red es solo CIFS
o es un entorno de múltiples protocolos (combinación de CIFS y NFS).
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
43 de 80
Nota: Un mount_point debe comenzar con una barra diagonal (/). Managing EMC Celerra Volumes
and File Systems proporciona información más detallada sobre la creación de un file system y un
punto de montaje.
Acción
Para especificar el bloqueo del file system, utilice la siguiente sintaxis de comandos:
$ server_mount <movername> -o nolock|wlock|rwlock <fs_name>
<mount_point>
donde:
<movername> = nombre del Data Mover
<fs_name> = nombre del file system que se monta
<mount_point> = nombre del punto de montaje
Ejemplo:
Para montar el file system ufs1 con bloqueo de lectura o escritura, escriba:
$ server_mount server_2 -o rwlock ufs1 /ufs1
Salida
server_2: done
44 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Visualización y configuración de permisos UNIX
desde un cliente Windows
La capacidad de los usuarios de Windows de ver y modificar los permisos UNIX se
encuentra desactivada como opción predeterminada. El parámetro cifs acl.extacl
permite a los usuarios Windows ver y configurar los permisos UNIX en archivos y
directorios, y activa capacidades especiales para la administración de ACLs, como
se explica en EMC Celerra Network Server Parameters Guide.
Al configurar el parámetro cifs acl.extacl, los permisos UNIX aparecerán en el
cuadro de diálogo Propiedades de Windows del archivo o directorio, como se
muestra en la Figura 5 en la página 45.
Figura 5 Cuadro de diálogo Propiedades con permisos UNIX
Consideraciones
Antes de visualizar y modificar los permisos UNIX, considere lo siguiente:
◆
Debido a que los permisos de directorio UNIX no se heredan (opción configurada
para “This folder only”), solo aparecerán en el área Advanced (Avanzadas). Por
ese motivo, es mejor visualizar y editar los permisos de carpetas mediante el
uso del área Advanced (Avanzadas).
◆
Cuando se modifican los permisos UNIX desde Windows, si se desactiva la casilla
de verificación Allow (Permitir) no se borran todas las entradas (cuando se
visualizan desde la configuración Avanced [Avanzadas]). Para borrar todas las
entradas, se debe activar la casilla Deny (Denegar).
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
45 de 80
◆
Si activa la casilla de verificación Allow Inheritable permissions (Permitir que los
permisos heredables del primario se propaguen a este objeto), es posible que
obtenga resultados inesperados al modificar los permisos UNIX desde Windows.
Si se activa esta casilla de verificación, es posible que los permisos UNIX tomen
valores predeterminados desde objetos principales.
Activación de capacidades especiales para la administración
de ACLs
Aplique este procedimiento para activar capacidades especiales de administración
de ACLs.
El EMC Celerra Network Server Parameters Guide explica el comando cifs
acl.extacl y sus valores.
Existen solo dos tipos de capacidades para ACL:
◆
Backup o restore de atributos UNIX específicos.
◆
Visualización o modificación de derechos de acceso de UNIX.
Acción
Para activar una capacidad específica de administración de ACLs, utilice la siguiente
sintaxis de comandos:
$ server_param <movername> -facility cifs -modify extac1 -value
<new_value>
Donde:
<movername> = nombre del Data Mover
<new_value> = la lista de bits está compuesta por siete bits binarios (0 a 6).
0 = se presentan los metadatos UNIX asociados con los archivos y
directorios al cliente de backup CIFS.
1 = los clientes Windows pueden visualizar y modificar los permisos UNIX.
2 = las aplicaciones de backup de red de CIFS pueden realizar backup y
restores de los atributos de seguridad de los directorios y archivos UNIX.
3 = las aplicaciones de backup de la red CIFS pueden realizar backup y
restores de los enlaces simbólicos de UNIX.
4 = las aplicaciones de backup de red CIFS pueden realizar backup y
restores de los tres nombres de archivos y directorios.
5 = permite a los clientes NFS v2 y v3 visualizar y modificar las ACLs
mediante el uso de la herramienta del cliente emcsetsd.
6 = modifica el comportamiento de bit 1. Los derechos UNIX que se aplican
son los derechos concedidos, con exclusión de los derechos denegados
por la ACL discrecional.
Ejemplo:
Para permitir a los usuarios de Windows visualizar y modificar los permisos UNIX,
escriba:
$ server_param server_2 -facility cifs -modify extacl -value 1
Salida
server_2 : done
46 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Configuración y administración de soporte de DFS
Para configurar una raíz de DFS en un recurso compartido de CIFS, utilice la
herramienta de línea de comandos Microsoft dfsutil.exe o la herramienta MMC
DFS. Para dfsutil.exe, utilice el indicador opcional para operar con la API en lugar
del Registro de Windows.
Nota: Para utilizar un servidor CIFS solo como servidor DFS independiente (sin infraestructura
de dominios), se deberá crear con dfsutil.exe.
El contenido de la raíz de DFS se administra mediante el comando de Microsoft
dfscmd.exe (por ejemplo, creación y eliminación de enlaces). No es posible eliminar
una estructura de árbol de DFS mediante este comando.
Nota: No establezca una raíz de DFS en un objeto del file system con una política de control
de acceso de UNIX o SECURE, ya que ninguno de los componentes del enlace de DFS se
crea con derechos UNIX.
Las herramientas dfsutil.exe y dfscmd.exe se incluyen en las Herramientas de soporte
de Windows 2000 o Windows Server 2003.
Nota: Cuando se envía una consulta al DFS en la red mediante la ejecución del comando
dfsutil /siteinfo:<cifs_server_name> que se incluye con las Herramientas de soporte
de Microsoft Windows 2000, el cliente se conecta al srvsvc pipe y emite un comando
NetrDfsManager ReportSiteInfo. Celerra arroja un error DCE RPC Fault of 0x1c010002
o Range Error. Para evitar este error, utilice el comando Microsoft Windows Server 2003
dfsutil /sitename:<cifs_server_name>.
Antes de configurar y administrar el soporte de DFS
Realice las siguientes tareas antes de configurar una raíz de DFS en un recurso
compartido de CIFS. Configuración de CIFS en Celerra proporciona instrucciones
en relación con estas tareas:
1. Configure el servidor CIFS en el Data Mover.
2. Inicie el servicio CIFS en el Data Mover, que automáticamente activa el soporte
de DFS.
3. En el servidor CIFS, configure un recurso compartido del file system para crear
una raíz de DFS; use la Tabla 13 en la página 47 como guía.
Tabla 13 Entornos DFS
DFS provisto de
Tipo de recurso
compartido
Cantidad de raíces de DFS
Windows 2000:
Recurso compartido local
Una
Equipo con Windows
Server 2003 y Windows XP:
Recurso compartido global
Múltiples
Es posible visualizar una raíz de
DFS en un recurso compartido
global desde un servidor CIFS
en el Data Mover.
Se recomienda esta opción, ya que
permite administrar múltiples raíces
de DFS en el mismo servidor CIFS.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
47 de 80
Creación de una raíz de DFS mediante dfsutil.exe
Paso
1.
Acción
Para crear una raíz de DFS en un recurso compartido global mediante dfsutil.exe en un
entorno de Windows Server 2003:
C:\>dfsutil /AddStdRoot /Server:DM2-ANA0-1-SA /Share:wl_root-1
Microsoft(R) Windows(TM) Dfs Utility Version 4.0
Copyright (C) Microsoft Corporation 1991-2001. Todos los derechos
reservados.
Indica que el comando DfsUtil se completó correctamente.
Creación de una raíz de DFS independiente mediante MMC DFS
Para crear una raíz de DFS mediante la herramienta MMC DFS:
Paso
1.
48 de 80 Versión 5.6
Acción
Inicie la herramienta New Root Wizard (Asistente para crear nueva raíz) desde
MMC DFS.
Administración de EMC Celerra para un entorno de múltiples protocolos
Paso
Acción
2.
En el cuadro de diálogo Host Server (Servidor host), especifique el servidor CIFS del
Data Mover que se usará como raíz de DFS.
3.
En el cuadro de diálogo Root Type (Tipo de raíz), seleccione Stand-alone root (Raíz
independiente).
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
49 de 80
Paso
4.
50 de 80 Versión 5.6
Acción
El cuadro de diálogo Root Name (Nombre de la raíz) muestra el path UNC a la raíz y al
recurso compartido. Escriba un nombre exclusivo para DFS root y agregue los
comentarios pertinentes.
Administración de EMC Celerra para un entorno de múltiples protocolos
Paso
5.
Acción
Si un nombre de raíz no corresponde a un recurso compartido existente que se haya
especificado con anterioridad, escriba el path al recurso compartido.
Una vez completada esta operación, aparecerá el mensaje Completing the New Root
Wizard (Finalización del Asistente para crear una nueva raíz).
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
51 de 80
Activación y desactivación de soporte de DFS
Después de iniciar el servicio CIFS, se activa el soporte de DFS como opción
predeterminada.
Para desactivar el soporte de DFS:
Paso
1.
Acción
Configure en cero la clave de Registro de Windows en el Data Mover con una herramienta
como RegEdit:
HKEY_LOCAL_MACHINE\SOFTWARE\EMC\DFS\Enable
2.
52 de 80 Versión 5.6
Detenga y reinicie el servicio CIFS.
Administración de EMC Celerra para un entorno de múltiples protocolos
Uso de wide links
Antes de crear wide links, considere lo siguiente:
◆
Los wide links se basan en la funcionalidad de Microsoft DFS. Antes de establecer
wide links, se deben cumplir los requerimientos de DFS, como se explica en
"Uso del Data Mover como servidor DFS" en la página 11.
◆
El destino del wide link deberá estar en una raíz de DFS, que es un recurso
compartido de CIFS o de Windows. Este recurso compartido puede ser local
o ubicarse en un servidor remoto. Pueden crearse tantos wide links como sea
necesario en el recurso compartido raíz.
◆
Dado que el DFS redirige únicamente directorios, se debe configurar un pathname
del directorio en el enlace de DFS usado para wide links. Durante la redirección
de los wide links, el sistema:
• Busca un enlace de DFS que coincida con el comienzo del path de destino
del enlace simbólico.
• Anexa el resto de este path al destino de DFS para la redirección final.
◆
Es posible configurar un wide link por cada Virtual Data Mover (VDM). Esto
permite dirigir un cliente Windows a tantas ubicaciones de directorio como
sean necesarias.
◆
Una vez configurados los wide links, aparece un enlace simbólico con un path
absoluto como directorio en lugar de un archivo en Windows Explorer.
◆
El path del enlace de DFS debe ser el mismo en Windows y en UNIX (en otras
palabras, el nombre UNIX de cada componente debe coincidir con el nombre
M256 de Windows).
◆
En un cliente NT4, no aparece la ficha Seguridad en el cuadro de diálogo
Propiedades para un archivo ubicado en un recurso compartido que soporte
wide links. Es posible puede configurar la seguridad mediante una herramienta
de seguridad, como cacls. De manera alternativa, administre las ACLs de
los archivos mediante archivos de un cliente de Windows 2000 o recursos
compartidos que no soporten wide links simbólicos. Puede haber dos recursos
compartidos diferentes en el mismo directorio, uno que soporte wide links y otro
que no, y el recurso compartido que no soporte wide links puede usarse para
administrar configuraciones de seguridad mediante clientes NT4.
◆
Si un cliente Windows está conectado a un recurso compartido de CIFS en una
raíz de DFS y se elimina dicho recurso compartido de DFS, es posible que el
cliente no tenga acceso al recurso. Debido a que la función de wide links se
basa en Microsoft DFS, esto también se aplica a los wide links. Esto ocurre
porque el cliente utiliza una memoria caché de DFS para realizar seguimientos
de todos los enlaces de DFS. Hasta que se agote el tiempo de espera de las
entradas de memoria caché del recurso compartido, los clientes Windows intentan
acceder al recurso compartido eliminado aunque este no exista en el DFS.
Para resolver esto:
• Espere a que se agote el tiempo de espera de las entradas de la memoria
caché del DFS.
• O desconecte el cliente del recurso compartido, limpie la memoria caché de
DFS del cliente mediante la herramienta de línea de comandos dfsutil/pktflush
de Microsoft y vuelva a conectar el recurso compartido.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
53 de 80
Pasos del proceso
Los siguientes pasos describen la manera en que un cliente Windows procesa la
función de wide links mediante el uso de DFS:
Paso
Acción
1.
El cliente abre un path que cuenta con un enlace simbólico absoluto.
2.
El servidor detecta un path de enlace absoluto y envía un error que indica
que el path no está cubierto. Este es un comportamiento típico de DFS.
3.
El cliente solicita las referencias de DFS de este path para determinar
dónde efectuar la conexión después.
4.
Desde la raíz de DFS en el Data Mover definido como base de datos
widelink en el registro de Windows del Data Mover, el servidor CIFS busca
un enlace que coincida con el comienzo del path de destino en el enlace
simbólico y determina el recurso compartido que se debe usar para la
resolución de wide links.
5.
El servidor CIFS envía las referencias de DFS que indican al cliente el
nuevo path.
Establecimiento de wide links
En el siguiente ejemplo, el file system w1_root-1 contiene el directorio user1 que
posee los enlaces simbólicos:
◆
enlace a fs_wslink-1\user1 en el Data Mover local
◆
enlace a fs_wlink-29\user1 en un Data Mover remoto
Ejemplo
el file system w1_root-1 existe en server_2:
$ server_export server_2 | grep -w "wl_root-1"
export "/wl_root-1"
share "wl_root-1" "/wl_root-1" maxusr=4294967295 umask=22
el directorio user1 se ubica en w1_root-1:
[user1@LINUX1PAG01 user1]$ pwd
/wl_root-1/user1
user1 cuenta con dos enlaces simbólicos UNIX a otros directorios en Data Movers
separados:
[user1@LINUX1PAG01 user1]$ ls -lhat
total 8.0K
drwxr-xr-x
3 root
root
0 Feb 2
drwxr-xr-x
3 user1
group-1001
1.0K Feb
-rw-r--r-1 user1
group-1001
0 Feb
lrwxrwxrwx
1 user1
group-1001
15 Feb
user1_on_fs_wlink-29 -> /wlink-29/user1
lrwxrwxrwx
1 user1
group-1001
14 Feb
user1_on_fs_wlink-1 -> /wlink-1/user1
drwxr-xr-x
2 user1
group-1001
80 Feb
54 de 80 Versión 5.6
13:19 ..
2 12:43 .
2 12:43 NFS_user_file
2 12:25
2 12:25
1 17:49 user1
Administración de EMC Celerra para un entorno de múltiples protocolos
Estos enlaces simbólicos hacen referencia a:
◆
user1 en fs_wlink-1 en el Data Mover local (server_2):
[user1@LINUX1PAG01 user1]$ mount | grep wlink-1
automount(pid26562) on /wlink-1 type autofs (rw,fd=5,pgrp=26562,minproto=2,maxproto=3)
dm2-ana0-1-sa:/wlink-1/user1 on /wlink-1/user1 type nfs (rw,addr=172.24.100.50)
◆
user1 en fs_wlink-29 en un Data Mover remoto (server_3):
[user1@LINUX1PAG01 user1_on_fs_wlink-29]$ mount | grep wlink-29
automount(pid26592) on /wlink-29 type autofs (rw,fd=5,pgrp=26592,minproto=2,maxproto=3)
vdm3-ana0-6-sa:/root_vdm_3/wlink-29/user1 on /wlink-29/user1 type nfs (rw,addr=172.24.100.58)
Desde Windows, los enlaces simbólicos de user1 se muestran como archivos:
C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1
Volume in drive \\dm2-ana0-1-sa\wl_root-1 is 102
Volume Serial Number is 0000-0014
Directory of \\dm2-ana0-1-sa\wl_root-1\user1
02/02/2005
02/02/2005
02/01/2005
02/02/2005
02/02/2005
02/02/2005
12:43 PM
<DIR>
.
12:23 PM
<DIR>
..
05:49 PM
<DIR>
user1
12:25 PM
14 user1_on_fs_wlink-1
12:25 PM
15 user1_on_fs_wlink-29
12:43 PM
0 NFS_user_file
3 File(s)
29 bytes
3 Dir(s) 52,867,235,840 bytes free
Creación de wide links
El siguiente procedimiento muestra cómo crear dos wide links que dirijan un cliente
Windows al directorio fs_wslink-1\user1 en el Data Mover local y al directorio
fs_wlink-29\user1 en el Data Mover remoto. Una vez creados los dos wide links,
el directorio user1 muestra estos enlaces simbólicos como directorios de Windows
y no como archivos, como se indicó anteriormente.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
55 de 80
Paso
1.
Acción
Inicie la herramienta MMC Distributed File System (Sistema de archivos distribuido
[DFS]).
Nota: Este procedimiento supone la activación del soporte de DFS (como opción
predeterminada) y la creación de las raíces de DFS, como se explica en "Uso del Data
Mover como servidor DFS" en la página 11.
56 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Paso
Acción
2.
Desde el cuadro de diálogo Action (Acción), seleccione Show Root (Mostrar raíz).
Escriba el nombre NetBIOS del servidor CIFS que se usa como raíz de DFS (en este
ejemplo, DM2-ANA0-1-SA) en el que se debe crear un wide link.
3.
El sistema muestra las raíces de DFS para DM2-ANA0-1-SA. Seleccione el la raíz de DFS
(en este ejemplo, \\DM2-ANA0-1-SA\w1_root-1) en la que se debe crear un wide link.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
57 de 80
Paso
4.
Acción
Haga clic con el botón derecho en \\DM2-ANA0-1-SA\w1_root-1 de la raíz de DFS
y seleccione New Link (Nuevo vínculo).
Aparece el cuadro de diálogo New Link (Nuevo vínculo), que muestra el path UNC a la
raíz DFS. Cada enlace que se crea debe corresponder a un recurso compartido de
CIFS o Windows.
5.
58 de 80 Versión 5.6
Escriba los valores de los campos Link name (Nombre de vínculo) y Path to target
(Ruta de acceso a destino [carpeta compartida]), que deben ser los mismos en
Windows y en UNIX (en otras palabras, el nombre UNIX de cada componente debe
coincidir con el nombre M256 de Windows), como se muestra en el siguiente ejemplo.
Este ejemplo muestra cómo crear el primer wide link, wlink-1\user1, para user1 en
wlink-1 en el Data Mover local.
Administración de EMC Celerra para un entorno de múltiples protocolos
Paso
6.
Acción
Cree el segundo enlace para el user1 en el Data Mover remoto; para esto, repita el
paso 5 y escriba los valores de los campos Nombre de vínculo y Ruta de acceso a
destino [carpeta compartida].
Este ejemplo muestra cómo crear el segundo wide link, wlink-29\user1, que dirige
a user1 en wlink-29.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
59 de 80
Paso
7.
Acción
Configure el servidor CIFS en la raíz de DFS en el Registro de Windows:
a. Configure el servidor CIFS y el recurso compartido de CIFS mediante el siguiente Registro:
HKEY_LOCAL_MACHINE\SOFTWARE\EMC\WideLink\Share
El Registro debe contener:
\\server_name\share_name
Donde:
• server_name es el nombre NetBIOS del servidor CIFS. Si se usa un recurso
compartido global, solo es necesario escribir el nombre del recurso compartido de
CIFS.
• share_name es el nombre del recurso compartido de CIFS o Windows.
A continuación, se muestra la clave de Registro para wl_root-1, que corresponde
a un recurso compartido global:
Windows Registry Editor Versión 5.00
[HKEY_LOCAL_MACHINE\Software\EMC\WideLink]
"Share"="wl_root-1"
b. Detenga el servicio CIFS.
c. Reinicie el servicio CIFS.
Si se actualiza el Registro con un nombre de recurso compartido que no se encuentre
en DFS, aparecen errores similares a los siguientes en server_log:
SMB: 3: Widelink:\\Global\w1_root-1 is not in DFS
SMB: 3: Widelink: error while updating from Registry 7
Si se configura el registro pero no la función de wide links, aparecerán en la pantalla
mensajes similares a los siguientes:
C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-1\
The network name cannot be found.
C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-29\
The network name cannot be found.
Una vez configurada la clave del Registro, aparecerán enlaces simbólicos como
directorios en Windows, que permiten a los usuarios leer el contenido de los dos
directorios siguientes:
Data Mover local:
C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-1\
Volume in drive \\dm2-ana0-1-sa\wl_root-1 is 102
Volume Serial Number is 0000-0014
Directory of \\dm2-ana0-1-sa\wl_root1\user1\user1_on_fs_wlink-1
02/02/2005
02/02/2005
02/01/2005
02/02/2005
11:07 AM
<DIR>
.
11:56 AM
<DIR>
..
07:08 PM
0 user1_NFS_file
10:27 AM
<DIR>
CIFS-user
1 File(s)
0 bytes
3 Dir(s) 52,867,260,416 bytes free
Data Mover remoto:
C:\>dir \\dm2-ana0-1-sa\wl_root-1\user1\user1_on_fs_wlink-29\
Volume in drive \\dm2-ana0-1-sa\wl_root-1 is 102
Volume Serial Number is 0000-0014
Directory of \\dm2-ana0-1-sa\wl_root1\user1\user1_on_fs_wlink-29
02/02/2005
02/01/2005
02/02/2005
60 de 80 Versión 5.6
05:11 AM
<DIR>
.
05:17 AM
<DIR>
..
05:11 PM
0 NFS_user1_wlink-29
1 File(s)
0 bytes
2 Dir(s) 52,867,268,608 bytes free
Administración de EMC Celerra para un entorno de múltiples protocolos
Visualización y configuración de ACLs de Windows
desde un cliente UNIX
Es posible ver y modificar la configuración de ACLs de Windows en un archivo o
directorio desde un cliente UNIX mediante las herramientas de línea de comandos
emcgetsd y emcsetsd. Estas herramientas son particularmente útiles para un
usuario UNIX que cuenta con acceso de lectura y escritura a un file system, pero
que no puede acceder a un archivo directorio por no contar con los derechos de
ACL pertinentes.
Nota: El file system se debe montar desde un Celerra Network Server para que estas
herramientas funcionen.
Recuperación de emcgetsd y emcsetsd
Las herramientas emcgetsd y emcsetsd se encuentran en el directorio CifsTools/
unixacltools en el Applications & Tools CD incluido con el producto.
Las herramientas emcgetsd y emcsetsd se pueden usar con tres tipos diferentes
de sistemas operativos UNIX: Linux, Solaris, SPARC y x86, y HP-UX. Se debe
recuperar la herramienta ejecutable apropiada para el sistema operativo.
Estas herramientas se pueden copiar en un cliente UNIX sin necesidad de realizar
un procedimiento de instalación en el cliente.
Visualización de ACLs
La herramienta emcgetsd, que se describe en la Tabla 14 en la página 61, permite
visualizar ACLs en un archivo o directorio desde un cliente UNIX o desde una
Control Station.
Tabla 14 Uso de la herramienta de línea de comandos emcgetsd (página 1 de 2)
Comando
Descripción
emcgetsd [-D <domain>] [-v] [-x]
Muestra el descriptor de seguridad de un file
system. Un descriptor de seguridad incluye
información sobre el propietario, la ACLs y las
auditorías del file system.
<local_node_path>
emcgetsd –a <local_node_path>
Opción
Descripción
-D <dominio>
Dirige el comando a un dominio específico.
Es posible que este dominio sea diferente al
dominio del usuario si existe una relación de
confianza entre el dominio del usuario y otro
dominio. En este caso, el comando muestra
los SIDs de ambos dominios.
Si no se especifica el dominio, CNS usa el
dominio predeterminado del servidor CIFS.
-v
Administración de EMC Celerra para un entorno de múltiples protocolos
Muestra información detallada sobre ACLs.
Versión 5.6
61 de 80
Tabla 14 Uso de la herramienta de línea de comandos emcgetsd (página 2 de 2)
Opción
Descripción
-x
Si no se inicia el CIFS o si no se encuentra el
nombre Windows de un usuario o grupo, se
devuelve el SID de este usuario en formato
decimal, a menos que se especifique la opción –x.
-a
Muestra los derechos de acceso de un usuario
actualmente conectado desde un cliente UNIX
o desde una Control Station.
<local_node_path>
Path del archivo o directorio del cliente UNIX.
Visualización de descriptor de seguridad
El comando emcgetsd se usa para mostrar el descriptor de seguridad de un file
system. Si el archivo o el directorio posee SIDs en una ACL que pertenezcan a
más de un dominio, la salida presenta información de domain/user o domain/group
sin que se especifique la opción -D en el comando emcgetsd.
Acción
Para mostrar el descriptor de seguridad de un file system mediante la opción verbose, utilice la
siguiente sintaxis de comandos:
$ emcgetsd -v <local_node_path>
Donde:
<local_node_path>= path del archivo o directorio del cliente UNIX
Ejemplo:
Para mostrar el descriptor de seguridad del directorio /fs2000A/apache/logs del file system
mediante la opción verbose, escriba:
$ emcgetsd –v /fs2000A/apache/logs
Salida
Dump of /fs2000A/apache/logs Security Descriptor
-----------------------------------------------Owner uid=677 fro
Group gid=2765 media
DACL
DENY
Gid=10 soft64
Access R-X--- 0x1200a9
READ_DATA
READ_EA
EXECUTE
READ_ATTRIBUTES
READ_CONTROL
Flags 0x3
OBJECT_INHERIT
CONTAINER_INHERIT
GRANT Uid=698 acl1
Access RWXPDO 0x1f01ff
62 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Salida
READ_DATA
WRITE_DATA
APPEND_DATA
READ_EA
WRITE_EA
EXECUTE
DELETE_CHILD
READ_ATTRIBUTES
WRITE_ATTRIBUTES
DELETE
READ_CONTROL
WRITE_DAC
WRITE_OWNER
Flags 0x1f
OBJECT_INHERIT
CONTAINER_INHERIT
NO_PROPAGATE_INHERIT
INHERIT_ONLY
INHERITED_ACE
GRANT Everyone
Access R-X--- 0x1200a9
READ_DATA
READ_EA
EXECUTE
READ_ATTRIBUTES
READ_CONTROL
Flags 0x3
OBJECT_INHERIT
CONTAINER_INHERIT
SACL
None
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
63 de 80
Visualización de derechos de acceso
Acción
Para mostrar los derechos de acceso de un usuario actualmente conectado desde un cliente
UNIX, utilice la siguiente sintaxis de comandos.
$ emcgetsd -a <local_node_path>
Donde:
<local_node_path>= path del archivo o directorio del cliente UNIX.
Ejemplo:
$ emcgetsd –a /fred/test1/TestDir
Salida
Server=dffr1, Path in the server=//test1/TestDir
Access of user uid=602 with groups gids={107-2765} on //test1/TestDir
NT Rights: R-XPDO 0x1f00e9
ReadExecute
Read
ListFolderContents
Modificación de ACLs
La herramienta emcsetsd permite modificar o visualizar la ACL en un archivo
o directorio desde un cliente UNIX o desde una Control Station.
Nota: Para usar esta herramienta, deberá contar con los derechos pertinentes.
Cuando se modifican los permisos Windows con la herramienta emcsetsd, el
propietario de Windows es reemplazado por el SID de UNIX y el UID/GID de UNIX,
como se muestra en los siguientes ejemplos:
Ejemplos:
Owner uid=898 Unix='luc' Sid=S-1-5-18-1-898
Group gid=109 Unix='emc2' Sid=S-1-5-18-2-109
Antes de usar la herramienta emcsetsd, se debe activar mediante el parámetro cifs
acl.extacl "Activación de capacidades especiales para la administración de ACLs"
en la página 46 proporciona una descripción completa del parámetro cifs acl.extacl.
64 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
La Tabla 15 en la página 65 describe las opciones de comandos de la herramienta
emcsetsd.
Tabla 15 Uso de la herramienta de línea de comandos emcsetsd (página 1 de 2)
Comando
Descripción
emcsetsd [-D <domain>] [-r]
Configura, restablece y audita los derechos
de control de acceso para los usuarios o
grupos en un archivo o un directorio.
-g <user_or_group>,<rights>[,<flags>]
-d <user_or_group>,<rights>[,<flags>]
-s <user_or_group>,<rights>[,<flags>]
-f <user_or_group>,<rights>[,<flags>]
-a <user_or_group>,<rights>[,<flags>]
<local_node_path>
Nota: Si no se inicia el CIFS o si no se
encuentra el nombre Windows de un
usuario o grupo, se rechaza el comando.
Usuario
Un usuario puede ser uno de los siguientes:
• UID=number
• User=NIS name
• domain\user
Group
Un grupo puede ser uno de los siguientes:
• GID=number
• Group=NIS name
• Everyone
• CreatorOwner
• CreatorGroup
• domain\user
Nota: Es posible cambiar el propietario del
usuario o grupo mediante el comando
UNIX chown o chgrp.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
65 de 80
Tabla 15 Uso de la herramienta de línea de comandos emcsetsd (página 2 de 2)
Comando
Descripción
Derechos
Los derechos pueden ser cualquiera de
los siguientes, separados por una barra
vertical (|):
READ_DATA
WRITE_DATA
APPEND_DATA
READ_EA
WRITE_EA
EXECUTE
DELETE_CHILD
READ_ATTRIBUTES
WRITE_ATTRIBUTES
DELETE
READ_CONTROL
WRITE_DAC
WRITE_OWNER
Una combinación de RWXPDO:
R: Read
W: Write
X: Execute
P: ChangePermission
D: Delete
O: TakeOwnership
Uno o más de los siguientes, separados
por una barra vertical (|):
FullControl
Modify
ReadExecute
• ListFolderContents
• Read
• Write
Flags
Uno o más de los siguientes valores,
separados por una barra vertical (|):
OBJECT_INHERIT: los subarchivos
heredan esta ACE.
CONTAINER_INHERIT: las subcarpetas
heredan esta ACE.
NO_PROPAGATE_INHERIT: herencia de
bloqueos del directorio principal
INHERIT_ONLY: La ACE no forma parte
de los derechos de acceso del directorio
actual, solo por herencia.
INHERITED_ACE: ACE heredada.
66 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Opción
Descripción
-D <domain>
Dirige el comando a un dominio específico.
Es posible que este dominio sea diferente
al dominio del usuario si existe una
relación de confianza entre el dominio del
usuario y otro dominio. En este caso, el
comando muestra los SIDs de ambos
dominios.
Si no se especifica el dominio, CNS usa el
dominio predeterminado del servidor CIFS.
-r
Elimina las ACLs actuales.
Nota: cuando se usa la opción -r , los
SIDs del propietario y del grupo son
reemplazados por los SIDs de UNIX y,
por lo tanto, después de usar la opción
-r, la identidad del propietario y del
grupo refleja los nuevos SIDs.
-g <user_or_group>,<rights>[,<flags>]
Concede acceso a un usuario o grupo.
-d <user_or_group>,<rights>[,<flags>]
Deniega acceso a un usuario o grupo.
-s <user_or_group>,<rights>[,<flags>]
Audita el acceso correcto de un usuario
o grupo.
-f <user_or_group>,<rights>[,<flags>]
Audita el acceso erróneo de un usuario
o grupo.
-a <user_or_group>,<rights>[,<flags>]
Audita todos los accesos de un usuario
o grupo.
<local_node_path>
Especifica el path del archivo o directorio
del cliente UNIX.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
67 de 80
Resolución de problemas del entorno Celerra
de múltiples protocolos
Como parte de su esfuerzo continuo por mejorar y optimizar el performance y
las capacidades de sus líneas de productos, EMC lanza periódicamente nuevas
versiones de las herramientas de hardware y software Celerra. En consecuencia,
es posible que algunas de las funciones que se describen en este documento no
se soporten en todas las versiones de las herramientas de hardware y software
que se encuentran en uso actualmente. Para obtener la información más reciente
acerca de las funciones de cada producto, consulte las notas de la versión del
producto correspondiente.
Si un producto no funciona correctamente o de la manera que se describe en este
documento, póngase en contacto con su representante de Soporte al cliente de EMC.
Dónde obtener ayuda
Para obtener información sobre licencias, productos y soporte de EMC:
Información de productos: para ver documentación, notas de la versión,
actualizaciones de software o para obtener información sobre productos, licencias
y servicios de EMC, visite el sitio Web de EMC Powerlink (registro obligatorio) en la
dirección:
http://Powerlink.EMC.com
Servicio técnico: para obtener servicio técnico, visite Servicio al Cliente de EMC
en Powerlink. Inicie sesión en el sitio Web de EMC Powerlink , vaya a Soporte >
Solicitar Soporte. Para abrir una solicitud de servicio por medio de Powerlink, debe
contar con un acuerdo de soporte válido. Comuníquese con un representante del
soporte al cliente de EMC para obtener detalles sobre cómo obtener un acuerdo de
soporte válido o para formular preguntas sobre su cuenta.
Nota: No solicite un representante de soporte específico a menos que ya le haya asignado
uno para su problema específico del sistema.
Problem Resolution Roadmap for EMC Celerra contiene información adicional
sobre el uso de Powerlink y la resolución de problemas.
Construcción de mensajes de error de server_log
El formato del código de evento puede ayudar a reducir el rango de búsqueda de
un mensaje. Existen varios componentes en el comienzo de cada línea que, por lo
general, son consistentes en todo el log de eventos. Por ejemplo, los mensajes de
eventos típicos presenta el siguiente formato:
2005-09-16 18:27:21: NFS: 3:
2005-09-16 18:27:23: CFS: 3:
2005-09-16 18:27:23: LIB: 6:
commit failed, status = NoPermission
Failed to open file, status NoPermission
last message repeated 1 times
El Manual de referencia de comandos de Celerra Network Server proporciona
información más detallada sobre server_log. Este mecanismo de log usa las
funcionalidades de log típicas de varios sistemas.
Los diversos componentes de un mensaje de evento son:
◆
68 de 80 Versión 5.6
La primera parte indica la fecha y la hora del evento de log.
Administración de EMC Celerra para un entorno de múltiples protocolos
◆
La segunda parte es el subsistema del código Celerra que informó el evento
(por ejemplo, NFS, CFS y LIB).
◆
La tercera parte es un código de clasificación, que es típico en funcionalidades
de log de eventos. La información acerca de los códigos de clasificación
se puede encontrar en la mayoría de los sistemas UNIX bajo el archivo de
encabezado syslog.h en el directorio /usr/include/sys.
Las definiciones de los códigos de clasificación posibles que soporta Celerra
Network Server son las siguientes:
#define
#define
#define
#define
#define
#define
#define
#define
◆
LOG_EMERG
LOG_ALERT
LOG_CRIT
LOG_ERR
LOG_WARNING
LOG_NOTICE
LOG_INFO
LOG_DEBUG
0
1
2
3
4
5
6
7
/*
/*
/*
/*
/*
/*
/*
/*
system is unusable */
action must be taken immediately */
critical conditions */
error conditions */
warning conditions */
normal but signification condition */
informational */
debug-level messages */
La cuarta parte describe la condición de error. La condición de error en las
primeras dos líneas del ejemplo no necesita explicación. Las operaciones que
se realizan son 'commit' y 'open', con la condición de error NoPermission. Otros
tipos de eventos no son tan descriptivos.
Códigos de error Kerberos
Los códigos de error Kerberos son códigos de estado que generalmente muestra
el subsistema SMB. Estos se pueden reconocer en los eventos registrados por la
existencia de un número negativo elevado.
Ejemplo
2003-07-24 16:29:35: SMB: 3: SSXAK=c0020030 origin=401 stat=e0000,
-1765328160
Debido a que Kerberos está estandarizado, existen recursos públicos donde
buscar los significados de la mayoría de estos códigos de estado. Uno de ellos
es el sitio Web http://www.net.berkeley.edu/kerberos/k5msgs.html, en el que se
encuentra una completa lista de los códigos de error Kerberos y sus definiciones.
Códigos de estado NT
Los códigos de estado NT se reportan para las funciones de emulación de CIFS o
de Microsoft Windows en los productos Celerra. Los códigos de estado NT son
valores de 32 bits sin firmar que se separan en subgrupos de datos binarios que
identifican las particularidades del estado de un evento. Los valores de 32 bits se
distribuyen de la siguiente manera:
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+---+-+-+-----------------------+-------------------------------+
|Sev|C|R|
Facility
|
Code
|
+---+-+-+-----------------------+-------------------------------+
Donde:
◆
Sev es el código de severidad.
• 00: Exitoso
• 01: Informativo
• 10: Advertencia
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
69 de 80
• 11: Error
◆
C es el indicador del código de cliente.
◆
R es un bit reservado.
◆
Facility es el código de la funcionalidad.
◆
Code es el código de estado de la funcionalidad.
Por lo común, los códigos de estado NT aparecen en el server_log con una
especificación de subsistema SMB. El código de estado NT se presenta de
diferentes maneras en los eventos de sistemas registrados. Entre los más
frecuentes, se encuentran:
◆
Un número hexadecimal precedido por Em=0x:
SMB: 4: authLogon=SamLogonInvalidReply Es=0x0 Em=0xc0000064
◆
Un número hexadecimal simple sin prefijo ni indicación de su formato:
SMB: 4: SSXAuth_SERVER_EXT13 aT=3 mT=1 c0000016
◆
Un número hexadecimal simple con prefijo de respuesta= sin indicación del formato:
SMB: 4: lookupNames:bad reply=c0000073
◆
Un número hexadecimal simple con prefijo de error= sin indicación del formato:
SMB: 4: SessSetupX failed=c0000016
◆
Un número hexadecimal marcado claramente como NTStatus= pero sin
indicación del formato:
SMB: 4: MsError sendLookupNames=21 NTStatus=c0000073
Problemas y limitaciones conocidos
La Tabla 16 en la página 70 describe los problemas conocidos que pudieran ocurrir al
usar Celerra para un entorno de múltiples protocolos y presenta soluciones alternativas.
Tabla 16 Situaciones problemáticas (página 1 de 3)
Problema conocido
Efecto
Solución alternativa
Con la autenticación de usuario NT,
algunos clientes de Windows 95 tal vez
no podrían asignar unidades de disco
desde el Data Mover.
El nombre de dominio enviado
por el cliente al Data Mover se
especificó incorrectamente, o el
username.domain no fue asignado
en el archivo de contraseña en el
Data Mover.
Verificar que el cliente está
enviando el nombre de dominio
correcto al archivo de contraseña.
70 de 80 Versión 5.6
Para verificar que el cliente esté
enviando el dominio correcto:
1. En la opción Network (Red) del
Control Panel (Panel de
control), haga doble clic en el
cliente de la red (Cliente para
Redes Microsoft).
2. En General properties
(Propiedades generales),
compruebe que se muestra el
nombre de dominio correcto.
Administración de EMC Celerra para un entorno de múltiples protocolos
Tabla 16 Situaciones problemáticas (página 2 de 3)
Problema conocido
Efecto
Solución alternativa
Con la autenticación de usuario NT,
aparecen los siguientes mensajes
de error:Incorrect password o
unknown username después de
intentar conectarse al servidor;
aparecerá la ventana de nombre
de usuario y contraseña.
Es posible que falte la cuenta de
usuario Windows NT del dominio
PDC, o que el Data Mover no haya
podido determinar un UID para
este usuario.
Agregue el usuario Windows NT
al PDC del dominio y asigne el
usuario a un UID y nombre de
usuario UNIX.
Con la autenticación de usuario NT, el
cliente no se puede conectar al servidor,
por lo que no aparecerá la ventana de
nombre de usuario y contraseña en el
lado del cliente.
No se encontró el controlador de
dominio para el dominio.
Controle si el PDC o el BDC está
activado. Controle si el Data
Mover puede acceder a un
servidor WINS que conozca el
dominio PDC o que tenga el PDC
y el BDC en la misma subred local
del Data Mover.
o
El nombre NetBIOS del servidor no
se registró como una cuenta para
computadora en el dominio PDC, o
no se ha establecido una relación
de confianza entre los dominios
cliente y servidor.
Aparecerá el siguiente mensaje en
el server_log:
The SAM database on the
Windows NT server does not
have a complete account
for this workstation trust
relationship.
Después de unir un servidor CIFS a un
dominio, aparecerá el siguiente error en
la salida de server_cifs, que indica que el
sistema no puede actualizar el registro
DNS:
Compruebe que existe una
cuenta para computadora y, si
fuera necesario, agréguela. Si
la cuenta para computadora
ya existe, quítela y agréguela
nuevamente antes de volver
a ingresar el comando. La
documentación del servidor
4.0 de Microsoft NT proporciona
mayor información acerca de la
configuración de una relación
de confianza entre los dominios.
Es posible que la zona del servidor
DNS incluya el mismo FQDN para
otra cuenta de computadora.
Compruebe que la zona del
servidor DNS no tenga el mismo
FQDN con una dirección de IP
distinta para otra cuenta de
computadora.
Se deniega el acceso porque,
cuando la computadora se creó en
el controlador de dominio, no se
activó (en el cuadro Windows New
Object - Computer dialog) el
permiso de uso de esta opción
de cuenta para computadoras
anteriores a Windows 2000.
Formatee la computadora y luego
vuelva a crearla con el permiso
de computadoras anteriores a
Windows 2000 para usar esta
opción de cuenta habilitada.
FQDN=dm4-a140ana0.c1t1.pt1.c3lab.nsgprod.em
c.com (Update of "A" record
failed during update:
Operation refused for policy
or security reasons)
0xC0000022
2004-04-26 10:49:40: SMB: 3:
Srv=<Celerra_netbios_name>
buildSecureChanel=Authenticate
2InvalidReply E=0xc0000022
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
71 de 80
Tabla 16 Situaciones problemáticas (página 3 de 3)
Problema conocido
Efecto
Solución alternativa
Al intentar iniciar MMC, aparece el
siguiente mensaje de error:
MMC requiere Internet Explorer
6.0 para usar su analizador de
XML DOM (Document Object
Model).
Actualice la versión de Internet
Explorer a 6.0.
Esto se debe, probablemente, a
que el parámetro NGROUPS_MAX
del kernel Solaris se configuró
para más de 16 grupos, que es el
límite predeterminado en los
sistemas Solaris. El NFS solo
soporta un máximo de 16 grupos.
En un entorno de múltiples
protocolos, se debe utilizar la
función de credenciales NT de
Celerra File Server para ampliar el
número de grupos a más de 16.
OLE Object: PBrush
El cliente Solaris recibe el siguiente
mensaje de advertencia durante la
creación de una cuenta de usuario:
UX:useradd: ADVERTENCIA: more
than NGROUPS_MAX(16) groups
specified
De todos modos, se creará la cuenta de
usuario, aunque es posible que se pueda
disponer de los datos.
Cuando el cliente Solaris intenta
acceder, recibe un mensaje de error
similar al siguiente:
nfs: [ID XXXXXX kern.notice]
NFS access failed for server
dm3-121-ana0-2: error 1 (RPC:
Can not encode arguments)
Según la implementación de UNIX,
el límite para la cantidad de grupos
por usuario es diferente:
• Solaris tiene un límite de 16
grupos
• Linux tiene un límite de 32 grupos
Al actualizar de un dominio Windows NT
a Windows 2000, no se puede cambiar
el sufijo del dominio original durante
la instalación de Windows 2000.
No hay posibilidad de cambiar
el sufijo del dominio porque fue
codificado de manera indeleble
en DDNS.
Antes de la actualización, cambie
el sufijo del dominio.
Se deniega el acceso a Internet
Information Services 6.0 (IIS) al intentar
conectarse al directorio Web
en un recurso compartido Celerra.
Para un servidor CIFS
independiente con el soporte de
usuario local activado, el nombre
de usuario y la contraseña
deberán ser los mismos en IIS 6.0,
en el Data Mover y en el cliente.
Especifique idénticos nombres de
usuario y contraseñas en IIS 6.0,
en el Data Mover y en el cliente.
En el log Web de IIS, se muestra el error
de nombre de usuario o contraseña
incorrectos aunque el nombre de usuario
y la contraseña estén en la base de
datos del usuario local.
72 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Mensajes de error del entorno de múltiples
protocolos de Celerra.
A partir de la versión 5.6, todos los mensajes de estado, alertas y nuevos eventos
proporcionan información detallada y acciones recomendadas para ayudarlo a
resolver problemas.
Para ver los detalles de un mensaje, utilice cualquiera de los métodos siguientes:
◆
Celerra Manager:
• Haga clic con el botón secundario sobre un mensaje de estado, alerta o
evento, y seleccione ver Event Details, Alert Details o Status Details.
◆
Celerra CLI:
• Escriba nas_message -info <MessageID>, donde MessageID corresponde
al número de identificación del mensaje.
◆
EMC Celerra Network Server Error Messages Guide:
• Utilice esta guía para hallar información sobre mensajes que se encuentren
en formato de mensaje de una versión anterior.
◆
Powerlink:
• Utilice el texto de la descripción breve del mensaje de error o el ID del
mensaje para realizar búsquedas en Knowledgebase, en Powerlink.
Inicie sesión en Powerlink y haga clic en Soporte > Búsqueda en
Knowledgebase > Búsqueda de Soluciones de Soporte.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
73 de 80
Información relacionada
Para obtener información específica relacionada con las características
y funcionalidades que se describen en este documento, consulte:
◆
◆
Configuring and Managing CIFS on EMC Celerra
Configuring EMC Celerra Naming Services
◆
Configuring EMC Celerra Time Services
◆
Configuración de mapping de usuario EMC Celerra
◆
Configuring External Usermapper for EMC Celerra
◆
Configuring NFS on EMC Celerra
◆
Configuración de Data Movers virtuales para EMC Celerra
◆
EMC Celerra Glossary
◆
Manual de referencia de comandos de EMC Celerra Network Server
◆
EMC Celerra Network Server Error Messages Guide
◆
EMC Celerra Network Server Parameters Guide
◆
Installing EMC Celerra Management Applications
◆
Configuring and Managing CIFS on EMC Celerra
◆
Administración de volúmenes y file systems EMC Celerra con Automatic
Volume Management
◆
Managing EMC Celerra Volumes and File Systems Manually
◆
Replicating EMC Celerra CIFS Environments (V1)
◆
Using EMC Utilities for the CIFS Environment
◆
Using International Character Sets with EMC Celerra
◆
Uso de herramientas administrativas de Windows con EMC Celerra
El EMC Celerra Network Server Documentation CD, que se incluye con Celerra
Network Server y que también se encuentra disponible en Powerlink, brinda
información general sobre otras publicaciones de EMC Celerra.
Inicie sesión en Powerlink, vaya a Soporte > Documentación Técnica y Asesorías
> Documentación de Hardware y Plataformas > Celerra Network Server. En esta
página, haga clic en Agregar a Favoritos. La sección Favoritos de la página
principal de Powerlink contiene un enlace que lo lleva directamente a esta página.
74 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Programas de capacitación para clientes
Los programas de capacitación para clientes de EMC están diseñados para ayudarlo a
aprender la manera en que interoperan los productos de almacenamiento de EMC y
se integran en del entorno para maximizar toda la inversión en infraestructura. Los
programas de capacitación para clientes de EMC incluyen capacitación en línea y
práctica en los laboratorios de última generación, que se encuentran distribuidos
en todo el mundo para brindar gran comodidad. Los programas de capacitación
para clientes de EMC son desarrollados e impartidos por expertos de EMC.
Para obtener más información sobre los programas y registrarse, inicie sesión en
Powerlink, nuestro sitio Web para clientes y asociados de negocios, y seleccione el
menú Capacitación.
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
75 de 80
76 de 80 Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Índice
A
acceso a archivos
configuración de ACLs desde UNIX 61
visualización de permisos UNIX 45
acceso de NFS 11
ACE 8
ACL y bits de modo, sincronización 27
ACLs
definición 8
modificación desde un cliente UNIX 64
visualización desde un cliente UNIX 61
ampliación de membresías de grupos, credencial de usuario
40
B
bits de modo 6
bloqueo de archivos
en un entorno CIFS 42
en un entorno NFS 42
limitaciones 43
modos de denegación de CIFS 42
políticas 42
C
CIFS
acceso a archivos, modos de denegación 42
definición 3
enlaces simbólicos 17
servicio, definición 5
servidor, definición 5
configuración de política de control de acceso 32
Consideraciones de interoperabilidad 16
control de acceso, mediante permisos UNIX únicamente 41
control de acceso, objetos de file systems 8
convenciones de nombres de archivos 16
credencial de Windows NT
adición de grupos a 40
configuración del dominio predeterminado 38
definición de 11
generación 39
membresías de grupos 11
memoria caché 38
procesamiento de 36
credenciales de usuario 8
D
DACL 8
Data Mover
servidor DFS independiente 11
derechos de acceso
configuración de políticas 35, 39
entorno de múltiples protocolos 26
UNIX 6
Windows 7
Administración de EMC Celerra para un entorno de múltiples protocolos
derivación de permisos, durante la traducción 33
descriptor de seguridad 8, 62
DFS
activación 52
configuración 47
desactivación 52
servidores raíz 11
wide links 12
dominio confiable, acceso 37
E
enlace, simbólico 17
enlaces simbólicos 17
activación de paths ascendentes 17
entorno de múltiples protocolos
convenciones de nombres de archivos 16
creación de una credencial estilo Windows 11
operaciones de backup de FSOs 31
permisos 26
políticas de control de acceso 10, 25, 26
seguridad de FSOs 8
estado de traducción 35
H
herramienta emcgetsd 61, 64
I
interfaces de usuario, opciones 14
M
memoria caché, credencial de Windows NT 38
MIXED/MIXED_COMPAT
migración a 32
reglas de herencia 31
restablecimiento de 35
sincronización automática 27
visión general 27
N
NDMP 31
NFS/CIFS
convenciones de nombres de archivos 16
resolución de conflictos de nombres 16
O
objetos de file systems
control de acceso 8
operaciones de backup 31
permisos de configuración 32
seguridad 8
UNIX 6
seguridad de Windows 7
Versión 5.6
77 de 80
P
T
parámetro acl.extendExtraGid 40
parámetro cifs acl.checkacl 41
parámetro cifs acl.extacl 45
parámetro NTcred.size 38
parámetro shadow followabsolutpath 20
parámetro shadow followdotdot 17
parámetros
acl.extendExtraGid 40
cifs acl.checkacl 41
cifs acl.extacl 45
NTcred.size 38
shadow followabsolutpath 20
shadow followdotdot 17
permisos
entorno de múltiples protocolos 26
seguridad 8
sincronización de 34
Política de control de acceso MIXED 10
Política de control de acceso MIXED_COMPAT 10
política de control de acceso NATIVE 9
política de control de acceso NT 9
Política de control de acceso SECURE 9
Política de control de acceso UNIX 9
política maestra, traducción 33
políticas de control de acceso
árbol de toma de decisiones 25
configuración 32
entorno de múltiples protocolos 26
MIXED 10
MIXED_COMPAT 10
NATIVE 9
NT 9
proceso de traducción 33
SECURE 9
UNIX 9
visión general 8
procesamiento, credencial de Windows NT 36
proceso de traducción, políticas de control de acceso 33
traducción de permisos
comando 34
política maestra 33
UNIX a Windows 29
Windows a UNIX 28
U
umask 30, 31
UNIX
bits de modo 6
cliente, visualización de derechos de acceso 64
credencial 8
modelo de seguridad 6
permisos, configuración desde Windows 45
W
wide links 12
configuración de Windows
Registro 60
creación 56
pasos del proceso 54
visión general 12
Windows
ACLs, configuración desde UNIX 61
configuración de permisos de archivos 8
credencial 8
dominio predeterminado, configuración 38
modelo de seguridad 7
R
raíz de DFS, creación
Data Mover independiente 48
uso de dfsutil.exe 48
uso de MMC 48
Registro de Windows, wide links 60
reglas de herencia, políticas de control de acceso 30
requerimientos del sistema 13
restores, objetos de file systems 31
S
SACL 8
seguridad
entorno de múltiples protocolos 8
Windows 7
seguridad, permisos 8
servidor DFS independiente 11
sincronización de, ACL y bits de modo 27, 34
78 de 80
Versión 5.6
Administración de EMC Celerra para un entorno de múltiples protocolos
Administración de EMC Celerra para un entorno de múltiples protocolos
Versión 5.6
79 de 80
Acerca de este documento
Como parte de su esfuerzo continuo por mejorar y optimizar el performance y las capacidades de la línea de productos Celerra Network
Server, EMC lanza periódicamente nuevas versiones de las herramientas de hardware y software Celerra. En consecuencia, es posible que
algunas de las funciones que se describen en este documento no se soporten en todas las versiones de las herramientas de hardware y
software Celerra que se encuentran en uso actualmente. Para obtener la información más reciente acerca de las funciones de cada producto,
consulte las notas de la versión del producto correspondiente. Si su sistema Celerra no cuenta con alguna de las funciones que se describen
en este documento, póngase en contacto con su representante de soporte al cliente de EMC para obtener una actualización de hardware o
software.
Comentarios y sugerencias acerca de la documentación
Sus sugerencias nos ayudarán mejorar la exactitud, organización y calidad general de la documentación para usuarios. Envíe un mensaje de
correo electrónico a [email protected] para darnos su opinión acerca de este documento.
Copyright © 1998-2008 EMC Corporation. Todos los derechos reservados.
EMC considera que la información de esta publicación es precisa en el momento de su publicación. La información está sujeta a cambios sin
previo aviso.
LA INFORMACIÓN DE ESTA PUBLICACIÓN SE PROPORCIONA "TAL CUAL". EMC CORPORATION NO SE HACE RESPONSABLE NI
OFRECE GARANTÍA DE NINGÚN TIPO CON RESPECTO A LA INFORMACIÓN DE ESTA PUBLICACIÓN Y, ESPECÍFICAMENTE,
RENUNCIA A TODA GARANTÍA IMPLÍCITA DE COMERCIABILIDAD O CAPACIDAD PARA UN PROPÓSITO DETERMINADO.
El uso, la copia y la distribución de cualquier software de EMC descrito en esta publicación requieren una licencia de software
correspondiente.
Para obtener una lista actualizada de nombres de productos de EMC, consulte las marcas comerciales de EMC Corporation en
argentina.emc.com.
Todas las otras marcas comerciales incluidas en este documento pertenecen a sus respectivos propietarios.
80 de 80 Versión 5.6