Conectarse a un recurso compartido en SAMBA usando el nombre de usuario y contraseña actual
Saludos hermanos.
Tengo un problemita.
Quiero conectarme a un recurso compartido en un servidor de archivos SAMBA usando el nombre de usuario y contraseña de mi sesión Linux. O sea, algo como esto:
mount.cifs //fileserver/share /mnt/smbfs/share1 -o username=$USER, password=$PASSWORD,workgroup=EXAMPLE
He leído sobre las variables de entorno y he visto algunas cosas, pero en ningún manual aparece como sacar la contraseña sino la variable de entorno $USER.
Lo que quiero lograr es que cuando un usuario se conecte a un recurso compartido (por ejemplo, los perfiles de usuario) se envíe el token correspondiente a ese usuario específico. Lo normal es pasarle un token predefinido al mount.cifs, pero eso no me sirve.
Gracias de antemano.
--------------------------------------- Red Telematica de Salud - Cuba CNICM - Infomed
Hector, conoces LinNeighborhood?, es excelente para acceder a recursos compartidos en servidores de archivo Samba.
Saludos.
Carlos R.
El 18 de septiembre de 2008 7:04, Héctor Suárez Planas < bolodia@medired.scu.sld.cu> escribió:
Saludos hermanos.
Tengo un problemita.
Quiero conectarme a un recurso compartido en un servidor de archivos SAMBA usando el nombre de usuario y contraseña de mi sesión Linux. O sea, algo como esto:
mount.cifs //fileserver/share /mnt/smbfs/share1 -o username=$USER, password=$PASSWORD,workgroup=EXAMPLE
He leído sobre las variables de entorno y he visto algunas cosas, pero en ningún manual aparece como sacar la contraseña sino la variable de entorno $USER.
Lo que quiero lograr es que cuando un usuario se conecte a un recurso compartido (por ejemplo, los perfiles de usuario) se envíe el token correspondiente a ese usuario específico. Lo normal es pasarle un token predefinido al mount.cifs, pero eso no me sirve.
Gracias de antemano.
Red Telematica de Salud - Cuba CNICM - Infomed _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
...
Hector, conoces LinNeighborhood?, es excelente para acceder a recursos compartidos en servidores de archivo Samba.
Sí, pero no es exactamente lo que necesito. Te explico.
Entre un amigo mío y yo montamos un Fedora Directory Server 1.0.4 en un servidor con CentOS 5.2 y configuramos el Samba como PDC usando al FDS como almacén de usuarios y contraseñas. O sea, un "dominio" en Linux.
Los datos de los usuarios y las contraseñas las tomamos de un servidor Active Directory que está en funcionamiento, o sea, logramos sincronizar los usuarios y contraseñas del ADS con el FDS.
Además de eso, existe un servidor de archivos donde se encuentran los perfiles de usuarios al cuál se conectan las estaciones de trabajo Windows montando en una unidad el recurso compartido que apunta al perfil del usuario.
Lo que quiero hacer es lograr que cuando un usuario autentique en su estación de trabajo, tomar ese mismo token y montar en un subdirectorio local el recurso compartido del servidor de archivos (el perfil del usuario) mediante el comando mount.cifs. He leído que cuando no se especifica las opciones del usuario y la contraseña, estos se toman de las variables de entorno $USER y $PASSWD.
La ventaja que tengo es que el usuario que se encuentra en el Fedora Directory Server tiene un equivalente en el Active Directory y quiero seguir usando el mismo servidor de archivos para no afectar el servicio.
Hasta ahora me da un error de permisos:
mount error 13 = Permission denied Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
--------------------------------------- Red Telematica de Salud - Cuba CNICM - Infomed
...
Hector, conoces LinNeighborhood?, es excelente para acceder a recursos compartidos en servidores de archivo Samba.
Sí, pero no es exactamente lo que necesito. Te explico.
Entre un amigo mío y yo montamos un Fedora Directory Server 1.0.4 en un servidor con CentOS 5.2 y configuramos el Samba como PDC usando al FDS como almacén de usuarios y contraseñas. O sea, un "dominio" en Linux.
Los datos de los usuarios y las contraseñas las tomamos de un servidor Active Directory que está en funcionamiento, o sea, logramos sincronizar los usuarios y contraseñas del ADS con el FDS.
Además de eso, existe un servidor de archivos donde se encuentran los perfiles de usuarios al cuál se conectan las estaciones de trabajo Windows montando en una unidad el recurso compartido que apunta al perfil del usuario.
Lo que quiero hacer es lograr que cuando un usuario autentique en su estación de trabajo, tomar ese mismo token y montar en un subdirectorio local el recurso compartido del servidor de archivos (el perfil del usuario) mediante el comando mount.cifs. He leído que cuando no se especifica las opciones del usuario y la contraseña, estos se toman de las variables de entorno $USER y $PASSWD.
La ventaja que tengo es que el usuario que se encuentra en el Fedora Directory Server tiene un equivalente en el Active Directory y quiero seguir usando el mismo servidor de archivos para no afectar el servicio.
Hasta ahora me da un error de permisos:
mount error 13 = Permission denied Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
...y viendo el log del mount.cifs (pasándole el parámetro --verbose) me percaté que la opción password no estaba tomando la contraseña, ¿la causa?, la variable de entorno $PASSWD no tiene valor, o sea, está vacío.
¿A qué se debe esto?
:?
--------------------------------------- Red Telematica de Salud - Cuba CNICM - Infomed
Si la contraseña estuviera almacenada en una variable seria un peligro para todo el sistema. La contraseña solamente se valida cuando se accede al sistema y date cuenta de que el proceso que realiza es encriptar la contraseña que has introducido y si coincide con la encriptada que tiene almacenada entonces accedes al sistema. Tu necesitas pasarle la contraseña en claro y eso "no es posible" (siempre y cuando desees mantener tu sistema seguro).
El jue, 18-09-2008 a las 18:36 -0400, Héctor Suárez Planas escribió:
...
Hector, conoces LinNeighborhood?, es excelente para acceder a recursos compartidos en servidores de archivo Samba.
Sí, pero no es exactamente lo que necesito. Te explico.
Entre un amigo mío y yo montamos un Fedora Directory Server 1.0.4 en un servidor con CentOS 5.2 y configuramos el Samba como PDC usando al FDS como almacén de usuarios y contraseñas. O sea, un "dominio" en Linux.
Los datos de los usuarios y las contraseñas las tomamos de un servidor Active Directory que está en funcionamiento, o sea, logramos sincronizar los usuarios y contraseñas del ADS con el FDS.
Además de eso, existe un servidor de archivos donde se encuentran los perfiles de usuarios al cuál se conectan las estaciones de trabajo Windows montando en una unidad el recurso compartido que apunta al perfil del usuario.
Lo que quiero hacer es lograr que cuando un usuario autentique en su estación de trabajo, tomar ese mismo token y montar en un subdirectorio local el recurso compartido del servidor de archivos (el perfil del usuario) mediante el comando mount.cifs. He leído que cuando no se especifica las opciones del usuario y la contraseña, estos se toman de las variables de entorno $USER y $PASSWD.
La ventaja que tengo es que el usuario que se encuentra en el Fedora Directory Server tiene un equivalente en el Active Directory y quiero seguir usando el mismo servidor de archivos para no afectar el servicio.
Hasta ahora me da un error de permisos:
mount error 13 = Permission denied Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
...y viendo el log del mount.cifs (pasándole el parámetro --verbose) me percaté que la opción password no estaba tomando la contraseña, ¿la causa?, la variable de entorno $PASSWD no tiene valor, o sea, está vacío.
¿A qué se debe esto?
:?
Red Telematica de Salud - Cuba CNICM - Infomed
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
...
Si la contraseña estuviera almacenada en una variable seria un peligro para todo el sistema. La contraseña solamente se valida cuando se accede al sistema y date cuenta de que el proceso que realiza es encriptar la contraseña que has introducido y si coincide con la encriptada que tiene almacenada entonces accedes al sistema. Tu necesitas pasarle la contraseña en claro y eso "no es posible" (siempre y cuando desees mantener tu sistema seguro).
Cierto. Tienes mucha razón.
Hum... ya eso es un problema. A la larga tendremos que montar un servidor Linux y que la gente se conecte por NFS.
En cuanto al NFS mi duda es la siguiente:
Supongamos que se activa el servicio NFS en un servidor (de perfiles de usuarios, por ejemplo) para que los sistemas clientes los monten. Ahora bien, ¿una vez que el recurso está montado localmente se respetan los permisos de los subdirectorios del servidor?
--------------------------------------- Red Telematica de Salud - Cuba CNICM - Infomed
...
Supongamos que se activa el servicio NFS en un servidor (de perfiles de usuarios, por ejemplo) para que los sistemas clientes los monten. Ahora bien, ¿una vez que el recurso está montado localmente se respetan los permisos de los subdirectorios del servidor?
Me explico, supongamos que se tiene lo siguiente:
carpeta (permisos 777) | -- usuario1 (permisos 700) | -- usuario2 (permisos 700)
Se comparte la carpeta por NFS a varias máquinas de la red (con permisos 'rw' en la exportación de los recursos, por ejemplo). Se monta la carpeta en los sistemas clientes. Se autenticó usuario1 en un sistema cliente. Mi pregunta es: ¿usuario1 puede entrar en la carpeta de usuario2 y ver/modificar los archivos de este?
--------------------------------------- Red Telematica de Salud - Cuba CNICM - Infomed
Hector, voy a describirte un escenario similar en el que trabajo, y como empleamos el Linneighborhood.
Tengo un servidor de archivos con RedHat, (aproximadamente 600 GB de información ), configurado el samba para la publicacion de esos recursos, tenemos instalado un sistema de autenticación (Fedora Directory Server) y manejamos el control de acceso a esos recursos a través de ACL'S, A esos recursos acceden diariamente unos 1500 usuarios aproximadamente de forma recurrente. Solo acceden aquellos usuarios que tienen permisos asignados (de lectura, o de lectura y escritura sobre carpetas o archivos previamente autorizados por los jefes de sección).
Nuestras estaciones de trabajo son en un 95 % Linux y el resto windows. Para el caso de los windows les creamos un acceso al recurso y este valida el usuario con el cual se va a autenticar, si este tiene permisos (a traves de las acl's) de ingresar a la carpeta que desee. si no tiene permisos no le permite ingresar.
Para el caso de Linux con la herramienta que te mensione nos simplifica mas el trabajo, ya que solo le configuramos el recurso que requiere, le validamos la clave una sola vez (Tambien es posible configurarlo para que cada vez que ingrese le pida la clave, pero los usuarios prefieren que no se las pida) y esta se mostrara en el escritorio como una carpeta mas de su estacion de trabajo.
La aplicacion tiene pestañas en las cuales configurar el sitio donde quieras que el usuario visualice su carpeta del servidor de archivos como si fuera local de su estacion de trabajo, tambien tiene opciones para que memorice el punto de montaje, el navegador de archivos a utilizas (usamos nautilus).
finalmente configuramos que cada vez que la maquina se reinicie o se apague y vuelva a subir tenga disponible la carpeta y la información contenida en ella, haciendo que la aplicacion linneighborhood corra en segundo plano (/usr/bin/linneighborhood -m ) esto lo puedes hacer por el ambiente grafico en la siguiente ruta: inicio-sistemas-preferencias-secciones ... alli agregas la aplicacion con el parametro -m para que suba en segundo plano.
Como veras tenemos autenticación, disponibilidad de los archivos, y control de acceso a los mismos (ya sea de solo lectura, de lectura y escritura o restriccion a los mismos para usuarios no autorizados).
Espero te sirva la forma como lo solucionamos en la empresa para la que trabajo.
PD. la solucion de nfs es otra alternativa, pero no es la mejor practica para un servidor de archivos (cambia el esquema de servidor de archivos a servidor NFS). Para controlar la parte de que un usuario no modifique los archivos de otro o "esculque" informacion no autorizada es bueno que contemples la implementacion de las ACL'S (Listas de control de acceso), es bastante simple de implementar y hay mucha documentación en la web para el tema.
Cordialmente,
Carlos Restrepo M.
Administrador de Sistemas.
2008/9/19 Héctor Suárez Planas bolodia@medired.scu.sld.cu
...
Supongamos que se activa el servicio NFS en un servidor (de perfiles de usuarios, por ejemplo) para que los sistemas clientes los monten. Ahora bien, ¿una vez que el recurso está montado localmente se respetan los permisos de los subdirectorios del servidor?
Me explico, supongamos que se tiene lo siguiente:
carpeta (permisos 777) | -- usuario1 (permisos 700) | -- usuario2 (permisos 700)
Se comparte la carpeta por NFS a varias máquinas de la red (con permisos 'rw' en la exportación de los recursos, por ejemplo). Se monta la carpeta en los sistemas clientes. Se autenticó usuario1 en un sistema cliente. Mi pregunta es: ¿usuario1 puede entrar en la carpeta de usuario2 y ver/modificar los archivos de este?
Red Telematica de Salud - Cuba CNICM - Infomed _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
...
Tengo un servidor de archivos con RedHat, (aproximadamente 600 GB de información ), configurado el samba para la publicacion de esos recursos,
¿Sólo publicación de recursos? ¿No está configurado para ser PDC de las pocas PCs con Windows que tienes?
tenemos instalado un sistema de autenticación (Fedora Directory Server) y manejamos el control de acceso a esos recursos a través de ACL'S,
¿ACLs de quien? ¿De Samba?
A esos recursos acceden diariamente unos 1500 usuarios aproximadamente de forma recurrente. Solo acceden aquellos usuarios que tienen permisos asignados (de lectura, o de lectura y escritura sobre carpetas o archivos previamente autorizados por los jefes de sección).
Hum... son un montón de accesos. :O
Nuestras estaciones de trabajo son en un 95 % Linux y el resto windows. Para el caso de los windows les creamos un acceso al recurso y este valida el usuario con el cual se va a autenticar, si este tiene permisos (a traves de las acl's) de ingresar a la carpeta que desee. si no tiene permisos no le permite ingresar.
Para el caso de Linux con la herramienta que te mensione nos simplifica mas el trabajo, ya que solo le configuramos el recurso que requiere, le validamos la clave una sola vez (Tambien es posible configurarlo para que cada vez que ingrese le pida la clave, pero los usuarios prefieren que no se las pida) y esta se mostrara en el escritorio como una carpeta mas de su estacion de trabajo.
Con el Lineightborhood resuelves ese problema, ¿no?
La aplicacion tiene pestañas en las cuales configurar el sitio donde quieras que el usuario visualice su carpeta del servidor de archivos como si fuera local de su estacion de trabajo, tambien tiene opciones para que memorice el punto de montaje, el navegador de archivos a utilizas (usamos nautilus).
finalmente configuramos que cada vez que la maquina se reinicie o se apague y vuelva a subir tenga disponible la carpeta y la información contenida en ella, haciendo que la aplicacion linneighborhood corra en segundo plano (/usr/bin/linneighborhood -m ) esto lo puedes hacer por el ambiente grafico en la siguiente ruta: inicio-sistemas-preferencias- secciones ... alli agregas la aplicacion con el parametro -m para que suba en segundo plano.
Como veras tenemos autenticación, disponibilidad de los archivos, y control de acceso a los mismos (ya sea de solo lectura, de lectura y escritura o restriccion a los mismos para usuarios no autorizados).
Sí, me has dejado sorprendido. A juzgar por todo lo que han hecho en tu empresa, ahora es que estamos empezando.
Espero te sirva la forma como lo solucionamos en la empresa para la que trabajo.
Está bastante interesante. ¿Podrías darme algunas luces para yo portar esa solución?
PD. la solucion de nfs es otra alternativa, pero no es la mejor practica para un servidor de archivos (cambia el esquema de servidor de archivos a servidor NFS). Para controlar la parte de que un usuario no modifique los archivos de otro o "esculque" informacion no autorizada es bueno que contemples la implementacion de las ACL'S (Listas de control de acceso), es bastante simple de implementar y hay mucha documentación en la web para el tema.
Mira, yo no soy muy amante del NFS, realmente lo veo un poco "seco" comparado con SAMBA, que está más terminado por la parte de los permisos a recursos y demás.
Háblame un poco más sobre las ACLs.
Cordialmente,
Carlos Restrepo M.
Administrador de Sistemas.
Gracias, hermano.
--------------------------------------- Red Telematica de Salud - Cuba CNICM - Infomed
El 19 de septiembre de 2008 13:53, Héctor Suárez Planas < bolodia@medired.scu.sld.cu> escribió:
...
Tengo un servidor de archivos con RedHat, (aproximadamente 600 GB de información ), configurado el samba para la publicacion de esos
recursos,
¿Sólo publicación de recursos? ¿No está configurado para ser PDC de las pocas PCs con Windows que tienes?
tenemos instalado un sistema de autenticación (Fedora Directory Server) y manejamos el control de acceso a esos recursos a través de ACL'S,
¿ACLs de quien? ¿De Samba?
ACL', es un paquete que instalas (yum install acl), de manera sencilla este paquete permite colocar a un recurso de un servidor de archivos samba, la gestion de permisos de los sistemas Linux-Unix. (debes instalarlo en el servidor de archivos, y este debe tener creados los perfiles de cada usuario.) te recomiendo que instales en el servidor de archivos el fedora directory server y tienes las dos cosas en el mismo lado, de lo contrario te tocara crear todos los perfiles tambien en el servidor de archivos.
A esos recursos acceden diariamente unos 1500 usuarios aproximadamente de
forma
recurrente. Solo acceden aquellos usuarios que tienen permisos asignados (de lectura, o de lectura y escritura sobre carpetas o archivos previamente autorizados por los jefes de sección).
Hum... son un montón de accesos. :O
Nuestras estaciones de trabajo son en un 95 % Linux y el resto windows. Para el caso de los windows les creamos un acceso al recurso y este
valida
el usuario con el cual se va a autenticar, si este tiene permisos (a traves de las acl's) de ingresar a la carpeta que desee. si no tiene permisos no le permite ingresar.
Para el caso de Linux con la herramienta que te mensione nos simplifica mas el trabajo, ya que solo le configuramos el recurso que requiere, le validamos la clave una sola vez (Tambien es posible configurarlo para que cada vez que ingrese le pida la clave, pero los usuarios prefieren que no se las pida) y esta se mostrara en el escritorio como una carpeta mas de su estacion de trabajo.
Con el Lineightborhood resuelves ese problema, ¿no? Claro que yes, de esa forma tienes lo que necesitas, es decir el recurso visto en el pc del usuario como si fuera local de su maquina.
La aplicacion tiene pestañas en las cuales configurar el sitio donde quieras que el usuario visualice su carpeta del servidor de archivos como si fuera local de su estacion de trabajo, tambien tiene opciones para que memorice el punto de montaje, el navegador de archivos a utilizas (usamos nautilus).
finalmente configuramos que cada vez que la maquina se reinicie o se apague y vuelva a subir tenga disponible la carpeta y la información contenida en ella, haciendo que la aplicacion linneighborhood corra en segundo plano (/usr/bin/linneighborhood -m ) esto lo puedes hacer por
el
ambiente grafico en la siguiente ruta: inicio-sistemas-preferencias- secciones ... alli agregas la aplicacion con el parametro -m para que suba en segundo plano.
Como veras tenemos autenticación, disponibilidad de los archivos, y control de acceso a los mismos (ya sea de solo lectura, de lectura y escritura o restriccion a los mismos para usuarios no autorizados).
Sí, me has dejado sorprendido. A juzgar por todo lo que han hecho en tu empresa, ahora es que estamos empezando.
Espero te sirva la forma como lo solucionamos en la empresa para la que trabajo.
Está bastante interesante. ¿Podrías darme algunas luces para yo portar esa solución?
Dime en que tienes dudas y las vamos trabajando...
PD. la solucion de nfs es otra alternativa, pero no es la mejor practica para un servidor de archivos (cambia el esquema de servidor de archivos a servidor NFS). Para controlar la parte de que un usuario no modifique los archivos de otro o "esculque" informacion no autorizada es bueno que contemples la implementacion de las ACL'S (Listas de control de acceso), es bastante simple de implementar y hay mucha documentación en la web
para
el tema.
Mira, yo no soy muy amante del NFS, realmente lo veo un poco "seco" comparado con SAMBA, que está más terminado por la parte de los permisos a recursos y demás.
Totalmente de acuerdo, chistosamente tambien a nfs (network file system) se le conoce como "sistema de archivos no seguro" ;-), para lo que tienes lo mejor es el samba.
Háblame un poco más sobre las ACLs.
Basicamente es un paquete que permite incorporar el poderio de los privilegios a traves de permisos a un recurso (directorio, archivo, etc), de forma mas puntual ( no solamente con los que ya conoces; propietario, grupo y otros, por el contrario los coloca sobre un usuario o perfil en particular.
Saludos
Carlos R.
Cordialmente,
Carlos Restrepo M.
Administrador de Sistemas.
Gracias, hermano.
Red Telematica de Salud - Cuba CNICM - Infomed _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
...
tenemos instalado un sistema de autenticación (Fedora Directory Server) y manejamos el control de acceso a esos recursos a través de ACL'S,
¿ACLs de quien? ¿De Samba?
ACL', es un paquete que instalas (yum install acl), de manera sencilla este paquete permite colocar a un recurso de un servidor de archivos samba, la gestion de permisos de los sistemas Linux-Unix. (debes instalarlo en el servidor de archivos, y este debe tener creados los perfiles de cada usuario.) te recomiendo que instales en el servidor de archivos el fedora directory server y tienes las dos cosas en el mismo lado, de lo contrario te tocara crear todos los perfiles tambien en el servidor de archivos.
Bien, eso me gusta, pero lo que necesitamos es separar el servidor de perfiles del FDS, ya que ahí queremos poner otras cosas, además de que el espacio en disco no nos acompaña.
En otras palabras, seguir por la variante larga que explicas en esta parte.
A esos recursos acceden diariamente unos 1500 usuarios aproximadamente de forma recurrente. Solo acceden aquellos usuarios que tienen permisos asignados (de lectura, o de lectura y escritura sobre carpetas o archivos previamente autorizados por los jefes de sección).
Hum... son un montón de accesos. :O
Nuestras estaciones de trabajo son en un 95 % Linux y el resto windows. Para el caso de los windows les creamos un acceso al recurso y este valida el usuario con el cual se va a autenticar, si este tiene permisos (a traves de las acl's) de ingresar a la carpeta que desee. si no tiene permisos no le permite ingresar.
Para el caso de Linux con la herramienta que te mensione nos simplifica mas el trabajo, ya que solo le configuramos el recurso que requiere, le validamos la clave una sola vez (Tambien es posible configurarlo para que cada vez que ingrese le pida la clave, pero los usuarios prefieren que no se las pida) y esta se mostrara en el escritorio como una carpeta mas de su estacion de trabajo.
Con el Lineightborhood resuelves ese problema, ¿no? Claro que yes, de esa forma tienes lo que necesitas, es decir el recurso visto en el pc del usuario como si fuera local de su maquina.
La aplicacion tiene pestañas en las cuales configurar el sitio donde quieras que el usuario visualice su carpeta del servidor de archivos como si fuera local de su estacion de trabajo, tambien tiene opciones para que memorice el punto de montaje, el navegador de archivos a utilizas (usamos nautilus).
finalmente configuramos que cada vez que la maquina se reinicie o se apague y vuelva a subir tenga disponible la carpeta y la información contenida en ella, haciendo que la aplicacion linneighborhood corra en segundo plano (/usr/bin/linneighborhood -m ) esto lo puedes hacer por el ambiente grafico en la siguiente ruta: inicio-sistemas-preferencias- secciones ... alli agregas la aplicacion con el parametro -m para que suba en segundo plano.
Como veras tenemos autenticación, disponibilidad de los archivos, y control de acceso a los mismos (ya sea de solo lectura, de lectura y escritura o restriccion a los mismos para usuarios no autorizados).
Sí, me has dejado sorprendido. A juzgar por todo lo que han hecho en tu empresa, ahora es que estamos empezando.
Espero te sirva la forma como lo solucionamos en la empresa para la que trabajo.
Está bastante interesante. ¿Podrías darme algunas luces para yo portar esa solución?
Dime en que tienes dudas y las vamos trabajando...
OK, mira lo que queremos es lo siguiente:
- Un servidor Fedora Directory Server + PDC para los usuarios Windows (los de Linux autenticarán directo con el LDAP mediante SSL/TLS). - Un servidor de Perfiles de Usuarios. - Un servidor de archivos para lo demás (documentación, instaladores de Windows, herramientas, música, etc.)
De ahí, las estaciones de trabajo que tenemos son un 98% Windows y un 2% Linux y queremos migrar al segundo, pero primero queremos asegurar la infraestructura de servidores y servicios con Linux como SO, de los cuales actualmente sólo tenemos el primero de los tres que te mencioné, o sea, el servidor con el FDS+PDC.
PD. la solucion de nfs es otra alternativa, pero no es la mejor practica para un servidor de archivos (cambia el esquema de servidor de archivos a servidor NFS). Para controlar la parte de que un usuario no modifique los archivos de otro o "esculque" informacion no autorizada es bueno que contemples la implementacion de las ACL'S (Listas de control de acceso), es bastante simple de implementar y hay mucha documentación en la web para el tema.
Mira, yo no soy muy amante del NFS, realmente lo veo un poco "seco" comparado con SAMBA, que está más terminado por la parte de los permisos a recursos y demás.
Totalmente de acuerdo, chistosamente tambien a nfs (network file system) se le conoce como "sistema de archivos no seguro" ;-), para lo que tienes lo mejor es el samba.
Exacto. Entonces estamos de acuerdo en este punto.
Háblame un poco más sobre las ACLs.
Basicamente es un paquete que permite incorporar el poderio de los > > privilegios a traves de permisos a un recurso (directorio, archivo, etc), de forma mas puntual ( no solamente con los que ya conoces; propietario, grupo y otros, por el contrario los coloca sobre un usuario o perfil en particular.
Bien, googlearé un poco para buscar eso. Aunque si tienes alguna URL ya guardada, te agradecería que me la facilitaras.
Saludos.
--------------------------------------- Red Telematica de Salud - Cuba CNICM - Infomed
Compañero, vas bién enfocado, estos links te ayudara a implementar ACL'S:
http://www.vanemery.com/Linux/ACL/linux-acl.html
http://dns.bdat.net/documentos/samba/acls-linux-samba/x115.html
El 18 de septiembre de 2008 16:34, Héctor Suárez Planas < bolodia@medired.scu.sld.cu> escribió:
...
Hector, conoces LinNeighborhood?, es excelente para acceder a recursos compartidos en servidores de archivo Samba.
Sí, pero no es exactamente lo que necesito. Te explico.
Entre un amigo mío y yo montamos un Fedora Directory Server 1.0.4 en un servidor con CentOS 5.2 y configuramos el Samba como PDC usando al FDS como almacén de usuarios y contraseñas. O sea, un "dominio" en Linux.
Los datos de los usuarios y las contraseñas las tomamos de un servidor Active Directory que está en funcionamiento, o sea, logramos sincronizar los usuarios y contraseñas del ADS con el FDS.
Además de eso, existe un servidor de archivos donde se encuentran los perfiles de usuarios al cuál se conectan las estaciones de trabajo Windows montando en una unidad el recurso compartido que apunta al perfil del usuario.
Lo que quiero hacer es lograr que cuando un usuario autentique en su estación de trabajo, tomar ese mismo token y montar en un subdirectorio local el recurso compartido del servidor de archivos (el perfil del usuario) mediante el comando mount.cifs. He leído que cuando no se especifica las opciones del usuario y la contraseña, estos se toman de las variables de entorno $USER y $PASSWD.
La ventaja que tengo es que el usuario que se encuentra en el Fedora Directory Server tiene un equivalente en el Active Directory y quiero seguir usando el mismo servidor de archivos para no afectar el servicio.
Hasta ahora me da un error de permisos:
mount error 13 = Permission denied Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
Red Telematica de Salud - Cuba CNICM - Infomed _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Olas k talkos... disculpa me intereza implementar un FDS..no se si seria mucho pedir que me pases si esk has utilizado una guia de la instalacion para yo tb poder guiarme..gracias espero tu respuesta help..!!!!
correos: odioajeno_59@hotmail.com, i610886@cibertec.edu.pe
* *
Saludos,
carlos restrepo escribió:
Compañero, vas bién enfocado, estos links te ayudara a implementar ACL'S:
http://www.vanemery.com/Linux/ACL/linux-acl.html
http://dns.bdat.net/documentos/samba/acls-linux-samba/x115.html
El 18 de septiembre de 2008 16:34, Héctor Suárez Planas <bolodia@medired.scu.sld.cu mailto:bolodia@medired.scu.sld.cu> escribió:
... > Hector, conoces LinNeighborhood?, es excelente para acceder a recursos > compartidos en servidores de archivo Samba. Sí, pero no es exactamente lo que necesito. Te explico. Entre un amigo mío y yo montamos un Fedora Directory Server 1.0.4 en un servidor con CentOS 5.2 y configuramos el Samba como PDC usando al FDS como almacén de usuarios y contraseñas. O sea, un "dominio" en Linux. Los datos de los usuarios y las contraseñas las tomamos de un servidor Active Directory que está en funcionamiento, o sea, logramos sincronizar los usuarios y contraseñas del ADS con el FDS. Además de eso, existe un servidor de archivos donde se encuentran los perfiles de usuarios al cuál se conectan las estaciones de trabajo Windows montando en una unidad el recurso compartido que apunta al perfil del usuario. Lo que quiero hacer es lograr que cuando un usuario autentique en su estación de trabajo, tomar ese mismo token y montar en un subdirectorio local el recurso compartido del servidor de archivos (el perfil del usuario) mediante el comando mount.cifs. He leído que cuando no se especifica las opciones del usuario y la contraseña, estos se toman de las variables de entorno $USER y $PASSWD. La ventaja que tengo es que el usuario que se encuentra en el Fedora Directory Server tiene un equivalente en el Active Directory y quiero seguir usando el mismo servidor de archivos para no afectar el servicio. Hasta ahora me da un error de permisos: mount error 13 = Permission denied Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) --------------------------------------- Red Telematica de Salud - Cuba CNICM - Infomed _______________________________________________ CentOS-es mailing list CentOS-es@centos.org <mailto:CentOS-es@centos.org> http://lists.centos.org/mailman/listinfo/centos-es-- Carlos Restrepo M.
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Hola...
Este links tiene toda la documentación que necesitas para la implementación de FDS.
http://directory.fedoraproject.org/
Saludos.
Carlos R.
El 22 de septiembre de 2008 14:48, Wilder Deza soporte@gammacargo.comescribió:
Olas k talkos... disculpa me intereza implementar un FDS..no se si seria mucho pedir que me pases si esk has utilizado una guia de la instalacion para yo tb poder guiarme..gracias espero tu respuesta help..!!!!
correos: odioajeno_59@hotmail.com, i610886@cibertec.edu.pe
Saludos,
carlos restrepo escribió:
Compañero, vas bién enfocado, estos links te ayudara a implementar ACL'S:
http://www.vanemery.com/Linux/ACL/linux-acl.html
http://dns.bdat.net/documentos/samba/acls-linux-samba/x115.html
El 18 de septiembre de 2008 16:34, Héctor Suárez Planas < bolodia@medired.scu.sld.cu mailto:bolodia@medired.scu.sld.cu> escribió:
...
Hector, conoces LinNeighborhood?, es excelente para acceder a
recursos
compartidos en servidores de archivo Samba.
Sí, pero no es exactamente lo que necesito. Te explico.
Entre un amigo mío y yo montamos un Fedora Directory Server 1.0.4 en un servidor con CentOS 5.2 y configuramos el Samba como PDC usando al FDS como almacén de usuarios y contraseñas. O sea, un "dominio" en Linux.
Los datos de los usuarios y las contraseñas las tomamos de un servidor Active Directory que está en funcionamiento, o sea, logramos sincronizar los usuarios y contraseñas del ADS con el FDS.
Además de eso, existe un servidor de archivos donde se encuentran los perfiles de usuarios al cuál se conectan las estaciones de trabajo Windows montando en una unidad el recurso compartido que apunta al perfil del usuario.
Lo que quiero hacer es lograr que cuando un usuario autentique en su estación de trabajo, tomar ese mismo token y montar en un subdirectorio local el recurso compartido del servidor de archivos (el perfil del usuario) mediante el comando mount.cifs. He leído que cuando no se especifica las opciones del usuario y la contraseña, estos se toman de las variables de entorno $USER y $PASSWD.
La ventaja que tengo es que el usuario que se encuentra en el Fedora Directory Server tiene un equivalente en el Active Directory y quiero seguir usando el mismo servidor de archivos para no afectar el servicio.
Hasta ahora me da un error de permisos:
mount error 13 = Permission denied Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
Red Telematica de Salud - Cuba CNICM - Infomed
CentOS-es mailing list CentOS-es@centos.org mailto:CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
-- Carlos Restrepo M.
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Saludos hermano.
Hola...
Este links tiene toda la documentación que necesitas para la implementación de FDS.
Otro que está suavecito para digerir es el de Wilmer Jaramillo.
http://wiki.fedora-ve.org/WilmerJaramillo
Y en español para el que tenga problemas o no le guste el inglés.
:)
--------------------------------------- Red Telematica de Salud - Cuba CNICM - Infomed
...
Compañero, vas bién enfocado, estos links te ayudara a implementar ACL'S:
http://dns.bdat.net/documentos/samba/acls-linux-samba/x115.html
Gracias hermano. Las imprimiré y las leeré.
--------------------------------------- Red Telematica de Salud - Cuba CNICM - Infomed
-
carlos restrepo -
Héctor Suárez Planas -
Solucions Informatiques JM SL -
Wilder Deza