Protocolos Para Instalación de Servicios




Sistema de Instalción y Configuración de Esquema
EKEKO - OpenLDAP - SAMBA - OpenWebMail

Por
Bernardo José Bongiovanni - Gastón Pablo Pérez

Parte del Proyecto Mojotoro
Universidad Nacional de Salta

Director - Diego Saravia


INDICE

1. Introducción
    1.1 Conceptos Generales y Sistema EKEKO
        1.1.1 Esquema de Servicios 
    1.2 Conceptos de LDAP 
        1.2.1 ¿Cómo funciona LDAP? 
        1.2.2 Orientación de este documento 
    1.3 Conceptos de OpenWebMail 
        1.3.1 Idea General 
        1.3.2 Ventajas 
    1.4 Conceptos de Autenticación via LDAP 
2. Sistema EKEKO 
    2.1 Requerimientos 
    2.2 Instalación de Sistema EKEKO 
3. Servidores LDAP 
    3.1 Requerimientos 
    3.2 Instalación de Servidor Central LDAP 
        3.2.1 Como instalar los paquetes 
    3.3 Configuración Servidor Central LDAP 
        3.3.1 Configuración ODBC 
        3.3.2 Funciones de PostgreSQL en EKEKO 
        3.3.3 Archivos de Configuración de LDAP 
    3.4 Instalación de Servidor de Réplica LDAP 
        3.4.1 Instalación de Paquetes 
    3.5 Configuración Servidor de Réplica LDAP 
4. OpenWebMail 
    4.1 Requerimientos 
    4.2 Instalación de OpenWebMail 
    4.3 Configuración de OpenWebMail 
5. Samba 
    5.1 Introduccion 
    5.2 Requerimientos 
    5.3 Configuración 
6. Clientes LDAP 
    6.1 Configuración de Clientes LDAP - Linux 
        6.1.1 Requerimientos 
        6.1.2 Configuración Por Medio de Herramientas 
        6.1.3 Configuración Manual 
    6.2 Configuración de Clientes LDAP -Windows 
        6.2.1 Introduccion 
        6.2.3 Configuracion de Clientes Windows 
7. Manejo de LDAP Fuera de EKEKO 
    7.1 Introducción 
    7.2 Creando nuestros archivos ldif (modificacion de migration-tools) 
        7.2.1 Ejemplo de Entrada en un Archivo .ldif 
        7.2.2 MigrationTools 
    7.3 Introducción de datos a LDAP mediante archivos en formato ldif 
        7.3.1 Introducción de Usuarios de Sistema 
        7.3.2 Introducción de Grupos de Sistema 
    7.4 Busqueda de Entradas con ldapsearch 
8. Herramientas Útiles 
    8.1 LDAPBrowser 
9. Recomendaciones e Ideas Utiles 
10. Aclaraciones y Fe de Erratas
11. Licencia
12. Bibliografía

1. Introducción

En este “tutorial” se intentará dar los conceptos y guías necesarías para instalar y configurar los servicios de:

- Sistema EKEKO.
- LDAP.
- OpenWebMail.
- Autenticación via LDAP.

1.1 Conceptos Generales y Sistema EKEKO

Se deben aclarar ciertos aspectos importantes, ya que no se trata de una instalación de servicios y servidores estandares sino que se pretende que estos servicios formen parte de una red de servicios mas grande y para lo cual se necesitará instalarlos y configurarlos de una manera especial.

1.1.1 Esquema de Servicios

Empecemos por una descripción del esquema de servicios que se pretende montar......

Como base de este proyecto se tiene al Sistema EKEKO desarrollado por Diego Saravia y definido en un principio como un “Escritorio para Internet” con extensión para bases de datos; un ambiente que se incluye a si mismo editando/mostrando todos sus archivos.

Este es un ambiente sobre el cual pueden crearse sistemas..... En conjunto con otros estudiantes y pasantes de la U.N.Sa (Universidad Nacional de Salta) y bajo la tutela de su creador se estan desarrollando sistemas de administración para la universidad. Una de las tareas principales de EKEKO pretende albergar información acerca de las personas y usuarios de la Universidad. Dicha información contendrá entre otras cosas; Nombre de usuarios, Login, cuenta de correo, clave de login, directorio en el servidor, etc.

Toda esta información se almacenará en una base de datos de tipo PostgreSQL la cual maneja el sistema EKEKO, que a su vez es manejado a travez de interfaces web por medio de un navegador.

1.2 Conceptos de LDAP

“LightWeight Directory Access Protocol”, por sus siglas o bien “Protocolo de Acceso a Directorios Liviano”. Es un protocolo de tipo cliente-servidor que funciona bajo TCP/IP para acceder a un servicio de directorio.

Un servicio de directorio es como una base de datos que contiene los datos mas descriptivos y especializados, basados en información ligada a atributos muy concretos. Estos sistemas son utilizados para manejar un gran volumen de datos, soportando complejas modificaciones y actualizaciones en los mismos.

Cualquier sistema de directorio LDAP esta orientado a ofrecer una respuesta rapida a cualquier peticion de datos de gran volumen, asi como a operaciones de busqueda. Tambien soportan facilidad de replicacion de datos, asi como la distribución de los mismos por la red. Estos metodos facilitan el acceso y reutilización de cualquier dato almacenado en el servicio de directorio reduciendo su tiempo de respuesta.

1.2.1 ¿Cómo funciona LDAP?

El servicio de directorio LDAP se basa en un modelo cliente-servidor. Uno o más servidores LDAP contienen los datos que conforman el árbol del directorio LDAP o base de datos troncal. El cliente ldap se conecta con el servidor LDAP y le hace una consulta. El servidor contesta con la respuesta correspondiente, o bien con una indicación de dónde puede el cliente hallar más información (normalmente otro servidor LDAP). No importa con qué servidor LDAP se conecte el cliente: siempre observará la misma vista del directorio; el nombre que se le presenta a un servidor LDAP hace referencia a la misma entrada a la que haría referencia en otro servidor LDAP. Es ésta una característica importante de un servicio de directorios universal como LDAP.

El demonio o programa servidor para el directorio LDAP se llama slapd y puede ejecutarse sobre muchas plataformas UNIX diferentes.

Hay otro demonio o programa servidor que se encarga de la replicación entre servidores. Su nombre es slurpd.

1.2.2 Orientación de este documento

El servidor LDAP en su forma estandard viene configurado y listo para instalar y trabajar con bases de datos de tipo LDBM, aquí lo pretendido es hacer que el servidor LDAP tome los datos de la misma base de datos que maneja el EKEKO, por lo tanto su instalación y configuración tiene unas cuantas variantes ya que no trabajaremos con este tipo de bases de datos sino con una del tipo PostgreSQL.

Ademas de esto tendremos que instalar y configurar los servidores de replicación (o servidores esclavos) para el servidor central.

Lo que pretendemos principalmente en este documento es explicar como hacer para que LDAP trabaje con la base de datos PostgreSQL ya que este es el punto mas dificil y el que mas nos ha costado resolver, no obstante explicaremos como hacerlo de la manera estandard ya que lo necesitaremos tambien para los servidores de replicación.

1.3 Conceptos de OpenWebMail

OpenWebMail es un sistema de Webmail basado en Neomail que proporciona una de las muchas variantes libres para ofrecer correo electronico a los usuarios a travez de la red, ademas de mantener las antiguas virtudes del mismo neomail se han agregado muchas otras entre ellas la autenticación de los usuarios mediante LDAP y muchas otras que luego veremos como configurar.

Su instalación y configuración no es de mucha preocupación pero habra que tener en cuenta ciertos detalles y aspectos ya que vamos a seguir un esquema talvez diferente al que viene por defecto.

1.3.1 Idea General

La idea es simple..... Los datos de los usuarios que se han ingresado por medio del sistema EKEKO se encuentran en la base de datos PostgreSQL que maneja el mismo, el Servidor de LDAP puede mirar esos datos y el OpenWebMail estará configurado para autenticar mediante LDAP....... Esto es.... Cuando un usuario de correo ingrese su nombre de usuario y contraseña en el Login de Correo este le dirá a LDAP que chequee este usuario y su contraseña, si existe, LDAP le proporcionará al programa de correo la validación correspondiente, pudiendo el usuario entrar en sesión.

