Este artículo está disponible en los siguientes idiomas: English Castellano Deutsch Francais Nederlands Turkce |
por Atif Ghaffar Sobre el autor:
Atif es un camaleón. Cambia sus roles, desde Administrador de Sistemas, a programador, a profesor, a administrador de proyectos, a lo que quiera que sea necesario para realizar el trabajo.
Contenidos:
|
Resumen:
En Mi último artículo te introduje en el uso de LDAP bajo Linux. Tuve muchas preguntas de gente que tenía curiosidad de saber como LDAP combinado con algún afinado sovtware de código abierto podian construir correo web o un sistema de hospedaje web.
En este artículo podremos iniciar un sistema ISP escalable basado en LDAP y Linux. Se tocarán muchos de los problemas y preguntas hechas. Podremos entonces usar una utilidad llamada ISPMan para manejarlo o administrarlo.
Para evitar textos de longitud innecesaria con los ejemplos textuales, los he embebido en widgets de área de texto. si realmente quieres imprimir esta página, salvala localmente y cambia el área de texto a pre tags.
Quzás estas líneas en Perl puedan hacer el truco.
perl -pi.bak -e 's!textarea.*?>!pre>!g' filename
Construir un ISP y administrarlo tiene su truco, especialmente si quieres hacerlo muy automatizado, altamente disponible y escalable. Poner en marcha un ISP requiere un equipo de administradores de sistemas, dedicados al funcionamiento de las máquinas, creando cuentas, administrando sitios web, resolviendo problemas, ejecutando tareas de ayuda, etc.
Muchas veces, la tarea de ayuda es pequeña o no se controla al inicio. Muchas de las tareas de ayuda que recibo y toco necesitan necesitan desesperadamente de la ayuda.
LDAP es un directorio excelente. No solo puede manejar el nombre y password de los usuarios sino mucho más acerca de ellos y sus recursos. Conforme avancemos, podremos ver como LDAP ayuda a manejar un montón de cosas de forma centralizada.
ISPMan es el software, lo he escrito, así la gente del departamento de IT no se me equivocará cuando necesiten crear un nuevo dominio, iniciar un nuevo servidor web o cambiar una entrada a un DNS. ISPMan es software de código abierto y está disponible en http://www.ispman.org. Quise probar a explicar más acerca de ISPMan en sí mismo pero voy atrasado. Sientete libre para probarlo y mejorarlo.
Este ISP puede proporcionar DNS, correo, correo web, hospedaje web, etc.
La idea es que un cliente llegue y quiera hospedar el dominio "exampledomain.com".
Este dominio se crea centralizadamente con tan solo unos clicks y un montón de magia es administrada entre las escenas incluyendo creación DNS, creación del servidor virtual para correo y un servidor web virtual.
El cliente tiene un nombre de usuario ftp para acceder a su/sus servidor/es web/ftp. Se puede crear cualquier número de usuarios dentro del dominio para acceso al correo electrónico. Los usuarios dentro del dominio pueden o no recibir espacio web.
Ahí está también el número suministrado de acceso a internet. Debe ser un proceso sencillo y directo o se complicará realmente, eso lo tocaremos en este artículo :).
Cada uno quiere un sitio web y su propio dominio de direcciones de correo electrónico. El servidor de correo electrónico ha sido ligado extrañamente al sistema de cuentas para correos electronicos. No me gusta.
El problema reside en los múltiples niveles cuando quieres manejar [email protected] y [email protected] etc.
Hay un montón de mapeados innecesarios etc para hacer. Felizmente el software futuro podrá escribirse recordando los nombres de dominio.
Por ejemplo, Cyrus, un servidor IMAP excelente. Cyrus administra buzones de correo (no usuarios). Solo dejaría que un buzón tuviese el nombre "aghaffar". Si tengo otro cliente que desde el dominio "linuxrus.com" acceda a un nombre de usuario "aghaffar", he tenido mala suerte. Tengo que crear un buzón con otro nombre y mapear al usuario a ese buzón. Otro truco podría ser crear un usuario "aghaffar.linuxrus.com" pero Cyrus ha usado "." como delimitador del buzón, así que no se puede usar, ni puedo usar "[email protected]".
Anotese tambien que no todos nosotros vivimos en US. Un montón de ejemplos en algunas listas de correo sugieren user1@domain1 y user1@domain2. Ellos esperan que todos los nombres de dominio terminen en .com. De esta forma tendremos que mantener la pista de "username" "domain" "TLD"(Top Level Doamin).
Nuestro diseño debe tener todo esto en cuenta.
Así en lugar de crear un usuario llamado "aghaffar", debemos crear usuarios de esta forma. "username_domain_tld".
Realemente no recuerdo por qué he usado "_" como delimitador, pero "." no estaba disponible por lo de Cyrus, y ahí tuve otros problemas con otros delimitadores, por ejemplo "&" es una mala conjunción para shells y URLs.
Esta es una lista de software que ha sido agradable de usar. Si quieres puedes usar otro, siempre que te funcione.
Nuestro directorio está basado en dominios. Hay dominios, dominio de usuarios, dominio de servicios, etc.
Por ejemplo, un usuario puede solo existir en un dominio (excepto algunos usuarios del sistema como el administrador LDAP, el administrador Cyrus, etc)
una rama del dominio tiene información sobre los usuarios de ese dominio, los datos DNS del dominio, los datos http del dominio, etc, etc.
Ejemplo
Aquí hemos definido una rama para el dominio "developer.ch", esta rama tiene subramas para usuarios, datos dns y datos http.
En este ejemplo, el haber definido un directorio home uid, gid, para el dominio etc, causa que queramos solo el usuario "domain.tld" para acceder via ftp.
Por ejemplo, si el cliente que usa developer.ch quiere descargar ficheros a su directorio, debe acceder como usuario "developer.ch" y dar el password apropiado para acceder al servidor ftp el cual podrá finalmente dar acceso al directorio home.. etc.. etc.. mas sobre esto después.
Para otros usuarios, no definiremos uid, gid, etc porque no querremos entrarlos via ftp.
Podrás encontrar un ejemplo completo de fichero LDIF aquí (este fichero estará obsoleto debido a su maquina de producción, y he añadido características etc en el nuevo diseño) o usa este link si deseas enseñarselo a tu jefe (también un poco desfasado).
Otra gran cosa es que no tenemos que crear ningún sistema de cuentas en /etc/passwd, /etc/shadow etc o manejar NIS etc.
Todas las cuentas son manejadas en LDAP y la autentificación se hará directamente desde LDAP.
Para este truco tomamos un monton de ayuda de PAM (Pluggable Authentification Module) pam_ldap.
PAM te deja definir que modulo debe tener cuidado de la autentificación, autorización, etc.
Por ejemplo, mis archivos /etc/pam.d/imap, /etc/pam.d/pop y /etc/pam.d/proftpd dicen
#%PAM-1.0 auth sufficient /lib/security/pam_ldap.so account sufficient /lib/security/pam_ldap.soAhora todas las autentificaciones imap/pop3/ftp son manejadas por el servidor Ldap. Así el usuario aghaffar_developer_ch toma autentificación y toma sus correros una vez piense que no existen en el sistema o registros nis o passwd.
DNS no tiene por el momento un back end LDAP, y quizás no sea una buena idea tener un backend LDAP para DNS excepto por el DNS Dynamica el cual se usa en conjunción con DHCP. De alguna manera, usaremos LDAP para almacenar información acerca del DNS y entonces extraerla para crear los ficheros de zona DNS. Esto nos permitirá manejar cada cosa centralmente desde una máquina segura, mientras no hagamos cambios en el DNS.
Las entradas DNS en el LDAP se ven así
dn: ou=dnsdata, domain=4unet.net, o=ispman domain: 4unet.net ou: dnsdata objectclass: top objectclass: domainrelatedobject objectclass: posixAccount uid: 4unet.net uidNumber: 2000 gidNumber: 1000 homeDirectory: /home/4unet.net userPassword: {crypt}XXffGGHH loginShell: /bin/true |
La definición se extiende por los datos DNS. Tambien se define un cuenta Posix (un usuario) con el mismo nombre que el dominio. Este usuario es del tipo webmaster, quien puede acceder via ftp cargar archivos a las areas designadas, etc. |
dn: cn=soarecords, ou=dnsdata, domain=4unet.net, o=ispman cn: soarecords primary: ns1.4unet.net ou: dnsdata retry: 1800 rootmail: dnsmaster.4unet.net domain: 4unet.net minimum: 432000 objectclass: top objectclass: domainRelatedObject expire: 1209600 refresh: 21600 |
Esto define los registros SOA para la DNS para 4unet.net. Un script es reponsable de extraer los valores y formatearlos en registro SOA dentro de un DNS para ser incluido en el fichero zona. |
dn: cn=nsrecords, ou=dnsdata, domain=4unet.net, o=ispman domain: 4unet.net cn: nsrecords ou: dnsdata objectclass: top objectclass: domainRelatedObject record: @,ns1.4unet.net record: @,ns2.4unet.net |
Y estos son los registros NS.
Un script puede grabar todos los atributos del registro, y dividirlos por caracteres "," y tomar el objeto y nombre de sevidor para ser añadido al nombre de zona. |
dn: cn=mxrecords, ou=dnsdata, domain=4unet.net, o=ispman domain: 4unet.net cn: mxrecords ou: dnsdata objectclass: top objectclass: domainRelatedObject record: @,10, mx1.4unet.net record: @,100, mx2.4unet.net |
Tal como antes, pero esta vez registros MX.
Estos registros tambien contienen el campo prioritario que está ajustado de acuerdo a los registros MX del fichero de zona. |
dn: cn=arecords, ou=dnsdata, domain=4unet.net, o=ispman objectclass: top objectclass: domainRelatedObject domain: 4unet.net cn: arecords ou: dnsdata record: ns1, 193.247.80.43 record: ns2, 193.247.80.44 record: @,193.247.80.43 record: @,193.247.80.44 |
Estos son los registros A, simplemente host, mapeos de direcciones ip. |
dn: cn=cnames, ou=dnsdata, domain=4unet.net, o=ispman objectclass: top objectclass: domainRelatedObject domain: 4unet.net cn: cnames ou: dnsdata record: ftp, www record: mail, www record: *, www |
Y los CNAMES o Alias para los hosts. |
Necesitas tener proftpd con el modulo LDAP instalado. Si quieres correr ftp con servidores virtuales, etc, y si piensas que estará muy ocupado deberás ejecutarlo como un proceso en solitario en lugar que desde inetd.
Comenta las lineas ftp desde tu inetd.conf y recarga el demonio inetd.
crea un grupo con el gid 1000 llamado ftponly. podemos dar este gid a todos los dominios.
edita tu /etc/pam.d/proftpd como se mostró anteriormente en la sección de autentificación LDAP.
En tu /etc/proftpd.conf debe verse algo como esto.
Para ejecutar proftpd, debes escribir /usr/sbin/proftpd y para matarlo, killall /usr/sbin/proftpd
Compila e instala Cyrus SASL e imapd, y los clientes c-sdk de UW-IMAP. El IMAP, los clientes sdk deben de ser instalados en tu sistema. Prueba primero rpm -aq | grep imap. Si dudas, compila e instala una nueva versión. Crea un usuario del sistema llamado cyrus y un grupo de correo, sigue las instrucciones de instalación y comprueba que tu servidor imap esté trabajando. Una vez esté trabajando simplemente selecciona /etc/pam.d/imap como se mostró anteriormente en la sección de autentificación de LDAP.
Puedes necesitar crear un usuario llamado cyrus o el que admin te de para /etc/imapd.conf en el directorio LDAP.
Por ejemplo si tu admin cyrus es llamado "cyrus", entonces deberías tener una entrada como la que sigue en tu directorio ldap.
dn: uid=cyrus, ou=admins, o=ispman cn: Cyrus Admin sn: Cyrus objectclass: top objectclass: systemadmins uid: cyrus userpassword: XXDDCCYY ou: adminsISPMan puede hacer esas entradas por tí durante los ajustes.
Postfix es muy amigable para LDAP. Puedes construir un dominio virtual y consultas virtuales de usuarios directamente en LDAP así no tendrás que especificar para que dominios debes de recibir correos.
Por ejemplo, si un correo llega para el dominio "perl.ch", deberías mirar en todos los dominios y ver si hay un dominio llamado "perl.ch", si está entonces debes aceptar el correo en lugar de devolverlo.
Mi /etc/postfix/main.cf se ve como este
Gestionar usuarios con ISPMan es facil. La creación de un usuario consiste en dos pasos
ISPMan deja crear buzones de correo para los usuarios para cualquier máquina en tu oficina de correo. Por ejemplo, puedes tener mail1, mail2, mail3, mail4, etc, cada una manejando 10.000 usuarios. Usando el combo LDAP + Postfix + Cyrus, puedes gestionar correo para cualquiera de las maquinas internas.
Por ejemplo. el correo llega para [email protected], Postfix responde al servidor ldap para devolver el maildrop para la entrada que deja [email protected], y el servidor LDAP devuelve [email protected]. El correo es entonces redirigido a la máquina llamada mail5 en tu oficina de correos.
Paralelamente he trabajado con algunos clientes en un proxy IMAP/pop3 que corria en el frontend de los servidores de correo en pop3 y en puertos imap y redireccionaba las respuestas de forma transparente a las máquinas internas. Así tus usuarios sabrán solo una dirección. Por ejemplo mail.developer.ch o pop.developer.ch para conectar para en lugar de conocer cual servidor de correo contiene su correo.
IMP es un gran producto para proporcionar correo web a los usuarios.
Puedes seleccionar un alias de correo.* en el httpd.conf de apache para apuntar a la instalación IMP central.
Por ejemplo el siguiente es desde mi instalación
Estoy trabajando en una versión ligeramente modificada de IMP que puede manejar los casos siguientes.
|
Contactar con el equipo de LinuFocus
© Atif Ghaffar, FDL LinuxFocus.org Pinchar aquí para informar de algún problema o enviar comentarios a LinuxFocus |
Información sobre la traducción:
|
2001-10-02, generated by lfparser version 2.9