Integración de redes con OpenLDAP, Samba, CUPS y PyKota Sergio González González Instituto Politécnico de Bragança, Portugal Copyright © 2004 Sergio González González Trabajo realizado para la asignatura Gestão de Sistemas e Redes y ampliado para la asignatura Comunicações por Computador II, ambas pertenecientes a la carrera Ingeniería Informática impartida en la Escola Superior de Tecnologia e de Gestão de Bragança del Instituto Politécnico de Bragrança, Portugal. Este documento muestra los pasos necesarios para conseguir la integración de una red compuesta por equipos con sistemas operativos GNU/Linux y MS Windows. Las herramientas empleadas para conseguir dicha integración han sido: OpenLDAP, Samba, CUPS y PyKota. Esta obra está bajo una licencia de Creative Commons (Reconocimiento-CompartirIgual 2.0 España). Usted es libre de: * copiar, distribuir y comunicar públicamente la obra * hacer obras derivadas * hacer un uso comercial de esta obra Bajo las condiciones siguientes: * Reconocimiento. Debe reconocer y citar al autor original. * Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. * Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. * Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor. Los derechos derivados de usos legítimos u otras limitaciones no se ven afectados por lo anterior. Esto es un resumen legible por humanos del texto legal (la licencia completa) disponible en el apéndice: Creative Commons, legal code: Reconocimiento-CompartirIgual 2.0. _________________________________________________________ Tabla de contenidos Prefacio 1. introducción 2. Organización 2.1. OpenLDAP 2.2. Samba 2.3. CUPS 2.4. PyKota 2.5. Apéndices 3. Convenciones utilizadas en esta documentación 4. Agradecimientos I. OpenLDAP 1. Conceptos teóricos 1.1. Introducción 1.2. ¿Qué es un servicio de directorios? 1.3. ¿Qué es LDAP? 1.4. ¿Cómo trabaja LDAP? 1.5. Sobre X.500 1.6. ¿Cuál es la diferencia entre LDAPv2 y LDAPv3? 1.7. ¿Qué es slapd y qué puede hacer? 1.8. ¿Qué es slurpd y que puede hacer? 1.9. Información adicional sobre el proyecto 2. Instalación 2.1. Consideraciones previas 2.2. Pasos para la instalación 2.3. Comprobaciones iniciales de la instalación 3. Retoques iniciales a la configuración por defecto de OpenLDAP 3.1. /etc/default/slapd 3.2. /etc/ldap/ldap.conf 3.3. /etc/ldap/slapd.conf 4. Preparando la conexión segura 4.1. Introducción 4.2. Creación de un certificado 4.3. Configuración de OpenLDAP 4.4. Solución temporal a los problemas de OpenLDAP en Debian GNU/Linux 4.5. Probando el servidor en modo seguro 5. Autentificación de usuarios a través de OpenLDAP 5.1. Introducción 5.2. Instalación del software necesario 5.3. Configuración de los archivos necesarios II. Samba 6. Conceptos teóricos 6.1. Introducción 6.2. ¿Qué es Samba? 6.3. ¿Qué puede hacer Samba por mí? 6.4. Familiarizándose con una red SMB 6.5. Grupos de trabajo y dominios Windows 6.6. Novedades de Samba 2.2 6.7. Novedades de Samba 3.0 6.8. ¿Qué puede hacer Samba? 6.9. Visión general de la distribución Samba 6.10. Información adicional sobre el proyecto 7. Instalación 7.1. Consideraciones previas 7.2. Pasos para la instalación 8. Primeros ajustes en la configuración de OpenLDAP 9. Configuración de Samba 9.1. Introducción 9.2. Estructura del archivo smb.conf 9.3. Ajustando el archivo de configuración de Samba 10. Ajustes finales en el sistema 10.1. Introducción 10.2. Estableciendo la clave del administrador de LDAP 10.3. Nueva regla de control de acceso en /etc/ldap/slapd.conf 10.4. Especificación de nuevos índices en /etc/ldap/slapd.conf 10.5. Creando la estructura de directorios en el home 11. Comprobando que todo funciona 11.1. Introducción 11.2. Verificación del archivo de configuración y reinicio de los demonios 11.3. Adición de un usuario al sistema 11.4. Acceso con la nueva cuenta en un sistema Unix 11.5. Acceso con la nueva cuenta a Samba 12. Añadiendo clientes al dominio 12.1. Introducción 12.2. Windows 95/98/ME 12.3. Windows NT 12.4. Windows 2000 12.5. Windows XP III. CUPS 13. Conceptos teóricos 13.1. Introducción 13.2. Trasfondo histórico 13.3. Historia 13.4. Una visión general sobre el diseño 13.5. Impresión en red 13.6. Nuevas características en CUPS 1.1 13.7. Información adicional sobre el proyecto 14. Instalación 14.1. Introducción 14.2. Elección de los paquetes necesarios 14.3. Instalando los paquetes 15. Configuración 15.1. Introducción 15.2. Comprobaciones iniciales 15.3. Modificaciones en la configuración del sistema 15.4. Creación de la estructura de impresión 15.5. Instalación de los controladores de impresión para los equipos MS Windows 15.6. Impresión desde Samba IV. PyKota 16. Visión general 16.1. Introducción 16.2. Aplicaciones existentes 16.3. Características y funcionalidades de PyKota 16.4. Información adicional sobre el proyecto 17. Obtención del código fuente y generación de un paquete deb 17.1. Introducción 17.2. Generación de un paquete deb para PyKota 18. Instalación 18.1. Introducción 18.2. Instalación del paquete 19. Retoques iniciales en el sistema 19.1. Introducción 19.2. Modificaciones en la configuración de slapd 19.3. Creación de la estructura para PyKota en LDAP 20. Configuración 20.1. Introducción 20.2. Usuarios de pykota 20.3. Repaso sobre las principales opciones de configuración 21. Modificaciones en las impresoras de CUPS 21.1. Introducción 21.2. Modificación del archivo /etc/cups/printers.conf 21.3. Añadiendo una impresora bajo el control de PyKota 22. Estableciendo las cuotas de impresión 22.1. Introducción 22.2. Estableciendo los precios en las impresoras 22.3. Gestionando los usuarios 23. Probando el sistema de cuotas 23.1. Introducción 23.2. Usuario printquota 23.3. usuario printsaldo V. Misceláneo A. Creación y configuración de un usuario de sólo lectura para el directorio LDAP A.1. Introducción A.2. Creación A.3. Configuración B. Demonio de caché para el servicio de nombres: nscd B.1. Introducción B.2. Instalación B.3. Configuración C. Ejecución de Samba desde (x)inetd C.1. Introducción C.2. Superservidor inetd C.3. Superservidor xinetd D. Opciones del kernel Linux para Samba D.1. Kernel 2.4.* D.2. Kernel 2.6.* E. Instalación y configuración de SWAT E.1. Introducción E.2. Instalación de SWAT E.3. Gestión de SWAT desde un superservidor (x)inetd E.4. Accediendo a SWAT F. Instalación y configuración de LAM (LDAP Account Manager) F.1. Instalación F.2. Configuración G. Instalación y configuración de phpLDAPadmin G.1. Instalación G.2. Configuración G.3. Acceso a la aplicación H. Instalación y configuración de smbldap-tools H.1. Introducción H.2. Instalación H.3. Configuración I. Preparación de Apache para el uso de SSL I.1. Introducción I.2. Generación de la entidad certificadora y los certificados I.3. Configuración de Apache J. Cambio para el registro de Windows XP (miembro de un dominio Samba) K. Script para la creación/eliminación de los homes de los usuarios L. Script para convertir a mayúsculas el archivo pasado como argumento M. Script para mover los controladores PostScript de Adobe al directorio /usr/share/cups/drivers N. Salida de la ejecución de la orden /usr/sbin/cupsaddsmb -v -U root -a O. Ejemplo de certificado para un servidor VI. Archivos de configuración P. Opciones de compilación de OpenLDAP en Debian GNU/Linux Q. Archivo de configuración /etc/ldap/slapd.conf R. Archivo de configuración /etc/ldap/ldap.conf S. Archivo de configuración /etc/default/slapd T. Archivo de configuración /etc/nsswitch.conf U. Archivo de configuración /etc/pam_ldap.conf V. Archivo de configuración /etc/libnss-ldap.conf W. Archivo de configuración /etc/pamd.d/common-account X. Archivo de configuración /etc/pamd.d/common-auth Y. Archivo de configuración /etc/pamd.d/common-password Z. Archivo de configuración /etc/pamd.d/common-session AA. Archivo de configuración /etc/nscd.conf AB. Archivo de configuración /etc/default/samba AC. Archivo de configuración /etc/samba/smb.conf - por defecto - AD. Archivo de configuración /etc/samba/smb.conf - Completo - AE. Archivo de configuración /etc/cups/client.conf AF. Archivo de configuración /etc/cups/cupsd.conf AG. Archivo de configuración /etc/pykota/pykota.conf AH. Archivo de configuración /etc/pykota/pykotadmin.conf AI. Archivo de configuración /var/www/phpldapadmin/config.php AJ. Archivo de configuración /var/www/phpldapadmin/templates/template_config.p hp AK. Archivo de configuración /etc/smbldap-tools/smbldap.conf AL. Archivo de configuración /etc/smbldap-tools/smbldap_bind.conf AM. Archivo de configuración /etc/apache/conf.d/mod_ssl-00-global.conf AN. Archivo de configuración /etc/apache/conf.d/vhost.conf AO. Archivo de configuración /etc/hosts.allow AP. Archivo de configuración /etc/hosts.deny VII. Licencias AQ. Creative Commons, legal code: Reconocimiento-CompartirIgual 2.0 0. Licencia AR. GNU General Public License AR.1. Preamble AR.2. TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION AS. GNU LESSER GENERAL PUBLIC LICENSE AS.1. Preamble AS.2. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION AT. The OpenLDAP Public License VIII. Derechos de copia AU. Derechos de copia de OpenLDAP AU.1. Derechos de copia de: Kurt D. Zeilenga, Net Boolean Incorporated e IBM Corporation AU.2. Derechos de copia de: Howard Y.H. Chu, Symas Corporation y Hallvard B. Furuseth AU.3. Derechos de copia de: Regents of the University of Michigan AV. Common UNIX Printing System License Agreement AV.1. INTRODUCTION AV.2. LICENSE EXCEPTIONS AV.3. TRADEMARKS AV.4. BINARY DISTRIBUTION RIGHTS AV.5. SUPPORT AW. Derechos de copia de Pykota (Print Quota for CUPS and LPRng) Bibliografía Glosario de términos Lista de tablas 2-1. Niveles de depurado de slapd 4-1. Directivas de configuración de clientes LDAP 4-2. Resumen de configuración SSL en LDAP 6-1. Tipos de nodo NetBIOS 6-2. Tipos de recursos únicos NetBIOS 6-3. Tipos de Recursos de Grupo NetBIOS 6-4. Primitivas de datagrama 6-5. Primitivas de sesión 6-6. Roles de Samba en la versión 3.0 16-1. Comparativa entre 4 sistemas de quotas de impresión 22-1. Cuotas que se establecerán en las impresoras Lista de figuras 1-1. Árbol del directorio LDAP (nombramiento tradicional)[2] 1-2. Árbol del directorio LDAP (nombramiento de Internet)[3] 2-1. Configuración de slapd mediante debconf 2-2. Configuración de slapd, elección del dominio 2-3. Configuración de slapd, nombre de la organización 2-4. Configuración de slapd, clave de administrador 2-5. Configuración de slapd, repetir clave de administrador 2-6. Configuración de slapd, elección del backend de la BBDD 2-7. Configuración de slapd, ¿conservar los datos al desinstalarlo? 2-8. Configuración de slapd, ¿mover los datos antiguos? 2-9. Configuración de slapd, protocolo LDAPv2 4-1. Captura de la clave del administrador del directorio LDAP con ethereal 5-1. Dirección del servidor LDAP 5-2. Nombre distintivo de la base de búsquedas 5-3. Versión del protocolo LDAP 5-4. Método de acceso a la base de datos 5-5. Permisos del archivo de configuración 5-6. Información sobre libnss-ldap 5-7. URL del servidor LDAP 5-8. Nombre distintivo de la base de búsquedas 5-9. Versión del protocolo LDAP 5-10. Comportamiento a la hora del cambio de claves 5-11. ¿Necesita autentificación la conexión con la base de datos? 5-12. Administrador de LDAP 5-13. Clave del administrador de LDAP 5-14. Elección el método de cifrado para las claves 6-1. Configuración de red simple con un servidor Samba[17] 6-2. Entorno de red 6-3. Recursos compartidos por toltec vistos desde maya 6-4. Mapeo de una unidad de red en una letra de unidad Windows 6-5. Un directorio de red mapeado como la unidad J en el cliente 6-6. Recursos compartidos en toltec (vistos desde aztec) 6-7. Impresora en red disponible en toltec 6-8. Protocolos sobre los que corre SMB[22] 6-9. Registro de nombres Broadcast versus NBNS[23] 6-10. Resolución de nombres Broadcast versus NBNS[24] 6-11. Estructura de nombres NetBIOS[25] 6-12. Un simple dominio Windows[28] 6-13. Un dominio Windows con un buscador maestro local y uno de respaldo[30] 6-14. Grupo de trabajo que abarca más de una subred[31] 7-1. Configuración del grupo de trabajo/dominio de samba mediante debconf 7-2. ¿Contraseñas cifradas? 7-3. ¿Utilizar la información del DHCP para configurar WINS? 7-4. ¿Cómo ejecutar Samba (demonios/inetd)? 7-5. Creación de la base de datos de contraseñas 11-1. URL donde está instalado LAM 11-2. Aviso acerca del certificado del servidor web I 11-3. Información SSL 11-4. Aviso acerca del certificado del servidor web II 11-5. Período de aceptación del certificado 11-6. Ingreso en LAM 11-7. Edición de perfiles 11-8. Edición de un perfil de usuario 11-9. Opciones de las cuentas (primera parte) 11-10. Opciones de las cuentas (segunda parte) 11-11. Perfil guardado 11-12. Creación de un nuevo usuario 11-13. Selección del perfil 11-14. Datos generales 11-15. Datos generales, completado automático de información 11-16. Propiedades sobre Unix 11-17. Propiedades sobre Samba (primera parte) 11-18. Propiedades sobre Samba (segunda parte) 11-19. Propiedades personales 11-20. Creación del usuario 11-21. Usuario creado 11-22. Lista de usuarios 11-23. Dirección de acceso a los recursos de Samba 11-24. Clave del usuario gsruser 11-25. Recursos compartidos 12-1. Acceso a la herramienta LDAP Account Manager 12-2. Ingreso en LAM 12-3. Sección Hosts 12-4. Crear nueva máquina 12-5. Completado de los campos 12-6. Corrección de los "errores" cometidos 12-7. Cuenta creada 12-8. Lista de Hosts 12-9. "Inicio" 12-10. "Configuración" 12-11. "Panel de Control" 12-12. "Red" 12-13. Cuadro de diálogo "Red" 12-14. Miembro de dominio 12-15. Nombre del dominio 12-16. Bienvenida 12-17. Cierre del cuadro de diálogo "Red" 12-18. Reinicio del sistema 12-19. Ctrl+Alt+Supr 12-20. Selección del nuevo dominio 12-21. "Inicio" 12-22. "Conexiones de Red" 12-23. "Identificación de Red" 12-24. Selección del dominio 12-25. Cuenta para añadir la máquina al dominio 12-26. Bienvenida al dominio 12-27. Preparándose para el reinicio 12-28. Solicitud de reinicio 12-29. Ctrl+Alt+Supr 12-30. Selección del nuevo dominio 12-31. Cuenta de dominio 12-32. Entrando en el sistema 12-33. Conexiones de Red e Internet 12-34. Conexiones de Red 12-35. Identificación de Red 12-36. Propiedades del Sistema 12-37. Selección del Dominio 12-38. Cuenta del dominio 12-39. Bienvenida al dominio 13-1. Diagrama de la organización interna de CUPS[32] 14-1. Backend de impresión para Foomatic 14-2. Configuración del filtro de impresión Foomatic 14-3. Selección del intérprete Ghostscript 14-4. Insertar información de contabilidad en cada trabajo 14-5. Trabajos sin tipo MIME 14-6. Selección de backends para CUPS 14-7. Compatibilidad lpd de BSD 15-1. Estructura de la red de impresión 15-2. Accediendo a la interfaz de administración web de CUPS 15-3. Aviso acerca del certificado del servidor web I 15-4. Información SSL 15-5. Aviso acerca del certificado del servidor web II 15-6. Período de aceptación del certificado 15-7. Administrando impresoras 15-8. Añadir nueva impresora 15-9. Clave del administrador 15-10. Información sobre la impresora 15-11. Dispositivo de impresión I 15-12. Dispositivo de impresión II 15-13. Modelo 15-14. Controlador 15-15. Nueva impresora lista 15-16. Información sobre la impresora LaserColor 15-17. Arrancando el administrador de impresión 15-18. Administrador de impresión 15-19. Nueva impresora 15-20. Bienvenida al asistente de impresión de KDE 15-21. Selección del tipo de impresora 15-22. URI de la impresora 15-23. Reconstruyendo la base de datos de controladores 15-24. Modelo de la impresora 15-25. Probando la impresora I 15-26. Opciones de configuración del controlador de impresión 15-27. Probando la impresora II 15-28. Usuario con privilegios de administración de impresión 15-29. Prueba enviada a la impresora 15-30. Prueba de impresión 15-31. Selección de rótulos 15-32. Cuotas de impresión 15-33. Permisos de acceso a la impresora 15-34. Información sobre la impresora 15-35. Confirmación 15-36. Nueva impresora LaserBN 15-37. Listado de impresoras 15-38. Accediendo a la interfaz de administración web de CUPS 15-39. Aviso acerca del certificado del servidor web I 15-40. Información SSL 15-41. Aviso acerca del certificado del servidor web II 15-42. Período de aceptación del certificado 15-43. Administrando clases 15-44. Clave del administrador 15-45. Añadiendo una clase 15-46. Información sobre la clase 15-47. Miembros de la clase 15-48. Nueva clase lista 15-49. Información sobre la clase Profesional 15-50. Arrancando el administrador de impresión 15-51. Administrador de impresión 15-52. Nueva clase 15-53. Bienvenida al asistente de impresión de KDE 15-54. Selección de la clase impresora 15-55. Composición de la clase 15-56. Información sobre la clase 15-57. Confirmación de la creación de la nueva clase 15-58. Nueva clase Color 15-59. Listado de clases 15-60. Realizando una prueba de impresión sobre una clase 15-61. Confirmación del envío de la prueba de impresión 15-62. Información de envío 15-63. Proceso de descompresión de los controladores y archivos de instalación 15-64. Comienza el proceso de instalación 15-65. Pantalla de bienvenida del instalador 15-66. Arrancando el administrador de impresión 15-67. Nueva impresora 15-68. Bienvenida al asistente de impresión de KDE 15-69. Selección del tipo de impresora 15-70. Usuario de acceso a la red Samba 15-71. Monitorizar la red 15-72. Selección de la impresora 15-73. Modelo de la impresora 15-74. Probando la impresora 15-75. Usuario con privilegios de administración de impresión 15-76. Prueba enviada a la impresora 15-77. Prueba de impresión 15-78. Selección de rótulos 15-79. Cuotas de impresión 15-80. Permisos de acceso a la impresora 15-81. Información sobre la impresora 15-82. Confirmación 15-83. Nueva impresora CompartidaSamba 18-1. Información de PyKota a través de debconf I 18-2. Información de PyKota a través de debconf II 18-3. Información de PyKota a través de debconf III 21-1. Añadiendo una impresora con soporte para PyKota 22-1. Informe de la impresora LaserColor 22-2. Informe de la impresora Sublimacion 23-1. Impresión de un documento de 5 páginas I 23-2. Impresión de un documento de 5 páginas II 23-3. Impresión de un documento de 5 páginas III 23-4. Impresión de un documento de 5 páginas IV 23-5. Impresión de un documento que supera la cuota disponible D-1. Sistema de archivos D-2. Sistema de archivos en red D-3. Opciones relativas Samba D-4. Sistema de archivos D-5. Sistema de archivos en red D-6. Opciones relativas Samba E-1. Aviso de sobreescritura del archivo /etc/samba/smb.conf E-2. Acceso a SWAT E-3. Autentificación E-4. Pantalla principal de SWAT F-1. ¿Arrancar Apache en el arranque? F-2. ¿Activar suExec? F-3. ¿Para qué servidor(es) web se ha de configurar LAM? F-4. Alias para el acceso a LAM desde el servidor web F-5. Clave para el administrador de los perfiles dentro de LAM F-6. Módulos que cargará Apache F-7. Nombre del dominio que servirá Apache por defecto F-8. Dirección de correo electrónico del administrador de Apache F-9. Directorio raíz de Apache por defecto F-10. Puerto de escucha de Apache F-11. Activar la extensión LDAP en PHP4 F-12. URL donde está instalado LAM F-13. Aviso acerca del certificado del servidor web I F-14. Información SSL F-15. Aviso acerca del certificado del servidor web II F-16. Período de aceptación del certificado F-17. Pantalla de ingreso F-18. Pantalla de configuración F-19. Asistente de configuración, datos del perfil F-20. Asistente de configuración, datos del servidor LDAP y Samba F-21. Asistente de configuración, creando la estructura para el directorio LDAP F-22. Asistente de configuración, confirmación de la creación de entradas LDAP F-23. Asistente de configuración, creación de un dominio F-24. Asistente de configuración, creación de grupos para Samba F-25. Información sobre el nuevo perfil creado F-26. Ingreso en LAM F-27. Pantalla principal de LAM F-28. Dominios existentes F-29. Grupos existentes F-30. Hosts existentes F-31. Saliendo de la herramienta G-1. ¿Qué tipo de autentificación desea? G-2. ¿Qué servidor web reconfigurar? G-3. ¿Reiniciar el servidor web? G-4. URL donde está instalado phpLDAPadmin G-5. Aviso acerca del certificado del servidor web I G-6. Información SSL G-7. Aviso acerca del certificado del servidor web II G-8. Período de aceptación del certificado G-9. Pantalla principal de phpLDAPadmin G-10. Autentificándose en phpLDAPadmin G-11. Autentificación realizada con éxito G-12. Árbol de contenidos del directorio G-13. Información sobre un objeto G-14. Creación de un nuevo objeto G-15. Finalizando la sesión Lista de ejemplos 1. Ejemplo de ejemplo 2-1. Instalación de los paquetes slapd ldap-utils (primera parte) 2-2. Instalación de los paquetes slapd ldap-utils (segunda parte) 2-3. Comprobación de que slapd está en la lista de procesos actuales 2-4. Comprobación de que slapd escucha en la red 2-5. Realización de una búsqueda simple con ldapsearch 2-6. Archivo /etc/hosts.allow 2-7. Archivo /etc/hosts.deny 2-8. Realización de una búsqueda simple con ldapsearch (conexión fallida) 2-9. Realización de una búsqueda simple con ldapsearch (modo depuración) 2-10. Ejecución del servidor slapd en modo de depuración 2-11. Ejecución del servidor slapd en modo de depuración (mensaje de rechazo de una conexión) 2-12. Ejecución del servidor slapd en modo de depuración (mensaje de aceptación de una conexión) 2-13. Ejecución del demonio slapd sin especificar la interfaz donde escuchar 2-14. Ejecución del demonio slapd especificando la interfaz donde escuchar 3-1. Creación de un grupo y usuario de sistema para slapd 3-2. Modo de parar el demonio slapd 3-3. Cambio del propietario/grupo en archivos relacionados con slapd 3-4. Asignación del usuario y grupo con que se ejecutará slapd 3-5. Arrancando el demonio slapd 3-6. Estableciendo las interfaces donde ha de escuchar slapd 3-7. Reinicio del demonio slapd 3-8. Configuración inicial del archivo /etc/ldap/ldap.conf 3-9. Estableciendo los permisos para /etc/ldap/ldap.conf 4-1. Creación de un certificado autofirmado para el servidor 4-2. Opciones de configuración para slapd.conf que añaden un certificado autofirmado en el servidor. 4-3. Creación de un directorio para crear y firmar los certificados 4-4. Creación de una entidad certificadora 4-5. Creación de la petición para la firma del certificado del servidor 4-6. Firma del CSR 4-7. Verificación de la firma creada en un certificado por una CA 4-8. Estructura de directorios final para los certificados 4-9. Líneas de configuración para un servidor SSL/TLS 4-10. Ejemplo de configuración de un archivo ldap.conf 4-11. Ejemplo de configuración de un archivo .ldaprc (en el home del usuario o en el directorio actual) 4-12. Esquemas en un archivo de configuración slapd.conf 4-13. Obtención del código fuente de OpenLDAP 4-14. Aplicando el parche a las fuentes de OpenLDAP 4-15. Resolviendo las dependencias de compilación para OpenLDAP 4-16. Compilando OpenLDAP 4-17. Listado de paquetes de OpenLDAP 4-18. Instalación de los nuevos paquetes de OpenLDAP 4-19. Comprobando la conexión SSL sin autentificación del cliente 4-20. Comprobando la conexión SSL con autentificación del cliente 4-21. Incorporación de datos al directorio LDAP por medio de un archivo LDIF 4-22. Devuelve todas las entradas del directorio 4-23. Devuelve algunas entradas del directorio 5-1. Instalación de libnss-ldap 5-2. Instalación de libnss-ldap (primera parte) 5-3. Instalación de libnss-ldap (segunda parte) 5-4. Información sobre el paquete libpam-ldap 5-5. Instalación de libpam-ldap (primera parte) 5-6. Instalación de libpam-ldap (segunda parte) 5-7. Creación del directorio /etc/ldap.secret 5-8. Modificaciones en el de configuración /etc/nsswitch.conf 5-9. Opciones de configuración para /etc/pam.d/common-account 5-10. Opciones de configuración para /etc/pam.d/common-auth 5-11. Opciones de configuración para /etc/pam.d/common-session 5-12. Opción para crear directorios home al vuelo 5-13. Opciones de configuración para /etc/pam.d/common-password 5-14. Comprobando la configuración del sistema con pamtest 6-1. Representación de un directorio en una máquina de red 6-2. Notación UNC (Universal Naming Convention) 6-3. Muestra de la salida de la orden smbstatus 6-4. Notación empleada para mostrar el tipo de servicio NetBIOS ofrecido por un ordenador 6-5. Ejecución de la orden nbtstat 6-6. Muestra de los grupos a los que pertenece un servidor con nbtstat 6-7. Notación UNC 6-8. Muestra de un SID (Security IDentifier) 7-1. Información sobre el paquete "samba" 7-2. Información sobre el paquete "samba-common" 7-3. Instalación de "samba" (primera parte) 7-4. Instalación de "samba" (segunda parte) 7-5. Configuración preliminar de "samba" 7-6. Información sobre los paquetes "smbclient" y "smbfs" 7-7. Instalación de "smbclient" y "smbfs" 7-8. Herramientas suministradas por los paquetes "smbclient" y "smbfs" 8-1. Instalación del paquete "samba-doc" 8-2. Copiado del esquema de Samba al directorio de esquemas de OpenLDAP 8-3. Reinicio del demonio slapd 9-1. Un archivo smb.conf mínimo 9-2. Comprobando el archivo por defecto smb.conf con testparm 9-3. [print$] - Subdirectorios para las distintas arquitecturas 10-1. Especificando la clave del administrador de LDAP en Samba 10-2. Regenerando los índices de slapd 10-3. Reiniciando el servidor slapd 10-4. Creación de los directorios necesarios para Samba 11-1. Comprobando la nueva configuración (soporte LDAP) 11-2. Releyendo la configuración de Samba 11-3. Reinicio los demonios de Samba 11-4. Acceso a una shell Unix por ssh 11-5. Mostrando los recursos compartidos con smbclient 11-6. Accediendo a un recurso compartido con smbclient 12-1. Estableciendo la clave de root en Samba 14-1. Descripción del paquete cupsys 14-2. Descripción del paquete gs-esp 14-3. Descripción de los paquetes gsfonts y psfontmgr 14-4. Descripción del paquete cupsys-client 14-5. Descripción del paquete kdeprint 14-6. Descripción del paquete cupsys-bsd 14-7. Descripción del paquete cupsys-driver-gimpprint 14-8. Descripción de los paquetes gimpprint-locales y cupsys-driver-gimpprint-data 14-9. Descripción del paquete foomatic-bin 14-10. Descripción de los paquetes foomatic-db 14-11. Descripción de los paquetes foomatic-db-gimp-print y foo2zjs 14-12. Descripción del paquete foomatic-db-hpijs 14-13. Descripción de los paquetes foomatic-db-engine 14-14. Descripción de los paquetes netcat y foomatic-gui 14-15. Descripción del paquete foomatic-filters 14-16. Descripción del paquete cupsomatic-ppd 14-17. Descripción del paquete foomatic-filters-ppds 14-18. Instalación del sistema de impresión CUPS (primera parte) 14-19. Instalación del sistema de impresión CUPS (segunda parte) 14-20. Instalación del paquete cups-pdf 15-1. Verificando que Samba se ha compilado con soporte para CUPS 15-2. Diferencia entre la configuración de Samba antes y después de instalar CUPS 15-3. Copiando el contenido del directorio /etc/ldap/ssl/ a /etc/cups 15-4. Reinicio del servidor CUPS 15-5. Desempaquetado de los controladores PostScript de CUPS 15-6. Desempaquetado de los controladores PostScript de CUPS en el directorio /usr/share/cups/drivers/ 15-7. Ejecución del instalador de controladores PostScript de Adobe con Wine (primera parte) 15-8. Ejecución del instalador de controladores PostScript de Adobe con Wine (segunda parte) 15-9. Convirtiendo a mayúsculas los controladores PostScript de Adobe 15-10. Copiando los controladores PostScript de Adobe a /usr/share/cups/drivers 15-11. Exportando los controladores de impresión con cupsaddsmb 15-12. Recursos compartidos por Samba, tras la instalación de CUPS 17-1. Aplicación del parche de modificaciones al código de PyKota 17-2. Generando el paquete deb de PyKota 18-1. Instalación del paquete pykota 19-1. Regenerando los índices de LDAP y reiniciando el demonio slapd 19-2. Creando la estructura para PyKota en LDAP 20-1. Añadiendo los usuarios relativos a PyKota en el directorio LDAP 22-1. Estableciendo los precios en las impresoras con pkprinters 22-2. Estableciendo una cuota de impresión a un usuario 22-3. Asignando un saldo de impresión a un usuario 23-1. Revisando la cuota de impresión del usuario printquota I 23-2. Correo de aviso enviado al usuario printquota - límite suave sobrepasado - 23-3. Correo de aviso enviado al administrador - cuota de impresión baja - 23-4. Correo de aviso enviado al usuario printquota - límite duro sobrepasado - 23-5. Correo de aviso enviado al administrador - cuota de impresión excedida - 23-6. Revisando la cuota de impresión del usuario printquota 23-7. Revisando la cuota de impresión del usuario printquota 23-8. Correo de aviso enviado al usuario printquota - límite blando sobrepasado - 23-9. Correo de aviso enviado al administrador - cuota excedida - 23-10. Reinicio de la cuota de impresión para el usuario printquota 23-11. Información sobre la cuota del usuario printquota, tras su reinicio I 23-12. Información sobre la cuota del usuario printquota, tras su reinicio II 23-13. Coste de impresión de un documento A-1. Creación del usuario readadmin B-1. Instalación de nscd B-2. Instalación de nscd B-3. Creación del usuario nscd B-4. Cambio del propietario y grupo de algunos archivos relativos a nscd B-5. Arranque del demonio nscd C-1. Habilitando el servicio "netbios-ssn" en el superservidor inetd C-2. Haciendo que el superservidor inetd relea su configuración C-3. Contenido del archivo /etc/xinetd.d/samba C-4. Releyendo la configuración de xinetd E-1. Instalación de SWAT (primera parte) E-2. Instalación de SWAT (segunda parte) E-3. Activación de SWAT en inetd E-4. Haciendo que el superservidor inetd relea su configuración E-5. Mostrando las conexiones de SWAT E-6. Contenido del archivo /etc/xinetd.d/swat E-7. Releyendo la configuración de xinetd E-8. Mostrando las conexiones de SWAT F-1. Descripción de LAM F-2. Instalación de LAM (primera parte) F-3. Instalación de LAM (segunda parte) F-4. Instalación de LAM (tercera parte) F-5. Instalación de LAM (cuarta parte) F-6. Releyendo la configuración de Apache F-7. Obtención del SID G-1. Descripción de phpLDAPadmin G-2. Instalación del paquete phpldapadmin (primera parte) G-3. Instalación del paquete phpldapadmin (segunda parte) G-4. Releyendo la configuración de Apache G-5. Modificaciones realizadas al archivo template_config.php H-1. Instalación del paquete smbldap-tools H-2. Descripción del paquete smbldap-tools H-3. Herramientas que provee el paquete smbldap-tools H-4. Copiando los archivos de configuración de smbldap-tools a /etc/smbldap-tools I-1. Creación del certificado para el servidor Apache I-2. Preparación para la configuración del módulo mod_ssl de Apache I-3. Reinicio del servidor Apache _________________________________________________________ Prefacio 1. introducción Está leyendo un documento sobre la integración de las tecnologías OpenLDAP, Samba, CUPS y PyKota en un sistema Debian GNU/Linux. Por si no tiene conocimiento de qué realizan cada una de estas tecnologías, de forma muy resumida, se muestra a continuación: * OpenLDAP. es una implementación open source del protocolo LDAP (Lightweight Directory Access Protocol). * Samba. es una suite que permite la interconexión, a través de la red, de sistemas Windows, Unix y otros sistemas operativos, haciendo uso de los protocolos de red nativos de Windows. * CUPS. acrónimo de Common Unix Printing System, es un sistema de impresión portable y extensible para Unix. * PyKota. PyKota es una aplicación GPL para dar soporte de cuotas de impresión a CUPS y LPRng (LPR Next Generation) en sistemas GNU/Linux y similares a Unix. Si alguna vez ha tenido que realizar labores de administración en redes heterogéneas, en las cuales existan múltiples clientes, y cada uno de ellos pueda tener un sistema operativo distinto, sobre el cual puedan operar una infinidad de usuarios; se habrá dado cuenta de la complejidad que esto conlleva. Por poner un simple ejemplo, si no posee una base de datos de usuarios común a todos los clientes, tendría que dar de alta a cada nuevo cliente en cada una de las máquinas que quisiese utilizar. Piense ahora que ocurriría si, por un cambio de política de su empresa, se tenga que modificar cierto aspecto en todas las cuentas de los usuarios existentes... Si entramos en la compartición de archivos entre los distintos usuarios, o el almacenamiento de los documentos de un determinado usuario, que puede utilizar múltiples clientes, la cosa se complica. Y si a todo esto se le añade la gestión de las cuotas de impresión de todos y cada uno de los usuarios, se hace necesario buscar un método que facilite, en la medida de lo posible, la labor de administración. Este documento intenta presentar un método para facilitar la integración de este tipo de redes. La idea es utilizar un directorio LDAP como base de datos común para almacenar la información relativa a los usuarios (bien sea la información personal, la relativa a las cuentas Unix, la relativa a las cuentas Samba/Windows o bien las cuotas de impresión asociadas a un usuario o grupo de usuarios). Samba proveerá la integración de redes Unix/Windows, de forma que se simplifique sobremanera el intercambio y almacenamiento de información de los usuarios. Samba permitirá, por ejemplo, tener un único HOME por usuario, independientemente del cliente que se utilice. También actuará como PDC (Servidor Primario de Dominio) de la red donde se encuentre, entre otras cosas. Con CUPS y PyKota se implementará el sistema de impresión con soporte para cuotas. Y si a estas dos herramientas se las integra con Samba y LDAP, se estará posibilitando la impresión y el control de impresión a todos los usuarios, independientemente del sistema operativo utilizado. _________________________________________________________ 2. Organización Este documento está organizado, principalmente, en 5 grandes bloques: la parte dedicada a OpenLDAP, la parte dedicada a Samba, la parte dedicada a CUPS, la parte dedicada a PyKota y los apéndices. A continuación se verá una breve descripción para cada una de estas partes: _________________________________________________________ 2.1. OpenLDAP Este apartado (Parte I en Integración de redes con OpenLDAP, Samba, CUPS y PyKota) está formado por 5 capítulos: * Capítulo 1: capítulo introductorio al protocolo LDAP y su funcionamiento, así como la descripción de los demonios slapd y slurpd, pertenecientes al proyecto OpenLDAP. Finalmente se proporciona información relativa al proyecto OpenLDAP. * Capítulo 2: la instalación de OpenLDAP, la ejecución del demonio slapd y la conexión con el servidor LDAP, son los temas tratados en este capítulo. * Capítulo 3: primeras modificaciones realizadas sobre la instalación de OpenLDAP: cambio de usuario de ejecución para el demonio slapd, especificación de las interfaces donde escuchar y permisos que debería tener los archivos de configuración. * Capítulo 4: la conexión segura con el servidor OpenLDAP se trata en este capítulo, que va desde la creación de los certificados, pasando por la configuración de OpenLDAP para que soporte conexiones cifradas, para finalizar con una serie de pruebas sobre el sistema. * Capítulo 5: modificaciones y software necesario para que un sistema Unix permita la autentificación de usuarios a partir de un directorio LDAP. _________________________________________________________ 2.2. Samba Este apartado (Parte II en Integración de redes con OpenLDAP, Samba, CUPS y PyKota) está formado por 7 capítulos: * Capítulo 6: capítulo que describe, en primer lugar las capacidades de Samba, luego describe los aspectos más importantes de las redes SMB/CIFS y dominios de Windows, para finalizar con un breve informe sobre el proyecto Samba. * Capítulo 7. Instalación de los paquetes necesarios para la ejecución de un servidor Samba. * Capítulo 8. Breve capítulo dedicado a las modificaciones que se han de realizar en la configuración de OpenLDAP, para que Samba pueda hacer uso de dicho directorio para el almacén de su información relativa. * Capítulo 9. Inicialmente explica la estructura de un archivo de configuración para Samba, para terminar con un repaso por las principales opciones de configuración de Samba, relacionadas con los objetivos de esta documentación. * Capítulo 10. Modificaciones finales sobre la configuración de OpenLDAP y sobre el sistema que aloja a Samba. * Capítulo 11, en este capítulo se hacen una serie de pruebas al sistema. Estas consisten en la verificación del archivo de configuración de Samba, la creación de un nuevo usuario y verificación de acceso al sistema con el nuevo usuario. * Capítulo 12. Este capítulo explica el proceso que se ha de seguir para añadir clientes Windows 95/98/ME, Windows NT, Windows 2000 y Windows XP al dominio de Samba. _________________________________________________________ 2.3. CUPS Este apartado (Parte III en Integración de redes con OpenLDAP, Samba, CUPS y PyKota) está formado por 3 capítulos: * Capítulo 13: capítulo que hace un breve recorrido por la historia de CUPS, explicando seguidamente las características del diseño de este sistema de impresión para finalizar con un breve informe sobre el proyecto CUPS. * Capítulo 14. La instalación de CUPS comienza con un análisis y selección de los paquetes existentes en Debian, seguido de la instalación de los paquetes seleccionados. * Capítulo 15. Aquí se realiza la configuración de CUPS, preparándolo para el soporte de OpenLDAP, creando nuevas impresoras e instalando los drivers necesarios para los clientes Windows. _________________________________________________________ 2.4. PyKota Este apartado (Parte IV en Integración de redes con OpenLDAP, Samba, CUPS y PyKota) está formado por 8 capítulos: * Capítulo 16: capítulo que muestra, inicialmente, una comparativa con otros sistemas de control de cuotas de impresión. Luego repasa las características y funcionalidades de PyKota para terminar con un breve informe sobre el proyecto PyKota. * Capítulo 17. Este capítulo muestra el proceso que se ha de seguir para obtener un un paquete deb de PyKota, a partir de su código fuente. * Capítulo 18. Instalación del paquete deb de PyKota. * Capítulo 19: retoques realizados en la configuración de OpenLDAP para que soporte el almacenamiento de los datos de PyKota. * Capítulo 20. Breve repaso sobre los aspectos más importantes para la configuración de PyKota. * Capítulo 21. Modificaciones realizadas en CUPS para el soporte de cuotas de impresión con PyKota. * Capítulo 22. Aquí se establecen los precios de impresión así como las cuotas de los usuarios. * Capítulo 23: capítulo en el que se realiza una prueba sobre el sistema de cuotas de impresión. _________________________________________________________ 2.5. Apéndices Este apartado está formado por 4 grupos de apéndices: * Parte V en Integración de redes con OpenLDAP, Samba, CUPS y PyKota, en este apéndice se tratan temas adicionales a la documentación, como funcionalidades extra o distintas a las mostradas en la documentación, como instalar determinado software o la disponibilidad de los scripts utilizados para la realización de esta documentación, entre otras cosas. * Parte VI en Integración de redes con OpenLDAP, Samba, CUPS y PyKota, aquí se pueden encontrar los archivos de configuración más importantes de las aplicaciones empleadas en esta documentación. * Parte VII en Integración de redes con OpenLDAP, Samba, CUPS y PyKota, licencias relacionadas, de alguna manera, con el software utilizado para la realización de esta documentación, así como la licencia de la documentación en sí. * Parte VIII en Integración de redes con OpenLDAP, Samba, CUPS y PyKota, información sobre los derechos de copia de los distintos programas utilizados para la generación de esta documentación. _________________________________________________________ 3. Convenciones utilizadas en esta documentación Las siguientes convenciones de texto se utilizan a lo largo de todo el documento: nombre-de-un-archivo: representa el nombre de un archivo. nombre-de-un-directorio: representa el nombre de un directorio. nombre-aplicacion: indica el nombre de una aplicación. orden: indica el nombre de una orden, o la ejecución de una orden con algunos parámetros asociados. cursiva: todo aquel texto que por alguna razón necesita ser remarcado sobre el resto, bien sea por ser un anglicismos, bien por ser el nombre de un usuario del sistema. "texto-entre-comillas": todo aquel texto que por alguna razón necesita ser remarcado sobre el resto, bien sea por ser un anglicismos, bien por ser el nombre de un usuario del sistema. ACRÓNIMO: palabra que representa un acrónimo. Alt+F2: indica la pulsación simultánea de las teclas Alt y F2. (1) : resalta una parte de un texto, que posteriormente tendrá una breve explicación. Bloque de texto, utilizado para resaltar en algún momento un trozo de texto. Nota Indica un apunte sobre el tema que se esté tratando cerca de este texto. Sugerencia Sugiere algo relativo al texto cercano. Importante Informa de algo a tener en cuenta con respecto al texto cercano. Aviso Advierte algo relativo al texto cercano. $ -> prompt del sistema, en este caso representa la ejecución de código como un usuario cualquiera del sistema, no el usuario root. # -> prompt del sistema, en este caso representa la ejecución de código como el usuario root. /usr/bin/tree -L 1 / -> Representa las órdenes tecleadas por el usuario. / |-- bin |-- boot |-- cdrom -> media/cdrom |-- dev |-- etc |-- home |-- initrd |-- lib |-- lib64 |-- media |-- mnt |-- nonexistent |-- opt |-- proc |-- root |-- sbin |-- srv |-- sys |-- tmp |-- usr |-- var |-- vmlinuz -> boot/vmlinuz-2.6.8.1-01 `-- vmlinuz.old -> boot/vmlinuz-2.6.7-1-386 21 directories, 2 files -> Representa la salida del ordenador, tras la ejecución de una orden por parte de un usuario. Ejemplo 1. Ejemplo de ejemplo Muestra un ejemplo sobre algún tema determinado. * Listado de código * Ejemplos de archivos de configuración * etc. _________________________________________________________ 4. Agradecimientos Los primeros pensamientos y agradecimientos van dirigidos a todos y cada uno de los desarrolladores que han hecho posible que el software utilizado para realizar esta documentación exista. Tampoco hay que olvidar a las dos personas que han hecho que esta documentación se llevase a cabo: * Rui Pedro Lopes * Nuno Gonçalves Rodrigues La siguiente lista, muestra aquellas personas que de alguna u otra forma, han participado en la realización de esta documentación. El orden utilizado para la presentación es completamente aleatorio. * Juan Sierra Pons (Sugerencia para indicar el orden de los esquemas en el Capítulo 8.) * Juan José Muñoz Martín (Gracias a sus correos, aclaración de ciertos aspectos en el Capítulo 4) I. OpenLDAP [openldap-logo.png] Tabla de contenidos 1. Conceptos teóricos 1.1. Introducción 1.2. ¿Qué es un servicio de directorios? 1.3. ¿Qué es LDAP? 1.3.1. ¿Qué tipo de información se puede almacenar en un directorio? 1.3.2. ¿Cómo se almacena la información? 1.3.3. ¿Cómo es referenciada la información? 1.3.4. ¿Cómo se accede a la información? 1.3.5. ¿Cómo se protege la información de los accesos no autorizados? 1.4. ¿Cómo trabaja LDAP? 1.5. Sobre X.500 1.6. ¿Cuál es la diferencia entre LDAPv2 y LDAPv3? 1.7. ¿Qué es slapd y qué puede hacer? 1.7.1. LDAPv3: 1.7.2. Simple Authentication and Security Layer (SASL): 1.7.3. Transport Layer Security: 1.7.4. Control Topológico 1.7.5. Control de Acceso: 1.7.6. Internacionalización: 1.7.7. Elección del backend de la base de datos: 1.7.8. Muchas instancias de bases de datos: 1.7.9. IP genérica de módulos: 1.7.10. Hilos: 1.7.11. Replicación: 1.7.12. Proxy caché: 1.7.13. Configuración: 1.8. ¿Qué es slurpd y que puede hacer? 1.9. Información adicional sobre el proyecto 1.9.1. Página principal 1.9.2. Cómo obtener OpenLDAP 1.9.3. Documentación 1.9.4. Información de soporte 1.9.5. Reporte de bugs 1.9.6. Cómo contactar 2. Instalación 2.1. Consideraciones previas 2.2. Pasos para la instalación 2.2.1. Instalación de slapd y ldap-utils 2.2.2. Observaciones a la instalación 2.3. Comprobaciones iniciales de la instalación 2.3.1. Ejecución del demonio 2.3.2. Conectando con el servidor 3. Retoques iniciales a la configuración por defecto de OpenLDAP 3.1. /etc/default/slapd 3.1.1. Cambio del usuario y grupo de ejecución de slapd 3.1.2. Especificación de las interfaces donde escuchar 3.2. /etc/ldap/ldap.conf 3.3. /etc/ldap/slapd.conf 4. Preparando la conexión segura 4.1. Introducción 4.2. Creación de un certificado 4.2.1. Certificado autofirmado 4.2.2. Certificado emitido por una CA 4.2.3. El certificado de los clientes 4.3. Configuración de OpenLDAP 4.3.1. Servidor 4.3.2. Cliente 4.3.3. Schema 4.3.4. Resumen de configuración 4.4. Solución temporal a los problemas de OpenLDAP en Debian GNU/Linux 4.4.1. Descripción del problema 4.4.2. Solución temporal propuesta 4.5. Probando el servidor en modo seguro 4.5.1. Comprobando la conexión SSL 4.5.2. Uso de cifrado con las herramientas de OpenLDAP 5. Autentificación de usuarios a través de OpenLDAP 5.1. Introducción 5.2. Instalación del software necesario 5.2.1. Instalación de nss-ldap 5.2.2. Instalación de pam_ldap 5.3. Configuración de los archivos necesarios 5.3.1. /etc/libnss-ldap.conf y /etc/pam_ldap.conf 5.3.2. /etc/nsswitch.conf 5.3.3. Configuración de PAM _________________________________________________________ Capítulo 1. Conceptos teóricos 1.1. Introducción Este capítulo hace una breve introducción al servicio de directorios, profundizando un poco más en la implementación realizada por OpenLDAP. Nota Los conceptos teóricos se han basado en la introducción de la entrada bibliográfica OpenLDAPProject01 _________________________________________________________ 1.2. ¿Qué es un servicio de directorios? Un directorio es una base de datos optimizada para lectura, navegación y búsqueda. Los directorios tienden a contener información descriptiva basada en atributos y tienen capacidades de filtrado muy sofisticada. Los directorios generalmente no soportan transacciones complicadas ni esquemas de vuelta atrás como los que se encuentran en los sistemas de bases de datos diseñados para manejar grandes y complejos volúmenes de actualizaciones. Las actualizaciones de los directorios son normalmente cambios simples, o todo o nada, siempre y cuando estén permitidos. Los directorios están afinados para dar una rápida respuesta a grandes volúmenes de búsquedas. Estos tienen la capacidad de replicar la información para incrementar la disponibilidad y la fiabilidad, al tiempo que reducen los tiempos de respuesta. Cuando la información de un directorio se replica, se pueden producir inconsistencias temporales entre las réplicas mientras esta se está sincronizando. Hay muchas formas diferentes de proveer un servicio de directorio. Diferentes métodos permiten almacenar distintos tipos de información en el directorio, tener distintos requisitos sobre como la información ha de ser referenciada, consultada y actualizada, como es protegida de los accesos no autorizados, etc. Algunos servicios de directorio son locales, es decir, proveen el servicio a un contexto restringido (como por ejemplo, el servicio finger en una única máquina). Otros servicios son globales y proveen servicio a un contexto mucho más amplio (como por ejemplo, Internet). Los servicios globales normalmente son distribuidos, esto significa que los datos están repartidos a lo largo de distintos equipos, los cuales cooperan para dar el servicio de directorio. Típicamente, un servicio global define un espacio de nombres uniforme que da la misma visión de los datos, independientemente de donde se esté, en relación a los propios datos. El servicio DNS (Domain Name System) es un ejemplo de un sistema de directorio globalmente distribuido. _________________________________________________________ 1.3. ¿Qué es LDAP? LDAP son las siglas de Lightweight Directory Access Protocol. Como su propio nombre indica, es un protocolo ligero para acceder al servicio de directorio, especialmente al basado en X.500. LDAP se ejecuta sobre TCP/IP o sobre otros servicios de transferencia orientado a conexión. La definición detallada de LDAP está disponible en el RFC2251 "The Lightweight Directory Access Protocol (v3)" y en otro documento que comprende las especificaciones técnicas, RFC3377. _________________________________________________________ 1.3.1. ¿Qué tipo de información se puede almacenar en un directorio? El modelo de información de LDAP está basado en entradas. Una entrada es una colección de atributos que tienen un único y global Nombre Distinguido[1] (DN). El DN se utiliza para referirse a una entrada sin ambigüedades. Cada atributo de una entrada posee un tipo y uno o más valores. Los tipos son normalmente palabras nemotécnicas, como "cn" para common name, o "mail" para una dirección de correo. La sintaxis de los atributos depende del tipo de atributo. Por ejemplo, un atributo cn puede contener el valor "Sergio González". Un atributo email puede contener un valor "sergio@ejemplo.com". El atributo jpegPhoto ha de contener una fotografía en formato JPEG. _________________________________________________________ 1.3.2. ¿Cómo se almacena la información? En LDAP, las entradas están organizadas en una estructura jerárquica en árbol. Tradicionalmente, esta estructura reflejaba los límites geográficos y organizacionales. Las entradas que representan países aparecen en la parte superior del árbol. Debajo de ellos, están las entradas que representan los estados y las organizaciones nacionales. Debajo de estás, pueden estar las entradas que representan las unidades organizacionales, empleados, impresoras, documentos o todo aquello que pueda imaginarse. La Figura 1-1 muestra un ejemplo de un árbol de directorio LDAP haciendo uso del nombramiento tradicional. Figura 1-1. Árbol del directorio LDAP (nombramiento tradicional)[2] [openldap-LDAP_directory_tree_traditional_naming.png] El árbol también se puede organizar basándose en los nombres de dominio de Internet. Este tipo de nombramiento se está volviendo muy popular, ya que permite localizar un servicio de directorio haciendo uso de los DNS. La Figura 1-2 muestra un ejemplo de un directorio LDAP que hace uso de los nombres basados en dominios. Figura 1-2. Árbol del directorio LDAP (nombramiento de Internet)[3] [openldap-LDAP_directory_tree_internet_naming.png] Además, LDAP permite controlar que atributos son requeridos y permitidos en una entrada gracias al uso del atributo denominado objectClass. El valor del atributo objectClass determina que reglas de diseño (schema rules) ha de seguir la entrada. _________________________________________________________ 1.3.3. ¿Cómo es referenciada la información? Una entrada es referenciada por su nombre distinguido, que es construido por el nombre de la propia entrada (llamado Nombre Relativo Distinguido[4] o RDN) y la concatenación de los nombres de las entradas que le anteceden. Por ejemplo, la entrada para Nuno Gonçalves en el ejemplo del nombramiento de Internet anterior tiene el siguiente RDN: uid=nuno y su DN sería: uid=nuno,ou=estig,dc=ipb,dc=pt. El formato completo para los DN está descrito en el RFC2253, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names." _________________________________________________________ 1.3.4. ¿Cómo se accede a la información? LDAP define operaciones para interrogar y actualizar el directorio. Provee operaciones para añadir y borrar entradas del directorio, modificar una entrada existente y cambiar el nombre de una entrada. La mayor parte del tiempo, sin embargo, LDAP se utiliza para buscar información almacenada en el directorio. Las operaciones de búsqueda de LDAP permiten buscar entradas que concuerdan con algún criterio especificado por un filtro de búsqueda. La información puede ser solicitada desde cada entrada que concuerda con dicho criterio. Por ejemplo, imagínese que quiere buscar en el subárbol del directorio que está por debajo de dc=ipb,dc=pt a personas con el nombre Nuno Gonçalves, obteniendo la dirección de correo electrónico de cada entrada que concuerde. LDAP permite hacer esto fácilmente. O tal vez prefiera buscar las organizaciones que posean la cadena IPB en su nombre, posean número de fax y estén debajo de la entrada st=Bragança,c=PT. LDAP le permite hacer esto también. La siguiente sección describe con mayor detalle que se puede hacer con LDAP y como puede serle útil. _________________________________________________________ 1.3.5. ¿Cómo se protege la información de los accesos no autorizados? Algunos servicios de directorio no proveen protección, permitiendo a cualquier persona acceder a la información. LDAP provee un mecanismo de autentificación para los clientes, o la confirmación de identidad en un servidor de directorio, facilitando el camino para un control de acceso que proteja la información que el servidor posee. LDAP también soporta los servicios de privacidad e integridad. _________________________________________________________ 1.4. ¿Cómo trabaja LDAP? El servicio de directorio de LDAP está basado en el modelo cliente/servidor. Uno o más servidores LDAP contienen los datos que conforman la información del árbol del directorio[5] (DIT). El cliente se conecta a los servidores y les formula preguntas. Los servidores responden con una respuesta o con un puntero donde el cliente puede obtener información adicional (normalmente otro servidor LDAP). No importa a que servidor LDAP se conecte un cliente, este siempre obtendrá la misma visión del directorio; un nombre presentado por un servidor LDAP referencia la misma entrada que cualquier otro servidor LDAP. Esta es una característica muy importante del servicio global de directorio, como LDAP. _________________________________________________________ 1.5. Sobre X.500 Técnicamente, LDAP es un protocolo de acceso a directorio para el servicio de directorio X.500, el servicio de directorio de OSI. Inicialmente, los cliente LDAP accedían a través de puertas de enlace al servicio de directorio X.500. Esta puerta de enlace ejecutaba LDAP entre el cliente y la puerta de enlace, y el Protocolo X.500 de Acceso al Directorio [6] (DAP) entre la puerta de enlace y el servidor X.500. DAP es un protocolo extremadamente pesado que opera sobre una pila protocolar OSI completa y requiere una cantidad significativa de recursos computacionales. LDAP está diseñado para operar sobre TCP/IP proporcionando una funcionalidad similar a la de DAP, pero con un coste muchísimo menor. Aunque LDAP se utiliza todavía para acceder al servicio de directorio X.500 a través de puertas de enlace, hoy en día es más común implementar LDAP directamente en los servidores X.500. El demonio autónomo de LDAP, o slapd (8), puede ser visto como un servidor de directorio X.500 ligero. Es decir, no implementa el DAP X.500, sino un subconjunto de modelos de X.500. Es posible replicar datos desde un servidor de directorio LDAP hacia un servidor DAP X.500. Esta operación requiere una puerta de enlace LDAP/DAP. OpenLDAP no suministra dicha puerta de enlace, pero el demonio de replicación que posee puede ser usado para la replicación, como si de una puerta de enlace se tratase. _________________________________________________________ 1.6. ¿Cuál es la diferencia entre LDAPv2 y LDAPv3? LDAPv3 fue desarrollado en los años 90 para reemplazar a LDAPv2. LDAPv3 incorpora las siguientes características a LDAP: * Autentificación fuerte haciendo uso de SASL * Protección de integridad y confidencialidad haciendo uso de TLS (SSL) * Internacionalización gracias al uso de Unicode * Remisiones y continuaciones * Descubrimiento de esquemas * Extensibilidad (controles, operaciones extendidas y más) LDAPv2 es histórico (RFC3494). Muchas implementaciones de LDAPv2 (incluyendo slapd (8)) no se adaptan a las especificaciones técnicas de LDAPv2, la interoperabilidad entre las distintas implementaciones de LDAPv2 es muy limitada. Como LDAPv2 difiere significativamente de LDAPv3, la interactuación entre ambas versiones puede ser un poco problemática. LDAPv2 ha de evitarse, por lo que en la implementación de OpenLDAP viene deshabilitado por defecto. _________________________________________________________ 1.7. ¿Qué es slapd y qué puede hacer? slapd (8) es un servidor de directorio LDAP que se ejecuta en distintas plataformas. Algunas de las características más interesantes de slapd son: _________________________________________________________ 1.7.1. LDAPv3: slapd implementa la versión 3 de Lightweight Directory Access Protocol. slapd soporta LDAP sobre IPv4, IPv6 y Unix IPC. _________________________________________________________ 1.7.2. Simple Authentication and Security Layer (SASL): slapd tiene soporte de autentificación fuerte gracias al uso de SASL. La implementación SASL de slapd hace uso del software Cyrus SASL, el cual soporta un gran número de mecanismos de autentificación, como: DIGEST-MD5, EXTERNAL, y GSSAPI. _________________________________________________________ 1.7.3. Transport Layer Security: slapd provee protecciones de privacidad e integridad gracias al uso de TLS (o SSL). La implementación TLS de slapd hace uso del software OpenSSL. _________________________________________________________ 1.7.4. Control Topológico slapd se puede configurar para restringir el acceso a la capa de socket basándose en la información topológica de la red. Esta característica hace uso de los TCP wrappers. _________________________________________________________ 1.7.5. Control de Acceso: slapd provee facilidades de control de acceso muy potentes, permitiéndole controlar el acceso a la información de su(s) base(s) de datos. Puede controlar el acceso a las entradas basándose en la información de autorización de LDAP, en la dirección IP, en los nombres de dominio y otros criterios. slapd soporta tanto el control de acceso a la información dinámico como estático. _________________________________________________________ 1.7.6. Internacionalización: slapd soporta Unicode y etiquetas de lenguaje. _________________________________________________________ 1.7.7. Elección del backend de la base de datos: slapd viene con una serie de backends para diferentes bases de datos. Estos incluyen DBD, un backend de una base de datos transaccional de alto rendimiento; LDBM, un backend ligero basado en DBM; SHELL, una interface para scripts de shell; y PASSWD, un backend simple para el archivo passwd (5). El backend BDB hace uso de Sleepycat Berkeley DB. LDBM utiliza cualquiera de las siguientes: Berkeley DB o GDBM. _________________________________________________________ 1.7.8. Muchas instancias de bases de datos: slapd se puede configurar para servir a múltiples bases de datos al mismo tiempo. Esto significa que un único servidor slapd puede responder a peticiones de diferentes porciones lógicas del árbol de LDAP, haciendo uso del mismo o distintos backends de bases de datos. _________________________________________________________ 1.7.9. IP genérica de módulos: Si necesita más personalización, slapd le permite escribir sus propios módulos fácilmente. slapd consiste en dos partes diferentes: un frontend que maneja las comunicaciones protocolares con los clientes LDAP; y módulos que manejan tareas específicas como las operaciones con las bases de datos. Debido a que estas dos piezas se comunican a través de una API C bien definida, puede escribir sus propios módulos, que extenderán slapd de múltiples maneras. También existen numerosos módulos programables de bases de datos. Estos permiten a slapd acceder a fuentes de datos externas haciendo uso de lenguajes de programación populares (Perl, shell, SQL y TCL). _________________________________________________________ 1.7.10. Hilos: slapd hace uso de hilos para obtener alto rendimiento. Un proceso único multihilo maneja todas las peticiones entrantes haciendo uso de una piscina de hilos. Esto reduce la carga del sistema a la vez que provee alto rendimiento. _________________________________________________________ 1.7.11. Replicación: slapd se puede configurar para que mantenga copias de la información del directorio. Este esquema de replicación, un único maestro/múltiples esclavos, es vital en ambientes con un volumen alto de peticiones, donde un único servidor slapd no podría proveer la disponibilidad ni la confiabilidad necesarias. slapd incluye también un soporte experimental para la replicación de múltiples maestros. slapd soporta dos métodos de replicación: Sync LDAP y slurpd (8). _________________________________________________________ 1.7.12. Proxy caché: slapd puede ser configurado como un servicio proxy de caché LDAP. _________________________________________________________ 1.7.13. Configuración: slapd es altamente configurable a través de un único archivo de configuración, que permite modificar todo aquello que se necesite cambiar. Las opciones por defecto son razonables, lo que facilita mucho el trabajo. _________________________________________________________ 1.8. ¿Qué es slurpd y que puede hacer? slurpd (8) es un demonio que, con la ayuda de slapd, provee el servicio de replicación. Es el responsable de distribuir los cambios realizados en la base de datos slapd principal hacia las distintas réplicas slapd. Este demonio libera a slapd de preocuparse por el estado de las réplicas (si estas se han caído, no están accesibles cuando se ha producido un cambio, etc.); slurpd maneja automáticamente el reenvío de las peticiones fallidas. slapd y slurpd se comunican a través de un simple archivo de texto, que es utilizado para almacenar los cambios ocurridos. _________________________________________________________ 1.9. Información adicional sobre el proyecto 1.9.1. Página principal El Proyecto OpenLDAP dispone de una página principal, http://www.openldap.org/, desde donde puede obtener mucha información sobre el proyecto. De hecho, para elaborar esta sección ha utilizado la información allí disponible. _________________________________________________________ 1.9.2. Cómo obtener OpenLDAP El código de OpenLDAP es de libre distribución (vea los The OpenLDAP Public License y Apéndice AU para más información) y su código fuente está disponible desde distintas fuentes, como se verá a continuación. OpenLDAP dispone de distintas ramas de desarrollo, entre las que se encuentran: * La versión estable (a la hora de escribir este documento era la versión 2.1.30), cuya característica es que el software que la compone ha sido ampliamente comprobado y se considera muy confiable. * La última liberación para uso general (a la hora de escribir este documento eran las versiones 2.2.5 y 2.1.30), la cual no ha sido todo lo ampliamente testeada como para considerarla estable. * La liberación de pruebas, ocasionalmente, los desarrolladores de OpenLDAP harán versiones beta o gamma u otro tipo de liberaciones. La característica de estas, es que sólo tienen el propósito de ser probadas, no son para el uso general. * Otras liberaciones, cuya existencia puede tener múltiples motivos. Normalmente se suelen emplear para actualizar versiones antiguas de OpenLDAP (como por ejemplo las versiones 1.x y 2.0.x). La forma de acceso al código fuente se detalla a continuación: * Acceso al CVS: para más información visite esta página. * Uso de los mirrors: Si desea bajarse el código fuente ya empaquetado, consulte los mirrors disponibles para hacerlo * Obtención directa de la página del proyecto: Además de los métodos anteriores de obtención del código fuente, el Proyecto OpenLDAP pone a su disposición el código fuente en las siguientes ubicaciones: + Acceso por FTP y HTTP + Acceso por FTP De todas formas, la mayoría de las distribuciones de GNU/Linux disponen de paquetes binarios de OpenLDAP, si los necesitase. Obtenga la información de su distribución para comprobar que posee paquetes de este software. _________________________________________________________ 1.9.3. Documentación La página principal del Proyecto OpenLDAP dispone de una sección dedicada a la documentación, desde donde se pueden obtener documentos tan interesantes como OpenLDAPProject01, entre otros. Para más detalles, visite: http://www.openldap.org/doc/index.html _________________________________________________________ 1.9.4. Información de soporte La página dedicada al soporte de OpenLDAP, informa sobre los distintos métodos existentes para obtener ayuda en un determinado momento. Los métodos más importantes para obtener ayuda son los siguientes: Faq-O-Matic: Sitio dedicado a las preguntas frecuentes sobre OpenLDAP: http://www.openldap.org/faq/ Listas de correo: El Proyecto OpenLDAP dispone varias listas de correo, entre las que se encuentran algunas como anuncios, bugs o desarrollo, siendo una fuente de información fiable y directa. En la siguiente página encontrará toda la información necesaria para acceder a dichas listas de correo: http://www.openldap.org/lists/ Servicio técnico de terceros: Muchas empresas ofrecen servicio técnico a la comunidad de OpenLDAP, un listado de las mismas se puede obtener desde: www.openldap.org/support/index.html _________________________________________________________ 1.9.5. Reporte de bugs OpenLDAP dispone de un Sistema de seguimiento de tareas, desde donde se pueden reportar errores y bugs relacionados con OpenLDAP (tanto en lo relativo al software como a la documentación), hacer peticiones de nuevas características y realizar contribuciones al software. _________________________________________________________ 1.9.6. Cómo contactar Para obtener más información sobre OpenLDAP, puede contactar con el Proyecto en la siguiente dirección: The OpenLDAP Project c/o The OpenLDAP Foundation 270 Redwood Shores Pwy, PMB#107 Redwood City, California 94065 USA _________________________________________________________ Capítulo 2. Instalación 2.1. Consideraciones previas La instalación y configuración de OpenLDAP se llevará a cabo de tal manera que al finalizarla, el sistema sobre el que se ha instalado debería estar listo para autentificar usuarios a través del servicio de directorios. Este es el objetivo final de este capítulo, en subsiguientes capítulos se irán añadiendo las funcionalidades necesarias para que cumpla con los requisitos del trabajo. Se ha seleccionado la versión 2.1.30 de OpenLDAP, que acompaña a la versión en desarrollo de Debian GNU/Linux. Nota A lo largo de todo el documento se asume que el dominio sobre el que se ejecutará OpenLDAP es "gsr.pt", perteneciente a la empresa gsr.pt. Para obtener un sistema acorde a estas condiciones, se ha añadido la línea "gsr.pt" en el archivo /etc/hosts para intentar simular las condiciones reales. _________________________________________________________ 2.2. Pasos para la instalación 2.2.1. Instalación de slapd y ldap-utils El primer paso para instalar OpenLDAP, es instalar los paquetes slapd y ldap-utils. Veamos el procedimiento: Aviso Se ha de tener en cuenta que en algunas ocasiones no aparecen todas las capturas de pantalla que se muestran en el Ejemplo 2-1, eso se puede deber a que ya se haya instalado anteriormente slapd en el sistema o debido al nivel de preguntas elegido en la configuración de debconf. Si por cualquier motivo no apareciesen, puede forzar la configuración de slapd con la orden: # /usr/sbin/dpkg-reconfigure --priority=low slapd Ejemplo 2-1. Instalación de los paquetes slapd ldap-utils (primera parte) # apt-get install slapd ldap-utils Leyendo lista de paquetes... Hecho Creando árbol de dependencias... Hecho Se instalarán los siguientes paquetes NUEVOS: ldap-utils slapd 0 actualizados, 2 se instalarán, 0 para eliminar y 1 no actualizados. Se necesita descargar 0B/1042kB de archivos. Se utilizarán 2884kB de espacio de disco adicional después de desempaqu etar. Preconfiguring packages ... Figura 2-1. Configuración de slapd mediante debconf [openldap-instalacion-slapd1.png] Si se quiere configurar algunos aspectos de slapd a través de debconf, responda No, en esta pantalla. Figura 2-2. Configuración de slapd, elección del dominio [openldap-instalacion-slapd2.png] Esta pantalla se pide el dominio sobre el cual se va a ejecutar el servidor slapd, en este caso será el dominio gsr.pt. Figura 2-3. Configuración de slapd, nombre de la organización [openldap-instalacion-slapd3.png] Solicitud del nombre de la organización que está instalando el servidor OpenLDAP. En este ejemplo se dejará el nombre del dominio anteriormente tecleado: gsr.pt. Figura 2-4. Configuración de slapd, clave de administrador [openldap-instalacion-slapd4.png] Pantalla de solicitud de la clave para el administrador del servicio LDAP. Este usuario es el superusuario (root) de OpenLDAP, por lo que se debería elegir una buena clave. Figura 2-5. Configuración de slapd, repetir clave de administrador [openldap-instalacion-slapd5.png] Verificación de la clave del administrador, se ha de teclear la misma que en la pantalla anterior. Figura 2-6. Configuración de slapd, elección del backend de la BBDD [openldap-instalacion-slapd6.png] Elección del backend de la base de datos que utilizará OpenLDAP. En este ejemplo se elegirá LDBM. Figura 2-7. Configuración de slapd, ¿conservar los datos al desinstalarlo? [openldap-instalacion-slapd7.png] Aviso Tenga cuidado con la elección de esta pantalla, puede perder los datos almacenados en la base de datos de OpenLDAP si "accidentalmente" se desinstala slapd. Seleccionamos que No queremos que se borre la base de datos de OpenLDAP al desinstalarse el servidor slapd. Figura 2-8. Configuración de slapd, ¿mover los datos antiguos? [openldap-instalacion-slapd8.png] Nota Esta pantalla de configuración puede no aparecer cuando instale OpenLDAP en su sistema, no se preocupe por ello. El motivo para que no aparezca es que no existen datos en el directorio /var/lib/ldap, esto se puede deber a que esta sea su primera instalación de OpenLDAP o se hayan borrado los datos de dicho directorio, entre otros. Dependiendo de sus necesidades debería contestar o Sí o No en esta pantalla. En este ejemplo se contestará que Sí, de esta forma los datos existentes en /var/lib/ldap se empaquetarán y se moverán moverán a un directorio similar a /var/backups/var_lib_ldap-*FECHA*/ donde *FECHA* se sustituirá por la fecha que posea el ordenador en ese momento. Figura 2-9. Configuración de slapd, protocolo LDAPv2 [openldap-instalacion-slapd9.png] Al igual que la pantalla anterior, la respuesta a esta pregunta dependerá de sus necesidades. En este ejemplo se optará por no mantener la compatibilidad con la versión 2 del protocolo LDAP, opción que se recomienda encarecidamente seleccionar. Ejemplo 2-2. Instalación de los paquetes slapd ldap-utils (segunda parte) find: /var/lib/ldap: No existe el fichero o el directorio Seleccionando el paquete ldap-utils previamente no seleccionado. (Leyendo la base de datos ... 252690 ficheros y directorios instalados actualmente.) Desempaquetando ldap-utils (de .../ldap-utils_2.1.30-3_i386.deb) ... Seleccionando el paquete slapd previamente no seleccionado. Desempaquetando slapd (de .../slapd_2.1.30-3_i386.deb) ... Configurando ldap-utils (2.1.30-3) ... Configurando slapd (2.1.30-3) ... Creating initial slapd configuration... done Creating initial LDAP directory... done Starting OpenLDAP: slapd. localepurge: checking system for new locale ... localepurge: processing locale files ... localepurge: processing man pages ... _________________________________________________________ 2.2.2. Observaciones a la instalación Una vez más, dependiendo de como se encuentre su sistema y los paquetes que tenga instalados en el mismo, se instalarán y sugerirán más o menos dependencias a la hora de instalar OpenLDAP. La siguiente captura muestra la información relativa a los paquetes que se acaban de instalar (dependencias, sugerencias de instalación, etc). $ /usr/bin/apt-cache show slapd ldap-utils Package: slapd Priority: optional Section: net Installed-Size: 2392 Maintainer: Torsten Landschoff Architecture: i386 Source: openldap2 Version: 2.1.30-3 Provides: ldap-server Depends: libc6 (>= 2.3.2.ds1-4), libdb4.2, libgcrypt11, libgnutls11 (>= 1.0.16), libgpg-error0 (>= 0.7), libiodbc2 (>= 3.51.2-2), libldap2 (>= 2.1.17-1), libltdl3 (>= 1.5.2-2), libsasl2 (>= 2.1.18), libslp1, libwrap0, zlib1g (>= 1:1.2.1), debconf (>= 0.5), coreutils (>= 4.5.1-1) | fileutils (>= 4.0i-1), psmisc, libldap2 (= 2.1.30-3), perl (>> 5.8.0) | libmime-base64-perl Recommends: db4.2-util, libsasl2-modules Suggests: ldap-utils Conflicts: umich-ldapd, ldap-server, libbind-dev, bind-dev, libltdl3 (= 1.5.4-1) Filename: pool/main/o/openldap2/slapd_2.1.30-3_i386.deb Size: 941934 MD5sum: 497cbd88576c42e89457fa8c1594067f Description: OpenLDAP server (slapd) This is the OpenLDAP (Lightweight Directory Access Protocol) standalon e server (slapd). The server can be used to provide a standalone directo ry service and also includes the slurpd replication server. Package: ldap-utils Priority: optional Section: net Installed-Size: 292 Maintainer: Torsten Landschoff Architecture: i386 Source: openldap2 Version: 2.1.30-3 Replaces: openldap-utils, slapd (<< 2.1.25), openldapd Provides: ldap-client, openldap-utils Depends: libc6 (>= 2.3.2.ds1-4), libdb4.2, libgcrypt11, libgnutls11 (>= 1.0.16), libgpg-error0 (>= 0.7), libiodbc2 (>= 3.51.2-2), libldap2 (>= 2.1.17-1), libltdl3 (>= 1.5.2-2), libsasl2 (>= 2.1.18), libslp1, zlib1g (>= 1:1.2.1), libldap2 (= 2.1.30-3) Recommends: libsasl2-modules Conflicts: umich-ldap-utils, openldap-utils, ldap-client Filename: pool/main/o/openldap2/ldap-utils_2.1.30-3_i386.deb Size: 114684 MD5sum: 01c409b7e225facf2056310fd70afdad Description: OpenLDAP utilities Utilities from the OpenLDAP (Lightweight Directory Access Protocol) package. These utilities can access a local or remote LDAP server and contain all the client programs required to access LDAP servers. _________________________________________________________ 2.3. Comprobaciones iniciales de la instalación 2.3.1. Ejecución del demonio En este punto, ya se debería tener un servidor OpenLDAP instalado y ejecutándose, aunque no esté ajustado todavía a los objetivos que persigue este apartado. Para comprobar que efectivamente el demonio slapd se está ejecutando, realizaremos un par de consultas al sistema. La primera consiste en ver si el demonio slapd se encuentra en la lista de procesos que actualmente se estén ejecutando en el sistema: Ejemplo 2-3. Comprobación de que slapd está en la lista de procesos actuales # /bin/ps auxf | /bin/grep slapd USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 4453 0.0 0.5 12144 3004 ? S 12:52 0:00 /usr/sbi n/slapd root 4455 0.0 0.5 12144 3004 ? S 12:52 0:00 \_ /usr /sbin/slapd root 4456 0.0 0.5 12144 3004 ? S 12:52 0:00 \_ /usr/sbin/slapd Nota En la captura de pantalla anterior se ha eliminado la línea que hacía referencia la instrucción tecleada (/bin/ps auxf | /bin/grep slapd) y se ha añadido la línea de información sobre cada parte de la captura, para mejorar la legibilidad. La segunda comprobación ha realizar, para ver si el demonio se está realmente ejecutando, es verificar que está escuchando en la red[7]: Ejemplo 2-4. Comprobación de que slapd escucha en la red # /bin/netstat -puta Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address Sta te PID/Program name tcp 0 0 *:ldap *:* LIS TEN 4453/slapd _________________________________________________________ 2.3.2. Conectando con el servidor Una vez comprobado que el demonio slapd se está ejecutando en el sistema, se verificará que la conexión con el mismo está permitida. Para ello, se realizará una búsqueda sencilla en el directorio. Si todo va bien, se debería mostrar algo similar a: Ejemplo 2-5. Realización de una búsqueda simple con ldapsearch $ /usr/bin/ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts # extended LDIF # # LDAPv3 # base <> with scope base # filter: (objectclass=*) # requesting: namingContexts # # dn: namingContexts: dc=gsr,dc=pt # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 _________________________________________________________ 2.3.2.1. Posibles problemas de conexión 2.3.2.1.1. TCP Wrappers Se han de tener en cuenta las opciones de configuración pasadas, antes de la compilación de OpenLDAP, para generar los paquetes que se están utilizando. Si nos fijamos en las opciones de configuración que posee OpenLDAP por defecto en Debian GNU/Linux (consulte el Apéndice P) veremos que utiliza la opción --enable-wrappers, lo que habilita el soporte de los TCP Wrappers en OpenLDAP. Si se posee una configuración restrictiva de los TCP Wrappers, puede que sea esta la causa de los problemas de conexión. A continuación se simulará un fallo de conexión debido a un bloqueo de los TCP Wrappers, mostrándola manera de detectarlo y corregirlo. Se supone la siguiente configuración de los TCP Wrappers (en los Apéndice AO y Apéndice AP se encuentran los archivos finales para los TCP Wrappers): Ejemplo 2-6. Archivo /etc/hosts.allow # /etc/hosts.allow: list of hosts that are allowed to access the system . # See the manual pages hosts_access(5), hosts_options (5) # and /usr/doc/netbase/portmapper.txt.gz # # Example: ALL: LOCAL @some_netgroup # ALL: .foobar.edu EXCEPT terminalserver.foobar.edu # # If you're going to protect the portmapper use the name "portmap" for the # daemon name. Remember that you can only use the keyword "ALL" and IP # addresses (NOT host or domain names) for the portmapper. See portmap( 8) # and /usr/doc/portmap/portmapper.txt.gz for further information. # Ejemplo 2-7. Archivo /etc/hosts.deny # /etc/hosts.deny: list of hosts that are _not_ allowed to access the s ystem. # See the manual pages hosts_access(5), hosts_options( 5) # and /usr/doc/netbase/portmapper.txt.gz # # Example: ALL: some.host.name, .some.domain # ALL EXCEPT in.fingerd: other.host.name, .other.domain # # If you're going to protect the portmapper use the name "portmap" for the # daemon name. Remember that you can only use the keyword "ALL" and IP # addresses (NOT host or domain names) for the portmapper. See portmap( 8) # and /usr/doc/portmap/portmapper.txt.gz for further information. # # The PARANOID wildcard matches any host whose name does not match its # address. You may wish to enable this to ensure any programs that don' t # validate looked up hostnames still leave understandable logs. In past # versions of Debian this has been the default. # ALL: PARANOID # Desautorizar a todos los hosts con nombre sospechoso ALL: PARANOID # Desautorizar a todos los hosts ALL:ALL Ahora se realizará la misma búsqueda que en Ejemplo 2-5: Ejemplo 2-8. Realización de una búsqueda simple con ldapsearch (conexión fallida) $ ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts ldap_bind: Can't contact LDAP server (81) Como se puede apreciar, no se ha podido conectar con el servidor LDAP. El siguiente ejemplo realizará la misma búsqueda, sólo que en este caso se activará el modo de depuración de la orden ldapsearch "-d -1" (se hará uso del nivel de depurado -1, que es el mayor nivel existente). Ejemplo 2-9. Realización de una búsqueda simple con ldapsearch (modo depuración) $ ldapsearch -d -1 -x -b '' -s base '(objectclass=*)' namingContext s ldap_create ldap_bind_s ldap_simple_bind_s ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_new_connection ldap_int_open_connection ldap_connect_to_host: TCP gsr.pt:389 (1) ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.2.1:389 (2) ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_ndelay_on: 3 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 ldap_int_sasl_open: host=gsr.pt ldap_open_defconn: successful (3) ldap_send_server_request ber_flush: 14 bytes to sd 3 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00 0....`..... ... ldap_write: want=14, written=14 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00 0....`..... ... ldap_result msgid 1 ldap_chkResponseList for msgid=1, all=1 ldap_chkResponseList returns NULL wait4msg (infinite timeout), msgid 1 wait4msg continue, msgid 1, all 1 ** Connections: * host: gsr.pt port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 9 16:18:26 2004 ** Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** Response Queue: Empty ldap_chkResponseList for msgid=1, all=1 ldap_chkResponseList returns NULL ldap_int_select read1msg: msgid 1, all 1 ber_get_next ldap_read: want=8, got=0 ber_get_next failed. (4) ldap_perror (5) ldap_bind: Can't contact LDAP server (81) (6) (1) (2) Aquí se puede ver que el host con el que establece la conexión es el correcto. (3) Una vez encontrado el host, se conecta satisfactoriamente al mismo. (4) (5) (6) En este momento comienzan los errores de conexión. Como se puede observar en el Ejemplo 2-9, que no se obtiene la información suficiente para deducir cual ha sido el problema que ocasiona el error en la conexión. Por este motivo se ejecutará el demonio slapd en modo depuración y, aunque no sea necesario, se ejecutará con el nivel de depurado "-1". Antes proceder con este ejemplo, se mostrarán los posibles valores que puede tomar el modo de depuración de slapd y su significado[8]: Tabla 2-1. Niveles de depurado de slapd Nivel Descripción -1 Habilita todo el depurado 0 Sin depurado 1 Rastrea las llamadas a funciones 2 Depura el manejo de paquetes 4 Rastreo de depuración intensivo 8 Administración de la conexión 16 Muestra los paquetes enviados y recibidos 32 Procesado de búsqueda por filtro 64 Procesado del archivo de configuración 128 Procesado de la lista de control de acceso 256 stats log connections/operations/results 512 stats log entries sent 1024 Muestra las comunicaciones con los backends de la shell 2048 Muestra las entradas analizadas (parsing) Ejemplo 2-10. Ejecución del servidor slapd en modo de depuración # /usr/sbin/slapd -d -1 -h ldap://gsr.pt:389/ @(#) $OpenLDAP: slapd 2.1.30 (Jul 27 2004 08:02:08) $ @euklid:/home/roland/debian/openldap/build/2.1.30/openldap2-2.1 .30/debian/build/servers/slapd daemon_init: ldap://gsr.pt:389/ daemon_init: listen on ldap://gsr.pt:389/ daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://gsr.pt:389/) daemon: initialized ldap://gsr.pt:389/ daemon_init: 1 listeners opened slapd init: initiated server. slap_sasl_init: initialized! reading config file /etc/ldap/slapd.conf line 11 (include /etc/ldap/schema/core.schema) reading config file /etc/ldap/schema/core.schema/ (...) slapd startup: initiated. slapd starting daemon: added 6r daemon: select: listen=6 active_threads=0 tvp=NULL En este momento ya tenemos el demonio slapd en modo depuración, por lo que si realizamos de nuevo la búsqueda del Ejemplo 2-8, se verá la información que muestra el servidor cuando esta se realiza: Ejemplo 2-11. Ejecución del servidor slapd en modo de depuración (mensaje de rechazo de una conexión) daemon: activity on 1 descriptors daemon: new connection on 9 fd=9 DENIED from unknown (192.168.2.1) (1) daemon: closing 9 daemon: activity on: daemon: select: listen=6 active_threads=0 tvp=NULL (1) Esta línea muestra el motivo del rechazo de la conexión, no se permite la conexión desde la IP 192.168.2.1, que es desde la que se está tratando de realizar la consulta precisamente. Si se añade la siguiente línea al archivo /etc/hosts.allow "slapd: 192.168.2.1" y se ejecuta de nuevo la búsqueda del Ejemplo 2-8, sucede lo siguiente: * El servidor muestra la siguiente información: Ejemplo 2-12. Ejecución del servidor slapd en modo de depuración (mensaje de aceptación de una conexión) daemon: activity on 1 descriptors daemon: new connection on 9 conn=2 fd=9 ACCEPT from IP=192.168.2.1:32852 (IP=192.168.2.1:389) (1) daemon: added 9r daemon: activity on: daemon: select: listen=6 active_threads=0 tvp=NULL daemon: activity on 1 descriptors daemon: activity on: 9r daemon: read activity on 9 connection_get(9) connection_get(9): got connid=2 connection_read(9): checking for input on id=2 ber_get_next (...) conn=2 op=1 SRCH base="" scope=0 filter="(objectClass=*)" conn=2 op=1 SRCH attr=namingContexts => test_filter PRESENT => access_allowed: search access to "" "objectClass" requested => acl_get: [1] check attr objectClass => dn: [2] => acl_get: [2] matched => acl_get: [2] check attr objectClass <= acl_get: [2] acl attr: objectClass => acl_mask: access to entry "", attr "objectClass" requested => acl_mask: to all values by "", (=n) <= check a_dn_pat: * <= acl_mask: [1] applying read(=rscx) (stop) <= acl_mask: [1] mask: read(=rscx) => access_allowed: search access granted by read(=rscx) <= test_filter 6 => send_search_entry: dn="" => access_allowed: read access to "" "entry" requested => acl_get: [1] check attr entry => dn: [2] => acl_get: [2] matched => acl_get: [2] check attr entry <= acl_get: [2] acl attr: entry => acl_mask: access to entry "", attr "entry" requested => acl_mask: to all values by "", (=n) <= check a_dn_pat: * <= acl_mask: [1] applying read(=rscx) (stop) <= acl_mask: [1] mask: read(=rscx) => access_allowed: read access granted by read(=rscx) => access_allowed: read access to "" "namingContexts" requested => acl_get: [1] check attr namingContexts => dn: [2] => acl_get: [2] matched => acl_get: [2] check attr namingContexts <= acl_get: [2] acl attr: namingContexts access_allowed: no res from state (namingContexts) => acl_mask: access to entry "", attr "namingContexts" requested => acl_mask: to all values by "", (=n) <= check a_dn_pat: * <= acl_mask: [1] applying read(=rscx) (stop) <= acl_mask: [1] mask: read(=rscx) => access_allowed: read access granted by read(=rscx) (...) ber_get_next on fd 9 failed errno=0 (Success) connection_read(9): input error=-2 id=2, closing. connection_closing: readying conn=2 sd=9 for close connection_close: deferring conn=2 sd=9 do_unbind conn=2 op=2 UNBIND connection_resched: attempting closing conn=2 sd=9 connection_close: conn=2 sd=9 daemon: removing 9 conn=2 fd=9 closed daemon: select: listen=6 active_threads=0 tvp=NULL daemon: activity on 1 descriptors daemon: select: listen=6 active_threads=0 tvp=NULL (1) Finalmente se ha aceptado la conexión. * Del lado del cliente se obtiene la misma información que en el Ejemplo 2-5. _________________________________________________________ 2.3.2.1.2. Address family not supported by protocol Un error derivado de la instalación por defecto, es el que se muestra en título de esta sección. Si no se especifica en que interfaces ha de escuchar el demonio slapd, dará el mentado error. A continuación se verá la diferencia de ejecutar el servidor especificando o no la interfaz sobre la que tiene que escuchar. Para ello, una vez más se ejecutará en modo depuración. Ejemplo 2-13. Ejecución del demonio slapd sin especificar la interfaz donde escuchar # /usr/sbin/slapd -d -1 @(#) $OpenLDAP: slapd 2.1.30 (Jul 27 2004 08:02:08) $ @euklid:/home/roland/debian/openldap/build/2.1.30/openldap2-2.1 .30/\ debian/build/servers/slapd openldap2-2.1.30/debian/build/servers/sla pd daemon_init: daemon_init: listen on ldap:/// daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap:///) slap_open_listener: socket() failed for AF_INET6 errno=97 (Address fami ly not supported by protocol) (1) daemon: initialized ldap:/// daemon_init: 2 listeners opened ldap_pvt_gethostbyname_a: host=todoscsi, r=0 slapd init: initiated server. slap_sasl_init: initialized! reading config file /etc/ldap/slapd.conf line 11 (include /etc/ldap/schema/core.schema) reading config file /etc/ldap/schema/core.schema (...) slapd startup: initiated. slapd starting daemon: added 6r daemon: select: listen=6 active_threads=0 tvp=NULL (1) Aquí se muestra el error. Ejemplo 2-14. Ejecución del demonio slapd especificando la interfaz donde escuchar # /usr/sbin/slapd -d -1 -h ldap://gsr.pt:389/ @(#) $OpenLDAP: slapd 2.1.30 (Jul 27 2004 08:02:08) $ @euklid:/home/roland/debian/openldap/build/2.1.30/openldap2-2.1 .30/\ debian/build/servers/slapd daemon_init: ldap://gsr.pt:389/ daemon_init: listen on ldap://gsr.pt:389/ daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://gsr.pt:389/) daemon: initialized ldap://gsr.pt:389/ daemon_init: 1 listeners opened slapd init: initiated server. slap_sasl_init: initialized! reading config file /etc/ldap/slapd.conf line 11 (include /etc/ldap/schema/core.schema) reading config file /etc/ldap/schema/core.schema (...) slapd startup: initiated. slapd starting daemon: added 6r daemon: select: listen=6 active_threads=0 tvp=NULL En el Ejemplo 2-14 se puede ver que ya no muestra ningún tipo de error al inicializar el servidor. Nota En el Capítulo 3 se verá como configurar slapd para que arranque automáticamente con la especificación de la interfaces. _________________________________________________________ Capítulo 3. Retoques iniciales a la configuración por defecto de OpenLDAP 3.1. /etc/default/slapd En este archivo se configuran los aspectos relativos a la ejecución del demonio slapd: parámetros pasados en el arranque, usuario y grupo de ejecución del demonio, etc. En las siguientes secciones se verán los cambios realizados. Nota Un ejemplo completo de este archivo de configuración se encuentra en el Apéndice S _________________________________________________________ 3.1.1. Cambio del usuario y grupo de ejecución de slapd Por defecto, el demonio slapd se ejecuta como usuario root (vea el Ejemplo 2-3 para más detalles), comportamiento que no es recomendable por las implicaciones de seguridad que acarrea. En esta sección se describirán los pasos necesarios para ejecutar el demonio slapd con un usuario y un grupo específicos. _________________________________________________________ 3.1.1.1. Creación del usuario y grupo para slapd Antes de poder ejecutar el demonio slapd con un usuario y grupo específico, se ha de crear el usuario y grupo en el sistema, en caso de no existir. El tipo de usuario y grupo que se crearán son los llamados "de sistema", y se denominarán "slapd". Para crearlos ejecute: Ejemplo 3-1. Creación de un grupo y usuario de sistema para slapd # addgroup --system slapd Añadiendo el grupo slapd (133)... Hecho. # adduser --home /var/lib/ldap --shell /bin/false --no-create-home --in group slapd --system slapd adduser: Aviso: El directorio home que Usted especificó ya existe. Añadiendo usuario del sistema slapd... Añadiendo nuevo usuario slapd (126) con grupo slapd. No se crea el directorio home. Como se puede apreciar en el Ejemplo 3-1, el home del usuario slapd es el directorio /var/lib/ldap (donde se almacena la base de datos de OpenLDAP, entre otras cosas), no posee shell asociada y está dentro del grupo slapd que se acaba de crear. _________________________________________________________ 3.1.1.2. Cambio de propietario/grupo en los archivos de slapd Aviso Antes de continuar con este paso, ha de parar el demonio slapd para evitar comportamientos no esperados: Ejemplo 3-2. Modo de parar el demonio slapd # /etc/init.d/slapd stop Stopping OpenLDAP: slapd. Antes de ejecutar el demonio slapd con el nuevo usuario y grupo creados, es necesario cambiar el propietario y el grupo de algunos archivos y directorios relacionados con slapd, para que este funcione con normalidad. Los cambios han de realizarse en los siguientes directorios, así como en los archivos que albergan: * /etc/ldap * /var/lib/slapd * /var/lib/ldap * /var/run/slapd Para ello se ha de ejecutar: Ejemplo 3-3. Cambio del propietario/grupo en archivos relacionados con slapd # /bin/chown -R slapd.slapd /etc/ldap /var/lib/slapd /var/lib/ldap /var /run/slapd En estos momentos slapd ya casi está preparado para ejecutarse con el nuevo usuario. _________________________________________________________ 3.1.1.3. Especificar el usuario/grupo con el que ejecutar slapd El último paso consiste en indicar al demonio slapd con qué usuario y grupo se ha de ejecutar a partir de ahora. Esta característica se configura asignando los valores correspondientes a las variables SLAPD_USER y SLAPD_GROUP del archivo /etc/default/slapd. Continuando con la configuración de ejemplo seguida en las secciones anteriores los valores que han de tener estas variables son: Ejemplo 3-4. Asignación del usuario y grupo con que se ejecutará slapd SLAPD_USER="slapd" SLAPD_GROUP="slapd" _________________________________________________________ 3.1.1.4. Arrancando el demonio slapd Ahora sólo queda arrancar de nuevo el demonio slapd para que se ejecute con el nuevo usuario: Ejemplo 3-5. Arrancando el demonio slapd # /etc/init.d/slapd start Starting OpenLDAP: slapd. # /bin/ps auxf USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND slapd (1) 12728 0.0 0.6 12216 3556 ? S 15:02 0:00 /usr/sbi n/slapd -g slapd -u slapd (2) slapd (3) 12729 0.0 0.6 12216 3556 ? S 15:02 0:00 \_ /usr /sbin/slapd -g slapd -u slapd (4) slapd (5) 12730 0.0 0.6 12216 3556 ? S 15:02 0:00 \_ /usr/sbin/slapd -g slapd -u slapd (6) (1) (3) (5) Usuario con el que se está ejecutando slapd. (2) (4) (6) Parámetros de ejecución de slapd, se puede apreciar que se ha indicado el usuario (-u slapd) y grupo (-g slapd) de ejecución del demonio. _________________________________________________________ 3.1.2. Especificación de las interfaces donde escuchar La configuración por defecto del demonio slapd hace que escuche en todas las interfaces de red presentes en el sistema. Esta característica no es deseable, por este motivo se verá la forma de modificarla. La especificación de las interfaces de red, así como el protocolo utilizado en cada una de ellas (ldap, ldaps, ldai), se realiza en el archivo /etc/default/slapd. Dentro de este, la variable SLAPD_SERVICES poseerá las interfaces donde se desea que escuche slapd. El Ejemplo 3-6 muestra como hacerlo. Ejemplo 3-6. Estableciendo las interfaces donde ha de escuchar slapd SLAPD_SERVICES="ldap://gsr.pt:389/ ldaps://gsr.pt:636/" Nota El protocolo "ldap" especifica las interfaces y los puertos donde escuchará slapd con la característica de que las conexiones que se establezcan a la misma no harán uso de cifrado. El protocolo "ldaps" especifica las interfaces y los puertos donde escuchará slapd con la característica de que las conexiones que se establezcan a la misma harán uso de cifrado. Adicionalmente se puede establecer un nuevo protocolo de comunicaciones, "ldapi", destinado a las peticiones realizadas desde sockets Unix. Una vez se han asignado las interfaces necesarias, se ha de reiniciar el demonio slapd: Ejemplo 3-7. Reinicio del demonio slapd # /bin/netstat -puta Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Pr ogram name tcp 0 0 *:ldap (1) *:* LISTEN 12 728/slapd # /etc/init.d/slapd restart Stopping OpenLDAP: slapd. Starting OpenLDAP: slapd. # /bin/netstat -puta Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Prog ram name tcp 0 0 gsr.pt:ldap (1) *:* LISTEN 1281 7/slapd tcp 0 0 gsr.pt:ldaps (2) *:* LISTEN 128 17/slapd # /bin/ps auxfw USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND slapd 12817 0.0 0.6 12216 3552 ? S 15:19 0:00 /usr/sbin/slapd -h ldap ://gsr.pt:389/ (1) | ldap s://gsr.pt:636/ | -g slap d -u slapd slapd 12818 0.0 0.6 12216 3552 ? S 15:19 0:00 \_ /usr/sbin/slapd -h ldap://gsr.pt:389/ (2) | ldaps://gsr.pt:636/ | -g slapd -u slapd slapd 12819 0.0 0.6 12216 3552 ? S 15:19 0:00 \_ /usr/sbin/slapd -h ldap://gsr.pt:389/ (3) ldaps://gsr.pt:636/ -g slapd -u slapd (1) Inicialmente el demonio slapd escucha en el puerto 389 en todas la interfaces. (1) (2) Una vez reiniciado con la nueva configuración, el demonio slapd escucha en las interfaces requeridas. (1) (2) (3) La lista de parámetros pasados al demonio slapd ha aumentado, ahora se especifica el host donde ha de escuchar y con qué protocolo. Nota La salida de la orden /bin/ps se ha retocado para mejorar la legibilidad. _________________________________________________________ 3.2. /etc/ldap/ldap.conf Este es el archivo de configuración global empleado por los clientes LDAP. En este momento estableceremos unas opciones iniciales, que pueden cambiar y ampliarse a lo largo del documento. Nota En el Apéndice R posee un ejemplo completo de configuración. Ejemplo 3-8. Configuración inicial del archivo /etc/ldap/ldap.conf # # Configuración por defecto de LDAP # 5 # Vea ldap.conf(5) para más detalles # Este archivo ha de poderse leer por todo el mundo, # pero no escribirse por todos. # Su servidor LDAP. Ha de ser resoluble sin utilizar LDAP. 10 HOST gsr.pt # El nombre distinguido para la base de las búsquedas. BASE dc=gsr, dc=pt 15 # El puerto. # Opcional: por defecto es el 389. El 636 es para ldaps port 389 Ha de asegurarse que los permisos de este archivo estén bien asignados (se ha de leer por todo el mundo): Ejemplo 3-9. Estableciendo los permisos para /etc/ldap/ldap.conf # /bin/chmod -v 644 /etc/ldap/ldap.conf el modo de `/etc/ldap/ldap.conf' cambia a 0644 (rw-r--r--) _________________________________________________________ 3.3. /etc/ldap/slapd.conf La única modificación que se ha de realizar en este archivo, de momento, es un cambio de permisos, de forma que sólo el propietario tenga permisos de lectura y escritura: # /bin/chmod -v 600 /etc/ldap/slapd.conf el modo de `/etc/ldap/slapd.conf' cambia a 0600 (rw-------) _________________________________________________________ Capítulo 4. Preparando la conexión segura Creación de certificados Creación de certificados _________________________________________________________ 4.1. Introducción Este capítulo está dedicado a la creación de la entidad certificadora y los certificados necesarios para hacer uso de una conexión segura, característica que provee la versión 3 del protocolo LDAP por defecto, y por tanto, la versión de OpenLDAP que se está utilizando en este documento. Aviso Tal y como se distribuye el paquete de OpenLDAP en Debian GNU/Linux, no es posible, al menos a la hora de generar esta documentación, hacer uso de cifrado en las comunicaciones relacionadas con LDAP. En la Sección 4.4 se detallará el problema y se dará una solución temporal, a la espera de que se solucionen los problemas con este paquete en Debian[9]. Atención Se asume que ya posee una instalación de OpenSSL en su sistema, de no ser así, será necesario instalarla: # apt-get install openssl Nota La versión de OpenSSL empleada para generar esta documentación ha sido la 0.9.7d. Nota Para la elaboración de este capítulo, se ha empleado, principalmente, la entrada bibliográfica Soper01 y el capítulo 6 de la entraba bibliográfica Tournier01. _________________________________________________________ 4.2. Creación de un certificado Para habilitar las conexiones SSL/TLS hacia el servidor LDAP, se necesita la presencia de un certificado en el servidor. Además, en el establecimiento de una conexión SSL/TLS, el certificado del servidor sólo proporciona una conexión segura y cifrada al servidor. Si se desea autentificar al cliente, se ha de presentar al servidor LDAP el certificado y el par de llaves del cliente. Existen dos formas de crear e instalar un certificado en el servidor: la creación de un "certificado autofirmado" y la creación de un "certificado emitido por una CA". Ambos métodos requieren la creación de un certificado para el servidor, enviárselo a los clientes OpenLDAP y realizar los cambios apropiados en los archivos de configuración de OpenLDAP. Ambos métodos necesitan el uso de órdenes OpenSSL que solicitarán información para la creación del certificado. Nota Para la elaboración de esta documentación se ha elegido la creación de un certificado a partir de una CA (Sección 4.2.2) y sobre este método se basará el resto de la documentación. De todas formas, se ha incluido en la Sección 4.2.1 el otro método existente, a título informativo. Aviso Cuando se pregunte por el "Common Name", ha de teclear el nombre del dominio de su servidor (FQDN), como por ejemplo: miservidor.pt, y no "su nombre" como sugiere OpenSSL. ¡Esta equivocación es la causa del 90% de los errores en el el certificado del servidor! _________________________________________________________ 4.2.1. Certificado autofirmado La primera forma para la creación del certificado del servidor emplea OpenSSL y genera un certificado autofirmado para el servidor. Para ello, desde la línea de comandos se ha de teclear (la letra en negrita son las opciones que ha de introducir el usuario): Nota OpenLDAP sólo trabaja con llaves no cifradas, por lo que se ha de emplear el parámetro "-nodes" de OpenSSL para evitar el cifrado de la llave privada. Ejemplo 4-1. Creación de un certificado autofirmado para el servidor $ openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout ser ver.pem -days 365 Generating a 1024 bit RSA private key ..........................++++++ ...............................++++++ writing new private key to 'server.pem' ----- You are about to be asked to enter information that will be incorporate d into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:PT State or Province Name (full name) [Some-State]:Braganca Locality Name (eg, city) []:Braganca Organization Name (eg, company) [Internet Widgits Pty Ltd]:gsr.pt Organizational Unit Name (eg, section) []:gsr.pt Common Name (eg, YOUR name) []:gsr.pt Email Address []:sergio@gsr.pt Esto creará un archivo server.pem en el directorio donde haya ejecutado la orden del Ejemplo 4-1. Puede ver una muestra de su resultado en el Apéndice O. Ahora sólo falta indicar a OpenLDAP que utilice el certificado anteriormente creado. El siguiente ejemplo muestra las opciones de configuración que han de añadirse al archivo /etc/ldap/slapd.conf si se ha seguido el método de creación del certificado autofirmado. Ejemplo 4-2. Opciones de configuración para slapd.conf que añaden un certificado autofirmado en el servidor. TLSCACertificateFile server.pem TLSCertificateFile server.pem TLSCertificateKeyFile server.pem Nota Puede observarse en el ejemplo anterior, que las tres opciones poseen el mismo valor: "server.pem". Esto diferirá si se ha obtenido el certificado a partir de una CA, como puede verse en el Ejemplo 4-9. _________________________________________________________ 4.2.2. Certificado emitido por una CA Si ya posee una entidad certificadora (CA) de confianza, sáltese esta sección dedicada al proceso de obtención de un certificado firmado por una entidad certificadora y una llave privada para el servidor. Sin embargo, si no posee de una entidad certificadora de confianza, OpenSSL realiza el proceso rápida y fácilmente. Para ello siga los siguientes pasos: 1. Creación de un directorio para crear y firmar los certificados, por ejemplo: /var/tmp/mica Ejemplo 4-3. Creación de un directorio para crear y firmar los certificados $ /bin/mkdir -v /var/tmp/mica /bin/mkdir: se ha creado el directorio `/var/tmp/mica' 2. Sitúese en el directorio /var/tmp/mica y ejecute el script CA.sh de OpenSSL. Ejemplo 4-4. Creación de una entidad certificadora $ cd /var/tmp/mica $ /usr/lib/ssl/misc/CA.sh -newca CA certificate filename (or enter to create) [Enter] Making CA certificate ... Generating a 1024 bit RSA private key ....................+++ ...................................+++ writing new private key to './demoCA/private/./cakey.pem' Enter PEM pass phrase: [Clave ca] (1) Verifying - Enter PEM pass phrase: [Clave ca] ----- You are about to be asked to enter information that will be incorporate d into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:PT State or Province Name (full name) [Some-State]:Braganca Locality Name (eg, city) []:Braganca Organization Name (eg, company) [Internet Widgits Pty Ltd]:Companhia GS R Organizational Unit Name (eg, section) []:Unidade de certificados Common Name (eg, YOUR name) []:gsr.pt Email Address []:[Enter] (1) La clave utilizada ha de tener un mínimo de 4 caracteres. Esto creará la siguiente estructura de directorios bajo /var/tmp/mica: $ /usr/bin/tree . `-- demoCA |-- cacert.pem |-- certs |-- crl |-- index.txt |-- newcerts |-- private | `-- cakey.pem `-- serial 5 directories, 4 files Pero los archivos realmente interesantes son demoCA/cacert.pem y demoCA/private/cakey.pem (El certificado de la entidad certificadora y la llave privada, respectivamente). 3. Creamos la petición para la firma del certificado perteneciente al servidor (CSR): Ejemplo 4-5. Creación de la petición para la firma del certificado del servidor $ /usr/bin/openssl req -newkey rsa:1024 -nodes -keyout newreq.pem -out newreq.pem Generating a 1024 bit RSA private key ...++++++ ...........++++++ writing new private key to 'newreq.pem' ----- You are about to be asked to enter information that will be incorporate d into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:PT State or Province Name (full name) [Some-State]:Braganca Locality Name (eg, city) []:Braganca Organization Name (eg, company) [Internet Widgits Pty Ltd]:SubGSR Organizational Unit Name (eg, section) []:Controle de acesso Common Name (eg, YOUR name) []:gsr.pt Email Address []:sergio@gsr.pt Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:[Clave] (1) An optional company name []:.[Enter] (1) La clave utilizada ha de tener un mínimo de 4 caracteres. El resultado es el archivo newreq.pem. 4. Firma del CSR: Ejemplo 4-6. Firma del CSR $ /usr/lib/ssl/misc/CA.sh -sign Using configuration from /usr/lib/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem:[Clave ca] Check that the request matches the signature Signature ok Certificate Details: Serial Number: 1 (0x1) Validity Not Before: Sep 23 16:16:11 2004 GMT Not After : Sep 23 16:16:11 2005 GMT Subject: countryName = PT stateOrProvinceName = Braganca localityName = Braganca organizationName = SubGSR organizationalUnitName = Controle de acesso commonName = gsr.pt emailAddress = sergio@gsr.pt X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 8C:66:2C:3E:0F:63:2F:53:29:FA:28:EA:7F:59:A4:16:4C:DF:7 C:6C X509v3 Authority Key Identifier: keyid:F1:34:77:80:A4:34:4B:71:C8:BF:81:6C:DF:0C:98:D3:6 2:B7:10:BE DirName:/C=PT/ST=Braganca/L=Braganca/O=Companhia GSR/OU =Unidade de\ certificad os/CN=gsr.pt serial:00 Certificate is to be certified until Sep 23 16:16:11 2005 GMT (365 days ) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: C=PT, ST=Braganca, L=Braganca, O=Companhia GSR, OU=Unid ade de certificados,\ CN=gsr.pt Validity Not Before: Sep 23 16:16:11 2004 GMT Not After : Sep 23 16:16:11 2005 GMT Subject: C=PT, ST=Braganca, L=Braganca, O=SubGSR, OU=Controle d e acesso, \ CN=gsr.pt/email Address=sergio@gsr.pt Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:ab:bc:62:aa:75:ad:76:6d:05:e6:be:c2:b7:b7: 1f:28:3a:b9:ed:0b:b2:11:6a:9d:27:7b:06:69:89: 3a:13:3d:29:85:0d:02:87:b7:ac:cf:46:b0:01:3a: 30:c6:2e:25:13:af:6f:35:b6:d0:2c:ae:fb:42:24: 77:f3:c7:e1:a6:cb:00:35:ca:03:be:b1:d8:dd:22: de:d6:bc:e2:94:d4:1a:ae:47:83:95:0c:a2:ae:1f: c3:d3:f4:1d:7e:cd:cc:9c:48:28:63:35:5c:af:7b: c9:bf:f8:f7:de:2b:09:61:c6:40:30:76:e3:9f:51: 28:d0:61:b2:18:9a:d9:8a:53 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 8C:66:2C:3E:0F:63:2F:53:29:FA:28:EA:7F:59:A4:16:4C:DF:7 C:6C X509v3 Authority Key Identifier: keyid:F1:34:77:80:A4:34:4B:71:C8:BF:81:6C:DF:0C:98:D3:6 2:B7:10:BE DirName:/C=PT/ST=Braganca/L=Braganca/O=Companhia GSR/OU =Unidade de \ cer tificados/CN=gsr.pt serial:00 Signature Algorithm: md5WithRSAEncryption 27:43:54:46:14:dd:f5:2d:64:40:b4:dd:62:b4:79:d6:93:32: d4:56:0d:a7:80:60:6a:93:1a:c2:02:e3:f8:33:d9:4d:32:c7: 0b:34:29:01:72:98:1a:aa:c6:34:78:50:11:0d:92:ab:31:ba: 9b:3f:27:39:1a:19:8b:a0:2c:d7:ca:56:04:69:c4:ae:cc:e5: dc:fa:ce:da:11:a9:25:0c:db:d6:8c:60:b1:86:9a:02:06:c5: c4:da:8f:8e:a6:4d:84:06:3d:e1:ce:3e:d9:fa:d4:5b:d5:44: 36:4f:48:88:d0:ab:ec:03:e5:a7:4f:92:e8:8e:db:aa:89:7e: 02:e4 -----BEGIN CERTIFICATE----- MIIDkDCCAvmgAwIBAgIBATANBgkqhkiG9w0BAQQFADB+MQswCQYDVQQGEwJQVDER MA8GA1UECBMIQnJhZ2FuY2ExETAPBgNVBAcTCEJyYWdhbmNhMRYwFAYDVQQKEw1D b21wYW5oaWEgR1NSMSAwHgYDVQQLExdVbmlkYWRlIGRlIGNlcnRpZmljYWRvczEP MA0GA1UEAxMGZ3NyLnB0MB4XDTA0MDkyMzE2MTYxMVoXDTA1MDkyMzE2MTYxMVow gZAxCzAJBgNVBAYTAlBUMREwDwYDVQQIEwhCcmFnYW5jYTERMA8GA1UEBxMIQnJh Z2FuY2ExDzANBgNVBAoTBlN1YkdTUjEbMBkGA1UECxMSQ29udHJvbGUgZGUgYWNl c3NvMQ8wDQYDVQQDEwZnc3IucHQxHDAaBgkqhkiG9w0BCQEWDXNlcmdpb0Bnc3Iu cHQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKu8Yqp1rXZtBea+wre3Hyg6 ue0LshFqnSd7BmmJOhM9KYUNAoe3rM9GsAE6MMYuJROvbzW20Cyu+0Ikd/PH4abL ADXKA76x2N0i3ta84pTUGq5Hg5UMoq4fw9P0HX7NzJxIKGM1XK97yb/4994rCWHG QDB2459RKNBhshia2YpTAgMBAAGjggEJMIIBBTAJBgNVHRMEAjAAMCwGCWCGSAGG +EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU jGYsPg9jL1Mp+ijqf1mkFkzffGwwgaoGA1UdIwSBojCBn4AU8TR3gKQ0S3HIv4Fs 3wyY02K3EL6hgYOkgYAwfjELMAkGA1UEBhMCUFQxETAPBgNVBAgTCEJyYWdhbmNh MREwDwYDVQQHEwhCcmFnYW5jYTEWMBQGA1UEChMNQ29tcGFuaGlhIEdTUjEgMB4G A1UECxMXVW5pZGFkZSBkZSBjZXJ0aWZpY2Fkb3MxDzANBgNVBAMTBmdzci5wdIIB ADANBgkqhkiG9w0BAQQFAAOBgQAnQ1RGFN31LWRAtN1itHnWkzLUVg2ngGBqkxrC AuP4M9lNMscLNCkBcpgaqsY0eFARDZKrMbqbPyc5GhmLoCzXylYEacSuzOXc+s7a EaklDNvWjGCxhpoCBsXE2o+Opk2EBj3hzj7Z+tRb1UQ2T0iI0KvsA+WnT5Lojtuq iX4C5A== -----END CERTIFICATE----- Signed certificate is in newcert.pem Esto crea el archivo newcert.pem (el certificado del servidor firmado por la entidad certificadora) con la clave privada, newreq.pem. Nota Para verificar que el certificado está correctamente firmado se puede utilizar la siguiente orden: Ejemplo 4-7. Verificación de la firma creada en un certificado por una CA $ /usr/bin/openssl verify -CAfile demoCA/cacert.pem newcert.pem newcert.pem: OK 5. Ahora se puede renombrar y mover los certificados al sitio deseado. En este caso se moverá al directorio /etc/ldap/ssl, quedando la estructura final como sigue: Ejemplo 4-8. Estructura de directorios final para los certificados # /usr/bin/tree /etc/ldap/ssl /etc/ldap/ssl |-- cacert.pem |-- certs | `-- servidorcert.pem (1) |-- crl |-- index.txt |-- newcerts | `-- 01.pem |-- private | |-- cakey.pem | `-- servidorkey.pem (2) `-- serial 4 directories, 7 files (1) Este archivo se corresponde con el archivo newcert.pem generado tras el Ejemplo 4-6 (2) Este archivo se corresponde con el archivo newreq.pem generado tras el Ejemplo 4-6 Importante Sería recomendable hacer la llave privada del servidor sólo legible por el usuario con el que se ejecuta slapd, para ello teclee: # /bin/chmod -v 400 /etc/ldap/ssl/private/servidorkey.pem el modo de `/etc/ldap/ssl/private/servidorkey.pem' cambia a 0400 (r---- ----) Los demás certificados tendría que poderse leer por todo el mundo. 6. Hacer que el certificado de la entidad certificadora esté disponible para los clientes de LDAP. Si los clientes están en la misma máquina, se ha de copiar el archivo cacert.pem a un lugar accesible por los clientes. Si los clientes están en otros equipos, se ha de copiar el archivo cacert.pem a esas máquinas y hacerlo accesible. Como se ha podido apreciar, este proceso requieres algunos pasos más que la creación un certificado autofirmado, pero los beneficios obtenidos sobrepasan cualquier gasto de tiempo empleado en crear la entidad certificadora. _________________________________________________________ 4.2.3. El certificado de los clientes Los certificados para los clientes se crean de forma similar a los certificados para el servidor. Si se siguen los pasos detallados en Sección 4.2.2, los únicos cambios son los siguientes: 1 y 2: No se hace nada... no se necesita crear de nuevo la entidad certificadora. El objetivo es utilizar la misma entidad certificadora para firmar el certificado del cliente. 3: Se ejecuta todo lo que allí se muestra, lo único que se ha de cambiar es el nombre del servidor por el del cliente cuando se pregunte el "Common Name". Se da por supuesto que todas las demás respuestas se han de ajustar a los datos del cliente. 4: Las mismas órdenes, obteniéndose los mismos archivos para el certificado y la llave privada. ¡Gracias que se renombró el certificado en el 5!. 5: Ahora se puede renombrar y mover el certificado y la llave privada del cliente al lugar indicado (por ejemplo, /home/usuario/ssl/[10]). También sería recomendable que cambiase los permisos de la llave privada, para que sólo pueda ser leída por el usuario al que pertenece. 6: No se ha de hacer nada en este paso. Ahora que ya están creados los certificados, sólo queda configurar OpenLDAP. _________________________________________________________ 4.3. Configuración de OpenLDAP Hay tres áreas a considerar para la configuración de OpenLDAP: el servidor (slapd.conf), el cliente (ldap.conf) y el directorio (schema). Esta sección configurará los requerimientos de un servidor SSL así como la autentificación de un cliente. Nota Un ejemplo completo del archivo de configuración del demonio slapd se encuentra en el Apéndice Q _________________________________________________________ 4.3.1. Servidor Se ha de añadir las siguientes líneas al archivo de configuración de slapd, slapd.conf. Ejemplo 4-9. Líneas de configuración para un servidor SSL/TLS # Certificado firmado de una entidad certificadora y # el certificado del servidor TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /etc/ldap/ssl/cacert.pem TLSCertificateFile /etc/ldap/ssl/certs/servidorcert.pem TLSCertificateKeyFile /etc/ldap/ssl/private/servidorkey.pem # Si desea que el cliente necesite autentificación, # descomente la siguiente línea TLSVerifyClient demand # ... si no, descomente esta otra # TLSVerifyClient never _________________________________________________________ 4.3.2. Cliente El archivo de configuración /etc/ldap/ldap.conf configura las opciones por defecto para los clientes LDAP. Si se necesitan valores específicos para los usuarios, se puede crear el archivo ldaprc o .ldaprc en el home del usuario o en el directorio actual, lo que sobreescribirá la configuración global de LDAP. Atención Si se requiere la autentificación de los clientes, se necesita añadir el certificado y la llave privada del cliente al archivo ldaprc o .ldaprc. _________________________________________________________ 4.3.2.1. Directivas de configuración del cliente LDAP La siguiente tabla refleja las directivas referentes a la parte de configuración del cliente LDAP. Las ocurrencias de las palabras específicas para usuarios quieren decir que las directivas a las que afectan sólo son aplicadas en la configuración del archivo ldaprc o .ldaprc, no son directivas globales de LDAP. Tabla 4-1. Directivas de configuración de clientes LDAP Directiva Valor Descripción BASE dn Base por defecto (Default Base - DN) a utilizar cuando se realizan operaciones ldap BINDDN dn Base por defecto a la que cambiar cuando se realizan operaciones ldap específicas para usuarios HOST nombre[:puerto] Nombre de los servidores LDAP a los que conectarse (separados por espacios) PORT número Puerto por defecto utilizado en las conexiones a un servidor LDAP. 636 = SSL SIZELIMIT número Límite de resultados devueltos en una búsqueda (0 = sin límite) TIMELIMIT número Límite en el tiempo de búsqueda (0 = sin límite) TLS nivel Si el usuario ha de utilizar TLS por defecto ( never | hard ), el uso de esta directiva está desaconsejado; es incompatible con la petición StartTLS de LDAPv3 TLS_CACERT nombre de un archivo Especifica el archivo que contiene todos los certificados pertenecientes a entidades certificadoras que el cliente reconoce TLS_CACERTDIR directorio Usado si falla TLS_CACERT TLS_REQCERT nivel Especifica que tipo de comprobación se ha de realizar a un certificado de servidor ( never | allow | try | demand,hard ) TLS_CERT nombre de un archivo Autentificación de clientes: especifica el certificado del cliente específico del usuario TLS_KEY nombre de un archivo Autentificación de clientes: especifica la llave privada, para la entrada TLS_CERT, específico del usuario _________________________________________________________ 4.3.2.2. Ejemplo de un archivo ldap.conf A continuación se muestra un ejemplo de configuración de un archivo ldap.conf: Nota En el Apéndice R se encuentra un ejemplo de configuración más extenso de este archivo. Ejemplo 4-10. Ejemplo de configuración de un archivo ldap.conf # # Configuración global de LDAP # # Lea ldap.conf(5) para más detalles # Este archivo se ha de poder leer por todo el mundo, pero no escribir. HOST gsr.pt BASE dc=gsr, dc=pt PORT 636 TLS_CACERT /etc/ldap/ssl/certs/cacert.pem TLS_REQCERT demand Esta configuración hará que los clientes se conecten a ldaps://gsr.pt:636 sin necesidad de especificar el host ni el puerto en las órdenes del cliente. _________________________________________________________ 4.3.2.3. Ejemplo de un archivo .ldaprc El archivo .ldaprc se utiliza para sobreescribir las opciones globales de LDAP y para establecer el el certificado y la llave privada utilizados para la autentificación del cliente. Ejemplo 4-11. Ejemplo de configuración de un archivo .ldaprc (en el home del usuario o en el directorio actual) # # Configuraciones de usuario específicas para LDAP # # Sobreescribe la directiva global (si se ha establecido) TLS_REQCERT demand # Autentificación del cliente TLS_CERT /home/ldap-user/ssl/certs/client.cert.pem TLS_KEY /home/ldap-user/ssl/certs/keys/client.key.pem Esta configuración mínima es todo lo que se necesita para la autentificación de un cliente. _________________________________________________________ 4.3.3. Schema En el archivo slapd.conf, los esquemas (schema) aparecen cerca de la parte superior del archivo. A continuación se muestra un ejemplo de algunos de los esquemas que se pueden establecer. Nota En el directorio /etc/ldap/schema se encuentran varias definiciones de esquemas para LDAP. Ejemplo 4-12. Esquemas en un archivo de configuración slapd.conf include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/inetorgperson.schema _________________________________________________________ 4.3.4. Resumen de configuración Existen varios grados de configuración SSL que se pueden establecer. La Tabla 4-2 resume las directivas y los valores que estas han de tomar para realizar desde una configuración básica ("Básica") a una muy estricta ("La mejor") en el servidor, en cuanto a conexiones SSL se refiere. Tabla 4-2. Resumen de configuración SSL en LDAP Archivo Directiva Básica OK Buena Mejor La mejor slapd.conf TLSCACertificateFile o TLSCACertificatePath x x x x x TLSCertificateFile x x x x x TLSCertificateKeyFile x x x x x TLSCipherSuite - x x x x TLSVerifyClient never never allow try demand ldap.conf TLS_CACERT - x x x x TLS_CACERTDIR (opcional) - x x x x TLS_REQCERT never never allow try demand ldaprc o .ldaprc TLS_CERT - - - x x TLS_KEY - - - x x LEYENDA: -: no se usa x: se usa y se ha de asignar un nombre de archivo o un directorio Note: El valor por defecto de TLSVerifyClient es "never" y el valor por defecto de TLS_REQCERT es "demand" _________________________________________________________ 4.4. Solución temporal a los problemas de OpenLDAP en Debian GNU/Linux 4.4.1. Descripción del problema Debido a un problema de licencias con OpenSSL, los desarrolladores de Debian han decidido incorporar GNU TLS al paquete de OpenLDAP de esta distribución. Este soporte no se ha incorporado oficialmente al proyecto OpenLDAP, y la implementación que se distribuye desde Debian no funciona correctamente. El principal problema que se ha presentado en la realización de esta documentación, relacionado con el soporte de gnutls por parte de OpenLDAP, ha sido que no reconoce el certificado generado en la Sección 4.2, por lo que no puede verificar su autenticidad, y por lo tanto no se puede establecer una conexión segura. _________________________________________________________ 4.4.1.1. Posible solución: uso de OpenSSL La primera solución que se planteó, para poder llevar a cabo la parte de cifrado de esta documentación, fue el empleo de OpenSSL en detrimento de GNU TLS[11]. La solución pasaba por especificar, en las opciones de compilación de OpenLDAP, el empleo de OpenSSL para el cifrado (en Debian se utiliza GNU TLS por defecto). Para ello, y teniendo en cuenta el reporte 214753 [12] del sistema de seguimiento de errores de Debian, se recompiló el paquete OpenLDAP con esta nueva opción y se probó el funcionamiento del sistema. Con el uso de OpenSSL, en lugar de GNU TLS, el certificado ya era reconocido y permitía realizar conexiones cifradas con el servidor LDAP. Pero ahora se presentaba un nuevo problema[13]: tras finalizar la ejecución de cualquier orden que implicara la conexión cifrada con el servidor LDAP, se obtenía una violación de segmento (segmentation fault). Este problema impedía, por ejemplo, hacer uso de las cuentas almacenadas en el directorio LDAP para acceder al sistema. Después de un período de pruebas y análisis del problema, se consiguió solucionarlo, presentando la solución en la siguiente sección. _________________________________________________________ 4.4.2. Solución temporal propuesta Después del planteamiento del problema (Sección 4.4.1), la solución que se ha llevado a cabo ha sido la de eliminar los parches aplicados por los desarrolladores de Debian, para dar soporte GNU TLS a OpenLDAP, entre otros. Atención De todas formas, ha de tomarse esta solución como algo temporal (a la espera de que se solucionen los problemas con el paquete de Debian). Si se desea hacer uso de cifrado junto con OpenLDAP en un entorno de producción, sería recomendable utilizar la versión oficial estable de OpenLDAP (en estos momentos es la versión 2.2.*), que todavía no tiene paquetes para Debian. En las siguientes secciones se muestran los pasos seguidos para aplicar la solución planteada. _________________________________________________________ 4.4.2.1. Obtención del código fuente de OpenLDAP Puede obtener el código fuente de la versión 2.1.30 de OpenLDAP de dos formas: a partir del proyecto OpenLDAP o de los distintos mirrors de Debian. Si opta por la segunda opción, tendrá que teclear la siguiente orden en un directorio en el que tenga permisos de escritura: Ejemplo 4-13. Obtención del código fuente de OpenLDAP $ /usr/bin/apt-get source openldap2 Nota Asegúrese de tener una entrada deb-src en el archivo /etc/apt/sources.list que apunte a uno de los mirrors de Debian, para poder bajarse el código fuente de OpenLDAP. _________________________________________________________ 4.4.2.2. Aplicación del parche La solución planteada se muestra en forma de parche a las fuentes de OpenLDAP. Dependiendo de donde haya obtenido el código fuente, tendrá que aplicar uno u otro parche (ambos darán el mismo resultado): * Si ha obtenido el código fuente de OpenLDAP del proyecto oficial, ha de aplicar el siguiente parche: openldap-2.1.30-debianized.patch.bz2. * Si ha preferido obtener el código fuente desde Debian, ha de aplicar el siguiente parche: openldap-2.1.30-without-gnutls.patch.bz2. El proceso para aplicar los parches es similar en ambas situaciones, por lo que aquí sólo se mostrará el proceso para una de ellas. Se aplicará el parche al código fuente obtenido desde Debian. Ejemplo 4-14. Aplicando el parche a las fuentes de OpenLDAP $ cd openldap2-2.1.30/ /usr/bin/bzcat ../openldap-2.1.30-without-gnutls.patch.bz2 | /usr/bin/p atch -p1 patching file configure patching file configure.in patching file contrib/ldapc++/config.guess patching file contrib/ldapc++/config.sub patching file debian/changelog patching file debian/control patching file include/ldap_pvt_gnutls.h patching file include/portable.h.in patching file libraries/libldap/getdn.c patching file libraries/libldap/gnutls.c patching file libraries/libldap/Makefile.in patching file libraries/libldap/tls.c patching file libraries/libldap_r/Makefile.in patching file servers/slapd/schema_init.c _________________________________________________________ 4.4.2.3. Resolviendo las dependencias de compilación El último paso, antes de proceder a recompilar el código, es la resolución de las dependencias de compilación de OpenLDAP. Para ello, ha de ejecutar: Ejemplo 4-15. Resolviendo las dependencias de compilación para OpenLDAP # /usr/bin/apt-get build-dep openldap2 La orden anterior instalará dos paquetes, libgnutls11-dev y libgcrypt11-dev, que no son necesarios tras aplicar el parche, por lo que puede desinstalarlos si lo considera oportuno. _________________________________________________________ 4.4.2.4. Compilación del paquete Ahora ya está todo listo para proceder a recompilar el paquete, para ello teclee: Ejemplo 4-16. Compilando OpenLDAP $ /usr/bin/dpkg-buildpackage -us -uc -b -rfakeroot Tras la compilación, se habrán generado los siguientes paquetes: Ejemplo 4-17. Listado de paquetes de OpenLDAP $ /bin/ls -l ../*deb -rw-r--r-- 1 sergio src 112810 2004-09-21 22:12 ldap-utils_2.1.30-3.1_ i386.deb -rw-r--r-- 1 sergio src 284366 2004-09-21 22:12 libldap2_2.1.30-3.1_i3 86.deb -rw-r--r-- 1 sergio src 321336 2004-09-21 22:12 libldap2-dev_2.1.30-3. 1_i386.deb -rw-r--r-- 1 sergio src 71864 2004-09-21 22:12 libslapd2-dev_2.1.30-3 .1_all.deb -rw-r--r-- 1 sergio src 945220 2004-09-21 22:12 slapd_2.1.30-3.1_i386. deb _________________________________________________________ 4.4.2.5. Instalación de los nuevos paquetes La única acción que nos queda por hacer es la instalación de los nuevos paquetes que se han generado. Para ello teclee: Ejemplo 4-18. Instalación de los nuevos paquetes de OpenLDAP # /usr/bin/dpkg -i ../slapd_2.1.30-3.1_i386.deb \ ../ldap-utils_2.1.30-3.1_i386.deb \ ../libldap2_2.1.30-3.1_i386.deb (Leyendo la base de datos ... 132792 ficheros y directorios instalados actualmente.) Preparando para reemplazar slapd 2.1.30-3 (usando slapd_2.1.30-3.1_i386 .deb) ... Stopping OpenLDAP: slapd. Stopping OpenLDAP: slapd. Desempaquetando el reemplazo de slapd ... Preparando para reemplazar ldap-utils 2.1.30-3 (usando ldap-utils_2.1.3 0-3.1_i386.deb) ... Desempaquetando el reemplazo de ldap-utils ... Preparando para reemplazar libldap2 2.1.30-3 (usando libldap2_2.1.30-3. 1_i386.deb) ... Desempaquetando el reemplazo de libldap2 ... Configurando libldap2 (2.1.30-3.1) ... Configurando slapd (2.1.30-3.1) ... Starting OpenLDAP: slapd. Configurando ldap-utils (2.1.30-3.1) ... Con esto se finalizaría la instalación del servidor OpenLDAP modificado. _________________________________________________________ 4.5. Probando el servidor en modo seguro En este punto ya se puede re/iniciar el demonio slapd con la nueva configuración de seguridad. Para ello emplee la orden /etc/init.d/slapd restart (en el Ejemplo 3-7 se muestra como hacerlo). En las siguientes secciones se verá la forma de comprobar que OpenLDAP se comporta como debe. Para cumplir este objetivo, se hará uso de las herramientas que vienen con OpenSSL para verificar las conexiones SSL y se realizarán búsquedas en el directorio LDAP. _________________________________________________________ 4.5.1. Comprobando la conexión SSL Nota Antes de ejecutar la siguiente orden, ha de asegurarse que valor tiene la variable TLSVerifyClient. Si su valor es demand, la orden no se ejecutará correctamente, ya que el cliente no se ha autentificado, como se requiere en la configuración de OpenLDAP. Nótese que a la orden del Ejemplo 4-19 se le pasa como argumento[14] el certificado de la entidad certificadora del cliente. ¿Por qué se ha de especificar el certificado, si ya se ha configurado en el archivo ldap.conf? la razón es porque la orden que estamos ejecutando, es una orden dependiente de OpenSSL y no de OpenLDAP. Ejemplo 4-19. Comprobando la conexión SSL sin autentificación del cliente $ /usr/bin/openssl s_client -connect gsr.pt:636 -showcerts -state \ -CAfile /etc/ldap/ssl/cacert.pem CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=1 /C=PT/ST=Braganca/L=Braganca/O=Companhia GSR/OU=Unidade de cert ificados/CN=gsr.pt verify return:1 depth=0 /C=PT/ST=Braganca/L=Braganca/O=SubGSR/OU=Controle de \ acesso/CN=gsr.pt/emailAdd ress=sergio@gsr.pt verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A --- Certificate chain 0 s:/C=PT/ST=Braganca/L=Braganca/O=SubGSR/OU=Controle de \ acesso/CN=gsr.pt/emailAddres s=sergio@gsr.pt i:/C=PT/ST=Braganca/L=Braganca/O=Companhia GSR/OU=Unidade de certifi cados/CN=gsr.pt -----BEGIN CERTIFICATE----- MIIDkDCCAvmgAwIBAgIBATANBgkqhkiG9w0BAQQFADB+MQswCQYDVQQGEwJQVDER MA8GA1UECBMIQnJhZ2FuY2ExETAPBgNVBAcTCEJyYWdhbmNhMRYwFAYDVQQKEw1D b21wYW5oaWEgR1NSMSAwHgYDVQQLExdVbmlkYWRlIGRlIGNlcnRpZmljYWRvczEP MA0GA1UEAxMGZ3NyLnB0MB4XDTA0MDkyMzE2MTYxMVoXDTA1MDkyMzE2MTYxMVow gZAxCzAJBgNVBAYTAlBUMREwDwYDVQQIEwhCcmFnYW5jYTERMA8GA1UEBxMIQnJh Z2FuY2ExDzANBgNVBAoTBlN1YkdTUjEbMBkGA1UECxMSQ29udHJvbGUgZGUgYWNl c3NvMQ8wDQYDVQQDEwZnc3IucHQxHDAaBgkqhkiG9w0BCQEWDXNlcmdpb0Bnc3Iu cHQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKu8Yqp1rXZtBea+wre3Hyg6 ue0LshFqnSd7BmmJOhM9KYUNAoe3rM9GsAE6MMYuJROvbzW20Cyu+0Ikd/PH4abL ADXKA76x2N0i3ta84pTUGq5Hg5UMoq4fw9P0HX7NzJxIKGM1XK97yb/4994rCWHG QDB2459RKNBhshia2YpTAgMBAAGjggEJMIIBBTAJBgNVHRMEAjAAMCwGCWCGSAGG +EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU jGYsPg9jL1Mp+ijqf1mkFkzffGwwgaoGA1UdIwSBojCBn4AU8TR3gKQ0S3HIv4Fs 3wyY02K3EL6hgYOkgYAwfjELMAkGA1UEBhMCUFQxETAPBgNVBAgTCEJyYWdhbmNh MREwDwYDVQQHEwhCcmFnYW5jYTEWMBQGA1UEChMNQ29tcGFuaGlhIEdTUjEgMB4G A1UECxMXVW5pZGFkZSBkZSBjZXJ0aWZpY2Fkb3MxDzANBgNVBAMTBmdzci5wdIIB ADANBgkqhkiG9w0BAQQFAAOBgQAnQ1RGFN31LWRAtN1itHnWkzLUVg2ngGBqkxrC AuP4M9lNMscLNCkBcpgaqsY0eFARDZKrMbqbPyc5GhmLoCzXylYEacSuzOXc+s7a EaklDNvWjGCxhpoCBsXE2o+Opk2EBj3hzj7Z+tRb1UQ2T0iI0KvsA+WnT5Lojtuq iX4C5A== -----END CERTIFICATE----- 1 s:/C=PT/ST=Braganca/L=Braganca/O=Companhia GSR/OU=Unidade de certifi cados/CN=gsr.pt i:/C=PT/ST=Braganca/L=Braganca/O=Companhia GSR/OU=Unidade de certifi cados/CN=gsr.pt -----BEGIN CERTIFICATE----- MIIDUDCCArmgAwIBAgIBADANBgkqhkiG9w0BAQQFADB+MQswCQYDVQQGEwJQVDER MA8GA1UECBMIQnJhZ2FuY2ExETAPBgNVBAcTCEJyYWdhbmNhMRYwFAYDVQQKEw1D b21wYW5oaWEgR1NSMSAwHgYDVQQLExdVbmlkYWRlIGRlIGNlcnRpZmljYWRvczEP MA0GA1UEAxMGZ3NyLnB0MB4XDTA0MDkyMzE2MDY1NFoXDTA1MDkyMzE2MDY1NFow fjELMAkGA1UEBhMCUFQxETAPBgNVBAgTCEJyYWdhbmNhMREwDwYDVQQHEwhCcmFn YW5jYTEWMBQGA1UEChMNQ29tcGFuaGlhIEdTUjEgMB4GA1UECxMXVW5pZGFkZSBk ZSBjZXJ0aWZpY2Fkb3MxDzANBgNVBAMTBmdzci5wdDCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEA15+Ciw1MUiRiY88v0rsAZDr+W/w4uQ3bx20v3ddE9Ok0mwv0 vE+DDJjKVUL4FK0rUe8ReDka4D3kB9j2vshWJjf2pA5nWtsoBgm5Dft0RIHM82GM KCqeG5Lb7/21UaKloJNXTDPfh/HVydQzt2Uivbss3iUdGaDuKCt7IKynA/kCAwEA AaOB3TCB2jAdBgNVHQ4EFgQU8TR3gKQ0S3HIv4Fs3wyY02K3EL4wgaoGA1UdIwSB ojCBn4AU8TR3gKQ0S3HIv4Fs3wyY02K3EL6hgYOkgYAwfjELMAkGA1UEBhMCUFQx ETAPBgNVBAgTCEJyYWdhbmNhMREwDwYDVQQHEwhCcmFnYW5jYTEWMBQGA1UEChMN Q29tcGFuaGlhIEdTUjEgMB4GA1UECxMXVW5pZGFkZSBkZSBjZXJ0aWZpY2Fkb3Mx DzANBgNVBAMTBmdzci5wdIIBADAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBAUA A4GBAEyudW3FLXIFNbWQ7qJqEE6KhrsiSgR1+VjavJZJP0j2A5sf0vsp083mWJd5 yCWvgxb/Bcx2kbi9KjeP/dtYJM0drAQzFAW4CQQBNxsk3lNkEMot0/8epybirKVG nThgAkySYQDPXfNEc5qSm2eAgLI7aElBLHQk2R6YVn26i0Gu -----END CERTIFICATE----- --- Server certificate subject=/C=PT/ST=Braganca/L=Braganca/O=SubGSR/OU=Controle de \ acesso/CN=gsr.pt/emailAddr ess=sergio@gsr.pt issuer=/C=PT/ST=Braganca/L=Braganca/O=Companhia GSR/OU=Unidade de certi ficados/CN=gsr.pt --- No client certificate CA names sent (1) --- SSL handshake has read 1933 bytes and written 340 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024 bit SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: C5101CF18CB3C821E1AD7C6CCD74693773C1AF75D2A209C6E12075B 300A29CF2 Session-ID-ctx: Master-Key: DB2972AF0D2AFF52B57861BBFE8164F5DE2347D3B5248C8D193C26F 9B2DA93C6FFB16\ A705BAD54477 16F7BAB2DA958D6 Key-Arg : None Start Time: 1095969142 Timeout : 300 (sec) Verify return code: 0 (ok) --- (1) Esta línea indica que el cliente no se ha autentificado ante el servidor. Nota Normalmente, para finalizar la ejecución de la orden anterior, se ha de pulsar Ctrl+c. No se preocupe por ello. Ahora se verá un ejemplo donde el cliente se autentifica ante el servidor: Ejemplo 4-20. Comprobando la conexión SSL con autentificación del cliente $ /usr/bin/openssl s_client -connect gsr.pt:636 -state \ -CAfile /etc/ldap/ssl/cacert.pem \ -cert /home/certs/ldap.cliente.cert.pem \ -key /home/certs/ldap.cliente.key.pem CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=1 /C=PT/ST=Braganca/L=Braganca/O=Companhia GSR/OU=Unidade de cert ificados/CN=gsr.pt verify return:1 depth=0 /C=PT/ST=Braganca/L=Braganca/O=SubGSR/OU=Controle de \ acesso/CN=gsr.pt/emailAd dress=sergio@gsr.pt verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server certificate request A (1) SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client certificate A (2) SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write certificate verify A (3) SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A --- Certificate chain 0 s:/C=PT/ST=Braganca/L=Braganca/O=SubGSR/OU=Controle de \ acesso/CN=gsr.pt/emailAdd ress=sergio@gsr.pt i:/C=PT/ST=Braganca/L=Braganca/O=Companhia GSR/OU=Unidade de certifi cados/CN=gsr.pt -----BEGIN CERTIFICATE----- MIIDkDCCAvmgAwIBAgIBATANBgkqhkiG9w0BAQQFADB+MQswCQYDVQQGEwJQVDER MA8GA1UECBMIQnJhZ2FuY2ExETAPBgNVBAcTCEJyYWdhbmNhMRYwFAYDVQQKEw1D b21wYW5oaWEgR1NSMSAwHgYDVQQLExdVbmlkYWRlIGRlIGNlcnRpZmljYWRvczEP MA0GA1UEAxMGZ3NyLnB0MB4XDTA0MDkyMzE2MTYxMVoXDTA1MDkyMzE2MTYxMVow gZAxCzAJBgNVBAYTAlBUMREwDwYDVQQIEwhCcmFnYW5jYTERMA8GA1UEBxMIQnJh Z2FuY2ExDzANBgNVBAoTBlN1YkdTUjEbMBkGA1UECxMSQ29udHJvbGUgZGUgYWNl c3NvMQ8wDQYDVQQDEwZnc3IucHQxHDAaBgkqhkiG9w0BCQEWDXNlcmdpb0Bnc3Iu cHQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKu8Yqp1rXZtBea+wre3Hyg6 ue0LshFqnSd7BmmJOhM9KYUNAoe3rM9GsAE6MMYuJROvbzW20Cyu+0Ikd/PH4abL ADXKA76x2N0i3ta84pTUGq5Hg5UMoq4fw9P0HX7NzJxIKGM1XK97yb/4994rCWHG QDB2459RKNBhshia2YpTAgMBAAGjggEJMIIBBTAJBgNVHRMEAjAAMCwGCWCGSAGG +EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU jGYsPg9jL1Mp+ijqf1mkFkzffGwwgaoGA1UdIwSBojCBn4AU8TR3gKQ0S3HIv4Fs 3wyY02K3EL6hgYOkgYAwfjELMAkGA1UEBhMCUFQxETAPBgNVBAgTCEJyYWdhbmNh MREwDwYDVQQHEwhCcmFnYW5jYTEWMBQGA1UEChMNQ29tcGFuaGlhIEdTUjEgMB4G A1UECxMXVW5pZGFkZSBkZSBjZXJ0aWZpY2Fkb3MxDzANBgNVBAMTBmdzci5wdIIB ADANBgkqhkiG9w0BAQQFAAOBgQAnQ1RGFN31LWRAtN1itHnWkzLUVg2ngGBqkxrC AuP4M9lNMscLNCkBcpgaqsY0eFARDZKrMbqbPyc5GhmLoCzXylYEacSuzOXc+s7a EaklDNvWjGCxhpoCBsXE2o+Opk2EBj3hzj7Z+tRb1UQ2T0iI0KvsA+WnT5Lojtuq iX4C5A== -----END CERTIFICATE----- 1 s:/C=PT/ST=Braganca/L=Braganca/O=Companhia GSR/OU=Unidade de certifi cados/CN=gsr.pt i:/C=PT/ST=Braganca/L=Braganca/O=Companhia GSR/OU=Unidade de certifi cados/CN=gsr.pt -----BEGIN CERTIFICATE----- MIIDUDCCArmgAwIBAgIBADANBgkqhkiG9w0BAQQFADB+MQswCQYDVQQGEwJQVDER MA8GA1UECBMIQnJhZ2FuY2ExETAPBgNVBAcTCEJyYWdhbmNhMRYwFAYDVQQKEw1D b21wYW5oaWEgR1NSMSAwHgYDVQQLExdVbmlkYWRlIGRlIGNlcnRpZmljYWRvczEP MA0GA1UEAxMGZ3NyLnB0MB4XDTA0MDkyMzE2MDY1NFoXDTA1MDkyMzE2MDY1NFow fjELMAkGA1UEBhMCUFQxETAPBgNVBAgTCEJyYWdhbmNhMREwDwYDVQQHEwhCcmFn YW5jYTEWMBQGA1UEChMNQ29tcGFuaGlhIEdTUjEgMB4GA1UECxMXVW5pZGFkZSBk ZSBjZXJ0aWZpY2Fkb3MxDzANBgNVBAMTBmdzci5wdDCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEA15+Ciw1MUiRiY88v0rsAZDr+W/w4uQ3bx20v3ddE9Ok0mwv0 vE+DDJjKVUL4FK0rUe8ReDka4D3kB9j2vshWJjf2pA5nWtsoBgm5Dft0RIHM82GM KCqeG5Lb7/21UaKloJNXTDPfh/HVydQzt2Uivbss3iUdGaDuKCt7IKynA/kCAwEA AaOB3TCB2jAdBgNVHQ4EFgQU8TR3gKQ0S3HIv4Fs3wyY02K3EL4wgaoGA1UdIwSB ojCBn4AU8TR3gKQ0S3HIv4Fs3wyY02K3EL6hgYOkgYAwfjELMAkGA1UEBhMCUFQx ETAPBgNVBAgTCEJyYWdhbmNhMREwDwYDVQQHEwhCcmFnYW5jYTEWMBQGA1UEChMN Q29tcGFuaGlhIEdTUjEgMB4GA1UECxMXVW5pZGFkZSBkZSBjZXJ0aWZpY2Fkb3Mx DzANBgNVBAMTBmdzci5wdIIBADAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBAUA A4GBAEyudW3FLXIFNbWQ7qJqEE6KhrsiSgR1+VjavJZJP0j2A5sf0vsp083mWJd5 yCWvgxb/Bcx2kbi9KjeP/dtYJM0drAQzFAW4CQQBNxsk3lNkEMot0/8epybirKVG nThgAkySYQDPXfNEc5qSm2eAgLI7aElBLHQk2R6YVn26i0Gu -----END CERTIFICATE----- --- Server certificate subject=/C=PT/ST=Braganca/L=Braganca/O=SubGSR/OU=Controle de \ acesso/CN=gsr.pt/emailAddr ess=sergio@gsr.pt issuer=/C=PT/ST=Braganca/L=Braganca/O=Companhia GSR/OU=Unidade de certi ficados/CN=gsr.pt --- Acceptable client certificate CA names (4) /C=PT/ST=Braganca/L=Braganca/O=Companhia GSR/OU=Unidade de certificados /CN=gsr.pt --- SSL handshake has read 2072 bytes and written 2274 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024 bit SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: CE4D0BFD367AF2F4B2E51ECB8C48A1D1A3F5EC0F00346EF13551534 C1F1CE8E1 Session-ID-ctx: Master-Key: 4D9089B2602C0376B92079BA539D8D3F244B5CBF31A68FD3A51DDC8 01251AA16\ 5C194DA63B1BFB7025D818 F2480E6450 Key-Arg : None Start Time: 1095970126 Timeout : 300 (sec) Verify return code: 0 (ok) --- (1) (2) (3) (4) Negociado extra relacionado con la comunicación SSL. _________________________________________________________ 4.5.2. Uso de cifrado con las herramientas de OpenLDAP OpenLDAP tiene varias herramientas, como son: ldapsearch, ldapadd, ldapmodify y ldapdelete. A continuación se verán algunos ejemplos de su uso, para ilustrar la comunicación mediante SSL y TLS. Los ejemplos se centrarán en las búsquedas de varias entradas, previamente incorporadas al directorio. _________________________________________________________ 4.5.2.1. Añadir datos al directorio Lo primero que se va a hacer es añadir una serie de datos al directorio LDAP, sobre los cuales, posteriormente, se realizarán las búsquedas. Para ello, puede copiar el siguiente texto a un archivo denominado datos-iniciales.ldif, por ejemplo. Tenga en cuenta que ha de eliminar cualquier espacio al inicio o al final de las líneas del ejemplo. Tampoco olvide adaptar el ejemplo que aquí se presenta a su configuración. #datos-iniciales.ldif dn: cn=sergio,dc=gsr,dc=pt objectclass: organizationalRole cn: sergio dn: ou=unidade de contas,dc=gsr,dc=pt objectclass: organizationalUnit ou: unidade de contas description: Organizacao de provas que contera ao administrador dn: cn=senhor administrador,ou=unidade de contas,dc=gsr,dc=pt objectclass: person userPassword: chaveprova description: Usuario de exemplo como administrador cn: senhor administrador sn: admin Ahora se procederá a añadir estas entradas a la base de datos de LDAP, para ello haga uso del usuario administrador de su directorio LDAP. Ejemplo 4-21. Incorporación de datos al directorio LDAP por medio de un archivo LDIF $ /usr/bin/ldapadd -x -D "cn=admin,dc=gsr,dc=pt" -W -f datos-iniciales. ldif Enter LDAP Password:[Clave] adding new entry "cn=sergio,dc=gsr,dc=pt" adding new entry "ou=unidade de contas,dc=gsr,dc=pt" adding new entry "cn=senhor administrador,ou=unidade de contas,dc=gsr,d c=pt" La orden anterior se ha realizado en texto plano, por lo que la transmisión de la clave del administrador del directorio LDAP se ha hecho sin ningún tipo de cifrado, como se puede apreciar en la siguiente captura de pantalla (debajo del color rojo aparece la clave del administrador): Figura 4-1. Captura de la clave del administrador del directorio LDAP con ethereal [openldap-certificado-ethereal.png] Al comunicarse con el servidor LDAP sin hacer uso de cifrado, las claves de los usuarios viajan en texto plano, como puede apreciarse en esta captura de pantalla. Las líneas en rojo ocultan la clave del administrador del directorio LDAP capturada por el programa ethereal. Para evitar esta situación, se puede hacer uso de SSL o TLS en las comunicaciones con el servidor LDAP. Las siguientes secciones explican como hacerlo: _________________________________________________________ 4.5.2.1.1. Cómo activar el cifrado SSL en las comunicaciones con el servidor LDAP Para asegurarse de que sus comunicaciones con el servidor LDAP utilizan SSL al hacer uso de las herramientas que incorpora OpenLDAP, ha de añadir el siguiente parámetro a sus órdenes: "-H ldaps://gsr.pt/". _________________________________________________________ 4.5.2.1.2. Cómo activar el cifrado TLS en las comunicaciones con el servidor LDAP La principal diferencia entre una conexión SSL y una TLS, es que la primera siempre utilizará el cifrado en la conexión mientras que la segunda provee al cliente la opción de hacer uso de cifrado cuando lo desee. Tenga en cuenta que por el simple hecho de acceder al servidor mediante ldap://:389 no asegura que la conexión haga uso de cifrado TLS, pero tampoco si accede mediante ldaps://. Para activar una conexión TLS tendrá que hace uso del parámetro "-Z" o "-ZZ". El parámetro "-ZZ" fuerza que la negociación TLS tenga éxito, mientras que el parámetro "-Z", intenta habilitar el cifrado TLS, pero si no lo consigue, continua con la conexión sin TLS. _________________________________________________________ 4.5.2.2. Búsquedas en el directorio En esta sección se realizarán una serie de búsquedas en el directorio. El uso del parámetro -D "cn=admin,dc=gsr,dc=pt" es necesario, debido a la restricción de acceso que se ha impuesto en el archivo slapd.conf: access to * by dn="cn=admin,dc=gsr,dc=pt" write by dn="cn=readadmin,dc=gsr,dc=pt" read (1) by self write by users read by anonymous auth (1) Para más datos sobre este usuario, ver el Apéndice A. Ejemplo 4-22. Devuelve todas las entradas del directorio Si el cliente se encuentra en la misma máquina que el servidor: $ /usr/bin/ldapsearch -x -b 'dc=gsr,dc=pt' -D "cn=admin,dc=gsr,dc=pt" - W \ '(objectclass=*)' Si el cliente se encuentra en una máquina distinta al servidor y se quiere hacer uso de SSL : $ /usr/bin/ldapsearch -x -b 'dc=gsr,dc=pt' -D "cn=admin,dc=gsr,dc=pt" - W \ '(objectclass=*)' -H ldaps://gsr.pt/ Si el cliente se encuentra en una máquina distinta al servidor y se quiere hacer uso de TLS : $ /usr/bin/ldapsearch -x -b 'dc=gsr,dc=pt' -D "cn=admin,dc=gsr,dc=pt" - W \ '(objectclass=*)' -H ldap://gsr.pt/ -ZZ Después de ejecutar las órdenes anteriores, la salida debería ser similar a: Enter LDAP Password:[Clave] # extended LDIF # # LDAPv3 # base with scope sub # filter: (objectclass=*) # requesting: ALL # # gsr.pt dn: dc=gsr,dc=pt objectClass: top objectClass: dcObject objectClass: organization o: gsr.pt dc: gsr # admin, gsr.pt dn: cn=admin,dc=gsr,dc=pt objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e2NyeXB0fXkxcFlKZVpQQzQ5Qlk= # sergio, gsr.pt dn: cn=sergio,dc=gsr,dc=pt objectClass: organizationalRole cn: sergio # unidade de contas, gsr.pt dn: ou=unidade de contas,dc=gsr,dc=pt objectClass: organizationalUnit ou: unidade de contas description: Organizacao de provas que contera ao administrador # senhor administrador, unidade de contas, gsr.pt dn: cn=senhor administrador,ou=unidade de contas,dc=gsr,dc=pt objectClass: person userPassword:: Y2hhdmVwcm92YQ== description: Usuario de exemplo como administrador cn: senhor administrador sn: admin # search result search: 3 result: 0 Success # numResponses: 6 # numEntries: 5 Ejemplo 4-23. Devuelve algunas entradas del directorio $ /usr/bin/ldapsearch -x -b 'cn=sergio,dc=gsr,dc=pt' -D "cn=admin,dc=gs r,dc=pt" \ '(objectclass=*)' -H ldaps://gsr.pt/ -w clave # extended LDIF # # LDAPv3 # base with scope sub # filter: (objectclass=*) # requesting: ALL # # sergio, gsr.pt dn: cn=sergio,dc=gsr,dc=pt objectClass: organizationalRole cn: sergio # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 $ $ /usr/bin/ldapsearch -x -b 'ou=unidade de contas,,dc=gsr,dc=pt' \ -D "cn=admin,dc=gsr,dc=pt" '(objectclass=*)' -H l daps://gsr.pt/ -w clave # extended LDIF # # LDAPv3 # base with scope sub # filter: (objectclass=*) # requesting: ALL # # unidade de contas, gsr.pt dn: ou=unidade de contas,dc=gsr,dc=pt objectClass: organizationalUnit ou: unidade de contas description: Organizacao de provas que contera ao administrador # senhor administrador, unidade de contas, gsr.pt dn: cn=senhor administrador,ou=unidade de contas,dc=gsr,dc=pt objectClass: person userPassword:: Y2hhdmVwcm92YQ== description: Usuario de exemplo como administrador cn: senhor administrador sn: admin # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 Como ha podido comprobar, la comunicación con el servidor LDAP se realiza satisfactoriamente, bien sea utilizando cifrado bien sin el. _________________________________________________________ Capítulo 5. Autentificación de usuarios a través de OpenLDAP 5.1. Introducción En este capítulo se verá como configurar una máquina para que sus usuarios se autentifiquen a través de un servidor LDAP. Para ello se han de modificar dos aspectos del comportamiento del sistema: * El mapeado entre los números de identificación de los usuarios y sus nombres (utilizados, por ejemplo, por /bin/ls -l) o la localización del directorio home. La búsqueda de este tipo de información es responsabilidad del servicio de nombres, cuyo archivo de configuración es: /etc/nsswitch.conf. * La autentificación (comprobación de claves), que es responsabilidad del subsistema PAM, cuya configuración se hace a través del directorio /etc/pam.d/ Ambos subsistemas se han de configurar separadamente, pero en este caso, ambos se van a configurar de tal forma que hagan uso de LDAP. En este capítulo sólo se trata la instalación y configuración de los dos aspectos arriba expuestos, de todas formas, hay un tercer punto que, en sistemas en producción, sería interesante abordar: la caché del servicio de nombres. Para ver en qué consiste y como se instala y configura, vea el Apéndice B. Nota Este capítulo se ha basado en la entrada bibliográfica metaconsultancy01, entre otras. _________________________________________________________ 5.2. Instalación del software necesario Antes de poder autentificar a los usuarios a través de un servidor LDAP, es necesario instalar algunas utilidades en el cliente, como pam_ldap y nss_ldap. Esta sección mostrará la forma de instalación de estas utilidades. _________________________________________________________ 5.2.1. Instalación de nss-ldap nss-ldap permite a un servidor LDAP actuar como un servidor de nombres. Esto significa que provee la información de las cuentas de usuario, los IDs de los grupos, la información de la máquina, los alias, los grupos de red y básicamente cualquier cosa que normalmente se obtiene desde los archivos almacenados bajo /etc o desde un servidor NIS. En Debian GNU/Linux el paquete libnss-ldap provee esta funcionalidad, por lo que será instalado en la máquina, como muestra el Ejemplo 5-2 Antes de proceder a su instalación, eche un vistazo a la descripción del paquete: Ejemplo 5-1. Instalación de libnss-ldap $ /usr/bin/apt-cache show libnss-ldap Package: libnss-ldap Priority: extra Section: net Installed-Size: 220 Maintainer: Stephen Frost Architecture: i386 Version: 220-1 (1) Depends: libc6 (>= 2.3.2.ds1-4), libdb4.2, libkrb53 (>= 1.3.2), libldap 2 (>= 2.1.17-1), debconf Recommends: nscd, libpam-ldap Filename: pool/main/libn/libnss-ldap/libnss-ldap_220-1_i386.deb Size: 73688 MD5sum: 1d2667fd13efc134e5baaa1d63f45372 Description: NSS module for using LDAP as a naming service This package provides a Name Service Switch that allows your LDAP serv er act as a name service. This means providing user account information, group id's, host information, aliases, netgroups, and basically anythi ng else that you would normally get from /etc flat files or NIS. . If used with glibc 2.1's nscd (Name Service Cache Daemon) it will help reduce your network traffic and speed up lookups for entries. (1) Versión de libnss-ldap que se va a instalar Ejemplo 5-2. Instalación de libnss-ldap (primera parte) # /usr/bin/apt-get install libnss-ldap Leyendo lista de paquetes... Hecho Creando árbol de dependencias... Hecho Paquetes recomendados nscd libpam-ldap Se instalarán los siguientes paquetes NUEVOS: libnss-ldap 0 actualizados, 1 se instalarán, 0 para eliminar y 27 no actualizados. Se necesita descargar 0B/73,7kB de archivos. Se utilizarán 225kB de espacio de disco adicional después de desempaque tar. Preconfiguring packages ... Nota Si ha instalado previamente este paquete, es posible que no se muestren todas las pantallas listadas seguidamente. Para forzar una configuración completa, teclee la siguiente orden: # /usr/sbin/dpkg-reconfigure --priority=low libnss-ldap Figura 5-1. Dirección del servidor LDAP [openldap-instalacion-libnss-ldap1.png] Dirección del servidor LDAP que se va a utilizar para la autentificación de usuarios. Figura 5-2. Nombre distintivo de la base de búsquedas [openldap-instalacion-libnss-ldap2.png] Nombre distintivo de la base de búsquedas. Figura 5-3. Versión del protocolo LDAP [openldap-instalacion-libnss-ldap3.png] Versión del protocolo LDAP a utilizar, es recomendable hacer uso de la versión 3. Figura 5-4. Método de acceso a la base de datos [openldap-instalacion-libnss-ldap4.png] En este ejemplo no se necesita autentificarse para acceder a la base de datos LDAP, por lo que se responde: NO. Figura 5-5. Permisos del archivo de configuración [openldap-instalacion-libnss-ldap5.png] Es buena idea que sólo el propietario del archivo pueda leer su información, máxime cuando este puede tener claves. Por este motivo se responde que Sí a esta pregunta. Figura 5-6. Información sobre libnss-ldap [openldap-instalacion-libnss-ldap6.png] La configuración del paquete nos muestra información adicional sobre el mismo. Si se quiere ver el ejemplo del archivo /etc/nsswitch.conf que provee libnss-ldap, acceda a: /usr/share/doc/libnss-ldap/examples/nsswitch.ldap. De todas formas, en el Apéndice T se dispone de un ejemplo. Ejemplo 5-3. Instalación de libnss-ldap (segunda parte) Seleccionando el paquete libnss-ldap previamente no seleccionado. (Leyendo la base de datos ... 132069 ficheros y directorios instalados actualmente.) Desempaquetando libnss-ldap (de .../libnss-ldap_220-1_i386.deb) ... Configurando libnss-ldap (220-1) ... localepurge: checking system for new locale ... localepurge: processing locale files ... localepurge: processing man pages ... La configuración de nss-ldap se almacena en el archivo /etc/libnss-ldap.conf, cuyo contenido se encuentra en el Apéndice V. Aviso El archivo /etc/libnss-ldap.conf se ha de poder leer por todos los usuarios del sistema, para asegurarse de que es legible por todo el mundo, puede ejecutar: /bin/chmod 644 /etc/libnss-ldap.conf. _________________________________________________________ 5.2.2. Instalación de pam_ldap pam_ldap permite hacer uso de un servidor LDAP para la autentificación de usuarios (comprobación de claves) a aquellas aplicaciones que utilicen PAM. En Debian GNU/Linux el paquete libpam-ldap provee esta funcionalidad, por lo que será instalado en la máquina, como muestra el Ejemplo 5-5 Antes de proceder con su instalación, eche un vistazo a la descripción del paquete: Ejemplo 5-4. Información sobre el paquete libpam-ldap $ /usr/bin/apt-cache show libpam-ldap Package: libpam-ldap Priority: extra Section: admin Installed-Size: 288 Maintainer: Stephen Frost Architecture: i386 Version: 169-1 (1) Depends: libc6 (>= 2.3.2.ds1-4), libldap2 (>= 2.1.17-1), libpam0g (>= 0 .76), debconf (>= 0.5) Suggests: libnss-ldap Filename: pool/main/libp/libpam-ldap/libpam-ldap_169-1_i386.deb Size: 52158 MD5sum: 5d1d450ac94b5e86a313a8277f5f84a3 Description: Pluggable Authentication Module allowing LDAP interfaces This module let's you use you LDAP server to authenticate users with programs that utilize PAM. If used along with libnss-ldap, you can replace your entire flat file (/etc/*) structure or NIS with LDAP. (1) Versión de libpam-ldap que acompaña a Debian GNU/Linux en su versión "en desarrollo", que va a ser instalada Ejemplo 5-5. Instalación de libpam-ldap (primera parte) # /usr/bin/apt-get install libpam-ldap Leyendo lista de paquetes... Hecho Creando árbol de dependencias... Hecho Paquetes sugeridos: libnss-ldap Se instalarán los siguientes paquetes NUEVOS: libpam-ldap 0 actualizados, 1 se instalarán, 0 para eliminar y 27 no actualizados. Se necesita descargar 0B/52,2kB de archivos. Se utilizarán 295kB de espacio de disco adicional después de desempaque tar. Preconfiguring packages ... Nota Si ha instalado previamente este paquete, es posible que no se muestren todas las pantallas listadas seguidamente. Para forzar una configuración completa, teclee la siguiente orden: # /usr/sbin/dpkg-reconfigure --priority=low libpam-ldap Figura 5-7. URL del servidor LDAP [openldap-configuracion-libpam-ldap1.png] Dirección del servidor LDAP que se va a utilizar para la autentificación de usuarios. Figura 5-8. Nombre distintivo de la base de búsquedas [openldap-configuracion-libpam-ldap2.png] Nombre distintivo de la base de búsquedas. Figura 5-9. Versión del protocolo LDAP [openldap-configuracion-libpam-ldap3.png] Versión del protocolo LDAP a utilizar, es recomendable hacer uso de la versión 3. Figura 5-10. Comportamiento a la hora del cambio de claves [openldap-configuracion-libpam-ldap4.png] Contestamos afirmativamente a esta pregunta, de esta forma, aquellas aplicaciones que cambien claves por medio de PAM, se comportarán como si lo hiciesen de forma local. Figura 5-11. ¿Necesita autentificación la conexión con la base de datos? [openldap-configuracion-libpam-ldap5.png] En este ejemplo no se necesita autentificarse para acceder a la base de datos LDAP, por lo que se responde que NO. Figura 5-12. Administrador de LDAP [openldap-configuracion-libpam-ldap6.png] Cuenta del administrador de LDAP, en este caso "admin". Figura 5-13. Clave del administrador de LDAP [openldap-configuracion-libpam-ldap7.png] Se introduce la clave del administrador de LDAP. Figura 5-14. Elección el método de cifrado para las claves [openldap-configuracion-libpam-ldap8.png] El método de cifrado elegido para almacenar las claves ha sido "exop", de esta forma pam-ldap utilizará el algoritmo de hash especificado en el archivo /etc/ldap/slapd.conf, en lugar de realizar la operación hash localmente y escribir el resultado en la base de datos directamente. Ejemplo 5-6. Instalación de libpam-ldap (segunda parte) Seleccionando el paquete libpam-ldap previamente no seleccionado. (Leyendo la base de datos ... 132024 ficheros y directorios instalados actualmente.) Desempaquetando libpam-ldap (de .../libpam-ldap_169-1_i386.deb) ... Configurando libpam-ldap (169-1) ... localepurge: checking system for new locale ... localepurge: processing locale files ... localepurge: processing man pages ... La configuración del módulo pam_ldap.so se almacena en el archivo /etc/pam_ldap.conf, cuyo contenido se encuentra en el Apéndice U. Aviso El archivo /etc/pam_ldap.conf se ha de poder leer por todos los usuarios del sistema, para asegurarse de que es legible por todo el mundo, puede ejecutar: /bin/chmod 644 /etc/pam_ldap.conf. En estos momentos el sistema ya está listo para la configuración de los distintos servicios que utilizan PAM, de forma que estos utilicen LDAP para la comprobación de la clave. Cada servicio que hace uso de PAM para la autentificación, posee su propio archivo bajo el directorio /etc/pam.d/. Para que dicho servicio utilice LDAP en la comprobación de claves, se ha de modificar su archivo de configuración. Esto se verá en la Sección 5.3.3. _________________________________________________________ 5.3. Configuración de los archivos necesarios Aviso Tenga en cuenta que va a modificar archivos de configuración utilizados para el ingreso al sistema. Sería recomendable que tuviese en todo momento una consola de root abierta, por si deja de funcionar la autentificación. _________________________________________________________ 5.3.1. /etc/libnss-ldap.conf y /etc/pam_ldap.conf Como en ambos archivos se van a modificar las mismas variables, se ha utilizado una única sección para ambos. Las modificaciones que se van a realizar a continuación son, principalmente, necesarias para activar el cifrado en las conexiones con el servidor LDAP. Esto es necesario si no se quiere que las claves de los usuarios, por ejemplo, viajen por la red en texto plano. Nota En los apéndices Apéndice V y Apéndice U verá un ejemplo completo de estos archivos de configuración. _________________________________________________________ 5.3.1.1. Usuario con el que conectar al directorio LDAP Debido a que durante el proceso de configuración de OpenLDAP se va a prohibir a los usuarios anónimos acceder a la información almacenada en el directorio, se hace necesario especificar un usuario válido con el cual autentificarse para realizar las operaciones llevadas a cabo por libnss-ldap y libpam-ldap, entre otras. Este usuario y su clave estarán especificados por las variables binddn y bindpw, respectivamente. binddn cn=readadmin,dc=gsr,dc=pt (1) bindpw ********** (2) (1) En el Apéndice A tiene un ejemplo sobre como crear y configurar un usuario que sólo tenga permisos de lectura en el directorio LDAP. (2) Clave del usuario en texto plano. Asegúrese de que está descomentada la variable "rootbinddn" y su valor es el usuario administrador del directorio LDAP, en este caso: "cn=admin,dc=gsr,dc=pt". rootbinddn cn=admin,dc=gsr,dc=pt Una vez hecho esto, tendrá que almacenar la clave del administrador en el archivo /etc/ldap.secret, para ello teclee: Ejemplo 5-7. Creación del directorio /etc/ldap.secret # /bin/echo "clave-del-administrdor" > /etc/ldap.secret # /bin/chmod 600 /etc/ldap.secret Nota La clave se almacena en texto plano, por lo que el archivo /etc/ldap.secret ha de pertenecer al usuario root y sus permisos han de ser 600. _________________________________________________________ 5.3.1.2. Protocolo de cifrado empleado en las comunicaciones La primera opción que se activará será el soporte para TLS, para ello ha de descomentar la línea siguiente en ambos archivos de configuración: ssl start_tls Nota Si desea que las conexiones utilicen SSL, tendrá que sustituir la línea anterior por la siguiente: ssl on En esta documentación se ha preferido utilizar TLS en las comunicaciones, por lo que se ha empleado la opción "ssl start_tls". _________________________________________________________ 5.3.1.3. Opciones para el cifrado (certificados) Para las conexiones cifradas se requiere un certificado en el servidor y este ha de ser válido. Para ello ha de descomentar la siguiente línea: tls_checkpeer yes Para poder verificar la validez del certificado del servidor, se ha de proporcionar la CA que lo generó, esto se indica con la siguiente línea: tls_cacertfile /etc/ldap/ssl/cacert.pem _________________________________________________________ 5.3.1.4. Algoritmo de cifrado Algoritmos de cifrado que se desean utilizar: tls_ciphers TLSv1 _________________________________________________________ 5.3.1.5. Certificados y llaves de los clientes Como en la configuración de OpenLDAP se ha requerido la autentificación del cliente antes de conectarse al servidor (vea el Ejemplo 4-9), se hace necesario descomentar las siguientes líneas: tls_cert tls_key _________________________________________________________ 5.3.2. /etc/nsswitch.conf nsswitch.conf es el fichero de configuración de las Bases de Datos del Sistema y del sistema de Conmutación de los Servicios de Nombres (Name Service Switch). En otras palabras, es un archivo que indica el orden y el procedimiento a seguir para la búsqueda de la información requerida, por ejemplo, para hacer búsquedas de hosts o usuarios. La forma de configurar este archivo es muy simple: primero se especifica la base de datos sujeta a la búsqueda (primera columna) seguida del procedimiento que se va a emplear para realizar una búsqueda sobre la misma (columnas siguientes). De esta forma, basta con configurar el procedimiento de búsqueda para que haga uso de LDAP en algún momento. El Ejemplo 5-8 muestra como hacerlo: Ejemplo 5-8. Modificaciones en el de configuración /etc/nsswitch.conf passwd: (1) files ldap (2) group: (3) files ldap (4) shadow: (5) files ldap (6) hosts: (7) files ldap dns (8) (1) (3) (5) (7) Bases de datos de búsqueda (2) (4) (6) Procedimiento de búsqueda: primero se mira en los archivos locales y luego en el directorio LDAP. (8) Procedimiento de búsqueda: primero se mira en los archivos locales, luego en el directorio LDAP y finalmente se realiza una consulta al servidor DNS. Nota En el Apéndice T se encuentra disponible un ejemplo completo de configuración de nsswitch.conf. Sugerencia Fíjese que no se ha eliminado el uso de los ficheros locales, "files", ya que algunos usuarios y grupos de usuarios (como por ejemplo root) permanecerán de forma local. Si su sistema no utiliza la entrada "files", y el servidor LDAP se cae, nadie, ni siquiera root, podrá entrar al sistema. nss-ldap espera que las cuentas sean objetos con los siguientes atributos: uid, uidNumber, gidNumber, homeDirectory y loginShell. Estos atributos están permitidos por la clase objeto (objectClass) posixAccount. Una vez realizada la configuración, se puede comprobar que todo funciona bien con la orden getent seguido de la base de datos de búsqueda deseada (por ejemplo: /usr/bin/getent hosts). Como resultado se mostrará la base de datos consultada por pantalla. _________________________________________________________ 5.3.3. Configuración de PAM PAM permite configurar el método de autentificación que van a utilizar las aplicaciones que hagan uso de él. Gracias a esto, se pueden añadir fácilmente distintas opciones de autentificación, como el uso de una base de datos LDAP. En las siguientes secciones se mostrarán los archivos que se han de modificar para lograr la autentificación a través de LDAP. Importante Hace relativamente poco tiempo que la versión en desarrollo de Debian (Sid) ha cambiado la forma de configuración de PAM. Actualmente posee secciones comunes a todos los archivos, estas secciones comunes son aquellos archivos localizados en el directorio /etc/pam.d/ que comiencen por "common-". Se ha de tener en cuenta la forma en la que se ha ido actualizando Debian Sid en la última temporada, para determinar si su sistema está utilizando o no dichos archivos comunes para la configuración de PAM. Un buen punto de partida, sería ojear los archivos almacenados bajo /etc/pam.d/ y comprobar las diferencias entre los archivos con extensión .dpkg-dist y los que no la tienen. pam-ldap asume que las cuentas del sistema son objetos con los siguientes atributos: uid y userPassword. Los atributos están permitidos por la clase objeto (objectClass) posixAccount. _________________________________________________________ 5.3.3.1. /etc/pam.d/common-account Este archivo ha de tener únicamente estas entradas: Ejemplo 5-9. Opciones de configuración para /etc/pam.d/common-account account required pam_unix.so account sufficient pam_ldap.so Nota En el Apéndice W tiene un ejemplo completo de este archivo de configuración. _________________________________________________________ 5.3.3.2. /etc/pam.d/common-auth Este archivo ha de tener únicamente estas entradas: Ejemplo 5-10. Opciones de configuración para /etc/pam.d/common-auth auth sufficient pam_unix.so auth sufficient pam_ldap.so try_first_pass auth required pam_env.so auth required pam_securetty.so auth required pam_unix_auth.so auth required pam_warn.so auth required pam_deny.so Nota En el Apéndice X tiene un ejemplo completo de este archivo de configuración. _________________________________________________________ 5.3.3.3. /etc/pam.d/common-session Este archivo ha de tener únicamente estas entradas: Ejemplo 5-11. Opciones de configuración para /etc/pam.d/common-session session required pam_limits.so session required pam_unix.so session optional pam_ldap.so Si desea que el sistema sea capaz de crear directorios home "al vuelo" (piense en el siguiente caso: acaba de añadir un usuario en la base de datos LDAP, pero no ha creado un directorio home para este usuario en el sistema), puede utilizar el módulo pam_mkhomedir para este propósito. Para ello añada la siguiente línea al principio del archivo common-session: Ejemplo 5-12. Opción para crear directorios home al vuelo session required pam_mkhomedir.so skel=/etc/skel/ umask=0022 Importante El módulo pam_mkhomedir sólo crea directorios de un nivel. Es importante tener esto en cuenta para planificar la estructura del home de los usuarios. Nota En el Apéndice Z tiene un ejemplo completo de este archivo de configuración. _________________________________________________________ 5.3.3.4. /etc/pam.d/common-passwd Este archivo ha de tener únicamente estas entradas: Ejemplo 5-13. Opciones de configuración para /etc/pam.d/common-password password required pam_cracklib.so (1) retry=3 minlen=8 difok=4 password sufficient pam_unix.so use_authtok md5 shadow password sufficient pam_ldap.so use_authtok password required pam_warn.so password required pam_deny.so (1) Se supone que tiene instalado en su sistema la librería libpam-cracklib, si no es así, instálela o comente esta línea. Nota En el Apéndice Y tiene un ejemplo completo de este archivo de configuración. _________________________________________________________ 5.3.3.5. Comprobando que todo funciona Ahora que ya está el sistema preparado para hacer uso de LDAP en la autentificación de los usuarios, sería recomendable hacer algunas pruebas con la nueva configuración para ver si todo funciona correctamente. La orden pamtest puede ayudar a realizar estas pruebas. pamtest acepta dos parámetros: el primero es el nombre del servicio al cual se va a conectar para realizar la autentificación, el segundo es el nombre del usuario que se va a autentificar sobre dicho servicio. Veamos unos ejemplos: Nota La orden pamtest se encuentra en el paquete libpam-dotfile, por lo que si no está disponible en su sistema, ha de ejecutar: # /usr/bin/apt-get install libpam-dotfile Ejemplo 5-14. Comprobando la configuración del sistema con pamtest $ /usr/bin/pamtest passwd sergio Trying to authenticate for service . Password:[Clave del usuario] Authentication successful. $ /usr/bin/pamtest ssh sergio Trying to authenticate for service . Password:[Clave fallida del usuario] Failed to authenticate: Authentication service cannot retrieve authenti cation info. $ /usr/bin/pamtest ssh sergio Trying to authenticate for service . Password:[Clave del usuario] Authentication successful. Una vez se ha llegado a este punto, el sistema ya está preparado para autentificar a los usuarios a través de LDAP. En el apartado dedicado a Samba (Parte II en Integración de redes con OpenLDAP, Samba, CUPS y PyKota) veremos, entre otras cosas, como añadir usuarios a la base de datos LDAP. II. Samba [samba-logo.png] Tabla de contenidos 6. Conceptos teóricos 6.1. Introducción 6.2. ¿Qué es Samba? 6.3. ¿Qué puede hacer Samba por mí? 6.3.1. Compartiendo un disco 6.3.2. Compartiendo una impresora 6.3.3. Viendo las cosas desde Unix 6.4. Familiarizándose con una red SMB 6.4.1. Comprendiendo NetBIOS 6.4.2. Obteniendo un nombre 6.4.3. Tipos de nodos 6.4.4. ¿Qué hay en un nombre? 6.4.5. Scope ID 6.4.6. Datagramas y sesiones 6.5. Grupos de trabajo y dominios Windows 6.5.1. Grupos de trabajo Windows 6.5.2. Navegando 6.5.3. Elecciones para la navegación 6.5.4. Autentificación de Windows 95/98/Me 6.5.5. Dominios de Windows NT 6.6. Novedades de Samba 2.2 6.6.1. Soporte PDC para clientes Windows 2000/XP 6.6.2. Soporte Dfs de Microsoft 6.6.3. Soporte de impresión en Windows NT/2000/XP 6.6.4. ACLs 6.6.5. Soporte de las herramientas de administración de clientes Windows 6.6.6. Integración con Winbind 6.6.7. Extensiones CIFS en Unix 6.6.8. Y más... 6.7. Novedades de Samba 3.0 6.8. ¿Qué puede hacer Samba? 6.9. Visión general de la distribución Samba 6.10. Información adicional sobre el proyecto 6.10.1. Página principal 6.10.2. Cómo obtener Samba 6.10.3. Documentación 6.10.4. Información de soporte 6.10.5. Reporte de bugs 6.10.6. Cómo contactar 7. Instalación 7.1. Consideraciones previas 7.2. Pasos para la instalación 7.2.1. Instalación de un servidor 7.2.2. Instalación de un cliente 8. Primeros ajustes en la configuración de OpenLDAP 9. Configuración de Samba 9.1. Introducción 9.2. Estructura del archivo smb.conf 9.2.1. Sintaxis 9.2.2. Comprobando el archivo smb.conf 9.3. Ajustando el archivo de configuración de Samba 9.3.1. Introducción 9.3.2. [global] - sección global 9.3.3. [homes] - directorios personales 9.3.4. [netlogon] 9.3.5. [profiles] - perfiles móviles 9.3.6. [printers] - impresoras 9.3.7. [print$] - controladores de impresión 9.3.8. [tmp] - Directorio temporal 9.3.9. [cdrom] - CDROM 10. Ajustes finales en el sistema 10.1. Introducción 10.2. Estableciendo la clave del administrador de LDAP 10.3. Nueva regla de control de acceso en /etc/ldap/slapd.conf 10.4. Especificación de nuevos índices en /etc/ldap/slapd.conf 10.5. Creando la estructura de directorios en el home 11. Comprobando que todo funciona 11.1. Introducción 11.2. Verificación del archivo de configuración y reinicio de los demonios 11.3. Adición de un usuario al sistema 11.4. Acceso con la nueva cuenta en un sistema Unix 11.5. Acceso con la nueva cuenta a Samba 11.5.1. Uso de smbclient 11.5.2. Uso de konqueror 12. Añadiendo clientes al dominio 12.1. Introducción 12.2. Windows 95/98/ME 12.3. Windows NT 12.3.1. Creación de cuentas para las máquinas 12.3.2. Uniendo un cliente Windows NT a un dominio 12.4. Windows 2000 12.4.1. Añadiendo el usuario "root" a Samba 12.4.2. Uniendo un cliente Windows 2000 a un dominio 12.5. Windows XP _________________________________________________________ Capítulo 6. Conceptos teóricos 6.1. Introducción Nota Este capítulo se ha basado en las introducciones de las entradas bibliográficas EcksteinCollier-BrownKelly01, TsEcksteinCollier-Brown01 y Sharpe01. También se ha de notar que las imágenes y los ejemplos utilizados en este apartado han sido obtenidos o basados en dichos documentos. Samba es una herramienta de red extremadamente útil para cualquier persona que posea en su red sistemas Unix y Windows. Samba se ejecuta en un sistema Unix, permitiendo a los sistemas Windows compartir archivos e impresoras en la máquina Unix, a la vez que los usuarios de Unix tienen acceso a los recursos compartidos en los sistemas Windows. Aunque parece natural hacer uso de servidores Windows para servir archivos e impresoras en una red donde haya clientes Windows, hay buenas razones para elegir un servidor Samba para estos servicios. Samba es un software confiable que corre en un sistema operativo confiable como Unix, dando como resultado la obtención de menos problemas y bajo coste de mantenimiento. A parte de esto, Samba ofrece mejor rendimiento ante cargas de trabajo extremadamente duras, sobrepasando a un servidor Windows 2000 en un factor de 2 a 1 en un PC con la misma configuración de hardware, de acuerdo con unos benchmarks publicados por terceros. Cuando un PC ya no pueda acometer las peticiones de los clientes, debido a la alta carga, el servidor Samba se puede trasladar fácilmente a un mainframe Unix propietario, el cual puede sobrepasar en mucho a un PC corriendo Windows. Si todo esto no fuese suficiente, Samba posee una ventaja muy buena en relación al coste: es libre. No sólo el software está a su disposición libremente, sino que no necesita ningún tipo de licencia para los clientes, ejecutándose en sistemas operativos de gran calidad y libres, como GNU/Linux y FreeBSD. _________________________________________________________ 6.2. ¿Qué es Samba? Samba es una suite de aplicaciones Unix que habla el protocolo SMB (Server Message Block). Los sistemas operativos Microsoft Windows y OS/2 utilizan SMB para compartir por red archivos e impresoras y para realizar tareas asociadas. Gracias al soporte de este protocolo, Samba permite a las máquinas Unix entrar en el juego, comunicándose con el mismo protocolo de red que Microsoft Windows y aparecer como otro sistema Windows en la red (desde la perspectiva de un cliente Windows). El servidor Samba ofrece los siguientes servicios: * Compartir uno o varios sistemas de archivos * Compartir uno o varios sistemas de archivos distribuidos * Compartir impresoras instaladas en el servidor entre los clientes Windows de la red * Ayudar a los clientes permitiéndoles navegar por la red * Autentificar a los clientes que ingresan en un dominio Windows * Proveer o ayudar con un servidor de resolución de nombres Windows (WINS) [15]. La suite Samba también incluye herramientas para los clientes, que permiten a los usuarios de un sistema Unix acceder a los directorios e impresoras que los sistemas Windows y servidores Samba comparten en la red. Samba es la idea de Andrew Tridgell, quien actualmente lidera el equipo de desarrollo de Samba. El proyecto nació en 1991 mientras Andrew trabajaba con la suite de Digital Equipment Corporation (DEC) llamada Pathworks, creada para conectar ordenadores VAX DEC con los de otras compañías. Sin conocer la transcendencia de lo que estaba haciendo, Andrew creó un programa servidor de archivos para un extraño protocolo que formaba parte de la suite Pathworks. Este protocolo pasó a llamarse más tarde SMB. Unos años más tarde, lo liberó como su servidor SMB particular y lo comenzó a distribuir por Internet bajo el nombre de "SMB Server". Sin embargo, Andrew no pudo mantener ese nombre -este pertenecía a un producto de otra compañía-, así que intentó lo siguiente para buscarle un nuevo nombre desde Unix: $ grep -i '^s.*m.*b' /usr/dict/words Obteniendo como respuesta: salmonberry samba sawtimber scramble De ésta manera nació el nombre de Samba. Hoy en día, la suite Samba gira alrededor de un par de demonios Unix que permiten la compartición de recursos entre los clientes SMB de una red. Estos demonios son: smbd Demonio que permite la compartición de archivos e impresoras sobre una red SMB y proporciona autentificación y autorización de acceso para clientes SMB. nmbd Demonio que soporta el servicio de nombres NetBIOS y WINS, que es una implementación de Microsoft del servicio de nombres NetBIOS (NBNS). Este demonio también ayuda añadiendo la posibilidad de navegar por la red. Samba actualmente está mantenido y es ampliado por un grupo de voluntarios bajo la supervisión activa de Andrew Tridgell. Al igual que el núcleo Linux, los autores de Samba lo distribuyen como software open source, bajo los términos de la licencia GPL (GNU General Public License). Desde su concepción, el desarrollo de Samba ha sido patrocinado en parte por la Australian National University, donde Andrew Tridgell hizo su doctorado. A partir de entonces, muchas otras organizaciones han patrocinado a los desarrolladores de Samba, incluyendo LinuxCare, VA Linux Systems, Hewlett-Packard e IBM. Es algo verdaderamente testimonial el que entidades tanto comerciales como no comerciales estén dispuestas a gastar dinero para dar soporte a un esfuerzo Open Source. Microsoft también ha contribuido ofreciendo la definición de su protocolo SBM al grupo IETF (Internet Engineering Task Force) en 1996, cuyo nombre es Common Internet File System (CIFS). _________________________________________________________ 6.3. ¿Qué puede hacer Samba por mí? Como se explicó anteriormente, Samba puede ayudar la coexistencia de máquinas Windows y Unix en la misma red. Sin embargo, existen algunas razones por las cuales podría desear instalar un servidor Samba en su red: * No quiere pagar -o no puede disponer- de un servidor Windows completo, pero todavía necesita la funcionalidad que provee * Qué las licencias de acceso a los clientes[16] que Microsoft solicita para que cada cliente Windows pueda acceder al servidor Windows sean incosteables * Tal vez quiera proporcionar un área común para datos o directorios de usuarios en orden a realizar una transición desde un servidor Windows hacia uno Unix, o viceversa * Desea compartir impresoras entre clientes Windows y Unix * Tenga que dar soporte a un grupo de usuarios cuyos ordenadores posean una mezcla de sistemas operativos, Windows y Unix * Quiera integrar la autentificación de Unix y Windows, manteniendo una única base de datos para las cuentas de los usuarios que funcione en ambos sistemas * Quiera establecer una red entre sistemas Unix, Windows, Macintosh (OS X) y otros, utilizando un único protocolo A continuación se verá a Samba en acción. Se asume la siguiente configuración de red: un servidor Samba sobre una máquina Unix, cuyo hostname es toltec, y un par de clientes Windows, denominados maya y aztec, todos los equipos están conectados gracias a una red de área local (LAN). Se asume también que toltec tiene una impresora de inyección de tinta conectada, lp, y un disco compartido spirit -ambos recursos están disponibles para las otras dos máquinas-. Un gráfico de esta red se muestra en la Figura 6-1. Figura 6-1. Configuración de red simple con un servidor Samba[17] [samba-configuracion-red-simple-con-servidor-samba.png] En esta red, cada ordenador comparte el mismo grupo de trabajo (workgroup). Un grupo de trabajo no es más que una etiqueta que identifica a un determinado grupo de ordenadores y sus recursos en una red SBM. Pueden existir varios grupos de trabajo sobre la red al mismo tiempo, pero para el ejemplo sólo se tiene uno: el grupo de trabajo METRAN. _________________________________________________________ 6.3.1. Compartiendo un disco Si todo está bien configurado, se debería ver el servidor Samba, toltec, a través del entorno de red de la máquina Windows denominada maya. De hecho, la Figura 6-2 muestra el entorno de red de la maya, incluyendo a toltec y a cada una de las máquinas que residen en el grupo de trabajo METRAN. Dese cuenta del icono "Entire Network" al principio de la lista. Como se mencionó anteriormente, pueden existir más grupos de trabajo sobre una red SBM al mismo tiempo. Si un usuario hace click sobre ese icono, verá la lista de todos los grupos de trabajo que actualmente existen en la red. Figura 6-2. Entorno de red [samba-entorno-de-red.png] Se puede ver con más detalle los recursos compartidos por toltec haciendo doble click sobre su icono. Esta acción provoca un contacto con toltec, solicitándole la lista de sus recursos compartidos -la impresora y el disco- que proporciona. En este caso, existe una impresora denominada lp, un directorio personal denominado jay y el disco compartido llamado spirit en el servidor, como se muestra en la Figura 6-3. Tenga en cuenta que Windows muestra los hostnames con letras mayúsculas/minúsculas (Toltec). La distinción entre mayúsculas y minúsculas es irrelevantes en los nombres de las máquinas (hostname), por lo que puede ver toltec, Toltec y TOLTEC como resultado de algunas órdenes o en distintas pantallas, pero todos se refieren al mismo sistema. Gracias a Samba, Windows 98 ve al servidor Unix como a un servidor SBM válido, y puede acceder al directorio spirit como si fuese un directorio más del sistema. Figura 6-3. Recursos compartidos por toltec vistos desde maya [samba-recursos-compartidos-en-toltec-vistos-desde-maya.png] Una característica interesante de Windows es la capacidad de mapear una letra de unidad (como E:, F: o Z:) hacia un directorio compartido usando la opción "Conectar a Unidad de Red" (Map Network Drive) desde el explorador de Windows [18]. Una vez hecho esto, las aplicaciones podrán acceder a la carpeta compartida utilizando la letra de la unidad de disco asignada. Se pueden almacenar datos en ella, instalar y ejecutar programas desde ella e incluso protegerla con una contraseña para evitar accesos no deseados. La Figura 6-4 muestra un ejemplo de mapeado de un directorio compartido hacia una letra de una unidad. Figura 6-4. Mapeo de una unidad de red en una letra de unidad Windows [samba-mapeo-de-una-unidad-de-red-en-una-letra-de-unidad-windo ws.png] Eche un vistazo a la línea que aparece al lado de la ruta (Path) en la imagen Figura 6-4. Una forma equivalente de representar un directorio en una máquina de la red es utilizando dos barras invertidas (\\), seguidas del nombre de la máquina de red, otra barra invertida (\), y el directorio de red de la máquina, como se muestra en el Ejemplo 6-1: Ejemplo 6-1. Representación de un directorio en una máquina de red \\maquina-de-red\directorio Esto se conoce como notación UNC (Universal Naming Convention) en el mundo Windows. Por ejemplo, la caja de diálogo de la Figura 6-4 representa el directorio de red del servidor toltec como en el Ejemplo 6-2: Ejemplo 6-2. Notación UNC (Universal Naming Convention) \\toltec\spirit Si esto le resulta familiar, probablemente esté pensando en uniform resource locator (URL), que es la notación que utilizan los navegadores web como Mozilla o Konqueror para acceder a las máquinas a través de Internet. Asegúrese de no confundir ambas notaciones, las URLs utilizan barras inclinadas hacia la derecha en vez de barras invertidas, y están precedidas por el nombre del protocolo de transferencia de datos (por ejemplo: ftp, http) y dos puntos (:). En realidad, URL y UNC son dos cosas completamente distintas, aunque algunas veces se pueda especificar un recurso SBM haciendo uso de la notación URL en vez de la notación UNC. Para especificar la siguiente dirección, \\toltec\spirit, en notación URL, se ha de escribir: smb://toltec/spirit. Una vez que la unidad de red está configurada, Windows y sus programas la verán como una unidad de disco más. Si tiene alguna aplicación multiusuario, puede instalarla sobre una unidad de red[19]. La Figura 6-5 muestra la unidad de red resultante, como si fuese una unidad más en el cliente Windows 98. Advierta la tubería de enlace en el icono de la unidad "J:"; esto indica que es una unidad de red, en lugar de una unidad física. Figura 6-5. Un directorio de red mapeado como la unidad J en el cliente [samba-directorio-de-red-mapeado-como-la-unidad-J-en-el-client e.png] Dependiendo del sistema operativo Widows que utilice (Windows Me, Windows 2000 o Windows XP), el entorno de red funcionará de una forma distinta. Es necesario pulsar sobre algunos iconos más, pero se puede ver el servidor toltec como se muestra en la Figura 6-6. Esta captura está realizada desde un sistema Windows 2000. Haciendo uso de la opción "Conectar a unidad de red" (Map Network Drive), obtendríamos el mismo resultado en otras versiones de Windows. Figura 6-6. Recursos compartidos en toltec (vistos desde aztec) [samba-recursos-compartidos-disponibles-en-toltec-vistos-desde -aztec.png] _________________________________________________________ 6.3.2. Compartiendo una impresora Probablemente se haya fijado en la impresora lp que aparece en la lista de recursos de toltec en la Figura 6-3. Esto indica que el servidor Unix posee una impresora que puede ser compartida con los clientes SBM del grupo de trabajo. Los datos enviados a la impresora desde cualquier cliente será colocado en la cola de impresión del servidor Unix, para seguidamente ser impresos en el orden de llegada. Configurar una impresora para que sea accesible a través de Samba a los clientes Windows es, si cabe más sencillo que configurar una unidad de disco. Haciendo doble click sobre la impresora e identificando el fabricante y modelo de la misma, puede instalar el controlador para esa impresora en el cliente Windows. Desde ese momento, Windows podrá formatear cualquier información enviada a la impresora de red y acceder a ella como si fuese una impresora local. En Windows 98, al hacer doble click sobre el icono de impresoras que aparece en el Panel de Control, abre la ventana de impresoras que se muestra en la Figura 6-7. Una vez más, note la tubería colocada bajo la impresora, lo que indica que se trata de una impresora en red. Figura 6-7. Impresora en red disponible en toltec [samba-impresora-en-red-disponible-en-toltec.png] _________________________________________________________ 6.3.3. Viendo las cosas desde Unix Como se mencionó anteriormente, Samba no es más que un conjunto de demonios. Puede verlos haciendo uso de la orden ps; puede ver cualquier mensaje que generen a través de archivos de depuración personalizados o a través del syslog (dependiendo de como se haya configurado Samba); y puede configurarlos desde un único archivo de configuración: smb.conf. A parte de esto, si quiere saber que están haciendo los demonios en un determinado momento, Samba posee un programa denominado smbstatus que muestra la información requerida. El Ejemplo 6-3 muestra su salida: Ejemplo 6-3. Muestra de la salida de la orden smbstatus # /usr/bin/smbstatus Processing section "[homes]" Processing section "[printers]" Processing section "[spirit]" Samba version 2.2.6 Service uid gid pid machine ----------------------------------------- spirit jay jay 7735 maya (172.16.1.6) Sun Aug 12 12:1 7:14 2002 spirit jay jay 7779 aztec (172.16.1.2) Sun Aug 12 12:4 9:11 2002 jay jay jay 7735 maya (172.16.1.6) Sun Aug 12 12:5 6:19 2002 Locked files: Pid DenyMode R/W Oplock Name -------------------------------------------------- 7735 DENY_WRITE RDONLY NONE /u/RegClean.exe Sun Aug 12 13 :01:22 2002 Share mode memory usage (bytes): 1048368(99%) free + 136(0%) used + 72(0%) overhead = 1048576(100%) t otal El informe de estado de Samba proporciona tres grupos de datos, cada uno de ellos dividido en secciones separadas. La primera sección identifica los sistemas que han conectado con el servidor Samba, identificando a cada cliente por su nombre de máquina (maza y aztec) y su dirección IP. La segunda sección informa del nombre y estado de los ficheros compartidos por el servidor que están actualmente en uso, incluyendo el estado de lectura/escritura o cualquier bloqueo que estos posean. Finalmente, Samba informa sobre la memoria en uso por los recursos que administra, incluyendo la cantidad de memoria que se está utilizando por los recursos compartidos más el gasto fijo de memoria. (Tenga en cuenta que esta no es la misma cantidad de memoria que el total de memoria utilizada por los procesos smbd y nmbd.) _________________________________________________________ 6.4. Familiarizándose con una red SMB Ahora que ya posee una breve visión sobre Samba, tómese algún tiempo para familiarizarse con el entorno que ha adoptado Samba: una red SBM. Trabajar con redes SBM es significativamente diferente a trabajar con protocolos comunes de TCP/IP, como FTP o SSH, debido a que hay bastantes conceptos nuevos que aprender y mucha información a cubrir. Primero, se discutirán los conceptos básicos existentes tras una red SBM, seguido de algunas implementaciones de Microsoft sobre SBM, para finalmente mostrar donde puede encajar un servidor Samba y dónde no. _________________________________________________________ 6.4.1. Comprendiendo NetBIOS Para comenzar, echemos la vista atrás. En 1984, IBM diseñó una API (Application Programming Interface) simple para conectar en red sus ordenadores, llamada Network Basic Input/Output System (NetBIOS). La API NetBIOS proporcionaba un diseño rudimentario para que una aplicación se conectase y compartiese datos con otros ordenadores. Es útil pensar en la API NetBIOS como una extensión de red para las llamadas de la API BIOS estándar. La BIOS contiene código de bajo nivel para realizar operaciones en el sistema de archivos de un ordenador local. Originalmente, NetBIOS tenía que intercambiar instrucciones con los ordenadores a través de redes IBM PC o Token Ring. Esto exigió un protocolo de transporte de bajo nivel para transportar las peticiones de un ordenador al siguiente. A finales de 1985, IBM liberó dicho protocolo, combinándolo con la API NetBIOS para convertirse en NetBIOS Extended User Interface (NetBEUI). NetBEUI fue diseñado para pequeñas redes de área local (LANs), permitiendo a cada ordenador usar un nombre (de hasta 15 caracteres) que no estuviese siendo utilizado en la red. Se entiende por una "LAN pequeña", una red de menos de 255 nodos -¡Esto se consideraba un número generoso en 1985!-. El protocolo NetBEUI se volvió muy popular en las aplicaciones de red, incluyendo aquellas que corrían bajo Windows for Workgroups. Más tarde, aparecieron implementaciones de NetBIOS sobre los protocolos IPX de Novell, los cuales competían con NetBEUI. Sin embargo, los protocolos de red escogidos por la floreciente comunidad de Internet fueron TCP/IP y UDP/IP, así como las implementaciones de las APIs NetBIOS sobre dichos protocolos, que pronto se convirtieron en una necesidad. Recuerde que TCP/IP hace uso de números para representar las direcciones de los ordenadores (192.168.220.100, por ejemplo), mientras que NetBIOS usa sólo nombres. Este fue el mayor problema encontrado a la hora de juntar los dos protocolos. En 1987, el grupo IETF (Internet Engineering Task Force) publicó una serie de documentos de estandarización, titulados RFC 1001 y 1002, que perfilaban cómo NetBIOS podría trabajar sobre una red TCP/UDP. Este conjunto de documentos todavía lidera las implementaciones que existen hoy en día, incluyendo aquellas proporcionadas por Microsoft para sus sistemas operativos Windows, así como a la suite Samba. Desde entonces, el estándar que estos documentos lideran se ha convertido en NetBIOS sobre TCP/IP, o NBT[20] para abreviar. El estándar NBT (RFC 1001/1002) actualmente establece un trio de servicios sobre una red: * Un Servicio de Nombres * Dos Servicios de Comunicación: + Datagramas + Sesiones El servicio de nombres resuelve el problema del paso de un nombre a una dirección anteriormente comentado; permite a cada ordenador proclamar un nombre específico en la red que puede se puede convertir en una dirección IP legible, como hacen hoy en día los DNS en Internet. Los servicios de datagramas y sesiones son protocolos secundarios de comunicación, usados para transmitir datos desde y hacia máquinas NetBIOS a través de la red. Como se ha visto hasta este momento, SMB puede correr sobre múltiples protocolos. El siguiente diagrama muestra este hecho[21]: Figura 6-8. Protocolos sobre los que corre SMB[22] [samba-protocolos-sobre-los-que-se-ejecuta-sbm.png] _________________________________________________________ 6.4.2. Obteniendo un nombre En el mundo NetBIOS, cuando cada ordenador se activa, quiere reclamar un nombre para sí; esto se denomina registro de nombre. Sin embargo, dos máquinas en el mismo grupo de trabajo no podrían solicitar el mismo nombre; ya que esto confundiría a una máquina que quisiese comunicarse con cualquiera de esas dos. Existen dos métodos diferentes para asegurarse de que esto no ocurrirá: * Hacer uso de NBNS para controlar el registro de nombres NetBIOS por parte de las máquinas * Permitir la defensa de su nombre a cada máquina de la red, en el caso de que otra máquina intente usarlo La Figura 6-9 ilustra un registro de nombre (fallido), con y sin NBNS. Figura 6-9. Registro de nombres Broadcast versus NBNS[23] [samba-registro-de-nombres-broadcast-vs-NBNS.png] Como se mencionó anteriormente, debería existir alguna forma de resolver nombres NetBIOS a la dirección IP correspondiente; a esto se le conoce como resolución de nombres. Existen dos estrategias diferentes con NBT aquí también: * Que cada ordenador comunique su dirección IP cuando "escuche" una petición broadcast para su nombre NetBIOS * Usar el NBNS para ayudar a resolver los nombres NetBIOS a direcciones IP La Figura 6-10 ilustra los dos tipos de resolución de nombres. Figura 6-10. Resolución de nombres Broadcast versus NBNS[24] [samba-resolucion-de-nombres-broadcast-vs-NBNS.png] Como se podría esperar, tener un NBNS en su red puede ayudar enormemente. Para ver exactamente por qué, eche un vistazo al método broadcast. Aquí, cuando un cliente arranca, envía un mensaje broadcast manifestando su deseo de registrar un nombre NetBIOS específico para el. Si nadie pone objeción al uso del nombre, el obtiene el nombre. Por otro lado, si otra máquina en la subred local está actualmente usando ese nombre, enviará un mensaje de respuesta al cliente solicitante indicando que ese nombre ya está siendo usado. Esto es conocido como defender el nombre del host. Este tipo de sistema es útil cuando un cliente se ha caído inesperadamente de la red -otro puede tomar su nombre-, pero se incurre en un importante aumento del tráfico de la red para algo tan simple como el registro de un nombre. Con un NBNS, ocurre lo mismo, pero con la diferencia de que la comunicación está confinada a la máquina solicitante y al servidor de nombres NBNS. No se produce un broadcast cuando una máquina desea registrar su nombre; el mensaje de registro es simplemente enviado desde el cliente hacia el servidor NBNS, y el servidor NBNS responde si el nombre está o no libre. A esto se le denomina como comunicación punto-a-punto, y es beneficioso en redes con más de una subred. Esto se debe a que los routers suelen estar preconfigurados para bloquear los paquetes broadcast entrantes. Los mismos principios se aplican a la resolución de nombres. Sin un servidor NBNS, la resolución de nombres NetBIOS se podría realizar mediante broadcast. Todos los paquetes se enviarían a cada ordenador de la red, con la esperanza de que el ordenador afectado por la petición responda directamente a la máquina solicitante. El uso de un servidor NBNS y la comunicación punto-a-punto para este propósito carga mucho menos la red que inundar la red con peticiones broadcast para cada petición de resolución de nombres que se produzca. Se puede discutir que los paquetes broadcast no causan problemas significativos en las redes modernas y de gran ancho de banda compuestas por máquinas con CPUs muy rápidas, si sólo un grupo reducido de ordenadores están presentes en la red, o la demanda de ancho de banda es pequeña. Hay muchos casos en los que la anterior suposición es cierta; sin embargo, se aconseja no confiar en el broadcast tanto como se pueda. Esta es una regla a seguir en redes grandes y saturadas, y si se sigue este consejo a la hora de configurar redes pequeñas, estas podrán crecer sin problemas en el futuro. _________________________________________________________ 6.4.3. Tipos de nodos ¿Cómo informo a los clientes sobre la estrategia a seguir para realizar el registro y la resolución de nombres? Cada máquina en una red NBT gana una de las siguientes designaciones, dependiendo de cómo se maneje el registro y la resolución de nombres: b-node, p-node, m-node y h-node. El comportamiento de cada tipo de nodo se resumen en la Tabla 6-1. Tabla 6-1. Tipos de nodo NetBIOS Rol Valor b-node Hace uso de registro y resolución broadcast únicamente p-node Hace uso de registro y resolución punto-a-punto únicamente m-node (mixto) Hace uso de broadcast para el registro. Si lo consigue, notifica al servidor NBNS el resultado. Hace uso de broadcast para la resolución; utiliza NBNS si el broadcast no ha tenido éxito h-node (híbrido) Hace uso del servidor NBNS para el registro y la resolución; utiliza broadcast si el servidor NBNS no responde o no está operativo Los clientes Windows suelen encontrarse como h-nodes o nodos híbridos. Los tres primeros tipos de nodos aparecen el los RFCs 1001/1002, y los h-nodes fueron inventados más tarde por Microsoft, como un método más tolerable a fallos. Puede encontrar el tipo de nodo de un ordenador Windows 95/98/Me ejecutando la orden winipcfg y pulsando sobre el botón de Más información. En Windows NT/2000/XP, puede hacer uso de la orden ipconfig /all en el prompt de una ventana de comandos. En cualquier caso, busque la línea que diga Node Type. _________________________________________________________ 6.4.4. ¿Qué hay en un nombre? Los nombres utilizados en NetBIOS son ligeramente diferentes de los nombres empleados en los DNS, con los que estará familiarizado. En primer lugar, los nombres NetBIOS existen en un espacio de nombres único. En otras palabras, no existen niveles jerárquicos como en samba.org (dos niveles) o en ftp.samba.org (tres niveles). Los nombres NetBIOS están formados por una única cadena como toltec o maya, cada uno de ellos pertenecientes a un grupo de trabajo o un dominio. En segundo lugar, los nombres NetBIOS sólo pueden contener 15 caracteres y están compuestos únicamente por los caracteres alfanuméricos estándar (a-z, A-Z, 0-9) y los siguientes: ! @ # $ % ^ & ( ) - ' { } . ~ Aunque se puede hacer uso del punto (.) en un nombre NetBIOS, no es recomendable, debido a que esos nombres puede que no funcionen en futuras versiones de NBT. No es una coincidencia que todos los nombres DNS válidos también sean válidos en NetBIOS. De hecho, el nombre DNS para un servidor Samba es frecuentemente usado como su nombre NetBIOS. Por ejemplo, si tiene un sistema con el siguiente nombre: toltec.ora.com, su nombre NetBIOS podría ser TOLTEC (seguido de 9 espacios en blanco). _________________________________________________________ 6.4.4.1. Nombres de recursos y tipos Con NetBIOS, un ordenador no sólo anuncia su presencia, sino que también comunica a las otras máquinas que tipo de servicios ofrece. Por ejemplo, toltec puede indicar que no es únicamente una estación de trabajo, sino que también es un servidor de ficheros y puede recibir mensajes Windows Messenger. Esto se consigue añadiendo el byte décimosexto al final del nombre de la máquina (recurso), denominado tipo de recurso, y registrando el nombre más de una vez, una vez por cada servicio que ofrece. Observe la Figura 6-11. Figura 6-11. Estructura de nombres NetBIOS[25] [samba-estructura-de-nombres-netbios.png] El tipo de recurso de 1 byte indica el único servicio que el ordenador ofrece. La notación empleada a partir de este momento para mostrar el tipo de servicio ofrecido por un determinado ordenador estará enmarcada entre los símbolos de mayor y menor que (<>) después del nombre NetBIOS, como se muestra en el Ejemplo 6-4: Ejemplo 6-4. Notación empleada para mostrar el tipo de servicio NetBIOS ofrecido por un ordenador TOLTEC<00> Puede saber qué nombres están registrados para una máquina NBT determinada usando la orden de Windows nbtstat. Debido a que estos servicios son únicos (no puede haber más de uno registrado), aparecerán listados como tipo ÚNICO (UNIQUE) en la salida. Por ejemplo, el Ejemplo 6-5 describe al servidor toltec: Ejemplo 6-5. Ejecución de la orden nbtstat D:\> nbtstat -a toltec NetBIOS Remote Machine Name Table Name Type Status --------------------------------------------- TOLTEC <00> UNIQUE Registered TOLTEC <03> UNIQUE Registered TOLTEC <20> UNIQUE Registered ... Esto indica que el servidor ha registrado el nombre NetBIOS toltec como nombre de máquina, como un receptor de mensajes desde el servicio Messenger de Windows y como un servidor de archivos. Algunos de los posibles atributos que un nombre puede tener se listan en la Tabla 6-2. Tabla 6-2. Tipos de recursos únicos NetBIOS Nombre del Recurso Valor en hexadecimal del byte Standard Workstation Service 00 Messenger Service 03 RAS Server Service 06 Domain Master Browser Service (associated with primary domain controller) 1B Master Browser name 1D NetDDE Service 1F Fileserver (including printer server) 20 RAS Client Service 21 Network Monitor Agent BE Network Monitor Utility BF _________________________________________________________ 6.4.4.2. Nombres de grupos y tipos SMB también usa el concepto de grupos, con los cuales los ordenadores se pueden registras ellos mismos. Anteriormente se mencionó que los ordenadores del ejemplo pertenecían a un grupo de trabajo, el cual es una partición de ordenadores en la misma red. Por ejemplo, una empresa podría tener fácilmente un grupo de trabajo ADMINISTRACIÓN y otro VENTAS, cada uno con diferentes servidores e impresoras. En el mundo Windows, un grupo de trabajo y un grupo SMB son la misma cosa. Continuando con el ejemplo sobre nbtstat, el servidor Samba toltec es también un miembro del grupo de trabajo METRAN (el atributo GROUP hex 00), y participará en la elección del buscador (browser) maestro (atributo GROUP 1E). Observe el Ejemplo 6-6>: Ejemplo 6-6. Muestra de los grupos a los que pertenece un servidor con nbtstat NetBIOS Remote Machine Name Table Name Type Status --------------------------------------------- METRAN <00> GROUP Registered METRAN <1E> GROUP Registered ..__MSBROWSE__.<01> GROUP Registered Los posibles atributos de grupo que puede tener una máquina se ilustran en la Tabla 6-3. Existe más información disponible en el libro "Windows NT in a Nutshell" de Eric Pearce, publicado por O'Reilly. Tabla 6-3. Tipos de Recursos de Grupo NetBIOS Nombre del Recurso Valor en hexadecimal del byte Standard Workstation group 00 Logon server 1C Master Browser name 1D Normal Group name (used in browser elections) 1E Internet Group name (administrative) 20 <01><02>_ _MSBROWSE_ _<02> 01 La entrada final, _ _ MSBROWSE _ _, es utilizada para anunciar un grupo a otros buscadores maestros. Los caracteres no imprimibles en el nombre se muestran como guiones bajos en una salida de nbtstat. No se preocupe si no comprende todos los recursos o tipos de grupos. Algunos de ellos no los necesitará con Samba, y sobre los otros se verá más en el resto del capítulo. Lo importante aquí es recordar la lógica del mecanismo de nombres. _________________________________________________________ 6.4.5. Scope ID En los años oscuros del funcionamiento en red de SMB, antes de la introducción de los grupos NetBIOS, se debía utilizar una estrategia muy primitiva para aislar grupos de ordenadores del resto de la red. Cada paquete SMB contenía un campo denominado scope ID, la idea era que los sistemas de la red se pudiesen configurar de forma que sólo aceptasen los paquetes con el scope ID que coincidiese con su configuración. Esta característica fue apenas utilizada y desgraciadamente aun pervive en las implementaciones modernas. Algunas de las utilidades incluidas en la distribución de Samba permite establecer el scope ID. El establecimiento del scope ID en una red es sinónimo de problemas, sólo se ha mencionado para evitar confusiones cuando aparezca el término más adelante. _________________________________________________________ 6.4.6. Datagramas y sesiones En este punto, se hará un paréntesis para abordar la responsabilidad de NBT: proporcionar servicios de conexión entre dos máquinas NetBIOS. NBT ofrece dos servicios: el servicio de sesión y el servicio de datagramas. Comprender cómo funcionan estos servicios no es vital para usar Samba, pero le dará una idea sobre cómo trabaja NBT y cómo arreglar problemas cuando Samba no funcione. El servicio de datagramas no proporciona una conexión estable entre ordenadores. Los paquetes de datos se envían o difunden (broadcast) de una máquina a otra, sin tener en cuenta el orden en que estos llegan al destino, o incluso si han llegado todos. El uso de datagramas requiere menos procesamiento que las sesiones, aunque la confiabilidad de la conexión puede sufrir. Los datagramas, por tanto, son empleados para enviar rápidamente bloques no vitales de datos a una o más máquinas. El servicio de datagramas se comunica usando las primitivas que se muestran en la Tabla 6-4. Tabla 6-4. Primitivas de datagrama Primitiva Descripción Send Datagram Envía un paquete datagrama a un ordenador o grupo de ordenadores Send Broadcast Datagram Difunde (broadcast) datagramas a cualquier ordenador, esperando por un Receive Broadcast datagram (datagrama de acuse de recibo) Receive Datagram Recibe un datagrama desde un ordenador Receive Broadcast Datagram Espera por un datagrama de difusión (broadcast) El servicio de sesiones es más complejo. Las sesiones son un método de comunicación que, en teoría, ofrece la capacidad de detectar conexiones problemáticas o inoperativas entre dos aplicaciones NetBIOS. Esto lleva a pensar en una sesión NBT en términos de una llamada telefónica, analogía que obviamente influyó en el diseño del estándar CIFS. Una vez que se establece la conexión, permanece abierta durante toda la conversación, cada lado conoce quien es el ordenador emisor y receptor, y cada uno se puede comunicar haciendo uso de las primitivas mostradas en la Tabla 6-5. Tabla 6-5. Primitivas de sesión Primitiva Descripción Call Inicia una sesión con un ordenador que está escuchando bajo un nombre determinado Listen Espera por una llamada desde un emisor conocido o cualquier emisor Hang-up Finaliza una conversación Send Envía datos al otro ordenador Receive Recibe datos del otro ordenador Session Status Obtiene información de las sesiones solicitadas Las sesiones son el backbone de la compartición de recursos en una red NBT. Se utilizan normalmente para establecer conexiones estables desde los clientes a unidades de disco o impresoras compartidas en un servidor. El cliente "llama" al servidor y comienza a negociar la información, como los archivos que desea abrir, los datos que desea intercambiar, etc. Estas llamadas pueden durar mucho tiempo -horas, incluso días- y todo esto ocurre dentro del contexto de una única conexión. Si se produce un error, el software de sesión (TCP) retransmitirá los datos hasta que se reciban correctamente, a diferencia del método "envía-y-reza" del servicio de datagramas (UDP). En realidad, mientras que las sesiones se supone que están para manejar comunicaciones problemáticas, algunas veces no lo hacen. Si la conexión es interrumpida, la información de sesión que está abierta entre dos ordenadores puede volverse inválida. Si esto ocurre, la única forma de restablecer la sesión entre los dos ordenadores es llamar de nuevo y comenzar desde cero. Si desea más información sobre estos servicios, eche un vistazo al RFC 1001. Sin embargo, hay dos cosas importantes a recordar aquí: * Las sesiones siempre ocurren entre dos máquinas NetBIOS. Si una sesión se interrumpe, se supone que el cliente ha almacenado suficiente información de estado para restablecerla. Sin embargo, en la práctica, normalmente esto no ocurre. * Los datagramas pueden ser difundidos (broadcast) hacia múltiples ordenadores, pero no son confiables. En otras palabras, no hay manera de que el emisor sepa si los datagramas que ha enviado han llegado correctamente a sus destinos. _________________________________________________________ 6.5. Grupos de trabajo y dominios Windows Hasta ahora se ha cubierto la tecnología básica SMB, que sería todo lo que necesitaría saber si su red estuviese compuesta únicamente de clientes MS-DOS. Se asumirá que posee clientes Windows, especialmente las versiones más recientes, por lo que en las siguientes secciones se describirán las mejoras que Microsoft ha introducido en en las redes SMB -denominadas: Windows para grupos de trabajo y Dominios Windows. _________________________________________________________ 6.5.1. Grupos de trabajo Windows Los grupos de trabajo de Windows son muy similares a los grupos SMB ya descritos. Pero necesita saber algunas cosas adicionales. _________________________________________________________ 6.5.2. Navegando La navegación es el proceso de buscar otros ordenadores o recursos compartidos en la red Windows. Tenga en cuenta que no tiene ningún parecido con un navegador web, a parte de la idea general de "descubrir que hay". Por otro lado, navegar por la red de Windows es parecido a hacerlo por la web, en el sentido de que todo lo que existe pude cambiar sin previo aviso. Antes de la existencia del navegador, los usuarios debían conocer el nombre del ordenador al que se querían conectar, luego tenían que teclear manualmente una dirección UNC en el gestor de archivos o la aplicación implicada para poder acceder al recurso. La dirección UNC era algo parecido a lo que se muestra en el Ejemplo 6-7: Ejemplo 6-7. Notación UNC \\toltec\spirit\ La navegación es mucho más conveniente, ya que permite examinar los contenidos de la red haciendo uso de una interfaz "apunta-y-pulsa" del entorno de red de los clientes Windows. Encontrará dos tipos de navegación en una red SMB: * Navegar por una lista de ordenadores y sus recursos compartidos * Navegar por los recursos compartidos de un determinado ordenador A continuación se profundizará un poco en el primer tipo. En cada LAN (o subred) con un grupo de trabajo o dominio Windows, un ordenador tiene la responsabilidad de mantener la lista de ordenadores que están en un momento dado accesibles a través de la red. Este ordenador se denomina buscador (browser) maestro local, y la lista que mantiene se denomina lista de búsqueda. Los ordenadores de una red utilizan la lista de búsqueda para minimizar el tráfico de datos necesario para realizar una búsqueda. En vez de que cada ordenador pregunte por la lista de ordenadores actualmente disponibles, estos pueden preguntar al buscador maestro local para obtener una lista completa y actualizada. Para navegar por los recursos de un determinado ordenador, el usuario debe conectar a dicho ordenador; esta información no se puede obtener de la lista de búsqueda. La navegación por la lista de recursos compartidos de un ordenador se realiza haciendo doble click sobre el icono del ordenador que se presenta en el entorno de red. Como se veía al principio del capítulo, el ordenador responderá con una lista de los recursos que están accesibles una vez que el usuario se haya autentificado. Cada servidor en un grupo de trabajo Windows necesita anunciar su presencia al brower maestro local, una vez que ha registrado su nombre NetBIOS, y (teóricamente) anuncia que va a dejar el grupo de trabajo cuando es desconectado. Es responsabilidad del buscador maestro local almacenar los servidores que se han anunciado. Aviso El entorno de red de Windows puede comportarse de manera extraña: hasta que se selecciona un ordenador, el entorno de red de Windows puede contener información no actualizada. Esto significa que el entorno de red de Windows puede mostrar ordenadores que se han caído o no informar de aquellos ordenadores que todavía no se han anunciado. Resumiendo, una vez seleccionado un servidor y realizada la conexión con el, puede estar seguro de que los recursos compartidos así como las impresoras existen realmente en la red. A parte de los roles vistos con anterioridad, casi cualquier sistema Windows (incluyendo Windows para grupos de trabajo y Windows 95/98/Me o Windows NT/2000/XP) puede actuar como un buscador maestro local. Un buscador maestro local puede tener uno o más buscadores de respaldo en la subred local, que tomarán el relevo al buscador maestro local en el caso de que este falle o se vuelva inaccesible. Para asegurar operaciones fluidas, los buscadores de respaldo actualizarán frecuentemente su lista con la del buscador maestro local. A continuación se muestra como calcular el número mínimo de buscadores de respaldo que se pueden asignar en un grupo de trabajo: * Si la red está formada por hasta 32 máquinas Windows NT/2000/XP, o hasta 16 máquinas Windows 95/98/Me, el buscador maestro local asigna un buscador de respaldo a mayores del buscador maestro local * Si el número de máquinas Windows NT/2000/XP está comprendido entre 33 y 64, o el número de máquinas Windows 95/98/Me está comprendido entre 17 y 32, el buscador maestro local asigna dos buscadores de respaldo * Para cada grupo de 32 máquinas Windows NT/2000/XP o 16 ordenadores Windows 95/98/Me además de esto, el buscador maestro local asigna otro buscador de respaldo No existe límite en cuanto al número máximo de buscadores de respaldo que pueden ser asignados por un buscador maestro local. _________________________________________________________ 6.5.3. Elecciones para la navegación La navegación es un aspecto crítico en cualquier grupo de trabajo Windows. Sin embargo, no todo funciona correctamente en todas las redes. Sirva el siguiente ejemplo para ilustrar este hecho: imagínese un ordenador con Windows ubicado en el despacho de un CEO de una pequeña compañía actúa como buscador maestro local -esto quiere decir, que será un buscador maestro local hasta que el CEO lo desconecte para recibir su masaje-. En este momento, la máquina Windows NT ubicada en la sección de piezas de recambio de un departamento está dispuesta a tomar el control del trabajo. Sin embargo, dicho ordenador está ejecutando un programa extremadamente grande y mal escrito que está consumiendo los recursos del procesador. La moraleja: los navegadores han de ser muy tolerantes con las idas y venidas de los servidores. Debido a que casi cualquier sistema Windows puede servir como buscador, ha de haber alguna forma de decidir en cualquier momento quien toma el trabajo. El proceso de decisión se denomina elección. Casi cualquier sistema Windows tiene un algoritmo de elección, de forma que los sistemas se puedan poner de acuerdo en quien será el buscador maestro local y quien el buscador de respaldo local. Una elección puede ser forzada en cualquier momento. Por ejemplo, imagine que el CEO ha finalizado su masaje y reinicia el servidor. Como el servidor vuelve a estar disponible, anuncia su presencia, y tendrá lugar una elección para ver si el PC ubicado en la sección de piezas de recambio todavía continua siendo el buscador maestro local. Cuando se ejecuta una elección, cada ordenador difunde información sobre sí mismo haciendo uso de datagramas. Esta información incluye: * La versión del protocolo de elección utilizado * El sistema operativo del ordenador * La cantidad de tiempo que el ordenador ha estado conectado a la red * El hostname del cliente Estos valores determinan que sistema operativo tiene la veteranía y pueda cumplir con el rol de buscador maestro local[26]. La estructura desarrollada para lograr esto no es elegante y tiene problemas de seguridad implícitos. Mientras que un dominio de búsqueda puede ser integrado con un dominio de seguridad, el algoritmo de elección no tiene en cuenta que ordenadores van a ser buscadores. Esto es posible para cualquier ordenador que ejecute un servicio de búsqueda y se haya registrado como participante en la elección del buscador, una vez ha ganado es capaz de cambiar la lista de búsqueda. No obstante, la navegación es una característica llave en el funcionamiento de la red de Windows, y las características de compatibilidad hacia atrás garantizarán que seguirá en uso durante los años venideros. _________________________________________________________ 6.5.4. Autentificación de Windows 95/98/Me Existen tres tipos de claves cuando un sistema Windows 95/98/Me está interactuando en un grupo de trabajo Windows: * Una clave de Windows * Una clave de red Windows * Una clave para cada uno de los recursos compartidos a los que se le ha asignado protección con contraseña Las claves de Windows funcionan de tal forma que son la fuente de confusión para los administradores de sistemas Unix. No hay manera de prevenir el uso de los ordenadores por parte de usuarios sin autorización. (Si no se lo cree, pulse sobre el botón Cancelar del cuadro de diálogo de autentificación y compruebe lo que ocurre). En lugar de eso, la clave de Windows se utiliza para poder acceder a los archivos y recursos compartidos disponibles en la red de Windows que están protegidos con clave. Existe un archivo por cada usuario registrado en el sistema, este se puede encontrar en el directorio C:\Windows y su nombre será el de la cuenta del usuario, seguido por la extensión .pwl. Por ejemplo, si la cuenta de usuario es sara, el archivo será C:\Windows\sara.pwl. Este archivo está cifrado con la clave de Windows como llave de cifrado. Sugerencia Como medida de seguridad, debería comprobar la existencia de archivos .pwl en los clientes Windows 95/98/Me, ya que pueden haber sido creados debido a los intentos de acceso fallidos por parte de los usuarios. Un archivo .pwl se puede romper con facilidad y puede contener claves válidas de cuentas Samba o recursos compartidos. La primera vez que se accede a la red, Windows intenta utilizar la clave de Windows como clave de red. Si hay éxito, no se le preguntará al usuario por una clave de acceso a la red, de esta forma, los siguientes ingresos en el sistema Windows ingresarán automáticamente a su vez en la red de Windows, haciendo las cosas más sencillas al usuario. Los recursos compartidos en un grupo de trabajo pueden tener asignados a su vez claves que limitan el acceso a los mismos. La primera vez que un usuario intenta acceder a este tipo de recursos, se le solicitará una clave, pudiendo seleccionar una opción en el cuadro de diálogo de autentificación para añadir la clave a su lista de claves. Esta opción está marcada por defecto; si se acepta, Windows almacenará la clave en el fichero .pwl del usuario, siendo manejadas automáticamente por Windows ulteriores autentificaciones para dicho recurso. La estrategia de Samba para la autentificación en los grupos de trabajo es un poco diferente, y ha sido el resultado de mezclar el modelo de grupos de trabajo de Windows con el modelo Unix, donde se ejecuta Samba[27]. _________________________________________________________ 6.5.5. Dominios de Windows NT El modelo de red punto-a-punto de los grupos de trabajo Windows funciona bastante bien siempre y cuando el número de ordenadores de la red sea pequeño y haya una comunidad de usuarios muy restringida. Sin embargo, en grandes redes la simplicidad de los grupos de trabajo llega a ser un factor limitador. Los grupos de trabajo ofrecen sólo el nivel más básico de seguridad, y debido a que cada recurso compartido puede tener su propia clave, es un inconveniente (por decir lo mínimo) para los usuarios tener que recordar la clave de cada recurso en una red de gran envergadura. Incluso si esto no fuese un problema, mucha gente encuentra frustrante tener que interrumpir su proceso de trabajo para teclear la clave del recurso compartido en el cuadro de diálogo cada vez que se accede a otro recurso de red. Para soportar las necesidades de las grandes redes, tales como las que se encuentran en los departamentos computacionales, Microsoft introdujo los dominios con la versión 3.51 de Windows NT. Un dominio Windows NT es en esencia un grupo de trabajo de un ordenador SMB que tiene una característica añadida: el servidor que actúa como controlador de dominio (vea la Figura 6-12). Figura 6-12. Un simple dominio Windows[28] [samba-un-simple-dominio-windows.png] _________________________________________________________ 6.5.5.1. Controladores de dominio Un controlador de dominio en un dominio Windows NT funciona de manera muy similar a un servidor NIS en una red Unix, manteniendo una base de datos del dominio que contiene la información de los usuarios y grupos, así como sus servicios asociados. Las responsabilidades de un controlador de dominio están principalmente centradas en la seguridad, incluyendo la autentificación o la tarea de permitir o denegar el acceso a los recursos del dominio a un determinado usuario. Esto se realiza normalmente gracias al uso de un nombre de usuario y una clave. El servicio que mantiene la base de datos en los controladores de dominio se denomina Security Account Manager (SAM). El modelo de seguridad de Windows NT gira en torno a los identificadores de seguridad (SIDs) y las listas de control de acceso (ACLs). Los identificadores de seguridad son utilizados para representar objetos en un dominio, que incluyen (pero no limitan) a los usuarios, los grupos, los ordenadores y los procesos. Los SIDs se escriben normalmente en un formulario ASCII como campos separados por guiones, tal y como se muestra en el Ejemplo 6-8: Ejemplo 6-8. Muestra de un SID (Security IDentifier) S-1-5-21-1638239387-7675610646-9254035128-545 Un SID comienza con el carácter "S", seguido de un guión. El número inmediatamente posterior al primer guión se denomina identificador relativo (RID) y es un número único dentro del dominio que identifica a un usuario, un grupo, un ordenador o cualquier otro objeto. El número RID es análogo al user ID (UID) o al group ID (GID) en un sistema Unix o dentro de un dominio NIS. Las ACLs proveen la misma funcionalidad que los permisos de los archivos "rwx" comunes en los sistemas Unix. Sin embargo, las ACLs son más versátiles. Los permisos de los archivos Unix sólo pueden establecer permisos para el propietario y el grupo al que el fichero pertenece, y "otros", significa que cualquier otro usuario. Las ACLs de Windows NT/2000/XP permiten establecer permisos individuales para cualquier número arbitrario de usuarios y/o grupos. Las ACLs están constituidas por una o más entradas de control de acceso (ACE - Access Control Entries), cada una de las cuales contienen un SID y derechos de acceso asociados a este. El soporte de ACLs ha sido incluido como una característica estándar en algunas variantes de Unix y están disponibles como añadidos para otras. Samba soporta el mapeo de las ACLs entre Windows y Unix[29]. _________________________________________________________ 6.5.5.2. Controladores de dominio primarios y secundarios Ya se ha hablado sobre buscadores maestros y de respaldo. Los controladores de dominio se parecen a estos en que un dominio tiene un controlador primario (PDC) y puede tener uno o más controladores secundarios de dominio (BDCs). Si un PDC falla o no está accesible, sus tareas son automáticamente traspasadas a uno de los BDCs. Los BDCs sincronizan frecuentemente sus datos SAM con el PDC, por lo que si surge la necesidad cualquiera de ellos puede desempeñar inmediatamente los servicios del controlador primario, sin ningún tipo de impacto para los clientes. Sin embargo, tenga en cuenta que los BDCs tienen copias de solo lectura de la base de datos SAM; estos sólo pueden actualizar sus datos mediante la sincronización con un PDC. Un servidor en un dominio Windows puede hacer uso de la SAM de cualquier PDC o BDC para autentificar a un usuario que intente acceder a sus recursos e ingresar en el dominio. Todas las versiones recientes de Windows pueden ingresar en un dominio como clientes para tener acceso a los recursos de los servidores de dominio. Los sistemas que son considerados miembros del dominio son una clase más exclusiva, compuesta de un PDC y uno o varios BDCs, así como los servidores miembros del dominio, que no son más que sistemas que se han unido como miembros al domino, y son conocidos por los controladores de dominio debido a la cuenta existente para ellos en la base de datos SAM. _________________________________________________________ 6.5.5.3. Autentificación Cuando un usuario teclea su usuario y clave para ingresar en un dominio Windows, se invoca un desafío de seguridad y un protocolo de respuesta entre el ordenador cliente y el controlador de dominio para verificar que el usuario y la clave son válidos. Seguidamente el controlador de dominio envía el SID de nuevo al cliente, quien lo utilizará para crear un SAT (Security Access Token) que es válido únicamente para este sistema, que será utilizado para autentificaciones ulteriores. Esta señal de acceso contiene la información sobre el usuario codificada en su interior, la cual incluye el nombre de usuario, el grupo y los permisos que el usuario posee en el dominio. En este momento, el usuario está autentificado en el dominio. Posteriormente, cuando el cliente intenta acceder a un recurso compartido dentro del dominio, el sistema cliente entra en un desafío de seguridad y un intercambio de respuestas con el servidor del recurso. Seguidamente el servidor entra en otro desafío de seguridad y conversación de respuesta con el controlador de dominio, para comprobar que el cliente es válido. (Lo que ocurre realmente es que el servidor utiliza la información que ha obtenido del cliente para hacerse pasar por este y autentificarse el mismo ante el controlador de dominio. Si el controlador de dominio valida sus credenciales, envía un SID al servidor, que utilizará para crear su propio SAT para el cliente, de esta forma habilita el acceso a sus recursos locales en beneficio del cliente.) En este punto, el cliente se encuentra autentificado para los recursos del servidor y se le permite acceder a ellos. El servidor utiliza el SID almacenado en el SAT para determinar que permisos de modificación y uso posee el cliente para el recurso en cuestión, esto lo consigue comparándolo con las entradas de las ACLs del recurso. Aunque este método de autentificación pueda parecer demasiado complicado, permite a los clientes la autentificación sin enviar las claves en texto plano a través de la red, y es mucho más difícil de romper que la endeble seguridad que proporcionan los grupos de trabajo descritos anteriormente. _________________________________________________________ 6.5.5.4. Servicio de nombres con WINS y DNS El servicio de nombres de Internet de Windows (WINS) es una implementación de Microsoft del servidor de nombres NetBIOS (NBNS). Como tal, WINS hereda muchas de las características de NetBIOS. En primer lugar, WINS sólo puede tener nombres nombres simples o llanos para las máquinas, tales como inca, mixtec o navaho, y grupos de trabajo como PERU, MEXICO o USA. Otra característica es que WINS es dinámico: cuando un un cliente se conecta inicialmente a la red, este solicita un nombre, una dirección y un grupo de trabajo al servidor WINS local. Este servidor WINS almacenará la información mientras el cliente refresque periódicamente su registro WINS, lo que indicará que todavía está conectado a la red. Advierta que los servidores WINS no son específicos de un grupo de trabajo o un dominio; pueden contener información sobre múltiples dominios y/o grupos de trabajo, y pueden estar presentes en más de una subred. Se pueden configurar múltiples servidores WINS para que se sincronicen unos con otros. Esto permite que las entradas de los ordenadores que aparecen y desaparecen de la red se propagarse de un servidor WINS a otro. Aunque que en teoría esto parece eficiente, podría volverse rápidamente problemático si hay varios servidores WINS en la red. Debido a que los servicios WINS pueden atravesar múltiples subredes (puede especificar la dirección del servidor WINS en cada uno de los clientes u obtenerla vía DHCP), normalmente es más eficiente tener a cada cliente Windows, no importa cuántos dominios Windows haya, apuntando a un mismo servidor WINS. De esa forma, sólo habrá un servidor WINS dominante con la información correcta, en lugar de tener varios servidores WINS esforzándose por mantenerse sincronizados con los cambios más recientes. El servidor WINS activo en un determinado momento es conocido como el servidor WINS primario. También puede instalar un servidor WINS secundario, el cual entrará en acción en el caso de que el primario falle o se vuelva inaccesible. Tanto el servidor primario como cualquier otro servidor WINS sincronizarán sus bases de datos de direcciones periódicamente. En la familia de sistemas operativos Windows, sólo la edición de servidor Windows NT/2000 puede actuar como servidor WINS. Samba 2.2 puede funcionar como servidor WINS primario, pero no puede actualizar su base de datos con otros servidores WINS. Por este motivo, no puede actuar como servidor secundario WINS o como un servidor primario WINS de un servidor secundario WINS Windows. WINS maneja el servicio de nombres por defecto, aunque Microsoft añadió el DNS con Windows NT Server 4. Este es compatible con los DNSs que son estándar en virtualmente todos los sistemas Unix, y un servidor Unix (como el host Samba) puede ser utilizado para actuar de DNS. _________________________________________________________ 6.5.5.5. Relaciones de confianza Un aspecto adicional de los dominios Windows NT, que todavía no está soportado en Samba 2.2, es la posibilidad de configurar una relación de confianza entre dominios, permitiendo a los clientes de un dominio acceder a los recursos de otro sin necesidad de cualquier tipo de autentificación. El protocolo que está detrás de esto se denomina pass-through authentication, mediante el cual las credenciales de un usuario son pasadas de un cliente, en el primer dominio, a un servidor en el segundo dominio, quien consultará al controlador de dominio del primer dominio (de confianza) para comprobar que el usuario es válido antes de permitir el acceso a los recursos. Ha de notar que en muchos aspectos, el comportamiento de un Windows para grupos de trabajo y un Windows NT concuerdan. Por ejemplo, el buscador maestro y de respaldo en un dominio son siempre el PDC y BDC, respectivamente. A continuación se actualizará el diagrama de dominios Windows para incluir tanto al buscador maestro local como el de respaldo. El resultado se muestra en la Figura 6-13. Figura 6-13. Un dominio Windows con un buscador maestro local y uno de respaldo[30] [samba-dominio-windows-con-un-buscador-maestro-local-y-de-resp aldo.png] El parecido entre los grupos de trabajo y los dominios NT no es accidental, ya que el concepto de dominio Windows no se desarrolló hasta la versión 3.5 de Windows NT, y los dominios Windows se vieron forzados a mantener la compatibilidad hacia atrás con los grupos de trabajo presentes en Windows para grupos de trabajo. Samba puede actuar como un controlador primario de dominio para clientes Windows 95/98/Me y Windows NT/2000/XP, con la única limitación de que sólo puede actuar de PDC, no de BDC. Samba también puede funcionar como un servidor miembro de dominio, esto significa que tendrá una cuenta de equipo en la base de datos del PDC y por tanto será reconocido como parte del dominio. Un servidor miembro del dominio no puede autentificar a los usuarios que ingresan en el dominio, pero puede manejar funciones de seguridad (como los permisos de los archivos) para los usuarios del dominio que acceden a sus recursos. _________________________________________________________ 6.5.5.6. Dominios de Active Directory Dando comienzo con Windows 2000, Microsoft introdujo el Active Directory (Directorio Activo), el siguiente camino más allá de los dominios de Windows NT. No se va a entrar en mucho detalle con Active Directory, ya que es un tema extremadamente amplio. Samba 2.2 no soporta ninguna característica de Active Directory, y el soporte de la versión 3.0 de Samba se limita a actuar como un cliente. Desde ahora, sea consciente de que con Active Directory, el modelo de autentificación está centrado al rededor de LDAP, y el servicio de nombres lo suministra un DNS en lugar de un servidor WINS. Los dominios en Active Directory se pueden organizar en una estructura jerárquica en árbol, en la cual, cada controlador de dominio es fijo, no hay distinción entre controlador primario y secundario, como en los dominios Windows NT. Los sistemas Windows 2000/XP pueden configurar un simple grupo de trabajo o un dominio de clientes Windows NT (que funcionaría con Samba). La edición Server de Windows 2000 puede configurarse para que ejecute Active Directory y dominios Windows NT para mantener la compatibilidad hacia atrás (modo mixto). En este caso, Samba 2.2 trabaja con los servidores Windows 2000 de la misma forma que lo hacía con los servidores Windows NT 4.0. Cuando se configura para que opere en modo nativo, los servidores Windows 2000 sólo soportan Active Directory. Incluso así, Samba 2.2 puede operar como un servidor en un dominio albergado por un servidor Windows 2000 en modo nativo, haciendo uso del modo emulación PDC de un servidor Windows 2000. Sin embargo, no es posible para Samba 2.2 o 3.0 operar como un controlador de dominio en un un dominio Active Directory de Windows 2000. _________________________________________________________ 6.5.5.7. ¿Puede un grupo de trabajo abarcar múltiples subredes? Sí, pero la mayoría de la gente que ha hecho esto ha tenido muchos quebraderos de cabeza. Abarcar múltiples subredes no era parte del diseño inicial de Windows NT 3.5 o de Windows para grupos de trabajo. Como resultado, un dominio Windows que abarca dos o más subredes es, en realidad, un "encolado" de dos o más grupos de trabajo que comparten un nombre idéntico. La buena noticia es que todavía se puede hacer uso de un controlador primario de dominio para el control de autentificación a lo largo de cada subred. La mala noticia es que las cosas no son tan sencillas en la navegación. Como se mencionó anteriormente, cada subred ha de tener su propio buscador maestro local. Cuando un dominio Windows abarca múltiples subredes, un administrador del sistema tendrá que asignar una de las máquinas como buscador maestro de dominio. El buscador maestro de dominio mantendrá una lista de búsqueda para todo el dominio Windows. Esta lista de búsqueda es creada por la sincronización periódica de la lista de búsqueda de cada buscador maestro local con la lista de búsqueda del buscador maestro de dominio. Después de la sincronización, el buscador maestro local y el buscador maestro de dominio deberían contener entradas idénticas. Observe la Figura 6-14 para ver un ejemplo. Figura 6-14. Grupo de trabajo que abarca más de una subred[31] [samba-grupo-de-trabajo-que-abarca-mas-de-una-subred.png] ¿Suena bien? pues no se acerca al "cielo" por las siguientes razones: * Si existe, un PDC siempre juega el papel de buscador maestro de dominio. Debido al diseño de Microsoft, los dos siempre comparten el tipo de recurso NetBIOS <1B> y (desafortunadamente) no se pueden separar. * En los equipos Windows 95/98/Me no pueden llegar a ser ni siquiera contactar con un buscador maestro de dominio. Esto significa que necesariamente se ha de tener, al menos, un sistema Windows NT/2000/XP (o un servidor Samba) en cada subred del grupo de trabajo multi-red Cada buscador maestro local de cada subred continua manteniendo la lista de búsqueda para su subred, para la cual se vuelve dominante. De esta forma, si un ordenador desease ver la lista de los servidores de su propia subred, el buscador maestro local de esa subred sería interrogado. Si un ordenador quisiese ver una lista de servidores fuera de su subred, sólo podrá llegar hasta donde le lleve el buscador maestro local. Esto funciona debido a los intervalos fijados, la lista de búsqueda dominante del buscador maestro local de una subred se sincroniza con el buscador maestro de dominio, quien está sincronizado con el buscador maestro local de las otras subredes pertenecientes al dominio. Esto se denomina propagación de la lista de búsqueda. Samba puede actuar como buscador maestro de dominio en un dominio Windows NT, o puede actuar como un buscador maestro local para una subred, sincronizando su lista de búsqueda con el buscador maestro de dominio. _________________________________________________________ 6.6. Novedades de Samba 2.2 En la versión 2.2, Samba posee un soporte más avanzado para el sistema de red Windows, incluyendo la posibilidad de desempeñar las tareas más importantes necesarias para interactuar en un dominio Windows NT. A parte de esto, Samba 2.2 tiene algún soporte para las tecnologías que Microsoft introdujo en Windows 2000, aunque el grupo de desarrollo de Samba ha dejado el soporte de Active Directory para la versión 3.0. _________________________________________________________ 6.6.1. Soporte PDC para clientes Windows 2000/XP Anteriormente, Samba podía actuar como un PDC para autentificar sistemas Windows 95/98/Me y Windows NT 4. Esta funcionalidad ha sido extendida en la versión 2.2 para incluir a los sistemas Windows 2000 y Windows XP. De esta manera es posible disponer de un servidor Samba con soporte de autentificación en el dominio para los clientes Windows de la red, incluyendo las versiones más recientes. El resultado es una red más estable, de alto rendimiento y mucho más segura, con el beneficio de no tener que comprar Windows CALs a Microsoft. _________________________________________________________ 6.6.2. Soporte Dfs de Microsoft Microsoft Dfs permite que los recursos compartidos por un número determinado de servidores dispersos a lo largo de la red se junten y aparezcan, a los ojos de los usuarios, como si todos ellos existiesen en un sólo árbol de directorios de un servidor. Este método de organización hace la vida más fácil a los usuarios. En lugar de tener que buscar por la red, como si se tratase de un tesoro oculto, para encontrar un determinado recurso, los usuarios pueden ir directamente al servidor Dfs y coger lo que necesiten. Samba 2.2 ofrece soporte para servir Dfs, por lo que no se necesita un servidor Windows para este propósito. _________________________________________________________ 6.6.3. Soporte de impresión en Windows NT/2000/XP Windows NT/2000/XP poseen una interface de impresión basada en RPC diferente a la interfaz que poseen los sistemas Windows 95/98/Me. En la versión 2.2 de Samba, la interfaz de Windows NT/2000/XP está soportada. Junto con esto, el equipo de desarrollo de Samba ha añadido soporte para bajarse automáticamente el controlador de impresión desde un servidor Samba mientras se añade una nueva impresora desde un cliente Windows. _________________________________________________________ 6.6.4. ACLs Samba ahora soporta ACLs en aquellos sistemas Unix que las tienen incorporadas. Esta lista incluye Solaris 2.6, 7 y 8, Irix, AIX, GNU/Linux (con cualquiera de los parches de soporte de ACLs para los sistemas de archivos ext2/ext3, disponible en http://acl.bestbits.at o cuando se hace uso del sistema de archivos XFS y FreeBSD (versión 5.0 y posterior). Cuando se hace uso del soporte de ACLs, Samba traduce entre las ACLs de Unix y las de Windows NT/2000/XP, haciendo al equipo que ejecuta samba parecer y actuar más parecido a un servidor Windows NT/2000/XP desde el punto de vista de los clientes Windows. _________________________________________________________ 6.6.5. Soporte de las herramientas de administración de clientes Windows Windows vienen con una herramienta que puede ser utilizada desde un cliente para administrar los recursos compartidos en un servidor Windows remotamente. Samba 2.2 permite a esas herramientas manejar los recursos compartidos en un servidor Samba también. _________________________________________________________ 6.6.6. Integración con Winbind Windbind es una ayuda que permite a los usuarios cuya información de autentificación está almacenada en una base de datos de dominio Windows, poder autentificarse en un sistema Unix. El resultado es un entorno unificado de autentificación, en el cual una cuenta de usuario se puede conservar entre un sistema Unix o un controlador de dominio Windows NT/2000/XP. Esto facilita enormemente la administración de cuentas, debido a que los administradores ya no necesitarán mantener los dos sistemas sincronizados, permitiendo a los usuarios cuyas cuentas estén asociadas a un dominio Windows, autentificarse cuando accedan a un recurso compartido por Samba. _________________________________________________________ 6.6.7. Extensiones CIFS en Unix Las extensiones CIFS de Unix fue desarrollado por Hewlett-Packard e introducido en la versión 2.2.4 de Samba. Estas permiten a los servidores Samba soportar los atributos de los sistemas de archivos Unix, como los enlaces y los permisos, cuando se comparten archivos con otros sistemas Unix. Esta característica permite utilizar Samba como una alternativa a NFS para la compartición de archivos entre sistemas Unix. La ventaja de utilizar Samba es que autentifica a usuarios individualmente, mientras que NFS autentifica solamente clientes (basándose en su dirección IP, que es un modelo muy pobre en cuanto a la seguridad). Esto da un empujón en el área de seguridad a Samba, a parte de su gran capacidad de configuración. Consulte el capítulo 5 de la entrada bibliográfica TsEcksteinCollier-Brown01 para ver como operar con los sistemas Unix como clientes Samba. _________________________________________________________ 6.6.8. Y más... Como ya viene siendo habitual, el código posee muchas mejoras que no se ven a un nivel administrativo de forma inmediata u obvia. Actualmente Samba funciona mejor en los sistemas que utilizan PAM, y existe un nuevo soporte para perfiles. El soporte de Samba para los oplocks ha sido reforzado, ofreciendo mejor integración con los servidores NFS (actualmente sólo en Irix y GNU/Linux) y en el sistema de archivos local, con los bloqueos SMB mapeados a bloqueos POSIX (que es dependiente la implementación de los bloqueos POSIX de cada variante Unix). Y por supuesto, también han tenido lugar las correcciones normales de bugs. _________________________________________________________ 6.7. Novedades de Samba 3.0 La principal característica que distingue a la versión 3.0 de Samba es que incluye soporte para la autentificación mediante Kerberos 5 y LDAP, que es imprescindible para actuar como un cliente en un dominio Active Directory. Otra nueva característica es el soporte de Unicode, lo que simplificará mucho el soporte de lenguajes internacionales. _________________________________________________________ 6.8. ¿Qué puede hacer Samba? A continuación se verá donde puede ayudar Samba y cuales son sus limitaciones. La Tabla 6-6 resume los roles que Samba puede o no puede jugar en un dominio Windows NT o Active Directory o en un grupo de trabajo. Muchos de los protocolos del dominio de Windows son propietarios y no han sido documentados por Microsoft, por este motivo el equipo de desarrollo de Samba ha tenido que utilizar la ingeniería inversa para poder soportarlos. En la versión 3.0, Samba no puede actuar como servidor secundario en muchos de los roles y todavía no soporta completamente Active Directory. Tabla 6-6. Roles de Samba en la versión 3.0 Rol ¿Puede desempeñarlo? Servidor de archivos Sí Servidor de impresión Sí Servidor Dfs de Microsoft Sí Controlador de dominio primario Sí Controlador de dominio secundario No Controlador de dominio Active Directory No Autentificación de clientes Windows 95/98/Me Sí Autentificación de clientes Windows NT/2000/XP Sí Buscador maestro local Sí Buscador de respaldo local Sí Buscador maestro de dominio Sí Servidor primario WINS Sí Servidor secundario WINS No _________________________________________________________ 6.9. Visión general de la distribución Samba Como se mencionó anteriormente, actualmente Samba contiene muchos programas que prestan distintos servicios pero que tienen propósitos relacionados. A continuación se hará una breve introducción a cada uno de ellos y se describirá como trabajan en conjunción. La mayoría de los programas que vienen con Samba se centran en sus dos demonios. Las siguientes líneas mostrarán las responsabilidades de cada demonio: nmbd El demonio nmbd es un simple servidor de nombres que suministra la funcionalidad de WINS. Este demonio espera peticiones del servidor de nombres y proporciona la dirección IP apropiada cuando se le requiere. También provee una lista de búsqueda para el entorno de red y participa en la elección de búsqueda. smbd El demonio smbd maneja los recursos compartidos entre el servidor Samba y sus clientes. Provee los servicios de servidor de archivos, impresión y búsqueda a los clientes SMB a través de una o más redes y maneja todas las notificaciones entre el servidor Samba y la red de clientes. A parte de esto, es el responsable de la autentificación de usuarios, bloqueo de recursos y compartición de datos a través del protocolo SMB. Añadido en la versión 2.2, hay otro nuevo demonio: winbind Este demonio se utiliza junto con el servicio de nombres para obtener la información de los usuarios y grupos desde un servidor Windows NT y permitir a Samba autorizar a los usuarios dentro de un servidor Windows NT/2000. La distribución de samba también viene con un conjunto de pequeñas herramientas para consola: findsmb Un programa que realiza búsquedas de ordenadores en la red local que respondan al protocolo SMB e imprime información sobre los mismos. make_smbcodepage Un programa utilizado cuando se trabaja con la característica de internacionalización de Samba para informarle sobre como convertir entre mayúsculas y minúsculas en los distintos conjuntos de caracteres. make_unicodemap Otro programa de internacionalización utilizado con Samba para compilar un mapa Unicode que utilizará Samba para traducir los códigos de páginas de DOS o los conjuntos de caracteres de Unix en formato Unicode de 16 bits. net Un nuevo programa distribuido con Samba 3.0 que puede ser utilizado para realizar una administración remota de los servidores. nmblookup Un programa que realiza búsquedas de nombres sobre NBT para encontrar direcciones IP de ordenadores cuando se da su nombre de máquina. pdbedit Nuevo programa distribuido con la versión 3.0 de Samba que ayuda en el manejo de las cuentas de usuario almacenadas en las bases de datos SAM. rpcclient Un programa que se puede utilizar para ejecutar las funciones MS-RPC en los clientes Windows. smbcacls Un programa que se utiliza para establecer o mostrar ACLs en un sistema de archivos Windows NT smbclient Un cliente Unix similar a un cliente ftp, que se puede utilizar para conectarse a los recursos compartidos SMB y operar con ellos. El capítulo 5 de la entrada bibliográfica TsEcksteinCollier-Brown01 discute esta orden con más detalle. smbcontrol Una simple utilidad de administración que envía mensajes a nmbd o smbd. smbgroupedit Una orden que se puede utilizar para definir mapeos entre los grupos de Windows NT y los de Unix. Esta es una funcionalidad nueva en Samba 3.0. smbmnt Una utilidad utilizada junto con smbmount. smbmount Un programa que monta un sistema de archivos smbfs, permitiendo que recursos remotos SMB sean montados en el sistema de archivos local de la máquina Samba. smbpasswd Un programa que permite a un administrador cambiar la clave utilizada por Samba. smbsh Una herramienta que funciona de manera similar a una shell, permitiendo el acceso a sistemas de archivos SMB remotos, y permite a las herramientas de Unix operar con ellos. Esta orden se describe con mayor profundidad en el capítulo 5 de la entrada bibliográfica TsEcksteinCollier-Brown01 smbspool Un programa de cola de impresión que se utiliza para enviar archivos a impresoras remotas que están compartidas en la red SMB. smbstatus Un programa que reporta las conexiones de red realizadas a los recursos compartidos en el servidor Samba actualmente. smbtar Un programa similar a la orden tar de Unix, que permite archivar datos en los recursos compartidos de SMB. smbumount Un programa que trabaja junto con smbmount para desmontar los sistemas de archivos smbfs. testparm Un programa que comprueba el archivo de configuración de Samba. testprns Un programa que comprueba si las impresoras en la máquina Samba están reconocidas por el demonio smbd wbinfo Una utilidad utilizada para realizar peticiones al demonio winbind. Cada liberación mayor de Samba se somete a un chequeo intensivo antes de anunciarla. A parte de esto, se actualiza rápidamente después de liberada si ocurren problemas o se encuentran efectos inesperados. _________________________________________________________ 6.10. Información adicional sobre el proyecto 6.10.1. Página principal El Proyecto Samba dispone de una página principal, http://www.samba.org/, desde donde puede obtener mucha información sobre el proyecto. De hecho, para elaborar esta sección ha utilizado la información allí disponible. _________________________________________________________ 6.10.2. Cómo obtener Samba Las distribuciones del código fuente y de los binarios de Samba están disponibles en muchos mirrors a lo largo de Internet. La página principal de Samba es http://www.samba.org/. Desde allí, se puede seleccionar un mirror que esté geográficamente cerca de usted. Las distintas formas de distribución de Samba desde la página oficial se pueden ver en http://www.samba.org/download.html. La mayoría de las distribuciones de GNU/Linux y muchos distribuidores de Unix disponen de paquetes binarios de Samba. Suele ser más conveniente hacer uso de esos paquetes antes que el código fuente o los binarios del equipo de desarrollo de Samba, ya que los distribuidores se esfuerzan en suministrar paquetes que se adapten a las especificaciones de sus productos. _________________________________________________________ 6.10.3. Documentación Desde la página principal del proyecto Samba se puede acceder a distintos enlaces con documentación sobre el proyecto. Hay dos grandes formas de obtener la documentación: * en formato electrónico, para lo cual hay que acceder a: http://www.samba.org/docs/ * comprando alguno de los libros disponibles sobre el tema. Para obtener un listado de algunos de ellos, visite: http://www.samba.org/books.html _________________________________________________________ 6.10.4. Información de soporte La página dedicada al soporte y al contacto de Samba, informa sobre los distintos métodos existentes para obtener ayuda en un determinado momento. Los métodos más importantes para obtener ayuda son los siguientes: Listas de correo: El proyecto Samba dispone de varias listas de correo, desde donde se puede obtener información fiable y directa. El las siguientes páginas se pueden ver las listas disponibles y la forma de inscribirse a las mismas: http://www.samba.org/archives.html y http://lists.samba.org/. Grupos de news: Otro de los métodos disponibles para obtener ayuda, es el grupo de news comp.protocols.smb. Canales de IRC: Samba también dispone de dos canales en el servidor de IRC http://freenode.net/. El canal dedicado al desarrollo de Samba es #samba-technical y el dedicado a las preguntas de los usuarios y la discusión en general es el #samba. Servicio técnico de terceros: Muchas empresas ofrecen servicio técnico a la comunidad de Samba, un listado de las mismas se puede obtener desde: http://www.samba.org/support/countries.html. _________________________________________________________ 6.10.5. Reporte de bugs Samba dispone de un Sistema de seguimiento de tareas, desde donde se pueden reportar errores y bugs relacionados con Samba (tanto en lo relativo al software como a la documentación) y hacer peticiones de nuevas características. Si se quiere reportar un error grave de seguridad, lo más conveniente es utilizar el correo: security%40samba.org. Si lo que se quiere es remitir un parche o una mejora para Samba, se ha de enviar un correo a samba-technical@samba.org o bien visitar: http://samba.org/samba-patches/. Más detalles de las formas de reportar errores y parches en el siguiente enlace: http://www.samba.org/bugreports.html. _________________________________________________________ 6.10.6. Cómo contactar Para obtener más información sobre Samba, puede contactar con el Proyecto en la siguiente dirección: Samba Team 26 Carstensz st Griffith, ACT 2603 Australia _________________________________________________________ Capítulo 7. Instalación 7.1. Consideraciones previas El servidor Samba se instalará y configurará para que actúe como PDC de la red local en la que esté presente. La información de las cuentas de los usuarios se almacenará en un directorio LDAP y proveerá servicios de impresión y perfiles móviles, entre otras cosas. En la parte dedicada a OpenLDAP, Parte I en Integración de redes con OpenLDAP, Samba, CUPS y PyKota, se dejó listo el servicio de directorio para autentificar usuarios en las máquinas GNU/Linux. Lo único que falta para que esto sea posible, es introducir la estructura necesaria en la base de datos LDAP. En este apartado no sólo veremos como realizar esto, sino que también se dará soporte, en la estructura del directorio LDAP, para almacenar los datos relativos a una cuenta de usuario Samba. Una vez se haya incorporado esta estructura en el directorio LDAP, los usuarios que ahí se almacenen tendrán la posibilidad de autentificarse en cualquier sistema GNU/Linux y/o Windows que haga uso del servidor LDAP para la autentificación de usuarios. La particularidad es que tendrán la misma cuenta de acceso para los todos sistemas, tanto en GNU/Linux como en Windows, de toda la red. Se ha seleccionado la versión 3.0.* de Samba, que acompaña a la versión en desarrollo de Debian GNU/Linux. _________________________________________________________ 7.2. Pasos para la instalación Se ha de diferenciar la instalación de un servidor Samba de la instalación de un cliente. En las siguientes secciones se verá como instalar uno y otro, así como los requisitos para que todo funcione correctamente. En muchas ocasiones un mismo ordenador puede actuar como cliente y servidor Samba. En esta documentación se entenderá por servidor Samba, aquel ordenador que preste servicios (autentificación, compartición de unidades y archivos, etc.), y un cliente será aquel que los utilice (acceso a los recursos compartidos, autentificación, montaje de sistemas de archivos compartidos, etc.). Nota En el apéndice Apéndice D se pueden ver las distintas opciones que han de seleccionar si se desea poder montar sistemas de archivos servidos por Samba. _________________________________________________________ 7.2.1. Instalación de un servidor El paquete principal del servidor Samba es "samba", a continuación se muestra la información relativa al mismo: Ejemplo 7-1. Información sobre el paquete "samba" $ /usr/bin/apt-cache show samba Package: samba Priority: optional Section: net Installed-Size: 6036 Maintainer: Eloy A. Paris Architecture: i386 Version: 3.0.7-1 Replaces: samba-common (<= 2.0.5a-2) Depends: samba-common (1) (= 3.0.7-1), netbase, logrotate, libacl1 (>= 2.2.11-1), libc6 (>= 2.3.2.ds1-4), libcomerr2 (>= 1.33-3), libcupsys2-gnutls10 (>= 1.1.20final-1), libkrb53 (>= 1.3.2), libldap2 (>= 2.1.17-1), libpam0g (>= 0.76), libpopt0 (>= 1.7), debconf (>= 0.5) | debconf-2.0, libpam-runtime (>= 0.76-13.1), libpam-modules Suggests: samba-doc (2) Filename: pool/main/s/samba/samba_3.0.7-1_i386.deb Size: 2412814 MD5sum: b60a9942c8057c2f7ef3868bc79954a0 Description: a LanManager-like file and printer server for Unix The Samba software suite is a collection of programs that implements the SMB protocol for unix systems, allowing you to serve files and printers to Windows, NT, OS/2 and DOS clients. This protocol is sometimes also referred to as the LanManager or NetBIOS protocol. . This package contains all the components necessary to turn your Debian GNU/Linux box into a powerful file and printer server. . Currently, the Samba Debian packages consist of the following: . samba - LanManager-like file and printer server for Unix. samba-common - Samba common files used by both the server and the cli ent. smbclient - LanManager-like simple client for Unix. swat - Samba Web Administration Tool samba-doc - Samba documentation. smbfs - Mount and umount commands for the smbfs (kernels 2.2.x and ab ove). libpam-smbpass - pluggable authentication module for SMB password dat abase libsmbclient - Shared library that allows applications to talk to SMB servers libsmbclient-dev - libsmbclient shared libraries winbind: Service to resolve user and group information from Windows N T servers python2.3-samba: Python bindings that allow access to various aspects of Samba . It is possible to install a subset of these packages depending on your particular needs. For example, to access other SMB servers you should only need the smbclient and samba-common packages. Task: file-server, print-server (1) Una de las dependencias del paquete "samba" es "samba-common" (2) El paquete "samba" sugiere la instalación de la documentación asociada al mismo. Aun siendo recomendable instalar dicha documentación, será tarea del administrador la elección de su instalación. Ejemplo 7-2. Información sobre el paquete "samba-common" $ /usr/bin/apt-cache show samba-common Package: samba-common Priority: optional Section: net Installed-Size: 4456 Maintainer: Eloy A. Paris Architecture: i386 Source: samba Version: 3.0.7-1 Replaces: samba (<< 2.999+3.0.alpha21-4) Depends: debconf, libpam-modules, libc6 (>= 2.3.2.ds1-4), libcomerr2 (>= 1.33-3), libkrb53 (>= 1.3.2), libldap2 (>= 2.1.17-1), libpopt0 (>= 1.7) Filename: pool/main/s/samba/samba-common_3.0.7-1_i386.deb Size: 1904980 MD5sum: 46ffe1e90eaf4dea5337ea7d87ea7732 Description: Samba common files used by both the server and the client The Samba software suite is a collection of programs that implements the SMB protocol for unix systems, allowing you to serve files and printers to Windows, NT, OS/2 and DOS clients. This protocol is sometimes also referred to as the LanManager or NetBIOS protocol. . This package contains the common files that are used by both the serve r (provided in the samba package) and the client (provided in the smbcli ent package). Una vez obtenida la información sobre los paquetes que se van a instalar, se procede con la instalación de Samba: Ejemplo 7-3. Instalación de "samba" (primera parte) # /usr/bin/apt-get install samba Leyendo lista de paquetes... Hecho Creando árbol de dependencias... Hecho Se instalarán los siguientes paquetes extras: samba-common Paquetes sugeridos: samba-doc Se instalarán los siguientes paquetes NUEVOS: samba samba-common 0 actualizados, 2 se instalarán, 0 para eliminar y 1 no actualizados. Se necesita descargar 0B/4318kB de archivos. Se utilizarán 10,7MB de espacio de disco adicional después de desempaqu etar. ¿Desea continuar? [S/n] S Preconfiguring packages ... Figura 7-1. Configuración del grupo de trabajo/dominio de samba mediante debconf [samba-instalacion-samba1.png] Elección del grupo de trabajo/dominio que servirá el servidor Samba sujeto a la instalación. En este caso "GSRDOMAIN". Figura 7-2. ¿Contraseñas cifradas? [samba-instalacion-samba2.png] Se responde afirmativamente a esta pregunta, de esta forma se hará uso de cifrado para el intercambio/almacén de contraseñas. Figura 7-3. ¿Utilizar la información del DHCP para configurar WINS? [samba-instalacion-samba3.png] En esta documentación no se van a utilizar servidores WINS ni DHCP, por lo que se responde que no a esta pregunta. Figura 7-4. ¿Cómo ejecutar Samba (demonios/inetd)? [samba-instalacion-samba4.png] Momento para la elección sobre como se quiere ejecutar Samba, ya sea utilizando el superservidor inetd o mediante demonios. La elección realizada para esta documentación ha sido la ejecución mediante demonios, ya que en un entorno donde el uso de Samba sea frecuente, es mucho más eficiente ejecutarlo desde los demonios que desde un superservidor inetd. De todas formas, en el Apéndice C puede ver como ejecutar Samba desde un superservidor (x)inetd. Figura 7-5. Creación de la base de datos de contraseñas [samba-instalacion-samba5.png] Se responde que sí a esta pregunta, de esta forma se creará un archivo destinado al almacén de las contraseñas para los usuarios de Samba. Ejemplo 7-4. Instalación de "samba" (segunda parte) Seleccionando el paquete samba-common previamente no seleccionado. (Leyendo la base de datos ... 133203 ficheros y directorios instalados actualmente.) Desempaquetando samba-common (de .../samba-common_3.0.7-1_i386.deb) ... Seleccionando el paquete samba previamente no seleccionado. Desempaquetando samba (de .../samba_3.0.7-1_i386.deb) ... Configurando samba-common (3.0.7-1) ... Configurando samba (3.0.7-1) ... Generating /etc/default/samba... (1) TDBSAM version too old (0), trying to convert it. TDBSAM converted successfully. --------- IMPORTANT INFORMATION FOR XINETD USERS ---------- (2) The following line will be added to your /etc/inetd.conf file: ## netbios-ssn stream tcp nowait root /usr/sbin/tcpd /usr/sbin/smbd If you are indeed using xinetd, you will have to convert the above into /etc/xinetd.conf format, and add it manually. See /usr/share/doc/xinetd/README.Debian for more information. ----------------------------------------------------------- Starting Samba daemons: nmbd smbd. localepurge: checking system for new locale ... localepurge: processing locale files ... localepurge: processing man pages ... (1) Archivo destinado a las opciones por defecto de los scripts de inicio del servidor Samba. (2) Información para los usuarios de xinetd (servidor que reemplaza al superservidor de Internet -inetd-), importante si pretende utilizarlo para ejecutar Samba. Nota Si a la hora de instalar el paquete no se le han realizado todas las preguntas que se han mostrado en el proceso de instalación, puede forzarlo tecleando la siguiente orden: Ejemplo 7-5. Configuración preliminar de "samba" # /usr/sbin/dpkg-reconfigure --priority=low samba En estos momentos el servidor Samba ya se encontraría instalado e inicialmente configurado. En el siguiente capítulo se verá como adecuar la configuración a sus necesidades, pero antes se tratará la instalación de los clientes en la siguiente sección. _________________________________________________________ 7.2.2. Instalación de un cliente Hay dos paquetes importantes para un cliente Samba: "smbclient" y "smbfs", a continuación se verá su descripción: Ejemplo 7-6. Información sobre los paquetes "smbclient" y "smbfs" $ /usr/bin/apt-cache show smbclient smbfs Package: smbclient Priority: optional Section: net Installed-Size: 5988 Maintainer: Eloy A. Paris Architecture: i386 Source: samba Version: 3.0.7-1 Replaces: samba (<< 2.999+3.0.alpha21-4) Provides: samba-client Depends: samba-common (1) (= 3.0.7-1), libc6 (>= 2.3.2.ds1-4), libcomerr2 (>= 1.33-3), libkrb53 (>= 1.3.2), libldap2 (>= 2.1.17-1), libncurses5 (>= 5.4-1), libpopt0 (>= 1.7), libreadline4 (>= 4.3-1) Suggests: smbfs (2) Filename: pool/main/s/samba/smbclient_3.0.7-1_i386.deb Size: 2411216 MD5sum: 3c4fdf54182fce094b94a6f3e420e6f9 Description: a LanManager-like simple client for Unix The Samba software suite is a collection of programs that implements the SMB protocol for unix systems, allowing you to serve files and printers to Windows, NT, OS/2 and DOS clients. This protocol is sometimes also referred to as the LanManager or NetBIOS protocol. . This package contains some client components of the Samba suite. In particular it includes the command line utilities smbclient, smbtar, and smbspool. If you want to mount shares exported from Microsoft Windows machines or a Samba server you must install the smbfs package. Task: file-server, print-server Package: smbfs Priority: optional Section: otherosfs Installed-Size: 720 Maintainer: Eloy A. Paris Architecture: i386 Source: samba Version: 3.0.7-1 Replaces: smbfsx Depends: netbase (>= 2.02), samba-common (3) (= 3.0.7-1), libc6 (>= 2.3.2.ds1-4), libcomerr2 (>= 1.33-3), libkrb53 (>= 1.3.2), li bldap2 (>= 2.1.17-1) Suggests: smbclient (4) Conflicts: smbfsx, suidmanager (<< 0.50) Filename: pool/main/s/samba/smbfs_3.0.7-1_i386.deb Size: 311844 MD5sum: 3051f174f56f0b1cc5056364847daa50 Description: mount and umount commands for the smbfs (for kernels >= th an 2.2.x) Smbfs is a filesystem which understands the SMB protocol. This is the protocol Windows for Workgroups, Windows NT or LAN Manager use to talk to each other. It was inspired by samba, the program by Andrew Tridgell that turns any unix site into a file server for DOS or Windows clients. . If you want to use command-line utilities like smbclient, smbtar and/or smbspool you just need to install the smbclient package. . Starting with the Debian Samba packages version 2.2.0-1, the old smbfs utilities for 2.0.x have been removed. There are no wrapper scripts that call a specific smbmount/smbumount depending on the kernel version. If you are using a 2.0.x kernel please upgrade or use the latest Samba 2.0.7 Debian package. Task: file-server, print-server (1) (3) Como se puede ver, tanto el paquete "smbclient" como el paquete "smbfs" dependen de "samba-common", al igual que el paquete "samba" (vea el Ejemplo 7-1). (2) (4) Se puede comprobar que ambos paquetes, "smbclient" y "smbfs", se recomiendan mutuamente, normalmente suele ser buena idea instalar ambos. Ahora que ya se tiene la información de los paquetes que se van a instalar en el cliente, se procede con su instalación: Ejemplo 7-7. Instalación de "smbclient" y "smbfs" # /usr/bin/apt-get install smbclient smbfs Leyendo lista de paquetes... Hecho Creando árbol de dependencias... Hecho Se instalarán los siguientes paquetes NUEVOS: smbclient smbfs 0 actualizados, 2 se instalarán, 0 para eliminar y 1 no actualizados. Se necesita descargar 0B/2723kB de archivos. Se utilizarán 6869kB de espacio de disco adicional después de desempaqu etar. Seleccionando el paquete smbclient previamente no seleccionado. (Leyendo la base de datos ... 133280 ficheros y directorios instalados actualmente.) Desempaquetando smbclient (de .../smbclient_3.0.7-1_i386.deb) ... Seleccionando el paquete smbfs previamente no seleccionado. Desempaquetando smbfs (de .../smbfs_3.0.7-1_i386.deb) ... Configurando smbclient (3.0.7-1) ... Configurando smbfs (3.0.7-1) ... localepurge: checking system for new locale ... localepurge: processing locale files ... localepurge: processing man pages ... Una vez se ha completado el proceso de instalación, el sistema tendrá disponibles las siguientes herramientas (para saber que hace cada una, se pueden consultar las páginas del manual que traen adjuntas): Ejemplo 7-8. Herramientas suministradas por los paquetes "smbclient" y "smbfs" $ /usr/bin/dpkg -L smbclient | /bin/grep bin /usr/bin/smbclient /usr/bin/smbtar /usr/bin/rpcclient /usr/bin/smbspool /usr/bin/smbtree /usr/bin/smbcacls /usr/bin/smbcquotas $ /usr/bin/dpkg -L smbfs | /bin/grep bin /usr/bin/smbmount /usr/bin/smbumount /usr/bin/smbmnt /sbin/mount.smbfs /sbin/mount.smb _________________________________________________________ Capítulo 8. Primeros ajustes en la configuración de OpenLDAP Antes de continuar con la configuración de Samba, es necesario realizar algunas modificaciones y ajustes en la configuración de OpenLDAP, de forma que quede preparado para soportar las características de Samba. Lo primero que se ha de hacer es copiar el esquema de samba al directorio de esquemas de OpenLDAP. El Ejemplo 8-2 muestra como hacerlo. Importante El archivo de esquemas para Samba se encuentra en el paquete samba-doc, por lo que si no lo ha instalado en su sistema, puede hacerlo en este momento: Ejemplo 8-1. Instalación del paquete "samba-doc" # /usr/bin/apt-get install samba-doc Leyendo lista de paquetes... Hecho Creando árbol de dependencias... Hecho Se instalarán los siguientes paquetes NUEVOS: samba-doc 0 actualizados, 1 se instalarán, 0 para eliminar y 1 no actualizados. Se necesita descargar 0B/11,6MB de archivos. Se utilizarán 18,1MB de espacio de disco adicional después de desempaqu etar. Seleccionando el paquete samba-doc previamente no seleccionado. (Leyendo la base de datos ... 133336 ficheros y directorios instalados actualmente.) Desempaquetando samba-doc (de .../samba-doc_3.0.7-1_all.deb) ... Configurando samba-doc (3.0.7-1) ... localepurge: checking system for new locale ... localepurge: processing locale files ... localepurge: processing man pages ... Ejemplo 8-2. Copiado del esquema de Samba al directorio de esquemas de OpenLDAP # /bin/cp -v /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz /et c/ldap/schema `/usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz' -> `/etc/ldap/ schema/samba.schema.gz' # /bin/gunzip -v /etc/ldap/schema/samba.schema.gz /etc/ldap/schema/samba.schema.gz: 81.0% -- replaced with /etc/ld ap/schema/samba.schema # /bin/chown -v slapd.slapd /etc/ldap/schema/samba.schema cambiado el propietario de `/etc/ldap/schema/samba.schema' a slapd:slap d # /bin/chmod -v 644 /etc/ldap/schema/samba.schema el modo de `/etc/ldap/schema/samba.schema' cambia a 0644 (rw-r--r--) Por último, sólo queda añadir el nuevo esquema en el archivo de configuración de slapd y reiniciar el demonio. Para ello se ha de editar el archivo /etc/ldap/slapd.conf y añadir en la sección "# Schema and objectClass definitions" la siguiente línea: Importante El orden en el que se coloquen los esquemas dentro del archivo /etc/ldap/slapd.conf es importante. Si ha seguido todos los pasos hasta este punto, añada la siguiente línea al final de la lista de esquemas, para evitar errores al arrancar el demonio slapd. include /etc/ldap/schema/samba.schema Importante La clase objeto (objectClass) sambaSamAccount definida en el esquema samba.schema depende de los siguientes esquemas: include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema Acto seguido, se ha de reiniciar el demonio slapd: Ejemplo 8-3. Reinicio del demonio slapd # /etc/init.d/slapd restart Stopping OpenLDAP: slapd. Starting OpenLDAP: slapd. _________________________________________________________ Capítulo 9. Configuración de Samba 9.1. Introducción Este capítulo está dedicado a la configuración de Samba, primero se mostrará como es la estructura de un archivo de configuración para Samba y luego se procederá a mostrar las distintas opciones de configuración para obtener el resultado esperado. Nota Para obtener la configuración de Samba se han utilizado las siguientes entradas bibliográficas, a parte de las páginas del manual que provee Samba: Lemaire01, Syroid01, Syroid02, Milne01, Milne02, TsEcksteinCollier-Brown01, VernooijTerpstraCarter01, Coupeau01. _________________________________________________________ 9.2. Estructura del archivo smb.conf La configuración de Samba se almacena en el archivo smb.conf, que en el sistema Debian GNU/Linux se encuentra en el directorio /etc/samba/. La edición de este archivo se puede hacer utilizando un editor de textos o haciendo uso de herramientas gráficas, como la que provee Samba: SWAT (vea el Apéndice E para más información). _________________________________________________________ 9.2.1. Sintaxis El archivo smb.conf utiliza la misma sintaxis que los antiguos ficheros .ini de Windows 3.1: cada archivo consistía en varias secciones, las cuales comenzaban con el nombre de la sección entre corchetes ([]) en una nueva línea. Cada una contenía cero o más pares llave/valor separados por un signo de igualdad (=). El archivo de configuración de Samba es un archivo en texto plano, por lo que se puede editar con cualquier editor de textos. Cada sección en el archivo smb.conf representa un recurso compartido en el servidor Samba. La sección "global" es especial, ya que contiene opciones que se aplican a todo el servidor Samba y no sólo a un recurso compartido en particular. Un archivo de configuración realmente pequeño, podría ser: Ejemplo 9-1. Un archivo smb.conf mínimo [global] workgroup = GRUPODETRABAJO netbios name = MINOMBRE [recurso-compartido1] path = /tmp [recurso-compartido2] path = /otro_directorio_compartido comment = Algunos archivos aleatorios _________________________________________________________ 9.2.2. Comprobando el archivo smb.conf Es importante validar el contenido del archivo smb.conf haciendo uso del programa testparm. Si testparm se ejecuta correctamente, listará los servicios cargados. En el Ejemplo 9-2 se comprobará el archivo que viene por defecto (vea el apéndice Apéndice AC) con el paquete de Samba de la distribución Debian GNU/Linux, una vez instalado el paquete. Ejemplo 9-2. Comprobando el archivo por defecto smb.conf con testparm # /usr/bin/testparm Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[printers]" Processing section "[print$]" Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions [ENTER] # Global parameters [global] workgroup = GSRDOMAIN server string = %h server (Samba %v) obey pam restrictions = Yes passdb backend = tdbsam, guest passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\s UNIX\spassword:* %n\n . syslog = 0 log file = /var/log/samba/log.%m max log size = 1000 dns proxy = No panic action = /usr/share/samba/panic-action %d invalid users = root [homes] comment = Home Directories create mask = 0700 directory mask = 0700 browseable = No [printers] comment = All Printers path = /tmp create mask = 0700 printable = Yes browseable = No [print$] comment = Printer Drivers path = /var/lib/samba/printers _________________________________________________________ 9.3. Ajustando el archivo de configuración de Samba 9.3.1. Introducción En esta sección se configurará Samba como un Controlador Primario de Dominio que almacena su base de datos SAM en un servidor OpenLDAP. Para la configuración se asumirá que: * El nombre del dominio será: GSRDOMAIN * El nombre del servidor Netbios será: TODOSCSI * El directorio home de los usuarios estará en: /home/samba/users/NOMBREUSUARIO * Los perfiles móviles se almacenarán en: /home/samba/profiles/NOMBREUSUARIO _________________________________________________________ 9.3.2. [global] - sección global En la sección global se configurarán los parámetros globales del servidor. Entre otras cosas, se definirán los programas que serán utilizados para que un usuario pueda cambiar su clave (passwd program) y el diálogo que se establecerá entre el servidor y el usuario durante este cambio. La opción "add user script" permite al demonio smb añadir, como usuario root, una nueva máquina. Cuando una máquina contacta con el dominio, este script es llamado y la nueva máquina es añadida al dominio. Esto hace que la administración de las cuentas para las máquinas sea muy sencilla. Por razones de seguridad, no todas las máquinas pueden entrar en el dominio, sólo aquellas cuyo administrador tenga una cuenta con los privilegios suficientes. En las secciones siguientes se mostrarán los parámetros más importantes de la configuración de Samba, en el Apéndice AD se muestra un archivo de configuración completo para Samba. _________________________________________________________ 9.3.2.1. [global] - Búsqueda/Identificación [global] workgroup = GSRDOMAIN (1) netbios name = TODOSCSI (2) server string = SAMBA-LDAP PDC server (3) (1) Definición del nombre del dominio. (2) Nombre Netbios por el cual el servidor Samba se va a conocer. (3) Descripción del servidor. _________________________________________________________ 9.3.2.2. [global] - Autentificación security = user (1) encrypt passwords = true (2) passdb backend = ldapsam:ldap://gsr.pt (3) guest account = guest (4) invalid users = root (5) unix password sync = yes (6) passwd program = /usr/sbin/smbldap-passwd -o %u (7) passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\ spassword:* %n\n . (8) (1) Opción necesaria para la administración de dominios por parte de Samba. (2) Se activa el cifrado para el almacenado de las claves (3) Se asigna a esta opción el valor: "ldapsam:ldap://gsr.pt", indicándole a Samba que las claves se almacenarán y recuperarán del servidor LDAP definido. (4) Nombre del usuario "invitado", este podrá acceder a aquellos recursos con el parámetro "guest ok" sin autentificarse. (5) Lista de usuarios a los cuales no se le permite el acceso a Samba. (6) Se activa la sincronización entre las claves Unix y las claves Samba. (7) Programa utilizado durante el cambio de clave de un usuario. Vea el Apéndice H para saber como obtener esta herramienta. (8) Texto que se mostrará durante el cambio de una clave mediante Samba. _________________________________________________________ 9.3.2.3. [global] - LDAP ldap admin dn = cn=admin,dc=gsr,dc=pt (1) ; ldap server = gsr.pt (2) ; ldap port = 389 (3) ldap ssl = start_tls (4) ldap delete dn = no (5) ldap filter = (&(uid=%u)(objectclass=sambaSamAccount)) (6) ldap suffix = ou=people,dc=gsr,dc=pt (7) ldap user suffix = ou=people (8) ldap group suffix = ou=groups (9) ldap machine suffix = ou=machines (10) (1) Esta línea le dice a Samba quien es el administrador del directorio LDAP. Este será el usuario empleado por Samba cuando se realicen operaciones de añadir, borrar o modificar cuentas de usuario. (2) Parámetro que contiene el FQDN del servidor ldap. Se necesita para encontrar la información sobre las cuentas de usuario. Este parámetro se comenta, ya que parece que Samba no lo reconoce. (3) Indica en que puerto está escuchando LDAP. El puerto 389 es el puerto estándar para las conexiones sin cifrado; el 636 es el puerto estándar para las conexiones con cifrado. Si la línea "ldap ssl" posee el valor "on", Samba intentará automáticamente conectarse por el puerto 636 para contactar con el servidor LDAP. Este parámetro se comenta, ya que parece que Samba no lo reconoce. (4) Opción que determina si cifrar o no las comunicaciones entre el servidor Samba y el servidor LDAP. Se ha seleccionado la conexión por TLS, como ya viene siendo habitual a lo largo de toda la documentación. (5) Este parámetro especifica si al realizar una operación de borrado en ldapsam, se borra la entrada completa o solamente los atributos específicos de Samba. (6) Filtro de búsqueda para LDAP. (7) Parámetro que especifica la base para todas las búsquedas en LDAP. (8) Parámetro que indica donde se añaden los usuarios dentro del árbol. (9) Parámetro que indica donde se añaden los grupos de usuarios dentro del árbol. (10) Parámetro que indica donde se añaden las máquinas dentro del árbol. _________________________________________________________ 9.3.2.4. [global] - impresión load printers = yes (1) printing = cups (2) printcap name = cups (3) printer admin = @domainadmins (4) (1) Se cargan automáticamente la lista de impresoras disponibles. (2) (3) Estilo de impresión ha utilizar, en este caso se utilizará la impresión con CUPS (vea la Parte III en Integración de redes con OpenLDAP, Samba, CUPS y PyKota dedicada a CUPS.) (4) Grupo de usuarios que tienen permiso para añadir y configurar impresoras, a parte del usuario "root". _________________________________________________________ 9.3.2.5. [global] - Controlador de dominio os level = 80 (1) preferred master = yes (2) domain master = yes (3) local master = yes (4) domain logons = yes (5) logon path = \\%L\profiles\%u (6) logon drive = H: (7) logon home = \\%L\%u\.profile (8) logon script = (9) ; domain admin group = @domainadmins (10) (1) Parámetro que controla el nivel en el que Samba se anunciará como elección de búsqueda. El valor de este parámetro determinará si el demonio nmbd tendrá alguna posibilidad de llegar a ser un buscador primario local para el grupo de trabajo en el área de broadcast local. (2) (3) (4) (5) Estos parámetros juegan un papel fundamental asegurando el control del dominio y el soporte de autentificación en red. Una descripción más detallada de los mismos se encuentra en la página del manual smb.conf(5). (6) (7) (8) (9) Opciones que facilitan las operaciones de autentificado de clientes y facilitan el control automatizado para la administración de redes sobrecargadas. Más información en la página del manual smb.conf(5). (10) Parámetro que acepta usuarios y grupos de usuarios que serán administradores de dominio. Este parámetro se comenta, ya que parece que Samba no lo reconoce. _________________________________________________________ 9.3.2.6. [global] - Misceláneo socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 (1) idmap uid = 10000-20000 (2) idmap gid = 10000-20000 (3) template shell = /bin/bash (4) add user script = /usr/sbin/smbldap-useradd -w %u (5) (1) Distintas opciones que mejoran el rendimiento del servidor Samba. (2) (3) Estos dos parámetros especifican el rango de los ids de usuario y grupo, respectivamente, que serán utilizados en el mapeado de usuarios/grupos Unix en SIDs de usuarios/grupos NT. (4) Shell que el demonio winbindd añadirá a la información de un usuario, cuando este valor no sea omitido. (5) Se hace uso de las herramientas smbldap-tools para añadir maquinas (En el Apéndice H se muestra un ejemplo de instalación y configuración de estas herramientas). _________________________________________________________ 9.3.3. [homes] - directorios personales Esta sección permite la compartición del directorio home de los usuarios, de forma que, dependiendo que usuario se haya autentificado en el sistema, Samba compartirá su directorio personal únicamente a él. Los parámetros más importantes de esta sección se muestran a continuación: browseable = yes (1) writeable = yes (2) create mask = 0700 (3) directory mask = 0700 (4) (1) Indica si este recurso aparecerá en la lista de recursos compartidos o no. En este caso, si se mostrará. (2) Esta opción permite escribir datos en los directorios home, si su valor fuese "no", los directorios home se compartirían como sólo lectura. (3) Máscara de creación de archivos, el valor de este parámetro indicará los permisos que tendrán los archivos de nueva creación. (4) Máscara de creación de directorios, el valor de este parámetro indicará los permisos que tendrán los directorios de nueva creación. _________________________________________________________ 9.3.4. [netlogon] El recurso compartido NETLOGON juega un papel fundamental en el soporte de inicio de sesión en un dominio y Miembro de Dominio. Este recurso compartido se provee en todos los Controladores de Dominio de Microsoft. Se utiliza para proveer de scripts de inicio de sesión, para almacenar archivos de Políticas de Grupo (NTConfig.POL), así como la localización de otras herramientas comunes que se puedan necesitar para el proceso de inicio de sesión. Este es un recurso esencial en un Controlador de dominio. Los parámetros más importantes de esta sección se muestran a continuación: path = /home/samba/netlogon (1) writeable = no (2) write list = @domainadmins (3) (1) Directorio donde se van a alojar los scripts. (2) No se permite escribir en el recurso compartido, sólo lectura. (3) Lista de usuarios/grupos que tienen permiso de escritura en el recurso compartido. _________________________________________________________ 9.3.5. [profiles] - perfiles móviles Este recurso compartido se utiliza para almacenar los perfiles de escritorio de los usuarios. Cada usuario ha de tener un directorio en el raíz de este recurso compartido. Este recurso ha de tener permisos de escritura para los usuarios y debería tener la permisos de lectura globales. Samba-3 tiene un módulo VFS denominado "fake_permissions" (permisos "falsos") que se deberían instalar en este recurso. Este módulo permitiría a un administrador de Samba hacer el directorio de sólo lectura para todo el mundo. Por supuesto, esto sólo es útil una vez se ha creado correctamente el perfil. Los parámetros más importantes de esta sección se muestran a continuación: path = /home/samba/profiles (1) writeable = yes (2) browseable = no (3) create mask = 0600 (4) directory mask = 0700 (5) (1) Directorio donde se almacenarán los perfiles móviles, bajo este directorio, cada usuario tendrá una carpeta con su nombre. (2) Se permite escribir en el recurso compartido. (3) Indica si este recurso aparecerá en la lista de recursos compartidos o no. En este caso, no se mostrará. (4) Máscara de creación de archivos, el valor de este parámetro indicará los permisos que tendrán los archivos de nueva creación. (5) Máscara de creación de directorios, el valor de este parámetro indicará los permisos que tendrán los directorios de nueva creación. _________________________________________________________ 9.3.6. [printers] - impresoras Este es un recurso compartido especial que crea automáticamente servicios de impresión. La forma en que trabaja es la siguiente: si se crea un recurso compartido con el nombre [printers] en el archivo de configuración, Samba leerá automáticamente el archivo de definición de sus impresoras y creará una impresora compartida para cada impresora que aparezca en el archivo. Por ejemplo, si posee tres impresoras definidas: una lp otra pcl y una última ps, Samba proveerá tres impresoras compartidas con esos nombres, cada una configurada con las opciones que aparezcan en el recurso compartido [printers]. Los parámetros más importantes de esta sección se muestran a continuación: browseable = no (1) path = /tmp (2) printable = yes (3) guest ok = no (4) writable = no (5) create mask = 0700 (6) (1) Indica si este recurso aparecerá en la lista de recursos compartidos o no. En este caso, no se mostrará. (2) Directorio que utilizará Samba como cola de impresión. (3) Como este parámetro tiene el valor yes, los clientes que se conecten al servidor, podrán abrir, escribir en y enviar archivos a la cola de impresión, es decir, al directorio especificado por la variable path. (4) No se permitirán las conexiones sin autentificación a este recurso. (5) No se permite escribir en el recurso compartido. (6) Máscara de creación de archivos, el valor de este parámetro indicará los permisos que tendrán los archivos de nueva creación. _________________________________________________________ 9.3.7. [print$] - controladores de impresión Al igual que un servidor de impresión Windows NT, para soportar la descarga de controladores por parte de clientes con distintas arquitecturas, se han de crear varios subdirectorios dentro del servicio [print$]. Estos se corresponderán con cada una de las arquitecturas soportadas. Samba también sigue este esquema. Así como el nombre del recurso compartido ha de ser [print$], los subdirectorios han de ser exactamente los nombres que se listan a continuación (puede obviar aquellos subdirectorios para las arquitecturas que no necesite soporte). Por lo tanto, se ha de crear la estructura de directorios que se muestra a continuación, bajo el directorio compartido por [print$]. Cree aquellos directorios para aquellas arquitecturas que quiera dar soporte: Ejemplo 9-3. [print$] - Subdirectorios para las distintas arquitecturas [print$]--+ |--W32X86 # controladores para Windows NT x86 |--WIN40 # controladores para Windows 95/98 |--W32ALPHA # controladores para Windows NT Alpha_AXP |--W32MIPS # controladores para Windows NT R4000 Nota El paquete "samba" de Debian GNU/Linux crea esta estructura de directorios bajo /var/lib/samba/printers. Los parámetros más importantes de esta sección se muestran a continuación: path = /var/lib/samba/printers (1) browseable = yes (2) writeable = no (3) guest ok = no (4) write list = root, @domainadmins (5) (1) Directorio donde se almacenarán los controladores de impresión para las distintas arquitecturas. (2) Indica si este recurso aparecerá en la lista de recursos compartidos o no. En este caso, si se mostrará. (3) No se permite escribir en el recurso compartido. (4) No se permitirán las conexiones sin autentificación a este recurso. (5) Lista de usuarios/grupos que tienen permiso de escritura en el recurso compartido. _________________________________________________________ 9.3.8. [tmp] - Directorio temporal A modo de ejemplo, se va a compartir el directorio temporal /tmp con los siguientes parámetros: comment = Temporal (1) writeable = yes (2) path = /tmp (3) guest ok = no (4) (1) Comentario del recurso compartido. (2) Se permite la escritura en este recurso. (3) Directorio compartido dentro del sistema. (4) No se permiten conexiones anónimas al directorio, todo usuario ha de autentificarse para acceder a este recurso. _________________________________________________________ 9.3.9. [cdrom] - CDROM Otro ejemplo de compartición será el CDROM del sistema. Los parámetros empleados en esta ocasión serán: comment = Samba server's CD-ROM (1) writable = no (2) locking = no (3) path = /cdrom (4) guest ok = yes (5) (1) Comentario del recurso compartido. (2) No se permite la escritura en este recurso compartido. (3) No se bloquearán realmente los archivos a petición de los clientes, simplemente se informará de que el bloqueo ha sido efectivo. (4) Ruta hacia el recurso compartido. (5) Se permitirá el acceso a este recurso a los usuarios invitados, es decir, aquellos usuarios que no se han autentificado. Sugerencia Normalmente, para acceder al contenido de un CDROM es necesario montarlo primero. Por lo que se recomienda instalar el parche supermount en el núcleo Linux, de forma que el montado y desmontado del CDROM sea transparente al usuario. Cuando se intenta acceder al recurso, el CDROM se montará automáticamente. Una vez aplicado el parche en el núcleo y seleccionado para la compilación, se ha de modificar la entrada para el CDROM dentro del archivo /etc/fstab, de forma que quede algo similar a: none /cdrom supermount dev=/dev/cdrom,fs=auto,ro,auto,u ser,exec 0 0 _________________________________________________________ Capítulo 10. Ajustes finales en el sistema 10.1. Introducción Antes de considerar Samba completamente instalado y configurado, se han de realizar una serie de modificaciones en el sistema, y estas modificaciones se abarcan en este capítulo. _________________________________________________________ 10.2. Estableciendo la clave del administrador de LDAP Samba necesita conocer la clave del administrador del directorio LDAP para poder acceder al mismo. Por este motivo es necesario indicársela, para ello ejecute: Ejemplo 10-1. Especificando la clave del administrador de LDAP en Samba En la captura de pantalla que se muestra a continuación, sustituya la palabra "clave" por la clave del administrador del servidor LDAP: # /usr/bin/smbpasswd -w clave Setting stored password for "cn=admin,dc=gsr,dc=pt" in secrets.tdb Aviso Si varía el valor de la opción "ldap admin dn" del archivo de configuración de Samba, la clave del administrador del directorio LDAP ha de resetearse, ejecutando de nuevo la orden presente en el Ejemplo 10-1. _________________________________________________________ 10.3. Nueva regla de control de acceso en /etc/ldap/slapd.conf Debido a que a partir de ahora se almacenarán las claves relacionadas con Samba en el directorio LDAP, se añade en el archivo /etc/ldap/slapd.conf una nueva regla de control de acceso que impida, a todos aquellos usuarios distintos del administrador de LDAP, el acceso a los "hashes" de las distintas claves allí almacenadas. Las líneas que se han de añadir al archivo son: # allow the "ldap admin dn" access, but deny everyone else # (Samba related) access to attribute=sambaLMPassword,sambaNTPassword by dn="cn=admin,dc=gsr,dc=pt" write by dn="cn=readadmin,dc=gsr,dc=pt" read by * none Para que la nueva configuración tenga efecto, ha de reiniciar el demonio slapd, en el Ejemplo 3-7 se muestra como hacerlo. _________________________________________________________ 10.4. Especificación de nuevos índices en /etc/ldap/slapd.conf Con el objetivo de mejorar el rendimiento de las búsquedas dentro del directorio LDAP, se van a añadir una serie de índices al archivo de configuración del demonio slapd. Los índices que se presentan a continuación, incrementan la velocidad en las búsquedas realizadas sobre la clases objeto sambaSamAccount, y posiblemente también sobre las clases objeto posixAccount y posixGroup. # Requerido por OpenLDAP index objectclass eq index default sub index cn pres,sub,eq index sn pres,sub,eq index mail eq,subinitial index givenname eq,subinitial # Requerido para soportar pdb_getsampwnam index uid pres,sub,eq # Requerido para soportar pdb_getsambapwrid() index displayName pres,sub,eq # Descomente las siguientes líneas si está almacenando entradas # posixAccount y posixGroup en el directorio index uidNumber eq index gidNumber eq index memberUid eq # Samba 3.* index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq Una vez realizados los cambios en el archivo /etc/ldap/slapd.conf se han de regenerar los índices, para ello ejecute: Ejemplo 10-2. Regenerando los índices de slapd # /usr/sbin/slapindex -vf /etc/ldap/slapd.conf indexing id=00000001 indexing id=00000002 indexing id=0000000a indexing id=0000000b indexing id=0000000c Ahora sólo queda reiniciar el servidor slapd: Ejemplo 10-3. Reiniciando el servidor slapd # /etc/init.d/slapd restart Stopping OpenLDAP: slapd. Starting OpenLDAP: slapd. _________________________________________________________ 10.5. Creando la estructura de directorios en el home En el Capítulo 9 se han definido una serie de directorios dedicados a distintas tareas dentro de Samba, como pueden ser alojar los perfiles móviles de los usuarios, los scripts para Netlogon o el directorio home de los usuarios. En esta sección se van a crear los anteriores directorios para preparar el sistema para alojar usuarios: Ejemplo 10-4. Creación de los directorios necesarios para Samba # mkdir -vpm 755 /home/samba/ mkdir: se ha creado el directorio `/home/samba' # mkdir -vpm 755 /home/samba/netlogon /home/samba/users mkdir: se ha creado el directorio `/home/samba/netlogon' mkdir: se ha creado el directorio `/home/samba/users' # /bin/chgrp -v domainadmins /home/samba/netlogon/ (1) cambiado el grupo de `netlogon/' a domainadmins # mkdir -vpm 1757 /home/samba/profiles mkdir: se ha creado el directorio `/home/samba/profiles' (1) El grupo domainadmins se crea en el proceso de configuración de la herramienta LDAP Account Manager (vea el Apéndice F, concretamente la imagen Figura F-24). _________________________________________________________ Capítulo 11. Comprobando que todo funciona 11.1. Introducción En esta sección se va a comprobar que todo lo que se ha realizado hasta ahora funciona; esto significa añadir usuarios al directorio LDAP y comprobar que tanto desde Samba como desde el propio sistema se puede hacer uso de dichos usuarios. La administración de usuarios se va a realizar con el programa LDAP Account Manager. El proceso de instalación se encuentra en el Apéndice F. Otro de los programas empleados en la administración de LDAP es: phpLDAPadmin. El Apéndice G muestra la manera de instalarlo y configurarlo. Para finalizar, son necesarias las herramientas smbldap-tools, ya que internamente Samba hace uso de ellas, como se ha definido en algunas partes de su configuración (vea las secciones: Sección 9.3.2.2 y Sección 9.3.2.6 para más detalles). El Apéndice H muestra el proceso de instalación y configuración de este conjunto de herramientas. Importante Se recomienda seguir el siguiente orden de instalación de las herramientas anteriormente expuestas: 1º LDAP Account Manager, 2º phpLDAPadmin y 3º smbldap-tools. _________________________________________________________ 11.2. Verificación del archivo de configuración y reinicio de los demonios En el capítulo Capítulo 9 se mostró la forma de configurar un servidor Samba. El resultado de esa configuración ha sido el archivo disponible en el Apéndice AD. En estos momentos, sólo queda comprobar si dicho archivo está bien, para ello se hará uso del programa testparm, como se muestra en el siguiente ejemplo: Ejemplo 11-1. Comprobando la nueva configuración (soporte LDAP) # /usr/bin/testparm Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[netlogon]" Processing section "[profiles]" Processing section "[printers]" Processing section "[print$]" Processing section "[tmp]" Processing section "[cdrom]" Loaded services file OK. Server role: ROLE_DOMAIN_PDC Press enter to see a dump of your service definitions [ENTER] # Global parameters [global] workgroup = GSRDOMAIN server string = SAMBA-LDAP PDC server obey pam restrictions = Yes passdb backend = ldapsam:ldap://gsr.pt guest account = guest passwd program = /usr/sbin/smbldap-passwd -o %u passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\s UNIX\spassword:* %n\n . unix password sync = Yes syslog = 0 log file = /var/log/samba/log.%m max log size = 1000 name resolve order = lmhosts host wins bcast socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 add user script = /usr/sbin/smbldap-useradd.pl -w %u logon path = \\%L\profiles\%u logon drive = H: logon home = \\%L\%u\.profile domain logons = Yes os level = 80 preferred master = Yes domain master = Yes dns proxy = No ldap admin dn = cn=admin,dc=gsr,dc=pt ldap group suffix = ou=groups ldap machine suffix = ou=machines ldap suffix = dc=gsr,dc=pt ldap user suffix = ou=people panic action = /usr/share/samba/panic-action %d idmap uid = 10000-20000 idmap gid = 10000-20000 template shell = /bin/bash printer admin = @domainadmins [homes] comment = Home Directories read only = No create mask = 0700 directory mask = 0700 browseable = No [netlogon] comment = Network Logon Service path = /home/samba/netlogon write list = @domainadmins guest ok = Yes share modes = No [profiles] comment = User's Profiles path = /home/samba/profiles read only = No create mask = 0600 directory mask = 0700 guest ok = Yes browseable = No [printers] comment = All Printers path = /tmp printable = Yes browseable = No [print$] comment = Printer Drivers path = /var/lib/samba/printers write list = root, @domainadmins [tmp] comment = Temporal path = /tmp read only = No [cdrom] comment = Samba server's CD-ROM path = /cdrom guest ok = Yes locking = No Una vez el archivo de configuración está listo y libre de posibles errores, el servidor Samba ha de releer su configuración. La forma de hacer esto se muestra en el Ejemplo 11-2. Ejemplo 11-2. Releyendo la configuración de Samba # /etc/init.d/samba reload Reloading /etc/samba/smb.conf (smbd only). Aunque con releer la configuración de Samba es suficiente para que tengan efecto los cambios introducidos en el mismo, se van a reiniciar los demonios de Samba y ver que muestran los archivos de log de los mismos. Esta última parte se muestra en el Ejemplo 11-3. Ejemplo 11-3. Reinicio los demonios de Samba # /etc/init.d/samba restart Stopping Samba daemons: nmbd smbd. Starting Samba daemons: nmbd smbd. Tras el reinicio de los demonios de samba, se echa un vistazo en los archivos de log siguientes: /var/log/samba/log.nmbd y /var/log/samba/log.smbd. El resultado es el siguiente: * Archivo /var/log/samba/log.nmbd [2004/10/03 13:15:26, 0] nmbd/nmbd.c:terminate(54) Got SIGTERM: going down... [2004/10/03 13:15:30, 0] nmbd/nmbd.c:main(664) Netbios nameserver version 3.0.7-Debian started. Copyright Andrew Tridgell and the Samba Team 1994-2004 [2004/10/03 13:15:30, 0] nmbd/nmbd_logonnames.c:add_logon_names(163) add_domain_logon_names: Attempting to become logon server for workgroup GSRDOMAIN on subnet 1 92.168.3.3 [2004/10/03 13:15:30, 0] nmbd/nmbd_become_dmb.c:become_domain_master_br owser_bcast(282) become_domain_master_browser_bcast: Attempting to become domain master browser on workgroup GSRDOMAIN on subnet 192.168.3.3 [2004/10/03 13:15:30, 0] nmbd/nmbd_become_dmb.c:become_domain_master_br owser_bcast(295) become_domain_master_browser_bcast: querying subnet 192.168.3.3 for d omain master browser on workgroup GSRDOMAIN [2004/10/03 13:15:34, 0] nmbd/nmbd_logonnames.c:become_logon_server_suc cess(124) become_logon_server_success: Samba is now a logon server for workgrou p GSRDOMAIN on subnet 192.168.3.3 [2004/10/03 13:15:38, 0] nmbd/nmbd_become_dmb.c:become_domain_master_st age2(113) ***** Samba server TODOSCSI is now a domain master browser for workgroup GS RDOMAIN on subnet 192.168.3.3 ***** [2004/10/03 13:15:53, 0] nmbd/nmbd_become_lmb.c:become_local_master_sta ge2(396) ***** Samba name server TODOSCSI is now a local master browser for workgrou p GSRDOMAIN on subnet 192.168.3.3 ***** Se puede comprobar que Samba se ha convertido en un controlador de dominio bajo al subred 192.168.3.3. El dominio que está administrando es GSRDOMAIN. * Archivo /var/log/samba/log.smbd [2004/10/03 13:15:30, 0] smbd/server.c:main(760) smbd version 3.0.7-Debian started. Copyright Andrew Tridgell and the Samba Team 1992-2004 [2004/10/03 13:15:30, 0] printing/print_cups.c:cups_printer_fn(119) Unable to connect to CUPS server localhost - Conexión rehusada Como en estos momentos no se ha instalado el servidor de impresión CUPS, Samba no puede contactar con él. Vea la Parte III en Integración de redes con OpenLDAP, Samba, CUPS y PyKota dedicada a CUPS para obtener más información sobre como instalarlo y configurarlo. _________________________________________________________ 11.3. Adición de un usuario al sistema Como se ha comentado anteriormente, se va a emplear la herramienta LDAP Account Manager para la gestión de usuarios. Las capturas de pantalla que se muestran a continuación mostrarán los pasos que hay que seguir para añadir un usuario al sistema: Figura 11-1. URL donde está instalado LAM [lam-configuracion1.png] Si se encuentra en un entorno de escritorio con KDE, teclee Alt+F2 e introduzca la dirección donde se encuentre instalado LAM. Figura 11-2. Aviso acerca del certificado del servidor web I [lam-configuracion-certificado1.png] Si ha configurado correctamente el servidor web, a la hora de acceder a la aplicación LAM por el protocolo http, Apache le tendría que redireccionar a la misma dirección, pero bajo el protocolo https (más información en: Sección I.1 y Sección F.2.1) Esto es lo que ha ocurrido en esta pantalla, Apache ha redirigido la petición realizada (http://gsr.pt/lam/) hacia el protocolo https. Por este motivo, y debido a que la entidad certificadora que se ha creado es desconocida, sale este aviso. Pulse sobre el botón Detalles para obtener más información. Figura 11-3. Información SSL [lam-configuracion-certificado2.png] En esta pantalla se muestra la información del certificado y la entidad certificadora que ha creado dicho certificado. Si se fija, aquí aparecerán los datos tecleados en el Apéndice I. Pulse sobre el botón Cerrar para continuar. Figura 11-4. Aviso acerca del certificado del servidor web II [lam-configuracion-certificado3.png] Pulse ahora sobre el botón Continuar para seguir con la carga de la página. Figura 11-5. Período de aceptación del certificado [lam-configuracion-certificado4.png] Seleccione la opción deseada y pulse sobre ella. Figura 11-6. Ingreso en LAM [lam-configuracion11.png] Si no está seleccionado, elija el perfil GSR y pulse sobre: Change Profile. Una vez seleccionado el perfil adecuado, se ha de teclear la clave del administrador del directorio LDAP y pulsar sobre Login. Figura 11-7. Edición de perfiles [lam-configuracion12.png] La sección predeterminada, tras el ingreso en la herramienta, es la gestión de usuarios. Antes de añadir usuarios, se creará un nuevo perfil de usuarios, personalizado para el sistema de ejemplo. Para proceder a la edición de perfiles, se ha de pulsar sobre el enlace Profile Editor. Figura 11-8. Edición de un perfil de usuario [lam-adduser1.png] En el cuadro de User Profiles se selecciona la opción Create a new User Profile y se pulsa sobre el botón Submit. Figura 11-9. Opciones de las cuentas (primera parte) [lam-adduser2.png] El cuadro destinado a las cuentas Unix (Unix account) permite configurar una serie de opciones comunes a todos los usuarios, como son: * Primary group: selección del grupo principal de los usuarios, por defecto será el grupo domainusers. * Additional groups: selección del grupo o grupos adicionales para los usuarios, a mayores se seleccionará el grupo domainguest. * Home Directory: localización del home de los usuarios. La ruta donde se establecerán los archivos personales de cada usuario será: /home/samba/users/$user, donde la variable $user se sustituirá por el nombre del usuario a la hora de su creación. * Login shell: se establece la shell bash como shell por defecto para los usuarios. * Account expires on: se establece la fecha en la cual la cuenta va a caducar. Se ha fijado en el máximo disponible por la aplicación. Figura 11-10. Opciones de las cuentas (segunda parte) [lam-adduser3.png] En el cuadro destinado a las cuentas de Samba (Samba account) especifique la ruta al directorio home (\\todoscsi\$user) y la ruta al directorio para los perfiles móviles de los usuarios (\\todoscsi\profiles\$user). Al igual que en las cuentas Unix, la variables $user se sustituirá por el nombre del usuario a la hora de crear una nueva cuenta. El campo Profile name se rellena con el nombre del perfil que se quiere crear, en este caso: GSR. Para continuar, pulse sobre el botón Save. Figura 11-11. Perfil guardado [lam-adduser4.png] Esta pantalla informa de que el perfil GSR se ha guardado correctamente. Se pulsa sobre el enlace Users para proceder a la adición de un nuevo usuario. Figura 11-12. Creación de un nuevo usuario [lam-configuracion12.png] Se pulsa sobre el botón: New user para comenzar el proceso de creación de un nuevo usuario. Figura 11-13. Selección del perfil [lam-adduser5.png] Antes de comenzar a completar los campos con los datos del nuevo usuario, se ha de seleccionar el perfil anteriormente creado, GSR. Una vez seleccionado, se pulsa sobre el botón: Load Profile. Figura 11-14. Datos generales [lam-adduser6.png] Con el perfil GSR cargado, sólo se han de completar los campos: Username con el nombre que va a tener el usuario en el sistema, First name con el nombre real del usuario, Last name con el primer apellido del usuario y, opcionalmente, el campo Gecos con una descripción del usuario. Para continuar, se ha de pulsar sobre el botón Unix. Figura 11-15. Datos generales, completado automático de información [lam-adduser7.png] Antes de acceder a la información sobre Unix, la aplicación completa automáticamente el campo UID number y sustituye las variables $group y $user por sus valores reales en el campo Home directory. Pulsando en este momento, nuevamente, sobre el botón Unix se accederá a la información sobre Unix para el usuario. Figura 11-16. Propiedades sobre Unix [lam-adduser8.png] En esta pantalla se completa la clave que tendrá el usuario, campos Password y Repeat password. Seguidamente pulse sobre el botón: Samba. Figura 11-17. Propiedades sobre Samba (primera parte) [lam-adduser9.png] En esta pantalla se completa el campo Display name, de forma que ilustre quien es el usuario de la cuenta. Una vez realizado esto, pulse sobre el botón Personal. Figura 11-18. Propiedades sobre Samba (segunda parte) [lam-adduser10.png] Antes de acceder a la información personal, la aplicación sustituye las variables $group y $user por sus valores reales en los campos Home path y Profile path. Vuelva a pulsar sobre el botón Personal. Figura 11-19. Propiedades personales [lam-adduser11.png] En esta pantalla no se completa ningún campo, de todas formas es libre de seleccionar aquellos campos que quiera completar. Se pulsa sobre el botón Final para continuar. Figura 11-20. Creación del usuario [lam-adduser12.png] Para completar la creación del usuario, se ha de pulsar sobre el botón Create Account. Figura 11-21. Usuario creado [lam-adduser13.png] Esta pantalla indica que el usuario se ha creado satisfactoriamente, se va a comprobar accediendo a la lista de usuarios, para ello pulse sobre el botón Back to user list. Figura 11-22. Lista de usuarios [lam-adduser14.png] Se puede comprobar en esta pantalla que el usuario gsruser ya se encuentra en el directorio LDAP. _________________________________________________________ 11.4. Acceso con la nueva cuenta en un sistema Unix A continuación se va a probar el acceso por ssh, con el nuevo usuario, a una shell de Unix. Para ello se tecleará: Ejemplo 11-4. Acceso a una shell Unix por ssh $ /usr/bin/ssh -l gsruser gsr.pt password: [clave] Creating directory '/home/samba/users/gsruser'. (1) Creating directory '/home/samba/users/gsruser/Maildir'. Creating directory '/home/samba/users/gsruser/Maildir/cur'. Creating directory '/home/samba/users/gsruser/Maildir/new'. Creating directory '/home/samba/users/gsruser/Maildir/tmp'. todoscsi-[gsruser]-13:39:04:~$ (1) Gracias a la opción comentada en el Ejemplo 5-12, al entrar por primera vez con la cuenta gsruser y no tener creado el directorio home para este usuario, el módulo pam_mkhomedir se encarga de crearlo, copiando el contenido del directorio /etc/skel al recién creado home. _________________________________________________________ 11.5. Acceso con la nueva cuenta a Samba Por último, se va a verificar el acceso a los recursos compartidos mediante Samba. Para ello se va a utilizar la orden smbclient y el navegador Konqueror, para ver dos formas de acceso a los recursos. _________________________________________________________ 11.5.1. Uso de smbclient smbclient es un cliente parecido al cliente ftp, que permite el acceso a los recursos compartidos de un servidor mediante SMB/CIFS. En primer lugar se listarán los recursos que tiene compartido un determinado servidor, para ello se ha de teclear: Ejemplo 11-5. Mostrando los recursos compartidos con smbclient $ /usr/bin/smbclient -L TODOSCSI --user=gsruser Password: [clave] Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] Sharename Type Comment --------- ---- ------- netlogon Disk Network Logon Service print$ Disk Printer Drivers tmp Disk Temporal cdrom Disk Samba server's CD-ROM IPC$ IPC IPC Service (SAMBA-LDAP PDC server) ADMIN$ IPC IPC Service (SAMBA-LDAP PDC server) gsruser Disk Home Directories Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] Server Comment --------- ------- TODOSCSI SAMBA-LDAP PDC server Workgroup Master --------- ------- GSRDOMAIN TODOSCSI El ejemplo anterior muestra los recursos compartidos que posee el servidor TODOSCSI. A continuación se va a acceder a uno de estos recursos para listar su contenido y realizar algunas operaciones dentro del mismo: Ejemplo 11-6. Accediendo a un recurso compartido con smbclient $ /bin/ls -la total 56 drwxr-xr-x 3 gsruser domainusers 408 2004-10-09 13:38 . drwxr-sr-x 3 root staff 72 2004-10-09 13:38 .. -rw-r--r-- 1 gsruser domainusers 1363 2004-10-09 13:38 .bash_aliases -rw-r--r-- 1 gsruser domainusers 337 2004-10-09 13:38 .bash_logout -rw-r--r-- 1 gsruser domainusers 239 2004-10-09 13:38 .bash_profile -rw-r--r-- 1 gsruser domainusers 6198 2004-10-09 13:38 .bashrc -rw-r--r-- 1 gsruser domainusers 45 2004-10-09 13:38 .cvsrc -rw-r--r-- 1 gsruser domainusers 618 2004-10-09 13:38 .dir_colors -rw-r--r-- 1 gsruser domainusers 357 2004-10-09 13:38 .ldaprc drwxr-xr-x 5 gsruser domainusers 120 2004-10-09 13:38 Maildir -rw-r--r-- 1 gsruser domainusers 4267 2004-10-09 13:38 .muttrc -rw-r--r-- 1 gsruser domainusers 105 2004-10-09 13:38 .procmailrc -rw-r--r-- 1 gsruser domainusers 87 2004-10-09 13:38 .screenrc -rw-r--r-- 1 gsruser domainusers 287 2004-10-09 13:38 .tidyrc -rw-r--r-- 1 gsruser domainusers 2686 2004-10-09 13:38 .vimrc $ /usr/bin/smbclient --user=gsruser //todoscsi/gsruser Password: [clave] Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] smb: \> ls . D 0 Sat Oct 9 13:38:52 2 004 .. D 0 Sat Oct 9 13:38:52 2 004 .bashrc H 6198 Sat Oct 9 13:38:52 2 004 .ldaprc H 357 Sat Oct 9 13:38:52 2 004 .bash_logout H 337 Sat Oct 9 13:38:52 2 004 .muttrc H 4267 Sat Oct 9 13:38:52 2 004 .dir_colors H 618 Sat Oct 9 13:38:52 2 004 .tidyrc H 287 Sat Oct 9 13:38:52 2 004 .procmailrc H 105 Sat Oct 9 13:38:52 2 004 .bash_aliases H 1363 Sat Oct 9 13:38:52 2 004 Maildir D 0 Sat Oct 9 13:38:52 2 004 .cvsrc H 45 Sat Oct 9 13:38:52 2 004 .vimrc H 2686 Sat Oct 9 13:38:52 2 004 .screenrc H 87 Sat Oct 9 13:38:52 2 004 .bash_profile H 239 Sat Oct 9 13:38:52 2 004 43910 blocks of size 524288. 1201 blocks available smb: \> mkdir directorio-de-ejemplo smb: \> ls . D 0 Sat Oct 9 13:45:39 2 004 .. D 0 Sat Oct 9 13:38:52 2 004 .bashrc H 6198 Sat Oct 9 13:38:52 2 004 .ldaprc H 357 Sat Oct 9 13:38:52 2 004 directorio-de-ejemplo D 0 Sat Oct 9 13:45:39 2 004 .bash_logout H 337 Sat Oct 9 13:38:52 2 004 .muttrc H 4267 Sat Oct 9 13:38:52 2 004 .dir_colors H 618 Sat Oct 9 13:38:52 2 004 .tidyrc H 287 Sat Oct 9 13:38:52 2 004 .procmailrc H 105 Sat Oct 9 13:38:52 2 004 .bash_aliases H 1363 Sat Oct 9 13:38:52 2 004 Maildir D 0 Sat Oct 9 13:38:52 2 004 .cvsrc H 45 Sat Oct 9 13:38:52 2 004 .vimrc H 2686 Sat Oct 9 13:38:52 2 004 .screenrc H 87 Sat Oct 9 13:38:52 2 004 .bash_profile H 239 Sat Oct 9 13:38:52 2 004 43910 blocks of size 524288. 1201 blocks available smb: \> exit ~$ /bin/ls -la total 56 drwxr-xr-x 3 gsruser domainusers 336 2004-06-01 12:27 ./ drwxr-xr-x 3 root root 72 2004-05-31 02:46 ../ -rw-r--r-- 1 gsruser domainusers 1,4K 2004-05-31 02:46 .bash_al iases -rw-r--r-- 1 gsruser domainusers 337 2004-05-31 02:46 .bash_lo gout -rw-r--r-- 1 gsruser domainusers 239 2004-05-31 02:46 .bash_pr ofile -rw-r--r-- 1 gsruser domainusers 6,3K 2004-05-31 02:46 .bashrc -rw-r--r-- 1 gsruser domainusers 45 2004-05-31 02:46 .cvsrc -rw-r--r-- 1 gsruser domainusers 618 2004-05-31 02:46 .dir_col ors drwx------ 2 gsruser domainusers 48 2004-06-01 12:27 director io-de-ejemplo/ -rw-r--r-- 1 gsruser domainusers 4,3K 2004-05-31 02:46 .muttrc -rw-r--r-- 1 gsruser domainusers 287 2004-05-31 02:46 .tidyrc -rw-r--r-- 1 gsruser domainusers 2,7K 2004-05-31 02:46 .vimrc $ /bin/rmdir -v directorio-de-ejemplo rmdir: borrando el directorio, directorio-de-ejemplo/ _________________________________________________________ 11.5.2. Uso de konqueror En esta sección se verá la forma de acceso a los recursos compartidos mediante Samba con konqueror. Las siguientes capturas de pantalla muestran los pasos para conseguirlo: Figura 11-23. Dirección de acceso a los recursos de Samba [samba-acceso1.png] Konqueror permite el acceso a los recursos compartidos desde un servidor samba; para ello hay que teclear direcciones del tipo: smb://usuario@SERVIDOR-SAMBA/. En este caso, se va a acceder al servidor "TODOSCSI" con el usuario "gsruser". Figura 11-24. Clave del usuario gsruser [samba-acceso2.png] En esta pantalla se ha de teclear la clave para el usuario gsruser. Figura 11-25. Recursos compartidos [samba-acceso3.png] En esta pantalla se muestran los recursos compartidos. El directorio gsruser se corresponde con el directorio Home del usuario gsruser. _________________________________________________________ Capítulo 12. Añadiendo clientes al dominio 12.1. Introducción Este capítulo se ha realizado gracias a las entradas bibliográficas: Syroid02 y Milne02. En la elaboración de esta documentación no se ha tenido acceso a ningún cliente Windows para la realización de pruebas, por lo tanto, todo lo que se expone en este capítulo es teórico. _________________________________________________________ 12.2. Windows 95/98/ME Los clientes Windows 9x no tienen implementada completamente la función de miembro de dominio, por este motivo es fácil unirlos a un dominio. Los pasos que se han de seguir para añadir a un cliente de este tipo a un dominio son: 1. Primero se ha de comprobar que el Cliente para Redes Microsoft está instalado; si no lo está, instálelo (Panel de Control -> Red -> Cliente para Redes Microsoft). Para instalarlo, coloque el CD de Windows en la unidad de CDROM y seleccione Añadir desde el antes mencionado cuadro de diálogo, luego: Cliente -> Añadir... -> Microsoft -> Cliente para Redes Microsoft. 2. Asegúrese de que el Cliente para Redes Microsoft es el protocolo de red primario (Panel de Control -> Red -> Autentificación de Red Primaria). 3. El siguiente paso es: Panel de Control -> Red -> Cliente para Redes Microsoft -> Propiedades -> Autentificarse en un Dominio NT. 4. Si ha hecho uso de la opción add user script en el archivo de configuración de Samba, seleccione el checkbox Crear una Cuenta de Máquina en el Dominio; Si no ha sido así, se ha de asegurar que la cuenta de la máquina existe para el cliente. 5. Complete el dominio y pulse sobre Aceptar _________________________________________________________ 12.3. Windows NT Los clientes Windows NT tienen una implementación completa de dominio, y mejor seguridad por defecto. Cada máquina posee su propia clave, que controla que máquina puede autentificarse desde el dominio. Todas estas máquinas necesitan su propia entrada en el archivo "smbpassswd" (o en el directorio LDAP). Hay que diferenciar entre cuentas de usuario y de máquina: las cuentas de máquina son diferentes a las de usuario por terminar en el símbolo $. Para los clientes Windows NT puede crear estas cuentas manualmente. Vea el Sección 12.4 para saber como hacer esto más sencillamente. _________________________________________________________ 12.3.1. Creación de cuentas para las máquinas La forma de añadir cuentas de máquina en Samba se detalla en las siguientes capturas de pantalla: Figura 12-1. Acceso a la herramienta LDAP Account Manager [lam-configuracion1.png] Si se encuentra en un entorno de escritorio con KDE, teclee Alt+F2 e introduzca la dirección donde se encuentre instalado LAM. Figura 12-2. Ingreso en LAM [lam-configuracion11.png] Si en estos momentos no tiene un perfil creado para LAM, vea el Apéndice F para saber como hacerlo. Una vez creado el perfil personalizado, seleccionelo y pulse sobre Change Profile. Una vez seleccionado el perfil adecuado, se ha de teclear la clave del administrador del directorio LDAP y pulsar sobre Login. Figura 12-3. Sección Hosts [lam-adduser14.png] Tras el ingreso en la herramienta, se ha de pulsar sobre el enlace Hosts para proceder con la adición de una cuenta de máquina. Figura 12-4. Crear nueva máquina [samba-aniadir-maquina1.png] Cuando se ha cargado la sección de hosts, se pulsa sobre el botón New Host para comenzar el proceso. Figura 12-5. Completado de los campos [samba-aniadir-maquina2.png] En esta pantalla se completan los campos Host name y Gecos con el nombre de la máquina y una descripción de la misma, respectivamente. Una vez realizado esto, se pulsa sobre el botón Create Account. Figura 12-6. Corrección de los "errores" cometidos [samba-aniadir-maquina3.png] Antes de la creación de la cuenta, LAM detecta y trata de corregir los posibles errores cometidos. En este caso no se ha tecleado el nombre del host de forma correcta, pues tiene que terminar en el signo $ (LAM lo ha introducido automáticamente) y se ha dejado en blanco el campo UID number, el cual rellena LAM de forma automática. Se vuelve a pulsar sobre el botón Create Account para finalizar la creación de la cuenta. Figura 12-7. Cuenta creada [samba-aniadir-maquina4.png] LAM informa de la creación de la cuenta para la máquina y propone una serie de acciones. Pulse sobre el botón Back to hosts list. Figura 12-8. Lista de Hosts [samba-aniadir-maquina5.png] Ahora aparece, en la lista de hosts, la nueva cuenta creada. _________________________________________________________ 12.3.2. Uniendo un cliente Windows NT a un dominio Los pasos que se muestran a continuación son los que se han de seguir para añadir un cliente Windows NT a un dominio: Figura 12-9. "Inicio" [samba-aniadir-winnt1.png] Se comienza el proceso con la pulsación sobre el botón "Inicio". Figura 12-10. "Configuración" [samba-aniadir-winnt2.png] Se selecciona el menú "Configuración". Figura 12-11. "Panel de Control" [samba-aniadir-winnt3.png] Luego la opción "Panel de Control". Figura 12-12. "Red" [samba-aniadir-winnt4.png] Abierta la ventana del Panel de Control, se hace doble clic sobre el icono de "Red". Figura 12-13. Cuadro de diálogo "Red" [samba-aniadir-winnt5.png] Se pulsa sobre el botón "Cambiar..." que aparece en el cuadro de diálogo de Red. Figura 12-14. Miembro de dominio [samba-aniadir-winnt6.png] Se selecciona la opción de Miembro de "dominio". Figura 12-15. Nombre del dominio [samba-aniadir-winnt7.png] Se completa el campo "dominio" con nombre del dominio al cual se quiere añadir el cliente y se pulsa sobre el botón Aceptar. Figura 12-16. Bienvenida [samba-aniadir-winnt8.png] Se da la bienvenida al nuevo dominio; pulse sobre el botón Aceptar para continuar. Figura 12-17. Cierre del cuadro de diálogo "Red" [samba-aniadir-winnt9.png] Pulse sobre el botón "Cerrar" para cerrar el cuadro de diálogo "Red". Figura 12-18. Reinicio del sistema [samba-aniadir-winnt10.png] Se sugiere un reinicio del sistema para que los cambios tengan efecto, se pulsa sobre el botón "Sí" para continuar. Figura 12-19. Ctrl+Alt+Supr [samba-aniadir-winnt11.png] Se pulsa la combinación de teclas: Ctrl+Alt+Supr para poder iniciar una nueva sesión en el sistema. Figura 12-20. Selección del nuevo dominio [samba-aniadir-winnt12.png] En el cuadro de diálogo de ingreso en el sistema, se selecciona el dominio al cual se acaba de añadir al cliente Windows NT y se teclea una cuenta válida en el dominio para proceder con el ingreso. _________________________________________________________ 12.4. Windows 2000 Windows 2000 es ligeramente diferente de Windows NT. Si se añade una máquina Windows NT a la red, como se ha visto en la sección anterior (Sección 12.3), habrá notado un checkbox con la leyenda: "Crear una cuenta para esta máquina en el dominio", que no se ha utilizado. Esta opción permite la creación de cuentas de máquina "al vuelo"; esta es la única forma de unir un cliente Windows 2000 a un dominio. En la Sección 9.3.2.6 se mostró la opción add user script, que permitía añadir cuentas de máquina automáticamente a Samba. Esta opción es necesaria para poder añadir a los clientes Windows 2000 al dominio. _________________________________________________________ 12.4.1. Añadiendo el usuario "root" a Samba De momento, el único usuario que puede crear cuentas automáticamente es el usuario "root". Esto significa que ha de hacer un "smbpasswd" (como el usuario "root") para el usuario "root". El siguiente ejemplo muestra como hacerlo: Ejemplo 12-1. Estableciendo la clave de root en Samba # /usr/bin/smbpasswd -a New SMB password: [clave] Retype new SMB password: [clave] Added user root. Sugerencia Se sugiere utilizar una clave diferente a la del usuario "root" del sistema Linux por cuestiones de seguridad. Nota Tal vez sea necesario comentar la línea "invalid users = root" del archivo de configuración de Samba, para permitir al usuario root añadir los clientes MS Windows al dominio. _________________________________________________________ 12.4.2. Uniendo un cliente Windows 2000 a un dominio Ha de seguir los siguientes pasos para añadir un cliente Windows 2000 a un dominio: Figura 12-21. "Inicio" [samba-aniadir-win2k1.png] Se comienza el proceso con la pulsación sobre el botón "Inicio": Figura 12-22. "Conexiones de Red" [samba-aniadir-win2k2.png] Se pulsa sobre la opción "Conexiones de Red" (Configuración -> Conexiones de Red). Figura 12-23. "Identificación de Red" [samba-aniadir-win2k3.png] Sobre la ventana de Conexiones de Red, se pulsa sobre el menú "Avanzado" y luego sobre la entrada: "Identificación de Red" Figura 12-24. Selección del dominio [samba-aniadir-win2k4.png] Se pulsa sobre el botón "Propiedades" del cuadro de diálogo Propiedades del Sistema. En la ventana resultante de la acción anterior, se pulsa sobre la opción "Dominio" y se teclea el nombre del dominio al cual se quiere añadir el cliente Windows 2000. Para finalizar, se pulsa sobre el botón Aceptar. Figura 12-25. Cuenta para añadir la máquina al dominio [samba-aniadir-win2k5.png] La acción anterior tendrá como consecuencia la apertura de una ventana, en la que se solicita una cuenta de dominio que tenga permisos suficientes para añadir una máquina al dominio. La cuenta que se ha de utilizar es la creada en Sección 12.4.1, es decir, la cuenta "root". Pulse sobre el botón Aceptar una vez se han completado los datos necesarios. Figura 12-26. Bienvenida al dominio [samba-aniadir-win2k6.png] Una vez se ha añadido el cliente al dominio, se da la bienvenida al mismo. Pulse sobre el botón Aceptar para continuar. Figura 12-27. Preparándose para el reinicio [samba-aniadir-win2k7.png] Una vez recibida la bienvenida, se pulsa sobre el botón Aceptar del cuadro de diálogo Propiedades del Sistema. Figura 12-28. Solicitud de reinicio [samba-aniadir-win2k8.png] Para que los cambios tengan efecto, se ha de reiniciar el sistema. Pulse en el botón Aceptar para proceder con el reinicio. Figura 12-29. Ctrl+Alt+Supr [samba-aniadir-win2k9.png] Se pulsa la combinación de teclas: Ctrl+Alt+Supr para poder iniciar una nueva sesión en el sistema. Figura 12-30. Selección del nuevo dominio [samba-aniadir-win2k10.png] En el cuadro de diálogo de ingreso en el sistema, se selecciona el dominio al cual se acaba de añadir al cliente Windows 2000. Figura 12-31. Cuenta de dominio [samba-aniadir-win2k11.png] Se teclean un usuario y una clave válidos en el dominio y se pulsa sobre Aceptar. Figura 12-32. Entrando en el sistema [samba-aniadir-win2k12.png] Si todo ha ido bien, el siguiente paso es la entrada al sistema. _________________________________________________________ 12.5. Windows XP Para poder añadir a un cliente Windows XP a un dominio manejado por Samba, se ha de realizar un cambio en el registro de Windows. En el Apéndice J se muestra el cambio a realizar. Una vez aplicado el cambio en el registro, siga los siguientes pasos para añadir al cliente Windows XP al dominio: Figura 12-33. Conexiones de Red e Internet [samba-aniadir-winxp1.png] Acceda a la opción "Conexiones de Red e Internet" del Panel de Control (Inicio -> Configuración -> Panel de Control -> Conexiones de Red e Internet). Figura 12-34. Conexiones de Red [samba-aniadir-winxp2.png] Pulse sobre "Conexiones de Red". Figura 12-35. Identificación de Red [samba-aniadir-winxp3.png] Pulse sobre el menú Avanzado, opción "Identificación de Red..." Figura 12-36. Propiedades del Sistema [samba-aniadir-winxp4.png] Pulse sobre el botón "Cambiar..." Figura 12-37. Selección del Dominio [samba-aniadir-winxp5.png] Seleccione la opción "Dominio", teclee el dominio al cual se quiere añadir y, finalmente, pulse sobre el botón Aceptar. Figura 12-38. Cuenta del dominio [samba-aniadir-winxp6.png] Teclee la cuenta del usuario "root" de Samba (vea la Sección 12.4.1 para más detalles) y pulse sobre el botón Aceptar. Figura 12-39. Bienvenida al dominio [samba-aniadir-winxp7.png] Si todo ha ido bien, se dará la bienvenida al dominio. III. CUPS [cups-logo.png] Tabla de contenidos 13. Conceptos teóricos 13.1. Introducción 13.2. Trasfondo histórico 13.3. Historia 13.4. Una visión general sobre el diseño 13.4.1. Planificador 13.4.2. Archivos de configuración 13.4.3. API de CUPS 13.4.4. Órdenes de Berkeley y System V 13.4.5. Filtros 13.4.6. Imágenes en CUPS 13.4.7. Backends 13.5. Impresión en red 13.6. Nuevas características en CUPS 1.1 13.6.1. Backends 13.6.2. Soporte de páginas de separación 13.6.3. Autentificación en modo Digest 13.6.4. Servicios de directorio 13.6.5. Cambios en la estructura de directorios 13.6.6. Documentación 13.6.7. Controladores 13.6.8. Filtros 13.6.9. Soporte IPP 13.6.10. Persistencia de trabajos 13.6.11. Soporte para el cliente LPD 13.6.12. Definiciones de impresoras y opciones por parte del usuario 13.6.13. Interfaz de administración web 13.7. Información adicional sobre el proyecto 13.7.1. Página principal 13.7.2. Cómo obtener CUPS 13.7.3. Documentación 13.7.4. Información de soporte 13.7.5. Reporte de bugs 13.7.6. Cómo contactar 14. Instalación 14.1. Introducción 14.2. Elección de los paquetes necesarios 14.2.1. Análisis del paquete gs-esp 14.2.2. Análisis del paquete cupsys-client 14.2.3. Análisis del paquete cupsys-bsd 14.2.4. Análisis del paquete cupsys-driver-gimpprint 14.2.5. Análisis del paquete foomatic-bin 14.2.6. Análisis del paquete cupsomatic-ppd 14.2.7. Lista completa de paquetes a instalar 14.3. Instalando los paquetes 14.3.1. Instalación del paquete cups-pdf 15. Configuración 15.1. Introducción 15.2. Comprobaciones iniciales 15.3. Modificaciones en la configuración del sistema 15.3.1. Modificaciones de PAM 15.3.2. Modificaciones en Samba 15.3.3. Modificaciones relativas a CUPS 15.4. Creación de la estructura de impresión 15.4.1. Creación de las impresoras 15.4.2. Creación de las clases 15.5. Instalación de los controladores de impresión para los equipos MS Windows 15.5.1. Instalación de los controladores PostScript de CUPS para Windows NT/2000/XP 15.5.2. Instalación de los controladores PostScript de Adobe 15.5.3. Exportando los controladores con cupsaddsmb 15.6. Impresión desde Samba _________________________________________________________ Capítulo 13. Conceptos teóricos 13.1. Introducción CUPS(TM), Common Unix Printing System(TM), es un sistema de impresión portable y extensible para Unix©. CUPS está siendo desarrollado por Easy Software Products, una empresa de software emplazada en Hollywood, Maryland, que ha estado vendiendo software comercial para Unix desde 1993 a más de 40 distribuidores, que sirven sus productos en 80 países de todo el mundo. La página principal de CUPS, desde donde se puede obtener más información, se encuentra localizada en http://www.cups.org. Nota Los conceptos teóricos se han basado en la la entrada bibliográfica Sweet01 _________________________________________________________ 13.2. Trasfondo histórico La impresión en Unix históricamente se ha realizado con uno de estos dos sistemas de impresión: el demonio de impresión en línea de Berkeley ("LPD") [RFC1179] y el sistema de impresión en línea de AT&T. Estos sistemas de impresión se diseñaron en la década de los setenta para imprimir texto en impresoras de línea; a partir de entonces, los vendedores han ido añadiendo diversos niveles de soporte para otro tipo de impresoras. Algunos sustitutos a estos sistemas de impresión han aflorado [LPRng, Palladin, PLP], sin embargo, ninguno de ellos cambió las capacidades fundamentales de los sistemas primigenios. A lo largo de los últimos años se han realizado muchos intentos de desarrollo para obtener una interfaz estándar de impresión, incluyendo el borrador de impresión estándar de POSIX, desarrollado por el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) [IEEE-1387.4], y el Protocolo de Impresión de Internet (IPP), desarrollado por IETF a través de PWG [IETF-IPP]. El protocolo de impresión estándar de POSIX define un conjunto común de herramientas para la consola así como una interfaz en C para la administración y los trabajos de impresión, pero fue abandonado por el IEEE. El Protocolo de Impresión de Internet (IPP) define una serie de extensiones al Protocolo de Transferencia de HiperTexto 1.1 (HTTP) [RFC2616] que añaden soporte para los servicios de impresión remota. IPP/1.0 fue aceptado por el IETF, como un documento RFC experimental, en octubre de 1999. Desde entonces el PWG ha desarrollado y actualizado el conjunto de especificaciones para IPP/1.1, que ha sido aceptado por el IETF y está en espera para ser publicado como una propuesta de estándar. Al contrario que la Impresión POSIX, IPP ha gustado a las grandes empresas de soporte, y se ha posicionado para convertirse en la solución estándar para la impresión en red de todos los sistemas operativos. CUPS hace uso de IPP/1.1 para proporcionar un sistema de impresión completo y moderno, destinado a sistemas Unix, que pueda ser ampliado para dar soporte a nuevas impresoras, dispositivos y protocolos, a la vez que garantice la compatibilidad con las aplicaciones Unix existentes. CUPS es Software Libre y se distribuye bajo los términos de la Licencia Pública General (GPL) y la Licencia Pública General de Librerías (LGPL) del proyecto GNU. _________________________________________________________ 13.3. Historia La primera versión de producción de CUPS (basada en IPP/1.0) fue liberada en octubre de 1999. Desde entonces, se han publicado bastantes actualizaciones para la versión 1.0, destinadas a corregir los errores encontrados, así como añadir seguridad y portabilidad a la versión existente; se ha de notar que no se han añadido nuevas funcionalidades para mejorar la estabilidad del código de CUPS. CUPS 1.1 está basado en IPP/1.1 y se han añadido las funcionalidades pedidas por sus usuarios. Al igual que con la versión 1.0, CUPS 1.1 disfrutará de las actualizaciones necesarias para corregir cualquier problema encontrado en el software, pero no se añadirán nuevas características. _________________________________________________________ 13.4. Una visión general sobre el diseño Al igual que muchos otros sistemas de impresión, CUPS gira entorno a un proceso central de planeamiento (scheduling) de impresión, que cursa los trabajos de impresión, procesa las órdenes de administración y facilita la información de estado de la impresora a los programas locales y remotos, informado a los usuario que lo necesiten. La Figura 13-1 muestra la organización básica de CUPS. Figura 13-1. Diagrama de la organización interna de CUPS[32] [cups-diagrama-organizacion-interna.png] _________________________________________________________ 13.4.1. Planificador El planificador es un servidor HTTP/1.1 que maneja peticiones HTTP. A parte de ocuparse de las peticiones enviadas (POST) por la impresora a través del protocolo IPP, el planificador también actúa como un servidor web cuyas funciones son: mostrar la documentación, monitorizar el estado de la impresión y proveer de una interfaz para realizar tareas de administración. El planificador también administra la lista de las impresoras disponibles en una LAN y reparte los trabajos de impresión como es preciso haciendo uso de los filtros y backends apropiados. _________________________________________________________ 13.4.2. Archivos de configuración Los archivos de configuración consisten en: * Los archivos de configuración del servidor HTTP * Los archivos de definición de las impresoras y las clases * Los archivos de configuración de los tipos MIME y las reglas de conversión * Los archivos PPD (PostScript Printer Description) El archivo de configuración del servidor HTTP se ha creado similar al archivo de configuración del servidor Apache a propósito, y define todas las propiedades de control de acceso del servidor. Los archivos de definición de impresoras y clases, listan las colas y clases de impresión disponibles. Las clases de impresoras con una colección de impresoras. Los trabajos enviados a una clase, son reenviados a la primera impresora disponible en dicha clase, modelo round-robin. Los archivos de tipos MIME listan los tipos MIME soportados (text/plain, application/postscript, etc.) y las reglas "mágicas" de la autodetección de los tipos de formato de un archivo. El servidor HTTP los utiliza para determinar el campo Content-Type (tipo de contenido) para las peticiones GET y HEAD así como por el manejador de peticiones IPP para determinar el tipo de archivo cuando se recibe un trabajo de impresión o una petición de envío de archivo con un formato de documento application/octet-stream. Los archivos de las reglas de conversión MIME listan los filtros disponibles. Los filtros se utilizan cuando un trabajo es despachado, de forma que una aplicación pueda enviar un archivo convenientemente formateado al sistema de impresión, quien convertirá el documento en un formato imprimible, si es necesario. Cada filtro posee un coste relativo asociado, de forma que el algoritmo de elección de filtros pueda elegir el conjunto de filtros que convertirán el archivo al formato necesario con el menor "coste" total. Los archivos PPD describen las capacidades de todas las impresoras, no sólo de las impresoras PostScript. Existe un archivo PPD por cada impresora. Los archivos PPD para las impresoras no PostScript definen un filtro adicional, a través del atributo cupsFilter, para soportar los controladores de la impresora. _________________________________________________________ 13.4.3. API de CUPS La API de CUPS contiene funciones de conveniencia específicas de CUPS para los trabajos de la cola de impresión, obtención de información sobre la impresora, acceso a los recursos a través de HTTP e IPP, así como el manipulado de los archivos PPD. Al contrario que el resto de CUPS, la API de CUPS se distribuye bajo los términos de la licencia LGPL del proyecto GNU, para permitir su uso a las aplicaciones no GPL. _________________________________________________________ 13.4.4. Órdenes de Berkeley y System V CUPS provee las interfaces de las órdenes de consola de System V y Berkeley, que permiten el envío de trabajos y comprobación del estado de una impresora. Las órdenes lpstat y lpcstatus también muestran impresoras de rec ("impresora@servidor") cuando la búsqueda de impresoras está habilitada. Las órdenes de administración de System V se suministran para manejar las impresoras y las clases. La herramienta de administración de Berkeley (lpc) sólo es soportada en un modo de solo lectura, para comprobar el estado actual de las colas de impresión y del planificador. _________________________________________________________ 13.4.5. Filtros El programa de filtrado lee desde la entrada estándar o desde un archivo, si se le pasa como parámetro. Todos los filtros han de soportar un conjunto común de opciones incluyendo el nombre de la impresora, el ID del trabajo, el número de copias y las opciones del trabajo. Todas las salidas son enviadas a la salida estándar. Los filtros se suministran para múltiples formatos de archivo e incluye archivos de imágenes y filtros de búsqueda PostScript, que soportan impresoras no PostScript. Múltiples filtros se ejecutan en paralelo para producir el formato de salida requerido. El filtro de búsqueda PostScript está basado en el núcleo GNU Ghostscript 5.50. En vez de utilizar los controladores de impresión y front-ends de Ghostscript, el filtro de CUPS utiliza un controlador de impresión genérico de búsqueda y un front-end compatible con CUPS para dar soporte a cualquier tipo de impresora "raster" desde cualquier filtro. _________________________________________________________ 13.4.6. Imágenes en CUPS La librería de imágenes de CUPS proporciona funciones de manipulado de grandes imágenes, haciendo una conversión del espacio de color y una administración del color, escalando las imágenes a imprimir y administrando los flujos de páginas "raster". Esta librería es utilizada por el archivo de filtros de imágenes de CUPS, por el RIP PostScript y todos los controladores de impresoras "raster". _________________________________________________________ 13.4.7. Backends Un programa backend es un filtro especial que envía datos a imprimir a un dispositivo o a una conexión de red. CUPS 1.1 provee backends para los puertos paralelo, serie, USB, protocolos como LPD, IPP y conexiones AppSocket (JetDirect). La versión 2.0.6 y superior de Samba incluye un backend (smbspool(1)) que se puede utilizar con CUPS 1.0 o 1.1 para imprimir desde Windows. _________________________________________________________ 13.5. Impresión en red Tradicionalmente, la impresión en red ha sido una de las tareas más difíciles de llevar a cabo bajo Unix. Una de las razones es porque cada vendedor añade sus propias extensiones al protocolo LPD (el anterior estándar de la impresión en red), haciendo la impresión entre plataformas muy difícil, por no decir imposible. Otra de las razones es que se tenía que administrar cada impresora de red en cada máquina cliente. En algunos casos se podía "clonar" la configuración de impresión desde un cliente "maestro" a los demás clientes, pero incluso así se consumía mucho tiempo y era propenso a errores. Se necesitaba algo mejor. CUPS proporciona "búsqueda de impresoras", lo que permite a los clientes buscar y usar automáticamente las impresoras desde cualquier servidor de la red local. Esto significa que sólo se necesita configurar el servidor, y los clientes automáticamente ven las impresoras y sus clases. Además de esto, CUPS puede asociar automáticamente impresoras en red idénticas en "clases implícitas". Esto permite a los clientes enviar trabajos a las clases implícitas y realizar la impresión en la primera impresora o servidor disponible. A mayores se pueden activar de manera sencilla funciones de control de errores y balanceo de carga, definiendo la misma impresora o múltiples servidores. _________________________________________________________ 13.6. Nuevas características en CUPS 1.1 CUPS 1.1 incluye muchas características y funcionalidades nuevas, algunas de las cuales se presentarán en las siguientes secciones. _________________________________________________________ 13.6.1. Backends CUPS 1.1 implementa una nueva interfaz para los backends que le permite recuperar la lista de los dispositivos disponibles para los clientes CUPS. Esto permite poseer interfaces de administración que hagan peticiones al planificador de CUPS para obtener una lista de los dispositivos disponibles, configurar automáticamente las impresoras, siempre y cuando la información de identificación del dispositivo esté disponible, mostrando al usuario una lista de los dispositivos disponibles en vez de confiar que el usuario sepa que dispositivos están o no configurados en el sistema. La nueva versión también incluye un backend para impresoras USB bajo *BSD y Linux. El soporte para USB en Solaris 8 se proveerá en subsecuentes liberaciones de parches. _________________________________________________________ 13.6.2. Soporte de páginas de separación CUPS 1.1 incluye soporte para páginas de separación al principio y al final de la impresión. Las páginas de separación pueden ser de cualquier formato y con soporte de sustitución dinámica para los títulos de los trabajos, nombres de usuario, etc. La página de separación por defecto están asociadas a cada impresora, pudiendo ser sobreescritas por el usuario. _________________________________________________________ 13.6.3. Autentificación en modo Digest La autentificación en modo Digest proporciona un método más seguro de autentificación para obtener acceso al sistema de impresión. Al contrario que la autentificación básica, la autentificación en modo Digest no envía las claves en "texto plano", lo que dificulta el acceso no autorizado al sistema. La implementación de la autentificación en modo Digest de la versión 1.1 de CUPS se realiza gracias al uso de un archivo especial de claves MD5 en vez del archivo de claves de Unix. Este archivo se maneja con la nueva orden lppasswd. _________________________________________________________ 13.6.4. Servicios de directorio CUPS 1.1 añade un nuevo servicio de directorio ("búsqueda de impresoras"), característica que permite hacer uso de CUPS en LANs y WANs de gran dimensión fácilmente. Ahora se puede escanear un servidor remoto en busca de información de impresión y retransmitirla a la red local, así como clasificar el tipo de información a ser procesada (por ejemplo, ocultar los servidores, redes o dominios que no se quieran ver). _________________________________________________________ 13.6.5. Cambios en la estructura de directorios CUPS 1.1 utiliza una estructura de directorios que obedece a la versión 2.0 del estándar FHS (Filesystem Hierarchy Standard). Esto debería hacer la integración en sistemas Linux y *BSD existentes un poco más fácil. _________________________________________________________ 13.6.6. Documentación La documentación de CUPS 1.1 ha pasado varias revisiones, incluyendo una completa reescritura del manual de administración, un nuevo manual para programadores y un manual de referencia sobre la implementación IPP. _________________________________________________________ 13.6.7. Controladores CUPS 1.1 incluye controladores para las impresoras matriciales y de chorro de tinta de EPSON. Como ocurre con los controladores PCL de Hewlett-Packard, los controladores de EPSON no proveen necesariamente de la mejor calidad de impresión para todas las impresoras, de todas formas suelen imprimir con la calidad suficiente para el uso general del día a día. _________________________________________________________ 13.6.8. Filtros CUPS 1.1 incluye nuevos filtros para imágenes, PostScript, PDF y texto. El filtro de imágenes se ha actualizado para soportar archivos BMP de Windows y PIX de Alias. El nuevo filtro para PostScript está basado en el programa Ghostscript 5.50 del proyecto GNU. Este filtro mejora el rendimiento con impresoras de gran resolución y soporta la mayoría de las características del nivel 3 del lenguaje PostScript. El nuevo filtro para PDF está basado en el excelente software, Xpdf, de Derek Noonburg, soportando el escalado automático de páginas. El nuevo filtro es un reemplazo más rápido, pequeño y confiable que el filtro PDF del programa Ghostscript del proyecto GNU utilizado en la versión 1.0 de CUPS. El nuevo filtro de texto soporta texto bidireccional y se le pueden incrustar fuentes si se desea. _________________________________________________________ 13.6.9. Soporte IPP Posiblemente la parte menos visible de CUPS es su soporte de IPP. CUPS 1.1 implementa todas las operaciones y atributos requeridos por IPP/1.1 y muchas de las opcionales. Las opciones opcionales "crear trabajo" y "enviar archivo" ya están implementadas, permitiendo una compatibilidad mejor con el sistema de impresión System V (un identificador de trabajo por cada orden lp), así como el soporte de páginas de separación. _________________________________________________________ 13.6.10. Persistencia de trabajos CUPS 1.1 tiene soporte para trabajos persistentes. Esto significa que los trabajos de impresión son preservados incluso después de un reinicio, característica que fue olvidada, desgraciadamente, en la versión 1.0 de CUPS. A parte de esto, CUPS 1.1 permite mantener la información de cada impresión, una vez que el trabajo se ha impreso. El modo básico de persistencia post-trabajo provee un historial de impresiones (número de páginas impresas, tiempo de impresión que ha tomado un trabajo, etc.) pero no almacena el archivo del trabajo impreso. CUPS se puede configurar para que descarte toda la información una vez ha finalizado la impresión o para mantener los archivos de impresión una vez impresos, de forma que se pueda imprimir de nuevo el archivo más tarde. _________________________________________________________ 13.6.11. Soporte para el cliente LPD Por petición popular, CUPS 1.1 soporta los clientes basados en LPD, usando un pequeño demonio que maneja las peticiones LPD y las retransmite al servidor principal. _________________________________________________________ 13.6.12. Definiciones de impresoras y opciones por parte del usuario CUPS 1.1 incluye soporte para las definiciones de usuario de impresoras y opciones gracias a una nueva orden, lpoptions. Las impresoras definidas por el usuario son instancias especiales de las impresoras disponibles (por ejemplo "printer/instance" o "printer@server/instance"), que pueden tener sus propias opciones por defecto, como el tamaño del papel, la resolución y así en adelante. La orden lpoptions se puede utilizar también para establecer una cola de impresión diferente a la definida por defecto. _________________________________________________________ 13.6.13. Interfaz de administración web CUPS 1.0 poseía una interfaz, destinada a navegadores web, simple para las clases, trabajos y monitorización de impresión, CUPS 1.1 ha reemplazado esta interfaz con una interfaz de administración mejorada, que permite añadir, modificar, borrar, configurar y controlar las clases, los trabajos y las impresoras. _________________________________________________________ 13.7. Información adicional sobre el proyecto 13.7.1. Página principal El Proyecto CUPS dispone de una página principal, http://www.cups.org/, desde donde puede obtener mucha información sobre el proyecto. De hecho, para elaborar esta sección ha utilizado la información allí disponible. _________________________________________________________ 13.7.2. Cómo obtener CUPS Desde la siguiente dirección, podrá seleccionar la versión de CUPS en la que esté interesado y descargársela desde cualquiera de los mirrors disponibles: http://www.cups.org/software.php. Esto es posible ya que CUPS es Software Libre y se licencia bajo los términos de la licencia GPL y LGPL (vea los GNU General Public License, GNU LESSER GENERAL PUBLIC LICENSE y Apéndice AV para más información). La mayoría de las distribuciones de GNU/Linux y muchos distribuidores de Unix disponen de paquetes binarios de CUPS. Infórmese de si su distribución posee este tipo de paquetes. _________________________________________________________ 13.7.3. Documentación La página principal del Proyecto CUPS dispone de una sección dedicada a la documentación, con un listado bastante amplio de documentación relativa al proyecto. Para más detalles, visite: http://www.cups.org/documentation.php _________________________________________________________ 13.7.4. Información de soporte La página dedicada al soporte de CUPS, informa sobre los distintos métodos existentes para obtener ayuda en un determinado momento. Los métodos más importantes para obtener ayuda son los siguientes: Grupos de noticias: El servidor de noticias de la empresa Easy Software Product, news.easysw.com, proporciona 5 grupos de noticias: cups.announce, cups.bugs, cups.cvs, cups.development y cups.general. Los mensajes que allí se publican, se redirigen a su vez a una serie de listas de correo, para obtener más información al respecto, visite el siguiente enlace: http://lists.easysw.com/mailman/listinfo Chequeo de los archivos PPD: La siguiente URL nos proporciona un método de verificar que nuestros archivos PPD están correctos, haciendo uso de la herramienta cupstestppd: http://www.cups.org/testppd.php. FAQs: La página principal de CUPS posee un listado de las preguntas más frecuentemente consultadas, este se encuentra en: http://www.cups.org/faq.php. _________________________________________________________ 13.7.5. Reporte de bugs CUPS dispone de un formulario de reporte de problemas, desde donde se pueden enviar los errores y bugs relacionados con CUPS. _________________________________________________________ 13.7.6. Cómo contactar Para obtener más información sobre CUPS, puede contactar con la empresa Easy Software Products en la siguiente dirección: Attn: CUPS Information Easy Software Products 44141 Airport View Drive Suite 204 Hollywood, Maryland 20636-3111 USA +1.301.373.9600 _________________________________________________________ Capítulo 14. Instalación 14.1. Introducción Este capítulo comenzará haciendo un análisis de los paquetes necesarios para la instalación de un sistema completo de impresión con CUPS, para acabar con la instalación de los paquetes seleccionados. El objetivo que perseguido con el sistema de impresión, es suministrar un mecanismos para que los clientes puedan imprimir, estén donde estén, y utilizando el sistema operativo que sea. Los clientes tipo Unix tendrán el problema resuelto gracias al protocolo IPP, sobre el cual funciona CUPS. Por otro lado, los clientes con sistemas operativos de Microsoft podrán imprimir gracias a la integración de CUPS con Samba. Nota La versión que se instalará de CUPS es la 1.1.20, que acompaña a la versión en desarrollo de Debian GNU/Linux (aka Sid). _________________________________________________________ 14.2. Elección de los paquetes necesarios La selección de los paquetes a instalar, para conseguir que el sistema de impresión CUPS funcione, se va a efectuar, en primer lugar, observando la descripción del paquete cupsys. A partir de las dependencias, sugerencias y recomendaciones de este paquete, se seleccionarán los paquetes más adecuados e importantes para conseguir los objetivos finales de este proyecto. Nota Si su proyecto tiene otras necesidades, sería recomendable repasar la lista de paquetes, y ver cuales de ellos son realmente necesarios y cuales no. En este caso, como no se tienen impresoras definidas, se instalarán la mayoría de los paquetes de controladores para impresoras. Si ya se tuviese un conjunto de impresoras sobre las cuales actuar, se podría hacer una selección más fina de paquetes de controladores. El siguiente ejemplo muestra la descripción del paquete cupsys: Ejemplo 14-1. Descripción del paquete cupsys $ /usr/bin/apt-cache show cupsys Package: cupsys Priority: optional Section: net Installed-Size: 10532 Maintainer: Kenshi Muto Architecture: i386 Version: 1.1.20final+rc1-9 Replaces: cupsys-pstoraster Depends: libc6 (>= 2.3.2.ds1-4), libcupsimage2 (>= 1.1.19final-1), libcupsys2-gnutls10 (>= 1.1.20final-1), libgcc1 (>= 1:3.4.1-3), libgnutls11 (>= 1.0.16), libpam0g (>= 0.76), libpaper1, libslp1, zlib1g (>= 1:1.2.1), gs-esp (1) , adduser (>= 3.12), debconf (>= 1.2.9 ), patch Recommends: cupsys-client (2) , smbclient (3) , xpdf-common Suggests: cupsys-bsd (4) , cupsys-driver-gimpprint (5) , foomatic-bin | foomatic-filters-ppds (6) , xpdf-korean | xpdf-japanese | xpdf-chinese-traditional | xpdf-chinese-s implified Conflicts: cupsys-pstoraster (<< 2), lprng (>= 3.8.25) Filename: pool/main/c/cupsys/cupsys_1.1.20final+rc1-9_i386.deb Size: 3609096 MD5sum: 9a1db7a532df1477e7c572151d217030 Description: Common UNIX Printing System(tm) - server The Common UNIX Printing System (or CUPS(tm)) is a printing system and general replacement for lpd and the like. It supports the Internet Printing Protocol (IPP), and has its own filtering driver model for handling various document types. . This package provides the CUPS scheduler/daemon and related files. . The terms "Common UNIX Printing System" and "CUPS" are trademarks of Easy Software Products (www.easysw.com), and refer to the original source packages from which these packages are made. Task: print-server (1) Paquete que provee la versión ESP del intérprete de PostScript Ghostscript. Este será utilizado por CUPS para renderizar archivos PostScript como gráficos, de forma que este tipo de archivos se puedan imprimir en impresoras sin soporte para PostScript. Al ser una dependencia del paquete cupsys, no será necesario marcarlo para instalar, ya que se instalará automáticamente. De todas formas, se analizará para ver los paquetes que sugiere y recomienda. (2) Herramientas para los clientes de CUPS. (3) Como recomendación, cupsys propone el paquete smbclient. Este paquete ya se ha tratado en la Sección 7.2.2, para más detalles diríjase a dicha sección. Este paquete ya se supone instalado, por lo que no se marcará para instalar. (4) Paquete que provee las órdenes de impresión BSD, de forma que puedan interactuar con CUPS. (5) Controladores de impresión, con calidad de impresión fotográfica para CUPS, basados en Gimp-Print. (6) Paquetes que proveen la base de datos de impresoras Foomatic, diseñada para facilitar la configuración de las impresoras más comunes. Más detalles en http://www.linuxprinting.org/ Del análisis anterior, se obtiene la siguiente lista de paquetes a instalar, a parte del paquete cupsys: * cupsys-client * cupsys-bsd * cupsys-driver-gimpprint * foomatic-bin * cupsomatic-ppd En las siguientes secciones se procederá al análisis de los paquetes de la lista anterior, de la misma forma que ya se hizo con el paquete cupsys. _________________________________________________________ 14.2.1. Análisis del paquete gs-esp En esta sección se analizará la lista de sugerencias y recomendaciones del paquete gs-esp; de esta lista se seleccionarán aquellos paquetes que se consideren interesantes para la consecución del proyecto. Ejemplo 14-2. Descripción del paquete gs-esp $ /usr/bin/apt-cache show gs-esp Package: gs-esp Priority: optional Section: text Installed-Size: 12008 Maintainer: Masayuki Hatta (mhatta) Architecture: i386 Version: 7.07.1-9 Replaces: gs-afpl (<< 8.14-3), gs-aladdin (<< 8.14-3), gs-gpl (<< 8.01-3), gs (<< 8.01-3), gs-pdfencrypt (<< 7.00), cupsys-pstoraster Provides: gs, gs-pdfencrypt, postscript-viewer Depends: libc6 (>= 2.3.2.ds1-4), libcupsimage2 (>= 1.1.19final-1), libcupsys2-gnutls10 (>= 1.1.20final-1), libgimpprint1 (>= 4.2.6), libglib2.0-0 (>= 2.4.1), libjpeg62, libpaper1, libpng12-0 (>= 1.2.5.0-4), libstdc++5 (>= 1:3.3.4-1), libtiff4, libx11-6 | xlibs (>> 4.1.0), libxext6 | xlibs (>> 4.1.0), libxt6 | xlibs (>> 4.1.0), zlib1g (>= 1:1.2.1), gs-common (>= 0.2) Recommends: gsfonts (1) (>= 6.0-1), psfontmgr (2) Conflicts: gs-afpl (<< 8.14-3), gs-aladdin (<< 8.14-3), gs-gpl (<< 8.01-3), gs (<< 8.01-3), gs-pdfencrypt (<< 7.00), cupsys-pstoraster Filename: pool/main/g/gs-esp/gs-esp_7.07.1-9_i386.deb Size: 2772000 MD5sum: 26559300a360d8aa1176512e4beab77e Description: The Ghostscript PostScript interpreter - ESP version Ghostscript is used for PostScript preview and printing. Usually as a back-end to a program such as ghostview, it can display postscript documents in an X11 environment. . Furthermore, it can render PostScript files as graphics to be printed on non-PostScript printers. Supported printers include common dot-matrix, inkjet and laser models. . Package gsfonts contains a set of standard fonts for Ghostscript. . This version of gs is a fork of GNU Ghostscript with updated drivers and patches, intended mostly for use with the Common UNIX Printing System (CUPS) from Easy Software Products (www.easysw.com). The ESP Ghostscript homepage is available at: . http://www.cups.org/ghostscript.php (1) gs-esp recomienda la instalación de las fuentes para el intérprete Ghostscript, paquete que se instalará. (2) psfontmgr es un administrador de fuentes PostScript que hace uso de la aplicación Defoma. Este paquete también se instalará, ya que puede facilitar, en un momento determinado, la administración de dichas fuentes. Después de ver la descripción de este paquete, se añaden a la lista inicial (Primera lista de paquetes a instalar junto con cupsys), los siguientes: * gsfonts * psfontmgr _________________________________________________________ 14.2.1.1. Paquetes gsfonts y psfontmgr Esta sección no tiene más sentido que el mostrar la descripción de los paquetes que se van a instalar, para obtener una visión más amplia de las modificaciones que se van a introducir en el sistema. Ejemplo 14-3. Descripción de los paquetes gsfonts y psfontmgr $ /usr/bin/apt-cache show gsfonts psfontmgr Package: gsfonts Priority: optional Section: text Installed-Size: 5080 Maintainer: Masayuki Hatta (mhatta) Architecture: all Version: 8.14+v8.11-0.1 Depends: defoma Conflicts: gs (<< 5.50-5), gs-aladdin (<< 6.50-4), gsfonts-x11 (<< 0.13 ) Filename: pool/main/g/gsfonts/gsfonts_8.14+v8.11-0.1_all.deb Size: 3726818 MD5sum: b383e6b56330d231fbd0dfee8797aaec Description: Fonts for the Ghostscript interpreter(s) These are free look-alike fonts of the Adobe PostScript fonts. Recommended for all flavors of Ghostscript (gs-gpl, gs-afpl and gs-esp ). Package: psfontmgr Priority: optional Section: admin Installed-Size: 172 Maintainer: Angus Lees Architecture: all Source: defoma Version: 0.11.8-0.1 Depends: defoma (>= 0.9.1), whiptail | dialog, perl Conflicts: defoma-ps, scigraphica-common (<= 0.7.1-3) Filename: pool/main/d/defoma/psfontmgr_0.11.8-0.1_all.deb Size: 21220 MD5sum: 82d87f3940cc0270fdff58568ca3c5ee Description: PostScript font manager -- part of Defoma, Debian Font Man ager psfontmgr manages PostScript fonts through the Defoma framework. It registers the name of available PostScript fonts to Defoma in postscript category, so applications which output a postscript file have all the available PostScript fonts in their font-choosing menus. . It also provides a tool named defoma-psfont-installer, which registers PostScript fonts installed in a PostScript printer. This tool benefits those who want to print a PostScript file with the printer fonts and have the printer fonts appear in a font-choosing menu. Task: chinese-s, chinese-t _________________________________________________________ 14.2.2. Análisis del paquete cupsys-client Esta sección está dedicada al análisis del paquete cupsys-client, de este análisis se obtendrá otra lista de paquetes a instalar, que se añadirán a las ya existentes (Primera lista de paquetes a instalar junto con cupsys y Segunda lista de paquetes a instalar junto con cupsys) Ejemplo 14-4. Descripción del paquete cupsys-client $ /usr/bin/apt-cache show cupsys-client Package: cupsys-client Priority: optional Section: net Installed-Size: 308 Maintainer: Kenshi Muto Architecture: i386 Source: cupsys Version: 1.1.20final+rc1-9 Replaces: cupsys (<= 1.1.18-3) Depends: libc6 (>= 2.3.2.ds1-4), libcupsys2-gnutls10 (>= 1.1.20final-1), zlib1g (>= 1:1.2.1) Recommends: cupsys-bsd (1) Suggests: cupsys, kdeprint (2) , gtklp, cupsys-pt, xpp Conflicts: lprng Filename: pool/main/c/cupsys/cupsys-client_1.1.20final+rc1-9_i386.deb Size: 87964 MD5sum: 100897320ff2fc8296d8c7192d11e313 Description: Common UNIX Printing System(tm) - client programs (SysV) The Common UNIX Printing System (or CUPS(tm)) is a printing system and general replacement for lpd and the like. It supports the Internet Printing Protocol (IPP), and has its own filtering driver model for handling various document types. . This package provides the System V style print client programs. . The terms "Common UNIX Printing System" and "CUPS" are trademarks of Easy Software Products (www.easysw.com), and refer to the original source packages from which these packages are made. Task: print-server (1) Paquete sugerido por cupsys, que ya estaba en la Primera lista de paquetes a instalar junto con cupsys. La Sección 14.2.3 analizará este paquete, en busca de paquetes interesantes para el proyecto. (2) Subsistema de impresión de KDE. Se hará uso de este subsistema para mostrar, en algunas ocasiones, la forma de configurar CUPS. La elección de este frontend sobre los demás existentes, ha sido por la facilidad de uso que presenta y la potencia a la hora de la administración. Se suma el paquete kdeprint a la lista de paquetes a instalar para obtener el sistema de impresión CUPS: * kdeprint _________________________________________________________ 14.2.2.1. Descripción del paquete kdeprint Esta sección no tiene más sentido que el mostrar la descripción del paquete que se va a instalar, para obtener una visión más amplia de las modificaciones que se van a introducir en el sistema. Ejemplo 14-5. Descripción del paquete kdeprint $ /usr/bin/apt-cache show kdeprint Package: kdeprint Priority: optional Section: utils Installed-Size: 1828 Maintainer: Debian Qt/KDE Maintainers Architecture: i386 Source: kdebase Version: 4:3.3.0a-1 Replaces: kdebase (<< 4:3.0.0), kdebase-doc (<< 4:3.0.0) Depends: kdelibs4 (>= 4:3.3.0), libart-2.0-2 (>= 2.3.16), libc6 (>= 2.3.2.ds1-4), libfam0c102, libgcc1 (>= 1:3.4.1-3), libice6 | xlibs (>> 4.1.0), libidn11 (>= 0.5.2), libpng12-0 (>= 1.2.5.0-4), libqt3c102-mt (>= 3:3.3.3), libsm6 | xlibs (>> 4.1.0), libstdc++5 (>= 1:3.3.4-1), libx11-6 | xlibs (>> 4.1.0), libxext6 | xlibs (>> 4.1.0), libxrender1, zlib1g (>= 1:1.2.1), enscript, gv, poster, psutils Suggests: khelpcenter, efax | hylafax-client | mgetty-fax Filename: pool/main/k/kdebase/kdeprint_3.3.0a-1_i386.deb Size: 1061246 MD5sum: b865d5a1909d34c910a5eba77617b3fc Description: KDE Print KDE is a powerful Open Source graphical desktop environment for Unix workstations. It combines ease of use, contemporary functionality, and outstanding graphical design with the technological superiority of the Unix operating system. . This package contains the KDE printing subsystem. It can use Cups, lpd-ng or the traditional lpd. It also includes support for fax and pd f printing. . This package is part of the official KDE base module. _________________________________________________________ 14.2.3. Análisis del paquete cupsys-bsd La descripción de este paquete no desvela ningún otro paquete a instalar. A continuación se muestra su descripción: Ejemplo 14-6. Descripción del paquete cupsys-bsd $ /usr/bin/apt-cache show cupsys-bsd Package: cupsys-bsd Priority: extra Section: net Installed-Size: 192 Maintainer: Kenshi Muto Architecture: i386 Source: cupsys Version: 1.1.20final+rc1-9 Replaces: lpr, cupsys (<= 1.1.15-2), manpages-fr (<< 0.9.5-1) Provides: lpr Depends: libc6 (>= 2.3.2.ds1-4), libcupsys2-gnutls10 (>= 1.1.20final-1) , cupsys-client (= 1.1.20final+rc1-9), debconf, netbase Conflicts: lpr, lprng, manpages-fr (<< 0.9.5-1) Filename: pool/main/c/cupsys/cupsys-bsd_1.1.20final+rc1-9_i386.deb Size: 40272 MD5sum: cfc6bc7f6a73e414752f297e3949f382 Description: Common UNIX Printing System(tm) - BSD commands The Common UNIX Printing System (or CUPS(tm)) is a printing system and general replacement for lpd and the like. It supports the Internet Printing Protocol (IPP), and has its own filtering driver model for handling various document types. . This package provides the BSD commands for interacting with CUPS. It is provides separately to allow CUPS to coexist with other printing systems (to a small degree). . The terms "Common UNIX Printing System" and "CUPS" are trademarks of Easy Software Products (www.easysw.com), and refer to the original source packages from which these packages are made. Task: print-server _________________________________________________________ 14.2.4. Análisis del paquete cupsys-driver-gimpprint Sección que analizará el paquete de los controladores para CUPS basados en Gimp-Print. A partir de este paquete se seleccionarán otros; vea el siguiente ejemplo para más detalles: Ejemplo 14-7. Descripción del paquete cupsys-driver-gimpprint $ /usr/bin/apt-cache show cupsys-driver-gimpprint Package: cupsys-driver-gimpprint Priority: optional Section: graphics Installed-Size: 1192 Maintainer: Roger Leigh Architecture: i386 Source: gimp-print Version: 4.2.7-4 Depends: libc6 (>= 2.3.2.ds1-4), libcupsimage2 (>= 1.1.19final-1), libcupsys2-gnutls10 (>= 1.1.20final-1), libgimpprint1 (>= 4.2.7), zlib1g (>= 1:1.2.1), perl, cupsys-driver-gimpprint-data (1) (= 4.2.7- 4), cupsys (>= 1.1.4) | cups (>= 1.1.4) Recommends: gs-esp (>= 7.05.2-1) | gs-gpl (>= 8.01-1) | postscript-view er Suggests: gimpprint-doc (>= 4.2.7-4), gimpprint-locales (2) (>= 4.2.7 -4) Filename: pool/main/g/gimp-print/cupsys-driver-gimpprint_4.2.7-4_i386.d eb Size: 952450 MD5sum: 0b6224bdd85be3a35b56af4d22d0de82 Description: Gimp-Print printer drivers for CUPS This package includes a CUPS driver based on Gimp-Print. . The CUPS drivers contain all of the files needed to support photo-quality printing on any printer supported by Gimp-Print. You can find out more about the Common UNIX Printing System ("CUPS"), an IPP-based printing system for UNIX/Linux, at: . http://www.cups.org . This is Gimp-Print version 4.2.7, a stable release in the 4.2 line. . Gimp-Print is the print facility for the Gimp, and in addition a suite of drivers that may be used with common UNIX spooling systems using GhostScript or CUPS. These drivers provide printing quality for UNIX/Linux on a par with proprietary vendor-supplied drivers in many cases, and can be used for many of the most demanding printing tasks. Task: print-server (1) Este paquete es una dependencia, por lo que se va a instalar cuando se instale el paquete cupsys-driver-gimpprint. Su contenido son los archivos PPDs, del proyecto Gimp-Print, para CUPS. (2) Paquete que provee los datos de internacionalización para Gimp-Print. El paquete que se lista a continuación se suma a los ya seleccionados anteriormente para instalar: * gimpprint-locales _________________________________________________________ 14.2.4.1. Paquetes gimpprint-locales y cupsys-driver-gimpprint-data Esta sección no tiene más sentido que el mostrar la descripción de los paquetes que se van a instalar, para obtener una visión más amplia de las modificaciones que se van a introducir en el sistema. Ejemplo 14-8. Descripción de los paquetes gimpprint-locales y cupsys-driver-gimpprint-data $ /usr/bin/apt-cache show gimpprint-locales \ cupsys-driver-gimpprint-data Package: gimpprint-locales Priority: optional Section: libs Installed-Size: 1152 Maintainer: Roger Leigh Architecture: all Source: gimp-print Version: 4.2.7-4 Replaces: libgimpprint1 (<= 4.2.0-1) Filename: pool/main/g/gimp-print/gimpprint-locales_4.2.7-4_all.deb Size: 309592 MD5sum: a32bf289f46ea3a6ce6ed915b3d6b647 Description: Locale data files for Gimp-Print This package contains the i18n files of Gimp-Print, used by libgimpprint1, cupsys-driver-gimpprint and escputil. It is also used by the Gimp Print plugin. It will be used by any programs which link with libgimpprint. . They are needed when you want the programs in Gimp-Print to print their messages in other languages than US English. . This is Gimp-Print version 4.2.7, a stable release in the 4.2 line. . Gimp-Print is the print facility for the Gimp, and in addition a suite of drivers that may be used with common UNIX spooling systems using GhostScript or CUPS. These drivers provide printing quality for UNIX/Linux on a par with proprietary vendor-supplied drivers in many cases, and can be used for many of the most demanding printing tasks. Package: cupsys-driver-gimpprint-data Priority: optional Section: graphics Installed-Size: 1984 Maintainer: Roger Leigh Architecture: all Source: gimp-print Version: 4.2.7-4 Replaces: cupsys-driver-gimpprint (<< 4.2.6-4) Depends: cupsys-driver-gimpprint (= 4.2.7-4) Filename: pool/main/g/gimp-print/cupsys-driver-gimpprint-data_4.2.7-4_a ll.deb Size: 1368570 MD5sum: 988e7ee0a060ebaed149c9d91dd9c5b8 Description: Gimp-Print printer drivers for CUPS This package includes Gimp-Print PPDs for CUPS. . The CUPS drivers contain all of the files needed to support photo-quality printing on any printer supported by Gimp-Print. You can find out more about the Common UNIX Printing System ("CUPS"), an IPP-based printing system for UNIX/Linux, at: . http://www.cups.org . This is Gimp-Print version 4.2.7, a stable release in the 4.2 line. . Gimp-Print is the print facility for the Gimp, and in addition a suite of drivers that may be used with common UNIX spooling systems using GhostScript or CUPS. These drivers provide printing quality for UNIX/Linux on a par with proprietary vendor-supplied drivers in many cases, and can be used for many of the most demanding printing tasks. _________________________________________________________ 14.2.5. Análisis del paquete foomatic-bin Desde la página linuxprinting.org se distribuyen una serie de controladores para distintas impresoras, cuyo objetivo es facilitar la instalación y configuración de las mismas. En esta sección se verán los paquetes necesarios para obtener dichos controladores: Ejemplo 14-9. Descripción del paquete foomatic-bin $ /usr/bin/apt-cache show foomatic-bin Package: foomatic-bin Priority: optional Section: text Installed-Size: 60 Maintainer: Chris Lawrence Architecture: all Source: foomatic-db-engine Version: 3.0.2-2 Depends: foomatic-db (1) (>> 2.9), foomatic-db-hpijs (2) , foomatic- db-engine (3) , foomatic-filters (4) Filename: pool/main/f/foomatic-db-engine/foomatic-bin_3.0.2-2_all.deb Size: 47592 MD5sum: f147f54037ca6c8c9a4a1128f3f6adfa Description: linuxprinting.org printer support - transition package Release 3.0 of foomatic has reorganized the foomatic printing system. This package is provided to facilitate a smooth upgrade from Foomatic 2.0 or earlier. . Once you have installed the dependencies of this package, this package can be safely purged from your system. . Home Page: http://www.linuxprinting.org/ (1) Paquete que contiene la base de datos de las impresoras más comunes que se distribuye desde linuxprinting.org. Estos controladores hacen uso de Ghostscript para la parte del procesado de la impresión. (2) Paquete que incluye el soporte necesario para las impresoras que hacen uso de los controladores HPIJS, particularmente las impresoras de inyección de tinta de Hewlett-Packard. (3) Programas dependientes de la arquitectura necesarios para configurar y mantener el sistema foomatic. (4) Scripts de filtrado utilizados por las colas de impresión para convertir los datos PostScript entrantes en el formato nativo de las impresoras que hacen uso de un archivo PPD específico de la impresora, pero independiente de la cola de impresión. El paquete foomatic-bin, no es más que un metapaquete de dependencias. Con la instalación de este paquete, se instalarán a su vez la siguiente lista de paquetes, por lo que no será necesario marcarlos para la instalación: * foomatic-db * foomatic-db-hpijs * foomatic-db-engine * foomatic-filters _________________________________________________________ 14.2.5.1. Análisis del paquete foomatic-db A continuación se muestra la descripción del paquete foomatic-db, la cual se analizará en busca de nuevos paquetes para instalar, en caso de ser necesario: Ejemplo 14-10. Descripción de los paquetes foomatic-db $ /usr/bin/apt-cache show foomatic-db Package: foomatic-db Priority: optional Section: text Installed-Size: 10064 Maintainer: Chris Lawrence Architecture: all Version: 20041013-1 Depends: foomatic-filters Recommends: foomatic-db-engine Suggests: foomatic-db-hpijs, foomatic-db-gimp-print (1) , foo2zjs (2) Conflicts: foomatic-bin (<< 2.9) Filename: pool/main/f/foomatic-db/foomatic-db_20041013-1_all.deb Size: 494012 MD5sum: 84891b80ef692464897e8ceb4bc8724a Description: linuxprinting.org printer support - database Foomatic is a printing system designed to make it easier to set up common printers for use with Debian (and other operating systems). It provides the "glue" between a print spooler (like CUPS or lpr) and your actual printer, by telling your computer how to process files sent to the printer. . This package contains the printer database distributed by linuxprinting.org for most common drivers. You will probably need the foomatic-db-engine package for this package to be useful. . The foomatic-db-hpijs package adds additional printers supported by the HPIJS printer driver backend, particularly consumer inkjet printers from Hewlett-Packard. . The foomatic-db-gimp-print package adds additional printers supported by the GIMP-Print printer driver backend, most commonly used for color photo printing on consumer inkjets. . The foo2zjs package adds backend support for a number of printers from HP and Minolta/QMS that use the Zenographics ZjStream protocol. . Home Page: http://www.linuxprinting.org/ (1) Paquete que provee soporte para las impresoras, haciendo uso de la suite de controladores de impresoras Gimp-Print. (2) Controladores de impresión para aquellas impresoras que utilizan el protocolo Zenographics ZjStream para la transmisión de los datos de impresión. Este paquete no se instalará, de todas formas, ha de analizar si posee alguna impresora de este tipo. A partir del paquete foomatic-db, se ha encontrado otro paquete más para la lista de paquetes de instalación. El paquete en cuestión es: * foomatic-db-gimp-print _________________________________________________________ 14.2.5.1.1. Paquetes foomatic-db-gimp-print y foo2zjs Esta sección no tiene más sentido que el mostrar la descripción de los paquetes que se van a instalar, para obtener una visión más amplia de las modificaciones que se van a introducir en el sistema. Nota En esta ocasión se muestra la descripción del paquete foo2zjs, que no va a ser instalado. El motivo de mostrar su descripción, es proveer la información necesaria para aquellas personas que tengan una impresora del tipo que soporta el paquete foo2zjs. Ejemplo 14-11. Descripción de los paquetes foomatic-db-gimp-print y foo2zjs $ /usr/bin/apt-cache show foomatic-db-gimp-print \ foo2zjs Package: foomatic-db-gimp-print Priority: optional Section: text Installed-Size: 11948 Maintainer: Roger Leigh Architecture: all Source: gimp-print Version: 4.2.7-4 Depends: foomatic-db, ijsgimpprint (>= 4.2.7-4) Conflicts: foomatic-bin (<< 2.9), foomatic-db (<< 2.9) Filename: pool/main/g/gimp-print/foomatic-db-gimp-print_4.2.7-4_all.deb Size: 544364 MD5sum: ef504aba3492142f5174aaeecd4af05f Description: linuxprinting.org printer support - database for Gimp-Prin t printer drivers Foomatic is a printing system designed to make it easier to set up common printers for use with Debian (and other operating systems). It provides the "glue" between a print spooler (like CUPS or lpr) and your actual printer, by telling your computer how to process files sent to the printer. . This package includes support for printers using the Gimp-Print printer driver suite. . Home Page: http://www.linuxprinting.org/ . This is Gimp-Print version 4.2.7, an unstable development release in the 4.3 line. . Gimp-Print is the print facility for the Gimp, and in addition a suite of drivers that may be used with common UNIX spooling systems using GhostScript or CUPS. These drivers provide printing quality for UNIX/Linux on a par with proprietary vendor-supplied drivers in many cases, and can be used for many of the most demanding printing tasks. Package: foo2zjs Priority: optional Section: text Installed-Size: 400 Maintainer: Chris Lawrence Architecture: i386 Version: 20040210-2 Depends: libc6 (>= 2.3.2.ds1-4) Recommends: foomatic-db-engine Suggests: psutils Filename: pool/main/f/foo2zjs/foo2zjs_20040210-2_i386.deb Size: 187138 MD5sum: e7ab1d8f6ea4e32fa6cd59fdee505ce8 Description: Support for printing to ZjStream-based printers foo2zjs is an open source printer driver for printers that use the Zenographics ZjStream wire protocol for their print data, such as the Minolta/QMS magicolor 2200 DL/2300 DL and HP LaserJet 1000/1005. These printers are often erroneously referred to as "winprinters" or "GDI printers". . The foomatic-db-engine package is recommended to simplify configuring this printer driver. The psutils package is needed to enable n-up printing support. . Home Page: http://foo2zjs.rkkda.com/ _________________________________________________________ 14.2.5.2. Paquete foomatic-db-hpijs A continuación se muestra la descripción del paquete foomatic-db-hpijs. De esta no se obtiene ningún nuevo paquete para instalar. Ejemplo 14-12. Descripción del paquete foomatic-db-hpijs $ /usr/bin/apt-cache show foomatic-db-hpijs Package: foomatic-db-hpijs Priority: optional Section: text Installed-Size: 4712 Maintainer: Chris Lawrence Architecture: all Version: 1.5-20041013-1 Depends: foomatic-filters, foomatic-db, hpijs (>> 1.3) Conflicts: foomatic-bin (<< 2.9), foomatic-db (<< 2.9) Filename: pool/main/f/foomatic-db-hpijs/foomatic-db-hpijs_1.5-20041013- 1_all.deb Size: 214228 MD5sum: 161b737f47bca70174237efae2d63ee8 Description: linuxprinting.org printer support - database for HPIJS pri nters Foomatic is a printing system designed to make it easier to set up common printers for use with Debian (and other operating systems). It provides the "glue" between a print spooler (like CUPS or lpr) and your actual printer, by telling your computer how to process files sent to the printer. . This package includes support for printers using the HPIJS printer driver backend, particularly consumer inkjet printers from Hewlett-Packard. . Home Page: http://www.linuxprinting.org/ Task: print-server _________________________________________________________ 14.2.5.3. Análisis de los paquetes foomatic-db-engine Aunque este paquete sugiere y recomienda la instalación de nuevos paquetes, se ha decidido no instalarlos, sólo se mostrará su descripción a modo de información. Ejemplo 14-13. Descripción de los paquetes foomatic-db-engine $ /usr/bin/apt-cache show foomatic-db-engine Package: foomatic-db-engine Priority: optional Section: text Installed-Size: 704 Maintainer: Chris Lawrence Architecture: i386 Version: 3.0.2-2 Replaces: foomatic-bin (<< 2.9) Depends: perl (>= 5.6.0-16), libc6 (>= 2.3.2.ds1-4), libxml2 (>= 2.6.11), zlib1g (>= 1:1.2.1), foomatic-db, foomatic-filters , wget | curl Pre-Depends: bash (>= 2.05) Recommends: netcat (1) Suggests: foomatic-db-hpijs, foomatic-db-gimp-print, foomatic-gui (2) Conflicts: foomatic-bin (<< 2.9), foomatic-db (<< 2.9) Filename: pool/main/f/foomatic-db-engine/foomatic-db-engine_3.0.2-2_i38 6.deb Size: 252714 MD5sum: aed29832cb990e97d859fb9066a06617 Description: linuxprinting.org printer support - programs Foomatic is a printing system designed to make it easier to set up common printers for use with Debian (and other operating systems). It provides the "glue" between a print spooler (like CUPS or lpr) and your actual printer, by telling your computer how to process files sent to the printer. . This package contains the architecture-dependent programs needed to set up and maintain the foomatic system. You will also need one or more database packages. The foomatic-db package includes drivers for most common printers using Ghostscript as the print processor, as well as some common glue code used in other filter systems. . foomatic-db-hpijs includes support for photo-quality printing with Hewlett-Packard and some other consumer inkjets using the HPIJS backend developed by HP. . foomatic-db-gimp-print includes support for photo-quality printing with many consumer inkjets (including those from HP and Epson). . foomatic-gui provides a GNOME-based setup tool for Foomatic printer queues using the command-line tools provided in this package. . Home Page: http://www.linuxprinting.org/ Task: print-server (1) La navaja suiza del protocolo TCP/IP. (2) Interfaz gráfica de configuración del sistema de filtrado Foomatic. _________________________________________________________ 14.2.5.3.1. Paquetes netcat y foomatic-gui Ejemplo 14-14. Descripción de los paquetes netcat y foomatic-gui $ /usr/bin/apt-cache show netcat \ foomatic-gui Package: netcat Priority: optional Section: net Installed-Size: 176 Maintainer: Decklin Foster Architecture: i386 Version: 1.10-26 Depends: libc6 (>= 2.3.2.ds1-4) Filename: pool/main/n/netcat/netcat_1.10-26_i386.deb Size: 66302 MD5sum: 3273445ba7953c3c827872d6c474053b Description: TCP/IP swiss army knife A simple Unix utility which reads and writes data across network connections using TCP or UDP protocol. It is designed to be a reliabl e "back-end" tool that can be used directly or easily driven by other programs and scripts. At the same time it is a feature-rich network debugging and exploration tool, since it can create almost any kind of connection you would need and has several interesting built-in capabilities. Package: foomatic-gui Priority: optional Section: gnome Installed-Size: 248 Maintainer: Chris Lawrence Architecture: all Version: 0.6.7 Depends: python (>> 2.3), python (<< 2.4), foomatic-db-engine, python-g nome2, python-glade2, netcat, pconf-detect, nmap, smbclient, gksu Filename: pool/main/f/foomatic-gui/foomatic-gui_0.6.7_all.deb Size: 58252 MD5sum: 3720f90cb004a41a24b19f07ca8bdf23 Description: GNOME interface for configuring the Foomatic printer filte r system Foomatic is a printing system designed to make it easier to set up common printers for use with Debian (and other operating systems). It provides the "glue" between a print spooler (like CUPS or lpr) and your actual printer, by telling your computer how to process files sent to the printer. . This package includes a GNOME-based graphical user interface to simpli fy configuring printers that use Foomatic. . Project Home: http://savannah.nongnu.org/projects/foomatic-gui/ Development weblog: http://blog.lordsutch.com/?topic=13 Task: print-server _________________________________________________________ 14.2.5.4. Análisis del paquete foomatic-filters A partir de la descripción de este paquete no se obtiene ningún otro para la instalación. Los motivos son que los posibles paquetes sujetos a la instalación, ya se han seleccionado en secciones anteriores o ya se encuentran instalados en el sistema. Importante Se da por supuesto que ya tiene instalado en el sistema las herramientas de conversión de archivos de texto a archivos PostScript (vea el siguiente ejemplo para más detalles), si no posee ninguna de estas herramientas instaladas, sería recomendable que lo hiciese. Ejemplo 14-15. Descripción del paquete foomatic-filters $ /usr/bin/apt-cache show foomatic-filters Package: foomatic-filters Priority: optional Section: text Installed-Size: 324 Maintainer: Chris Lawrence Architecture: all Version: 3.0.2-1 Replaces: foomatic-bin (<< 2.9), cupsomatic-ppd Depends: perl, debconf (>= 0.5) | debconf-2.0, ucf (>= 0.30) Pre-Depends: bash (>= 2.05) Recommends: cupsys-client | lpr | lprng | pdq | rlpr, gs-esp | gs, cupsys | enscript (1) | a2ps (2) | mpage (3) , foomatic-db-engine Conflicts: foomatic-bin (<< 2.9), cupsomatic-ppd (<< 20030507) Filename: pool/main/f/foomatic-filters/foomatic-filters_3.0.2-1_all.deb Size: 123842 MD5sum: ba5f0f7710be13d2a131c5d16cd8cec5 Description: linuxprinting.org printer support - filters Foomatic is a printer database designed to make it easier to set up common printers for use with Debian (and other operating systems). It provides the "glue" between a print spooler (like CUPS or lpr) and your actual printer, by telling your computer how to process files sent to the printer. . This package consists of filter scripts used by the printer spoolers to convert the incoming PostScript data into the printer's native format using a printer-specific, but spooler-independent PPD file. You will need to install the foomatic-db-engine package and its dependencies for this package to be useful. . For use with CUPS, you will need both the cupsys and cupsys-client packages installed on your system. . Home Page: http://www.linuxprinting.org/ (1) (2) (3) Estos tres paquetes proveen una serie de herramientas para convertir archivos, normalmente de texto, en formato PostScript. Es imprescindible tener al menos uno de estos paquetes instalados en el sistema. Será labor del administrador elegir cual se instala. _________________________________________________________ 14.2.6. Análisis del paquete cupsomatic-ppd Ejemplo 14-16. Descripción del paquete cupsomatic-ppd $ /usr/bin/apt-cache show cupsomatic-ppd Package: cupsomatic-ppd Priority: optional Section: text Installed-Size: 12 Maintainer: Chris Lawrence Architecture: all Source: foomatic-filters-ppds Version: 20041013-1 Depends: foomatic-filters-ppds (1) Filename: pool/main/f/foomatic-filters-ppds/cupsomatic-ppd_20041013-1_a ll.deb Size: 2588 MD5sum: 6474bf484cd5a424134e301b1dd928a3 Description: linuxprinting.org printer support - transition package Foomatic is a printer database designed to make it easier to set up common printers for use with Debian (and other operating systems). It provides the "glue" between a print spooler (like CUPS or lpr) and your actual printer, by telling your computer how to process files sent to the printer. . This package depends on the foomatic-filters-ppds package, which replaces the functionality of this package. This package can be safely removed once you have installed foomatic-filters-ppds. . Home Page: http://www.linuxprinting.org/ (1) Archivos PPD que se adaptan a la especificación de Adobe. Un nuevo paquete para la lista de instalación: * foomatic-filters-ppds _________________________________________________________ 14.2.6.1. Paquete foomatic-filters-ppds Esta sección no tiene más sentido que el mostrar la descripción del paquete que se va a instalar, para obtener una visión más amplia de las modificaciones que se van a introducir en el sistema. Ejemplo 14-17. Descripción del paquete foomatic-filters-ppds $ /usr/bin/apt-cache show foomatic-filters-ppds Package: foomatic-filters-ppds Priority: extra Section: text Installed-Size: 10616 Maintainer: Chris Lawrence Architecture: all Version: 20041013-1 Replaces: cupsomatic-ppd (<< 20030507) Depends: foomatic-db-engine Recommends: cupsys Suggests: foomatic-db-hpijs, foomatic-db-gimp-print, foo2zjs Conflicts: cupsomatic-ppd (<< 20030507) Filename: pool/main/f/foomatic-filters-ppds/foomatic-filters-ppds_20041 013-1_all.deb Size: 6145132 MD5sum: 249f8685a14a4b7b05a8a74cb4621134 Description: linuxprinting.org printer support - prebuilt PPD files Foomatic is a printer database designed to make it easier to set up common printers for use with Debian (and other operating systems). It provides the "glue" between a print spooler (like CUPS or lpr) and your actual printer, by telling your computer how to process files sent to the printer. . This package provides Adobe-compliant PPD files for *every single printer* supported by Foomatic. Unless you want to be able to select your printer from the web interface of CUPS or PPR, you almost certainly don't want this package. Instead, you can use the "foomatic-configure" script in foomatic-db-engine, the "foomatic-gui" package, or the web interface for getting a particular PPD file at http://www.linuxprinting.org/printer_list.cgi . Again, you probably don't want this package unless you have a lot of disk space to spare and/or using the CUPS or PPR web interface to set up your printer queue is important to you. . Home Page: http://www.linuxprinting.org/ Task: print-server _________________________________________________________ 14.2.7. Lista completa de paquetes a instalar Juntando todos los paquetes que se han ido seleccionando para la instalación, el conjunto de los mismos queda como sigue: * cupsys * cupsys-client * cupsys-bsd * cupsys-driver-gimpprint * foomatic-bin * cupsomatic-ppd * gsfonts * psfontmgr * kdeprint * gimpprint-locales * foomatic-db-gimp-print * foomatic-filters-ppds A la lista anterior se ha de sumar un paquete más, que se instalará posteriormente. El paquete en cuestión es cups-pdf, que no es más que una impresora PDF virtual: todo el trabajo de impresión que procese lo convierte a un archivo PDF. Esta impresora será la impresora utilizada para la realización de las pruebas, al no disponer de una impresora real. Nota Para completar el análisis de paquetes relacionados con CUPS, habría que hacer una búsqueda en la base de datos de paquetes disponibles y seleccionar aquellos que se consideren necesarios. La búsqueda se puede realizar con la siguiente orden: /usr/bin/apt-cache search cups. Esta orden devolverá una lista con aquellos paquetes cuya descripción posea la palabra cups. De la lista devuelta, los paquetes más interesantes son: * bluez-cups * cups-pdf * escputil * hpoj De la lista anterior, el único paquete que se va a instalar es el cups-pdf, como ya se ha dicho. _________________________________________________________ 14.3. Instalando los paquetes En esta se mostrará el proceso de instalación de los paquetes seleccionados en la sección anterior, Sección 14.2. La lista completa de paquetes necesarios se encuentra en la Sección 14.2.7. El siguiente ejemplo muestra el proceso de instalación de dichos paquetes: Ejemplo 14-18. Instalación del sistema de impresión CUPS (primera parte) # /usr/bin/apt-get install cupsys cupsys-client cupsys-bsd \ cupsys-driver-gimpprint foomatic-bin \ cupsomatic-ppd gsfonts psfontmgr \ kdeprint gimpprint-locales \ foomatic-db-gimp-print \ foomatic-filters-ppds Leyendo lista de paquetes... Hecho Creando árbol de dependencias... Hecho gsfonts ya está en su versión más reciente. (1) psfontmgr ya está en su versión más reciente. (2) kdeprint ya está en su versión más reciente. (3) Se instalarán los siguientes paquetes extras: cupsys-driver-gimpprint-data foomatic-db foomatic-db-engine foomatic- db-hpijs foomatic-filters gs-esp hpijs ijsgimpprint libcupsimage2 libijs-0.35 Paquetes sugeridos: xpdf-korean xpdf-japanese xpdf-chinese-traditional xpdf-chinese-simpl ified gtklp cupsys-pt xpp gimpprint-doc foo2zjs foomatic-gui hpoj Paquetes recomendados xpdf-common Se instalarán los siguientes paquetes NUEVOS: cupsomatic-ppd cupsys cupsys-bsd cupsys-client cupsys-driver-gimpprin t cupsys-driver-gimpprint-data foomatic-bin foomatic-db foomatic-db-eng ine foomatic-db-gimp-print foomatic-db-hpijs foomatic-filters foomatic-fi lters-ppds gimpprint-locales gs-esp hpijs ijsgimpprint libcupsimage2 libijs-0.35 0 actualizados, 19 se instalarán, 0 para eliminar y 0 no actualizados. 0 actualizados, 19 se instalarán, 0 para eliminar y 2 no actualizados. Se necesita descargar 0B/17,1MB de archivos. Se utilizarán 67,8MB de espacio de disco adicional después de desempaqu etar. ¿Desea continuar? [S/n] S Preconfiguring packages ... (1) (2) (3) En el sistema donde se han realizado las pruebas ya se encontraban instalados estos paquetes. Figura 14-1. Backend de impresión para Foomatic [cupsys-instalacion1.png] Seleccione la cola de impresión que desea que utilice Foomatic para los trabajos de impresión. Como en esta documentación se va a emplear CUPS, se ha elegido esta opción. Figura 14-2. Configuración del filtro de impresión Foomatic [cupsys-instalacion2.png] Foomatic permite la creación de un archivo de log, sobre el que volcará los informes de depuración. La creación de este archivo supone un riesgo de seguridad en el sistema, por lo que se recomienda no instalarlo, a no ser que lo necesite para analizar su comportamiento. Figura 14-3. Selección del intérprete Ghostscript [cupsys-instalacion3.png] Se recomienda seleccionar la opción gs, de forma que se elegirá el intérprete de Ghostscript seleccionado en las alternativas de Debian. Si en un determinado momento quiere cambiar el intérprete de Ghostscript predeterminado, sólo ha de ejecutar: /usr/sbin/update-alternatives --config gs y seleccionar aquel que desee. Figura 14-4. Insertar información de contabilidad en cada trabajo [cupsys-instalacion4.png] Respondemos negativamente a esta pregunta, debido a que se utilizará un programa externo, PyKota, para la gestión de quotas de impresión. Figura 14-5. Trabajos sin tipo MIME [cupsys-instalacion5.png] Aquellos trabajos que no lleven adjunto un tipo MIME, serán enviados a la impresora tal cual, sin ningún tipo de preprocesado. Figura 14-6. Selección de backends para CUPS [cupsys-instalacion6.png] En esta pantalla se seleccionarán los backends que utilizará CUPS a la hora de imprimir. Figura 14-7. Compatibilidad lpd de BSD [cupsys-instalacion7.png] No se activa la compatibilidad lpd de BSD en este caso, por no ser necesaria. Puede que en su caso esta situación sea distinta... Ejemplo 14-19. Instalación del sistema de impresión CUPS (segunda parte) Seleccionando el paquete foomatic-filters previamente no seleccionado. (Leyendo la base de datos ... 135345 ficheros y directorios instalados actualmente.) Desempaquetando foomatic-filters (de .../foomatic-filters_3.0.2-1_all.d eb) ... Seleccionando el paquete foomatic-db previamente no seleccionado. Desempaquetando foomatic-db (de .../foomatic-db_20041013-1-1_all.deb) . .. Seleccionando el paquete foomatic-db-engine previamente no seleccionado . Desempaquetando foomatic-db-engine (de .../foomatic-db-engine_3.0.2-2_i 386.deb) ... Seleccionando el paquete foomatic-filters-ppds previamente no seleccion ado. Desempaquetando foomatic-filters-ppds (de .../foomatic-filters-ppds_200 41013-1_all.deb) ... Seleccionando el paquete cupsomatic-ppd previamente no seleccionado. Desempaquetando cupsomatic-ppd (de .../cupsomatic-ppd_20041013-1_all.de b) ... Seleccionando el paquete libcupsimage2 previamente no seleccionado. Desempaquetando libcupsimage2 (de .../libcupsimage2_1.1.20final+rc1-9_i 386.deb) ... Seleccionando el paquete gs-esp previamente no seleccionado. Desempaquetando gs-esp (de .../gs-esp_7.07.1-9_i386.deb) ... Seleccionando el paquete cupsys previamente no seleccionado. Desempaquetando cupsys (de .../cupsys_1.1.20final+rc1-9_i386.deb) ... Seleccionando el paquete cupsys-client previamente no seleccionado. Desempaquetando cupsys-client (de .../cupsys-client_1.1.20final+rc1-9_i 386.deb) ... Seleccionando el paquete cupsys-driver-gimpprint-data previamente no se leccionado. Desempaquetando cupsys-driver-gimpprint-data (de .../cupsys-driver-gimp print-data_4.2.7-4_all.deb) ... Seleccionando el paquete cupsys-driver-gimpprint previamente no selecci onado. Desempaquetando cupsys-driver-gimpprint (de .../cupsys-driver-gimpprint _4.2.7-4_i386.deb) ... Seleccionando el paquete hpijs previamente no seleccionado. Desempaquetando hpijs (de .../hpijs_1.6.2-1_i386.deb) ... Seleccionando el paquete foomatic-db-hpijs previamente no seleccionado. Desempaquetando foomatic-db-hpijs (de .../foomatic-db-hpijs_1.5-2004101 3-1_all.deb) ... Seleccionando el paquete foomatic-bin previamente no seleccionado. Desempaquetando foomatic-bin (de .../foomatic-bin_3.0.2-2_all.deb) ... Seleccionando el paquete libijs-0.35 previamente no seleccionado. Desempaquetando libijs-0.35 (de .../libijs-0.35_0.35-1_i386.deb) ... Seleccionando el paquete ijsgimpprint previamente no seleccionado. Desempaquetando ijsgimpprint (de .../ijsgimpprint_4.2.7-4_i386.deb) ... Seleccionando el paquete foomatic-db-gimp-print previamente no seleccio nado. Desempaquetando foomatic-db-gimp-print (de .../foomatic-db-gimp-print_4 .2.7-4_all.deb) ... Seleccionando el paquete gimpprint-locales previamente no seleccionado. Desempaquetando gimpprint-locales (de .../gimpprint-locales_4.2.7-4_all .deb) ... Seleccionando el paquete cupsys-bsd previamente no seleccionado. Desempaquetando cupsys-bsd (de .../cupsys-bsd_1.1.20final+rc1-9_i386.de b) ... Configurando foomatic-filters (3.0.2-1) ... Creating config file /etc/foomatic/filter.conf with new version Configurando foomatic-db (20041013-1) ... Configurando foomatic-db-engine (3.0.2-2) ... Configurando foomatic-filters-ppds (20041013-1) ... invoke-rc.d: unknown initscript, /etc/init.d/cupsys not found. Configurando cupsomatic-ppd (20041013-1) ... Configurando libcupsimage2 (1.1.20final+rc1-9) ... Configurando gs-esp (7.07.1-9) ... Configurando cupsys (1.1.20final+rc1-9) ... Adding group `lpadmin' (116)... Hecho. Starting printing system service: cupsd. Configurando cupsys-client (1.1.20final+rc1-9) ... Configurando hpijs (1.6.2-1) ... Configurando foomatic-db-hpijs (1.5-20041013-1) ... Configurando foomatic-bin (3.0.2-2) ... Configurando libijs-0.35 (0.35-1) ... Configurando ijsgimpprint (4.2.7-4) ... Configurando foomatic-db-gimp-print (4.2.7-4) ... Configurando gimpprint-locales (4.2.7-4) ... Configurando cupsys-bsd (1.1.20final+rc1-9) ... Configurando cupsys-driver-gimpprint-data (4.2.7-4) ... Configurando cupsys-driver-gimpprint (4.2.7-4) ... No Gimp-Print PPD files to update. Reloading printing system service: cupsd. _________________________________________________________ 14.3.1. Instalación del paquete cups-pdf Esta sección está dedicada a la instalación de lo que será la impresora del proyecto. Como ya se ha comentado anteriormente (Sección 14.2.7), el paquete cups-pdf añadirá un nuevo backend al servidor CUPS, desde el cual se podrán crear impresoras virtuales. Estas impresoras convertirán los trabajos de impresión a archivos PDF. El siguiente ejemplo muestra el proceso de instalación de este paquete: Ejemplo 14-20. Instalación del paquete cups-pdf # /usr/bin/apt-get install cups-pdf Leyendo lista de paquetes... Hecho Creando árbol de dependencias... Hecho Paquetes sugeridos: gnome-cups-manager Se instalarán los siguientes paquetes NUEVOS: cups-pdf 0 actualizados, 1 se instalarán, 0 para eliminar y 2 no actualizados. Se necesita descargar 0B/15,4kB de archivos. Se utilizarán 106kB de espacio de disco adicional después de desempaque tar. Seleccionando el paquete cups-pdf previamente no seleccionado. (Leyendo la base de datos ... 140777 ficheros y directorios instalados actualmente.) Desempaquetando cups-pdf (de .../cups-pdf_1.6.3-1_i386.deb) ... Configurando cups-pdf (1.6.3-1) ... Restarting printing system service: cupsd. Los documentos PDF generados por las impresoras virtuales se almacenarán en el directorio: $HOME/cups-pdf. (Más datos en /usr/share/doc/cups-pdf/README.Debian). Con este paquete finalizaría la parte de instalación de CUPS, en las siguientes secciones se verán las modificaciones y configuración que se han de realizar al sistema. _________________________________________________________ Capítulo 15. Configuración 15.1. Introducción Este capítulo comienza con la realización de unas comprobaciones en el sistema relacionadas con Samba. Luego se configurarán algunos aspectos necesarios para la integración de CUPS en LDAP, la interactuación con los clientes MS Windows, etc. Y finalmente, se simulará la siguiente red de impresión: Figura 15-1. Estructura de la red de impresión [cups-red-impresoras.png] Red de impresión que se simulará en CUPS. Esta red está formada por tres laboratorios, en los cuales hay una serie de impresoras. La interconexión de los laboratorios se ha realizado mediante cable y red inalámbrica. Las impresoras se han agrupado en 5 clases, como se puede observar en la imagen. Las clases de impresoras definidas en este ejemplo no serían muy útiles en un entorno real por diversos motivos; pero sirvan para ilustrar su funcionamiento. Si quiere obtener el código fuente de esta imagen, generado con el programa de diagramas Dia, pulse aquí. Nota La bibliografía consultada, mayoritariamente, para la realización de este capítulo ha sido: el capítulo 18 de la entrada bibliográfica VernooijTerpstraCarter01 y la entrada bibliográfica CUPS02. _________________________________________________________ 15.2. Comprobaciones iniciales Antes de proceder con la configuración de CUPS, se va a comprobar que el servidor Samba está preparado para funcionar junto con CUPS. Esta comprobación se realizará con la orden ldd, que nos mostrará las librerías compartidas que utiliza el demonio smbd, en este caso. Si entre estas librerías se encuentra la de CUPS, es que Samba ha sido compilado con soporte para este sistema de impresión: Ejemplo 15-1. Verificando que Samba se ha compilado con soporte para CUPS $ /usr/bin/ldd `which smbd` | /bin/grep "cups" libcups.so.2 => /usr/lib/libcups.so.2 (0x40109000) Con el ejemplo anterior se comprueba que Samba ha sido compilado con soporte para CUPS. El siguiente paso va a ser el reinicio de Samba, para comprobar que ya no da error al no encontrar un servidor CUPS en el sistema (vea Samba no puede contactar con el servidor CUPS para más detalles). El procedimiento para reiniciar Samba está descrito en el Ejemplo 11-3. Una vez se ha reiniciado el servidor Samba, se analiza el archivo de log /var/log/samba/log.smbd para ver si se produce algún error relacionado con CUPS, como ocurría en: Samba no puede contactar con el servidor CUPS: [2004/10/09 20:13:22, 0] smbd/server.c:main(760) smbd version 3.0.7-Debian started. Copyright Andrew Tridgell and the Samba Team 1992-2004 Se puede comprobar, que ahora ya no se produce ningún error en el arranque del demonio smbd al disponer el sistema de un servidor de impresión CUPS. _________________________________________________________ 15.3. Modificaciones en la configuración del sistema Para conseguir integrar CUPS en el sistema, tal y como se ha configurado hasta el momento, es necesario realizar algunas modificaciones, que se muestran en las siguientes secciones. _________________________________________________________ 15.3.1. Modificaciones de PAM Se ha de añadir al sistema de autentificación de CUPS, la posibilidad de utilizar usuarios almacenados en la base de datos de LDAP. Esto se realiza en el archivo /etc/pam.d/cupsys. Si se echa un vistazo a su contenido, se comprobará que no es necesario realizar ninguna modificación al mismo, ya que en la Sección 5.3.3 se han realizado todas las modificaciones necesarias. @include common-auth @include common-account @include common-session _________________________________________________________ 15.3.2. Modificaciones en Samba Es necesario realizar una pequeña revisión en la configuración de Samba, los cambios se muestran a continuación: Ejemplo 15-2. Diferencia entre la configuración de Samba antes y después de instalar CUPS $ /usr/bin/diff -u /etc/samba/smb.conf-antes /etc/samba/smb.conf --- /etc/samba/smb.conf-antes 2004-06-15 16:17:19.000000000 +0100 +++ /etc/samba/smb.conf 2004-06-15 16:15:48.000000000 +0100 @@ -188,7 +188,7 @@ # When using [print$], root is implicitly a 'printer admin', but you c an # also give this right to other users to add drivers and set printer # properties - printer admin = @domainadmins + printer admin = @domainprintoperator (1) ######## File sharing ######## @@ -327,13 +327,15 @@ [printers] comment = All Printers - path = /tmp + path = /var/spool/samba (2) browseable = no public = yes guest ok = no writable = no printable = yes create mask = 0700 + use client driver = no (3) + printer admin = root, @domainprintoperator (4) # Windows clients look for this share name as a source of downloadable # printer drivers @@ -343,7 +345,7 @@ browseable = yes guest ok = no read only = yes - write list = root, @domainadmins + write list = root, @domainprintoperator (5) [tmp] comment = Temporal (2) Se modifica la ruta de la cola de impresión de Samba. Este es un cambio puramente estético. Si no existe el directorio de la cola de impresión para Samba, se tendrá que crear en este momento. Aviso Tenga especial cuidado con los permisos que le asigna al directorio /var/spool/samba; tenga en cuenta, que todo usuario que quiera imprimir en una impresora compartida por Samba, ha de tener permisos de escritura en dicho directorio. En este caso, el directorio tiene los siguientes permisos: $ /bin/ls -ld /var/spool/samba drwxrws--- 2 root domainpoweruser 48 \ 2004-10-09 20:28 /var/spool/samba Note que se ha utilizado el grupo domainpoweruser, grupo al que han de pertenecer aquellos usuarios que quieran imprimir vía Samba. (3) Para saber más acerca de esta opción, se recomienda la lectura de la sección "Raw Print Serving Vendor Drivers on Windows Clients" y "How to Recognize If cupsaddsmb Completed Successfully" del capítulo 18 (CUPS Printing Support) de la entrada bibliográfica VernooijTerpstraCarter01; así como la página del manual smb.conf(5). El valor de esta opción dependerá del comportamiento de su sistema. (1) (4) (5) En el Grupos adicionales para Samba se propone la opción de añadir los grupos de usuarios listados en el archivo template_config.php de la aplicación phpLDAPadmin. Esos grupos ya existen en el sistema empleado para la elaboración de esta documentación, por lo que se hará uso de ellos. Se selecciona el grupo más adecuado, "domainprintoperator", para la administración de las impresoras. Una vez modificada la configuración de Samba, este servidor ha de releer su configuración. En el Ejemplo 11-2 se muestra como hacerlo. _________________________________________________________ 15.3.3. Modificaciones relativas a CUPS Nota Para realizar esta sección se ha consultado, principalmente, la entrada bibliográfica CUPS02. _________________________________________________________ 15.3.3.1. Archivo /etc/cups/client.conf En este archivo se descomentarán dos líneas, la primera hace referencia al servidor donde está instalado CUPS y la segunda al uso o no de cifrado: ServerName gsr.pt (1) Encryption Required (2) (1) Se especifica donde está alojado el servidor CUPS. (2) Se hace uso del cifrado TLS en las comunicaciones. Nota En el Apéndice AE tiene un ejemplo completo de este archivo de configuración. _________________________________________________________ 15.3.3.2. Archivo /etc/cups/cupsd.conf El archivo de configuración cupsd.conf está estructurado en secciones, por este motivo, las opciones de configuración más importantes se irán mostrando en sucesivas secciones, que se corresponderán con las secciones del archivo tratado. Nota En el Apéndice AF tiene un ejemplo completo de este archivo de configuración. _________________________________________________________ 15.3.3.2.1. Server Identity ServerName gsr.pt (1) ServerAdmin sergio@gsr.pt (2) (1) Nombre del servidor donde está alojado CUPS. (2) Dirección de correo del administrador de impresión. _________________________________________________________ 15.3.3.2.2. Encryption Support Se han utilizado los mismos certificados creados en la Sección 4.2.2, por este motivo se ha copiado el directorio /etc/ldap/ssl/ a /etc/cups. Ejemplo 15-3. Copiando el contenido del directorio /etc/ldap/ssl/ a /etc/cups # /bin/cp -va /etc/ldap/ssl/ /etc/cups/ «/etc/ldap/ssl/» -> «/etc/cups/ssl» «/etc/ldap/ssl/crl» -> «/etc/cups/ssl/crl» «/etc/ldap/ssl/certs» -> «/etc/cups/ssl/certs» «/etc/ldap/ssl/certs/servidorcert.pem» -> «/etc/cups/ssl/certs/servidor cert.pem» «/etc/ldap/ssl/index.txt.old» -> «/etc/cups/ssl/index.txt.old» «/etc/ldap/ssl/index.txt» -> «/etc/cups/ssl/index.txt» «/etc/ldap/ssl/serial.old» -> «/etc/cups/ssl/serial.old» «/etc/ldap/ssl/serial» -> «/etc/cups/ssl/serial» «/etc/ldap/ssl/newcerts» -> «/etc/cups/ssl/newcerts» «/etc/ldap/ssl/newcerts/01.pem» -> «/etc/cups/ssl/newcerts/01.pem» «/etc/ldap/ssl/cacert.pem» -> «/etc/cups/ssl/cacert.pem» «/etc/ldap/ssl/index.txt.attr» -> «/etc/cups/ssl/index.txt.attr» «/etc/ldap/ssl/private» -> «/etc/cups/ssl/private» «/etc/ldap/ssl/private/cakey.pem» -> «/etc/cups/ssl/private/cakey.pem» «/etc/ldap/ssl/private/servidorkey.pem» -> «/etc/cups/ssl/private/servi dorkey.pem» # /bin/chown root.lpadmin -vR /etc/cups/ssl cambiado el propietario de «/etc/cups/ssl» a root:lpadmin cambiado el propietario de «/etc/cups/ssl/crl» a root:lpadmin cambiado el propietario de «/etc/cups/ssl/certs» a root:lpadmin cambiado el propietario de «/etc/cups/ssl/certs/servidorcert.pem» a roo t:lpadmin cambiado el propietario de «/etc/cups/ssl/index.txt.old» a root:lpadmin cambiado el propietario de «/etc/cups/ssl/index.txt» a root:lpadmin cambiado el propietario de «/etc/cups/ssl/serial.old» a root:lpadmin cambiado el propietario de «/etc/cups/ssl/serial» a root:lpadmin cambiado el propietario de «/etc/cups/ssl/newcerts» a root:lpadmin cambiado el propietario de «/etc/cups/ssl/newcerts/01.pem» a root:lpadm in cambiado el propietario de «/etc/cups/ssl/cacert.pem» a root:lpadmin cambiado el propietario de «/etc/cups/ssl/index.txt.attr» a root:lpadmi n cambiado el propietario de «/etc/cups/ssl/private» a root:lpadmin cambiado el propietario de «/etc/cups/ssl/private/cakey.pem» a root:lpa dmin cambiado el propietario de «/etc/cups/ssl/private/servidorkey.pem» a ro ot:lpadmin Las opciones de configuración, por tanto, quedarían de la siguiente forma: ServerCertificate /etc/cups/ssl/certs/servidorcert.pem ServerKey /etc/cups/ssl/private/servidorkey.pem _________________________________________________________ 15.3.3.2.3. Network Options Se especifica donde ha de escuchar el servidor CUPS y en que puertos: Listen gsr.pt:631 (1) SSLListen gsr.pt:6443 (2) (1) Puerto por defecto, destinado a las conexiones sin cifrado. (2) Puerto destinado a las conexiones con cifrado. Si su sistema no posee el puerto 443 ocupado, sería recomendable utilizarlo. _________________________________________________________ 15.3.3.2.4. Security Options La única modificación que se realizará en esta sección, será obligar a aquellos directorios que precisan autentificación para su acceso, a hacer uso de cifrado. Para ello se utilizará la directiva Encryption Required. AuthType Basic AuthClass User Encryption Required AuthType Basic AuthClass System Order Deny,Allow Deny From All Allow From 127.0.0.1 Encryption Required _________________________________________________________ 15.3.3.3. Reinicio del servidor CUPS Una vez se ha finalizado la configuración de CUPS, se ha de reiniciar el servidor, para que relea su configuración: Ejemplo 15-4. Reinicio del servidor CUPS # /etc/init.d/cupsys restart Restarting printing system service: cupsd. _________________________________________________________ 15.4. Creación de la estructura de impresión En la introducción de este capítulo (Sección 15.1) se mostró la estructura de la red de impresión que se va a simular en esta documentación. De forma simplificada, se crearán siete impresoras[33] y cinco clases. En las dos siguientes secciones se mostrará la forma de hacer esto, respectivamente. _________________________________________________________ 15.4.1. Creación de las impresoras Las impresoras que se van a crear a continuación son todas del mismo tipo: impresoras PDF virtuales; el único elemento diferenciador entre ellas será su nombre. Los nombres de las impresoras serán: * LaserColor * LaserBN * Plotter * InyeccionColor * InyeccionBN * Sublimacion * Multifuncion Las dos secciones siguientes mostrarán como añadir una impresora desde la interfaz de administración web de CUPS y desde el frontend que provee el escritorio KDE para la administración de impresoras. _________________________________________________________ 15.4.1.1. Añadiendo una impresora desde la interfaz de administración web de CUPS En esta sección se mostrará el proceso seguido para añadir una impresora desde la interfaz de administración web de CUPS. Figura 15-2. Accediendo a la interfaz de administración web de CUPS [cupsys-aniadir-impresora1.png] Si se encuentra en un entorno de escritorio KDE, teclee Alt+F2 e introduzca la dirección donde se encuentre instalado CUPS seguido del puerto donde está escuchando. En este caso: https://gsr.pt:6443. Nota Si se fija en la URL que se ha tecleado, se ha especificado el protocolo https y el puerto de conexión segura de CUPS. Esto es necesario si se quiere hacer uso de cifrado en las comunicaciones con CUPS. Si no accede de esta forma a la interfaz web de CUPS, no podrá realizar labores de administración, ya que se ha obligado en los archivos de configuración de CUPS, al uso de cifrado en las secciones de administración. Figura 15-3. Aviso acerca del certificado del servidor web I [lam-configuracion-certificado1.png] Como se ha accedido a la interfaz web de CUPS vía el puerto seguro y debido a que la entidad certificadora que se ha creado para las conexiones SSL/TLS es desconocida, sale este aviso. Pulse sobre el botón Detalles para obtener más información. Figura 15-4. Información SSL [lam-configuracion-certificado2.png] En esta pantalla se muestra la información del certificado y la entidad certificadora que ha creado dicho certificado. Pulse sobre el botón Cerrar para continuar. Figura 15-5. Aviso acerca del certificado del servidor web II [lam-configuracion-certificado3.png] Pulse ahora sobre el botón Continuar para seguir con la carga de la página. Figura 15-6. Período de aceptación del certificado [lam-configuracion-certificado4.png] Seleccione la opción deseada y pulse sobre ella. Figura 15-7. Administrando impresoras [cupsys-aniadir-impresora2.png] Una vez se tenga acceso al interfaz de administración web de CUPS, pulse sobre el enlace "Manage Printers". Figura 15-8. Añadir nueva impresora [cupsys-aniadir-impresora3.png] Pulse sobre el botón "Add Printer" para comenzar el proceso de adición de una impresora al sistema. Figura 15-9. Clave del administrador [cupsys-aniadir-impresora4.png] Introduzca un usuario con permisos de administración para el sistema de impresión, así como su clave. Figura 15-10. Información sobre la impresora [cupsys-aniadir-impresora5.png] Teclee el nombre, la localización y una breve descripción de la nueva impresora. Procure no introducir caracteres especiales ni espacios en el nombre de la impresora. Figura 15-11. Dispositivo de impresión I [cupsys-aniadir-impresora6.png] Seleccione el tipo Virtual Printer (PDF Printer) como dispositivo de impresión... Aviso En las pruebas realizadas desde la interfaz web de CUPS por el puerto seguro 6443, no se ha conseguido que se muestren los dispositivos de impresión disponibles en el sistema. Por este motivo se ha seguido, a partir de este punto, la configuración por el puerto estándar: el 631. Para conseguir esto, se han de comentar (o cambiar al valor adecuado) las directivas Encryption de los directorios /admin y /jobs del archivo de configuración /etc/cups/cupsd.conf (más datos sobre estas directivas en la Sección 15.3.3.2.4). Figura 15-12. Dispositivo de impresión II [cupsys-aniadir-impresora7.png] ... y pulse sobre el botón "Continue". Figura 15-13. Modelo [cupsys-aniadir-impresora8.png] Seleccione el modelo "Postsript" y pulse sobre el botón "Continue". Figura 15-14. Controlador [cupsys-aniadir-impresora9.png] Seleccione el controlador "Generic postscript color printer (en)" como controlador para la nueva impresora. Figura 15-15. Nueva impresora lista [cupsys-aniadir-impresora10.png] Esta pantalla informa que se acaba de crear satisfactoriamente la nueva impresora. Para ver los detalles de la misma, pulse sobre el enlace "LaserColor". Figura 15-16. Información sobre la impresora LaserColor [cupsys-aniadir-impresora11.png] Desde esta ventana se puede realizar la administración de la impresora LaserColor, así como observar el estado de la misma en un momento determinado. _________________________________________________________ 15.4.1.2. Añadiendo una impresora desde KDE En esta sección se mostrará el proceso seguido para añadir una impresora desde el administrador de impresión de KDE. Figura 15-17. Arrancando el administrador de impresión [cupsys-aniadir-impresora12.png] Acceda al menú de KDE, y seleccione la herramienta Administrador de impresión desde el mismo; o bien teclee la orden /usr/bin/kcmshell printers. Figura 15-18. Administrador de impresión [cupsys-aniadir-impresora13.png] Una vez arrancado el administrador de impresión de KDE, ha de asegurarse que la opción del campo: Sistema de impresión actualmente usado es el sistema de impresión CUPS. Si se fija en la imagen, bajo el directorio impresoras aparece la impresora LaserColor, que se añadió en la sección anterior (Sección 15.4.1.1). Figura 15-19. Nueva impresora [cupsys-aniadir-impresora14.png] Para añadir una nueva impresora, pulse sobre el botón "Añadir" y seguidamente sobre la opción Añadir impresora/clase... Figura 15-20. Bienvenida al asistente de impresión de KDE [cupsys-aniadir-impresora15.png] Esta pantalla nos da la bienvenida al asistente que guiará el proceso de adición de una nueva impresora al sistema. Pulse sobre el botón "Siguiente" para continuar. Figura 15-21. Selección del tipo de impresora [cupsys-aniadir-impresora16.png] En esta pantalla se selecciona el tipo de impresora que se va a añadir al sistema. En este caso, se va a añadir una impresora virtual, por lo que se selecciona la opción Otro tipo de impresora y se pulsa sobre el botón "Siguiente". Figura 15-22. URI de la impresora [cupsys-aniadir-impresora17.png] Seleccione el tipo Virtual Printer (PDF Printer) y pulse sobre el botón "Siguiente". Figura 15-23. Reconstruyendo la base de datos de controladores [cupsys-aniadir-impresora18.png] Espere a que se finalice la reconstrucción de la base de datos de controladores de impresión. Figura 15-24. Modelo de la impresora [cupsys-aniadir-impresora19.png] Seleccione el fabricante "POSTSCRIPT" y el modelo "Generic postscript color printer" y pulse sobre el botón "Siguiente" para continuar. Figura 15-25. Probando la impresora I [cupsys-aniadir-impresora20.png] Desde esta pantalla se permite realizar pruebas con la configuración de la impresora que se está añadiendo, antes de añadirla definitivamente al sistema. Pulse sobre el botón "Preferencias..." Figura 15-26. Opciones de configuración del controlador de impresión [cupsys-aniadir-impresora21.png] Dependiendo del controlador de impresión elegido, en esta pantalla aparecerán unas opciones u otras. En el caso de la impresora virtual, esta pantalla muestra las opciones que soporta el controlador, pudiendo variar dichas opciones para adaptarlas a las necesidades del sistema. Una vez cambiadas las opciones, pulse sobre el botón "Aceptar" para continuar. Figura 15-27. Probando la impresora II [cupsys-aniadir-impresora20.png] Pulse ahora sobre el botón "Probar" Figura 15-28. Usuario con privilegios de administración de impresión [cupsys-aniadir-impresora22.png] Teclee los datos de un usuario con privilegios de administración de impresión y pulse sobe el botón "Aceptar". Figura 15-29. Prueba enviada a la impresora [cupsys-aniadir-impresora23.png] Esta pantalla nos informa de que se ha enviado la prueba de impresión a la impresora. Pulse sobre el botón "Aceptar" para continuar. Si todo ha ido bien, en el home del usuario que se ha tecleado, aparecerá un nuevo directorio, $HOME/cups-pdf y dentro de este un archivo similar a Test_Page.pdf. Si se abre este archivo con un visualizador de archivos PDF, se podrá comprobar que es una prueba de impresión de CUPS. Figura 15-30. Prueba de impresión [cupsys-aniadir-impresora24.png] En esta pantalla se puede observar la prueba de impresión que se ha realizado en la imagen anterior. Figura 15-31. Selección de rótulos [cupsys-aniadir-impresora25.png] CUPS permite imprimir páginas separadoras para los trabajos de impresión. Si desea hacer uso de esta característica, seleccione los rótulos que desee en esta pantalla, en caso contrario, pulse directamente sobre el botón "Siguiente". Figura 15-32. Cuotas de impresión [cupsys-aniadir-impresora26.png] CUPS implemente un rudimentario sistema de cuotas de impresión. Como se va a hacer uso de PyKota para la administración de cuotas, esta opción no se utilizará. Pulse el botón "Siguiente" para continuar. Figura 15-33. Permisos de acceso a la impresora [cupsys-aniadir-impresora27.png] En esta pantalla se seleccionan los usuarios a los que se les permite, o no, imprimir. Como este control se realizará con la herramienta PyKota, pulse sobre el botón "Siguiente" directamente. Figura 15-34. Información sobre la impresora [cupsys-aniadir-impresora28.png] Complete los campos con el nombre, ubicación y descripción para la impresora que se está añadiendo. Pulse sobre el botón "Siguiente" para continuar. Figura 15-35. Confirmación [cupsys-aniadir-impresora29.png] Esta es la última pantalla antes de crear la nueva impresora. Revise la información sobre la misma, y si todo está correcto, pulse sobre el botón "Finalizar" para crear la impresora. Figura 15-36. Nueva impresora LaserBN [cupsys-aniadir-impresora30.png] Se puede apreciar en el directorio de impresoras la aparición de una nueva entrada, en este caso la impresora LaserBN. _________________________________________________________ 15.4.1.3. Añadiendo el resto de impresoras El proceso de creación de nuevas impresoras se ha realizado para cada una de las impresoras que se muestran en el esquema de la Sección 15.1, obteniendo finalmente: Figura 15-37. Listado de impresoras [cupsys-aniadir-impresora31.png] Impresoras que conforman la red organizacional del esquema mostrado en la Sección 15.1. _________________________________________________________ 15.4.2. Creación de las clases Al igual que ya se hizo en la Sección 15.4.1 con las impresoras, en esta sección se añadirán las clases. Los nombres y el contenido de las clases será: * Profesional: Plotter, Sublimacion, LaserColor * Color: LaserColor, InyeccionColor * BlancoNegro: LaserBN, InyeccionBN * Barato: Multifuncion, InyeccionBN * Laser: LaserColor, LaserBN Las dos siguientes secciones mostrarán como añadir una clase desde la interfaz de administración web de CUPS y desde el frontend que provee el escritorio KDE para la administración de impresoras. _________________________________________________________ 15.4.2.1. Añadiendo una clase desde la interfaz de administración web de CUPS En esta sección se mostrará el proceso seguido para añadir una clase desde la interfaz de administración web de CUPS. Figura 15-38. Accediendo a la interfaz de administración web de CUPS [cupsys-aniadir-impresora1.png] Si se encuentra en un entorno de escritorio KDE, teclee Alt+F2 e introduzca la dirección donde se encuentre instalado CUPS seguido del puerto donde está escuchando. En este caso: https://gsr.pt:6443. Nota Si se fija en la URL que se ha tecleado, se ha especificado el protocolo https y el puerto de conexión segura de CUPS. Esto es necesario si se quiere hacer uso de cifrado en las comunicaciones con CUPS. Si no accede de esta forma a la interfaz web de CUPS, no podrá realizar labores de administración, ya que se ha obligado en los archivos de configuración de CUPS, al uso de cifrado en las secciones de administración. Figura 15-39. Aviso acerca del certificado del servidor web I [lam-configuracion-certificado1.png] Como se ha accedido a la interfaz web de CUPS vía el puerto seguro y debido a que la entidad certificadora que se ha creado para las conexiones SSL/TLS es desconocida, sale este aviso. Pulse sobre el botón Detalles para obtener más información. Figura 15-40. Información SSL [lam-configuracion-certificado2.png] En esta pantalla se muestra la información del certificado y la entidad certificadora que ha creado dicho certificado. Pulse sobre el botón Cerrar para continuar. Figura 15-41. Aviso acerca del certificado del servidor web II [lam-configuracion-certificado3.png] Pulse ahora sobre el botón Continuar para seguir con la carga de la página. Figura 15-42. Período de aceptación del certificado [lam-configuracion-certificado4.png] Seleccione la opción deseada y pulse sobre ella. Figura 15-43. Administrando clases [cupsys-aniadir-impresora2.png] Una vez se tenga acceso al interfaz de administración web de CUPS, pulse sobre el enlace "Do Administration Tasks". Figura 15-44. Clave del administrador [cupsys-aniadir-impresora4.png] Introduzca un usuario con permisos de administración para el sistema de impresión, así como su clave. Figura 15-45. Añadiendo una clase [cupsys-aniadir-clase1.png] Para comenzar el proceso de adición de una clase, pulse sobre el botón "Add Class". Figura 15-46. Información sobre la clase [cupsys-aniadir-clase2.png] Teclee la información relativa a la clase y pulse sobre el botón "Continue". Figura 15-47. Miembros de la clase [cupsys-aniadir-clase3.png] Seleccione las impresoras que van a pertenecer a la clase y pulse sobre el botón "Continue". Aviso En las pruebas realizadas desde la interfaz web de CUPS por el puerto seguro 6443, no se ha conseguido que se muestren las impresoras existentes. Por este motivo se ha seguido, a partir de este punto, la configuración por el puerto estandar: el 631. Para conseguir esto, se han de comentar (o cambiar al valor adecuado) las directivas Encryption de los directorios /admin y /jobs del archivo de configuración /etc/cups/cupsd.conf (más datos sobre estas directivas en la Sección 15.3.3.2.4). Figura 15-48. Nueva clase lista [cupsys-aniadir-clase4.png] Esta pantalla informa que se acaba de crear satisfactoriamente la nueva clase. Para ver los detalles de la misma, pulse sobre el enlace "Profesional". Figura 15-49. Información sobre la clase Profesional [cupsys-aniadir-clase5.png] Desde esta ventana se puede realizar la administración de la clase Profesional. _________________________________________________________ 15.4.2.2. Añadiendo una clase desde KDE En esta sección se mostrará el proceso seguido para añadir una clase desde la el administrador de impresión de KDE. Figura 15-50. Arrancando el administrador de impresión [cupsys-aniadir-impresora12.png] Acceda al menú de KDE, y seleccione la herramienta Administrador de impresión desde el mismo; o bien teclee la orden /usr/bin/kcmshell printers. Figura 15-51. Administrador de impresión [cupsys-aniadir-clase6.png] En esta pantalla se puede observar el estado actual del sistema de impresión. A parte de las impresoras que se han añadido anteriormente aparece también la nueva clase que se acaba de añadir. Figura 15-52. Nueva clase [cupsys-aniadir-clase7.png] Para añadir una nueva clase, pulse sobre el botón "Añadir" y seguidamente sobre la opción Añadir impresora/clase... Figura 15-53. Bienvenida al asistente de impresión de KDE [cupsys-aniadir-impresora15.png] Esta pantalla nos da la bienvenida al asistente que guiará el proceso de adición de una nueva clase al sistema. Pulse sobre el botón "Siguiente" para continuar. Figura 15-54. Selección de la clase impresora [cupsys-aniadir-clase8.png] En esta pantalla se selecciona el tipo de impresora que se va a añadir al sistema. En este caso, se va a añadir una clase de impresora, por lo que se selecciona la opción Clase de impresora y se pulsa sobre el botón "Siguiente". Figura 15-55. Composición de la clase [cupsys-aniadir-clase9.png] Seleccione las impresoras que formarán parte de la clase que se está creando. Una vez seleccionadas, pulse sobre el botón "Siguiente" para continuar. Figura 15-56. Información sobre la clase [cupsys-aniadir-clase10.png] Complete la información relativa a la nueva clase, y pulse sobre el botón "Siguiente" para continuar. Figura 15-57. Confirmación de la creación de la nueva clase [cupsys-aniadir-clase11.png] Antes de añadir la nueva clase al sistema, revise los datos de la misma, y una vez esté seguro de que todo está correcto, pulse sobre el botón "Finalizar", lo que creará la nueva clase en el sistema. Figura 15-58. Nueva clase Color [cupsys-aniadir-clase12.png] Se puede apreciar en el directorio de clases la aparición de una nueva entrada, en este caso la clase Color. _________________________________________________________ 15.4.2.3. Añadiendo el resto de clases El proceso de creación de nuevas clases se ha realizado para cada una de las clases que se muestran en el esquema de la Sección 15.1, obteniéndose finalmente: Figura 15-59. Listado de clases [cupsys-aniadir-clase13.png] Clases que conforman la red organizacional del esquema mostrado en la Sección 15.1. _________________________________________________________ 15.4.2.4. Probando la impresión en las clases A continuación se realizará una prueba de impresión sobre una clase de impresoras, para comprobar que funciona. Para ello, ejecute el administrador de impresión de KDE y seleccione la clase sobre la cual quiera hacer la prueba. Figura 15-60. Realizando una prueba de impresión sobre una clase [cupsys-prueba-impresion1.png] Seleccione una clase sobre la cual realizar la prueba de impresión, y luego acceda a la pestaña Instancias y pulse sobre el botón "Probar..." Esta acción enviará una prueba de impresión a la clase que haya seleccionado. Figura 15-61. Confirmación del envío de la prueba de impresión [cupsys-prueba-impresion2.png] El sistema pide confirmación para realizar la prueba de impresión, pulse sobre "Imprimir página de prueba" para continuar. Figura 15-62. Información de envío [cupsys-prueba-impresion3.png] El sistema informa de que la página de prueba ha sido enviada a la clase seleccionada. Si ahora echa un vistazo a los logs de CUPS, más concretamente al archivo de log /var/log/cups/page_log, ha de ver una entrada similar a: Sublimacion sergio 2 [10/Oct/2004:19:52:05 +0200] 1 1 - localhost Finalmente, si mira en el directorio cups-pdf localizado en el HOME del usuario que ha realizado la prueba de impresión, tendrá que ver un archivo PDF denominado Test_Page.pdf, cuyo contenido será similar al mostrado en la imagen Prueba de impresión. _________________________________________________________ 15.5. Instalación de los controladores de impresión para los equipos MS Windows CUPS no da soporte, directamente, a los clientes MS Windows; para ello se ha de hacer uso de Samba. La forma de hacerlo, es compartiendo las impresoras gestionadas por CUPS en Samba, como ya se ha visto en los capítulos dedicados a Samba (Parte II en Integración de redes con OpenLDAP, Samba, CUPS y PyKota). En esta sección se verá la forma de exportar los controladores de impresión para los equipos MS Windows. Los controladores se almacenan en la instalación de CUPS, y se comparten, vía Samba, con los clientes MS Windows. Para realizar esta labor, se puede hacer uso de la herramienta cupsaddsmb. cupsaddsmb transfiere los controladores de impresión al recurso Samba [print$]. Recuerde que los clientes esperan tener los controladores almacenados en este recurso, al que accederán en el momento de la instalación para bajarse los controladores de impresión. cupsaddsmb facilita la compartición de cualquier (o todas) impresora CUPS instalada en el sistema. También puede utilizar los controladores PostScript de Adobe así como los controladores PostScript de CUPS para Windows NT/2000/XP. Los controladores de impresión de CUPS se pueden obtener desde la sección download de la página de CUPS. El paquete de controladores se denomina cups-samba-[version].tar.gz. Actualmente, CUPS provee controladores para los clientes Windows NT, 2000 y XP, pero no para los clientes Windows 95, 98 y ME. Estos últimos han de utilizar los drivers que provee Adobe. Antes de poder exportar los controladores de impresión, estos se han de ubicar en el directorio /usr/share/cups/drivers/. Las siguientes secciones mostrarán como "instalar" los controladores PostScript de CUPS y Adobe en este directorio. _________________________________________________________ 15.5.1. Instalación de los controladores PostScript de CUPS para Windows NT/2000/XP Antes de proceder con la instalación, ha de bajarse los controladores de la página de CUPS[34]. Se supone que el paquete con los controladores se encuentra en el directorio /tmp, por lo que se procederá, en primer lugar, a su desempaquetado: Ejemplo 15-5. Desempaquetado de los controladores PostScript de CUPS $ /bin/tar xzvf /tmp/cups-samba-5.0rc3.tar.gz -C /tmp cups-samba.install cups-samba.license cups-samba.readme cups-samba.remove cups-samba.ss Como el proceso de instalación de los controladores PostScript de CUPS es muy sencillo, no se va a utilizar el script de instalación, cups-samba.install, que adjuntan. El archivo cups-samba.ss no es más que un archivo tar[35], cuyo contenido son los controladores en cuestión. Por este motivo se desempaquetará en el directorio /usr/share/cups/drivers/, como se muestra en el siguiente ejemplo: Ejemplo 15-6. Desempaquetado de los controladores PostScript de CUPS en el directorio /usr/share/cups/drivers/ # /bin/mkdir -v -m 755 /usr/share/cups/drivers/ /bin/mkdir: se ha creado el directorio `/usr/share/cups/drivers/' # /bin/tar xvf /tmp/cups-samba.ss -C / /usr/share/cups/drivers/cups5.hlp /bin/tar: Removing leading `/' from member names /usr/share/cups/drivers/cupsdrv5.dll /usr/share/cups/drivers/cupsui5.dll A partir de este momento ya se encuentran disponibles los controladores PostScript de CUPS para Windows NT/2000/XP disponibles. Ahora sólo queda exportarlos en Samba, operación que se verá más adelante (Sección 15.5.3). _________________________________________________________ 15.5.2. Instalación de los controladores PostScript de Adobe Adobe proporciona controladores PostScript para los sistemas MS Windows 95/98/ME así como para MS Windows NT/2000/XP. Estos se pueden obtener de su página web, http://www.adobe.com/. Los controladores PostScript de Adobe, actualmente, vienen en un archivo autoinstalable para los sistemas MS Windows, por lo que se tendrá que hacer uso de Wine para obtenerlos. En primer lugar se ha de bajar el archivo que los contiene, que en este caso se denomina winstspa.exe (se corresponde con la versión española de estos controladores). Ahora se ha de ejecutar el instalador, para ello se hace uso de wine, como se muestra en el siguiente ejemplo: Nota Se supone que wine ya se encuentra instalado y correctamente configurado. Ejemplo 15-7. Ejecución del instalador de controladores PostScript de Adobe con Wine (primera parte) $ /usr/bin/wine winstspa.exe Tras la ejecución de la orden del ejemplo anterior, comenzará el proceso de instalación de los controladores PostScript de Adobe en el sistema. Vea las siguientes capturas para más detalles: Figura 15-63. Proceso de descompresión de los controladores y archivos de instalación [cupsys-drivers-adobe1.png] Justo después de ejecutar el instalador, se procede a la descompresión de los controladores PostScript y de los archivos necesarios para la instalación en los sistemas MS Windows. Estos archivos son copiados al directorio C:\Windows\Temp\, que en el caso del sistema donde se ha ejecutado Wine, se encuentra bajo el directorio $HOME/.wine/fake_windows/Windows/Temp. El proceso de instalación creará un directorio temporal, cuyo nombre será similar a pft3405~tmp. Este directorio se creará bajo el directorio $HOME/.wine/fake_windows/Windows/Temp, y es ahí de donde se obtendrán los controladores PostScript de Adobe. Figura 15-64. Comienza el proceso de instalación [cupsys-drivers-adobe2.png] Tras descomprimir los archivos necesarios para la instalación, se ejecutará el instalador de los controladores PostScript de Adobe. Figura 15-65. Pantalla de bienvenida del instalador [cupsys-drivers-adobe3.png] Una vez se ha llegado a la pantalla de bienvenida del instalador de los controladores PostScript de Adobe, se puede terminar la ejecución del programa. Importante No cancele la instalación desde el programa de instalación de los controladores (ya que esto haría que se borrasen del sistema), simplemente finalice la ejecución de Wine, bien sea matando el proceso o pulsando la combinación de teclas Ctrl+c, siempre y cuando esté ejecutando Wine desde un terminal, por ejemplo. Ejemplo 15-8. Ejecución del instalador de controladores PostScript de Adobe con Wine (segunda parte) $ /usr/bin/wine winstspa.exe [Ctrl+c] $ cd ~/.wine/fake_windows/Windows/Temp $ /usr/bin/tree . |-- pftc3c~tmp | |-- DATA.TAG | |-- Leame.wri | |-- SETUP.INI | |-- Setup.exe | |-- Win2000 (1) | | |-- DEFPRTR2.PPD | | |-- PS5UI.DLL | | |-- PSCRIPT.HLP | | |-- PSCRIPT.NTF | | |-- PSCRIPT5.DLL | | `-- PSCRPTFE.NTF | |-- WinNT (2) | | |-- ADOBEPSU.HLP | | |-- AdobeJpn.ntf | | |-- AdobeKor.ntf | | |-- AdobePS5.dll | | |-- AdobePS5.ntf | | |-- AdobeZhS.ntf | | |-- AdobeZhT.ntf | | |-- DEFPRTR2.PPD | | `-- adobepsu.dll | |-- WinXP (3) | | |-- DEFPRTR2.PPD | | |-- PS5UI.DLL | | |-- PSCRIPT.HLP | | |-- PSCRIPT.NTF | | |-- PSCRIPT5.DLL | | `-- PSCRPTFE.NTF | |-- Windows (4) | | |-- ADOBEPS4.DRV | | |-- ADOBEPS4.HLP | | |-- DEFPRTR2.PPD | | |-- ICONLIB.DLL | | |-- PSMON.DLL | | `-- adfonts.mfm | |-- _INST32I.EX_ | |-- _ISDel.exe | |-- _Setup.dll | |-- _sys1.cab | |-- _sys1.hdr | |-- _user1.cab | |-- _user1.hdr | |-- data1.cab | |-- data1.hdr | |-- lang.dat | |-- layout.bin | |-- os.dat | |-- pftw1.pkg | |-- setup.bmp | |-- setup.ins | `-- setup.lid `-- plfa2b.tmp 5 directories, 48 files (1) Controladores PostScript de Adobe para MS Windows 2000. (2) Controladores PostScript de Adobe para MS Windows NT. (3) Controladores PostScript de Adobe para MS Windows XP. (4) Controladores PostScript de Adobe para MS Windows 9x. En el Ejemplo 15-8 se ha mostrado el listado de controladores PostScript que provee Adobe. Antes de copiarlos al directorio /usr/share/cups/drivers se van a renombrar, de forma que queden todos los archivos en mayúsculas. El proceso se muestra a continuación: Ejemplo 15-9. Convirtiendo a mayúsculas los controladores PostScript de Adobe En este ejemplo se hace uso del script presente en el Apéndice L. Se supone que el script está almacenado en el directorio /usr/local/bin. $ cd ~/.wine/fake_windows/Windows/Temp/pftc3c~tmp $ for x in "Win2000/* Windows/* WinNT/* WinXP/*"; > do > /bin/bash /usr/local/bin/uppercase $x; > done /usr/local/bin/uppercase: Win2000/DEFPRTR2.PPD not changed. /usr/local/bin/uppercase: Win2000/PS5UI.DLL not changed. /usr/local/bin/uppercase: Win2000/PSCRIPT5.DLL not changed. /usr/local/bin/uppercase: Win2000/PSCRIPT.HLP not changed. /usr/local/bin/uppercase: Win2000/PSCRIPT.NTF not changed. /usr/local/bin/uppercase: Win2000/PSCRPTFE.NTF not changed. /usr/local/bin/uppercase: Windows/adfonts.mfm -> Windows/ADFONTS.MFM /usr/local/bin/uppercase: Windows/ADOBEPS4.DRV not changed. /usr/local/bin/uppercase: Windows/ADOBEPS4.HLP not changed. /usr/local/bin/uppercase: Windows/DEFPRTR2.PPD not changed. /usr/local/bin/uppercase: Windows/ICONLIB.DLL not changed. /usr/local/bin/uppercase: Windows/PSMON.DLL not changed. /usr/local/bin/uppercase: WinNT/AdobeJpn.ntf -> WinNT/ADOBEJPN.NTF /usr/local/bin/uppercase: WinNT/AdobeKor.ntf -> WinNT/ADOBEKOR.NTF /usr/local/bin/uppercase: WinNT/AdobePS5.dll -> WinNT/ADOBEPS5.DLL /usr/local/bin/uppercase: WinNT/AdobePS5.ntf -> WinNT/ADOBEPS5.NTF /usr/local/bin/uppercase: WinNT/adobepsu.dll -> WinNT/ADOBEPSU.DLL /usr/local/bin/uppercase: WinNT/ADOBEPSU.HLP not changed. /usr/local/bin/uppercase: WinNT/AdobeZhS.ntf -> WinNT/ADOBEZHS.NTF /usr/local/bin/uppercase: WinNT/AdobeZhT.ntf -> WinNT/ADOBEZHT.NTF /usr/local/bin/uppercase: WinNT/DEFPRTR2.PPD not changed. /usr/local/bin/uppercase: WinXP/DEFPRTR2.PPD not changed. /usr/local/bin/uppercase: WinXP/PS5UI.DLL not changed. /usr/local/bin/uppercase: WinXP/PSCRIPT5.DLL not changed. /usr/local/bin/uppercase: WinXP/PSCRIPT.HLP not changed. /usr/local/bin/uppercase: WinXP/PSCRIPT.NTF not changed. /usr/local/bin/uppercase: WinXP/PSCRPTFE.NTF not changed. Ahora sólo queda copiar los controladores necesarios al directorio /usr/share/cups/drivers. El siguiente ejemplo muestra como hacerlo: Ejemplo 15-10. Copiando los controladores PostScript de Adobe a /usr/share/cups/drivers Sustituya la variable $HOME, por el directorio home del usuario donde se encuentran los controladores PostScript de Adobe. El contenido del script mover-controladores se encuentra en el Apéndice M. # cd $HOME/.wine/fake_windows/Windows/Temp/pftc3c~tmp # /bin/bash /usr/local/bin/mover-controladores `PATH/Windows/ADFONTS.MFM' -> `/usr/share/cups/drivers/ADFONTS.MFM' `PATH/Windows/ADOBEPS4.DRV' -> `/usr/share/cups/drivers/ADOBEPS4.DRV' `PATH/Windows/ADOBEPS4.HLP' -> `/usr/share/cups/drivers/ADOBEPS4.HLP' `PATH/WinNT/DEFPRTR2.PPD' -> `/usr/share/cups/drivers/DEFPRTR2.PPD' `PATH/WinXP/DEFPRTR2.PPD' -> `/usr/share/cups/drivers/DEFPRTR2.PPD' `PATH/Win2000/DEFPRTR2.PPD' -> `/usr/share/cups/drivers/DEFPRTR2.PPD' `PATH/Windows/DEFPRTR2.PPD' -> `/usr/share/cups/drivers/DEFPRTR2.PPD' `PATH/Windows/ICONLIB.DLL' -> `/usr/share/cups/drivers/ICONLIB.DLL' `PATH/Windows/PSMON.DLL' -> `/usr/share/cups/drivers/PSMON.DLL' `PATH/WinNT/ADOBEPS5.DLL' -> `/usr/share/cups/drivers/ADOBEPS5.DLL' `PATH/WinNT/ADOBEPSU.DLL' -> `/usr/share/cups/drivers/ADOBEPSU.DLL' `PATH/WinNT/ADOBEPSU.HLP' -> `/usr/share/cups/drivers/ADOBEPSU.HLP' el modo de `/usr/share/cups/drivers/ADFONTS.MFM' cambia a 0644 (rw-r--r --) el modo de `/usr/share/cups/drivers/ADOBEPS4.DRV' cambia a 0644 (rw-r-- r--) el modo de `/usr/share/cups/drivers/ADOBEPS4.HLP' cambia a 0644 (rw-r-- r--) el modo de `/usr/share/cups/drivers/ADOBEPS5.DLL' cambia a 0644 (rw-r-- r--) el modo de `/usr/share/cups/drivers/ADOBEPSU.DLL' cambia a 0644 (rw-r-- r--) el modo de `/usr/share/cups/drivers/ADOBEPSU.HLP' cambia a 0644 (rw-r-- r--) el modo de `/usr/share/cups/drivers/cups5.hlp' cambia a 0644 (rw-r--r-- ) el modo de `/usr/share/cups/drivers/cupsdrv5.dll' cambia a 0644 (rw-r-- r--) el modo de `/usr/share/cups/drivers/cupsui5.dll' cambia a 0644 (rw-r--r --) el modo de `/usr/share/cups/drivers/DEFPRTR2.PPD' cambia a 0644 (rw-r-- r--) el modo de `/usr/share/cups/drivers/ICONLIB.DLL' cambia a 0644 (rw-r--r --) el modo de `/usr/share/cups/drivers/PSMON.DLL' cambia a 0644 (rw-r--r-- ) _________________________________________________________ 15.5.3. Exportando los controladores con cupsaddsmb Una vez copiados los controladores de impresión PostScript, tanto de Adobe como de CUPS al directorio /usr/share/cups/drivers/, se han de exportar en Samba; para ello se hará uso de la herramienta cupsaddsmb. A parte de exportar los controladores de Adobe y CUPS, también se exportarán los controladores de las impresoras que se han añadido en la Sección 15.4. Nota Actualmente en el directorio /usr/share/cups/drivers/ se encuentran los controladores PostScript, para MS Windows NT/2000/XP, tanto de CUPS como de Adobe. Al exportar dichos controladores con la herramienta cupsaddsmb, esta priorizará la instalación de los controladores creados por el proyecto CUPS, sobre los creados por Adobe. Esto significa que exportará los controladores del proyecto CUPS para los sistemas operativos MS Windows NT/2000/XP, en lugar de los controladores que provee Adobe; y los controladores de Adobe para los sistemas operativos MS Windows 95/98/ME. El siguiente ejemplo mostrará como realizar esta operación: Ejemplo 15-11. Exportando los controladores de impresión con cupsaddsmb La opción -a le dice a la orden cupsaddsmb que añada todas las impresoras presentes en el sistema. $ /usr/bin/tree /var/lib/samba/printers /var/lib/samba/printers |-- W32X86 `-- WIN40 2 directories, 0 files $ /usr/sbin/cupsaddsmb -U root -a Password for root required to access localhost via SAMBA: [Clave] $ /usr/bin/tree /var/lib/samba/printers /var/lib/samba/printers |-- W32X86 (1) | `-- 2 | |-- InyeccionBN.ppd | |-- InyeccionColor.ppd | |-- LaserBN.ppd | |-- LaserColor.ppd | |-- Multifuncion.ppd | |-- Plotter.ppd | |-- Sublimacion.ppd | |-- cups5.hlp | |-- cupsdrv5.dll | `-- cupsui5.dll `-- WIN40 (2) `-- 0 |-- ADFONTS.MFM |-- ADOBEPS4.DRV |-- ADOBEPS4.HLP |-- DEFPRTR2.PPD |-- ICONLIB.DLL |-- InyeccionBN.PPD |-- InyeccionColor.PPD |-- LaserBN.PPD |-- LaserColor.PPD |-- Multifuncion.PPD |-- PSMON.DLL |-- Plotter.PPD `-- Sublimacion.PPD 4 directories, 23 files (1) Controladores de impresión para MS Windows NT/2000/XP exportados mediante samba, gracias al recurso [print$] (2) Controladores de impresión para MS Windows 95/98/ME exportados mediante samba, gracias al recurso [print$] Nota En el Apéndice N se muestra la ejecución de la orden cupsaddsmb con la opción -v (modo verbose). Una vez finalizada la exportación de los controladores de impresión, ya se tendría el sistema preparado para que los clientes MS Windows hagan uso de las impresoras administradas por CUPS. _________________________________________________________ 15.6. Impresión desde Samba Nota Como para la realización de esta documentación no se ha tenido acceso a un sistema MS Windows, no se ha podido comprobar el funcionamiento de la impresión desde dicho sistema operativo. En esta sección se va a comprobar que las impresoras están realmente presentes en samba, para ello se va a añadir una impresora, compartida por Samba, al sistema. Pero antes de realizar esta operación, se verán los recursos compartidos por Samba, tras la incorporación de CUPS al sistema: Ejemplo 15-12. Recursos compartidos por Samba, tras la instalación de CUPS $ /usr/bin/smbclient -L TODOSCSI -U gsruser Password: [Clave] Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] Sharename Type Comment --------- ---- ------- netlogon Disk Network Logon Service print$ Disk Printer Drivers tmp Disk Temporal cdrom Disk Samba server's CD-ROM IPC$ IPC IPC Service (SAMBA-LDAP PDC server) ADMIN$ IPC IPC Service (SAMBA-LDAP PDC server) InyeccionBN Printer Impresora de inyeccion de tinta a Bla nco y Negro LaserBN Printer Impresora Laser a Blanco y Negro LaserColor Printer Impresora Laser a Color Multifuncion Printer Impresora multifuncion Plotter Printer Plotter de impresion Barato Printer Impresoras para imprimir a bajo coste Sublimacion Printer Impresora de sublimacion BlancoNegro Printer Impresion a Blanco y Negro Color Printer Impresoras a color Laser Printer Impresion a Laser Profesional Printer Impresoras para trabajos de calidad gsruser Disk Home Directories Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] Server Comment --------- ------- TODOSCSI SAMBA-LDAP PDC server Workgroup Master --------- ------- GSRDOMAIN TODOSCSI Se puede comprobar en el ejemplo anterior, que ya se encuentran disponibles varias impresoras en Samba. A continuación se añadirá una impresora, compartida por Samba, al sistema. Para ello se hará uso del administrador de impresión de KDE. Nota Esta operación no tiene mucho sentido en un sistema GNU/Linux, pero sirva este ejemplo como muestra de las posibilidades que brinda el sistema. Figura 15-66. Arrancando el administrador de impresión [cupsys-aniadir-impresora12.png] Acceda al menú de KDE, y seleccione la herramienta Administrador de impresión desde el mismo; o bien teclee la orden /usr/bin/kcmshell printers. Figura 15-67. Nueva impresora [cupsys-aniadir-samba1.png] Para añadir una nueva impresora, pulse sobre el botón "Añadir" y seguidamente sobre la opción Añadir impresora/clase... Figura 15-68. Bienvenida al asistente de impresión de KDE [cupsys-aniadir-impresora15.png] Esta pantalla nos da la bienvenida al asistente que guiará el proceso de adición de una nueva impresora al sistema. Pulse sobre el botón "Siguiente" para continuar. Figura 15-69. Selección del tipo de impresora [cupsys-aniadir-samba2.png] En esta pantalla se selecciona el tipo de impresora que se va a añadir al sistema. En este caso, se va a añadir una impresora compartida por Samba, por lo que se selecciona la opción Impresora compartida SMB (Windows) y se pulsa sobre el botón "Siguiente". Figura 15-70. Usuario de acceso a la red Samba [cupsys-aniadir-samba3.png] Pulse sobre la opción "Cuenta de normal" y luego teclee un usuario y clave válidos para acceder al sistema Samba. Tenga en cuenta que este usuario ha de tener permisos de impresión (vea el Ejemplo 15-2 para más detalles). Figura 15-71. Monitorizar la red [cupsys-aniadir-samba4.png] Pulse sobre el botón "Monitorizar", para realizar una búsqueda de servidores Samba disponibles en la red. Figura 15-72. Selección de la impresora [cupsys-aniadir-samba5.png] Una vez encontrado el servidor Samba, seleccione la impresora que quiera utilizar y pulse sobre el botón "Siguiente". Nota Fíjese que en este caso se va a hacer uso de una clase de impresora. Figura 15-73. Modelo de la impresora [cupsys-aniadir-samba6.png] Para esta impresora no es necesario seleccionar un controlador, ya que es CUPS quien se encarga de procesar el trabajo, no Samba. Por este motivo, seleccione la opción "Impresora en bruto (no necesita controlador)" y pulse sobre el botón "Siguiente". Figura 15-74. Probando la impresora [cupsys-aniadir-samba7.png] Pulse sobre el botón "Probar" para enviar una prueba de impresión a la impresora que se está a punto de añadir. Figura 15-75. Usuario con privilegios de administración de impresión [cupsys-aniadir-impresora22.png] Teclee los datos de un usuario con privilegios de administración de impresión y pulse sobe el botón "Aceptar". Figura 15-76. Prueba enviada a la impresora [cupsys-aniadir-impresora23.png] Esta pantalla nos informa de que se ha enviado la prueba de impresión a la impresora. Pulse sobre el botón "Aceptar" para continuar. Si todo ha ido bien, en el home del usuario que se ha tecleado, aparecerá un nuevo directorio, $HOME/cups-pdf y dentro de este un archivo similar a Test_Page.pdf. Si se abre este archivo con un visualizador de archivos PDF, se podrá comprobar que es una prueba de impresión de CUPS. Figura 15-77. Prueba de impresión [cupsys-aniadir-impresora24.png] En esta pantalla se puede observar la prueba de impresión que se ha realizado en la imagen anterior. Figura 15-78. Selección de rótulos [cupsys-aniadir-impresora25.png] CUPS permite imprimir páginas separadoras para los trabajos de impresión. Si desea hacer uso de esta característica, seleccione los rótulos que desee en esta pantalla, en caso contrario, pulse directamente sobre el botón "Siguiente". Figura 15-79. Cuotas de impresión [cupsys-aniadir-impresora26.png] CUPS implemente un rudimentario sistema de cuotas de impresión. Como se va a hacer uso de PyKota para la administración de cuotas, esta opción no se utilizará. Pulse el botón "Siguiente" para continuar. Figura 15-80. Permisos de acceso a la impresora [cupsys-aniadir-impresora27.png] En esta pantalla se seleccionan los usuarios a los que se les permite, o no, imprimir. Como este control se realizará con la herramienta PyKota, pulse sobre el botón "Siguiente" directamente. Figura 15-81. Información sobre la impresora [cupsys-aniadir-samba8.png] Complete los campos con el nombre, ubicación y descripción para la impresora que se está añadiendo. Pulse sobre el botón "Siguiente" para continuar. Figura 15-82. Confirmación [cupsys-aniadir-samba9.png] Esta es la última pantalla antes de crear la nueva impresora. Revise la información sobre la misma, y si todo está correcto, pulse sobre el botón "Finalizar" para crear la impresora. Figura 15-83. Nueva impresora CompartidaSamba [cupsys-aniadir-samba10.png] Se puede apreciar en el directorio de impresoras la aparición de una nueva entrada, en este caso la impresora CompartidaSamba. Aquí finaliza la configuración de CUPS, el siguiente capítulo estará dedicado a la instalación y configuración de PyKota. IV. PyKota [pykota-logo.png] Tabla de contenidos 16. Visión general 16.1. Introducción 16.2. Aplicaciones existentes 16.2.1. Comparativa de algunas soluciones existentes 16.3. Características y funcionalidades de PyKota 16.3.1. Sistemas operativos 16.3.2. Sistemas de impresión 16.3.3. Bases de datos 16.3.4. Impresoras 16.3.5. Sistemas de cuotas 16.3.6. Administración 16.3.7. Interfaz de usuario 16.4. Información adicional sobre el proyecto 16.4.1. Página principal 16.4.2. Cómo obtener PyKota 16.4.3. Documentación 16.4.4. Información de soporte 16.4.5. Reporte de bugs 16.4.6. Cómo contactar 17. Obtención del código fuente y generación de un paquete deb 17.1. Introducción 17.2. Generación de un paquete deb para PyKota 17.2.1. Descarga del código fuente de PyKota 17.2.2. Modificaciones para generar el paquete deb 17.2.3. Generación del paquete deb 18. Instalación 18.1. Introducción 18.2. Instalación del paquete 19. Retoques iniciales en el sistema 19.1. Introducción 19.2. Modificaciones en la configuración de slapd 19.3. Creación de la estructura para PyKota en LDAP 20. Configuración 20.1. Introducción 20.2. Usuarios de pykota 20.3. Repaso sobre las principales opciones de configuración 20.3.1. Opciones del archivo /etc/pykota/pykota.conf 20.3.2. Opciones del archivo /etc/pykota/pykotadmin.conf 21. Modificaciones en las impresoras de CUPS 21.1. Introducción 21.2. Modificación del archivo /etc/cups/printers.conf 21.3. Añadiendo una impresora bajo el control de PyKota 22. Estableciendo las cuotas de impresión 22.1. Introducción 22.2. Estableciendo los precios en las impresoras 22.3. Gestionando los usuarios 23. Probando el sistema de cuotas 23.1. Introducción 23.2. Usuario printquota 23.2.1. Alcanzando el límite blando 23.2.2. Impresión de un documento mayor a la cuota disponible 23.2.3. Alcanzando el límite duro 23.2.4. Reinicio de la cuota de impresión 23.3. usuario printsaldo _________________________________________________________ Capítulo 16. Visión general 16.1. Introducción PyKota es una aplicación GPL para dar soporte de cuotas de impresión a CUPS (Common UNIX Printing System) y LPRng (LPR Next Generation) en sistemas GNU/Linux y similares a Unix. Pykota ofrece una gran flexibilidad con respecto a los métodos empleados a la hora de contar las páginas. Por defecto, solicita directamente a la impresora el número de páginas que ha impreso, pero se puede utilizar el método para contar páginas que se desee. _________________________________________________________ 16.2. Aplicaciones existentes Las quotas de impresión son una característica muy útil para soluciones completas de impresión en red, desgraciadamente no existe mucho software de este tipo basadas en Software Libre bajo GNU/Linux. Las siguientes aplicaciones cubren algunas de las necesidades de las cuotas de impresión: * PrintBill es una solución existente que hace un buen trabajo, pero todavía no soporta completamente CUPS, sólo LPRng. * Printquota es otra solución existente, pero sólo trabaja con LPRng. * CUPS, que es una aplicación de nueva generación para la impresión bajo sistemas Unix, posee cuotas de impresión, pero tiene una gran deficiencia en cuanto a características y no es extensible. _________________________________________________________ 16.2.1. Comparativa de algunas soluciones existentes La Tabla 16-1 muestra una comparativa entre PyKota, PrintBill, Printquota y PQuotas. Dicha tabla se ha obtenido de la página principal de PyKota y está elaborada por los autores de los sistemas de quota implicados (tabla original). Tabla 16-1. Comparativa entre 4 sistemas de quotas de impresión Funcionalidad PyKota PrintBill Printquota PQuotas Licencia GNU GPL GNU GPL, los módulos de Perl tiene doble licencia (Artística+GPL) GNU GPL La descarga y el uso es libre. No tiene licencia, sin embargo. Soporte comercial Sí Sí Sí No Paquetes propietarios No No No No Madurez Maduro Maduro Joven Maduro Lenguaje de programación Python Perl + C C Shell scripts + PHP Uso de recursos computacionales Ligero Puede ser intenso si se hace uso de la cuenta de tinta Ligero Medio Internacionalización Sí: inglés, francés, español, portugués, brasileño, sueco, tailandés, alemán e italiano. Están planificadas más traducciones Sí: inglés y francés. Están planificadas más traducciones No No, solamente francés Interfaz web Informe de quotas e historial únicamente, la interfaz web de administración está planificada Sí, incluyendo informes gráficos Todavía no. Una interfaz CGI está en preparación Sí. Interfaz de administración completa en PHP Almacenamiento central Sí Centralizado en la máquina donde se ejecuta PrintBill, pero no se puede disponer fácilmente de los datos desde fuera de PrintBill Sí Sí Dependencias * Python (requerido) * Módulo mxDateTime de Python (requerido) * PostgreSQL u OpenLDAP (requerido) * Módulo PyGreSQL o python-ldap de Python (requerido) * CUPS o LPRng (requerido) * Ghostscript (recomendado) * Net-SNMP (recomendado) * netatalk (recomendado) * Apache (recomendado) * Perl (requerido) * Módulo File::Temp de Perl * Ghostscript (requerido) * LPRng (requerido) * Apache (recomendado) * Magicfilter (recomendado) * Samba (recomendado) * Libpng (requerido) * Ghostscript fonts (requerido) * GnuPlot (recomendado) * LPRng (requerido) * libpopt (requerido) * Ghostscript (requerido) * PostgreSQL o MySQL (recomendado) * LPRng o LPD (requerido) * Ghostscript (requerido) * enscript (requerido) * psselect (requerido) * pdf2ps (recomendado) * MySQL (requerido) * Apache (recomendado) * PHP (recomendado) Sistemas de impresión soportados CUPS y LPRng LPRng y CUPS LPRng LPRng y LPD ¿Trabaja con clientes Windows? Sí. Bien sea directamente a través de IPP o a través de Samba. Puede enviar mensajes Winpopup también. Sí. Puede enviar mensajes Winpopup también. Sí. Probado con Windows + Samba y directamente a través del sistema de impresión TCP de Windows Sí Documentación Sí, todavía en desarrollo (formato en DocBook) Sí, FAQ, Howto (en formato de texto) Sí, instrucciones de instalación y post-instalación (en formato de texto) Sí, sólo en francés (en formato HTML) Métodos de contabilidad soportados * Petición al contador interno de la impresora (contabilidad por hardware) * Delegación del control de copias a cualquier orden externa a su elección * Escaneo de trabajos de impresión muy poco confiable * Computación de los niveles de tinta * Escaneo rápido de los trabajos de impresión * Obtención del número de hojas de un trabajo de impresión a partir de Ghostscript * Obtención del número de hojas de un trabajo de impresión a partir de Ghostscript Modo de sólo contabilidad (no se aplican las quotas) Sí Sí No Sí Cuotas de usuario por impresora Sí Sí Sí Sí Cuotas de grupos de usuarios por impresora Sí No (en la lista de trabajos por hacer) No No Cuotas para grupos de impresoras Sí No No No Políticas de impresión con usuarios desconocidos Completamente configurable No No No Cuotas de impresión Sí Sí No No Gasto en dinero Sí Sí Sí No Contador de páginas Sí Sí Sí Sí Contador de tinta Sí Sí, por color No No Cambio de configuración inmediata Sí No, se ha de reiniciar el demonio Sí Sí Trabaja con impresoras en red Sí Sí Sí Sí Trabaja con impresoras locales Sí Sí Sí Sí Trabaja con impresoras tontas (dumb) Depende del método contador y del sistema de impresión Sí Sí Sí Tipo de base de datos PostgreSQL y OpenLDAP Archivos planos (en la lista de tareas pendientes SQL y LDAP) PostgreSQL, MySQL y archivos planos MySQL (+NIS) (LDAP está planificado para el 2004) Fácilmente extensible Más que fácil. Se pueden añadir instrucciones externas simplemente en cualquier punto estratégico Puede adaptarse a otros sistemas de impresión fácilmente No No Paquetes para Debian No, planificado. Algunos scripts permiten una integración fácil en un sistema Debian Sí No, planificado No Paquetes RPM Sí, con recargo monetario No, sin embargo se incluye un archivo .spec No No Paquetes tar Sí, con recargo monetario Sí Sí Sí Acceso CVS Sí No Sí Sí Precisión Con el método de contabilidad por defecto, PyKota mantiene el número de páginas impresas solicitando dicha información a la impresora, por lo tanto la precisión es justamente el número de hojas consumidas. Con LPRng, PyKota siempre lleva un trabajo de impresión de retraso, sin embargo, en caso de atasco de papel o problemas similares, los usuario son debidamente cobrados. Como algunas impresoras no poseen un contador de páginas almacenado en la NVRAM, o no actualizan dicho contador en tiempo real (Hewlett-Packard), este contador es incorrecto en algunas ocasiones cuando se enciende una impresora, PyKota intenta solucionar lo mejor posible esta limitación de las impresoras. Con métodos contadores externos, la precisión la marcan estos métodos, ya que se especifica directamente la orden a utilizar para computar el tamaño del trabajo. Sin embargo, se puede sufrir los mismos problemas que posee PrintBill con los atascos de papel, dependerá de como la orden externa compute el tamaño del trabajo. Como no cuenta en ningún caso el consumo de tinta, PyKota es injusto con aquellas personas que hacen poco consumo de tinta, ya que los usuarios que hacen mucho consumo de tinta no reciben un recargo por este motivo. Printbill mantiene los consumos de papel y tinta preguntando a Ghostscript y/o calculando los niveles de tinta, lo que puede consumir muchos recursos. De todas formas, es exacto y justo en sus cálculos, al menos en teoría. En caso de atascos de papel o problemas similares, los usuarios no son justamente cobrados. Printbill puede escanear rápidamente los trabajos de impresión para contar únicamente el número de páginas, lo que no conlleva un consumo intensivo de recursos, sin embargo el contador de páginas puede ser explotado por usuarios con los conocimientos necesarios Printquota está diseñado para contar páginas. Si el contador de páginas y si el usuario posee la cuota suficiente (de páginas) permite imprimir. Printquota es injusto con aquellas personas que hacen poco uso de la tinta. Tan justo como lo pueda ser Ghostscript. PQuotas borra automáticamente todos los trabajos que no están en el formato permitido (text/ps/pdf), para evitar la mayoría de las impresiones no deseadas. Los usuarios pueden ver su historial de impresiones, lo que evita muchas reclamaciones _________________________________________________________ 16.3. Características y funcionalidades de PyKota 16.3.1. Sistemas operativos * Cualquier sistema operativo similar a Unix que actúe como un servidor de impresión * Cualquier sistema operativo que actúe como cliente _________________________________________________________ 16.3.2. Sistemas de impresión * Soporta tanto el sistema de impresión CUPS como LPRng _________________________________________________________ 16.3.3. Bases de datos * Soporta PostgreSQL como backend de almacenamiento de quotas. Se incluye un script completo para la creación de la base de datos en SQL * Soporta OpenLDAP como backend de almacenamiento de quotas. Se incluyen un esquema y un ejemplo de árbol para LDAP. Añadir PyKota a su infraestructura LDAP existente es realmente fácil gracias a la gran configurabilidad de PyKota _________________________________________________________ 16.3.4. Impresoras * Los métodos de contabilidad por hardware o por software son completamente configurables * Soporta cualquier impresora que pueda devolver su contador interno de páginas. Puede preguntar a las impresoras por su contador interno de páginas vía SNMP, Netatalk, PJL, PS o cualquier otra forma. Esto es completamente configurable * Soporta DSC y PostScript binarios, PDF, PCL5, PCLXL (o PCL6) e impresoras ESC/P2 nativamente por métodos de contabilidad software. Se están preparando más formatos _________________________________________________________ 16.3.5. Sistemas de cuotas * Soporta cuotas por impresora y por grupos de impresoras * Soporta cuotas por usuario y por grupos de usuarios * Soporta cuotas de papel. Se pueden establecer de forma diferente las cuotas de papel para una impresora o para los usuarios/grupos * Soporta cuotas sobre el balance de consumo en cualquier moneda. Se pueden asignar cuotas sobre el balance de consumo a cada usuario. Los balances de las cuentas se comparten entre todas las impresoras * Las cuotas de papel y de balance de consumo se pueden establecer/restablecer independientemente * Se puede asignar un factor limitante, quota de papel o balance de consumo, a cada usuario o grupo de usuarios * Los precios por página o por trabajo se pueden establecer independientemente en cualquier impresora * Se puede establecer la cuota mínima de consumo de papel o balance de consumo * Tanto los límites por software como por hardware así como el intervalo de gracia se pueden establecer para una cuota de papel * Posibilidad de deshabilitar las quotas a cualquier usuario o grupo de usuarios, mientras que se sigue manteniendo el contador de páginas _________________________________________________________ 16.3.6. Administración * Se pueden utilizar potentes herramientas de administración para automatizar el establecimiento o restablecimiento de las cuotas o los balances de consumo en intervalos específicos * Las herramientas de configuración pueden modificar varios usuarios, grupos o impresoras a la vez * Los balances de consumo se pueden establecer, incrementar y decrementar * Tanto las impresoras como los usuarios se pueden añadir automáticamente con la primera impresión, de una manera completamente configurable * Existe un generador de informes sobre cuotas disponible tanto desde la consola como desde cualquier navegador web. El generador de informes basado en web puede protegerse con clave. * El generador de informes sobre las cuotas, puede adelantar la información sobre el coste de un trabajo de impresión * Se puede configurar una política de actuación para los usuarios no registrados para cada impresora, tanto para denegar la impresión, permitirla o delegar la decisión a una herramienta externa * Los mensajes de aviso y de error se pueden enviar automáticamente a través de correo electrónico al administrador, al usuario, a ambos o a ninguno * El contenido de los mensajes de error y aviso es completamente configurable * La configuración se puede cambiar sin necesidad de reiniciar el sistema de impresión * Se mantiene un historial de impresión completo. Se puede deshabilitar se es preciso * Se pueden ajustar automáticamente las cuotas mínimas o el balance de saldo de forma regular o lanzarlo manualmente * Herramienta de exportación de datos muy potente, que permite llevar los datos de PyKota a otro software _________________________________________________________ 16.3.7. Interfaz de usuario * Todas las órdenes de consola aceptan el parámetro -h | --help, que mostrará todas las opciones disponibles y ejemplos de uso * Completamente internacionalizada. Actualmente soporta los idiomas: inglés, francés, español, portugués, brasileño, sueco, tailandés, alemán e italiano. Más en camino _________________________________________________________ 16.4. Información adicional sobre el proyecto _________________________________________________________ 16.4.1. Página principal Pykota dispone de una página principal, www.librelogiciel.com/software/PyKota/Presentation/action_Pres entation, desde donde puede obtener mucha información. De hecho, para elaborar esta sección ha utilizado la información allí disponible. _________________________________________________________ 16.4.2. Cómo obtener PyKota El código fuente de Pykota se distribuye bajo los términos de la licencia GPL (vea los GNU General Public License y Apéndice AW para más información) y su código fuente está disponible desde distintas fuentes, como se verá a continuación. Hay dos formas de conseguir PyKota, de forma gratuita y de pago. A continuación se verá en que consisten: * Obtención gratuita del código: La única forma de conseguir Pykota de forma gratuita es bajando el código fuente desde su CVS, para más información visite: http://savannah.nongnu.org/cvs/?group=pykota. Si obtiene el código fuente de esta forma, estará obteniendo una copia "no oficial" de PyKota, lo que implicará ver la palabra "unofficial" cuando se muestre la información sobre la versión del programa desde la línea de comandos con el parámetro --version. * Obtención del código pagando: De esta forma podrá obtener el código fuente empaquetado con tar. El autor de este programa ha optado por una forma de distribución retributiva de su software, lo que es perfectamente legal y no atenta en ningún momento con la licencia que está utilizando. Si se emplea esta forma de obtención del código, se estará ayudando al autor a continuar con el desarrollo del programa, por lo que se le anima a comprar su versión oficial de PyKota (la cual trae muchas ventajas, como soporte durante un año). Para más detalles sobre las formas de obtener PyKota, visite el siguiente enlace: www.librelogiciel.com/software/PyKota/Download/action_Download . _________________________________________________________ 16.4.3. Documentación El código fuente de PyKota viene con un directorio destinado a la documentación, doc/. Bajo el mismo está la documentación "oficial" del programa así como un documento escrito en OpenOffice.org por Dennis Romero L., con la salvedad de que está en español. _________________________________________________________ 16.4.4. Información de soporte Actualmente hay tres vías principales para obtener ayuda sobre Pykota: IRC: Puede acceder al canal de #pykota alojado en el servidor irc.freenode.net. Más información en: www.librelogiciel.com/software/PyKota/IRC/action_IRC. Lista de correo: PyKota pone a su disposición una lista de correo desde donde se podrán formular preguntas relativas a PyKota, más información en: http://cgi.librelogiciel.com/mailman/listinfo/pykota. Soporte derivado de la obtención de una copia oficial de PyKota: Al comprar una versión oficial de PyKota, está también adquiriendo un año de soporte técnico privilegiado sobre el programa. _________________________________________________________ 16.4.5. Reporte de bugs La página principal de PyKota pone a su disposición un formulario desde el cual se podrán enviar sugerencias, retroalimentación y posibles errores encontrados en el programa al autor del mismo. Más detalles en: www.librelogiciel.com/software/PyKota/Features/Feedback. Aunque si lo desea, puede hacer uso de la dirección de correo electrónico del autor para tal fin: Jerome Alet, . _________________________________________________________ 16.4.6. Cómo contactar Para obtener más información sobre PyKota, Jerome Alet (autor del programa) pone a su disposición su cuenta de correo: . _________________________________________________________ Capítulo 17. Obtención del código fuente y generación de un paquete deb 17.1. Introducción El objetivo final de este capítulo es obtener un paquete deb de PyKota, con el cual poder instalar dicho software en el sistema. Se ha decidido generar un paquete deb para mantener el sistema lo más limpio y ordenado posible. Los pasos para lograr esto serán, en primer lugar obtener el código fuente de PyKota, hacer las modificaciones oportunas para generar el paquete deb y finalmente generar dicho paquete. En las siguientes secciones se mostrará el proceso seguido para cumplir con este primer objetivo. _________________________________________________________ 17.2. Generación de un paquete deb para PyKota 17.2.1. Descarga del código fuente de PyKota Para obtener el código fuente de pykota, refiérase a la Sección 16.4.2. Para la realización de esta documentación se ha elegido descargar el código fuente directamente del CVS. La versión que se ha empleado es la 1.20alpha25. _________________________________________________________ 17.2.2. Modificaciones para generar el paquete deb Lo único que se modificará en el código fuente de PyKota será la versión del paquete que se genere. Para ello, aplique el siguiente parche a la versión 1.20alpha25 de pykota (en el Ejemplo 17-1 se muestra como hacerlo): diff -urN pykota/debian/changelog pykota-1.20alpha25/debian/changelog --- pykota/debian/changelog 2004-10-13 18:35:03.000000000 +0200 +++ pykota-1.20alpha25/debian/changelog 2004-10-13 18:45:06.000000000 + 0200 @@ -1,3 +1,9 @@ +pykota (1.20alpha25) unstable; urgency=low + + * Update from CVS. + + -- Sergio González González Wed, 13 Oct 2004 18:44:34 +0200 + pykota (1.20alpha24) unstable; urgency=low * Update from CVS. Ejemplo 17-1. Aplicación del parche de modificaciones al código de PyKota Sitúese en el directorio que contenga el código fuente de PyKota y teclee la siguiente orden, suponiendo que el parche se encuentra en el directorio padre, se llama patch-pykota y está en texto plano: $ /bin/cat ../patch-pykota | /usr/bin/patch -p1 patching file debian/changelog _________________________________________________________ 17.2.3. Generación del paquete deb Ejemplo 17-2. Generando el paquete deb de PyKota Sitúese en el directorio que contenga el código fuente de PyKota, edite el archivo setup.py y cambie el valor de la variable DEBIAN_BUILD_PACKAGE a "1". Asegúrese de que el archivo debian/rules tiene permisos de ejecución y teclee: $ /usr/bin/dpkg-buildpackage -rfakeroot -us -uc -b dpkg-buildpackage: source package is pykota dpkg-buildpackage: source version is 1.20alpha25 dpkg-buildpackage: source maintainer is Sergio González González dpkg-buildpackage: host architecture is i386 fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp /usr/bin/python setup.py clean --all running clean ... dpkg-deb: construyendo el paquete `pykota' en `../pykota_1.20alpha25_al l.deb'. dpkg-genchanges -b dpkg-genchanges: binary-only upload - not including any source code dpkg-buildpackage: binary only upload (no source included) La acción anterior debería haber generado un archivo deb en el directorio padre del actual. El archivo en cuestión debería denominarse pykota_1.20alpha25_all.deb. A partir de este momento, ya se está en disposición de instalar PyKota, el siguiente capítulo mostrará la forma de hacerlo. _________________________________________________________ Capítulo 18. Instalación 18.1. Introducción Este capítulo va a describir el proceso de instalación de PyKota, que tras la generación del paquete deb en el capítulo anterior, Capítulo 17, se simplificará mucho. _________________________________________________________ 18.2. Instalación del paquete El proceso de instalación de PyKota se reduce a la instalación del paquete generado en la Sección 17.2.3. Para ello sitúese en el directorio donde se encuentre dicho paquete y siga los pasos del siguiente ejemplo: Ejemplo 18-1. Instalación del paquete pykota # /usr/bin/dpkg -i pykota_1.20alpha25_all.deb Seleccionando el paquete pykota previamente no seleccionado. (Leyendo la base de datos ... 141967 ficheros y directorios instalados actualmente.) Preparando para reemplazar pykota 1.20alpha25 (usando pykota_1.20alpha2 5_all.deb) ... Desempaquetando el reemplazo de pykota ... Configurando pykota (1.20alpha25) ... Nota Si quiere ver información relativa a PyKota, tal vez tenga que teclear la siguiente orden: # /usr/sbin/dpkg-reconfigure --priority=low pykota El resultado de esta orden se muestra en las siguientes capturas de pantalla: Figura 18-1. Información de PyKota a través de debconf I [pykota-instalacion1.png] Información sobre el mecanismo de caché existente para la base de datos que utiliza PyKota. Figura 18-2. Información de PyKota a través de debconf II [pykota-instalacion2.png] Información de actualización de versiones pre-1.19alpha17 a versiones iguales o superiores a 1.19alpha17. Figura 18-3. Información de PyKota a través de debconf III [pykota-instalacion3.png] Información de actualización de versiones pre-1.19alpha10 a versiones iguales o superiores a 1.19alpha10. Con esto concluiría el proceso de instalación, ahora sólo queda configurar PyKota, tema que se abordará en el Capítulo 20. _________________________________________________________ Capítulo 19. Retoques iniciales en el sistema 19.1. Introducción Antes de proceder con la configuración de PyKota, es necesario realizar una serie de ajustes en el sistema. En primer lugar hay que elegir la base de datos sobre la cual se almacenarán los datos de las cuotas. PyKota da la posibilidad de almacenar estos datos sobre Postgresql o sobre un directorio LDAP. La elección ha sido LDAP, por lo que habrá que modificar el servidor slapd para que soporte los datos de PyKota y, finalmente, crear la estructura necesaria en el directorio LDAP para PyKota. Este capítulo mostrará como realizar estas modificaciones en el sistema. _________________________________________________________ 19.2. Modificaciones en la configuración de slapd En primer lugar se ha añadir una línea similar a la siguiente en el archivo de configuración de slapd (/etc/ldap/slapd.conf), en la sección de definiciones de esquemas y objectClass (añádala al final de la lista de esquemas, para evitar problemas): include /etc/ldap/schema/pykota.schema Y, finalmente, puede añadir una serie de índices que acelerarán un poco las búsquedas sobre los atributos de PyKota. Para ello añada las siguientes entradas en la sección de índices del archivo de configuración de slapd: # PyKota index pykotaUserName pres,eq,sub index pykotaGroupName pres,eq,sub index pykotaPrinterName pres,eq,sub index pykotaLastJobIdent eq En este momento sólo queda regenerar los índices de slapd y reiniciar el demonio: Ejemplo 19-1. Regenerando los índices de LDAP y reiniciando el demonio slapd # /usr/sbin/slapindex -v indexing id=00000001 indexing id=00000002 indexing id=00000016 indexing id=00000017 indexing id=00000018 indexing id=00000019 indexing id=0000001b indexing id=0000001c indexing id=0000001d indexing id=0000001e indexing id=00000020 indexing id=00000021 indexing id=00000022 indexing id=00000023 indexing id=00000024 indexing id=00000025 indexing id=00000027 indexing id=00000028 indexing id=0000002a indexing id=0000002b # /etc/init.d/slapd restart Stopping OpenLDAP: slapd. Starting OpenLDAP: slapd. Con esto finalizarían las modificaciones en el servidor slapd. _________________________________________________________ 19.3. Creación de la estructura para PyKota en LDAP En esta sección se creará la estructura para PyKota en el directorio LDAP. Las siguientes líneas muestran, en formato LDIF, las entradas que se han de incorporar al directorio LDAP: Nota Esta estructura se ha basado en el archivo /usr/share/doc/pykota/initscripts/ldap/pykota-sample.ldif que se distribuye con PyKota. # Entry 1: ou=pykota,dc=gsr,dc=pt dn:ou=pykota,dc=gsr,dc=pt ou: pykota objectClass: top objectClass: organizationalUnit # Entry 2: ou=printers,ou=pykota,dc=gsr,dc=pt dn:ou=printers,ou=pykota,dc=gsr,dc=pt ou: printers objectClass: top objectClass: organizationalUnit # Entry 3: ou=jobs,ou=pykota,dc=gsr,dc=pt dn:ou=jobs,ou=pykota,dc=gsr,dc=pt ou: jobs objectClass: top objectClass: organizationalUnit # Entry 4: ou=uquotas,ou=pykota,dc=gsr,dc=pt dn:ou=uquotas,ou=pykota,dc=gsr,dc=pt ou: uquotas objectClass: top objectClass: organizationalUnit # Entry 5: ou=gquotas,ou=pykota,dc=gsr,dc=pt dn:ou=gquotas,ou=pykota,dc=gsr,dc=pt ou: gquotas objectClass: top objectClass: organizationalUnit # Entry 6: ou=lastjobs,ou=pykota,dc=gsr,dc=pt dn:ou=lastjobs,ou=pykota,dc=gsr,dc=pt ou: lastjobs objectClass: top objectClass: organizationalUnit Suponiendo que la estructura anterior se encuentra almacenada en el archivo pykota.ldif, ejecute la siguiente orden para incorporarla a su directorio LDAP: Ejemplo 19-2. Creando la estructura para PyKota en LDAP $ /usr/bin/ldapadd -x -D "cn=admin,dc=gsr,dc=pt" -W -h gsr.pt -f pykota .ldif Enter LDAP Password: [clave] adding new entry "ou=pykota,dc=gsr,dc=pt" adding new entry "ou=printers,ou=pykota,dc=gsr,dc=pt" adding new entry "ou=jobs,ou=pykota,dc=gsr,dc=pt" adding new entry "ou=uquotas,ou=pykota,dc=gsr,dc=pt" adding new entry "ou=gquotas,ou=pykota,dc=gsr,dc=pt" adding new entry "ou=lastjobs,ou=pykota,dc=gsr,dc=pt" Esto completaría las modificaciones iniciales a realizar en el sistema, ahora se puede proceder a la configuración de PyKota, para ello vea el Capítulo 20 _________________________________________________________ Capítulo 20. Configuración 20.1. Introducción La configuración de PyKota se realiza en dos archivos: /etc/pykota/pykota.conf y /etc/pykota/pykotadmin.conf. Como dichos archivos son suficientemente explicativos, sólo se van a realizar una serie de apuntes sobre los mismos. Refiérase a los apéndices: Apéndice AG y Apéndice AH para ver un ejemplo de configuración de PyKota. _________________________________________________________ 20.2. Usuarios de pykota PyKota hace uso de dos usuarios para el acceso al directorio LDAP: uno destinado a la lectura de la base de datos de cuotas de impresión y otro destinado a la administración de esta base de datos. El primer usuario sólo ha de tener permisos de lectura y el segundo de lectura/escritura en la base de datos. Los usuarios utilizados en esta documentación son: * pykotauser: usuario de sólo lectura. * pykotaadmin: administrador de PyKota. Puede hacer uso del siguiente LDIF para generar dichos usuarios en su sistema: # Entry: cn=pykotauser,dc=gsr,dc=pt dn:cn=pykotauser,dc=gsr,dc=pt cn: pykotauser objectClass: simpleSecurityObject objectClass: organizationalRole userPassword: {crypt}y1pYJeZPC49BY description: Usuario de acceso como sólo lectura para PyKota # Entry: cn=pykotaadmin,dc=gsr,dc=pt dn:cn=pykotaadmin,dc=gsr,dc=pt cn: pykotaadmin objectClass: simpleSecurityObject objectClass: organizationalRole userPassword: {crypt}y1pYJeZPC49BY description: Usuario de acceso como sólo lectura para PyKota En el siguiente ejemplo se muestra como añadirlos al directorio LDAP. Se supone que el archivo usuarios-pykota.ldif contiene los datos LDIF anteriores: Ejemplo 20-1. Añadiendo los usuarios relativos a PyKota en el directorio LDAP $ /usr/bin/ldapadd -x -D "cn=admin,dc=gsr,dc=pt" -W -f usuarios-pykota .ldif Enter LDAP Password: [Clave] adding new entry "cn=pykotauser,dc=gsr,dc=pt" adding new entry "cn=pykotaadmin,dc=gsr,dc=pt" El siguiente paso consiste en dar los permisos adecuados a los usuarios en el directorio LDAP. Para ello edite el archivo de configuración de OpenLDAP, /etc/ldap/slapd.conf, y añada las siguientes líneas en los atributos userPassword, sambaLMPassword,sambaNTPassword y * de las listas de control de acceso: by dn="cn=pykotaadmin,dc=gsr,dc=pt" write by dn="cn=pykotauser,dc=gsr,dc=pt" read Por último, para asegurarse de que los usuarios con los que se autentificará PyKota en el servidor OpenLDAP no tienen límites de peticiones de búsquedas, añada las siguientes líneas: # User Limits limits dn="cn=pykotauser,dc=gsr,dc=pt" size.soft=-1 size.hard=soft limits dn="cn=pykotaadmin,dc=gsr,dc=pt" size.soft=-1 size.hard=soft Nota En el Apéndice Q tiene un archivo de configuración completo. _________________________________________________________ 20.3. Repaso sobre las principales opciones de configuración En esta sección se realizará un breve repaso sobre las opciones más importantes de configuración de PyKota. _________________________________________________________ 20.3.1. Opciones del archivo /etc/pykota/pykota.conf Este es el archivo de configuración principal de PyKota. Posee una sección [global], donde se configuran las opciones por defecto para todas las impresoras administradas por PyKota. Opcionalmente, pueden existir otras secciones ([nombreimpresora]), destinadas a personalizar la configuración de una impresora en concreto. Aquí sólo se tratará la sección global, por ser las demás secciones similares a esta y dependientes del sistema donde se instale PyKota. _________________________________________________________ 20.3.1.1. Datos de LDAP Las siguientes opciones le indican a PyKota el backend que ha de utilizar y los datos relativos al mismo: storagebackend: ldapstorage storageserver: ldap://gsr.pt:389 storagename: dc=gsr,dc=pt storageuser: cn=pykotauser,dc=gsr,dc=pt storageuserpw: ******** La base a partir de la cual se almacenarán los usuarios de PyKota en el directorio LDAP: userbase: ou=people,dc=gsr,dc=pt userrdn: uid La base a partir de la cual se almacenará el crédito que poseen los usuarios de PyKota: balancebase: ou=people,dc=gsr,dc=pt balancerdn: uid La base a partir de la cual se almacenarán los grupos de PyKota en el directorio LDAP: groupbase: ou=groups,dc=gsr,dc=pt grouprdn: cn La base a partir de la cual se almacenarán los datos de las impresoras de PyKota en el directorio LDAP: printerbase: ou=printers,ou=pykota,dc=gsr,dc=pt printerrdn: cn La base a partir de la cual se almacenarán los trabajos de impresión, cuotas de usuario, cuotas de grupo y el último trabajo realizado, respectivamente: jobbase: ou=jobs,ou=pykota,dc=gsr,dc=pt userquotabase: ou=uquotas,ou=pykota,dc=gsr,dc=pt groupquotabase: ou=gquotas,ou=pykota,dc=gsr,dc=pt lastjobbase: ou=lastjobs,ou=pykota,dc=gsr,dc=pt _________________________________________________________ 20.3.1.2. Creación de usuarios/grupos Estas dos opciones informan a PyKota como se han de añadir los datos de los usuarios y grupos en el sistema. Se ha seleccionado la opción de añadir la información sobre la cuota de impresión a los usuarios/grupos ya existentes: newuser : attach(posixAccount, warn) newgroup : attach(posixGroup, warn) _________________________________________________________ 20.3.1.3. Correo electrónico de los usuarios Esta opción indica cual es el atributo, dentro del directorio LDAP, que ha de buscar PyKota para obtener el correo electrónico de los usuarios: usermail : mail _________________________________________________________ 20.3.1.4. Atributo que contiene la lista de miembros de un grupo Indique en esta variable el atributo que contiene la lista de miembros de un grupo determinado: groupmembers: memberUid _________________________________________________________ 20.3.1.5. Servidor SMTP Servidor de correo utilizado para enviar correos: Sugerencia Si desea integrar su servidor de correo con el sistema que se está configurando en esta documentación, le aconsejo que lea el documento http://guepardo.dyndns.org:8080/sergio-gonzalez/doc/08-postfix -ldap/html/ smtpserver: localhost _________________________________________________________ 20.3.1.6. Dominio para los correos electrónicos Esta variable establece el dominio al cual se enviarán los correos electrónicos de los usuarios del sistema. Es decir, será el valor que se ponga detrás de la @ como se muestra a continuación: usuario@gsr.pt. maildomain: gsr.pt _________________________________________________________ 20.3.1.7. Contado de páginas Pykota permite realizar el contado de las páginas que se han impreso de dos maneras: mediante hardware (dejándole el trabajo de contado a la impresora) o mediante software (haciendo uso de un contador de páginas propio). En esta documentación, por el tipo de impresoras utilizadas (impresoras virtuales), se ha elegido el contado de páginas mediante software: accounter: software(/usr/bin/pkpgcounter) _________________________________________________________ 20.3.1.8. Qué hacer ante un error del subsistema de contado de páginas Existen dos posibles comportamientos ante un error en la contabilidad de las páginas: continuar con la cola de trabajos pendientes, como si nada hubiese ocurrido o detener la cola de trabajos pendientes. La opción elegida es la segunda, se detendrá el sistema de impresión ante un fallo en la contabilidad de las páginas. onaccountererror: stop _________________________________________________________ 20.3.1.9. Información sobre el administrador de PyKota Información sobre quien es y cual es la dirección de correo electrónico del administrador de PyKota: admin: Sergio González González adminmail: root@localhost _________________________________________________________ 20.3.1.10. Envío de notificaciones Se le indica a PyKota que envíe, tanto al usuario como al administrador, notificaciones sobre el estado de la cuota de un usuario determinado: mailto: both _________________________________________________________ 20.3.1.11. Texto de las notificaciones Por defecto, PyKota provee una serie de mensajes de ejemplo que se emplearán para el envío de correos electrónicos cuando las cuotas de los usuarios se hayan sobrepasado o hayan alcanzado un cierto límite. Puede personalizar estos mensajes, las siguientes líneas le muestran un ejemplo: # Poor man's warning message # The warning message that is sent if the "poorman" value is reached # Again this must appear in the global section poorwarn: Su saldo en la cuota de impresión es bajo. Dentro de poco no podrá volver a imprimir. # Soft limit reached warning message # The warning message that is sent if the soft quota limit is reached # May appear either globally or on a per-printer basis softwarn: Ha alcanzado su límite blando en la cuota de impresión. Esto significa que podrá seguir imprimiendo algún tiempo, pero debería contactar con su administrador para comprar más cuota de impresión. # Hard limit reached error message # The error message that is sent if the hard quota limit is reached # May appear either globally or on a per-printer basis hardwarn: Ha alcanzado su límite duro en la cuota de impresión. Esto significa que no podrá volver a imprimir. Contacte con su administrador en tan pronto como le sea posible para solucionar el problema. _________________________________________________________ 20.3.1.12. ¿Se permite a los usuarios sobrepasar la cuota de impresión? Esta variable controla si se permite o no a un usuario completar un trabajo, si durante la impresión del mismo, se termina su cuota de impresión. La opción strict no permite esta situación, por lo que alertará al usuario y no permitirá la impresión. Esta es la opción elegida. La opción laxist permite finalizar el trabajo de impresión, si durante el trascurso del mismo, se termina la cuota de impresión del usuario. enforcement: strict _________________________________________________________ 20.3.2. Opciones del archivo /etc/pykota/pykotadmin.conf En este archivo se configura el usuario que tendrá acceso de escritura en la base de datos de PyKota. En este caso se utilizará el usuario pykotaadmin, por lo que se configurará de la siguiente forma: # Quota Storage administrator's name and password storageadmin: cn=pykotaadmin,dc=gsr,dc=pt storageadminpw: ********** Importante Asegúrese de que el archivo /etc/pykota/pykotadmin.conf sólo puede ser leído por el usuario root y por el usuario con el que se ejecuta el sistema de impresión. _________________________________________________________ Capítulo 21. Modificaciones en las impresoras de CUPS 21.1. Introducción En el apartado dedicado a CUPS (Parte III en Integración de redes con OpenLDAP, Samba, CUPS y PyKota) se añadieron una serie de impresoras al sistema y se comentó que la cuota de impresión se iba a administrar con PyKota. Este capítulo trata de mostrar las modificaciones que se han de realizar en las impresoras presentes en el sistema para que PyKota controle las cuotas de impresión de las mismas. _________________________________________________________ 21.2. Modificación del archivo /etc/cups/printers.conf En el archivo /etc/cups/printers.conf se encuentra disponible la configuración para cada una de las impresoras presentes en el sistema, y administradas por CUPS. Para conseguir que PyKota administre las cuotas de impresión para todas, o algunas de las impresoras allí presentes (usted elige qué impresoras estarán o no administradas por PyKota), sólo tendrá que modificar el parámetro DeviceURI, anteponiéndole el valor "cupspykota:" a la dirección de la impresora. De esta forma, suponga que tiene la siguiente definición en dicho archivo: Info Impresora de inyección de tinta en Blanco y Negro Location Laboratorio 2 DeviceURI cups-pdf:/ State Idle Accepting Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 Para que la impresora InyeccionBN pasase a estar administrada por PyKota, habría que anteponer al valor del parámetro DeviceURI la cadena "cupspykota:", como se muestra a continuación: Info Impresora de inyección de tinta en Blanco y Negro Location Laboratorio 2 DeviceURI cupspykota:cups-pdf:/ State Idle Accepting Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 Ha de realizar esta operación con todas las impresoras, cuya cuota de impresión, quiera que se administre con PyKota Una vez haya realizado las modificaciones oportunas, sólo queda reiniciar el demonio cupsd (vea el Ejemplo 15-4). A partir de ese momento, la impresión en las impresoras modificadas pasará a estar controlada por PyKota. _________________________________________________________ 21.3. Añadiendo una impresora bajo el control de PyKota Una vez se ha instalado PyKota en el sistema, a la hora de añadir una nueva impresora, se presentará la opción de instalar la nueva impresora bajo el control de PyKota. En la siguiente imagen se muestra esta nueva posibilidad: Figura 21-1. Añadiendo una impresora con soporte para PyKota [pykota-aniadir-impresora.png] Tras la instalación de PyKota, en el cuadro de selección del URI de una impresora, aparecerá la posibilidad de instalar la impresora con y sin soporte de PyKota. _________________________________________________________ Capítulo 22. Estableciendo las cuotas de impresión 22.1. Introducción Ahora que el sistema de impresión ya está configurado para hacer uso de PyKota en el control de la cuotas de impresión, falta por establecer dichas cuotas. Este capítulo le va a guiar en el proceso de establecimiento de las cuotas de impresión para las impresoras presentes en el sistema. También le mostrará como realizar la gestión de los usuarios y grupos del sistema para que interoperen con el sistema de impresión. _________________________________________________________ 22.2. Estableciendo los precios en las impresoras En la siguiente tabla se muestran los precios que se establecerán en las impresoras creadas en la parte dedicada a CUPS (Parte III en Integración de redes con OpenLDAP, Samba, CUPS y PyKota). Hay dos tipos de precios: por página (obligatorio) y por trabajo (opcional): Tabla 22-1. Cuotas que se establecerán en las impresoras Impresora Precio por página Precio por trabajo LaserColor 0.09 0 LaserBN 0,03 0 Plotter 0.5 1 Sublimacion 0.65 0.75 Multifuncion 0.025 0 InyeccionColor 0.07 0 InyeccionBN 0.025 0 La orden que se va a utilizar para el establecimiento de los precios de la tabla anterior en las impresoras es: pkprinters. El siguiente ejemplo le mostrará como hacerlo: Nota Si ejecuta la orden pkprinters --help, obtendrá un listado con las opciones que acepta pkprinters así como una serie de ejemplos de uso. Ejemplo 22-1. Estableciendo los precios en las impresoras con pkprinters $ /usr/bin/pkprinters --add --charge 0.09 LaserColor $ /usr/bin/pkprinters --add --charge 0.03 LaserBN $ /usr/bin/pkprinters --add --charge 0.5,1 Plotter $ /usr/bin/pkprinters --add --charge 0.65,0.75 Sublimacion $ /usr/bin/pkprinters --add --charge 0.025 Multifuncion InyeccionBN $ /usr/bin/pkprinters --add --charge 0.07 InyeccionColor $ /usr/bin/pkprinters --list LaserColor [] (0.0 + #*0.09) LaserBN [] (0.0 + #*0.03) Plotter [] (1.0 + #*0.5) Sublimacion [] (0.75 + #*0.65) Multifuncion [] (0.0 + #*0.025) InyeccionBN [] (0.0 + #*0.025) InyeccionColor [] (0.0 + #*0.07) $ /usr/bin/repykota Informe para la cuota user en la impresora LaserColor () Tiempo de gracia para páginas: 7 día(s) Precio por trabajo: 0.000 Precio por página: 0.090 Usuario usado blando duro saldo gracia total pagado ----------------------------------------------------------------------- ------- Real : Desconocido Informe para la cuota user en la impresora LaserBN () Tiempo de gracia para páginas: 7 día(s) Precio por trabajo: 0.000 Precio por página: 0.030 Usuario usado blando duro saldo gracia total pagado ----------------------------------------------------------------------- ------- Real : Desconocido Informe para la cuota user en la impresora Plotter () Tiempo de gracia para páginas: 7 día(s) Precio por trabajo: 1.000 Precio por página: 0.500 Usuario usado blando duro saldo gracia total pagado ----------------------------------------------------------------------- ------- Real : Desconocido Informe para la cuota user en la impresora Sublimacion () Tiempo de gracia para páginas: 7 día(s) Precio por trabajo: 0.750 Precio por página: 0.650 Usuario usado blando duro saldo gracia total pagado ----------------------------------------------------------------------- ------- Real : Desconocido Informe para la cuota user en la impresora Multifuncion () Tiempo de gracia para páginas: 7 día(s) Precio por trabajo: 0.000 Precio por página: 0.025 Usuario usado blando duro saldo gracia total pagado ----------------------------------------------------------------------- ------- Real : Desconocido Informe para la cuota user en la impresora InyeccionBN () Tiempo de gracia para páginas: 7 día(s) Precio por trabajo: 0.000 Precio por página: 0.025 Usuario usado blando duro saldo gracia total pagado ----------------------------------------------------------------------- ------- Real : Desconocido Informe para la cuota user en la impresora InyeccionColor () Tiempo de gracia para páginas: 7 día(s) Precio por trabajo: 0.000 Precio por página: 0.070 Usuario usado blando duro saldo gracia total pagado ----------------------------------------------------------------------- ------- Real : Desconocido Con esto se completaría el establecimiento de los precios por impresora; en la siguiente sección se verá como permitir a los usuarios hacer uso del sistema de impresión. _________________________________________________________ 22.3. Gestionando los usuarios Los usuarios pueden tener dos tipos de cuota de impresión: por páginas impresas o por precio. De esta forma se puede establecer un límite de páginas impresas para un período de tiempo concreto, pasado el cual, se resetea dicho valor a cero. La otra forma de gestión de las cuotas, es estableciendo un saldo por usuario, que tras agotarse, no se podrá volver a imprimir hasta que no se recargue. En los siguientes ejemplos se verá la forma de establecer ambas cuotas de impresión, para ello se hará uso de la orden edpykota: Nota Si ejecuta la orden edpykota --help, obtendrá un listado con las opciones que acepta edpykota así como una serie de ejemplos de uso. Ejemplo 22-2. Estableciendo una cuota de impresión a un usuario En este ejemplo se le asignará un límite de 10 páginas impresas para el usuario printquota. Como el usuario printquota no existe en el sistema, el comando edpykota lo añadirá automáticamente. # /usr/bin/edpykota --add -P LaserColor -S 5 -H 10 printquota WARN: No se ha podido encontrar una entrada objectClass posixAccount ex istente con \ uid=printquota para anexionar el objectClass pykotaAccount. A new entry will be created instead. # /usr/bin/repykota --printer LaserColor Informe para la cuota user en la impresora LaserColor () Tiempo de gracia para páginas: 7 día(s) Precio por trabajo: 0.000 Precio por página: 0.090 Usuario usado blando duro saldo gracia total pagado ----------------------------------------------------------------------- ------- printquot -Q 0 5 10 0.00 0 0.00 Real : Desconocido Pykota provee un CGI que muestra gráficamente el estado de las cuotas. Para acceder a este programa, teclee la URL del servidor web donde ha instalado PyKota seguido de la ubicación del citado CGI. En el sistema que se ha empleado para realizar esta documentación, el CGI se encuentra en la siguiente URL: http://gsr.pt/cgi-bin/printquota.cgi Figura 22-1. Informe de la impresora LaserColor [pykota-cgi2.png] Información sobre la impresora LaserColor generado por el CGI que provee PyKota. Ejemplo 22-3. Asignando un saldo de impresión a un usuario En este ejemplo se le asignará un saldo de 5 euros al usuario printsaldo. Como el usuario printsaldo no existe en el sistema, el comando edpykota lo añadirá automáticamente. # /usr/bin/edpykota --add -P Sublimacion --limitby balance --balance 5 printsaldo WARN: No se ha podido encontrar una entrada objectClass posixAccount ex istente con uid=printsaldo para \ anexionar el objectClass pykotaAccount. A new entry will be created ins tead. # /usr/bin/repykota --printer Sublimacion Informe para la cuota user en la impresora Sublimacion () Tiempo de gracia para páginas: 7 día(s) Precio por trabajo: 0.750 Precio por página: 0.650 Usuario usado blando duro saldo gracia total pagado ----------------------------------------------------------------------- ------- printsald -B 0 None None 5.00 0 5.00 Total : 0 5.00 Real : Desconocido Figura 22-2. Informe de la impresora Sublimacion [pykota-cgi1.png] Información sobre la impresora Sublimacion generado por el CGI que provee PyKota. Con esto finalizaría la asignación de cuotas de impresión a los usuarios. En la siguiente sección se verá el funcionamiento de dichas cuotas. _________________________________________________________ Capítulo 23. Probando el sistema de cuotas 23.1. Introducción Este capítulo pondrá a prueba el sistema de cuotas de impresión, para ver si funciona como debe. Se realizarán pruebas sobre los dos tipos de cuotas empleados. _________________________________________________________ 23.2. Usuario printquota En las siguientes secciones se van a mostrar tres ejemplos a la hora de imprimir un determinado documento: * Se alcanza el límite blando de la cuota de impresión, Sección 23.2.1. * Se intenta imprimir un documento mayor que la cuota disponible, Sección 23.2.2. * Se alcanza el límite duro de la cuota de impresión, Sección 23.2.3. _________________________________________________________ 23.2.1. Alcanzando el límite blando Recuerde que este usuario tiene un límite de impresión de 10 páginas (vea el Ejemplo 22-2 para más detalles). Se va a imprimir un documento de 5 páginas y se va a comprobar que ocurre en el sistema de cuotas: Figura 23-1. Impresión de un documento de 5 páginas I [pykota-printsaldo1.png] Figura 23-2. Impresión de un documento de 5 páginas II [pykota-printsaldo2.png] Figura 23-3. Impresión de un documento de 5 páginas III [pykota-printsaldo3.png] Figura 23-4. Impresión de un documento de 5 páginas IV [pykota-printsaldo4.png] Tras la impresión de este documento, aparece un nuevo archivo PDF bajo el directorio cups-pdf del home del usuario printquota con un nombre similar a: job_2-untitled_document.pdf. Si ahora se revisa el estado de la cuota de este usuario, se obtendrá algo similar a: Ejemplo 23-1. Revisando la cuota de impresión del usuario printquota I # /usr/bin/repykota --printer LaserColor Informe para la cuota user en la impresora LaserColor () Tiempo de gracia para páginas: 7 día(s) Precio por trabajo: 0.000 Precio por página: 0.090 Usuario usado blando duro saldo gracia total pagado ----------------------------------------------------------------------- ------- printquot +Q 5 5 10 -0.45 2004-10-21 5 0.00 Total : 5 0.00 Real : 0 Se puede observar que ha consumido 5 páginas de su cuota de impresión. PyKota también informa del coste de la impresión (-0.45), el valor negativo indica que el usuario no ha pagado por esta impresión. A continuación se va a imprimir una página más, para rebasar el límite suave de la cuota, y ver qué ocurre. Tras realizar esta primera impresión, el usuario printquota recibirá un correo electrónico, informándole de que ha alcanzado su límite blando de impresión. Así mismo, el administrador del sistema de impresión, recibirá otro correo, informándole de que el usuario printquota tiene su cuota de impresión baja (recuerde que este comportamiento se ha definido en la Sección 20.3.1.10). A continuación puede ver los correos enviados: Ejemplo 23-2. Correo de aviso enviado al usuario printquota - límite suave sobrepasado - From: root@localhost Subject: Cuota de Impresión Baja To: printquota@gsr.pt Ha alcanzado su límite blando en la cuota de impresión. Esto significa que podrá seguir imprimiendo algún tiempo, pero debería contactar con su administrador para comprar más cuota de impresión. Entre en contacto con su administrador de sistema, por favor : Sergio González González - Ejemplo 23-3. Correo de aviso enviado al administrador - cuota de impresión baja - From: root@localhost Subject: Cuota de impresión To: root@localhost Cuota de impresión baja para el usuario printquota en la impresora Lase rColor _________________________________________________________ 23.2.2. Impresión de un documento mayor a la cuota disponible En esta sección se ha intentado imprimir un documento de dimensiones superiores a la cuota del usuario printquota: Figura 23-5. Impresión de un documento que supera la cuota disponible [pykota-printsaldo5.png] Intento de impresión de un documento que superaría la cuota de impresión del usuario. Debido a que se ha configurado PyKota en modo strict (vea la Sección 20.3.1.12), el documento que se ha tratado de imprimir, no se imprimirá. Como resultado a esta acción, el usuario printquota y el administrador del sistema de impresión recibirán los siguientes correos: Ejemplo 23-4. Correo de aviso enviado al usuario printquota - límite duro sobrepasado - From: root@localhost Subject: Cuota de Impresión Excedida To: printquota@gsr.pt Ha alcanzado su límite duro en la cuota de impresión. Esto significa que no podrá volver a imprimir. Contacte con su administrador en tan pronto como le sea posible para solucionar el problema. Entre en contacto con su administrador de sistema, por favor : Sergio González González - Ejemplo 23-5. Correo de aviso enviado al administrador - cuota de impresión excedida - From: root@localhost Subject: Cuota de impresión To: root@localhost Cuota de impresión excedida para el usuario printquota en la impresora LaserColor Importante Si se hubiese utilizado el modo laxist, el documento se habría impreso en su totalidad, obteniéndose como resultado una cuota negativa para el usuario en cuestión. El aviso recibido, tanto por el usuario printquota como por el administrador del sistema de impresión, no es del todo cierto. Es cierto que se ha alcanzado el límite duro de la cuota de impresión con el trabajo enviado a la cola de impresión, pero debido a que este sobrepasaba el límite de la cuota de impresión, el trabajo no se ha impreso. Como resultado, la cuota del usuario printquota permanece igual que antes de haber enviado el trabajo a la cola de impresión: Ejemplo 23-6. Revisando la cuota de impresión del usuario printquota # /usr/bin/repykota --printer LaserColor Informe para la cuota user en la impresora LaserColor () Tiempo de gracia para páginas: 7 día(s) Precio por trabajo: 0.000 Precio por página: 0.090 Usuario usado blando duro saldo gracia total pagado ----------------------------------------------------------------------- ------- printquot +Q 5 5 10 -0.45 2004-10-21 5 0.00 Total : 5 0.00 Real : 0 _________________________________________________________ 23.2.3. Alcanzando el límite duro Ahora se van a imprimir 4 páginas más, acabando de esta forma la cuota de impresión. Nota Si se intentan imprimir 5 páginas, alcanzando de esta forma el límite duro, ocurrirá lo mismo que el ejemplo mostrado en la Sección 23.2.2. Ejemplo 23-7. Revisando la cuota de impresión del usuario printquota # /usr/bin/repykota --printer LaserColor Informe para la cuota user en la impresora LaserColor () Tiempo de gracia para páginas: 7 día(s) Precio por trabajo: 0.000 Precio por página: 0.090 Usuario usado blando duro saldo gracia total pagado ----------------------------------------------------------------------- ------- printquot +Q 9 5 10 -0.81 2004-10-21 9 0.00 Total : 9 0.00 Real : 5 Los correos de notificación que se han recibido en esta ocasión son los siguientes: Ejemplo 23-8. Correo de aviso enviado al usuario printquota - límite blando sobrepasado - From: root@localhost Subject: Cuota de Impresión Baja To: printquota@gsr.pt Ha alcanzado su límite blando en la cuota de impresión. Esto significa que podrá seguir imprimiendo algún tiempo, pero debería contactar con su administrador para comprar más cuota de impresión. Entre en contacto con su administrador de sistema, por favor : Sergio González González - Ejemplo 23-9. Correo de aviso enviado al administrador - cuota excedida - From: root@localhost Subject: Cuota de impresión To: root@localhost Cuota de impresión excedida para el usuario sergio en la impresora Lase rColor A partir de este momento, el usuario printquota no podrá volver a imprimir, hasta que no obtenga más cuota de impresión. Nota El comportamiento del sistema de impresión con la opción laxist hubiese sido ligeramente diferente. Por lo tanto, la elección de uno u otro comportamiento ha de elegirse en función de sus preferencias. _________________________________________________________ 23.2.4. Reinicio de la cuota de impresión Supongamos ahora que el sistema reinicia las cuotas de los usuarios cada cierto período de tiempo: Ejemplo 23-10. Reinicio de la cuota de impresión para el usuario printquota # /usr/bin/edpykota --reset printquota A partir de ese momento, el usuario printquote dispone de nuevo de una cuota de impresión de 10 páginas: Ejemplo 23-11. Información sobre la cuota del usuario printquota, tras su reinicio I # /usr/bin/repykota --printer LaserColor Informe para la cuota user en la impresora LaserColor () Tiempo de gracia para páginas: 7 día(s) Precio por trabajo: 0.000 Precio por página: 0.090 Usuario usado blando duro saldo gracia total pagado ----------------------------------------------------------------------- ------- printquot -Q 0 5 10 -0.81 2004-10-21 9 0.00 Total : 9 0.00 Real : 9 Si se realiza en este momento una nueva impresión, el informe para el usuario printquota sería: Ejemplo 23-12. Información sobre la cuota del usuario printquota, tras su reinicio II # /usr/bin/repykota --printer LaserColor Informe para la cuota user en la impresora LaserColor () Tiempo de gracia para páginas: 7 día(s) Precio por trabajo: 0.000 Precio por página: 0.090 Usuario usado blando duro saldo gracia total pagado ----------------------------------------------------------------------- ------- printquot +Q 5 5 10 -1.26 2004-10-21 14 0.00 Total : 14 0.00 Real : 9 Como se ha podido comprobar, el sistema de cuotas funciona de la manera esperada. Con esto concluirían las pruebas sobre el sistema de cuotas de impresión. _________________________________________________________ 23.3. usuario printsaldo El usuario printsaldo posee una cuota de impresión basada en saldo; su comportamiento es similar al mostrado en la Sección 23.2, por lo que se deja como trabajo para el lector las pruebas con este tipo de cuotas. Sugerencia Imagínese que el usuario printsaldo desea imprimir el documento que está leyendo, pero no tiene ni idea de lo que puede costar su impresión. Por este motivo, ha decidido consultar, antes de imprimir, el precio de impresión en cada una de las impresoras disponibles en el sistema. El resultado ha sido el siguiente: Ejemplo 23-13. Coste de impresión de un documento $ /usr/bin/pykotme ldap+samba+cups+pykota.ps Tamaño del trabajo : 759 página(s) Coste en la impresora LaserColor : 68.31 Coste en la impresora LaserBN : 22.77 Coste en la impresora Plotter : 380.50 Coste en la impresora Sublimacion : 494.10 Coste en la impresora Multifuncion : 18.98 Coste en la impresora InyeccionBN : 18.98 Coste en la impresora InyeccionColor : 53.13 V. Misceláneo Tabla de contenidos A. Creación y configuración de un usuario de sólo lectura para el directorio LDAP A.1. Introducción A.2. Creación A.3. Configuración B. Demonio de caché para el servicio de nombres: nscd B.1. Introducción B.2. Instalación B.3. Configuración C. Ejecución de Samba desde (x)inetd C.1. Introducción C.2. Superservidor inetd C.3. Superservidor xinetd D. Opciones del kernel Linux para Samba D.1. Kernel 2.4.* D.2. Kernel 2.6.* E. Instalación y configuración de SWAT E.1. Introducción E.2. Instalación de SWAT E.3. Gestión de SWAT desde un superservidor (x)inetd E.3.1. Gestión de SWAT desde inetd E.3.2. Gestión de SWAT desde xinetd E.4. Accediendo a SWAT F. Instalación y configuración de LAM (LDAP Account Manager) F.1. Instalación F.2. Configuración F.2.1. Configuración relativa a Apache F.2.2. Configuración desde la interfaz web G. Instalación y configuración de phpLDAPadmin G.1. Instalación G.2. Configuración G.2.1. Configuración relativa a Apache G.2.2. Ajustes en la configuración G.3. Acceso a la aplicación H. Instalación y configuración de smbldap-tools H.1. Introducción H.2. Instalación H.3. Configuración H.3.1. /etc/smbldap-tools/smbldap_bind.conf H.3.2. /etc/smbldap-tools/smbldap.conf I. Preparación de Apache para el uso de SSL I.1. Introducción I.2. Generación de la entidad certificadora y los certificados I.3. Configuración de Apache I.3.1. Configuración de los virtual host J. Cambio para el registro de Windows XP (miembro de un dominio Samba) K. Script para la creación/eliminación de los homes de los usuarios L. Script para convertir a mayúsculas el archivo pasado como argumento M. Script para mover los controladores PostScript de Adobe al directorio /usr/share/cups/drivers N. Salida de la ejecución de la orden /usr/sbin/cupsaddsmb -v -U root -a O. Ejemplo de certificado para un servidor _________________________________________________________ Apéndice A. Creación y configuración de un usuario de sólo lectura para el directorio LDAP A.1. Introducción Este apéndice tiene por objetivo la creación y configuración de un usuario que tenga permisos de lectura en todo el directorio LDAP, pero no de escritura. El usuario que se cree, no podrá acceder a las claves de otros usuarios, únicamente a la suya Este usuario se hace necesario cuando el acceso al directorio LDAP se limita a usuarios autentificados (como es el caso de esta documentación). _________________________________________________________ A.2. Creación Se supone que se posee un archivo denominado readadmin.ldif, con el siguiente contenido: # Entry: cn=readadmin,dc=gsr,dc=pt dn:cn=readadmin,dc=gsr,dc=pt cn: readadmin objectClass: simpleSecurityObject objectClass: organizationalRole userPassword: {crypt}y1pYJeZPC49BY description: LDAP administrator (read only admin) El ejemplo siguiente muestra como añadir el usuario readadmin al directorio LDAP: Ejemplo A-1. Creación del usuario readadmin $ /usr/bin/ldapadd -x -ZZ -D "cn=admin,dc=gsr,dc=pt" -W -f readadmin.ld if Enter LDAP Password: [Clave] adding new entry "cn=readadmin,dc=gsr,dc=pt" _________________________________________________________ A.3. Configuración Una vez creado el usuario readadmin, se han de configurar los permisos que tendrá dentro del directorio LDAP. Esta operación se realiza en el archivo /etc/ldap/slapd.conf. Debido a que el proceso de configuración de OpenLDAP se extiende por toda la documentación, en este apéndice se indicará únicamente la línea que se añadirá a las distintas ACLs a lo largo de la documentación: by dn="cn=readadmin,dc=gsr,dc=pt" read Nota En el Apéndice Q tiene un archivo completo de configuración de OpenLDAP. _________________________________________________________ Apéndice B. Demonio de caché para el servicio de nombres: nscd B.1. Introducción Este demonio evita, en los equipos donde se encuentra instalado, que las órdenes del tipo /bin/ls -l /home constantemente consulten al servidor LDAP con cada ejecución. nscd mantiene una caché con información sobre los datos de los usuarios, que refresca cada cierto tiempo, de forma que las estaciones de trabajo la utilizarán en lugar de consultar al servidor LDAP. Las siguientes secciones comprenderán el proceso de instalación y configuración de este demonio. _________________________________________________________ B.2. Instalación La instalación es muy sencilla, como se verá a continuación: Ejemplo B-1. Instalación de nscd # /usr/bin/apt-get install nscd Leyendo lista de paquetes... Hecho Creando árbol de dependencias... Hecho Se instalarán los siguientes paquetes NUEVOS: nscd 0 actualizados, 1 se instalarán, 0 para eliminar y 0 no actualizados. Se necesita descargar 0B/90,4kB de archivos. Se utilizarán 217kB de espacio de disco adicional después de desempaque tar. (Leyendo la base de datos ... 273953 ficheros y directorios instalados actualmente.) Desempaquetando nscd (de .../nscd_2.3.2.ds1-16_i386.deb) ... Configurando nscd (2.3.2.ds1-16) ... Starting Name Service Cache Daemon: nscd. Para ver la información acerca del paquete, teclee: Ejemplo B-2. Instalación de nscd $ /usr/bin/apt-cache show nscd Package: nscd Priority: optional Section: admin Installed-Size: 212 Maintainer: GNU Libc Maintainers Architecture: i386 Source: glibc Version: 2.3.2.ds1-16 Replaces: libc6 (<< 2.1-4) Depends: libc6 (>= 2.3.2.ds1-16) Filename: pool/main/g/glibc/nscd_2.3.2.ds1-16_i386.deb Size: 90436 MD5sum: 4830a171d3ef40bef18315bcfb47be3a Description: GNU C Library: Name Service Cache Daemon A daemon which handles passwd, group and host lookups for running programs and caches the results for the next query. You should install this package only if you use slow Services like LDAP, NIS or NIS+ _________________________________________________________ B.3. Configuración nscd se configura a través del archivo /etc/nscd.conf (puede encontrar un ejemplo del mismo en el Apéndice AA). Los únicos parámetros que se tocarán de ese archivo de configuración son los siguientes: logfile /var/log/nscd.log server-user nscd El primer parámetro especifica el archivo de log que va a emplear el demonio nscd y el segundo el usuario con el que se ejecutará en el sistema. Como el usuario nscd no existe en la máquina, se crea: Ejemplo B-3. Creación del usuario nscd # /usr/sbin/addgroup --system nscd Añadiendo el grupo nscd (135)... Hecho. # /usr/sbin/adduser --system --no-create-home --shell /bin/false \ --ingroup nscd --disabled-password --disabled-login nscd Añadiendo usuario del sistema nscd... No se crea el directorio home. Antes de arrancar el demonio nscd, se modifican el propietario y grupo del archivo de log y, si es necesario, el del archivo /var/run/nscd.pid. Ejemplo B-4. Cambio del propietario y grupo de algunos archivos relativos a nscd # /bin/chown nscd\:nscd /var/log/nscd.log /var/run/nscd.pid Ahora ya se puede arrancar el demonio: Ejemplo B-5. Arranque del demonio nscd # /etc/init.d/nscd start Starting Name Service Cache Daemon: nscd. _________________________________________________________ Apéndice C. Ejecución de Samba desde (x)inetd C.1. Introducción Para poder ejecutar Samba desde el superservidor (x)inetd, hay que indicarlo en el archivo /etc/defaul/samba (en el Apéndice AB tiene un ejemplo de este archivo de configuración). La forma de hacerlo sería asignando el valor "inetd" a la variable RUN_MODE (esta variable acepta los valores "daemons" e "inetd"). Una vez hecho esto, sólo quedaría configurar el superservidor para que gestione las conexiones de Samba. En las siguientes secciones se verá como hacerlo para los superservidores inetd y xinetd. _________________________________________________________ C.2. Superservidor inetd En el Ejemplo 7-4 se puede ver como en la instalación de Samba se añade la siguiente línea al archivo de configuración del superservidor inetd: ## netbios-ssn stream tcp nowait root /usr/sbin/tcpd /usr/sbin/smbd Como se puede ver al comienzo de la línea, esta se encuentra desactivada (## ...) por defecto; si se quieren gestionar las conexiones de Samba desde inetd, se ha de activar. En el Ejemplo C-1 se ve como hacerlo: Ejemplo C-1. Habilitando el servicio "netbios-ssn" en el superservidor inetd # /usr/sbin/update-inetd --verbose --enable netbios-ssn Processing /etc/inetd.conf Processing service `netbios-ssn' ... enabled Ahora sólo queda hacer que el superservidor inetd lea de nuevo su configuración, para ello se ha de teclear (suponiendo que el superservidor ya se esté ejecutando): Ejemplo C-2. Haciendo que el superservidor inetd relea su configuración # /usr/bin/killall --verbose -HUP inetd Killed inetd(3005) with signal 1 Si todo ha ido bien, en este punto el superservidor inetd gestionaría las conexiones de Samba. _________________________________________________________ C.3. Superservidor xinetd Para ejecutar Samba desde el superservidor xinetd se ha de crear la configuración para este servicio en dicho superservidor. Esto se realiza creando un nuevo archivo denominado samba bajo el directorio /etc/xinetd.d, cuyo contenido sea: Ejemplo C-3. Contenido del archivo /etc/xinetd.d/samba service netbios-ssn { disable = no (1) socket_type = stream protocol = tcp wait = no user = root server = /usr/sbin/smbd } (1) Variable que controla si el servicio está o no activo. Si su valor es igual a "yes", el servicio estará deshabilitado, si es "no", estará habilitado. Ahora haga que el superservidor xinetd relea su configuración de la siguiente manera: Ejemplo C-4. Releyendo la configuración de xinetd # /etc/init.d/xinetd reload Reloading internet superserver configuration: xinetd. Una vez ejecutada la orden del Ejemplo C-4, el superservidor xinetd pasaría a gestionar las conexiones a Samba. _________________________________________________________ Apéndice D. Opciones del kernel Linux para Samba Para poder montar los sistemas de archivos que sirve Samba, es necesario que el núcleo Linux del ordenador donde se pretenden montar, tenga soporte para dicho sistema de archivos. Las opciones necesarias para conseguir este soporte en el núcleo Linux se verán a continuación (tanto para la versión 2.4.27 como para la 2.6.8.1, que son la versiones con las que se ha trabajado para realizar este documento): _________________________________________________________ D.1. Kernel 2.4.* Tecleando make menuconfig en el directorio raíz de las fuentes del núcleo, veamos como llegar a las opciones necesarias: Nota En esta documentación se ha empleado la versión 2.4.27 del núcleo Linux. Figura D-1. Sistema de archivos [samba-opciones-kernel-2.4.png] Entramos en la selección de los distintos sistemas de archivos soportados por el núcleo. Figura D-2. Sistema de archivos en red [samba-opciones-kernel-2.41.png] Seleccionamos la opción sistema de archivos en red. Figura D-3. Opciones relativas Samba [samba-opciones-kernel-2.42.png] Soporte para el protocolo SMB y CIFS. Las opciones seleccionadas en la Figura D-3 se pueden resumir en: CONFIG_SMB_FS=m CONFIG_SMB_NLS_DEFAULT=y CONFIG_SMB_NLS_REMOTE="cp850" CONFIG_SMB_UNIX=y _________________________________________________________ D.2. Kernel 2.6.* Tecleando make menuconfig en el directorio raíz de las fuentes del núcleo, veamos como llegar a las opciones necesarias: Nota En esta documentación se ha empleado la versión 2.6.8.1 del núcleo Linux. Figura D-4. Sistema de archivos [samba-opciones-kernel-2.6.png] Entramos en la selección de los distintos sistemas de archivos soportados por el núcleo. Figura D-5. Sistema de archivos en red [samba-opciones-kernel-2.61.png] Seleccionamos la opción sistema de archivos en red. Figura D-6. Opciones relativas Samba [samba-opciones-kernel-2.62.png] Soporte para el protocolo SMB y CIFS. Las opciones seleccionadas en la Figura D-6 se pueden resumir en: CONFIG_SMB_FS=m CONFIG_SMB_NLS_DEFAULT=y CONFIG_SMB_NLS_REMOTE="cp850" CONFIG_CIFS=m CONFIG_CIFS_STATS=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y _________________________________________________________ Apéndice E. Instalación y configuración de SWAT E.1. Introducción SWAT es una herramienta de configuración de Samba vía web. En las siguientes secciones se verán los pasos para ponerla en funcionamiento. _________________________________________________________ E.2. Instalación de SWAT En el siguiente ejemplo se muestra la información relativa al paquete swat y la forma de instalarlo: Ejemplo E-1. Instalación de SWAT (primera parte) $ /usr/bin/apt-cache show swat Package: swat Priority: optional Section: net Installed-Size: 8968 Maintainer: Eloy A. Paris Architecture: i386 Source: samba Version: 3.0.7-1 Depends: debconf, samba (= 3.0.7-1), libc6 (>= 2.3.2.ds1-4), libcomerr2 (>= 1.33-3), libcupsys2-gnutls10 (>= 1.1.20final-1), libkrb53 (>= 1.3.2), libldap2 (>= 2.1.17-1), libpam0g (>= 0.76), libpopt0 (>= 1.7) Recommends: samba-doc Filename: pool/main/s/samba/swat_3.0.7-1_i386.deb Size: 3964890 MD5sum: d84a020935c85831d8d81321b7391ed4 Description: Samba Web Administration Tool The Samba software suite is a collection of programs that implements the SMB protocol for unix systems, allowing you to serve files and printers to Windows, NT, OS/2 and DOS clients. This protocol is sometimes also referred to as the LanManager or NetBIOS protocol. . This package contains the components of the Samba suite that are neede d for Web administration of the Samba server. . Note: if you want to use the on-line documentation that is accesible through the Swat front-end you must install the samba-doc package. Task: file-server, print-server #/usr/bin/apt-get install swat Leyendo lista de paquetes... Hecho Creando árbol de dependencias... Hecho Se instalarán los siguientes paquetes NUEVOS: swat 0 actualizados, 1 se instalarán, 0 para eliminar y 1 no actualizados. Se necesita descargar 0B/3965kB de archivos. Se utilizarán 9183kB de espacio de disco adicional después de desempaqu etar. Preconfiguring packages ... Figura E-1. Aviso de sobreescritura del archivo /etc/samba/smb.conf [samba-instalacion-swat.png] El programa SWAT sobreescribe el archivo de configuración de Samba, eliminado los comentarios, entre otras cosas. Esta pantalla avisa de este hecho, y recomienda no utilizar SWAT en aquellos casos en los que se tenga muy personalizado el archivo de configuración de Samba. Ejemplo E-2. Instalación de SWAT (segunda parte) Seleccionando el paquete swat previamente no seleccionado. (Leyendo la base de datos ... 133905 ficheros y directorios instalados actualmente.) Desempaquetando swat (de .../archives/swat_3.0.7-1_i386.deb) ... Configurando swat (3.0.7-1) ... --------- IMPORTANT INFORMATION FOR XINETD USERS ---------- The following line will be added to your /etc/inetd.conf file: ## swat\t\tstream\ttcp\tnowait.400\troot\t/usr/sbin/tcpd\t/usr/sbi n/swat If you are indeed using xinetd, you will have to convert the above into /etc/xinetd.conf format, and add it manually. See /usr/share/doc/xinetd/README.Debian for more information. ----------------------------------------------------------- localepurge: checking system for new locale ... localepurge: processing locale files ... localepurge: processing man pages ... _________________________________________________________ E.3. Gestión de SWAT desde un superservidor (x)inetd A continuación se verá la forma de configurar SWAT para que sea gestionado desde los superservidores inetd y xinetd: _________________________________________________________ E.3.1. Gestión de SWAT desde inetd Tras la instalación de SWAT, se ha de activar en el archivo de configuración de inetd: Ejemplo E-3. Activación de SWAT en inetd # /usr/sbin/update-inetd --verbose --enable swat Processing /etc/inetd.conf Processing service `swat' ... enabled Ahora se hace que el superservidor inetd relea su configuración, quedando el servicio SWAT disponible en el sistema: Ejemplo E-4. Haciendo que el superservidor inetd relea su configuración # /usr/bin/killall --verbose -HUP inetd Killed inetd(3005) with signal 1 Como se puede ver en el Ejemplo E-5, SWAT está a la espera de peticiones: Ejemplo E-5. Mostrando las conexiones de SWAT # /bin/netstat -puta | /bin/grep swat Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address Sta te PID/Program name tcp 0 0 *:swat *:* LIS TEN 1265/inetd _________________________________________________________ E.3.2. Gestión de SWAT desde xinetd Para ejecutar SWAT desde el superservidor xinetd se ha de crear la configuración para este servicio en dicho superservidor. Esto se realiza creando un nuevo archivo denominado swat bajo el directorio /etc/xinetd.d, cuyo contenido sea: Ejemplo E-6. Contenido del archivo /etc/xinetd.d/swat service swat { disable = no (1) socket_type = stream protocol = tcp wait = no user = root server = /usr/sbin/swat # server_args = -a (2) } (1) Variable que controla si el servicio está o no activo. Si su valor es igual a "yes", el servicio estará deshabilitado, si es "no", estará habilitado. (2) Esta línea, en caso de estar descomentada, está destinada al paso de parámetros para el servidor swat. La opción "-a" deshabilitaría la autentificación, permitiendo a cualquier persona modificar la configuración de Samba. ¡Tenga cuidado con su uso! Ahora haga que el superservidor xinetd relea su configuración de la siguiente manera: Ejemplo E-7. Releyendo la configuración de xinetd # /etc/init.d/xinetd reload Reloading internet superserver configuration: xinetd. Una vez ejecutada la orden del Ejemplo E-7, el superservidor xinetd pasaría a gestionar las conexiones a Samba: Ejemplo E-8. Mostrando las conexiones de SWAT # /bin/netstat -puta | /bin/grep swat Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address Sta te PID/Program name tcp 0 0 *:swat *:* LIS TEN 4687/xinetd _________________________________________________________ E.4. Accediendo a SWAT Para ejecutar SWAT, teclee en su navegador favorito la siguiente dirección: http://localhost:901/ y verá algo similar a: Figura E-2. Acceso a SWAT [samba-swat1.png] Ventana de ejecución de KDE, aparece tecleando: Alt+F2. Figura E-3. Autentificación [samba-swat2.png] Si no se ha utilizado el parámetro "-a" en el arranque de SWAT, será necesario autentificarse antes de poder entrar en la herramienta. Figura E-4. Pantalla principal de SWAT [samba-swat3.png] Pantalla principal de SWAT, desde aquí se puede acceder a todas las partes de la configuración de Samba. _________________________________________________________ Apéndice F. Instalación y configuración de LAM (LDAP Account Manager) F.1. Instalación LAM es un frontend web para la administración de usuarios para cuentas unix y Samba dentro de un directorio LDAP. Su descripción es la siguiente: Ejemplo F-1. Descripción de LAM $ /usr/bin/apt-cache show ldap-account-manager Package: ldap-account-manager Priority: extra Section: web Installed-Size: 2208 Maintainer: Roland Gruber Architecture: all Version: 0.4.6-2 Depends: php4 | php4-cgi | libapache2-mod-php4, php4-ldap, apache | apache-ssl | httpd, perl, wwwconfig-common, debconf Recommends: php4-mhash Suggests: ldap-server, sudo, php4-mcrypt Conflicts: php4-apc Filename: pool/main/l/ldap-account-manager/ldap-account-manager_0.4.6-2 _all.deb Size: 406002 MD5sum: 03bb45d124c8783415631f884c97692e Description: Webfrontend for managing Unix and Samba accounts in a LDAP directory LDAP Account Manager (LAM) runs on an existing webserver. LAM supports LDAP connections via SSL and TLS. It uses the Samba 2.x or Samba 3 schema and manages user, group and host accounts. You can use templates for account creation and use multiple configuration profiles. Account information can be exported as PDF file. There is also a script included which manages quota and homedirectories, you have to setup sudo if you want to use it. LAM is translated to English, French, German, Hungarian and Japanese. . Homepage: http://lam.sourceforge.net/ La manera de instalar este software se muestra a continuación: Ejemplo F-2. Instalación de LAM (primera parte) # /usr/bin/apt-get install ldap-account-manager Leyendo lista de paquetes... Hecho Creando árbol de dependencias... Hecho Se instalarán los siguientes paquetes extras: apache apache-common apache-utils libapache-mod-php4 libapache-mod-ss l libmm13 php4 php4-common php4-ldap wwwconfig-common Paquetes sugeridos: apache-doc apache-ssl apache-perl sudo php4-mcrypt php4-pear libapach e-mod-ssl-doc mysql-client postgresql-client Paquetes recomendados php4-mhash Se instalarán los siguientes paquetes NUEVOS: apache apache-common apache-utils ldap-account-manager libapache-mod- php4 libapache-mod-ssl libmm13 php4 php4-common php4-ldap wwwconfig-common 0 actualizados, 11 se instalarán, 0 para eliminar y 2 no actualizados. Se necesita descargar 0B/3958kB de archivos. Se utilizarán 11,3MB de espacio de disco adicional después de desempaqu etar. ¿Desea continuar? [S/n] Preconfiguring packages ... Figura F-1. ¿Arrancar Apache en el arranque? [lam-instalacion1.png] Adapte la respuesta a esta pregunta a sus necesidades, en este caso se ha decidido arrancar Apache en el arranque. Figura F-2. ¿Activar suExec? [lam-instalacion2.png] La respuesta a esta pregunta es negativa, de momento no se va a necesitar esta funcionalidad, por lo que así se evita tener un archivo setuid más en el sistema. Figura F-3. ¿Para qué servidor(es) web se ha de configurar LAM? [lam-instalacion3.png] En esta documentación sólo se ha instalado el servidor web Apache, por lo que se elige esta opción. La funcionalidad SSL en Apache se provee mediante el módulo mod_ssl (paquete libapache-mod-ssl). Figura F-4. Alias para el acceso a LAM desde el servidor web [lam-instalacion4.png] Teclee en esta pantalla el alias con el que quiera acceder a la aplicación LAM desde su servidor web. En este caso se ha seleccionado el alias lam, por lo que para acceder a la herramienta, se hará a través de: http://gsr.pt/lam/. Figura F-5. Clave para el administrador de los perfiles dentro de LAM [lam-instalacion5.png] Teclee la clave, en texto plano, que desee para el administrador de perfiles de la herramienta LAM. Ejemplo F-3. Instalación de LAM (segunda parte) Seleccionando el paquete apache-utils previamente no seleccionado. (Leyendo la base de datos ... 134049 ficheros y directorios instalados actualmente.) Desempaquetando apache-utils (de .../apache-utils_1.3.31-6_i386.deb) .. . Seleccionando el paquete apache-common previamente no seleccionado. Desempaquetando apache-common (de .../apache-common_1.3.31-6_i386.deb) ... Seleccionando el paquete apache previamente no seleccionado. Desempaquetando apache (de .../apache_1.3.31-6_i386.deb) ... Seleccionando el paquete libmm13 previamente no seleccionado. Desempaquetando libmm13 (de .../libmm13_1.3.0-3_i386.deb) ... Seleccionando el paquete libapache-mod-ssl previamente no seleccionado. Desempaquetando libapache-mod-ssl (de .../libapache-mod-ssl_2.8.19-1_i3 86.deb) ... Seleccionando el paquete php4-common previamente no seleccionado. Desempaquetando php4-common (de .../php4-common_4%3a4.3.8-12_i386.deb) ... Seleccionando el paquete libapache-mod-php4 previamente no seleccionado . Desempaquetando libapache-mod-php4 (de .../libapache-mod-php4_4%3a4.3.8 -12_i386.deb) ... Seleccionando el paquete php4 previamente no seleccionado. Desempaquetando php4 (de .../php4_4%3a4.3.8-12_all.deb) ... Seleccionando el paquete php4-ldap previamente no seleccionado. Desempaquetando php4-ldap (de .../php4-ldap_4%3a4.3.8-12_i386.deb) ... Seleccionando el paquete wwwconfig-common previamente no seleccionado. Desempaquetando wwwconfig-common (de .../wwwconfig-common_0.0.40_all.de b) ... Seleccionando el paquete ldap-account-manager previamente no selecciona do. Desempaquetando ldap-account-manager (de .../ldap-account-manager_0.4.6 -2_all.deb) ... Configurando apache-utils (1.3.31-6) ... Configurando apache-common (1.3.31-6) ... Configurando apache (1.3.31-6) ... Figura F-6. Módulos que cargará Apache [lam-instalacion6.png] Asegúrese de que están marcados los módulos mod_ssl y mod_php4. El primero será necesario para activar el soporte SSL en Apache y el segundo para activar el soporte PHP4. Figura F-7. Nombre del dominio que servirá Apache por defecto [lam-instalacion7.png] Teclee en esta pantalla el FQDN de su servidor web. Figura F-8. Dirección de correo electrónico del administrador de Apache [lam-instalacion8.png] Complete el campo de la captura con la dirección del administrador encargado del servidor Apache. Figura F-9. Directorio raíz de Apache por defecto [lam-instalacion9.png] Sería recomendable dejar la sugerencia que se muestra en esta pantalla como directorio raíz de su servidor web. Figura F-10. Puerto de escucha de Apache [lam-instalacion10.png] Establezca el puerto donde ha de escuchar Apache. Ejemplo F-4. Instalación de LAM (tercera parte) Creating config file /etc/apache/httpd.conf with new version Creating config file /etc/apache/srm.conf with new version Creating config file /etc/apache/access.conf with new version Creating config file /etc/apache/modules.conf with new version Starting web server: apache. Configurando libmm13 (1.3.0-3) ... Configurando libapache-mod-ssl (2.8.19-1) ... ./snakeoil-ca-rsa.crt ... e52d41d0.0 ./ca-bundle.crt ... Skipped ./snakeoil-dsa.crt ... 5d8360e1.0 ./snakeoil-rsa.crt ... 82ab5372.0 ./snakeoil-ca-dsa.crt ... 0cf14d7d.0 Configurando php4-common (4.3.8-12) ... Configurando libapache-mod-php4 (4.3.8-12) ... Configurando php4 (4.3.8-12) ... Configurando php4-ldap (4.3.8-12) ... Figura F-11. Activar la extensión LDAP en PHP4 [lam-instalacion11.png] Seleccione Sí si desea activar la extensión LDAP en PHP4, sería recomendable, para que LAM funcionase. Ejemplo F-5. Instalación de LAM (cuarta parte) Configurando wwwconfig-common (0.0.40) ... Configurando ldap-account-manager (0.4.6-2) ... localepurge: checking system for new locale ... localepurge: processing locale files ... localepurge: processing man pages ... Nota Si no ve alguna de las pantallas de configuración que aquí se muestran, tal vez sea necesario forzar la configuración de algunos paquetes a "bajo nivel". Para ello puede teclear: # /usr/sbin/dpkg-reconfigure ldap-account-manager O # /usr/sbin/dpkg-reconfigure apache O # /usr/sbin/dpkg-reconfigure php4-ldap _________________________________________________________ F.2. Configuración F.2.1. Configuración relativa a Apache Nota Si desea ver como se configura Apache para el soporte SSL, vea el Apéndice I. Antes de proceder a la configuración de la herramienta, se va a obligar al servidor web Apache a servir las páginas relacionadas con LAM en modo SSL. Para ello, edite el archivo /etc/ldap-account-manager/apache.conf y añada las siguientes líneas al final del archivo: # redirect to https when available (thanks omen@descolada.dartmouth.edu ) RewriteEngine on RewriteCond %{HTTPS} !=on RewriteRule . https://%{HTTP_HOST}%{REQUEST_URI} [L] El siguiente paso será hacer que el servidor Apache relea su configuración: Ejemplo F-6. Releyendo la configuración de Apache # /etc/init.d/apache reload Reloading apache configuration. _________________________________________________________ F.2.2. Configuración desde la interfaz web Ahora que ya está instalado LAM en el sistema, el siguiente paso será acceder a la interfaz LAM con un navegador web. Para ello se ha de teclear la siguiente URL en su navegador favorito: http://gsr.pt/lam (suponiendo que "gsr.pt" sea su dominio). En las siguientes capturas se mostrará el proceso de configuración de LAM desde la interfaz web. Durante el proceso se creará un nuevo perfil. Importante No utilice caracteres especiales al reyenar los campos, pues LAM no los reconoce. Figura F-12. URL donde está instalado LAM [lam-configuracion1.png] Si se encuentra en un entorno de escritorio con KDE, teclee Alt+F2 e introduzca la dirección donde se encuentre instalado LAM. Figura F-13. Aviso acerca del certificado del servidor web I [lam-configuracion-certificado1.png] Si ha configurado correctamente el servidor web, a la hora de acceder a la aplicación LAM por el protocolo http, Apache le tendría que redireccionar a la misma dirección, pero bajo el protocolo https. Esto es lo que ha ocurrido en esta pantalla, Apache ha redirigido la petición realizada (http://gsr.pt/lam/) hacia el protocolo https. Por este motivo, y debido a que la entidad certificadora que se ha creado es desconocida, sale este aviso. Pulse sobre el botón Detalles para obtener más información. Figura F-14. Información SSL [lam-configuracion-certificado2.png] En esta pantalla se muestra la información del certificado y la entidad certificadora que ha creado dicho certificado. Si se fija, aquí aparecerán los datos tecleados en el Apéndice I. Pulse sobre el botón Cerrar para continuar. Figura F-15. Aviso acerca del certificado del servidor web II [lam-configuracion-certificado3.png] Pulse ahora sobre el botón Continuar para seguir con la carga de la página. Figura F-16. Período de aceptación del certificado [lam-configuracion-certificado4.png] Seleccione la opción deseada y pulse sobre ella. Figura F-17. Pantalla de ingreso [lam-configuracion2.png] Pantalla principal de LAM antes del ingreso. Como es la primera vez que se accede, se creará un nuevo perfil adaptado a las necesidades del sistema. Para ello pulse sobre Configuration Login. Figura F-18. Pantalla de configuración [lam-configuracion3.png] Esta imagen presenta la pantalla de configuración de LAM, aquí seleccione el enlace: Configuration wizard. Figura F-19. Asistente de configuración, datos del perfil [lam-configuracion4.png] A partir de esta pantalla, se irán completando las distintas opciones que presente el asistente de configuración de LAM. Aquí se pide el nombre para el nuevo perfil (Profile name), la clave para acceder al nuevo perfil creado (Password) y la clave principal (Master password) de LAM, recuerde que esta clave se estableció en el proceso de instalación (Figura F-5). Figura F-20. Asistente de configuración, datos del servidor LDAP y Samba [lam-configuracion5.png] Pantalla dedicada a la localización del servidor LDAP y la versión de Samba: * Server address: dirección del servidor LDAP que se va a utilizar. Nota Como no especifíca en ningún lugar la forma de activar el uso de TLS para las comunicaciones contra el servidor LDAP, si quiere asegurarse una conexión cifrada entre LAM y el servidor LDAP, especifique aquí la dirección mediante el protocolo ldaps, para utilizar SSL en las comunicaciones. * LDAP admin DN: administrador del directorio LDAP. * Password: clave para el administrador del directorio LDAP. * Samba version: versión de Samba que se va a emplear, en este caso es la versión 3.* Figura F-21. Asistente de configuración, creando la estructura para el directorio LDAP [lam-configuracion6.png] Las cuentas que se crearán a través de LAM se almacenarán en el directorio LDAP de la forma que se indique en este paso: * UserSuffix: lugar donde se almacenarán las cuentas de los usuarios. * GroupSuffix: lugar donde se almacenarán las cuentas de los grupos de usuarios. * HostSuffix: lugar donde se almacenará la información sobre las máquinas Samba. * DomainSuffix: lugar donde se almacenará la información sobre los dominios Samba. * Password hash type: tipo de algoritmo de hash a utilizar para almacenar las claves, en este caso se ha elegido el tipo MD5. * Cache timeout: tiempo que LAM mantendrá en su caché las búsquedas LDAP realizadas. * Optional settings: las opciones por defecto se adaptan a las necesidades del proyecto, por lo que no se selecciona ninguna opción en este cuadro. La última opción: Lamdaemon settings and PDF text sirve para ajustar, entre otras cosas, la ruta al script lamdaemon.pl. Este script permite la creación/eliminación de los directorios home de los usuarios y el establecimiento de quotas para los mismos. En esta documentación no se ha empleado dicho script, en su lugar se ha empleado el script del Apéndice K. Figura F-22. Asistente de configuración, confirmación de la creación de entradas LDAP [lam-configuracion7.png] Confirmación para la creación de las nuevas entradas en el directorio LDAP. Figura F-23. Asistente de configuración, creación de un dominio [lam-configuracion8.png] Aquí se introducirá el dominio que se va a utilizar en Samba así como el SID del servidor donde está alojado, las demás opciones se dejarán como están. De esta forma, en la opción Domain name se ha de teclear el dominio correspondiente (en este caso GSRDOMAIN). La forma de obtener el SID se muestra en el Ejemplo F-7, su resultado se ha de introducir en la opción Domain SID. Ejemplo F-7. Obtención del SID # /usr/bin/net getlocalsid SID for domain TODOSCSI is: S-1-5-21-2817058862-34499604-3382793611 Figura F-24. Asistente de configuración, creación de grupos para Samba [lam-configuracion9.png] El asistente pide confirmación para la creación de una serie de grupos esenciales para Samba, se pulsa sobre Create para continuar. Figura F-25. Información sobre el nuevo perfil creado [lam-configuracion10.png] Esta pantalla muestra la información que se a almacenado para el perfil GSR que se acaba de crear. A continuación se regresará a la pantalla de ingreso, pulsando sobre el enlace Back to Login. Como se ha creado un nuevo perfil adaptado a las necesidades del sistema, GSR, sería recomendable modificar el archivo /etc/ldap-account-manager/config.cfg para indicar que el perfil por defecto pasa a ser GSR y no lam. Para ello, se ha de asignar el valor GSR a la variable: default. Figura F-26. Ingreso en LAM [lam-configuracion11.png] En estos momentos, ya se puede ingresar al sistema con el perfil que se acaba de añadir. Para ello, si no está seleccionado, elija el perfil GSR y pulse sobre: Change Profile. Una vez seleccionado el perfil adecuado, se ha de teclear la clave del administrador del directorio LDAP y pulsar sobre Login. Figura F-27. Pantalla principal de LAM [lam-configuracion12.png] Nada más ingresar en la herramienta, se muestran los usuarios que posee el directorio LDAP bajo la unidad organizacional people (en estos momentos no hay ningún usuario, ya que se acaba de crear la estructura y todavía no se ha añadido ningún usuario). Figura F-28. Dominios existentes [lam-configuracion13.png] Si se pulsa sobre el enlace Domains, se listan los dominios existentes bajo la unidad organizacional domains. En estos momentos, sólo hay un dominio: GSRDOMAIN, creado en el proceso de configuración. Figura F-29. Grupos existentes [lam-configuracion14.png] Bajo el enlace Groups, se listan los grupos existentes bajo la unidad organizacional groups. Actualmente los grupos existentes únicamente son tres, los que se han creado durante el proceso de configuración. Nota Si no ha cambiado el grupo del directorio /home/samba/netlogon/, este sería un buen momento para hacerlo. Más detalles en el Ejemplo 10-4. Figura F-30. Hosts existentes [lam-configuracion15.png] Al pulsar sobre Hosts, se muestran las máquinas de Samba existentes bajo la unidad organizacional machines. Como se puede ver, todavía no se ha introducido ninguna máquina. Figura F-31. Saliendo de la herramienta [lam-configuracion16.png] Una vez se ha finalizado el uso de la herramienta, se ha de salir de la misma, para ello se ha de pulsar sobre el enlace Logout. LAM ya se encuentra completamente instalado y adaptado a las necesidades del sistema, por lo que ya se puede comenzar a utilizar para la administración de usuarios y demás aspectos relativos. En las secciones Sección 11.3 y Sección 12.3.1 tiene un ejemplo sobre como crear cuentas de usuario y máquina, respectivamente. _________________________________________________________ Apéndice G. Instalación y configuración de phpLDAPadmin G.1. Instalación phpLDAPadmin es una interfaz web destinada a la administración de un directorio LDAP. Antes de proceder con la instalación de phpLDAPadmin, se verá la descripción del paquete phpldapadmin, que provee dicha herramienta dentro de Debian: Ejemplo G-1. Descripción de phpLDAPadmin $ /usr/bin/apt-cache show phpldapadmin Package: phpldapadmin Priority: extra Section: admin Installed-Size: 1716 Maintainer: Fabio Tranchitella Architecture: all Version: 0.9.4-9 Depends: apache | httpd, php4-ldap, php4 (>= 4.1.0) | php4-cgi (>= 4.1.0) | libapache2-mod-php4, debconf (> = 0.2.26) Filename: pool/main/p/phpldapadmin/phpldapadmin_0.9.4-9_all.deb Size: 374178 MD5sum: eea7c0c0bc601462e999a5207c530846 Description: Web based interface for administering LDAP servers phpLDAPadmin is a web-based LDAP client. It provides easy, anywhere-accessible, multi-language administration for your LDAP server. Its hierarchical tree-viewer and advanced search functionality make it intuitive to browse and administer your LDAP directory. Since it is a web application, this LDAP browser works on many platforms, makin g your LDAP server easily manageable from any location. El proceso de instalación de esta herramienta se muestra en el siguiente ejemplo: Ejemplo G-2. Instalación del paquete phpldapadmin (primera parte) # /usr/bin/apt-get install phpldapadmin Leyendo lista de paquetes... Hecho Creando árbol de dependencias... Hecho Se instalarán los siguientes paquetes NUEVOS: phpldapadmin 0 actualizados, 1 se instalarán, 0 para eliminar y 1 no actualizados. Se necesita descargar 0B/374kB de archivos. Se utilizarán 1757kB de espacio de disco adicional después de desempaqu etar. Preconfiguring packages ... Figura G-1. ¿Qué tipo de autentificación desea? [phpldapadmin-instalacion1.png] Seleccione aquí el tipo de autentificación que más se ajuste a sus necesidades, en esta documentación se ha seleccionado la opción "session". Figura G-2. ¿Qué servidor web reconfigurar? [phpldapadmin-instalacion2.png] Elija la versión(es) de Apache que tenga instalada(s) o aquella(s) para la(s) cual(es) quiera configurar el acceso a phpldapadmin. Figura G-3. ¿Reiniciar el servidor web? [phpldapadmin-instalacion3.png] Sería recomendable reiniciar el servidor web, para que relea la nueva configuración. Ejemplo G-3. Instalación del paquete phpldapadmin (segunda parte) Seleccionando el paquete phpldapadmin previamente no seleccionado. (Leyendo la base de datos ... 135022 ficheros y directorios instalados actualmente.) Desempaquetando phpldapadmin (de .../phpldapadmin_0.9.4-9_all.deb) ... Configurando phpldapadmin (0.9.4-9) ... Restarting apache. localepurge: checking system for new locale ... localepurge: processing locale files ... localepurge: processing man pages ... _________________________________________________________ G.2. Configuración G.2.1. Configuración relativa a Apache Nota Si desea ver como se configura Apache para el soporte SSL, vea el Apéndice I. Antes de proceder a la configuración de la herramienta, se va a obligar al servidor web Apache a servir las páginas relacionadas con phpLDAPadmin en modo SSL. Para ello, edite el archivo /etc/phpldapadmin/apache.conf y añada las siguientes líneas al final del archivo: # redirect to https when available (thanks omen@descolada.dartmouth.edu ) RewriteEngine on RewriteCond %{HTTPS} !=on RewriteRule . https://%{HTTP_HOST}%{REQUEST_URI} [L] El siguiente paso será hacer que el servidor Apache relea su configuración: Ejemplo G-4. Releyendo la configuración de Apache # /etc/init.d/apache reload Reloading apache configuration. _________________________________________________________ G.2.2. Ajustes en la configuración El último paso antes de tener phpLDAPadmin completamente instalado y configurado, es retocar varios archivos de configuración del mismo. Las siguientes secciones mostrarán dichos cambios. _________________________________________________________ G.2.2.1. /etc/phpldapadmin/config.php Las siguientes líneas mostrarán las opciones más importantes del archivo de configuración /etc/phpldapadmin/config.php y los valores adoptados en esta documentación. Nota En el Apéndice AI posee un ejemplo completo de este archivo de configuración. 1. Nombre del equipo donde está alojado el servidor LDAP: $servers[$i]['name'] = 'TodoSCSI'; 2. URL del servidor LDAP. Si quiere utilizar TLS en la conexión contra el servidor LDAP (como es el caso de esta documentación), asegúrese de indicar aquí la dirección del servidor LDAP por el protocolo ldap. $servers[$i]['host'] = 'ldap://gsr.pt'; 3. La base DN del servidor LDAP. $servers[$i]['base'] = 'dc=gsr,dc=pt'; 4. Puerto del servidor LDAP. Al igual que se indicaba anteriormente, especifique aquí el puerto del servidor LDAP que no utilice cifrado SSL, esto es necesario para realizar las conexiones por TLS. $servers[$i]['port'] = 389; 5. Tipo de autentificación que se utilizará. Esta opción ya se definió en el proceso de instalación de phpldapadmin (vea la Figura G-1 para más datos). $servers[$i]['auth_type'] = 'session'; 6. Usuario con el que se desea ingresar en phpLDAPadmin por defecto. El DN que aquí se teclee, aparecerá por defecto siempre que trate de ingresar en la herramienta. $servers[$i]['login_dn'] = 'cn=admin,dc=gsr,dc=pt'; 7. Se activa la conexión por TLS entre la aplicación phpLDAPadmin y el servidor LDAP. $servers[$i]['tls'] = true; 8. Seleccione el algoritmo de hash que desee utilizar por defecto para el cifrado de las claves. $servers[$i]['default_hash'] = 'crypt'; 9. Si se quiere que phpLDAPadmin busque y asigne automáticamente el uid para las nuevas entradas, active esta opción. $servers[$i]['enable_auto_uid_numbers'] = true; 10. Método para buscar el primer uid disponible en el sistema. $servers[$i]['auto_uid_number_mechanism'] = 'search'; 11. Base de la búsqueda para encontrar el siguiente uid libre en el sistema. $servers[$i]['auto_uid_number_search_base'] = 'ou=people,dc=gsr,dc=pt'; 12. Si se ha seleccionado la opción "search" para encontrar automáticamente los uids de las nuevas entradas, indique aquí el valor mínimo que un UID puede tener. $servers[$i]['auto_uid_number_min'] = 1000; _________________________________________________________ G.2.2.2. /etc/phpldapadmin/templates/template_config.php En este archivo se configuran algunos aspectos relativos a Samba y la forma de añadir cuentas al sistema. A continuación se verán las partes que se han modificado de este archivo, en relación al archivo original distribuido con la herramienta: Nota En el Apéndice AJ posee un archivo de configuración completo. Ejemplo G-5. Modificaciones realizadas al archivo template_config.php --- template_config.php.orig 2004-10-01 18:22:34.000000000 +0200 +++ template_config.php 2004-10-01 22:10:18.000000000 +0200 @@ -101,7 +101,7 @@ // uncomment to set the base dn of posix groups // default is set to the base dn of the server -//$base_posix_groups="ou=People,dc=example,dc=com"; +$base_posix_groups="ou=groups,dc=gsr,dc=pt"; (1) @@ -117,29 +117,30 @@ ###################################################################### ################*/ // path 2 the mkntpwd utility (Customize) -$mkntpwdCommand = "./templates/creation/mkntpwd"; +$mkntpwdCommand = "/usr/sbin/smbldap-passwd"; (2) // Default domains definition (Customize) // (use `net getlocalsid` on samba server) $default_samba3_domains = array(); $default_samba3_domains[] = - array( 'name' => 'My Samba domain Name', - 'sid' => 'S-1-5-21-479559372-1547523452-3818884970' ); + array( 'name' => 'GSRDOMAIN', (3) + 'sid' => 'S-1-5-21-2817058862-34499604-3382793611' ); (4) // The base dn of samba group. (CUSTOMIZE) -//$samba_base_groups = "ou=Groups,ou=samba,dc=example,dc=org"; +$samba_base_groups = "ou=groups,dc=gsr,dc=pt"; (5) //Definition of built-in local groups -$built_in_local_groups = array( "S-1-5-32-544" => "Administrators", - "S-1-5-32-545" => "Users", - "S-1-5-32-546" => "Guests", - "S-1-5-32-547" => "Power Users", - "S-1-5-32-548" => "Account Operators", - "S-1-5-32-549" => "Server Operators", - "S-1-5-32-550" => "Print Operators", - "S-1-5-32-551" => "backup Operators", - "S-1-5-32-552" => "Replicator" ); +$built_in_local_groups = array( + "S-1-5-21-2817058862-34499604-3382793611-512" => "Admi nistrators", (6) + "S-1-5-21-2817058862-34499604-3382793611-513" => "User s", + "S-1-5-21-2817058862-34499604-3382793611-514" => "Gues ts", + "S-1-5-21-2817058862-34499604-3382793611-21007" => "Po wer Users", + "S-1-5-21-2817058862-34499604-3382793611-21009" => "Ac count Operators", + "S-1-5-21-2817058862-34499604-3382793611-21011" => "Se rver Operators", + "S-1-5-21-2817058862-34499604-3382793611-21013" => "Pr int Operators", + "S-1-5-21-2817058862-34499604-3382793611-21015" => "ba ckup Operators", + "S-1-5-21-2817058862-34499604-3382793611-21017" => "Re plicator" ); /*#################################################################### ################## (1) Base de la unidad organizacional destinada al almacén de los grupos de usuarios. (2) Localización de la herramienta mkntpwd. Esta herramienta la proveía IDEALX (http://samba.idealx.org/) con el paquete smbldap-tools (versión <=0.8.4). Desde la versión 0.8.5 esta herramienta se ha sustituído por el módulo de perl Crypt::SmbHash. Por este motivo, a partir de ahora se puede hacer uso de la herramienta smbldap-passwd en su lugar. Nota En el Apéndice H podrá ver la forma de instalar y configurar este conjunto de herramientas. (3) Dominio que administra el servidor Samba. (4) SID de la máquina donde se ejecuta Samba. (Vea el Ejemplo F-7 para saber como obtener este número). (5) Base de la unidad organizacional destinada al almacén de los grupos de usuarios. (6) Se modifican los gids que tienen por defecto los grupos listados y se adaptan a los gids de los grupos ya existentes en el sistema (si no existe algún grupo, puede crearlos en este momento, si lo desea). El valor que se ha de añadir en cada uno de los grupos, es el valor del atributo sambaSID de los grupos en cuestión. _________________________________________________________ G.3. Acceso a la aplicación Realizadas las modificaciones de las secciones anteriores, ya se puede acceder a la aplicación, para ello puede teclear en su navegador favorito la URL: http://gsr.pt/phpldapadmin/ (sustituya el dominio por el que se adapte a su configuración). Figura G-4. URL donde está instalado phpLDAPadmin [phpldapadmin1.png] Si se encuentra en un entorno de escritorio con KDE, teclee Alt+F2 e introduzca la dirección donde se encuentre instalado phpLDAPadmin. Figura G-5. Aviso acerca del certificado del servidor web I [lam-configuracion-certificado1.png] Si ha configurado correctamente el servidor web, a la hora de acceder a la aplicación phpLDAPadmin por el protocolo http, Apache le tendría que redireccionar a la misma dirección, pero bajo el protocolo https. Esto es lo que ha ocurrido en esta pantalla, Apache ha redirigido la petición realizada (http://gsr.pt/phpldapadmin/) hacia el protocolo https. Por este motivo, y debido a que la entidad certificadora que se ha creado es desconocida, sale este aviso. Pulse sobre el botón Detalles para obtener más información. Figura G-6. Información SSL [lam-configuracion-certificado2.png] En esta pantalla se muestra la información del certificado y la entidad certificadora que ha creado dicho certificado. Si se fija, aquí aparecerán los datos tecleados en el Apéndice I. Pulse sobre el botón Cerrar para continuar. Figura G-7. Aviso acerca del certificado del servidor web II [lam-configuracion-certificado3.png] Pulse ahora sobre el botón Continuar para seguir con la carga de la página. Figura G-8. Período de aceptación del certificado [lam-configuracion-certificado4.png] Seleccione la opción deseada y pulse sobre ella. Figura G-9. Pantalla principal de phpLDAPadmin [phpldapadmin2.png] Pantalla principal de phpLDAPadmin, para poder administrar el directorio LDAP se ha de efectuar la autentificación. Esto se consigue pulsando sobre el enlace Autenticación... Figura G-10. Autentificándose en phpLDAPadmin [phpldapadmin3.png] Se teclea en el campo correspondiente el DN del usuario con el que quiera acceder al directorio LDAP (recuerde que por defecto aparecerá el usuario que haya tecleado en el archivo de configuración de phpLDAPadmin. En el siguiente enlace puede ver la opción referida anteriormente: Usuario por defecto para el ingreso de phpLDAPadmin) y la clave para dicho usuario. Luego se procede a la autentificación, pulsando sobre el botón Authenticate. Figura G-11. Autentificación realizada con éxito [phpldapadmin4.png] La aplicación informa de la correcta autentificación en el servidor LDAP. Como se puede ver en la imagen, una vez autentificado, la aplicación provee una serie de herramientas para la administración de un directorio LDAP. Estas comprenden desde el listado de los esquemas disponibles en el servidor LDAP, búsquedas, creación de nuevas entradas, información sobre el servidor hasta la posibilidad de importar archivos LDIF. Figura G-12. Árbol de contenidos del directorio [phpldapadmin5.png] Si se pulsa sobre el signo "+" que está a la izquierda de cada objeto, se puede ver los objetos hijos que este posee. Figura G-13. Información sobre un objeto [phpldapadmin6.png] Si se pulsa sobre el nombre de un objeto, por ejemplo sobre ou=people, se puede ver la información almacenada en el mismo, así como proceder a su modificación. Figura G-14. Creación de un nuevo objeto [phpldapadmin7.png] phpLDAPadmin da la posibilidad de crear una serie de objetos predefinidos, ayudando sobremanera a la hora de administrar un servidor LDAP. En esta pantalla se pueden observar aquellos objetos para los que phpLDAPadmin posee plantillas. Figura G-15. Finalizando la sesión [phpldapadmin8.png] Una vez finalizado el trabajo con phpLDAPadmin se ha de finalizar la sesión, para ello se ha de pulsar sobre el enlace salir. _________________________________________________________ Apéndice H. Instalación y configuración de smbldap-tools H.1. Introducción Las herramientas que provee el paquete smbldap-tools, son un conjunto de scripts que se ejecutan sobre las herramientas de sistema user{add,del,mod} y group{add,del,mod} para permitir la manipulación de usuarios y grupos almacenados en un directorio LDAP, destinadas a sistemas DEN como Samba-LDAP y pam/nss_ldap. Adicionalmente, se han diseñado algunos scripts para facilitar la migración de servidores PDC Windows NT 4.0 a servidores PDC Samba-LDAP. Estas son: smbldap-populate, smbldap-migrate-groups y smbldap-migrate-accounts. La última versión de estas herramientas se encuentra en: http://samba.idealx.org/. La versión utilizada para realizar esta documentación ha sido la 0.8.5. _________________________________________________________ H.2. Instalación Las herramientas diseñadas por idealx se encuentran en el paquete smbldap-tools, por lo que tendrá que teclear la siguiente orden para instalarlas: Ejemplo H-1. Instalación del paquete smbldap-tools # /usr/bin/apt-get install smbldap-tools Leyendo lista de paquetes... Hecho Creando árbol de dependencias... Hecho Se instalarán los siguientes paquetes extras: libconvert-asn1-perl libcrypt-smbhash-perl libdigest-md4-perl libnet- ldap-perl Paquetes sugeridos: libio-socket-ssl-perl libxml-parser-perl libauthen-sasl-perl libxml-s ax-perl Se instalarán los siguientes paquetes NUEVOS: libconvert-asn1-perl libcrypt-smbhash-perl libdigest-md4-perl libnet- ldap-perl smbldap-tools 0 actualizados, 5 se instalarán, 0 para eliminar y 1 no actualizados. Se necesita descargar 0B/624kB de archivos. Se utilizarán 1794kB de espacio de disco adicional después de desempaqu etar. ¿Desea continuar? [S/n] Seleccionando el paquete libconvert-asn1-perl previamente no selecciona do. (Leyendo la base de datos ... 133905 ficheros y directorios instalados actualmente.) Desempaquetando libconvert-asn1-perl (de .../libconvert-asn1-perl_0.18- 1_all.deb) ... Seleccionando el paquete libdigest-md4-perl previamente no seleccionado . Desempaquetando libdigest-md4-perl (de .../libdigest-md4-perl_1.1-2_i38 6.deb) ... Seleccionando el paquete libnet-ldap-perl previamente no seleccionado. Desempaquetando libnet-ldap-perl (de .../libnet-ldap-perl_0.3202-2_all. deb) ... Seleccionando el paquete libcrypt-smbhash-perl previamente no seleccion ado. Desempaquetando libcrypt-smbhash-perl (de .../libcrypt-smbhash-perl_0.0 2-6_all.deb) ... Seleccionando el paquete smbldap-tools previamente no seleccionado. Desempaquetando smbldap-tools (de .../smbldap-tools_0.8.5-1_all.deb) .. . Configurando libconvert-asn1-perl (0.18-1) ... Configurando libdigest-md4-perl (1.1-2) ... Configurando libnet-ldap-perl (0.3202-2) ... Configurando libcrypt-smbhash-perl (0.02-6) ... Configurando smbldap-tools (0.8.5-1) ... localepurge: checking system for new locale ... localepurge: processing locale files ... localepurge: processing man pages ... Si desea ver la descripción del paquete que se acaba de instalar, teclee la orden: Ejemplo H-2. Descripción del paquete smbldap-tools # /usr/bin/apt-cache show smbldap-tools Package: smbldap-tools Priority: optional Section: admin Installed-Size: 600 Maintainer: Sergio Talens-Oliag Architecture: all Version: 0.8.5-1 Depends: perl, libnet-ldap-perl, libcrypt-smbhash-perl Filename: pool/main/s/smbldap-tools/smbldap-tools_0.8.5-1_all.deb Size: 291454 MD5sum: 87dd4028958d8ef9f9e4bafdf1b4ae6d Description: Scripts to manage Unix and Samba accounts stored on LDAP Set of scripts to manage data relative to users and groups stored in a n LDAP server. The tools manage POSIX, shadow and Samba (3.0 series) accounts and groups. . This package is used to add/del/mod users and groups in the Linux Samba-OpenLDAP Howto . Con la siguiente orden se observarán las herramientas que provee este paquete: Ejemplo H-3. Herramientas que provee el paquete smbldap-tools $ /usr/bin/dpkg -L smbldap-tools | /bin/grep bin /usr/sbin/smbldap-groupadd /usr/sbin/smbldap-groupdel /usr/sbin/smbldap-groupmod /usr/sbin/smbldap-groupshow /usr/sbin/smbldap-passwd /usr/sbin/smbldap-populate /usr/sbin/smbldap-useradd /usr/sbin/smbldap-userdel /usr/sbin/smbldap-usermod /usr/sbin/smbldap-usershow _________________________________________________________ H.3. Configuración El primer paso para configurar estas herramientas, es copiar los archivos de configuración al directorio /etc/smbldap-tools. En el directorio /usr/share/doc/smbldap-tools/examples/ hay archivos de configuración de ejemplo, y a partir de ellos se realizará la configuración. El siguiente ejemplo muestra como hacerlo. Ejemplo H-4. Copiando los archivos de configuración de smbldap-tools a /etc/smbldap-tools # /bin/cp -v \ /usr/share/doc/smbldap-tools/examples/smbldap_bind.conf /e tc/smbldap-tools/ «/usr/share/doc/smbldap-tools/examples/smbldap_bind.conf» -> \ «/etc/smbldap-tools/smbldap_bind.conf» # /bin/zcat -v /usr/share/doc/smbldap-tools/examples/smbldap.conf.gz > \ /etc/smbldap-tools/smbldap.conf /usr/share/doc/smbldap-tools/examples/smbldap.conf.gz: 62.8% Ahora que ya están los archivos de configuración necesarios, sólo queda adaptarlos al sistema. En las siguientes secciones se verán las opciones más importantes de ambos archivos. Nota En los apéndices: Apéndice AK y Apéndice AL posee un ejemplo de estos archivos ya configurados. _________________________________________________________ H.3.1. /etc/smbldap-tools/smbldap_bind.conf * Usuario administrador del directorio LDAP. masterDN="cn=admin,dc=gsr,dc=pt" * Clave del usuario administrador del servidor LDAP. masterPw="**********" _________________________________________________________ H.3.2. /etc/smbldap-tools/smbldap.conf H.3.2.1. Sección general * SID del servidor (en el siguiente enlace tiene un ejemplo de como obtenerlo: Ejemplo F-7). SID="S-1-5-21-2817058862-34499604-3382793611" _________________________________________________________ H.3.2.2. Sección LDAP * Dirección del servidor LDAP. masterLDAP="gsr.pt" * Puerto por el que conectarse al servidor LDAP. masterPort="389" * Se activa la conexión por TLS. ldapTLS="1" * Se obliga a que el servidor LDAP provea un certificado y además, este certificado ha de ser válido. verify="require" * Archivo del certificado de la CA. cafile="/etc/ldap/ssl/cacert.pem" * Certificado que se utilizará para conectarse con el servidor LDAP. clientcert="/home/certs/ldap.cliente.cert.pem" * Llave del certificado que se utilizará para conectarse con el servidor LDAP. clientkey="/home/certs/ldap.cliente.key.pem" * Base del servidor LDAP. suffix="dc=gsr,dc=pt" * Entidad bajo la cual se almacenarán los usuarios. usersdn="ou=people,${suffix}" * Entidad bajo la cual se almacenarán los equipos. computersdn="ou=machines,${suffix}" * Entidad bajo la cual se almacenarán los grupos. groupsdn="ou=groups,${suffix}" * Algoritmo de hash para cifrar las claves. hash_encrypt="MD5" _________________________________________________________ H.3.2.3. Sección para las cuentas unix * Shell por defecto para los nuevos usuarios. userLoginShell="/bin/bash" * Directorio «home» de los usuarios (la variable %U se sustituirá por el nombre del usuario). userHome="/home/samba/users/%U" * GID por defecto al que pertenecerán los nuevos usuarios (en este caso se ha elegido el grupo domainusers). defaultUserGid="1001" * GID por defecto al que pertenecerán los nuevos equipos (en este caso se ha elegido el grupo domainadmins). defaultComputerGid="1000" * Directorio desde el cual se copiarán los archivos de configuración por defecto de los nuevos usuarios (directorio skel). skeletonDir="/etc/skel" _________________________________________________________ H.3.2.4. Sección Samba * Localización del home de los usuarios a través de Samba (la variable %U sustituye al nombre del usuario). Nota Si se quiere hacer uso de la directiva "logon home" del archivo de configuración de Samba, smb.conf y/o se quiere deshabilitar los perfiles móviles, deje esta variable en blanco. userSmbHome="\\TODOSCSI\%U" * Localización de los perfiles de los usuarios a través de Samba (la variable %U sustituye al nombre del usuario). Nota Si se quiere hacer uso de la directiva "logon home" del archivo de configuración de Samba, smb.conf y/o se quiere deshabilitar los perfiles móviles, deje esta variable en blanco. userProfile="\\TODOSCSI\profiles\%U" * Letra para mapear el directorio home del usuario. userHomeDrive="H:" * Script netlogon por defecto (la variable %U sustituye al nombre del usuario). Nota Si la variable se deja en blanco, se utilizará automáticamente el script bajo el archivo nombreusuario.cmd. userScript="" * Dominio que se añadirá al atributo "mail" de los usuarios, cuando se utiliza la orden smbldap-useradd -M. mailDomain="gsr.pt" _________________________________________________________ Apéndice I. Preparación de Apache para el uso de SSL I.1. Introducción En los ejemplos Ejemplo F-2, Ejemplo F-3, Ejemplo F-4 y Ejemplo F-5 se ha visto el proceso de instalación de Apache junto con el módulo "mod_ssl", entre otros. Este apéndice abordará la creación de los certificados necesarios así como la configuración relativa al servidor web, para permitir conexiones SSL contra el servidor Apache. _________________________________________________________ I.2. Generación de la entidad certificadora y los certificados A continuación se mostrará el proceso que se ha de seguir para la creación de la entidad certificadora y el certificado necesario para que el servidor Apache pueda servir páginas a través de SSL: Ejemplo I-1. Creación del certificado para el servidor Apache # /usr/bin/dpkg-reconfigure libapache-mod-ssl What type of certificate do you want to create? 1. dummy (dummy self-signed Snake Oil cert) 2. test (test cert signed by Snake Oil CA) 3. custom (custom cert signed by own CA) 4. existing (existing cert) Use dummy when you are a vendor package maintainer, test when you are an admin but want to do tests only, custom when you are an admin willing to run a real server existing when you are an admin who upgrades a server. Normally you would choose 2. your choice: 3 Which algorithm should be used to generate required key(s)? 1. RSA 2. DSA Normally you would choose 1. your choice: 1 SSL Certificate Generation Utility (mkcert.sh) Copyright (c) 1998-2000 Ralf S. Engelschall, All Rights Reserved. Generating custom certificate signed by own CA [CUSTOM] ______________________________________________________________________ STEP 1: Generating RSA private key for CA (1024 bit) [ca.key] 2477870 semi-random bytes loaded Generating RSA private key, 1024 bit long modulus .....++++++ ..........................................++++++ e is 65537 (0x10001) ______________________________________________________________________ STEP 2: Generating X.509 certificate signing request for CA [ca.csr] You are about to be asked to enter information that will be incorporate d into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- 1. Country Name (2 letter code) [XY]:PT 2. State or Province Name (full name) [Snake Desert]:Braganca 3. Locality Name (eg, city) [Snake Town]:Braganca 4. Organization Name (eg, company) [Snake Oil, Ltd]:Companhia GSR 5. Organizational Unit Name (eg, section) [Certificate Authority]:Ser vicos web 6. Common Name (eg, CA name) [Snake Oil CA]:gsr.pt 7. Email Address (eg, name@FQDN) [ca@snakeoil.dom]:sergio@gs r.pt 8. Certificate Validity (days) [365]: [Enter] ______________________________________________________________________ STEP 3: Generating X.509 certificate for CA signed by itself [ca.crt] Certificate Version (1 or 3) [3]:3 Signature ok subject=/C=PT/ST=Braganca/L=Braganca/O=Companhia \ GSR/OU=Servicos web/CN=gsr.pt/emailAd dress=sergio@gsr.pt Getting Private key Verify: matching certificate & key modulus Verify: matching certificate signature /etc/apache/ssl.crt/ca.crt: /C=PT/ST=Braganca/L=Braganca/O=Companhia \ GSR/OU=Servicos web/CN=gsr.pt/emailAd dress=sergio@gsr.pt error 18 at 0 depth lookup:self signed certificate OK ______________________________________________________________________ STEP 4: Generating RSA private key for SERVER (1024 bit) [server.key] 2477870 semi-random bytes loaded Generating RSA private key, 1024 bit long modulus ........++++++ ......++++++ e is 65537 (0x10001) ______________________________________________________________________ STEP 5: Generating X.509 certificate signing request for SERVER [server .csr] You are about to be asked to enter information that will be incorporate d into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- 1. Country Name (2 letter code) [XY]:PT 2. State or Province Name (full name) [Snake Desert]:Braganca 3. Locality Name (eg, city) [Snake Town]:Braganca 4. Organization Name (eg, company) [Snake Oil, Ltd]:GSR Web 5. Organizational Unit Name (eg, section) [Webserver Team]:Aplicacoes web 6. Common Name (eg, FQDN) [www.snakeoil.dom]:gsr.pt 7. Email Address (eg, name@fqdn) [www@snakeoil.dom]:sergio@g sr.pt 8. Certificate Validity (days) [365]:[Enter] ______________________________________________________________________ STEP 6: Generating X.509 certificate signed by own CA [server.crt] Certificate Version (1 or 3) [3]:3 Signature ok subject=/C=PT/ST=Braganca/L=Braganca/O=GSR Web/OU=Aplicacoes \ web/CN=gsr.pt/emailAddress=sergi o@gsr.pt Getting CA Private Key Verify: matching certificate & key modulus Verify: matching certificate signature /etc/apache/ssl.crt/server.crt: OK ______________________________________________________________________ STEP 7: Enrypting RSA private key of CA with a pass phrase for security [ca.key] The contents of the ca.key file (the generated private key) has to be kept secret. So we strongly recommend you to encrypt the server.key fil e with a Triple-DES cipher and a Pass Phrase. Encrypt the private key now? [Y/n]: n (1) Warning, you're using an unencrypted private key. Please notice this fact and do this on your own risk. ______________________________________________________________________ STEP 8: Enrypting RSA private key of SERVER with a pass phrase for secu rity [server.key] The contents of the server.key file (the generated private key) has to be kept secret. So we strongly recommend you to encrypt the server.key fil e with a Triple-DES cipher and a Pass Phrase. Encrypt the private key now? [Y/n]: n (2) Warning, you're using an unencrypted RSA private key. Please notice this fact and do this on your own risk. ______________________________________________________________________ RESULT: CA and Server Certification Files o /etc/apache/ssl.key/ca.key The PEM-encoded RSA private key file of the CA which you can use to sign other servers or clients. KEEP THIS FILE PRIVATE! o /etc/apache/ssl.crt/ca.crt The PEM-encoded X.509 certificate file of the CA which you use to sign other servers or clients. When you sign clients with it (for SSL client authentication) you can configure this file with the 'SSLCACertificateFile' directive. o /etc/apache/ssl.key/server.key The PEM-encoded RSA private key file of the server which you configu re with the 'SSLCertificateKeyFile' directive (automatically done when you install via APACI). KEEP THIS FILE PRIVATE! o /etc/apache/ssl.crt/server.crt The PEM-encoded X.509 certificate file of the server which you confi gure with the 'SSLCertificateFile' directive (automatically done when you install via APACI). o /etc/apache/ssl.csr/server.csr The PEM-encoded X.509 certificate signing request of the server file which you can send to an official Certificate Authority (CA) in order to request a real server certificate (signed by this CA instead of our own CA) which later can replace the /etc/apache/ssl.crt/serve r.crt file. Congratulations that you establish your server with real certificates. ./snakeoil-ca-rsa.crt ... e52d41d0.0 ./ca-bundle.crt ... Skipped ./gsr-ca-rsa.crt ... c43c023d.0 ./snakeoil-dsa.crt ... 5d8360e1.0 ./snakeoil-rsa.crt ... 82ab5372.0 ./ca.crt ... 458c23d7.0 ./server.crt ... 6219a630.0 ./snakeoil-ca-dsa.crt ... 0cf14d7d.0 (1) (2) Como se está trabajando sobre un equipo destinado a pruebas, se ha decidido no cifrar las llaves generadas, de esta forma se evitará el teclear la clave empleada en el cifrado cada vez que se reinicie el servidor Apache. ¡Esto es un problema muy grabe de seguridad! si está trabajando sobre un servidor en producción, es más que recomendable hacer uso del cifrado en estos puntos. _________________________________________________________ I.3. Configuración de Apache Para añadir soporte SSL a Apache, no basta únicamente con crear el certificado, también hay que indicar a Apache donde se encuentra dicho certificado. En primer lugar, se copiará un archivo de ejemplo de configuración del módulo mod_ssl, distribuído con el paquete libapache-mod-ssl, y se personalizará. Siga las siguientes indicaciones: Ejemplo I-2. Preparación para la configuración del módulo mod_ssl de Apache # /bin/cp -v /usr/share/doc/libapache-mod-ssl/examples/mod-ssl.conf \ /etc/apache/conf.d/mod_ssl-00-global.conf «/usr/share/doc/libapache-mod-ssl/examples/mod-ssl.conf» -> «/etc/apach e/conf.d/mod_ssl-00-global.conf» # /bin/chmod -v 644 mod_ssl-00-global.conf el modo de «mod_ssl-00-global.conf» cambia a 0644 (rw-r--r--) Ahora edite el archivo /etc/apache/conf.d/mod_ssl-00-global.conf y comente las siguientes líneas: Listen 80 SSLSessionCache none y descomente estas otras: #SSLSessionCache dbm:/var/run/mod_ssl_scache #SSLSessionCacheTimeout 300 #SSLLog /var/log/apache/ssl_engine.log #SSLLogLevel info Nota En el Apéndice AM se encuentra un archivo de configuración completo. _________________________________________________________ I.3.1. Configuración de los virtual host Ahora se creará la configuración personalizada para cada "virtual host". En la actualidad existen dos "virtual host" en el equipo: uno denominado gsr.pt:80 y otro gsr.pt:443. La configuración de los "virtual host" se almacenará en el archivo /etc/apache/conf.d/vhost.conf. Aquí no se tratará el contenido de este archivo, ya que posee un archivo de configuración completo en el Apéndice AN. Esto es suficiente para habilitar el soporte SSL en Apache. Ahora se ha de reiniciar Apache, para ello teclee: Ejemplo I-3. Reinicio del servidor Apache # /etc/init.d/apache restart Restarting apache. _________________________________________________________ Apéndice J. Cambio para el registro de Windows XP (miembro de un dominio Samba) Para poder añadir un cliente Windows XP a un dominio administrado por Samba, es necesario aplicar el siguiente cambio en el registro de Windows: Windows Registry Editor Version 5.00 ; ; This registry key is needed for a Windows XP Client to join ; and logon to a Samba domain. Note: Samba 2.2.3a contained ; this key in a broken format which did nothing to the registry - ; however XP reported "registry key imported". If in doubt ; check the key by hand with regedit. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Paramete rs] "requiresignorseal"=dword:00000000 Nota El cambio a realizar se ha obtenido de los archivos suministrados con el paquete samba-doc, más concretamente el archivo /usr/share/doc/samba-doc/registry/WinXP_SignOrSeal.reg _________________________________________________________ Apéndice K. Script para la creación/eliminación de los homes de los usuarios Cuando se añaden/borran usuarios en la base de datos de LDAP no se crea el directorio destinado a almacenar sus archivos personales (el directorio HOME). La aplicación LDAP Account Manager (ver el Apéndice F para más información) adjunta un script destinado a la creación/eliminación de los directorios home de los usuarios: lamdaemon.pl; pero en esta documentación no se hará uso del mismo. En su lugar se ha creado el siguiente script, que ha de ser ejecutado como usuario root cada vez que se cree un nuevo usuario, sobre todo si este está destinado a hacer uso de Samba (la creación del directorio home cuando se accede a la shell ya está solucionado: vea la Sección 5.3.3.3 para más detalles): Nota El script no está pensado para sistemas en producción, simplemente es un ejemplo utilizado para facilitar la creación de esta documentación. Aviso Tenga mucho cuidado con el uso del siguiente script, ya que añade y borra, ¡sin preguntar!, los homes de los usuarios en relación al estado de la base de datos de usuarios LDAP. Su comportamiento es el siguiete: * Crea el directorio home y copia el contenido del directorio /etc/skel, de aquellos usuarios que no tengan creado su directorio home. * Borra, sin preguntar ni hacer una copia de seguridad, los homes de los usuarios que ya no existan en la base de datos LDAP, pero aun posean un directorio home en el sistem. Nota Este script se ha basado en los scripts creados por J. Vriesman y Jesús Roncero Franco para la elaboración de los siguientes documentos, respectivamente: * http://jeroen.protheus.com/postfix-courier-ldap-howto.html * http://bulma.net/body.phtml?nIdNoticia=2013 #!/bin/sh # # Copyright (C) 2004 Sergio González González # # Depends on: # - ldapsearch # # Based on http://jeroen.protheus.com/postfix-courier-ldap-howto.html # (c) J.Vriesman # # and # # Based on http://bulma.net/body.phtml?nIdNoticia=2013 # (c) Jesús Roncero Franco # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # # # This script manage the home directories of LDAP users (make the new u sers home # directory and delete the non-existent users home directory) # Password to bind to ldap server systempass="********" # Bind dn binddn="cn=admin,dc=gsr,dc=pt" # Acount leave accountleave="ou=people,dc=gsr,dc=pt" # ldap host ldaphost="gsr.pt" # skel directory skel="/etc/skel/" # Home leave (without final slash: '/') homeleave="/home/samba/users" usernames=`ldapsearch -h $ldaphost -x -w $systempass -D "$binddn" \ -b "$accountleave" uid | grep "^[^#]" | grep "^[^ dn]" \ | grep uid | awk '{ print $2 }'` # create personal home directories for username in $usernames do homedirectory=`ldapsearch -h $ldaphost -x -w $systempass -D "$binddn" \ -b "$accountleave" "(uid=$username)" homeDi rectory \ | grep "^[^#]" | grep homeDirectory \ | awk '{ print $2 }'` group=`ldapsearch -h $ldaphost -x -w $systempass -D "$binddn" \ -b "$accountleave" "(uid=$username)" gidNumber \ | grep "^[^#]" | grep gidNumber \ | awk '{ print $2 }'` if [ ! -d $homedirectory ] && [ ! -z $homedirectory ] then cp -a $skel $homedirectory chown -R $username.$group $homedirectory fi done # delete personal home directories for username in `ls $homeleave` do name=`ldapsearch -h $ldaphost -x -w $systempass -D "$binddn" \ -b "$accountleave" "(homeDirectory=$homeleave/$usern ame)" uid \ | grep "^[^#]" | grep "uid:" | awk '{ print $2 }'` if [ -z $name ] then rm -rf $homeleave/$username fi done _________________________________________________________ Apéndice L. Script para convertir a mayúsculas el archivo pasado como argumento El script que se lista a continuación, convierte el archivo pasado como argumento a mayúsculas. Nota Este script se ha adaptado a partir del archivo de ejemplo /usr/share/doc/bash/examples/scripts.v2/lowercase que se distribuye con el paquete bash. #! /bin/bash # # original from # @(#) lowercase.ksh 1.0 92/10/08 # 92/10/08 john h. dubois iii (john@armory.com) # # conversion to bash v2 syntax done by Chet Ramey # # Convert to uppercase by Sergio González González # Usage="Usage: $name file ..." phelp() { echo "$name: change filenames to upper case. $Usage Each file is moved to a name with the same directory component, if any, and with a filename component that is the same as the original but with any lower case letters changed to upper case." } name=${0##*/} while getopts "h" opt; do case "$opt" in h) phelp; exit 0;; *) echo "$Usage" 1>&2; exit 2;; esac done shift $((OPTIND - 1)) for file; do filename=${file##*/} case "$file" in */*) dirname=${file%/*} ;; *) dirname=. ;; esac nf=$(echo $filename | tr a-z A-Z) newname="${dirname}/${nf}" if [ "$nf" != "$filename" ]; then mv "$file" "$newname" echo "$0: $file -> $newname" else echo "$0: $file not changed." fi done _________________________________________________________ Apéndice M. Script para mover los controladores PostScript de Adobe al directorio /usr/share/cups/drivers El script que se lista a continuación, mueve los controladores PostScript de Adobe necesarios al directorio /usr/share/cups/drivers. #!/bin/bash ARCHIVOS="ADFONTS.MFM ADOBEPS4.DRV ADOBEPS4.HLP DEFPRTR2.PPD ICONLIB.DLL PSMON.DLL ADOBEPS5.DLL ADOBEPSU.DLL ADOBEPSU.HLP" for x in $ARCHIVOS do find `pwd` -name "$x" -exec /bin/cp -vf {} /usr/share/cups/driv ers \; done chmod -v 644 /usr/share/cups/drivers/* _________________________________________________________ Apéndice N. Salida de la ejecución de la orden /usr/sbin/cupsaddsmb -v -U root -a Nota Las líneas se han cortado para aumentar la legibilidad $ /usr/sbin/cupsaddsmb -v -U root -a Password for root required to access localhost via SAMBA: [Clave] Running command: smbclient //localhost/print\$ -N -U'root%1' \ -c 'mkdir W32X86;put /var/tmp/40d05d8c7eb4b \ W32X86/InyeccionBN.ppd;put \ /usr/share/cups/drivers/cupsdrv5.dll \ W32X86/cupsdrv5.dll;put \ /usr/share/cups/drivers/cupsui5.dll \ W32X86/cupsui5.dll;put \ /usr/share/cups/drivers/cups5.hlp \ W32X86/cups5.hlp' Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86 putting file /var/tmp/40d05d8c7eb4b as \W32X86/InyeccionBN.ppd \ (1571,5 kb/s) (average 1571,5 kb/s) putting file /usr/share/cups/drivers/cupsdrv5.dll as \W32X86/cupsdrv5.d ll \ (3041,1 kb/s) (average 2963,8 kb/s) putting file /usr/share/cups/drivers/cupsui5.dll as \W32X86/cupsui5.dll \ (2646,8 kb/s) (average 2817,9 kb/s) putting file /usr/share/cups/drivers/cups5.hlp as \W32X86/cups5.hlp \ (3475,0 kb/s) (average 2832,5 kb/s) Running command: rpcclient localhost -N -U'root%1' \ -c 'adddriver "Windows NT x86" \ "InyeccionBN:cupsdrv5.dll:InyeccionBN.ppd:\ cupsui5.dll:cups5.hlp:NULL:RAW:NULL"' Printer Driver InyeccionBN successfully installed. Running command: smbclient //localhost/print\$ -N -U'root%1' \ -c 'mkdir WIN40;put /var/tmp/40d05d8c7eb4b \ WIN40/InyeccionBN.PPD;put \ /usr/share/cups/drivers/ADFONTS.MFM \ WIN40/ADFONTS.MFM;put \ /usr/share/cups/drivers/ADOBEPS4.DRV \ WIN40/ADOBEPS4.DRV;put \ /usr/share/cups/drivers/ADOBEPS4.HLP \ WIN40/ADOBEPS4.HLP;put \ /usr/share/cups/drivers/DEFPRTR2.PPD \ WIN40/DEFPRTR2.PPD;put \ /usr/share/cups/drivers/ICONLIB.DLL \ WIN40/ICONLIB.DLL;put \ /usr/share/cups/drivers/PSMON.DLL \ WIN40/PSMON.DLL;' Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40 putting file /var/tmp/40d05d8c7eb4b as \WIN40/InyeccionBN.PPD \ (1571,5 kb/s) (average 1571,5 kb/s) putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM \ (3722,4 kb/s) (average 3653,5 kb/s) putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DR V \ (4838,3 kb/s) (average 4396,1 kb/s) putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HL P \ (3019,2 kb/s) (average 4161,2 kb/s) putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PP D \ (4389,2 kb/s) (average 4162,5 kb/s) putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL \ (1774,8 kb/s) (average 3891,2 kb/s) putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL \ (1098,0 kb/s) (average 3662,5 kb/s) Running command: rpcclient localhost -N -U'root%1' \ -c 'adddriver "Windows 4.0" \ "InyeccionBN:ADOBEPS4.DRV:InyeccionBN.PPD:NU LL:\ ADOBEPS4.HLP:PSMON.DLL:RAW:ADOBEPS4.DRV,\ InyeccionBN.PPD,ADOBEPS4.HLP,PSMON.DLL, \ ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"' Printer Driver InyeccionBN successfully installed. Running command: rpcclient localhost -N -U'root%1' \ -c 'setdriver InyeccionBN InyeccionBN' Succesfully set InyeccionBN to driver InyeccionBN. Running command: smbclient //localhost/print\$ -N -U'root%1' \ -c 'mkdir W32X86;put /var/tmp/40d05d92939de \ W32X86/InyeccionColor.ppd;put \ /usr/share/cups/drivers/cupsdrv5.dll \ W32X86/cupsdrv5.dll;put \ /usr/share/cups/drivers/cupsui5.dll \ W32X86/cupsui5.dll;put \ /usr/share/cups/drivers/cups5.hlp \ W32X86/cups5.hlp' Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86 putting file /var/tmp/40d05d92939de as \W32X86/InyeccionColor.ppd \ (982,2 kb/s) (average 982,2 kb/s) putting file /usr/share/cups/drivers/cupsdrv5.dll as \W32X86/cupsdrv5.d ll \ (3146,0 kb/s) (average 2963,8 kb/s) putting file /usr/share/cups/drivers/cupsui5.dll as \W32X86/cupsui5.dll \ (2713,9 kb/s) (average 2850,3 kb/s) putting file /usr/share/cups/drivers/cups5.hlp as \W32X86/cups5.hlp \ (2316,7 kb/s) (average 2832,5 kb/s) Running command: rpcclient localhost -N -U'root%1' \ -c 'adddriver "Windows NT x86" \ "InyeccionColor:cupsdrv5.dll:\ InyeccionColor.ppd:cupsui5.dll:\ cups5.hlp:NULL:RAW:NULL"' Printer Driver InyeccionColor successfully installed. Running command: smbclient //localhost/print\$ -N -U'root%1' \ -c 'mkdir WIN40;put /var/tmp/40d05d92939de \ WIN40/InyeccionColor.PPD;put \ /usr/share/cups/drivers/ADFONTS.MFM \ WIN40/ADFONTS.MFM;put \ /usr/share/cups/drivers/ADOBEPS4.DRV \ WIN40/ADOBEPS4.DRV;put \ /usr/share/cups/drivers/ADOBEPS4.HLP \ WIN40/ADOBEPS4.HLP;put \ /usr/share/cups/drivers/DEFPRTR2.PPD \ WIN40/DEFPRTR2.PPD;put \ /usr/share/cups/drivers/ICONLIB.DLL \ WIN40/ICONLIB.DLL;put \ /usr/share/cups/drivers/PSMON.DLL \ WIN40/PSMON.DLL;' Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40 putting file /var/tmp/40d05d92939de as \WIN40/InyeccionColor.PPD \ (1964,3 kb/s) (average 1964,4 kb/s) putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM \ (4043,8 kb/s) (average 3985,6 kb/s) putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DR V \ (4432,3 kb/s) (average 4283,4 kb/s) putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HL P \ (2917,5 kb/s) (average 4048,7 kb/s) putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PP D \ (2633,5 kb/s) (average 4035,2 kb/s) putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL \ (1831,1 kb/s) (average 3798,2 kb/s) putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL \ (5090,9 kb/s) (average 3822,0 kb/s) Running command: rpcclient localhost -N -U'root%1' \ -c 'adddriver "Windows 4.0" \ "InyeccionColor:ADOBEPS4.DRV:InyeccionColor. PPD:\ NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:ADOBEPS4.DR V,\ InyeccionColor.PPD,ADOBEPS4.HLP,PSMON.DLL,\ ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"' Printer Driver InyeccionColor successfully installed. Running command: rpcclient localhost -N -U'root%1' \ -c 'setdriver InyeccionColor InyeccionColor' Succesfully set InyeccionColor to driver InyeccionColor. Running command: smbclient //localhost/print\$ -N -U'root%1' \ -c 'mkdir W32X86;put /var/tmp/40d05d96c0f3a \ W32X86/LaserBN.ppd;put \ /usr/share/cups/drivers/cupsdrv5.dll \ W32X86/cupsdrv5.dll;put \ /usr/share/cups/drivers/cupsui5.dll \ W32X86/cupsui5.dll;put \ /usr/share/cups/drivers/cups5.hlp \ W32X86/cups5.hlp' Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86 putting file /var/tmp/40d05d96c0f3a as \W32X86/LaserBN.ppd \ (1571,5 kb/s) (average 1571,5 kb/s) putting file /usr/share/cups/drivers/cupsdrv5.dll as \W32X86/cupsdrv5.d ll \ (2975,0 kb/s) (average 2902,6 kb/s) putting file /usr/share/cups/drivers/cupsui5.dll as \W32X86/cupsui5.dll \ (2614,6 kb/s) (average 2770,7 kb/s) putting file /usr/share/cups/drivers/cups5.hlp as \W32X86/cups5.hlp \ (3475,0 kb/s) (average 2786,1 kb/s) Running command: rpcclient localhost -N -U'root%1' \ -c 'adddriver "Windows NT x86" \ "LaserBN:cupsdrv5.dll:LaserBN.ppd:\ cupsui5.dll:cups5.hlp:NULL:RAW:NULL"' Printer Driver LaserBN successfully installed. Running command: smbclient //localhost/print\$ -N -U'root%1' \ -c 'mkdir WIN40;put /var/tmp/40d05d96c0f3a \ WIN40/LaserBN.PPD;put \ /usr/share/cups/drivers/ADFONTS.MFM \ WIN40/ADFONTS.MFM;put \ /usr/share/cups/drivers/ADOBEPS4.DRV \ WIN40/ADOBEPS4.DRV;put \ /usr/share/cups/drivers/ADOBEPS4.HLP \ WIN40/ADOBEPS4.HLP;put \ /usr/share/cups/drivers/DEFPRTR2.PPD \ WIN40/DEFPRTR2.PPD;put \ /usr/share/cups/drivers/ICONLIB.DLL \ WIN40/ICONLIB.DLL;put \ /usr/share/cups/drivers/PSMON.DLL \ WIN40/PSMON.DLL;' Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40 putting file /var/tmp/40d05d96c0f3a as \WIN40/LaserBN.PPD \ (1964,3 kb/s) (average 1964,4 kb/s) putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM \ (4043,8 kb/s) (average 3985,6 kb/s) putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DR V \ (4282,5 kb/s) (average 4185,8 kb/s) putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HL P \ (2596,6 kb/s) (average 3890,9 kb/s) putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PP D \ (2633,5 kb/s) (average 3879,4 kb/s) putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL \ (1774,8 kb/s) (average 3654,8 kb/s) putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL \ (1076,9 kb/s) (average 3452,0 kb/s) Running command: rpcclient localhost -N -U'root%1' \ -c 'adddriver "Windows 4.0" \ "LaserBN:ADOBEPS4.DRV:LaserBN.PPD:NULL:\ ADOBEPS4.HLP:PSMON.DLL:RAW:ADOBEPS4.DRV,\ LaserBN.PPD,ADOBEPS4.HLP,PSMON.DLL,\ ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"' Printer Driver LaserBN successfully installed. Running command: rpcclient localhost -N -U'root%1' \ -c 'setdriver LaserBN LaserBN' Succesfully set LaserBN to driver LaserBN. Running command: smbclient //localhost/print\$ -N -U'root%1' \ -c 'mkdir W32X86;put /var/tmp/40d05d9b3e1a0 \ W32X86/LaserColor.ppd;put \ /usr/share/cups/drivers/cupsdrv5.dll \ W32X86/cupsdrv5.dll;put \ /usr/share/cups/drivers/cupsui5.dll \ W32X86/cupsui5.dll;put \ /usr/share/cups/drivers/cups5.hlp \ W32X86/cups5.hlp' Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86 putting file /var/tmp/40d05d9b3e1a0 as \W32X86/LaserColor.ppd \ (1309,5 kb/s) (average 1309,6 kb/s) putting file /usr/share/cups/drivers/cupsdrv5.dll as \W32X86/cupsdrv5.d ll \ (2709,9 kb/s) (average 2631,4 kb/s) putting file /usr/share/cups/drivers/cupsui5.dll as \W32X86/cupsui5.dll \ (2614,6 kb/s) (average 2624,1 kb/s) putting file /usr/share/cups/drivers/cups5.hlp as \W32X86/cups5.hlp \ (3475,0 kb/s) (average 2641,7 kb/s) Running command: rpcclient localhost -N -U'root%1' \ -c 'adddriver "Windows NT x86" \ "LaserColor:cupsdrv5.dll:LaserColor.ppd:\ cupsui5.dll:cups5.hlp:NULL:RAW:NULL"' Printer Driver LaserColor successfully installed. Running command: smbclient //localhost/print\$ -N -U'root%1' \ -c 'mkdir WIN40;put /var/tmp/40d05d9b3e1a0 \ WIN40/LaserColor.PPD;put \ /usr/share/cups/drivers/ADFONTS.MFM \ WIN40/ADFONTS.MFM;put \ /usr/share/cups/drivers/ADOBEPS4.DRV \ WIN40/ADOBEPS4.DRV;put \ /usr/share/cups/drivers/ADOBEPS4.HLP \ WIN40/ADOBEPS4.HLP;put \ /usr/share/cups/drivers/DEFPRTR2.PPD \ WIN40/DEFPRTR2.PPD;put \ /usr/share/cups/drivers/ICONLIB.DLL \ WIN40/ICONLIB.DLL;put \ /usr/share/cups/drivers/PSMON.DLL \ WIN40/PSMON.DLL;' Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40 putting file /var/tmp/40d05d9b3e1a0 as \WIN40/LaserColor.PPD \ (1964,3 kb/s) (average 1964,4 kb/s) putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM \ (4043,8 kb/s) (average 3985,6 kb/s) putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DR V \ (4694,9 kb/s) (average 4449,3 kb/s) putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HL P \ (2950,6 kb/s) (average 4186,1 kb/s) putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PP D \ (3291,9 kb/s) (average 4179,0 kb/s) putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL \ (1860,6 kb/s) (average 3925,5 kb/s) putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL \ (5090,9 kb/s) (average 3947,7 kb/s) Running command: rpcclient localhost -N -U'root%1' \ -c 'adddriver "Windows 4.0" \ "LaserColor:ADOBEPS4.DRV:LaserColor.PPD:\ NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:\ ADOBEPS4.DRV,LaserColor.PPD,ADOBEPS4.HLP,\ PSMON.DLL,ADFONTS.MFM,DEFPRTR2.PPD,\ ICONLIB.DLL"' Printer Driver LaserColor successfully installed. Running command: rpcclient localhost -N -U'root%1' \ -c 'setdriver LaserColor LaserColor' Succesfully set LaserColor to driver LaserColor. Running command: smbclient //localhost/print\$ -N -U'root%1' \ -c 'mkdir W32X86;put /var/tmp/40d05d9f9895e \ W32X86/Multifuncion.ppd;put \ /usr/share/cups/drivers/cupsdrv5.dll \ W32X86/cupsdrv5.dll;put \ /usr/share/cups/drivers/cupsui5.dll \ W32X86/cupsui5.dll;put \ /usr/share/cups/drivers/cups5.hlp \ W32X86/cups5.hlp' Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86 putting file /var/tmp/40d05d9f9895e as \W32X86/Multifuncion.ppd \ (982,2 kb/s) (average 982,2 kb/s) putting file /usr/share/cups/drivers/cupsdrv5.dll as \W32X86/cupsdrv5.d ll \ (3041,1 kb/s) (average 2873,0 kb/s) putting file /usr/share/cups/drivers/cupsui5.dll as \W32X86/cupsui5.dll \ (2821,0 kb/s) (average 2850,3 kb/s) putting file /usr/share/cups/drivers/cups5.hlp as \W32X86/cups5.hlp \ (3475,0 kb/s) (average 2864,3 kb/s) Running command: rpcclient localhost -N -U'root%1' \ -c 'adddriver "Windows NT x86" \ "Multifuncion:cupsdrv5.dll:\ Multifuncion.ppd:cupsui5.dll:\ cups5.hlp:NULL:RAW:NULL"' Printer Driver Multifuncion successfully installed. Running command: smbclient //localhost/print\$ -N -U'root%1' \ -c 'mkdir WIN40;put /var/tmp/40d05d9f9895e \ WIN40/Multifuncion.PPD;put \ /usr/share/cups/drivers/ADFONTS.MFM \ WIN40/ADFONTS.MFM;put \ /usr/share/cups/drivers/ADOBEPS4.DRV \ WIN40/ADOBEPS4.DRV;put \ /usr/share/cups/drivers/ADOBEPS4.HLP \ WIN40/ADOBEPS4.HLP;put \ /usr/share/cups/drivers/DEFPRTR2.PPD \ WIN40/DEFPRTR2.PPD;put \ /usr/share/cups/drivers/ICONLIB.DLL \ WIN40/ICONLIB.DLL;put \ /usr/share/cups/drivers/PSMON.DLL \ WIN40/PSMON.DLL;' Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40 putting file /var/tmp/40d05d9f9895e as \WIN40/Multifuncion.PPD \ (1964,3 kb/s) (average 1964,4 kb/s) putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM \ (3747,2 kb/s) (average 3700,9 kb/s) putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DR V \ (4932,4 kb/s) (average 4471,0 kb/s) putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HL P \ (2950,6 kb/s) (average 4202,8 kb/s) putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PP D \ (2633,5 kb/s) (average 4187,3 kb/s) putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL \ (1538,1 kb/s) (average 3844,1 kb/s) putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL \ (1037,0 kb/s) (average 3604,7 kb/s) Running command: rpcclient localhost -N -U'root%1' \ -c 'adddriver "Windows 4.0" \ "Multifuncion:ADOBEPS4.DRV:Multifuncion.PPD: \ NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:\ ADOBEPS4.DRV,Multifuncion.PPD,ADOBEPS4.HLP, \ PSMON.DLL,ADFONTS.MFM,DEFPRTR2.PPD,\ ICONLIB.DLL"' Printer Driver Multifuncion successfully installed. Running command: rpcclient localhost -N -U'root%1' \ -c 'setdriver Multifuncion Multifuncion' Succesfully set Multifuncion to driver Multifuncion. Running command: smbclient //localhost/print\$ -N -U'root%1' \ -c 'mkdir W32X86;put /var/tmp/40d05da3c1a90 \ W32X86/Plotter.ppd;put \ /usr/share/cups/drivers/cupsdrv5.dll \ W32X86/cupsdrv5.dll;put \ /usr/share/cups/drivers/cupsui5.dll \ W32X86/cupsui5.dll;put \ /usr/share/cups/drivers/cups5.hlp \ W32X86/cups5.hlp' Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86 putting file /var/tmp/40d05da3c1a90 as \W32X86/Plotter.ppd \ (1964,3 kb/s) (average 1964,4 kb/s) putting file /usr/share/cups/drivers/cupsdrv5.dll as \W32X86/cupsdrv5.d ll \ (2943,0 kb/s) (average 2902,6 kb/s) putting file /usr/share/cups/drivers/cupsui5.dll as \W32X86/cupsui5.dll \ (3633,8 kb/s) (average 3179,2 kb/s) putting file /usr/share/cups/drivers/cups5.hlp as \W32X86/cups5.hlp \ (2780,0 kb/s) (average 3166,8 kb/s) Running command: rpcclient localhost -N -U'root%1' \ -c 'adddriver "Windows NT x86" \ "Plotter:cupsdrv5.dll:Plotter.ppd:\ cupsui5.dll:cups5.hlp:NULL:RAW:NULL"' Printer Driver Plotter successfully installed. Running command: smbclient //localhost/print\$ -N -U'root%1' \ -c 'mkdir WIN40;put /var/tmp/40d05da3c1a90 \ WIN40/Plotter.PPD;put \ /usr/share/cups/drivers/ADFONTS.MFM \ WIN40/ADFONTS.MFM;put \ /usr/share/cups/drivers/ADOBEPS4.DRV \ WIN40/ADOBEPS4.DRV;put \ /usr/share/cups/drivers/ADOBEPS4.HLP \ WIN40/ADOBEPS4.HLP;put \ /usr/share/cups/drivers/DEFPRTR2.PPD \ WIN40/DEFPRTR2.PPD;put \ /usr/share/cups/drivers/ICONLIB.DLL \ WIN40/ICONLIB.DLL;put \ /usr/share/cups/drivers/PSMON.DLL \ WIN40/PSMON.DLL;' Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40 putting file /var/tmp/40d05da3c1a90 as \WIN40/Plotter.PPD \ (1571,5 kb/s) (average 1571,5 kb/s) putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM \ (3557,5 kb/s) (average 3496,6 kb/s) putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DR V \ (4712,4 kb/s) (average 4253,6 kb/s) putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HL P \ (3054,8 kb/s) (average 4056,5 kb/s) putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PP D \ (2194,6 kb/s) (average 4035,2 kb/s) putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL \ (1860,6 kb/s) (average 3804,7 kb/s) putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL \ (848,5 kb/s) (average 3505,0 kb/s) Running command: rpcclient localhost -N -U'root%1' \ -c 'adddriver "Windows 4.0" \ "Plotter:ADOBEPS4.DRV:Plotter.PPD:NULL:\ ADOBEPS4.HLP:PSMON.DLL:RAW:ADOBEPS4.DRV,\ Plotter.PPD,ADOBEPS4.HLP,PSMON.DLL,\ ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"' Printer Driver Plotter successfully installed. Running command: rpcclient localhost -N -U'root%1' \ -c 'setdriver Plotter Plotter' Succesfully set Plotter to driver Plotter. Running command: smbclient //localhost/print\$ -N -U'root%1' \ -c 'mkdir W32X86;put /var/tmp/40d05da9be1dc \ W32X86/Sublimacion.ppd;put \ /usr/share/cups/drivers/cupsdrv5.dll \ W32X86/cupsdrv5.dll;put \ /usr/share/cups/drivers/cupsui5.dll \ W32X86/cupsui5.dll;put \ /usr/share/cups/drivers/cups5.hlp \ W32X86/cups5.hlp' Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86 putting file /var/tmp/40d05da9be1dc as \W32X86/Sublimacion.ppd \ (1122,5 kb/s) (average 1122,5 kb/s) putting file /usr/share/cups/drivers/cupsdrv5.dll as \W32X86/cupsdrv5.d ll \ (4414,5 kb/s) (average 4080,5 kb/s) putting file /usr/share/cups/drivers/cupsui5.dll as \W32X86/cupsui5.dll \ (5229,1 kb/s) (average 4508,6 kb/s) putting file /usr/share/cups/drivers/cups5.hlp as \W32X86/cups5.hlp \ (3475,0 kb/s) (average 4472,4 kb/s) Running command: rpcclient localhost -N -U'root%1' \ -c 'adddriver "Windows NT x86" \ "Sublimacion:cupsdrv5.dll:Sublimacion.ppd:\ cupsui5.dll:cups5.hlp:NULL:RAW:NULL"' Printer Driver Sublimacion successfully installed. Running command: smbclient //localhost/print\$ -N -U'root%1' \ -c 'mkdir WIN40;put /var/tmp/40d05da9be1dc \ WIN40/Sublimacion.PPD;put \ /usr/share/cups/drivers/ADFONTS.MFM \ WIN40/ADFONTS.MFM;put \ /usr/share/cups/drivers/ADOBEPS4.DRV \ WIN40/ADOBEPS4.DRV;put \ /usr/share/cups/drivers/ADOBEPS4.HLP \ WIN40/ADOBEPS4.HLP;put \ /usr/share/cups/drivers/DEFPRTR2.PPD \ WIN40/DEFPRTR2.PPD;put \ /usr/share/cups/drivers/ICONLIB.DLL \ WIN40/ICONLIB.DLL;put \ /usr/share/cups/drivers/PSMON.DLL \ WIN40/PSMON.DLL;' Domain=[GSRDOMAIN] OS=[Unix] Server=[Samba 3.0.7-Debian] NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40 putting file /var/tmp/40d05da9be1dc as \WIN40/Sublimacion.PPD \ (1571,5 kb/s) (average 1571,5 kb/s) putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM \ (5620,8 kb/s) (average 5428,0 kb/s) putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DR V \ (5174,0 kb/s) (average 5250,2 kb/s) putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HL P \ (2297,8 kb/s) (average 4529,6 kb/s) putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PP D \ (731,5 kb/s) (average 4387,5 kb/s) putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL \ (5015,6 kb/s) (average 4416,2 kb/s) putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL \ (3294,1 kb/s) (average 4379,6 kb/s) Running command: rpcclient localhost -N -U'root%1' \ -c 'adddriver "Windows 4.0" \ "Sublimacion:ADOBEPS4.DRV:Sublimacion.PPD:\ NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:ADOBEPS4.DR V,\ Sublimacion.PPD,ADOBEPS4.HLP,PSMON.DLL,\ ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"' Printer Driver Sublimacion successfully installed. Running command: rpcclient localhost -N -U'root%1' \ -c 'setdriver Sublimacion Sublimacion' Succesfully set Sublimacion to driver Sublimacion. _________________________________________________________ Apéndice O. Ejemplo de certificado para un servidor -----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQDHrnH1k+2Iae/5jC0mia+LiJTLJj9KVI7t0/vj5Nu7cLTsQJEi 71bGHq23TQDuwCwaAK12aIbaXUk1m1C/pl3BCTm1h5mlHMZXZrMyikNeh+3Fq33a xSAn71pbm5iRp9EJjoDXggWIJwZrGoCG4wXDZAT9iXtEI5y/jP4xV7s8HwIDAQAB AoGBAIaPo/QeD8ARw8mjEPobZtTc4YhU6empOfhDFkfo/bo+pW1fxW6JYyx3mBEi LzK1BgMv2bUlk1qr6p3ZYH0GG768ZBr3Vola0W1H9pNx2/Cm/7wt3Dkv5cjG5STk qYHIsfTyvyGdE0Gr5OLl84ayHh6Bv7AU2FGC/1ybABNYiUqBAkEA89uJpTXzNC/7 RKARHqmPjwTAVoJAbIwefNT5KyOysCYe0oa3U0pW/Q5aWEgkTJ1KOD6/oPKZHCbW xgu6BbSNTwJBANGfytpVx3bF2Emnkp0Dr4+edVvj16xPWuuK25PHTqqTHkX7Qn9A kSMRXmSmQuHf8uBt6iIUd8Sn4MmQMF3k0DECQHokims//JM1PUwASNLs50Uhgh1S nGZCQLsSCcP723KzhVi5tXV4lN2npMT3TYc6eYR2mZFKMjqRkZ4dHY3iA60CQQCN i8WxCm0GkW+LxKBmb5+zbb83TjFKw8bT985vCgzfdzng7VmojZOzRz4i3nWZCdx5 mR6Y5pM88lMCJ9/Q9vlxAkApzw9xI0gjLp0TD7fqocbrcDf8RNatRZlN2J9ciVBn jWos3xjqtpSjXISCjUUh3k6vLGAxBvXFdN6nM8fQFnM7 -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIDZTCCAs6gAwIBAgIBADANBgkqhkiG9w0BAQQFADCBhDELMAkGA1UEBhMCUFQx ETAPBgNVBAgUCEJyYWdhbudhMREwDwYDVQQHFAhCcmFnYW7nYTEPMA0GA1UEChMG Z3NyLnB0MQ8wDQYDVQQLEwZnc3IucHQxDzANBgNVBAMTBmdzci5wdDEcMBoGCSqG SIb3DQEJARYNc2VyZ2lvQGdzci5wdDAeFw0wNDAzMDkyMTI5MTVaFw0wNTAzMDky MTI5MTVaMIGEMQswCQYDVQQGEwJQVDERMA8GA1UECBQIQnJhZ2Fu52ExETAPBgNV BAcUCEJyYWdhbudhMQ8wDQYDVQQKEwZnc3IucHQxDzANBgNVBAsTBmdzci5wdDEP MA0GA1UEAxMGZ3NyLnB0MRwwGgYJKoZIhvcNAQkBFg1zZXJnaW9AZ3NyLnB0MIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHrnH1k+2Iae/5jC0mia+LiJTLJj9K VI7t0/vj5Nu7cLTsQJEi71bGHq23TQDuwCwaAK12aIbaXUk1m1C/pl3BCTm1h5ml HMZXZrMyikNeh+3Fq33axSAn71pbm5iRp9EJjoDXggWIJwZrGoCG4wXDZAT9iXtE I5y/jP4xV7s8HwIDAQABo4HkMIHhMB0GA1UdDgQWBBRvONFfdt9EbYzVcOgfHeaa jBToHDCBsQYDVR0jBIGpMIGmgBRvONFfdt9EbYzVcOgfHeaajBToHKGBiqSBhzCB hDELMAkGA1UEBhMCUFQxETAPBgNVBAgUCEJyYWdhbudhMREwDwYDVQQHFAhCcmFn YW7nYTEPMA0GA1UEChMGZ3NyLnB0MQ8wDQYDVQQLEwZnc3IucHQxDzANBgNVBAMT Bmdzci5wdDEcMBoGCSqGSIb3DQEJARYNc2VyZ2lvQGdzci5wdIIBADAMBgNVHRME BTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAIhp8yRnTK8IYnMyPyvvjEId3sv/D6M9 RgkG7T1M7MovJn9EHwn3c2rcexrZeCP8viomGGuyuN7/nr9rmTZ1fi/z0tjpXCdt D7UMsEKA8lzzWldrm2sv9xUQfuwZivU9SFXQ8Q+PLAFRquTnRiE+SvOAKYumaa8I UM7tOAK2EvQv -----END CERTIFICATE----- VI. Archivos de configuración Tabla de contenidos P. Opciones de compilación de OpenLDAP en Debian GNU/Linux Q. Archivo de configuración /etc/ldap/slapd.conf R. Archivo de configuración /etc/ldap/ldap.conf S. Archivo de configuración /etc/default/slapd T. Archivo de configuración /etc/nsswitch.conf U. Archivo de configuración /etc/pam_ldap.conf V. Archivo de configuración /etc/libnss-ldap.conf W. Archivo de configuración /etc/pamd.d/common-account X. Archivo de configuración /etc/pamd.d/common-auth Y. Archivo de configuración /etc/pamd.d/common-password Z. Archivo de configuración /etc/pamd.d/common-session AA. Archivo de configuración /etc/nscd.conf AB. Archivo de configuración /etc/default/samba AC. Archivo de configuración /etc/samba/smb.conf - por defecto - AD. Archivo de configuración /etc/samba/smb.conf - Completo - AE. Archivo de configuración /etc/cups/client.conf AF. Archivo de configuración /etc/cups/cupsd.conf AG. Archivo de configuración /etc/pykota/pykota.conf AH. Archivo de configuración /etc/pykota/pykotadmin.conf AI. Archivo de configuración /var/www/phpldapadmin/config.php AJ. Archivo de configuración /var/www/phpldapadmin/templates/template_config.php AK. Archivo de configuración /etc/smbldap-tools/smbldap.conf AL. Archivo de configuración /etc/smbldap-tools/smbldap_bind.conf AM. Archivo de configuración /etc/apache/conf.d/mod_ssl-00-global.conf AN. Archivo de configuración /etc/apache/conf.d/vhost.conf AO. Archivo de configuración /etc/hosts.allow AP. Archivo de configuración /etc/hosts.deny _________________________________________________________ Apéndice P. Opciones de compilación de OpenLDAP en Debian GNU/Linux # Copyright 1998-2003 The OpenLDAP Foundation, All Rights Reserved. # Restrictions apply, see COPYRIGHT and LICENSE files. # Usage: configure [options] [host] # Options: [defaults in brackets after descriptions] # Configuration: # --cache-file=FILE cache test results in FILE # --help print this message # --no-create do not create output files # --quiet, --silent do not print `checking...' messages # --version print the version of autoconf that created configure # Directory and file names: # --prefix=PREFIX install architecture-independent files in P REFIX # [/usr/local] --prefix=/usr # --exec-prefix=EPREFIX install architecture-dependent files in EPR EFIX # [same as prefix] # --bindir=DIR user executables in DIR [EPREFIX/bin] # --sbindir=DIR system admin executables in DIR [EPREFIX/sb in] # --libexecdir=DIR program executables in DIR [EPREFIX/libexec ] --libexecdir='${prefix}/lib' # --datadir=DIR read-only architecture-independent data in DIR # [PREFIX/share] # --sysconfdir=DIR read-only single-machine data in DIR [PREFI X/etc] --sysconfdir=/etc # --sharedstatedir=DIR modifiable architecture-independent data in DIR # [PREFIX/com] # --localstatedir=DIR modifiable single-machine data in DIR [PREF IX/var] --localstatedir=/var/run # --libdir=DIR object code libraries in DIR [EPREFIX/lib] # --includedir=DIR C header files in DIR [PREFIX/include] # --oldincludedir=DIR C header files for non-gcc in DIR [/usr/inc lude] # --infodir=DIR info documentation in DIR [PREFIX/info] # --mandir=DIR man documentation in DIR [PREFIX/man] --mandir='${prefix}/share/man' # --srcdir=DIR find the sources in DIR [configure dir or . .] # --program-prefix=PREFIX prepend PREFIX to installed program names # --program-suffix=SUFFIX append SUFFIX to installed program names # --program-transform-name=PROGRAM # run sed PROGRAM on installed program names # Host type: # --build=BUILD configure for building on BUILD [BUILD=HOST ] # --host=HOST configure for HOST [guessed] # --target=TARGET configure for TARGET [TARGET=HOST] # Features and packages: # --disable-FEATURE do not include FEATURE (same as --enable-FE ATURE=no) # --enable-FEATURE[=ARG] include FEATURE [ARG=yes] # --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] # --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE= no) # --x-includes=DIR X include files are in DIR # --x-libraries=DIR X library files are in DIR # --enable and --with options recognized: # --with-subdir=DIR change default subdirectory used for instal ls --with-subdir=ldap # --enable-debug enable debugging [yes] ## Our users might want to use the -d option --enable-debug # --enable-syslog enable syslog support [auto] --enable-syslog # --enable-proctitle enable proctitle support [yes] --enable-proctitle # --enable-cache enable caching (experimental) [no] #--enable-cache # --enable-referrals enable LDAPv2+ Referrals (experimental) [no] ## Better support this standard ldap feature --enable-referrals # --enable-ipv6 enable IPv6 support [auto] ## Debian tries to fully support IPv6 so we need this --enable-ipv6 # --enable-local enable AF_LOCAL (AF_UNIX) socket support [aut o] --enable-local # --enable-x-compile enable cross compiling [no] # --with-cyrus-sasl with Cyrus SASL support [auto] --with-cyrus-sasl # --with-fetch with freeBSD fetch URL support [auto] # --with-kerberos with Kerberos support [auto] # --with-readline with readline support [auto] --with-readline # --with-threads with threads [auto] --with-threads # --with-tls with TLS/SSL support [auto] --with-tls # --with-yielding-select with implicitly yielding select [auto] # # SLAPD (Standalone LDAP Daemon) Options: # --enable-slapd enable building slapd [yes] --enable-slapd # --enable-aci enable per-object ACIs (experimental) [no] #--enable-aci # --enable-cleartext enable cleartext passwords [yes] --enable-cleartext # --enable-crypt enable crypt(3) passwords [no] --enable-crypt # --enable-dynamic enable linking built binaries with dynamic li bs [no] --enable-dynamic # --enable-kpasswd enable Kerberos password verification [no] # --enable-lmpasswd enable LAN Manager passwords [no] # --enable-spasswd enable (Cyrus) SASL password verification [no ] --enable-spasswd # --enable-modules enable dynamic module support [no] --enable-modules # --enable-phonetic enable phonetic/soundex [no] --enable-phonetic # --enable-rewrite enable DN rewriting in back-ldap and back-met a [no] --enable-rewrite # --enable-rlookups enable reverse lookups of client hostnames [n o] --enable-rlookups # --enable-slp enable SLPv2 support [no] --enable-slp # --enable-wrappers enable tcp wrapper support [no] --enable-wrappers # --enable-bdb enable Berkeley DB backend [yes] --enable-bdb # --with-bdb-module module type static|dynamic [static] --with-bdb-module=dynamic # --enable-dnssrv enable dnssrv backend [no] --enable-dnssrv # --with-dnssrv-module module type static|dynamic [static] --with-dnssrv-module=dynamic # --enable-ldap enable ldap backend [no] --enable-ldap # --with-ldap-module module type static|dynamic [static] --with-ldap-module=dynamic # --enable-ldbm enable ldbm backend [no] --enable-ldbm # --with-ldbm-api with LDBM API auto|berkeley|bcompat|mdbm|gd bm [auto] --with-ldbm-api=berkeley # --with-ldbm-module module type static|dynamic [static] --with-ldbm-module=dynamic # --with-ldbm-type use LDBM type auto|btree|hash [auto] # --enable-meta enable metadirectory backend [no] --enable-meta # --with-meta-module module type static|dynamic [static] --with-meta-module=dynamic # --enable-monitor enable monitor backend [no] --enable-monitor # --with-monitor-module module type static|dynamic [static] --with-monitor-module=dynamic # --enable-null enable null backend [no] --enable-null # --with-null-module module type static|dynamic [static] --with-null-module=dynamic # --enable-passwd enable passwd backend [no] --enable-passwd # --with-passwd-module module type static|dynamic [static] --with-passwd-module=dynamic # --enable-perl enable perl backend [no] ## This does not currently build with Perl 5.8 - disable it --disable-perl # --with-perl-module module type static|dynamic [static] # --enable-shell enable shell backend [no] --enable-shell # --with-shell-module module type static|dynamic [static] --with-shell-module=dynamic # --enable-sql enable sql backend [no] --enable-sql # --with-sql-module module type static|dynamic [static] --with-sql-module=dynamic # # SLURPD (Replication Daemon) Options: # --enable-slurpd enable building slurpd [auto] --enable-slurpd # # Library Generation & Linking Options # --enable-static[=PKGS] build static libraries [default=yes] # --enable-shared[=PKGS] build shared libraries [default=yes] --enable-shared # --enable-fast-install[=PKGS] optimize for fast installation [defau lt=yes] # --with-gnu-ld assume the C compiler uses GNU ld [default= no] # --disable-libtool-lock avoid locking (might break parallel builds) # --with-pic try to use only PIC/non-PIC objects [defaul t=use both] # # See INSTALL file for further details. _________________________________________________________ Apéndice Q. Archivo de configuración /etc/ldap/slapd.conf # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ####################################################################### # Global Directives: # Features to permit #allow bind_v2 # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/samba.schema include /etc/ldap/schema/pykota.schema # Schema check allows for forcing entries to # match schemas for their objectClasses's schemacheck on # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd.args # Read slapd.conf(5) for possible values loglevel -1 # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_ldbm ####################################################################### # Specific Backend Directives for ldbm: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend ldbm ####################################################################### # Specific Backend Directives for 'other': # Backend specific directives apply to this backend until another # 'backend' directive occurs #backend ####################################################################### # Specific Directives for database #1, of type ldbm: # Database specific directives apply to this databasse until another # 'database' directive occurs database ldbm # The base of your directory in database #1 suffix "dc=gsr,dc=pt" # Where the database file are physically stored for database #1 directory "/var/lib/ldap" # Indexing options for database #1 # # Requerido por OpenLDAP index objectclass eq index default sub index cn pres,sub,eq index sn pres,sub,eq index mail eq,subinitial index givenname eq,subinitial # Requerido para soportar pdb_getsampwnam index uid pres,sub,eq # Requerido para soportar pdb_getsambapwrid() index displayName pres,sub,eq # Descomente las siguientes líneas si está almacenando entradas # posixAccount y posixGroup en el directorio index uidNumber eq index gidNumber eq index memberUid eq # Samba 3.* index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq # PyKota index pykotaUserName pres,eq,sub index pykotaGroupName pres,eq,sub index pykotaPrinterName pres,eq,sub index pykotaLastJobIdent eq # Save the time that the entry gets modified, for database #1 lastmod on # Where to store the replica logs for database #1 # replogfile /var/lib/ldap/replog # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only access to attribute=userPassword by dn="cn=admin,dc=gsr,dc=pt" write by dn="cn=readadmin,dc=gsr,dc=pt" read by dn="cn=pykotaadmin,dc=gsr,dc=pt" write by dn="cn=pykotauser,dc=gsr,dc=pt" read by self write by anonymous auth by * none # allow the "ldap admin dn" access, but deny everyone else # (Samba related) access to attribute=sambaLMPassword,sambaNTPassword by dn="cn=admin,dc=gsr,dc=pt" write by dn="cn=readadmin,dc=gsr,dc=pt" read by dn="cn=pykotaadmin,dc=gsr,dc=pt" write by dn="cn=pykotauser,dc=gsr,dc=pt" read by * none # Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. access to dn.base="" by * read # The admin dn has full write access, everyone else # can read everything. access to * by dn="cn=admin,dc=gsr,dc=pt" write by dn="cn=readadmin,dc=gsr,dc=pt" read by dn="cn=pykotaadmin,dc=gsr,dc=pt" write by dn="cn=pykotauser,dc=gsr,dc=pt" read by self write by users read by anonymous auth # For Netscape Roaming support, each user gets a roaming # profile for which they have write access to #access to dn=".*,ou=Roaming,o=morsnet" # by dn="cn=admin,dc=gsr,dc=pt" write # by dnattr=owner write # User Limits limits dn="cn=pykotauser,dc=gsr,dc=pt" size.soft=-1 size.hard=soft limits dn="cn=pykotaadmin,dc=gsr,dc=pt" size.soft=-1 size.hard=soft # CA signed certificate and server cert entries: TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /etc/ldap/ssl/cacert.pem TLSCertificateFile /etc/ldap/ssl/certs/servidorcert.pem TLSCertificateKeyFile /etc/ldap/ssl/private/servidorkey.pem # Use the following if client authentication is required TLSVerifyClient demand # ... or not desired at all #TLSVerifyClient try #TLSVerifyClient allow #TLSVerifyClient never #TLSCipherSuite ALL ####################################################################### # Specific Directives for database #2, of type 'other' (can be ldbm too ): # Database specific directives apply to this databasse until another # 'database' directive occurs #database # The base of your directory for database #2 #suffix "dc=debian,dc=org" _________________________________________________________ Apéndice R. Archivo de configuración /etc/ldap/ldap.conf # $OpenLDAP: pkg/ldap/libraries/libldap/ldap.conf,v 1.9 2000/09/04 19:5 7:01 kurt Exp $ # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. HOST gsr.pt BASE dc=gsr, dc=pt PORT 636 TLS_CACERT /etc/ldap/ssl/cacert.pem TLS_REQCERT demand _________________________________________________________ Apéndice S. Archivo de configuración /etc/default/slapd # Default location of the slapd.conf file SLAPD_CONF= # System account to run the slapd server under. If empty the server # will run as root. SLAPD_USER="slapd" # System group to run the slapd server under. If empty the server will # run in the primary group of its user. SLAPD_GROUP="slapd" # Path to the pid file of the slapd server. If not set the init.d scrip t # will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.conf) SLAPD_PIDFILE= # Configure if the slurpd daemon should be started. Possible values: # - yes: Always start slurpd # - no: Never start slurpd # - auto: Start slurpd if a replica option is found in slapd.conf (def ault) SLURPD_START=auto # slapd normally serves ldap only on all TCP-ports 389. slapd can also # service requests on TCP-port 636 (ldaps) and requests via unix # sockets. SLAPD_SERVICES="ldap://gsr.pt:389/ ldaps://gsr.pt:636/" # Additional options to pass to slapd and slurpd SLAPD_OPTIONS="" SLURPD_OPTIONS="" _________________________________________________________ Apéndice T. Archivo de configuración /etc/nsswitch.conf # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: compat ldap group: compat ldap shadow: compat ldap hosts: files ldap dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis _________________________________________________________ Apéndice U. Archivo de configuración /etc/pam_ldap.conf ###DEBCONF### # the configuration of this file will be done by debconf as long as the # first line of the file says '###DEBCONF###' # # you should use dpkg-reconfigure to configure this file # # @(#)$Id: ldap.conf,v 1.28 2003/05/29 13:01:04 lukeh Exp $ # # This is the configuration file for the LDAP nameservice # switch library and the LDAP PAM module. # # PADL Software # http://www.padl.com # # Your LDAP server. Must be resolvable without using LDAP. # Multiple hosts may be specified, each separated by a # space. How long nss_ldap takes to failover depends on # whether your LDAP client library supports configurable # network or connect timeouts (see bind_timelimit). host gsr.pt # The distinguished name of the search base. base dc=gsr,dc=pt # Another way to specify your LDAP server is to provide an # uri with the server name. This allows to use # Unix Domain Sockets to connect to a local LDAP Server. #uri ldap://127.0.0.1/ #uri ldaps://gsr.pt/ #uri ldapi://%2fvar%2frun%2fldapi_sock/ # Note: %2f encodes the '/' used as directory separator # The LDAP version to use (defaults to 3 # if supported by client library) ldap_version 3 # The distinguished name to bind to the server with. # Optional: default is to bind anonymously. binddn cn=readadmin,dc=gsr,dc=pt # The credentials to bind with. # Optional: default is no credential. bindpw 1 # The distinguished name to bind to the server with # if the effective user ID is root. Password is # stored in /etc/ldap.secret (mode 600) rootbinddn cn=admin,dc=gsr,dc=pt # The port. # Optional: default is 389. #port 389 # The search scope. #scope sub #scope one #scope base # Search timelimit #timelimit 30 # Bind timelimit #bind_timelimit 30 # Idle timelimit; client will close connections # (nss_ldap only) if the server has not been contacted # for the number of seconds specified below. #idle_timelimit 3600 # Filter to AND with uid=%s #pam_filter objectclass=account # The user ID attribute (defaults to uid) #pam_login_attribute uid # Search the root DSE for the password policy (works # with Netscape Directory Server) #pam_lookup_policy yes # Check the 'host' attribute for access control # Default is no; if set to yes, and user has no # value for the host attribute, and pam_ldap is # configured for account management (authorization) # then the user will not be allowed to login. #pam_check_host_attr yes # Check the 'authorizedService' attribute for access # control # Default is no; if set to yes, and the user has no # value for the authorizedService attribute, and # pam_ldap is configured for account management # (authorization) then the user will not be allowed # to login. #pam_check_service_attr yes # Group to enforce membership of #pam_groupdn cn=PAM,ou=Groups,dc=padl,dc=com # Group member attribute #pam_member_attribute uniquemember # Specify a minium or maximum UID number allowed #pam_min_uid 0 #pam_max_uid 0 # Template login attribute, default template user # (can be overriden by value of former attribute # in user's entry) #pam_login_attribute userPrincipalName #pam_template_login_attribute uid #pam_template_login nobody # HEADS UP: the pam_crypt, pam_nds_passwd, # and pam_ad_passwd options are no # longer supported. # Do not hash the password at all; presume # the directory server will do it, if # necessary. This is the default. pam_password exop # Hash password locally; required for University of # Michigan LDAP server, and works with Netscape # Directory Server if you're using the UNIX-Crypt # hash mechanism and not using the NT Synchronization # service. #pam_password crypt # Remove old password first, then update in # cleartext. Necessary for use with Novell # Directory Services (NDS) #pam_password nds # Update Active Directory password, by # creating Unicode password and updating # unicodePwd attribute. #pam_password ad # Use the OpenLDAP password change # extended operation to update the password. #pam_password exop # Redirect users to a URL or somesuch on password # changes. #pam_password_prohibit_message Please visit http://internal to change y our password. # RFC2307bis naming contexts # Syntax: # nss_base_XXX base?scope?filter # where scope is {base,one,sub} # and filter is a filter to be &'d with the # default filter. # You can omit the suffix eg: # nss_base_passwd ou=People, # to append the default base DN but this # may incur a small performance impact. #nss_base_passwd ou=People,dc=padl,dc=com?one #nss_base_shadow ou=People,dc=padl,dc=com?one #nss_base_group ou=Group,dc=padl,dc=com?one #nss_base_hosts ou=Hosts,dc=padl,dc=com?one #nss_base_services ou=Services,dc=padl,dc=com?one #nss_base_networks ou=Networks,dc=padl,dc=com?one #nss_base_protocols ou=Protocols,dc=padl,dc=com?one #nss_base_rpc ou=Rpc,dc=padl,dc=com?one #nss_base_ethers ou=Ethers,dc=padl,dc=com?one #nss_base_netmasks ou=Networks,dc=padl,dc=com?ne #nss_base_bootparams ou=Ethers,dc=padl,dc=com?one #nss_base_aliases ou=Aliases,dc=padl,dc=com?one #nss_base_netgroup ou=Netgroup,dc=padl,dc=com?one # attribute/objectclass mapping # Syntax: #nss_map_attribute rfc2307attribute mapped_attribute #nss_map_objectclass rfc2307objectclass mapped_objectclass # configure --enable-nds is no longer supported. # For NDS now do: #nss_map_attribute uniqueMember member # configure --enable-mssfu-schema is no longer supported. # For MSSFU now do: #nss_map_objectclass posixAccount User #nss_map_attribute uid msSFUName #nss_map_attribute uniqueMember posixMember #nss_map_attribute userPassword msSFUPassword #nss_map_attribute homeDirectory msSFUHomeDirectory #nss_map_objectclass posixGroup Group #pam_login_attribute msSFUName #pam_filter objectclass=User #pam_password ad # configure --enable-authpassword is no longer supported # For authPassword support, now do: #nss_map_attribute userPassword authPassword #pam_password nds # For IBM SecureWay support, do: #nss_map_objectclass posixAccount aixAccount #nss_map_attribute uid userName #nss_map_attribute gidNumber gid #nss_map_attribute uidNumber uid #nss_map_attribute userPassword passwordChar #nss_map_objectclass posixGroup aixAccessGroup #nss_map_attribute cn groupName #nss_map_attribute uniqueMember member #pam_login_attribute userName #pam_filter objectclass=aixAccount #pam_password clear # Netscape SDK LDAPS #ssl on # Netscape SDK SSL options #sslpath /etc/ssl/certs/cert7.db # OpenLDAP SSL mechanism # start_tls mechanism uses the normal LDAP port, LDAPS typically 636 ssl start_tls #ssl on # OpenLDAP SSL options # Require and verify server certificate (yes/no) # Default is "no" tls_checkpeer yes # CA certificates for server certificate verification # At least one of these are required if tls_checkpeer is "yes" tls_cacertfile /etc/ldap/ssl/cacert.pem #tls_cacertdir /etc/ssl/certs # Seed the PRNG if /dev/urandom is not provided #tls_randfile /var/run/egd-pool # SSL cipher suite # See man ciphers for syntax tls_ciphers TLSv1 # Client certificate and key # Use these, if your server requires client authentication. tls_cert /home/certs/ldap.cliente.cert.pem tls_key /home/certs/ldap.cliente.key.pem _________________________________________________________ Apéndice V. Archivo de configuración /etc/libnss-ldap.conf Una vez instalado y configurado el paquete libnss-ldap (vea el Ejemplo 5-2 para más detalles), el archivo de configuración para el mismo quedaría de la siguiente manera: ###DEBCONF### # the configuration of this file will be done by debconf as long as the # first line of the file says '###DEBCONF###' # # you should use dpkg-reconfigure libnss-ldap to configure this file. # # @(#)$Id: ldap.conf,v 2.35 2004/03/03 21:06:34 lukeh Exp $ # # This is the configuration file for the LDAP nameservice # switch library and the LDAP PAM module. # # PADL Software # http://www.padl.com # # Your LDAP server. Must be resolvable without using LDAP. # Multiple hosts may be specified, each separated by a # space. How long nss_ldap takes to failover depends on # whether your LDAP client library supports configurable # network or connect timeouts (see bind_timelimit). host gsr.pt # The distinguished name of the search base. base dc=gsr,dc=pt # Another way to specify your LDAP server is to provide an # uri with the server name. This allows to use # Unix Domain Sockets to connect to a local LDAP Server. #uri ldap://127.0.0.1/ #uri ldaps://gsr.pt/ #uri ldapi://%2fvar%2frun%2fldapi_sock/ # Note: %2f encodes the '/' used as directory separator # The LDAP version to use (defaults to 3 # if supported by client library) ldap_version 3 # The distinguished name to bind to the server with. # Optional: default is to bind anonymously. binddn cn=readadmin,dc=gsr,dc=pt # The credentials to bind with. # Optional: default is no credential. bindpw 1 # The distinguished name to bind to the server with # if the effective user ID is root. Password is # stored in /etc/ldap.secret (mode 600) rootbinddn cn=admin,dc=gsr,dc=pt # The port. # Optional: default is 389. #port 389 # The search scope. #scope sub #scope one #scope base # Search timelimit #timelimit 30 # Bind/connect timelimit #bind_timelimit 30 # Reconnect policy: hard (default) will retry connecting to # the software with exponential backoff, soft will fail # immediately. #bind_policy hard # Idle timelimit; client will close connections # (nss_ldap only) if the server has not been contacted # for the number of seconds specified below. #idle_timelimit 3600 # Filter to AND with uid=%s #pam_filter objectclass=account # The user ID attribute (defaults to uid) #pam_login_attribute uid # Search the root DSE for the password policy (works # with Netscape Directory Server) #pam_lookup_policy yes # Check the 'host' attribute for access control # Default is no; if set to yes, and user has no # value for the host attribute, and pam_ldap is # configured for account management (authorization) # then the user will not be allowed to login. #pam_check_host_attr yes # Check the 'authorizedService' attribute for access # control # Default is no; if set to yes, and the user has no # value for the authorizedService attribute, and # pam_ldap is configured for account management # (authorization) then the user will not be allowed # to login. #pam_check_service_attr yes # Group to enforce membership of #pam_groupdn cn=PAM,ou=Groups,dc=padl,dc=com # Group member attribute #pam_member_attribute uniquemember # Specify a minium or maximum UID number allowed #pam_min_uid 0 #pam_max_uid 0 # Template login attribute, default template user # (can be overriden by value of former attribute # in user's entry) #pam_login_attribute userPrincipalName #pam_template_login_attribute uid #pam_template_login nobody # HEADS UP: the pam_crypt, pam_nds_passwd, # and pam_ad_passwd options are no # longer supported. # Do not hash the password at all; presume # the directory server will do it, if # necessary. This is the default. #pam_password clear # Hash password locally; required for University of # Michigan LDAP server, and works with Netscape # Directory Server if you're using the UNIX-Crypt # hash mechanism and not using the NT Synchronization # service. #pam_password crypt # Remove old password first, then update in # cleartext. Necessary for use with Novell # Directory Services (NDS) #pam_password nds # Update Active Directory password, by # creating Unicode password and updating # unicodePwd attribute. #pam_password ad # Use the OpenLDAP password change # extended operation to update the password. #pam_password exop # Redirect users to a URL or somesuch on password # changes. #pam_password_prohibit_message Please visit http://internal to change y our password. # RFC2307bis naming contexts # Syntax: # nss_base_XXX base?scope?filter # where scope is {base,one,sub} # and filter is a filter to be &'d with the # default filter. # You can omit the suffix eg: # nss_base_passwd ou=People, # to append the default base DN but this # may incur a small performance impact. #nss_base_passwd ou=People,dc=padl,dc=com?one #nss_base_shadow ou=People,dc=padl,dc=com?one #nss_base_group ou=Group,dc=padl,dc=com?one #nss_base_hosts ou=Hosts,dc=padl,dc=com?one #nss_base_services ou=Services,dc=padl,dc=com?one #nss_base_networks ou=Networks,dc=padl,dc=com?one #nss_base_protocols ou=Protocols,dc=padl,dc=com?one #nss_base_rpc ou=Rpc,dc=padl,dc=com?one #nss_base_ethers ou=Ethers,dc=padl,dc=com?one #nss_base_netmasks ou=Networks,dc=padl,dc=com?ne #nss_base_bootparams ou=Ethers,dc=padl,dc=com?one #nss_base_aliases ou=Aliases,dc=padl,dc=com?one #nss_base_netgroup ou=Netgroup,dc=padl,dc=com?one # attribute/objectclass mapping # Syntax: #nss_map_attribute rfc2307attribute mapped_attribute #nss_map_objectclass rfc2307objectclass mapped_objectclass # configure --enable-nds is no longer supported. # NDS mappings #nss_map_attribute uniqueMember member # Services for UNIX 3.5 mappings #nss_map_objectclass posixAccount User #nss_map_objectclass shadowAccount User #nss_map_attribute uid msSFU30Name #nss_map_attribute uniqueMember msSFU30PosixMember #nss_map_attribute userPassword msSFU30Password #nss_map_attribute homeDirectory msSFU30HomeDirectory #nss_map_attribute homeDirectory msSFUHomeDirectory #nss_map_objectclass posixGroup Group #pam_login_attribute msSFU30Name #pam_filter objectclass=User #pam_password ad # configure --enable-mssfu-schema is no longer supported. # Services for UNIX 2.0 mappings #nss_map_objectclass posixAccount User #nss_map_objectclass shadowAccount user #nss_map_attribute uid msSFUName #nss_map_attribute uniqueMember posixMember #nss_map_attribute userPassword msSFUPassword #nss_map_attribute homeDirectory msSFUHomeDirectory #nss_map_attribute shadowLastChange pwdLastSet #nss_map_objectclass posixGroup Group #nss_map_attribute cn msSFUName #pam_login_attribute msSFUName #pam_filter objectclass=User #pam_password ad # RFC 2307 (AD) mappings #nss_map_objectclass posixAccount user #nss_map_objectclass shadowAccount user #nss_map_attribute uid sAMAccountName #nss_map_attribute homeDirectory unixHomeDirectory #nss_map_attribute shadowLastChange pwdLastSet #nss_map_objectclass posixGroup group #nss_map_attribute uniqueMember member #pam_login_attribute sAMAccountName #pam_filter objectclass=User #pam_password ad # configure --enable-authpassword is no longer supported # AuthPassword mappings #nss_map_attribute userPassword authPassword # AIX SecureWay mappings #nss_map_objectclass posixAccount aixAccount #nss_base_passwd ou=aixaccount,?one #nss_map_attribute uid userName #nss_map_attribute gidNumber gid #nss_map_attribute uidNumber uid #nss_map_attribute userPassword passwordChar #nss_map_objectclass posixGroup aixAccessGroup #nss_base_group ou=aixgroup,?one #nss_map_attribute cn groupName #nss_map_attribute uniqueMember member #pam_login_attribute userName #pam_filter objectclass=aixAccount #pam_password clear # Netscape SDK LDAPS #ssl on # Netscape SDK SSL options #sslpath /etc/ssl/certs/cert7.db # OpenLDAP SSL mechanism # start_tls mechanism uses the normal LDAP port, LDAPS typically 636 ssl start_tls #ssl on # OpenLDAP SSL options # Require and verify server certificate (yes/no) # Default is "no" tls_checkpeer yes # CA certificates for server certificate verification # At least one of these are required if tls_checkpeer is "yes" tls_cacertfile /etc/ldap/ssl/cacert.pem #tls_cacertdir /etc/ssl/certs # Seed the PRNG if /dev/urandom is not provided #tls_randfile /var/run/egd-pool # SSL cipher suite # See man ciphers for syntax tls_ciphers TLSv1 # Client certificate and key # Use these, if your server requires client authentication. tls_cert /home/certs/ldap.cliente.cert.pem tls_key /home/certs/ldap.cliente.key.pem # Disable SASL security layers. This is needed for AD. #sasl_secprops maxssf=0 # Override the default Kerberos ticket cache location. #krb5_ccname FILE:/etc/.ldapcache _________________________________________________________ Apéndice W. Archivo de configuración /etc/pamd.d/common-account # # /etc/pam.d/common-account - authorization settings common to all serv ices # # This module performs non-authentication based account management. It is # typically used to restrict/permit access to a service based on the ti me of day, # currently available system resources (maximum number of users) or per haps # the location of the applicant user---`root' login only on the console . # # This file is included from other service-specific PAM config files, # and should contain a list of the authorization modules that define # the central access policy for use on the system. The default is to # only deny service to users whose accounts are expired in /etc/shadow. # account required pam_unix.so account sufficient pam_ldap.so _________________________________________________________ Apéndice X. Archivo de configuración /etc/pamd.d/common-auth # # /etc/pam.d/common-auth - authentication settings common to all servic es # # This module type provides two aspects of authenticating the user. # Firstly, it establishes that the user is who they claim to be, by # instructing the application to prompt the user for a password or othe r # means of identification. Secondly, the module can grant group members hip # (independently of the /etc/groups file) or other privileges through # its credential granting properties. # # This file is included from other service-specific PAM config files, # and should contain a list of the authentication modules that define # the central authentication scheme for use on the system # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the # traditional Unix authentication mechanisms. # auth sufficient pam_unix.so auth sufficient pam_ldap.so try_first_pass auth required pam_env.so auth required pam_securetty.so auth required pam_unix_auth.so # Se escribe un aviso en el archivo designado por # syslog para la autentificación, en este caso: # /var/log/auth.log # auth required pam_warn.so auth required pam_deny.so _________________________________________________________ Apéndice Y. Archivo de configuración /etc/pamd.d/common-password # # /etc/pam.d/common-password - password-related modules common to all s ervices # # This module type is required for updating the authentication token as sociated # with the user. Typically, there is one module for each `challenge/res ponse' # based authentication (auth) module-type. # # This file is included from other service-specific PAM config files, # and should contain a list of modules that define the services to be # used to change user passwords. The default is pam_unix password required pam_cracklib.so retry=3 minlen=8 difok=4 password sufficient pam_unix.so use_authtok md5 shadow password sufficient pam_ldap.so use_authtok password required pam_warn.so password required pam_deny.so _________________________________________________________ Apéndice Z. Archivo de configuración /etc/pamd.d/common-session # # /etc/pam.d/common-session - session-related modules common to all ser vices # # This module is associated with doing things that need to be done for the # user before/after they can be given service. Such things include the # logging of information concerning the opening/closing of some data ex change # with a user, mounting directories, etc. . # # This file is included from other service-specific PAM config files, # and should contain a list of modules that define tasks to be performe d # at the start and end of sessions of *any* kind (both interactive and # non-interactive). The default is pam_unix. # session required pam_mkhomedir.so skel=/etc/skel/ umask=0022 session required pam_limits.so session required pam_unix.so session optional pam_ldap.so _________________________________________________________ Apéndice AA. Archivo de configuración /etc/nscd.conf # # /etc/nscd.conf # # An example Name Service Cache config file. This file is needed by ns cd. # # Legal entries are: # # logfile # debug-level # threads <#threads to use> # server-user # server-user is ignored if nscd is started with -S parameters # stat-user # # enable-cache # positive-time-to-live