1.3.2 Ventajas

Las ventajas de usar un webmail son bastante notorias, y las mas importantes son:

- Es una implementación de muy bajo costo ya que no se necesitan recursos de mucha envergadura.

- Los clientes se manejan a travez de un navegador por lo que no es necesario ningun tipo de configuración en los mismos ahorrando esto mucho tiempo.

1.4 Conceptos de Autenticación via LDAP

LDAP es un servicio de directorio que nos permitirá como ya mencionamos anteriormente, contener entre otras cosas los datos (logins, claves) de los usuarios de la red, y realizar la autentificación de los mismos a travez de un unico servidor central o de sus replicas o servidores esclavos.

Veremos como configurar un cliente Linux o Windows para que se autentifique a travez de un directorio LDAP. Una de las grandes ventajas de esto será que un usuario podrá iniciar una sesión en cualquier maquina cliente conectada a la red, esto sin necesidad de tener una cuenta de usuario localmente ya que el servidor LDAP lo autenticará.... no se usará /etc/passwd..... por supuesto para los casos en los que el usuario no sea un usuario local de la maquina Esto le permitirá trabajar en una sesión en la cual su carpeta de trabajo será la carpeta que tiene asignada en el servidor LDAP.


2. Sistema EKEKO

2.1 Requerimientos

2.2 Instalación de Sistema EKEKO

La instalación del Sistema EKEKO es bastante sencilla, solo deberemos descomprimir el paquete correpondiente y ubicarlo (en el caso de una distribución de Linux DEBIAN) en el directorio /var/lib/

tar xvfz ekeko-version.tar.gz
cp -R ekeko-version.tar.gz /var/lib
De esta manera tenemos el siguiente esquema:
/var/lib/ekeko/ #directorio principal
/raiz/ #la raiz del sistema EKEKO
/SIS/ #directorio principal de sistema EKEKO
/src #directorio de fuentes del EKEKO

El ambiente incluye sistemas, cada uno en un directorio. Los sistemas conocen las propiedades de los sistemas en que se incluyen.

Cada sistema tiene en principio tres tipos de elementos, archivos, vistas de bases de datos y registros de bases de datos.

Los elementos son administrados mediante weblets, que consisten en un acceso directo, que puede referenciar a un archivo, un directorio (sistema incluido) o un par consistente en un ejecutable embebido mas un template que representan las vistas y como hijos a sus registros.

Se puede editar y/o ver un elemento del sistema segun se desee y/o tenga derechos. Tanto la edicion como la vista pueden ser en formato con sensible o como fuente.

Cada sistema del EKEKO es un directorio con archivos visibles y ocultos, tiene en su interior un directorio /SIS que indica que el mismo es un “Sistema” sigiendo el arbol hay dentro de /sistema/SIS/ tres directorios principales más

/bin --> Donde se encontrarán todos los weblets.

/db --> Donde se encuentran las definiciones de las bases de datos. Las bases pueden tener vistas, cada vista es un elemento directamente accesible o cada registro dela misma.

/template --> Es donde estan los “templates” para las vistas de los weblets osea los que le dan el formato en el que se verán los datos en el navegador.

Entonces para instalar despues de haber puesto lo anterior en /var/lib/ hacemos:

cd /var/lib/ekeko/raiz/SIS/src/

make

Posiblemente tengamos que cambiar los permisos de /var/log/ekeko.log para que pueda escribir el apache en el.

Otro error posible es cuando queremos recompilar el EKEKO; debemos hacer lo siguiente:

En el caso que ya tuvieramos instalado EKEKO, seria conveniente que se borraran las bases de datos de ekeko, ya que estas pueden llegar a causar algun tipo de inconveniente.

Lo siguiente seria borrar los archivos de EKEKO que tienen algo que ver con las bases, ya que si instalamos un ekeko nuevo, a lo mejor nos daria algun error si dejaramos las bases de datos antiguas. Estos archivo se encuentrar en

/var/lib/ekeko/raiz/SIS/

Tendriamos que borrar todos los archivos del directorio “bases”

Luego borrar todos los archivos de extension .sql , .log y .db del directorio db.

Esos archivos son los que le dicen a EKEKO si es que tiene que crear las bases de datos nuevas. Y en los archivo de extension .bd se encuentra el nombre (numero) que le da EKEKO a una base de datos en particular

cd /var/lib/ekeko/raiz/SIS/src/
rm borrains
make borrains
make

Hay que cambiar los permisos del archivo /var/log/ekeko.log para que deje escribir al usuario de apache; en nuestro caso hacemos.

chmod 700 /var/log/ekeko.log
chown www-data /var/log/ekeko.log

Hay que darle permisos de creacion de tablas al usuario del Apache; en DEBIAN es el usuario www-data en otras distribuciones es el usuario nobody.

Entonces en una consola, y logueado como usuario root, hacemos:

su postgres
createuser -a -d www-data

y le decimos que si a crear bases, no a que cree usuarios.

Recordemos que nos acabamos de loguear como el usuariop postgres, asi que no tenemos los provilegios de root, asi que deberemos volver a estar como root.

El único problema que podemos tener son los permisos de accesos que brinda el postgres a las bases, esto nos puede dar problemas a la hora de ejecutar EKEKO, vamos a dar por el momento un ejemplo del archivo de configuracion de postgres el /etc/postgresql/pg_hba.conf (recordando nuestra distribución DEBIAN) donde se da permisos a todo el mundo en base a la confianza.

Editando el archivo antes mencionado en las ultimas tres lineas del mismo cambiamos de la siguiente forma

local all trust
host all 127.0.0.1 255.0.0.0 trust
host all 0.0.0.0 0.0.0.0 trust

Seguramente en donde dice “trust” dirá algo como “ident sameuser” , lo ponemos así por ahora.

Luego para que los cambios surtan efecto, deberemos reiniciar el servidor postgresql en debian seria algo como

/etc/init.d/postgresql restart

Por último para ingresar al Sistema, abrimos un navegador web y colocamos la dirección

http://localhost/cgi-bin/ekeko

3. Servidores LDAP

3.1 Requerimientos

3.2 Instalación de Servidor Central LDAP

Supondremos que a esta altura ya tenemos instalado el PostgreSQL, para lo cual no es necesario instalar nada raro, por lo que pasaremos a explicar como instalar los demas paquetes ya que no se necesita ninguna configuración especial para el mismo.

Volviendo al LDAP cabe desatacar que deberemos conseguir los paquetes no compilados es decir los que vienen con la extensión .tar.gz y no los binarios o precompilados que vienen para cada distribución como son los que tienen las extensiones .deb (para DEBIAN) o .rpm (para SUSE o REDHAT). Ya que tenemos que compilarlos con algunas opciones especiales que los paquetes que vienen en forma estandard no traen, esto ya lo habiamos mencionado antes y es la parte importante en donde dejamos atrás la configuración estandar de el LDAP.

Vamos a usar OpenLDAP que es una de las alternativas GNU para LDAP, podemos conseguir las últimas versiones de OpenLDAP de su página www.openldap.org .

3.2.1 Como instalar los paquetes

Recordar siempre que para realizar estas tareas necesitaremos tener la clave del root.

Una vez descomprimido y desempaquetado cada uno de los programas iremos entrando en el directorio correspondiente y ejecutaremos las siguientes instrucciones.

Tambien es importante seguir este orden de instalación o podemos encontrarnos con problemas.

iODBC

Para instalarlo solo necesitamos realizar los siguientes pasos:

tar xvfz iodbc-version.tar.gz
cd /directorio/donde_descomprimiste_el_paquete
./configure --with-iodbc-inidir=/etc
make
make install
psqlodbc
tar xvfz psqlodbc-version.tar.gz
cd /directorio/donde_descomprimiste_el_paquete
./configure --with-iodbc --with-odbcinst=/etc
make
make install

OpenLDAP

tar xvfz ldap-version.tar.gz
cd /directorio/donde_descomprimiste_el_paquete
./configure --enable-sql --without-cyrus-sasl --disable-bdb --enable-crypt
make depend
make
make install

Las opciones --without-cyrus-sasl y --disable-bdb son para remover el soporte de autenticación Cyrus Sasl y el uso de un backend de Base de Datos Berkeley ya que esto no es necesario y podria molestar en la fase de configuración pidiendonos paquetes que no nos son necesarios.

Si usamos encriptación de claves en el servidor por medio de crypt tendremos que habilitarlo con --enable-crypt de otra manera nunca podremos autenticar con LDAP.

3.3 Configuración Servidor Central LDAP

3.3.1 Configuración ODBC

En primer lugar tenemos que decirle al odbc como será nuestra conección con la base de datos y avisarle al sistema donde estan los controladores y otras cuestiones. Para esto tenemos 2 archivos y daremos una configuración de ejemplo.

/etc/odbc.ini

[ODBC Data Sources]
UNSA_LDAP=PostgreSQL
[UNSA_LDAP] #nombre de la coneccion odbc
Driver=/usr/local/lib/psqlodbc.so #driver usado para conectar
Description=Conexion para LDAP/POSTGRESQL SEMINARIO
Servername=localhost
Port=5432
Protocol=6.4
FetchBufferSize=99
Username=www-data
Password=*
Database=nombre_de_base_datos_registro_civil_en_ekeko
ReadOnly=no
Debug=1
CommLog=1

[ODBC]
InstallDir=/usr/local/lib

La base de datos de registro civil en ekeko esta en /var/lib/ekeko/raiz/SIS/db/alias.db

Ese es el que deberemos poner donde dice Database= , cabe la aclaracion de que EKEKO llama a todas las bases de datos con numeros para poder tener dos bases de datgos con el mismo nombre, pero ekeko sabra que son diferentes porque tendran el mismo número.

/etc/odbcinst.ini

[PostgreSQL]
Description=ODBC for PostgreSQL
Driver=/usr/local/lib/psqlodbc.so
[ODBC]
Trace=1
Debug=1
Pooling=No

Debemos probar si se puede establecer la conexión odbc y Postgres, esto supone ya hemos instalado EKEKO; por lo tanto la base de datos a la que hicimos mención en el archivo de configuración /etc/odbc.ini ya esta creada. En realidad la base no se crea cuando instalamos EKEKO sino cuando lo hacemos correr por primera vez.

Vamos a hacer que el usuario de Apache sea el dueño de la base de datos, por lo tanto debemos habilitarlo para crear, las bases (esto ya lo hicimos anteriormente cuando instalamos EKEKO).

Entonces probamos en una consola con el usuario definido ahi mismo también, con el programa odbctest.

su www-data

odbctest

DSN=UNSA_LDAP

El DSN es el nombre que le pusimos a la conexión de la base de datos en el /etc/odbc.ini, en nuestro caso es UNSA_LDAP, pero podria ser cualquier nombre que utilizemos.

Si funciona bien nos dará el prompt de sql. De otra manera deberemos revisar el archivo de configuración o permisos de acceso del usuario a la base de datos, o el archivo de configuración de Postgres que mencionamos anteriormente (/etc/postgresql/pg_hba.conf).

Para salir de odbctest, deberemos presionar las teclas Ctrl + C

3.3.2 Funciones de PostgreSQL en EKEKO

Lo unico que faltaria para que la base de datos creada por EKEKO para el Sistema de Registro Civil, que en un principio funcionaria con EKEKO, tambien funcione con cualquier cliente de Ldap (por ejemplo LDAPBrowser, GnomeLDAP) seria agregarle unas funciones sql ya predefinidas, para eso hacemos

psql -q -d nombre_de_base_datos_registro_civil_en_ekeko < alias_functions.sql

El archivo alias_functios.sql esta en trinidad/arch_varios

3.3.3 Archivos de Configuración de LDAP

Ahora vamos a la configuración del servidor LDAP para esto debemos editar el archivo de configuración del programa servidor que es el slapd; para una distribución DEBIAN y habiendo seguido los pasos anteriores de la instalacion, estos archivo se encuentran en el directorio /usr/local/etc/openldap.

En el mismo tenemos un directorio llamado /usr/local/etc/openldap/schema en el cual se encuentran los archivos que contienen los esquemas, estos definen clases y atributos de los objetos que componen las entradas al directorio, las Objectclases y atributos con los que trabaja el LDAP. Seguramente encontraremos ahi los esquemas necesarios pero deberiamos asegurarnos de tener los siguientes.

Como solo necesitamos autenticar mediante LDAP vamos a usar muy pocos datos, solo los necesarios por lo que vamos a hacer una pequeña modificacion al esquema nis.schema.

Abrimos el archivo para edicion y buscamos la definicion de la ObjectClass “posixAccount” que es la siguiente:

objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY
DESC 'Abstraction of an account with POSIX attributes'
MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
MAY ( userPassword $ loginShell $ gecos $ description ) )

Cambiamos donde dice AUXILIARY por STRUCTURAL. De esta forma nos evitaremos de trabajar con multiples objectClass y cada usuario será definido por solo esta objectClass.

Entonces ahora si podemos editar el archivo de configuración del servidor, este es slapd.conf. Aquí va un ejemplo.

# $OpenLDAP: pkg/ldap/servers/slapd/back-sql/rdbms_depend/pgsql/slapd.conf,v 1.1.2.2 2002/08/29 01:51:04 kurt Exp $
#
# Lea slapd.conf(5) por detalles en las opciones de configuracion.
#Este archivo no debe ser legible por todo el mundo
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/nis.schema
# Define global ACLs to disable default read access.
# 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

access to *
by self write
by * read

access to * by dn="cn=admin,dc=unsa,dc=edu,dc=ar" write
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://192.168.1.1/
pidfile /usr/local/var/slapd.pid
argsfile /usr/local/var/slapd.args
#######################################################################
# sql database definitions --> esta es la parte mas importante
#######################################################################
database sql #tipo de base de datos
suffix "dc=unsa,dc=edu,dc=ar" #el dn raiz del arbol LDAP
rootdn "cn=admin,dc=unsa,dc=edu,dc=ar" #dn del administrador LDAP
rootpw secret #clave de administrador LDAP
dbname UNSA_LDAP #el nombre de la conexión por ODBC
dbuser www-data #el nombre del dueño de la base de datos (usuario apache)
#dbpasswd #comentado porque el usuario apache no tiene clave
insentry_query "insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from ldap_entries),?,?,?,?)"
upper_func "upper"
strcast_func "text"
concat_pattern "?||?"
has_ldapinfo_dn_ru no
schemacheck on
lastmod off

La linea insentry_query define la consulta que usa el LDAP para añadir una entrada pero para nuestro caso no será de mucha relevancia ya que nuestros datos y entradas se ingresarán a partir del sistema EKEKO.

La linea que dice rootpw es la que lleva la clave del administrador de LDAP en este caso esta puesta como texto plano, no es algo muy seguro que digamos, si queremos podemos ponerla encriptada anteponiendo a la misma la cadena {crypt}. Una forma de encriptar la clave es haciendo:

perl -e “print crypt(“passwd”, “string_salto”);”

En passwd ponemos la clave a encriptar en texto plano y en string_salto un salto de 2 caracteres.

Esto nos imprimirá en la consola la calve encriptada; solo resta pegarla en el archivo slapd.conf y anteponerle la cadena {crypt}. Por ejemplo esto deberiamos poner en vez de poner secret como pusimos en el archivo de confguración de ejemplo:

rootpw {crypt}23aBA1.GvSREg

Y nuestra clave seguiría siendo “secret”.

Ahor alo ultimo que nos quedaria por hacer seria arrancar el servidor ldap, en nuestro caso no lo arrancariamos desde inetd, pero se podria hacer, modificando o creando los archivos correspondientes, cosa que escapa a este manual, en tonces para arrancar el servidor ldap, ponemos

/usr/local/libexec/slapd -d 5 y enter

Si todo fue bien, deberiamos haber visto un gran debug y “slapd starting”, si sucedió eso, estamos listos para empezar a usar ldap con backend de postgres y EKEKO.

3.4 Instalación de Servidor de Réplica LDAP

Un servidor esclavo o de replicación de LDAP es otro servidor mas de LDAP pero en este caso se utiliza un programa llamado slurpd que es el encargado de permitir al servidor slapd maestro proporcionar el servicio de replicación de operaciones de actualización. Es el responsable de la distribución de los cambios que se hacen en el servidor maestro hacia los esclavos. Libera al servidor maestro slapd de los problemas relacionados con los servidores esclavos inaccesibles o caidos ya que slurpd gestiona automaticamente las actualizaciones fallidas. Slapd y Slurpd se comunican a travez de un fichero de texto que se utiliza como traza de cambios; cuando en el servidor maestro se producen cambios este los escribe en el archivo de replica y cuando el programa slurpd lee este archivo y encuentra cambios los propaga a los servidores esclavos.

En resumen un servidor LDAP maestro usa el programa slurpd que se encarga de propagar los datos de una base de datos slapd a otra de un servidor LDAP esclavo.

Según lo que hemos instalado tenemos el programa slurpd en /usr/local/libexec/slurpd.

Aclaración: Para los servidores esclavos de LDAP vamos a instalar en los otros servidores, servidores ldap estandard, osea aquellos que trabajan con tipos de bases de datos LDBM ya que no requerimos que trabajen con un backend de PostgreSQL porque solo serviran para autenticación, ellos no visualizarán las bases de EKEKO sino las propias que solo guardarán datos replicados por el servidor maestro, debido a que en estos servidores no se deberían hacer modificaciones de datos ni ingreso de nuevos usuarios, esta tarea se realizará en el servidor maestro y con el Sistema EKEKO; ademas si se realizaran cambios en los mismos estos no se reflejarian en el servidor maestro.

3.4.1 Instalación de Paquetes

Habiendo tomado esta aclaración podemos instalar sin problemas los paquetes para LDAP que vienen en nuestra distribucion (para DEBIAN los *.deb)

Para instalarlos, en DEBIAN podemos hacer:

apt-get install paquetes1, paquete2, paquete3........

3.5 Configuración Servidor de Réplica LDAP

En este caso en otro servidor, instalaremos un servidor LDAP standard para utilizarlo como esclavo, por lo tanto algunos archivos han cambiaran.

Los archivos de configuración de LDAP se encuentran en /etc/ldap (para DEBIAN), seguro encontraremos el demonio para slapd y slurpd en /etc/init.d/, sino estos programas deberían encontrarse en /usr/sbin.

Vamos a tener que darle la misma estructura que el servidor maestro por lo tanto es importante que cambiemos el archivo de esquema nis es decir ahora /etc/ldap/schemas/nis.schema de la misma manera que lo hicimos para el servidor maestro.

Slurpd utiliza al igual que slapd el fichero de configuración: /usr/local/etc/openldap/slapd.conf (en el caso de nuestra instalación, en el servidor maestro).

Para la configuración solo resta agregar unas lineas al mismo, por ejemplo:

Archivo slapd.conf – Servidor LDAP maestro (agregar en la parte de la definicion de la base de datos)

replica host=192.168.1.2 #host esclavo
binddn=”cn=admin,dc=unsa,dc=edu,dc=ar” #dn de administrador LDAP esclavo
bindmethod=simple credentials=admin #metodo de autenticacion y clave de administ. (encriptada)
replogfile /usr/local/var/replog #archivo de log de replica

Archivo slapd.conf – Servidor LDAP esclavo (agregar en la parte de la definicion de la base de datos)

Recodar que en el caso del servidor esclavo y debido a que se trata de una instalación estandard este archivo se encuentra en /etc/ldap/slapd.conf.

updatedn “cn=admin,dc=unsa,dc=edu,dc=ar” #dn de administrador LDAP esclavo
updateref 192.168.1.1 #servidor Ldap maestro

El binddn y el updatedn deben ser iguales.

Recomendación

Para poder empezar con un servidor LDAP maestro y uno esclavo, ambos deben empezar funcionando con sus bases de datos identicas, por lo que recomendamos iniciar ambos en cero (sin entradas de usuarios). Luego hay que iniciar el servidor esclavo y el maestro y entonces realizamos las entradas en el servidor maestro; esto producirá la replicación de los datos al servidor esclavo.

4. OpenWebMail

4.1 Requerimientos

4.2 Instalación de OpenWebMail

Podríamos instalar el OpenWebMail obteniendo sus paquetes binarios pero daremos aquí una explicación de como hacerlo desde sus paquetes no compilados ya que siempre podremos encontrar las ultimas versiones no compiladas y nos serviran para instalarlas en cualquier tipo de servidor (o sea cualquier distribución).

En primer lugar desempaquetamos y descomprimimos el paquete de OpenWebMail; para este entonces supondremos tener instalado y corriendo el servidor web Apache con los requerimientos necesarios ya que no ahondaremos en este aspecto salvo se necesite algun tipo de configuración fuera de lo común.

(Vamos a seguir tomando por cuenta un servidor DEBIAN pero solo para tomar una distribución en particular y no liarnos con las rutas, en caso de tener otra solo cambiamos las rutas de los archivos.)

Dentro del paquete que acabamos de descomprimir tenemos dos directorios /cgi-bin y /data.

Dentro de cada uno de estos encontramos una carpeta /openwebmail; copiamos la carpeta /data en el directorio

/var/www, que es de donde el Apache saca las paginas web y copiamos la carpeta openwebmail que se encuentra dentro de cgi-bin en el directorio /usr/lib/cgi-bin/ que es de donde Apache saca los programas *.pl ejecutables para OpenWebMail.

4.3 Configuración de OpenWebMail

Primero modificamos el fichero /usr/lib/cgi-bin/openwebmail/auth_ldap.pl que es el encargado de hacer la autenticación via LDAP y cambiamos las siguientes lineas con los valores correspondientes:

my $ldapHost = “nombre_o_dir_servidor” #nombre o direccion del servidor LDAP
my $ou = “ou=People” #la organización a la que pertenecemos People por defecto
my $cn = “cn=LOGIN” #el nombre del administrador del ldap
my $dc1 = “dc=unsa”
my $dc2 = “dc=edu,dc=ar”
my $pwd = “secret” #password del administrador de ldap (encriptada)

Luego tenemos que modificar el fichero /usr/lib/cgi-bin/openwebmail/etc/openwebmail.conf que es donde deberemos poner nuestras preferencias de configuración del Openwebmail para que trabaje a nuestro gusto.

Veremos entonces algunas de estas opciones y su significado:

domainnames auto #toma por defecto el dominio de nuestra maquina pero pueden agregarse otros
auth_module auth_ldap.pl #este es el modulo de autenticación para nosotros, el de LDAP
mailspooldir /var/mail #el spool donde se encuentran los mails de los usuarios
dbm_ext .pag #poner .pag si dice otra cosa
dbmopen_ext none
dbmopen_haslock no
ow_cgidir /usr/lib/cgi-bin/openwebmail #el directorio cgi del OpenWebMail
ow_cgiurl /cgi-bin/openwebmail #el directorio cgi del OpenWebMail para el navegador
ow_htmldir /var/www/data/openwebmail #el directorio de los html de OpenWebMail
ow_htmlurl /openwebmail #el directorio de los html de OpenWebMail para el navegador
logfile /var/log/openwebmail.log #el archivo donde se escriben los logs de OpenWebMail
spellcheck /usr/local/bin/ispell #el programa para el corrector ortográfico
default_languaje es #Lenguaje por defecto para la interfaz; “español” en este caso
enable_pop3 yes #Soporte para descarga de servidores POP3

Una vez hecha nuestra configuración deberemos ejecutar:

/usr/lib/cgi-bin/openwebmail/openwebmail-tool.pl --init

Listo ya tenemos instalado y configurado el OpenWebMail para usar....

Vuelvo a recordarles que para este caso hemos seguido una configuración para un servidor con una distribución DEBIAN en el caso de tener otra distribución seguramente algunos de los parametros de configuración cambiarán, pero la mayoría de estos cambios solo se referirán a ubicación de los archivos en el sistema por lo que no debieramos preocuparnos demasiado.

Recomendación

Creería que no hace falta pero....... por las dudas hago pequeña mención a la idea de no probar nada hasta no tener instalado, configurado y corriendo en perfectas condiciones el servicio de LDAP, osea que los usuarios pueden hacer autenticación sin ningun problema ya que se trata de la misma autenticación que para hacer una sesión en un cliente, y por consiguiente si un usuario no puede autenticar mediante LDAP en una maquina cliente, dificilmente lo hará en OpenWebMail.

5. Samba

5.1 Introduccion

La interconexión entre equipos Linux y Windows es importante ya que esto permitirá a los usuarios compartir archivos e impresoras, esta configuración se consigue exitosamente a travez de SAMBA.

SAMBA es un conjunto de programas, mantenidos por “The Samba Team” y bajo la Licencia Publica General o GPL y que implementan bajo sistemas UNIX el protocolo Server Message Block (SMB), muchas veces referido tambien como Common Internet File Sistem (CIFS), LanManager o Protocolo NetBios, y nos puede servir como sustituto total para servidores Windows NT, Warp, NFS o servidores Netware.

5.2 Requerimientos

Los paquetes que se necesitan son:

Estos se encuentran en nuestra distribución de DEBIAN Woody, pero vamos a destacar nuevamente que a lo que queremos llegar nuevamente es algo especial ya que nuestro sistema SAMBA deberá autenticar a los usuarios mediante LDAP, y trabajando con EKEKO. Cabe destacar que lo especial de esta configuracion no esta ligada a SAMBA, sino al la maquina en si, es por eso que no hondaremos en la configuracion de esta herramienta

Recomendariamos instalar el que viene con la distribucion o conseguirlo en .tar.gz, en RPM o DEB según la distribucion de la pagina de samba www.samba.org.

Si es .tar.gz desempaquetarlo

tar xvfz samba-latest.tar.gz

Les recomendariamos leer WHATSNEW.txt y docs/textdocs/UNIX_INSTALL.txt

Configurarlo, compilarlo e instalarlo

# ./configure
# make
#make install

Los directorios por defecto son:

/usr/local/samba/bin (demonios y ejecutables)
/usr/local/samba/lib (archivos de configuración)
/usr/local/samba/man (páginas de manual)
/usr/local/samba/var (archivos de log y locks)

5.3 Configuración

El archivo de configuracion se encuentra en /etc/samba/smb.conf, aquí mostraremos no como ejemplo, aunque sencillo nos permitira conectar el directorio /home de cada usuario en una maquina windows.


# Parametros Globales

[global]

workgroup = grupo_de_trabajo

netbios name = nombre_netbiod

server string = LDAP-SAMBA Server (Samba %v)

obey pam restrictions = Yes

passwd program = /usr/bin/passwd %u

passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .

syslog = 0

log file = /var/log/samba/log.%m

max log size = 1000

dns proxy = No

invalid users = root #invalidar ese usuario por cuestiones de seguridad

[homes]

comment = Directorios Homes de Usuarios #comentario

read only = No # si es de solo lectura

create mask = 0700 #mascara de creacion de ficheros

directory mask = 0700 # mascara de creacion de directorios

guest ok = Yes # si esta habilitado

[printers]

comment = Todas las Impresoras # comentario

path = /tmp # donde guardara los archivos samba en este caso de impresion

create mask = 0700

printable = Yes

browseable = No #no se puede navegar dentro de ese directorio

Una breve explicación del archivo de configuración de SAMBA puede ser la siguiente:

[global] Cualquier opción definida en esta sección aplica para el resto de las secciones definidas

[homes] Cuando un cliente intenta conectarse a un recurso compartido que no existe en el servidor, pero existe [homes] entonces Samba interpreta el recurso desconocido como si se tratase de un nombre de usuario. Si dicho usuario existe en el servidor, Samba comparte automágicamente el directorio personal del usuario.

[printers] Si el comportamiento de la sección anterior no es capaz de generar un recurso apropiado para el usuario, pero existe [printers] entonces Samba interpreta el recurso desconocido como si se tratase de un nombre de impresora. Si existe una impresora con ese nombre, Samba la comparte automágicamente. Eso seria lo mas

Lo unico que faltaria por hacer seria arrancar al servidor samba, hay dos posibilidades

Iniciarlos manualmente

/usr/bin/smbd -D

/usr/bin/nmbd -D

Iniciarlos durante el arranque del sistema

/etc/rc.d/init.d/samba (SYSV Init)

/etc/rc.d/rc.local (BSD Init)

Entonces lo que faltaria para que todo quede funcionando seria, hacer a la maquina que tiene el servidor LDAP cliente de si misma, como asi tambien a los servidores de replicas, para eso veamos el capitulo que sigue...

Recomendación

Nosotros presentamos un archivo de configuracion sencillo, con lo minimo indispensable para que funcione SAMBA, pero si ya tenemos instalado SAMBA en nuestro servidor, podriamos utilizar ese archivo de configuracion o seguir utilizando el servidor SAMBA que tenemos intalado desde antes, el secreto de lograr que SAMBA autentique mediante ldap, como nosotros lo presentamos, es hacer al servidor LDAP cliente de si mismo, asi SAMBA no autentica sobre un sistema /etc/passwd sino que lo hace mediante LDAP.

Ademas, ya que la configuracion y el manejo de samba es tocar y ver los archivos en texto, recomendariamos usar alguna herramienta gráfica, que vienen con las distribuciones, nosotros probamos SWAT y nos resulto muy facil de aprender, intuitivo y ademas funciona en un Browser, asi que no ocupa muchos recursos del servidor, se lo puede descargar de www.samba.org. Cosa en la que no hondaremos ya que no es el fin de esto manual

6. Clientes LDAP

Supondremos ya en este paso que tenemos un servidor LDAP corriendo y que el mismo ve a los usuarios, tanto el servidor maestro como uno replicado, tienen cargados ya los datos de los usuarios, logins, claves, etc.

6.1 Configuración de Clientes LDAP - Linux

6.1.1 Requerimientos

Para los clientes necesitamos basicamente 2 librerias:

6.1.2 Configuración Por Medio de Herramientas

En el caso de Linux la mayoria de las distribuciones ya traen herramientas especificas para configurar la máquina como cliente LDAP; YaST en SUSE, authconfig en REDHAT, etc.

En estas herramientas se nos preguntan los parametros básicos para actuar como un cliente; estos parametros son:

6.1.3 Configuración Manual

En el caso de no tener una herramienta de configuración, no debemos preocuparnos ya que podemos hacerlo a mano y esta tarea no requiere de muchos esfuerzos, es bastante sencillo.

Tendremos que modificar dos ficheros del sistema uno es el /etc/ldap.conf y otro es el /etc/nsswitch.conf, esta es la ubicación de estos ficheros en muchas de las distribuciones; en otras por ejemplo en SUSE, /etc/openldap/ldap.conf.

ldap.conf

Este fichero sirve para indicar los parametros globales del sistema para autenticar como cliente de LDAP. En el indicaremos el servidor LDAP y sobre que parte del directorio nos vamos a autenticar. Basicamente debemos indicar:

host unsa.edu.ar #direccion ip o nombre del servidor LDAP

base dc=unsa,dc=edu,dc=ar #base del servidor LDAP

Siendo host la direccion de la maquina servidor y base el nombre distinguido que usaremos para localizar la base de datos de los usuarios.

nsswitch.conf

En este fichero indicaremos como queremos que la maquina cliente autentifique, para ello editamos y colocamos los tres parametros siguientes asi:

passwd: files ldap

shadow: files ldap

group: files ldap

De esta manera le estamos indicando al cliente en que orden debe realizar la autenticación del usuario. Primero se fija en los ficheros locales y luego si no encuentra al usuario se fija en el directorio LDAP, de esta manera el usuario “root” siempre autenticará de manera local.

¡Atención!

Otra cuestion a tener en cuenta es la siguiente; al crear usuarios locales en la maquina cliente, los mismos deberán tener el mismo numero de usuario que poseen en el servidor LDAP ya que si no es asi para el servidor LDAP son tomados como usuarios diferentes.

6.2 Configuración de Clientes LDAP -Windows

6.2.1 Introduccion

La idea principal es esto es unificar el Login de un usuario ya sea como explicamos anteriormente en Linux o en este caso en Windows; cualquier usuario podría ingresar a sus archivos ubicados en el servidor desde cualquier computadora de la red ya sea con Windows o Linux como asi tambien iniciar una sesion para trabajar.

Queremos hacer mención especial en este caso a que nos encontramos en plena etapa de pruebas con esto, de manera que pasaremos a explicar de manera breve alguna idea de que es lo que se quiere lograr, en las proximas versiones de este manual desarrollaremos este tema mas a fondo, en el cual explicaremos que y como deben instalarse y configurarse los servicios de SAMBA en LINUX para poder unificar los clientes windows a nuestro esquema de red, pero trabajando con LDAP.

6.2.3 Configuracion de Clientes Windows

Deberemos configurar los clientes Windows de una manera especial para que trabajen con SAMBA de manera correcta, cosa que no tiene nada de especial.

Veremos los pasos a seguir para configura un cliente Windows 9X

Una vez echo esto, quiere decir que ya tenemos el cliente Windows conectado a SAMBA y viendo los archivos las carpetas que tiene Samba

El paso a seguir es el tema de la clave en texto plano en windows, y que como está configurado SAMBA en este ejemplo usaria las claves de texto plano, en otro caso habria que modificar el archivo de configuracion de samba en nuestro caso /etc/samba/smb.conf .

Los pasos a seguir serian los siguientes:

1º Ejecutar el editor de Registros (regedit)

2º Agregar en el registro según la version de windows un DWORD de valor igual a 1 (uno)

Windows NT:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters

Agregar: EnablePlainTextPassword = dword:00000001

Windows 9X - Milenium:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP Agregar: EnablePlainTextPassword = dword:00000001

Windows 2000:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkStation\ =>

Parameters

Agregar: EnablePlainTextPassword"=dword:00000001

Una vez realizado el cambio en el registro, podriamos entrar en el servidor SAMBA y alli conectar una unidad de red, que en nuestro ejemplo seria /homes que es el directorio home del usuario en el servidor Linux.

Lo que cabe destacar en este punto es que al iniciar una cesion de red en windows, este pide una clave, esa clave es manejada por Windows, y en este caso la misma no seria manejable por SAMBA-LDAP, como esta armado el esquema que estamos presentando, el usuario cambiaria su clave en EKEKO, esta cambio se reflejaria automaticamente en LDAP, y SAMBA tomaria ese cambio para que, cuando el usuario en windows ingrese a su directorio home de linux, en el entorno de red, este le pedira la nueva clave, que se cambio desde EKEKO

7. Manejo de LDAP Fuera de EKEKO

7.1 Introducción

Hasta ahora todo lo que venimos siguiendo se ha basado en la idea de que nuestro servidor de LDAP trabaja mirando en la base de datos de EKEKO y solo se limita a realizar busquedas para efectuar la autenticación de los usuarios; ya que como dijimos anteriormente la carga de los datos se realizará principalmente a travez de los sistemas de EKEKO.

No obstante LDAP tiene sus propias funciones para realizar carga, modificacion y eliminación de datos, a continuación veremos como hacer uso de estas herramientas ya que a pesar de que estamos trabajando con un backend especial para LDAP (PostgreSQL) las mismas también pueden ser implementadas y esto nos puede agilizar en algunos casos bastante el trabajo.

Lo principal que veremos es como ingresar en la base de datos de EKEKO usuarios de una manera rápida, por ejemplo ingresar de una sola vez todos los usuarios del sistema de nuestro servidor, esto podría agilizarnos el trabajo en el sentido de que, si lo hacemos a travez de EKEKO de la manera en la que veniamos pensando hacerlo, podriamos tradar bastante por ejemplo en ingresar unos 500 usuarios y sus claves de acceso de a uno por uno; con una función de LDAP solo nos tomará unos cuantos minutos.

7.2 Creando nuestros archivos ldif (modificacion de migration-tools)

Como veremos en el siguiente punto la función para ingresar los datos a la base de LDAP, que en nuestro caso se trata de la misma base de EKEKO, se llama “ldapadd”, luego veremos los parametros que toma y como funciona.

Esta función necesita leer los datos a ingresar de un archivo de texto especial con un formato especial, este archivo es del tipo “nombre_archivo.ldif”.

Como ya sabemos LDAP se guía por las “entradas” que encuentra en su árbol, por lo tanto la funcion ldapadd lo que hace es añadir entradas que encuentra en este archivo, veamos un ejemplo de una entrada.

7.2.1 Ejemplo de Entrada en un Archivo .ldif

dn: uid=pablo,ou=People,dc=unsa,dc=edu,dc=ar
uid: pablo
cn: Gaston Pablo Perez
objectClass: posixAccount
userPassword: {crypt}KsRM1CbltWY02
loginShell: /bin/bash
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/pablo

Por lo tanto un archivo ldif para agregar los usuarios de nuestro servidor, deberá tener por cada usuario una entrada como esta. De mas esta decir que escribirlo a mano sería una tarea muy tediosa y peor que la idea de ingresar los usuarios por EKEKO de a uno por vez; pero no debemos preocuparnos ya que hay una serie de herramientas que pueden crearnos estos archivos en un abrir y cerrar de ojos. Estas herramientas se llaman “migrationtools”, se trata de un set de scripts escritos en Perl para migrar usuarios, grupos y muchas cosas mas a LDAP, en este caso nosotros solo utilizaremos la parte para migrar los usuarios y talvez migrar los grupos de un sistema.

Para nuestro servidor DEBIAN podemos instalar el paquete migrationtools que viene con nuestra distribución, o bien podemos bajarlas del sitio oficial de OpenLDAP www.openldap.org.

7.2.2 MigrationTools

Vamos a seguir con el ejemplo de la migracion de los usuarios, tenemos que tener en cuenta dos archivos de las migrationtools:

El migrate_common es donde se define los datos escenciales para la estructura de LDAP y el migrate_passwd usa el migrate_common para crear el archivo con los usuarios de sistema tomando los datos de el archivo /etc/passwd y del /etc/shadow (en general se le dice que los tome de estos 2 archivos), pero si los usamos tal como vienen nos van a crear entradas bastante diferentes al ejemplo

Vamos a destacar algo; esta entrada corresponde a un usuario pero esta definida especificamente con la estructura que necesitamos para trabajar con nuestro LDAP armado con PostgreSQL. Deberemos hacer unas modificaciones a estas herraminetas para que agregen solo los datos que necesitamos en la entrada. Para esto directamente mostraremos una definición completa de los dos archivos:

migrate_common.ph

En este solo editamos las siguientes lineas.

# Default DNS domain
$DEFAULT_MAIL_DOMAIN = "unsa.edu.ar"; #nuestro dominio
# Default base
$DEFAULT_BASE = "dc=unsa,dc=edu,dc=ar"; #la raiz o base de nuestro directorio LDAP
# turn this on to support more general object classes such as person.
$EXTEND_SCHEMA = 0

migrate_passwd.pl

En este archivo lo unico que haremos es comentar algunas lineas que escriben datos en el archivo ldif que nosotros no necesitamos por ahora. A continuación mostramos el archivo de ejemplo.


#!/usr/bin/perl
require 'migrate_common.ph';
$PROGRAM = "migrate_passwd.pl";
$NAMINGCONTEXT = &getsuffix($PROGRAM);
&parse_args();
&read_shadow_file();
&open_files();
while(<INFILE>)
{
chop;
next if /^#/;
next if /^\+/;
s/Ä/Ae/g;
s/Ë/Ee/g;
s/Ï/Ie/g;
s/Ö/Oe/g;
s/Ü/Ue/g;
s/ä/ae/g;
s/ë/ee/g;
s/ï/ie/g;
s/ö/oe/g;
s/ü/ue/g;
s/ÿ/ye/g;
s/Æ/Ae/g;
s/æ/ae/g;
s/Ø/Oe/g;
s/ø/oe/g;
s/Å/Ae/g;
s/å/ae/g;
local($user, $pwd, $uid, $gid, $gecos, $homedir, $shell) = split(/:/);

if ($use_stdout) {
&dump_user(STDOUT, $user, $pwd, $uid, $gid, $gecos, $homedir, $shell);
} else {
&dump_user(OUTFILE, $user, $pwd, $uid, $gid, $gecos, $homedir, $shell);
}
}
sub dump_user
{
local($HANDLE, $user, $pwd, $uid, $gid, $gecos, $homedir, $shell) = @_;
local($name,$office,$wphone,$hphone)=split(/,/,$gecos);
local($sn);
local($givenname);
local($cn);
local(@tmp);
if ($name) { $cn = $name; } else { $cn = $user; }
$_ = $cn;
@tmp = split(/\s+/);
$sn = $tmp[$#tmp];
pop(@tmp);
$givenname=join(' ',@tmp);
print $HANDLE "dn: uid=$user,$NAMINGCONTEXT\n";
print $HANDLE "uid: $user\n";
print $HANDLE "cn: $cn\n";
if ($EXTENDED_SCHEMA) {
if ($wphone) {
print $HANDLE "telephoneNumber: $wphone\n";
}
if ($office) {
print $HANDLE "roomNumber: $office\n";
}
if ($hphone) {
print $HANDLE "homePhone: $hphone\n";
}
if ($givenname) {
print $HANDLE "givenName: $givenname\n";
}
print $HANDLE "sn: $sn\n";
if ($DEFAULT_MAIL_DOMAIN) {
print $HANDLE "mail: $user\@$DEFAULT_MAIL_DOMAIN\n";
}
if ($DEFAULT_MAIL_HOST) {
print $HANDLE "mailRoutingAddress: $user\@$DEFAULT_MAIL_HOST\n";
print $HANDLE "mailHost: $DEFAULT_MAIL_HOST\n";
print $HANDLE "objectClass: mailRecipient\n";
}
print $HANDLE "objectClass: person\n";
print $HANDLE "objectClass: organizationalPerson\n";
print $HANDLE "objectClass: inetOrgPerson\n";
}
# print $HANDLE "objectClass: account\n";
print $HANDLE "objectClass: posixAccount\n";
# print $HANDLE "objectClass: top\n";
if ($DEFAULT_REALM) {
print $HANDLE "objectClass: kerberosSecurityObject\n";
}
if ($shadowUsers{$user} ne "") {
&dump_shadow_attributes($HANDLE, split(/:/, $shadowUsers{$user}));
} else {
print $HANDLE "userPassword: {crypt}$pwd\n";
}
if ($DEFAULT_REALM) {
print $HANDLE "krbName: $user\@$DEFAULT_REALM\n";
}
if ($shell) {
print $HANDLE "loginShell: $shell\n";
}
if ($uid ne "") {
print $HANDLE "uidNumber: $uid\n";
} else {
print $HANDLE "uidNumber:\n";
}
if ($gid ne "") {
print $HANDLE "gidNumber: $gid\n";
} else {
print $HANDLE "gidNumber:\n";
}
if ($homedir) {
print $HANDLE "homeDirectory: $homedir\n";
} else {
print $HANDLE "homeDirectory:\n";
}
if ($gecos) {
# print $HANDLE "gecos: $gecos\n";
}
print $HANDLE "\n";
}
close(INFILE);
if (OUTFILE != STDOUT) { close(OUTFILE); }
sub read_shadow_file
{
open(SHADOW, "/etc/shadow") || return;
while(<SHADOW>) {
chop;
($shadowUser) = split(/:/, $_);
$shadowUsers{$shadowUser} = $_;
}
close(SHADOW);
}
sub dump_shadow_attributes
{
local($HANDLE, $user, $pwd, $lastchg, $min, $max, $warn, $inactive, $expire, $flag) = @_;
# print $HANDLE "objectClass: shadowAccount\n";
if ($pwd) {
print $HANDLE "userPassword: {crypt}$pwd\n";
}
if ($lastchg) {
# print $HANDLE "shadowLastChange: $lastchg\n";
}
if ($min) {
# print $HANDLE "shadowMin: $min\n";
}
if ($max) {
# print $HANDLE "shadowMax: $max\n";
}
 if ($warn) {
# print $HANDLE "shadowWarning: $warn\n";
}
if ($inactive) {
# print $HANDLE "shadowInactive: $inactive\n";
}
if ($expire) {
# print $HANDLE "shadowExpire: $expire\n";
}
if ($flag) {
# print $HANDLE "shadowFlag: $flag\n";
}
}

7.3 Introducción de datos a LDAP mediante archivos en formato ldif

7.3.1 Introducción de Usuarios de Sistema

Ahora podemos crear nuestro archivo ldif con las entradas de los usuarios, haciendo:

./migrate_passwd.pl /etc/passwd passwd.ldif

Para Tener en Cuenta

Luego de realizar esto, revise el archivo LDIF resultante. Debe remover de su sistema las entradas de cuentas tales como root y usuarios locales que no necesita que aparezcan en LDAP.

Finalmente agregamos las entradas de usuarios al LDAP, haciendo:

Primero arrancamos nuestro servidor LDAP

/usr/local/libexec/slapd

Podemos arrancar tambien el servidor en modo debug, para ver los pasos y errores que podrian presentarse ante una eventualidad, hacemos entonces:

/usr/local/libexec/slapd -d 5

Ahora relizamos las entradas con el comando ldapadd:

ldapadd -x -D “cn=admin,dc=unsa,dc=edu,dc=ar” -w secret -f passwd.ldif

-x: Para usar autenticación simple
-D: Para indicar la entrada del administrador o de quien tenga permisos para ingresar datos al LDAP.
-w: Para indicar la contraseña de la entrada indicada con -D, podemos poner -W solamente y se nos pedirá luego la contraseña.
-f: Para indicar el archivo que contiene la definición de las entradas.

Pueden darse muchas otras opciones que pueden verse en el manual de ldapadd haciendo:

man ldapadd

7.3 Introducción de Grupos de Sistema

De la misma manera en como hicimos para agregar a LDAP las entradas correspondientes a los usuarios del sistema, podemos ingresar las entradas correspondientes a los grupos del sistema. Para esto solo bastará crear nuestro archivo en formato ldif pero esta vez con el scrip llamado migrate_group.pl; hacemos:

./migrate_group.pl /etc/group group.ldif

Luego volvemos a efectuar la entrada a LDAP (con ldapadd) pero esta vez haciendo referencia al archivo group.ldif que acabamos de crear en la parte donde se pone -f archivo.ldif

7.4 Busqueda de Entradas con ldapsearch

Ahora podemos chequear si entraron los datos al LDAP con el comando ldapsearch, que sirve para realizar busquedas sobre el directorio; por ejemplo para buscar al usuario pablo que pusimos como ejemplo en la entrada ldif que mencionamos mas arriba:

ldapsearch -x -b “dc=unsa,dc=edu,dc=ar” “uid=pablo”

-x: Para autenticación simple.
-b: Para indicar la base sobre la que realizamos la busqueda.
“uid=pablo” Está indicando lo que queremos buscar.

Esto nos devuelve algo como esto:

# extended LDIF
#
# LDAPv3
# base <dc=unsa,dc=edu,dc=ar> with scope sub
# filter: uid=pablo
# requesting: ALL
#
# pablo, People, unsa.edu.ar
dn: uid=pablo,ou=People,dc=unsa,dc=edu,dc=ar
cn: pablo
userPassword:: e2NyeXB0fVZmYzJkRVF0bjRuLms=
uid: pablo
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/pablo
loginShell: /bin/bash
objectClass: posixAccount
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1

Tambien tenemos muchas opciones para realizar busquedas sobre LDAP y tambien podemos consultar el manual correspondiente:

man ldapsearch

Recomendación

Para hacer consultas y busquedas sobre el árbol de LDAP es mucho más comodo trabajar con alguna herramienta gráfica que sobre la consola, hay varias y bastante buenas, en la sección Herramientas Útiles de este manual, explicamos brevemente como instalar una de ellas.

8. Herramientas Útiles

8.1 LDAPBrowser

Hay muchas herramientas muy útiles para trabajar con ldap en forma gráfica y que tienen soporte para realizar la mayoría de las funciones de LDAP o por lo menos busquedas y navegación por el arbol de directorio, otras ofrecen r la importación o exportación de archivos .ldif o modificación y eliminación de datos y otras cosas más.

Entre todas estas podemos encontrar: gnomeldap, ldapexplorer, ldapbrowser, y muchas otras más. Las dos primeras las podemos encontrar entre los paquetes de nuestra distribución de DEBIAN Woody, aunque talvez a estas alturas no sean las ultimas versiones de las mismas.

A nuestro criterio una de las mejores herramientas gráficas que hemos probado para el trabajo con LDAP es LDAPBrowser; esta desarrollada en JAVA2 por lo que tendremos que tener instalado unos paquetes extra que en nuestra distribución estandard no vienen, los que necesitamos son:

Seguramente y por lo que recordamos no son necesarios todos estas para que funcione pero en este momento no recordamos con presición cual era la que estaba de más, así que por las dudas se las menciono a todas, y eso si que no está de más :-)

Luego para instalarlos solo hacemos.

dpkg -i nombre_paquete

(Lo nombramos solo a titulo aclaratorio ya que esto no pretende ser un manual de instalación de DEBIAN).

Si estamos trabajando con DEBIAN como hasta ahora, podemos tambien usar “la magia” de la herramienta apt, y mencionar en el archivo /etc/apt/sources.list un mirror de donde queremos que saque los paquetes. En este momento no recuerdo con certeza como era la linea a agregar, prometemos ponerla para la proxima versión de este manual; pero no se preocupen vamos a decirles de donde sacarla: pueden entrar a http://debianitas.net y en esta pagina encontraran muchos sources.list para DEBIAN entre ellos los lugares de donde sacar los paquetes para JAVA2.

Una vez puestos los nuevos sources list solo hacemos.

apt-get install nombre_paquete

Volvemos a mencionar el carácter aclarativo de esto..... perdon por la redundancia :-)

Luego de tener instalada estas librerias de JAVA tenemos que conseguir el paquete de LDAPBrowser, lo podemos descargar de http://freshmeat.net

Instalación

Para instalarlo solo lo descomprimimos en /usr/local por ejemplo y ejecutamos:

cd /usr/local/ldapbrowser

./lbe.sh

¡Listo! Ya está andando....... dejamos en sus manos las pruebas..... es sencillo de manejar y muy intutitivo.

9. Recomendaciones e Ideas Utiles

man nsswitch.conf y tambien haciendo man ldap.conf

Aquí podremos ver todas las opciones de configuracion que tienen los ficheros.

Cuando iniciamos una sesion de trabajo en una maquina Linux, sabemos que debemos proporcionar un usuario y una contraseña; en nuestro esquema de red y de acuerdo a lo configurado nuestra maquina se fijará primero en el sistema local si existe el usuario, en caso de que no exista le pedirá a LDAP que lo autentique.

Con esto llegamos a la pregunta ¿con que /home trabajara un usuario no local?, bueno nosotros hemos creado una configuración bastante sencilla pero que funciona perfectamente.

En nuestro servidor tenemos en /home todas las carpetas de los usuarios de la red y que son los mismos usuarios cargados en LDAP, lo primero que hacemos es crear en el servidor un enlace simbólico a esta carpeta, por ejemplo /red para nosotros.

Al LDAP le decimos que las carpetas de los usuarios ahora son /red/nombre_usuario en vez de /home/nombre_usuario y configuramos el servidor para que exporte este directorio (/home) a todas las maquinas de la red.

En el cliente configuramos para que monte el directorio /home del servidor en una carpeta /red con lo que seguro encontraremos al iniciar nuestra maquina nuestro directorio del servidor en esta carpeta (en realidad es nuestro /home del servidor).

Asi cuando iniciemos una sesión en una maquina cualquiera con un usuario no local siempre el LDAP le dirá al sistema local que la carpeta sobre la cual trabajaremos en esa sesión sera la /red/nombre_usuario con lo que podremos trabajar normalmente como en cualquier otra sesión solo que lo que guardemos ahi estará en el servidor, guardandose así tambien las configuraciones que hagamos por ejemplo para el escritorio en la sesión grafica, etc. ¡una maravilla! ¿no? :-)

Ademas cualquier usuario local tambien podrá encontrar su directorio de red, por añadidura :-)

10. Aclaraciones y Fe de Erratas

Este es el momento de hacer ciertas aclaraciones, si bien las hemos mencionado en muchas oportunidades vale la pena recordar ciertas cuestiones.

En primer lugar este manual pretende ser lo mas explicativo posible acerca de la manera de poder instalar y hacer funcionar todo este esquema de servicios, que es bastante especial, por lo que no ahondamos en ciertas cuestiones que suponemos de antemano deberian saberse antes de relizar esta tarea, que no es tan sencilla como parece.

Al buscar manuales por la red o cualquier otro lado, sobretodo acerca de LDAP, tengan presente que talvez encuentren ciertas diferencias con respecto a lo que mencionamos aquí, esta no es una manera muy natural de trabajar con LDAP, pero ya hemos explicado que queremos alcanzar otro proposito en el cual se encuentran involucrados otros sistemas que trabajarán en conjunto, como ser EKEKO, no obstante esto puede servirle de guia a quien quiera hacer trabajar LDAP con una base de datos Postgres cualquiera.

Hemos tratado de explicar todos los pasos y configuraciones necesarias a realizar basandonos en una distribución en especial (DEBIAN Woody en este caso) para no “marear” a aquellos que intentan montar todo esto, auque hemos mencionado en ciertos casos otras distribuciones, esto quiere decir que no estamos obligados a casarnos con esta distribución y tampoco que será la mejor ni la peor, simplemente fue nuestra elección por un gusto propio, dejamos el libre albedrio de la elección a ustedes; en definitiva cualquiera es un LINUX :-)

Agregamos cosas a este manual de las cuales no podemos asegurar que funcionen de una manera totalmente correcta, o mejor dicho todavia no sabemos con total certeza si asi es como deben instalarse o configurarse ya que nosotros tambien nos encontramos todavia en un proceso de pruebas, en las proximas versiones de este manual iremos corrigiendo algunos errores y completando algunas cuestiones que falten. Estas cosas no probadas totalmente son en especial la parte de SAMBA con LDAP que trata de la parte en donde unificamos los sistemas Linux y Windows, suponemos en este entonces que esta será la mejor opción a tomar en caso de encontrar otra lo haremos saber a la brevedad, aclaro nuevamente, configurar una red con SAMBA para que las maquinas Windows compartan archivos y demas, no es tarea de otro mundo pero deberíamos hacer que trabajen con LDAP.

La parte de LDAP con Postgres y EKEKO anda bastante bien y solo nos resta pulir algunos que otros detalles.

El motivo de este manual ademas de ser el explicativo de un proyecto para la universidad es el de aportar algo a la comunidad del software libre y como bien se sabe esto lleva un proceso y su tiempo, como asi también de la colaboración de los lectores aportando ideas, dudas, correcciones y demás; pretendemos lograr que quienes recien comiencen con esto o algo parecido encuentren algo mas que nosotros para apoyarse, ya que sobre este tema en especial no hay mucha documentación al respecto (me refiero especialmente al tema de LDAP y Postgres) y menos en castellano. Por lo que nuestro gran orgullo es pensar que alguien lo encontrará útil.

Por ultimo y sin justificarnos, sabemos que pueden faltar muchos detalles y seguramente habrá muchas equivocaciones, todo es parte del proceso, y rogamos en primer lugar sepan disculparnos y por favor no duden en consultarnos ante cualquier duda.

Estamos a su dispocición......................

Bongiovanni, Bernardo José bernardobongio@argentina.com

Pérez, Gastón Pablo gpperez@argentina.com

11. Licencia

Todo el software desarrollado en este proyecto se distribuye bajo la licencia GPL http://www.gnu.org, incluyendo los modulos para Ekeko y Trinidad. La documentacion bajo la licencia FDL

12. Bibliografía