Fedora en Nicaragua.

Diseño Asistido por Computadora CAD para Linux QCAD

noreply@blogger.com (Anonymous) — Fri, 29 Jul 2011 02:14:00 +0000

¿Que es el Diseño Asistido por Computadora?

El diseño asistido por computadora, más conocido por sus siglas inglesas CAD (computer-aided design), es el uso de un amplio rango de herramientas computacionales que asisten a ingenieros, arquitectos y a otros profesionales del diseño en sus respectivas actividades. El CAD es también utilizado en el marco de procesos de administración del ciclo de vida de productos (en inglés product lifecycle management).

También se puede llegar a encontrar denotado con las siglas CADD (computer-aided design and drafting), que significan "dibujo y diseño asistido por ordenador" .

Estas herramientas se pueden dividir básicamente en programas de dibujo en dos dimensiones (2D) y modeladores en tres dimensiones (3D). Las herramientas de dibujo en 2D se basan en entidades geométricas vectoriales como puntos, líneas, arcos y polígonos, con las que se puede operar a través de una interfaz gráfica. Los modeladores en 3D añaden superficies y sólidos.

El usuario puede asociar a cada entidad una serie de propiedades como color, usuario, capa, estilo de línea, nombre, definición geométrica, etc., que permiten manejar la información de forma lógica. Además pueden asociarse a las entidades o conjuntos de éstas otro tipo de propiedades como material, etc., que permiten enlazar el CAD a los sistemas de gestión y producción.

¿Que es el QCAD?

QCad es una aplicación informática de diseño asistido por computadora (CAD) para diseño 2D. Funciona en los sistemas operativos GNU/Linux, Mac OS X, Solaris y Microsoft Windows.

QCad fue desarrollado por RibbonSoft. El desarrollo de QCad empezó en octubre de 1999, partiendo de código de CAM Expert. QCad 2, diseñado para "hacer QCad más productivo, más amigable al usuario, más flexible y para incrementar su compatibilidad con otros productos”, empezó su desarrollo en mayo de 2002.

Buena parte de la interfaz y de los conceptos sobre su uso son iguales que los de AutoCAD, aunque quizás más fácil de entender en QCad.

QCad utiliza el formato del archivo de AutoCAD DXF internamente y para guardar e importar archivos. Los archivos se pueden exportar en varios formatos, pero perceptiblemente los que faltan son el VRML y SVG.

Captura de pantalla de QCAD

Caracteristicas de QCAD

Varios modos de creación de líneas, arcos, círculos, elipses, paralelas, ángulos bisectores, etc.
Formato DXF (DXF 2004).
Muchas fuentes de texto CAD.
Dimensiones en distancias, ángulos, diámetros, tolerancias, etc.
Rellenos sólidos y rayados.
Soporte completo para capas y bloques (inserciones).
Herramientas potentes de selección y modificación (mover, rotar, espejo, recortar, estirar, etc.).
Ajuste a objetos (extremos, centros, intersecciones, etc.).
Consola para inserción de coordenadas y ejecución de instrucciones.
Múltiples niveles de «deshacer»/«rehacer».
Soporte para varias unidades, incluyendo métrica, imperial, grados, radianes, etc.
Importación y exportación de mapas de bits (JPEG, PNG, etc.).
Creación de ficheros PS que pueden portarse fácilmente a PDF.
Interfaz de usuario traducida a múltiples idiomas: alemán, catalán, checo, danés, eslovaco, español, estonio, francés, griego, holandés, húngaro, inglés, italiano, polaco, ruso y turco.
Sistemas Operativos soportados; Microsoft Windows, GNU/Linux, Mac Osx.

Ejemplo. creacion del marco y cajetin de una lamina en QCAD

Descaragr QCAD para Mac 10.5-10.6, 10.4, 10.3
Descargar QCAD para GNU/Linux
Descargar QCAD para Microsoft Windows.

Descargar manual de QCAD

Ver manual online

Lanzamiento del FLISOL 2011

noreply@blogger.com (Anonymous) — Wed, 30 Mar 2011 00:17:00 +0000

¿Qué es el FLISOL?

El Festival Latinoamericano de Instalación de Software Libre (FLISoL) es el evento de difusión de Software Libre más grande en Latinoamérica. Se realiza desde el año 2005 y desde el 2008 se adoptó su realización el 4to Sábado de abril de cada año. En 2011 por única vez será el día 9 de Abril.

Su principal objetivo es promover el uso del software libre, dando a conocer al público en general su filosofía, alcances, avances y desarrollo.

A tal fin, las diversas comunidades locales de software libre (en cada país/ciudad/localidad), organizan simultáneamente eventos en los que se instala, de manera gratuita y totalmente legal, software libre en las computadoras que llevan los asistentes. Además, en forma paralela, se ofrecen charlas, ponencias y talleres, sobre temáticas locales, nacionales y latinoamericanas en torno al Software Libre, en toda su gama de expresiones: artística, académica, empresarial y social.

Ubicación del evento

Sedes

Managua

Organiza

Grupo de Usuarios GNU/Linux en Nicaragua

Patrocinadores

Media Partners

Podcast Software Libre Nicaragua (POSOL)

tomado de: Flisol 2011

how to install fedora repositories

noreply@blogger.com (Anonymous) — Fri, 03 Sep 2010 22:51:00 +0000

We have two separate software repositories:

free for Open Source Software (as defined by the Fedora Licensing Guidelines) which the Fedora project cannot ship due to other reasons
nonfree for redistributable software that is not Open Source Software (as defined by the Fedora Licensing Guidelines); this includes software with publicly available source-code that has "no commercial use"-like restrictions

Installation can be done either using a web browser, or via the command line.

Graphical Setup via Firefox web browser

First enable access to the free repository. For users of gpk (gnome package kit) or kpackagekit in Fedora that is easy and basically only one step: just click on one of the following files, depending on what distribution you use and then follow the default options that Firefox and Package Kit offer by clicking Enter a few times (¹):
Once that succeeds, you can enable access to the nonfree repositories by clicking on one of the following files, depending on what distribution you use and then follow the default options that Firefox and Package Kit offer by clicking Enter a few times(¹):

(¹) Once you clicked on above link Firefox will ask you how to Open the file. Here you can simply use the default and open the file with the default application Package Installer. Then Firefox will call Package Kit, which asks Do you want to install this file ?. Click OK to begin install; Package Kit then will complain about a Missing security signature; once you tell Package Kit to install the package nevertheless it will move on and install it. That's all.

Command Line Setup using rpm

To enable access to both the free and the nonfree repository use the following command:

Fedora 12 and 13:

su -c 'yum localinstall --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm'

Fedora Rawhide and what will become Fedora 14 (Alpha, Beta and snapshots):

su -c 'yum localinstall --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-rawhide.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-rawhide.noarch.rpm'

RHEL5 or compatible like CentOS:

su -c 'rpm -Uvh http://download1.rpmfusion.org/free/el/updates/testing/5/i386/rpmfusion-free-release-5-0.1.noarch.rpm http://download1.rpmfusion.org/nonfree/el/updates/testing/5/i386/rpmfusion-nonfree-release-5-0.1.noarch.rpm'

Important notes

You need to enable EPEL on RHEL5 or compatible distributions like CentOS before you enable RPM Fusion for EL. See the fedoraproject wiki for instruction how to enable EPEL.
The RPM Fusion for EL repositories are still in the early testing stages; hence you (for now) need to enable epel-testing as well, as some of the RPM Fusion packages depend on packages that are currently in epel-testing.
All users that used Freshrpms or Livna installed properly (e.g. by installing one of their foo-release packages) got RPM Fusion free and nonfree repositories enabled automatically.
Informacion tomada de RPMFUSION.ORG

Como instalar DansGuard en windows.

noreply@blogger.com (Anonymous) — Fri, 21 May 2010 19:38:00 +0000

Contenido
• Introduccion
• Requisitos Previos
• Recolectando lo necesario
• Instalacion y compilacion
• Opciones Avanzadas
• Configuracion de Squid
• Configuracion del Cliente
• Soporte

Introduccion
Esta no es una guia de instalacion rapida. Este documento apunta a quien busca instrucciones detalladas sobre DansGuardian 2.2.x. Para instalar DansGuardian en forma rapida, le recomendamos leer la Guia de Instalacion Rapida.

Requisitos Previos
Se requiere una distribucion razonablemente reciente de Linux, FreeBSD, OpenBSD, Solaris o SuSE. Tambien se requiere squid corriendo en el puerto 3128.
DansGuardian es in filtro directo que se ubica entre el el cliente Web (web browser) y el Servidor Proxy Squid. Dansguardian acepta conexiones en el puerto 8080 y se conecta a squid en el puerto 3128. Por lo tanto, es importante que no haya otro servicio utilizando el puerto 8080.
Tambien se necesita un Servidor Web. El servicio Apache (httpd) que se incluye con RedHat 6.2 es perfecto y seria dificil encontrar un mejor servidor para tal efecto. El Servidor se usa para mostrar un script cgi escrito en perl que notifiaca al usuario en caso de haber un 'Acceso Denegado'.
Se necesitan tambien varias herramientas de desarrollo estandar como glibc, autoconf, gcc and make. Los usuarios de Debian tambien necesitaran zlib1g-dev. La instalacion predeterminada de Redhat 6.2 y muchas otras ya incluyen dichas herramientas, por lo que no necesitaria preocuparse por las mismas.
La mayoria del tiempo, durante la instalacion necesitara estar conectado como root o para usuarios experimentados, el proceso completo directamente puede efectuarse como root.
Asegurese de que todo lo mencionado previamente esta instalado y funcionando correctamente antes de proseguir.

Recolectando lo necesario
Obviamente necesitara DansGuardian. Lo puede obtener aqui: DansGuardian, o en el sitio US mirror.
Es recomendable instalar desde el codigo fuente ya que siempre esta al dia. Sin embargo, hay paquetes pre-compilados para distintas distribuciones. A fines instructivos, esta guia detalla el proceso de instalacion desde el codigo fuente.

Instalacion y compilacion
Si desea instalar DansGuardian en forma rapida y evitar los detalles de esta guia, no olvide que puede contar con la Guia de Instalacion Rapida.
1. Ponga DansGuardian-2.2.*.source.tar.gz en un area temporal y descomprima el archivo con tar -zxpf. Esto creara el sub-directorio DansGuardian-2.2.*.
DansGuardian usa el autoconf de gnu, auto-generando el archivo Makefile con el script "configure".
2. Ingrese al nuevo directorio con cd. Ejecute el script "configure" con la opcion de ayuda (./configure --help) para ver las opciones de configuracion (vea la tabla a continuacion).
opcion descripcion valor predeterminado
bindir Donde se instalan los binarios o ejecutables /usr/sbin/
sysconfdir Donde se instalan los archivos de configuracion y datos /etc/dansguardian/
sysvdir Donde se instala el script de inicio /etc/rc.d/init.d/
cgidir Ubicacion del directorio cgi-bin /home/httpd/cgi-bin/
mandir Ubicacion de los manuales /usr/man/
logdir Donde se crearan los archivos historicos (logs) /var/log/dansguardian/
runas_usr El usuario de sistema corre como nobody
runas_grp El grupo del usuario del sistema es nobody
piddir Ubicacion del archivo de identificacion del proceso (pid) /var/run/
3. Ejecute "configure" con las opciones deseadas. Por ejemplo vea la seccion Ejemplos de Scripts de Configuracion mas adelante.
Los usuarios de RedHat 6.2 y 7.0 users pueden usar las configuraciones predeterminadas. Los usuarios de RedHat 7.1 y 7.2 necesitaran especificar la opcion cgidir. Usuarios de Solaris, OpenBSD y FreeBSD necesitaran ajustar casi todas las opciones en forma manual.
4. Modifique el archivo Makefile y verifique que todos los parametros son correctos. De no ser asi, ejecute el script nuevamente. Si no esta familiarizado con archivos Makefile, saltee este paso.

5. Ejecute make para compilar DansGuardian (gmake en Solaris).

6. Ejecute make install para crear la estructura de directorios, instalar el programa y archivos en los directorios elejidos y ajustar los permisos en forma apropiada.

7. Ejecute make clean para eliminar los archivos no necesarios.

8. Cuando una pagina es denegada, DansGuardian redireccionara al usuario al script cgi perl en su servidor web, donde el usuario vera el reporte. De esta forma es facil personalizar los mensajes que el usuario recibira. Este servidor no necesariamente tiene que correr en el mismo ordenador donde corre el servicio DansGuardian. Sin embargo, de no estar en el ordenador local, tendra que enmendar o eliminar la linea que especifica la ubicacion del script perl en el archivo Makefile.
Para configurar la direccion del servidor web que mostrara la pagina con el reporte de error, modifique la variable accessdeniedaddress dentro del archivo dansguardian.conf (vea sysconfdir arriba). Para mas opciones de configuracion, vea la seccion Opciones Avanzadas
9. Por ultimo, debe configurar la rotacion de los archivos historicos (logs). La rotacion de los historicos evitara que el crecimiento desmedido de los historicos llene el sistema de archivos. La mayoria de los servicios rotan sus historiales una vez por semana. Con DansGuardian, hay cinco archivos historicos: access.log, access.log.1, access.log.2 ... y asi sucesivamente hasta 4. Todas las semanas, el archivo mas antiguo de los cinco es eliminado y los nombres de los demas archivos se incrementan en uno y un nuevo archivo access.log es creado. El script Makefile copia el script de rotacion de historiales al directorio de configuracion. Es necesario entonces agendar la ejecucion de este proceso de la siguiente manera: Ejecute crontab -e (como root) y agrege la siguente linea:
59 23 * * sat /etc/dansguardian/logrotation
Grabe el archivo. Esto agendara la rotacion a las 23:59 todos los sabados. Por supuesto, usted puede personalizar este parametro y modificar el script de rotacion como usted lo prefiera.
DansGuardian ya esta listo. Ahora puede iniciarlo simplemente ejecutando el binario (por ejemplo, escriba dansguardian y presione Retorno). Puede detenerlo con dansguardian -q. O use el script provisto SysV(-like). Ejecute dansguardian -h para ver otras opciones disponibles.
Ejemplos de Scripts de Configuracion
A continuacion vera algunos ejemplos de opciones para el script de configuracion para diferentes distribuciones:
FreeBSD
La ejecucion con los valores predeterminados deberia funcionar, siempre y cuando la instalacion de FreeBSD haya sido efectuada ubicando los programas en forma predeterminada.

./configure --cgidir=/usr/local/www/cgi-bin/ \
--sysconfdir=/usr/local/etc/dansguardian/ \
--sysvdir=/usr/local/etc/rc.d/ \
--bindir=/usr/local/sbin/ \
--mandir=/usr/local/man/

OpenBSD
La ejecucion con los valores predeterminados deberia funcionar, siempre y cuando la instalacion de OpenBSD haya sido efectuada ubicando los programas en forma predeterminada.

./configure --cgidir=/var/www/cgi-bin/ \
--sysconfdir=/usr/local/etc/dansguardian/ \
--sysvdir=/usr/local/etc/rc.d/ \
--bindir=/usr/sbin/ \
--mandir=/usr/share/man/
RedHat 6.2/7.0
Tambien es posible ejecutar "configure" (./configure) con los valores predeterminados.

RedHat 7.1/7.2
./configure --sysconfdir=/usr/local/etc/dansguardian/ \
--sysvdir=/etc/rc.d/init.d/ \
--cgidir=/var/www/cgi-bin/

Mandrake 7.2
./configure --mandir=/usr/share/man/

Mandrake 8/8.1
./configure --mandir=/usr/share/man/ \
--cgidir=/var/www/cgi-bin/

El usuario de sistema 'squid' puede tambien ser apropiado en lugar de 'nobody' cuando configure el valor del parametro "runas".
SuSE 7.2
./configure --runas_grp=nogroup \
--cgidir=/usr/local/httpd/cgi-bin/

SuSE 7.3
./configure --runas_grp=nogroup \
--cgidir=/usr/local/httpd/cgi-bin/ \
--sysvdir=/etc/init.d/
Solaris
Solo se ha testeado Solaris 8 (7/01). DansGuardian necesita la version GNU de make (gmake), y GCC version 2.95.3 (3.01 puede funcionar, pero no ha sido testeado todavia y por lo tanto, no recomendado).

Ambos gmake y GCC 2.95.3 estan incluidos en el Sistema Operativo en el "Companion CD", y por lo general se instalan en /opt/sfw/bin. Para asegurar que existen en esta ubicacion, simplemente haga (in csh; la sintaxis de bash es diferente):

setenv PATH /opt/sfw/bin\:$PATH

Para compilar y configurar, haga:
./configure --bindir=/opt/dansguardian/sbin/ \
--sysconfdir=/opt/dansguardian/etc/ \
--sysvdir=/etc/init.d/ \
--cgidir=/var/apache/cgi-bin/ \
--mandir=/opt/dansguardian/man/ \
--logdir=/opt/dansguardian/log/

Opciones Avanzadas
DansGuardian es altamente versatil. El codigo fuente le garantiza la maxima flexibilidad de configuracion, aunque para la mayoria de los usuarios sera suficiente con modificar los archivos de configuracion. Si modifica el codigo fuente, por favor envie dichas modificaciones a Daniel.
Despues de haber modificado cualquier archivo de configuracion, necesitara reiniciar DansGuardian. Para esto, ejecute el script sysv con la opcion "restart". Por ejemplo, para usuarios de Redhat ejecute en una terminal:
/etc/rc.d/init.d/dansguardian restart
o para OpenBSD:
/usr/local/etc/rc.d/dansguardian.sh restart
Ademas, ejecute dansguardian -q seguido por dansguardian.
Existe un archivo de configuracion principal, varias listas de frases prohibidas y una lista de excepciones. Las mismas se detallan de la siguiente manera:
exceptionsitelist
Este archivo contiene una lista de fines de dominios que de encontrarse en la URL requerida, , DansGuardian no filtrara la pagina. Observe que no debe incluir http:// o www. al comienzo de los dominios.
exceptioniplist
Este archivo contiene una lista de direcciones IP de clientes que saltearan el filtro. Por ejemplo, la direccion IP del administrator.
exceptionuserlist
Lista de nombre de usuario que no seran filtrados (para esto se necesita autenticacion basica o "ident").
bannedphraselist
Contiene la lista de frases prohibidas. Las frases deben encerrarse entre <>. DansGuardian incluye una lista de ejemplo (en ingles). Debe evitar usar palabras como ya qye de esta manera bloqueara paginas que contengan por ejemplo "Universidad Middlesex". Las frases pueden contener espacios. Use los espacios para obtener mayor beneficio del filtrado. Esta es la parte mas util de DansGuardian y atrapara mas paginas que combinando los filtros de imagen y URL juntos.
Tambien puede usar combinaciones de frases, que de ser encontradas en una pagina, seran bloqueadas.
bannedmimetypelist
Contiene una lista de tipos MIME prohibidos. Si una URL retorna un tipo MIME incluido en esta lista, DansGuardian lo bloqueara. DansGuardian incluye algunos ejemplo de tipos MIME a ser bloqueados. Esta es una forma interesante de bloquear peliculas no deseadas, por ejemplo. Es obvio que no tendria sentido filtrar los tipos MIME text/html o image/*.
bannedextensionlist
Contiene una lista de extensiones de archivos no permitidas. Si una URL termina con alguna extension contenida en esta lista, DansGuardian la bloqueara. DansGuardian incluye un archivo de ejemplo que muestra como denegar extensiones. Esta es una buena forma de evitar que se bajen protectores de pantalla y herramientas para hackers. De mas esta decir que seria una tonteria bloquear las extensiones .html o .jpg, etc.
bannedregexpurllist
Este archivo contiene una lista de expresiones regulares (regexp) a ser bloqueadas. Para mas informacion sobre expresiones regulares, visite (en ingles) a href="http://www.opengroup.org/onlinepubs/7908799/xbd/re.html">este lugar.
bannedsitelist
Este archivo contiene una lista de sitios prohibidos. Si ingresa un nombre de dominio aqui, todo el sitio correspondiente al dominio sera bloqueado. Para bloquear partes especificas de un sitio, vea "bannedurllist". Ademas, si asi lo quisiera, puede bloquear todos los sitios con exepcion de los especificados en exceptionsitelist. Tambien puede bloquear sitios especificados con direcciones IP e incluir una coleccion de listas negras squidGuard. Para habilitar dichas listas, obtengalas en la seccion de extras. Simplemente ubique las listas donde lo crea apropiado y quite el comentario de las lineas correspondientes a las listas negras squidGuard al final del archivo bannedsitelist, verificando que las ubicaciones de los archivos son correctas. Para listas negras de URLs, modifique el archivo bannedurllist de manera similar.
bannedurllist
Este archivo le permite bloquear partes especificas de un site en lugar del sito entero. Para bloquear un sitio entero, vea el archivo bannedsitelist. Para habilitar el bloqueo de listas negras squidGuard, necesita bajar las listas y modificar la seccion de listas negras squidGuard al final del archivo. (de la misma forma en que bannedsitelist se ha explicado anteriormente).
pics
Este archivo le permite hacer un ajuste fino del filtro de PICS (Plataforma para la Seleccion de Contenido de la Internet). Cada seccion PICS contiene una descripcion de las configuraciones permitidas y de lo que las mismas representan. Las configuraciones predeterminadas de DansGuardian estan pensadas para jovenes donde, por ejemplo, los desnudos artisticos estan permitidos.
Para mas detalles e information sobre PICS, visite (en ingles) este sitio.
ICRA
La seccion ICRA se explica por si misma. Un valor 0 significa que nada en esta categoria esta permitido, mientras que un valor 1 lo permite. Por ejemplo:
ICRAnudityartistic = 1
permite los desnudos artisticos. Para informacion mas detallada visite (en ingles) este sitio.
RSAC
RSAC es una version antigua de ICRA. Estos valores varian de 0 (nada es permitido) pasando por 2 (valor predeterminado) hasta 4, que permite todo en la categoria. Para informacion mas detallada visite (en ingles) este sitio.
evaluWEB
evaluWEB utiliza un sistema de calificacion similar a la sistema usado en Filmes Britanicos:
0 = U (Universal, para todas las edades)
1 = PG (Se recomienda la presencia de los padres)
2 = 18 (Solo para mayores de 18)
SafeSurf
Similar a RSAC, pero contiene un rango mas amplio de categorias con valores desde 0 = filtrar todo hasta 9 = permitir todo. Para informacion mas detallada visite (en ingles) este sitio.

Weburbia
Vea evaluWEB. Para informacion mas detallada visite (en ingles) este sitio.

Vancouver Webpages
Otro sistema mas para calificacion. Vea (en ingles) este sitio para mas informacion.

dansguardian.conf
La unica configuracion vital aqui es el valor de accessdeniedaddress . El mismo debe equivaler a la direccion URL (no la ubicacion fisica del archivo) del servidor Apache con el script perl de reporte de acceso denegado. Por lo general, Apache esta instalado en el mismo servidor Squid y DansGuardian. De asi desearlo, esta direccion puede ser cualquier pagina en cualquier servidor web.
Reporting Level
El nivel de reporte cuando una pagina es denegada es configurable. El mismo puede decir simplemente 'Acceso Denegado', o mostrar detalles de porque ha sido denegado y que es lo que se ha denegado. Esto ultimo puede ser util para testear, pero puede que no necesite tanto detalle en una aplicacion de produccion como en una escuela por ejemplo. El modo Stealth agrega los detalles al historico pero no bloquea nada.
Logging Settings
Esto le permite configurar el nivel de reporte historico (log). Puede no reportar nada, solo las paginas denegadas, texto o todos los requerimientos de paginas. Los requerimientos de paginas seguras (HTTPS) solo se registran en el historico cuando el valor de logging equicale a 3 (todos los requerimientos).
Network Settings
Aqui puede modificar la direccion de IP en la que DansGuardian va a aceptar conexiones, el puerto en el que va a escuchar, la direccion de IP y puerto del servidor Squid. Tambien se puede configurar el reporte de Acceso Denegado aqui.
Content Filtering Settings
Aqui se especifica la ubicacion de los archivos que contienen las listas de filtrado. Por lo tanto no es recomendable modificar estos valores.
Reverse Lookups for Banned Sites and URLs
Si habilita esta opcion, DansGuardian hara la resolucion reversa DNS (Servidor de Nombre de Dominio) y buscarlo en las listas correspondientes de sitio y URL. Esto evitara que un usuario por ejemplo entre una direccion IP para acceder a dominios prohibidos. Esta opcion afecta a la velocidad de busqueda, por lo que a no ser que tenga un DNS server local, es recomendable dejar esta opcion desabilitada y usar la opcion Blanket IP Block option en el archivo bannedsitelist.
Build bannedsitelist and bannedurllist Cache Files
Esta opcion compara las fechas de actualizacion de los archivos de lista y cache y los regenera de ser necesario. Si un archivo bsl o bul .processed existe, ese sera el contenido a utilizar. Esto incrementa el proceso de inicio en un 300%. En computadores lentos la diferencia es significativa y no es necesario en computadores rapidos.
POST protection (web upload and forms)
Esta opcion bloquea o limita los uploads (subir archivos) y no sirve para bloquear formularios que no tengan 'upload' de archivos. El valor se especifica en kilobytes despues del codificado MIME y encabezados.
Username identification methods (used in logging)
La opcion proxyauth es para cuando se usa autenticacion basica en el proxy (obviamente esta opcion no sirve para aplicaciones de proxy transparente). La opcion ntlm se usa cuando el proxy soporta autenticacion MS NTLM. Esto solo funciona con IE5.5 SP1 o posterior, y no ha sido implementada todavia. La opcion ident hace que DansGuardian se conecte a un servidor identd en el computador que origino el requerimiento.
Forwarded For
Esta opcion agrega el campo X-Forwarded-For: al encabezado HTTP. Esto puede ayudar a resolver problemas con sitios que necesitan saber la direccion IP de origen.
Max Children
Esta opcion especifica el numero de procesos a iniciar para aceptar conecciones. Esto puede evitar ataques de DoS afectando a un numero ilimitado de procesos. En sitios con mucho trafico, este valor deberia ser duplicado o triplicado.
Log Connection Handling Errors
Esta opcion registra en el archivo historico (log) informacion de 'debug' acerca de estados fork() y accept(), lo cual puede por lo general ser ignorado. Estos estados son registran por syslog y es seguro configurarlo tanto en si o no ('on' u 'off').

Configuracion de Squid
No hay nada requerido aqui ya que para Squid, DansGuardian aparenta ser un cliente web normal. Sin embargo...
Debemos asegurarnos que squid no permitira que ningun cliente web se conecte directamente, salteando a DansGuardian. Se asume que el acceso al puerto de Squid esta bloqueado via firewall o tables de IP (ipchains o iptables) y que la unica forma de acceder a Squid es atraves de DansGuardian. Esto se puede garantizar de varias maneras.
Metodo squid.conf
Puede modificar las reglas ACL para que solo 'localhost' tenga acceso. A continuacion se muestra un ejemplo en el archivo squid.conf:
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
acl localnet src 192.168.42.0/255.255.255.0
http_access allow localnet
http_access allow localhost
http_access deny all
Note que se ha agregado el comentario # a ambas lineas que especifican 'localnet'. Por lo general la configuracion predeterminada de Squid solo permite acceso a localhost, por lo que puede que no necesite modificar esta configuracion.
Con autenticacion proxy, se torna un poco mas complejo. Sin DansGuardian en el archivo squid.conf, tenemos:
authenticate_program /usr/bin/smb_auth -W DOMAIN -U 192.168.0.2
acl domainusers proxy_auth REQUIRED
http_access allow domainusers
http_access deny all
Lo cual permite acceso a los usuarios autenticados desde cualquier lugar.
Sin embargo, tendria sentido dejar que el trafico SSL pase directo sin pasar por DansGuardian, pero al mismo tiempo evitar que el trafico a otros puertos saltee a DansGuardian. Por lo tanto, la seccion se veria de la siguiente forma:
authenticate_program /usr/bin/smb_auth -W DOMAIN -U 192.168.0.2
acl domainusers proxy_auth REQUIRED
acl linuxserver src 192.168.0.1/255.255.255.255
acl ntserver src 192.168.0.2/255.255.255.255
http_access allow linuxserver
http_access allow ntserver
http_access allow domainusers localhost
http_access allow CONNECT SSL_ports
http_access deny all
Por lo tanto para todo acceso web (SSL o no), el usuario necesita ser autenticado, pero SSL puede pasar en forma directa salteando DansGuardian. Tambien se le permite a los servidores NT y Linux saltear el filtrado accediendo a Squid directamente.
Metodo ipchains 1
Se pueden redireccionar conexiones entrantes al puerto 3128 desde la red local al puerto 8080 mientras se permiten conexiones de localhost a 3128. Los detalles especificos sobre esta configuracion van mas alla del objetivo de este documento.
Metodo ipchains 2 - Metodo astuto
El metodo mas astuto seria configurar a Squid como proxy transparente y redireccionar todo el trafico al puerto 80 hacia el puerto 8080. Este metodo puede convivir con el metodo 1. Recuerde que en este caso el mismo servidor squid debe ser el gateway de los clientes web. Los detalles especificos sobre esta configuracion van mas alla del objetivo de este documento. Hay un documento (en ingles) que lo explica en detalle

Configuracion del Cliente Web
Configuracion Simple
Asumiento que el servidor Linux que oficia de Web Proxy y servidor Web Intranet se encuantra en la direccion IP 192.168.0.1, y que en este mismo servidor se ha instalado DansGuardian aceptando conexiones en el puerto 8080.
El cliente web se configura especificando que el servidor proxy http esta en la IP 192.168.0.1 en el puerto 8080. Tambien puede especificar proxy para FTP a la misma direccion - se ha reportado que funciona. Eso es todo. Pero para mayor eficiencia, seria bueno especificar 'sin proxy' para la direccion local del apache - 192.168.0.1 en este caso. Si usted tiene un servidor DNS funcionando, puede especificar la direccion de su server local. Aunque yo prefiero no hacerlo.
Configuracion Astuta
Si ha implementado el metodo astuto al configurar Squid, entonces no se requiere ninguna configuracion. Configure su cliente web para no usar proxy y tambien elija la opcion 'sin proxy' para el servidor local (192.168.0.1 en este caso). Recuerde que en este caso el mismo servidor squid debe ser el gateway de los clientes web.
La Configuracion de Daniel
Este podria ser el metodo super astuto. El problema del metodo simple es que hay que configurar todos los clientes web manualmente. Es por eso que el metodo astuto es mas recomendado.
El Metodo de Daniel soluciona todos los problemas con una pequena aplicacion en Visual Basic que en el momento de ingresar el usuario al sistema, le modifica los valores necesarios en el registro de systema de Windows (system registry) de forma tal que tanto Internet Explorer o Netscape (incluyendo email) se configuren en forma automatica. Es tan bueno que simplemente puede instalar una copia del servidor Netscape en una unidad compartida y ejecutar este programa automaticamente en todas las PCs despues de la pantalla de 'login' No se necesita instalacion y es muy facil de actualizar teniendo una copia central.
Tambien tiene otras cualidades como la de remover carpetas web o hacer autoswitch de GMT/BST, datos de aplicaciones y mucho mas.
A no ser que convenza a los directores de liberar el codigo abierto, este metodo no puede ser usado sin pagar la licencia a no ser que lo escriba Usted mismo. I adivine quien escribio esta aplicacion ? Si, el autor de DansGuardian
Soporte
Ante cualquier duda, unase a la lista de correo y deje su comentario o pregunta ahi mismo.
Si prefiere que su comentario no sea publicado o si es de indole privada (por ejemplo para consultas de precios o comerciales) me puede escribir (en ingles) directamente a daniel arroba jadeb punto com.
Tambien puede obtener mas ayuda en el sitio de DansGuardian: dansguardian.org.
Sobre comentarios acerca de esta documento, envie un email (en ingles) a gb arroba dansguardian punto org o al traductor julian arroba coccia punto com

Instalación de un Proxy para windows con Squid for windows

noreply@blogger.com (Anonymous) — Fri, 21 May 2010 19:33:00 +0000

Procedimiento:

Nos descargamos el squid en su más reciente versión estable desde Squid Download
Descomprimimos el paquete con winrar en el disco local C:
La carpeta que se descomprime en C: hay que renombrarla y llamarla squid
Entramos a la carpeta C:/squid/etc y renombramos los archivos .deafult, para que siempre los tengamos originales guardados, los dejamos todos con extensión .conf
Abrimos el archivo squid.conf con nuestro editor preferido.
Allí buscamos la variable http_port podemos dejarla 3128 por defecto o poner 8080 o ambas.
Buscamos la línea cache_dir ufs c:/squid/var/cache 100 16 256 y nos aseguramos que este descomentada (sin el símbolo # al principio de la linea); también podemos aumentar el tamaño de la memoria para el almacenamiento de 100 a otro valor por ej. 1000.
Buscamos la línea visible_hostname y colocamos el nombre de nuestra máquina, si no lo sabes te vas a inicio y luego a ejecutar y tipeas msinfo32 allí verás el nombre del sistema.
Buscamos la sección de las listas de acceso, se identifican porque contienen la palabra acl, es la sección ACCESS CONTROLS del squid.conf; allí buscamos donde dice:

acl all src 0.0.0.0/0.0.0.0

acl manager proto cache_object

acl localhost src 127.0.0.1/255.255.255.255

acl to_localhost dst 127.0.0.0/8

acl SSL_ports port 443 563

acl Safe_ports port 80 # http

acl Safe_ports port 21 # ftp

acl Safe_ports port 443 563 # https, snews

acl Safe_ports port 70 # gopher

acl Safe_ports port 210 # wais

acl Safe_ports port 1025-65535 # unregistered ports

acl Safe_ports port 280 # http-mgmt

acl Safe_ports port 488 # gss-http

acl Safe_ports port 591 # filemaker

acl Safe_ports port 777 # multiling http

acl CONNECT method CONNECT

y debajo escribimos acl nuestra_red src 192.168.0.0/255.255.255.0 También podemos crear un archivo .txt y guardarlo en c:/squid/etc, en dicho archivo colocamos la o las IP que queramos que accedan a los servicios de red.

Ejemplo:

192.168.0.1

192.168.0.2

192.168.1.3

192.168.3.45 , (sólo la máquinas con estas ip accederán a Internet)

el archivo se nombra permitidos.txt y se guarda en c:/squid/etc, y entonces debajo de la línea acl CONNECT method CONNECT colocaríamos acl nuestra_red src “c:/squid/etc/permitidos.txt”; de la primera forma estaríamos dando acceso a toda la red y de esta sería acceso solo a algunas máquinas.

Buscamos la línea http_access allow manager localhost y debajo de ella agregamos: http_acess allow nuestra_red
Crear los siguientes directorios en forma manual

C:\squid\var\cache

C:\squid\var\cache0

C:\squid\var\cache1

C:\squid\var\cache2

C:\squid\var\cache3

C:\squid\var\cache4

C:\squid\var\cache5

C:\squid\var\cache6

C:\squid\var\cache7

C:\squid\var\cache8

C:\squid\var\cache9

C:\squid\var\cacheA

C:\squid\var\cacheB

C:\squid\var\cacheC

C:\squid\var\cacheD

C:\squid\var\cacheE

C:\squid\var\cacheF

O sea nos vamos al direcorio var y creamos un directorio llamado cache y luego dentro de éste creamos varios directotios nombrados de 00 hasta 0F (Esto es numeración Hexadecimal)

Ir a menú Inicio, darle clic a ejecutar y escribir cmd y darle a aceptar (esto es para abrir una consola)
Una vez en la consola escribir: c:/squid/sbin/squid –z y si todo ha salido bien no dará mensajes de error.
Luego escribir c:/squid/sbin/squid –i lo cual instalará squid como servicio de Windows xp.
Iniciar el servicio squid, ir a menú Inicio y hacer clic en ejecutar, luego escribimos services.msc y le damos clic a aceptar, esto nos abrirá la ventana de los servicios y allí buscamos a squid y lo iniciamos o reiniciamos.

De esta forma ya tendremos nuestro Proxy-cache funcionando en Windows.

Cómo configurar Squid: Parámetros básicos para Servidor Intermediario (Proxy).

noreply@blogger.com (Anonymous) — Fri, 21 May 2010 19:29:00 +0000

Introducción.

¿Qué es Servidor Intermediario (Proxy)?

El término en ingles «Proxy» tiene un significado muy general y al mismo tiempo ambiguo, aunque invariablemente se considera un sinónimo del concepto de «Intermediario». Se suele traducir, en el sentido estricto, como delegado o apoderado (el que tiene el que poder sobre otro).

Un Servidor Intermediario (Proxy) se define como una computadora o dispositivo que ofrece un servicio de red que consiste en permitir a los clientes realizar conexiones de red indirectas hacia otros servicios de red. Durante el proceso ocurre lo siguiente:

•	Cliente se conecta hacia un Servidor Intermediario (Proxy).
•	Cliente solicita una conexión, fichero u otro recurso disponible en un servidor distinto.
•	Servidor Intermediario (Proxy) proporciona el recurso ya sea conectándose hacia el servidor especificado o sirviendo éste desde un caché.
•	En algunos casos el Servidor Intermediario (Proxy) puede alterar la solicitud del cliente o bien la respuesta del servidor para diversos propósitos.

Los Servidores Intermediarios (Proxies) generalmente se hacen trabajar simultáneamente como muro cortafuegos operando en el Nivel de Red, actuando como filtro de paquetes, como en el caso de iptables, o bien operando en el Nivel de Aplicación, controlando diversos servicios, como es el caso de TCP Wrapper. Dependiendo del contexto, el muro cortafuegos también se conoce como BPD o Border Protection Device o simplemente filtro de paquetes.

Una aplicación común de los Servidores Intermediarios (Proxies) es funcionar como caché de contenido de Red (principalmente HTTP), proporcionando en la proximidad de los clientes un caché de páginas y ficheros disponibles a través de la Red en servidores HTTP remotos, permitiendo a los clientes de la red local acceder hacia éstos de forma más rápida y confiable.

Cuando se recibe una petición para un recurso de Red especificado en un URL (Uniform Resource Locator) el Servidor Intermediario busca el resultado del URL dentro del caché. Si éste es encontrado, el Servidor Intermediario responde al cliente proporcionado inmediatamente el contenido solicitado. Si el contenido solicitado no estuviera disponible en el caché, el Servidor Intermediario lo traerá desde servidor remoto, entregándolo al cliente que lo solicitó y guardando una copia en el caché. El contenido en el caché es eliminado luego a través de un algoritmo de expiración de acuerdo a la antigüedad, tamaño e historial de respuestas a solicitudes (hits) (ejemplos: LRU, LFUDA y GDSF).

Los Servidores Intermediarios para contenido de Red (Web Proxies) también pueden actuar como filtros del contenido servido, aplicando políticas de censura de acuerdo a criterios arbitrarios.

Acerca de Squid.

Squid es un Servidor Intermediario (Proxy) de alto desempeño que se ha venido desarrollando desde hace varios años y es hoy en día un muy popular y ampliamente utilizado entre los sistemas operativos como GNU/Linux y derivados de Unix®. Es muy confiable, robusto y versátil y se distribuye bajo los términos de la Licencia Pública General GNU (GNU/GPL). Siendo sustento lógico libre, está disponible el código fuente para quien así lo requiera.

Entre otras cosas, Squid puede funcionar como Servidor Intermediario (Proxy) y caché de contenido de Red para los protocolos HTTP, FTP, GOPHER y WAIS, Proxy de SSL, caché transparente, WWCP, aceleración HTTP, caché de consultas DNS y otras muchas más como filtración de contenido y control de acceso por IP y por usuario.

Squid consiste de un programa principal como servidor, un programa para búsqueda en servidores DNS, programas opcionales para reescribir solicitudes y realizar autenticación y algunas herramientas para administración y y herramientas para clientes. Al iniciar Squid da origen a un número configurable (5, de modo predefinido a través del parámetro dns_children) de procesos de búsqueda en servidores DNS, cada uno de los cuales realiza una búsqueda única en servidores DNS, reduciendo la cantidad de tiempo de espera para las búsquedas en servidores DNS.

NOTA ESPECIAL: Squid no debe ser utilizado como Servidor Intermediario (Proxy) para protocolos como SMTP, POP3, TELNET, SSH, IRC, etc. Si se requiere intermediar para cualquier protocolo distinto a HTTP, HTTPS, FTP, GOPHER y WAIS se requerirá implementar obligatoriamente un enmascaramiento de IP o NAT (Network Address Translation) o bien hacer uso de un servidor SOCKS como Dante (http://www.inet.no/dante/).

URL: http://www.squid-cache.org/

Algoritmos de caché utilizados por Squid.

A través de un parámetro (cache_replacement_policy) Squid incluye soporte para los siguientes algoritmos para el caché:

•	LRU	Acrónimo de Least Recently Used, que traduce como Menos Recientemente Utilizado. En este algoritmo los objetos que no han sido accedidos en mucho tiempo son eliminados primero, manteniendo siempre en el caché a los objetos más recientemente solicitados. Ésta política es la utilizada por Squid de modo predefinido.

•	LFUDA	Acrónimo de Least Frequently Used with Dynamic Aging, que se traduce como Menos Frecuentemente Utilizado con Envejecimiento Dinámico. En este algoritmo los objetos más solicitados permanecen en el caché sin importar su tamaño optimizando la eficiencia (hit rate) por octetos (Bytes) a expensas de la eficiencia misma, de modo que un objeto grande que se solicite con mayor frecuencia impedirá que se pueda hacer caché de objetos pequeños que se soliciten con menor frecuencia.

•	GDSF	Acrónimo de GreedyDual Size Frequency, que se traduce como Frecuencia de tamaño GreedyDual (codicioso dual), que es el algoritmo sobre el cual se basa GDSF. Optimiza la eficiencia (hit rate) por objeto manteniendo en el caché los objetos pequeños más frecuentemente solicitados de modo que hay mejores posibilidades de lograr respuesta a una solicitud (hit). Tiene una eficiencia por octetos (Bytes) menor que el algoritmo LFUDA debido a que descarta del caché objetos grandes que sean solicitado con frecuencia.

Sustento lógico necesario.

Para poder llevar al cabo los procedimientos descritos en este manual y documentos relacionados, usted necesitará tener instalado al menos lo siguiente:

•	Al menos squid-2.5.STABLE6
•	httpd-2.0.x (Apache), como auxiliar de caché con aceleración.
•	Todos los parches de seguridad disponibles para la versión del sistema operativo que esté utilizando. No es conveniente utilizar un sistema con posibles vulnerabilidades como Servidor Intermediario.

Debe tomarse en consideración que, de ser posible, se debe utilizar siempre las versiones estables más recientes de todo sustento lógico que vaya a ser instalado para realizar los procedimientos descritos en este manual, a fin de contar con los parches de seguridad necesarios. Ninguna versión de Squid anterior a la 2.5.STABLE6 se considera como apropiada debido a fallas de seguridad de gran importancia.

Squid no se instala de manera predeterminada a menos que especifique lo contrario durante la instalación del sistema operativo, sin embargo viene incluido en casi todas las distribuciones actuales. El procedimiento de instalación es exactamente el mismo que con cualquier otro sustento lógico.

Instalación a través de yum.

Si cuenta con un sistema con CentOS o White Box Enterprise Linux 3 o versiones posteriores, utilice lo siguiente y se instalará todo lo necesario junto con sus dependencias:

yum -y install squid httpd

Instalación a través de up2date.

Si cuenta con un sistema con Red Hat™ Enterprise Linux 3 o versiones posteriores, utilice lo siguiente y se instalará todo lo necesario junto con sus dependencias:

up2date -i squid httpd

Otros componentes necesarios.

El mandato iptables se utilizará para generar las reglas necesarias para el guión de Enmascaramiento de IP. Se instala de modo predefinido en todas las distribuciones actuales que utilicen núcleo (kernel) versiones 2.4 y 2.6.

Es importante tener actualizado el núcleo del sistema operativo por diversas cuestiones de seguridad. No es recomendable utilizar versiones del kernel anteriores a la 2.4.21. Actualice el núcleo a la versión más reciente disponible para su distribución.

Si cuenta con un sistema con CentOS o White Box Enterprise Linux 3 o versiones posteriores, utilice lo siguiente para actualizar el núcleo del sistema operativo e iptables, si acaso fuera necesario:

yum -y update kernel iptables

Si cuenta con un sistema con Red Hat™ Enterprise Linux 3 o versiones posteriores, utilice lo siguiente para actualizar el núcleo del sistema operativo, e iptables si acaso fuera necesario:

up2date -u kernel iptables

Antes de continuar.

Tenga en cuenta que este manual ha sido comprobado varias veces y ha funcionado en todos los casos y si algo no funciona solo significa que usted no lo leyó a detalle y no siguió correctamente las indicaciones.

Evite dejar espacios vacíos en lugares indebidos. El siguiente es un ejemplo de como no se debe habilitar un parámetro.

Mal

# Opción incorrectamente habilitada

http_port 3128

El siguiente es un ejemplo de como si se debe habilitar un parámetro.

Bien

# Opción correctamente habilitada

http_port 3128

Configuración básica.

Squid utiliza el fichero de configuración localizado en /etc/squid/squid.conf, y podrá trabajar sobre este utilizando su editor de texto simple preferido. Existen un gran número de parámetros, de los cuales recomendamos configurar los siguientes:

•	http_port
•	cache_dir
•	Al menos una Lista de Control de Acceso
•	Al menos una Regla de Control de Acceso
•	httpd_accel_host
•	httpd_accel_port
•	httpd_accel_with_proxy

Parámetro http_port: ¿Que puerto utilizar para Squid?

De acuerdo a las asignaciones hechas por IANA y continuadas por la ICANN desde el 21 de marzo de 2001, los Puertos Registrados (rango desde 1024 hasta 49151) recomendados para Servidores Intermediarios (Proxies) pueden ser el 3128 y 8080 a través de TCP.

De modo predefinido Squid utilizará el puerto 3128 para atender peticiones, sin embargo se puede especificar que lo haga en cualquier otro puerto disponible o bien que lo haga en varios puertos disponibles a la vez.

En el caso de un Servidor Intermediario (Proxy) Transparente, regularmente se utilizará el puerto 80 o el 8000 y se valdrá del re-direccionamiento de peticiones de modo tal que no habrá necesidad alguna de modificar la configuración de los clientes HTTP para utilizar el Servidor Intermediario (Proxy). Bastará con utilizar como puerta de enlace al servidor. Es importante recordar que los Servidores HTTP, como Apache, también utilizan dicho puerto, por lo que será necesario volver a configurar el servidor HTTP para utilizar otro puerto disponible, o bien desinstalar o desactivar el servidor HTTP.

Hoy en día puede no ser del todo práctico el utilizar un Servidor Intermediario (Proxy) Transparente, a menos que se trate de un servicio de Café Internet u oficina pequeña, siendo que uno de los principales problemas con los que lidian los administradores es el mal uso y/o abuso del acceso a Internet por parte del personal. Es por esto que puede resultar más conveniente configurar un Servidor Intermediario (Proxy) con restricciones por clave de acceso, lo cual no puede hacerse con un Servidor Intermediario (Proxy) Transparente, debido a que se requiere un diálogo de nombre de usuario y clave de acceso.

Regularmente algunos programas utilizados comúnmente por los usuarios suelen traer de modo predefinido el puerto 8080 (servicio de cacheo WWW) para utilizarse al configurar que Servidor Intermediario (Proxy) utilizar. Si queremos aprovechar esto en nuestro favor y ahorrarnos el tener que dar explicaciones innecesarias al usuario, podemos especificar que Squid escuche peticiones en dicho puerto también. Siendo así localice la sección de definición de http_port, y especifique:

# You may specify multiple socket addresses on multiple lines.

# Default: http_port 3128

http_port 3128

http_port 8080

Si desea incrementar la seguridad, puede vincularse el servicio a una IP que solo se pueda acceder desde la red local. Considerando que el servidor utilizado posee una IP 192.168.1.254, puede hacerse lo siguiente:

# You may specify multiple socket addresses on multiple lines.

# Default: http_port 3128

http_port 192.168.1.254:3128

http_port 192.168.1.254:8080

Parámetro cache_mem.

El parámetro cache_mem establece la cantidad ideal de memoria para lo siguiente:

•	Objetos en tránsito.
•	Objetos frecuentemente utilizados (Hot).
•	Objetos negativamente almacenados en el caché.

Los datos de estos objetos se almacenan en bloques de 4 Kb. El parámetro cache_mem especifica un límite máximo en el tamaño total de bloques acomodados, donde los objetos en tránsito tienen mayor prioridad. Sin embargo los objetos Hot y aquellos negativamente almacenados en el caché podrán utilizar la memoria no utilizada hasta que esta sea requerida. De ser necesario, si un objeto en tránsito es mayor a la cantidad de memoria especificada, Squid excederá lo que sea necesario para satisfacer la petición.

De modo predefinido se establecen 8 MB. Puede especificarse una cantidad mayor si así se considera necesario, dependiendo esto de los hábitos de los usuarios o necesidades establecidas por el administrador.

Si se posee un servidor con al menos 128 MB de RAM, establezca 16 MB como valor para este parámetro:

cache_mem 16 MB

Parámetro cache_dir: ¿Cuanto desea almacenar de Internet en el disco duro?

Este parámetro se utiliza para establecer que tamaño se desea que tenga el caché en el disco duro para Squid. Para entender esto un poco mejor, responda a esta pregunta: ¿Cuanto desea almacenar de Internet en el disco duro? De modo predefinido Squid utilizará un caché de 100 MB, de modo tal que encontrará la siguiente línea:

cache_dir ufs /var/spool/squid 100 16 256

Se puede incrementar el tamaño del caché hasta donde lo desee el administrador. Mientras más grande sea el caché, más objetos se almacenarán en éste y por lo tanto se utilizará menos el ancho de banda. La siguiente línea establece un caché de 700 MB:

cache_dir ufs /var/spool/squid 700 16 256

Los números 16 y 256 significan que el directorio del caché contendrá 16 directorios subordinados con 256 niveles cada uno. No modifique esto números, no hay necesidad de hacerlo.

Es muy importante considerar que si se especifica un determinado tamaño de caché y éste excede al espacio real disponible en el disco duro, Squid se bloqueará inevitablemente. Sea cauteloso con el tamaño de caché especificado.

Parámetro ftp_user.

Al acceder a un servidor FTP de manera anónima, de modo predefinido Squid enviará como clave de acceso Squid@. Si se desea que el acceso anónimo a los servidores FTP sea más informativo, o bien si se desea acceder a servidores FTP que validan la autenticidad de la dirección de correo especificada como clave de acceso, puede especificarse la dirección de correo electrónico que uno considere pertinente.

ftp_user proxy@su-dominio.net

Controles de acceso.

Es necesario establecer Listas de Control de Acceso que definan una red o bien ciertas máquinas en particular. A cada lista se le asignará una Regla de Control de Acceso que permitirá o denegará el acceso a Squid. Procedamos a entender como definir unas y otras.

Listas de control de acceso.

Regularmente una lista de control de acceso se establece con la siguiente sintaxis:

acl [nombre de la lista] src [lo que compone a la lista]

Si se desea establecer una lista de control de acceso que abarque a toda la red local, basta definir la IP correspondiente a la red y la máscara de la sub-red. Por ejemplo, si se tiene una red donde las máquinas tienen direcciones IP 192.168.1.n con máscara de sub-red 255.255.255.0, podemos utilizar lo siguiente:

acl miredlocal src 192.168.1.0/255.255.255.0

También puede definirse una Lista de Control de Acceso especificando un fichero localizado en cualquier parte del disco duro, y la cual contiene una lista de direcciones IP. Ejemplo:

acl permitidos src "/etc/squid/permitidos"

El fichero /etc/squid/permitidos contendría algo como siguiente:

192.168.1.1

192.168.1.2

192.168.1.3

192.168.1.15

192.168.1.16

192.168.1.20

192.168.1.40

Lo anterior estaría definiendo que la Lista de Control de Acceso denominada permitidos estaría compuesta por las direcciones IP incluidas en el fichero /etc/squid/permitidos.

Reglas de Control de Acceso.

Estas definen si se permite o no el acceso hacia Squid. Se aplican a las Listas de Control de Acceso. Deben colocarse en la sección de reglas de control de acceso definidas por el administrador, es decir, a partir de donde se localiza la siguiente leyenda:

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

La sintaxis básica es la siguiente:

http_access [deny o allow] [lista de control de acceso]

En el siguiente ejemplo consideramos una regla que establece acceso permitido a Squid a la Lista de Control de Acceso denominada permitidos:

http_access allow permitidos

También pueden definirse reglas valiéndose de la expresión !, la cual significa no. Pueden definirse, por ejemplo, dos listas de control de acceso, una denominada lista1 y otra denominada lista2, en la misma regla de control de acceso, en donde se asigna una expresión a una de estas. La siguiente establece que se permite el acceso a Squid a lo que comprenda lista1 excepto aquello que comprenda lista2:

http_access allow lista1 !lista2

Este tipo de reglas son útiles cuando se tiene un gran grupo de IP dentro de un rango de red al que se debe permitir acceso, y otro grupo dentro de la misma red al que se debe denegar el acceso.

Aplicando Listas y Reglas de control de acceso.

Una vez comprendido el funcionamiento de la Listas y las Regla de Control de Acceso, procederemos a determinar cuales utilizar para nuestra configuración.

Caso 1.

Considerando como ejemplo que se dispone de una red 192.168.1.0/255.255.255.0, si se desea definir toda la red local, utilizaremos la siguiente línea en la sección de Listas de Control de Acceso:

acl todalared src 192.168.1.0/255.255.255.0

Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo:

Listas de Control de Acceso: definición de una red local completa

# Recommended minimum configuration:

acl all src 0.0.0.0/0.0.0.0

acl manager proto cache_object

acl localhost src 127.0.0.1/255.255.255.255

acl todalared src 192.168.1.0/255.255.255.0

A continuación procedemos a aplicar la regla de control de acceso:

http_access allow todalared

Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de este modo:

Reglas de control de acceso: Acceso a una Lista de Control de Acceso.

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

http_access allow localhost

http_access allow todalared

http_access deny all

La regla http_access allow todalared permite el acceso a Squid a la Lista de Control de Acceso denominada todalared, la cual está conformada por 192.168.1.0/255.255.255.0. Esto significa que cualquier máquina desde 192.168.1.1 hasta 192.168.1.254 podrá acceder a Squid.

Caso 2.

Si solo se desea permitir el acceso a Squid a ciertas direcciones IP de la red local, deberemos crear un fichero que contenga dicha lista. Genere el fichero /etc/squid/listas/redlocal, dentro del cual se incluirán solo aquellas direcciones IP que desea confirmen la Lista de Control de acceso. Ejemplo:

192.168.1.1

192.168.1.2

192.168.1.3

192.168.1.15

192.168.1.16

192.168.1.20

192.168.1.40

Denominaremos a esta lista de control de acceso como redlocal:

acl redlocal src "/etc/squid/listas/redlocal"

Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo:

Listas de Control de Acceso: definición de una red local completa

# Recommended minimum configuration:

acl all src 0.0.0.0/0.0.0.0

acl manager proto cache_object

acl localhost src 127.0.0.1/255.255.255.255

acl redlocal src "/etc/squid/listas/redlocal"

A continuación procedemos a aplicar la regla de control de acceso:

http_access allow redlocal

Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de este modo:

Reglas de control de acceso: Acceso a una Lista de Control de Acceso.

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

http_access allow localhost

http_access allow redlocal

http_access deny all

La regla http_access allow redlocal permite el acceso a Squid a la Lista de Control de Acceso denominada redlocal, la cual está conformada por las direcciones IP especificadas en el fichero /etc/squid/listas/redlocal. Esto significa que cualquier máquina no incluida en /etc/squid/listas/redlocal no tendrá acceso a Squid.

Parámetro chache_mgr.

De modo predefinido, si algo ocurre con el caché, como por ejemplo que muera el procesos, se enviará un mensaje de aviso a la cuenta webmaster del servidor. Puede especificarse una distinta si acaso se considera conveniente.

cache_mgr joseperez@midominio.net

Parámetro cache_peer: caches padres y hermanos.

El parámetro cache_peer se utiliza para especificar otros Servidores Intermediarios (Proxies) con caché en una jerarquía como padres o como hermanos. Es decir, definir si hay un Servidor Intermediario (Proxy) adelante o en paralelo. La sintaxis básica es la siguiente:

cache_peer servidor tipo http_port icp_port opciones

Ejemplo: Si su caché va a estar trabajando detrás de otro servidor cache, es decir un caché padre, y considerando que el caché padre tiene una IP 192.168.1.1, escuchando peticiones HTTP en el puerto 8080 y peticiones ICP en puerto 3130 (puerto utilizado de modo predefinido por Squid) ,especificando que no se almacenen en caché los objetos que ya están presentes en el caché del Servidor Intermediario (Proxy) padre, utilice la siguiente línea:

cache_peer 192.168.1.1 parent 8080 3130 proxy-only

Cuando se trabaja en redes muy grandes donde existen varios Servidores Intermediarios (Proxy) haciendo caché de contenido de Internet, es una buena idea hacer trabajar todos los caché entre si. Configurar caches vecinos como sibling (hermanos) tiene como beneficio el que se consultarán estos caches localizados en la red local antes de acceder hacia Internet y consumir ancho de banda para acceder hacia un objeto que ya podría estar presente en otro caché vecino.

Ejemplo: Si su caché va a estar trabajando en paralelo junto con otros caches, es decir caches hermanos, y considerando los caches tienen IP 10.1.0.1, 10.2.0.1 y 10.3.0.1, todos escuchando peticiones HTTP en el puerto 8080 y peticiones ICP en puerto 3130, especificando que no se almacenen en caché los objetos que ya están presentes en los caches hermanos, utilice las siguientes líneas:

cache_peer 10.1.0.1 sibling 8080 3130 proxy-only

cache_peer 10.2.0.1 sibling 8080 3130 proxy-only

cache_peer 10.3.0.1 sibling 8080 3130 proxy-only

Pueden hacerse combinaciones que de manera tal que se podrían tener caches padres y hermanos trabajando en conjunto en una red local. Ejemplo:

cache_peer 10.0.0.1 parent 8080 3130 proxy-only

cache_peer 10.1.0.1 sibling 8080 3130 proxy-only

cache_peer 10.2.0.1 sibling 8080 3130 proxy-only

cache_peer 10.3.0.1 sibling 8080 3130 proxy-only

Caché con aceleración.

Cuando un usuario hace petición hacia un objeto en Internet, este es almacenado en el caché de Squid. Si otro usuario hace petición hacia el mismo objeto, y este no ha sufrido modificación alguna desde que lo accedió el usuario anterior, Squid mostrará el que ya se encuentra en el caché en lugar de volver a descargarlo desde Internet.

Esta función permite navegar rápidamente cuando los objetos ya están en el caché de Squid y además optimiza enormemente la utilización del ancho de banda.

La configuración de Squid como Servidor Intermediario (Proxy) Transparente solo requiere complementarse utilizando una regla de iptables que se encargará de re-direccionar peticiones haciéndolas pasar por el puerto 8080. La regla de iptables necesaria se describe más adelante en este documento.

Proxy Acelerado: Opciones para Servidor Intermediario (Proxy) en modo convencional.

En la sección HTTPD-ACCELERATOR OPTIONS deben habilitarse los siguientes parámetros:

httpd_accel_host virtual

httpd_accel_port 0

httpd_accel_with_proxy on

Proxy Acelerado: Opciones para Servidor Intermediario (Proxy) Transparente.

Si se trata de un Servidor Intermediario (Proxy) transparente, deben utilizarse las siguientes opciones, considerando que se hará uso del caché de un servidor HTTP (Apache) como auxiliar:

# Debe especificarse la IP de cualquier servidor HTTP en la

# red local o bien el valor virtual

httpd_accel_host 192.168.1.254

httpd_accel_port 80

httpd_accel_with_proxy on

httpd_accel_uses_host_header on

Proxy Acelerado: Opciones para Servidor Intermediario (Proxy) Transparente para redes con Internet Exlorer 5.5 y versiones anteriores.

Si va a utilizar Internet Explorer 5.5 y versiones anteriores con un Servidor Intermediario (Proxy) transparente, es importante recuerde que dichas versiones tiene un pésimo soporte con los Servidores Intermediarios (Proxies) transparentes imposibilitando por completo la capacidad de refrescar contenido. Si se utiliza el parámetro ie_refresh con valor on puede hacer que se verifique en los servidores de origen para nuevo contenido para todas las peticiones IMS-REFRESH provenientes de Internet Explorer 5.5 y versiones anteriores.

# Debe especificarse la IP de cualquier servidor HTTP en la

# red local

httpd_accel_host 192.168.1.254

httpd_accel_port 80

httpd_accel_with_proxy on

httpd_accel_uses_host_header on

ie_refresh on

Lo más conveniente es actualizar hacia Internet Explorer 6.x o definitivamente optar por otras alternativas. Mozilla es en un conjunto de aplicaciones para Internet, o bien Firefox, que es probablemente el mejor navegador que existe en el mercado. Firefox es un navegador muy ligero y que cumple con los estándares, y está disponible para Windows, Linux, Mac OS X y otros sistemas operativos.

Estableciendo el idioma de los mensajes mostrados por de Squid hacia el usuario.

Squid incluye traducción a distintos idiomas de las distintas páginas de error e informativas que son desplegadas en un momento dado durante su operación. Dichas traducciones se pueden encontrar en /usr/share/squid/errors/. Para poder hacer uso de las páginas de error traducidas al español, es necesario cambiar un enlace simbólico localizado en /etc/squid/errors para que apunte hacia /usr/share/squid/errors/Spanish en lugar de hacerlo hacia /usr/share/squid/errors/English.

Elimine primero el enlace simbólico actual:

rm -f /etc/squid/errors

Coloque un nuevo enlace simbólico apuntando hacia el directorio con los ficheros correspondientes a los errores traducidos al español.

ln -s /usr/share/squid/errors/Spanish /etc/squid/errors

Nota: Este enlace simbólico debe verificarse, y regenerarse de ser necesario, cada vez que se actualizado Squid ya sea a través de yum, up2date o manualmente con el mandato rpm.

Iniciando, reiniciando y añadiendo el servicio al arranque del sistema.

Una vez terminada la configuración, ejecute el siguiente mandato para iniciar por primera vez Squid:

service squid start

Si necesita reiniciar para probar cambios hechos en la configuración, utilice lo siguiente:

service squid restart

Si desea que Squid inicie de manera automática la próxima vez que inicie el sistema, utilice lo siguiente:

chkconfig squid on

Lo anterior habilitará a Squid en todos los niveles de corrida.

Depuración de errores

Cualquier error al inicio de Squid solo significa que hubo errores de sintaxis, errores de dedo o bien se están citando incorrectamente las rutas hacia los ficheros de las Listas de Control de Acceso.

Puede realizar diagnóstico de problemas indicándole a Squid que vuelva a leer configuración, lo cual devolverá los errores que existan en el fichero /etc/squid/squid.conf.

service squid reload

Cuando se trata de errores graves que no permiten iniciar el servicio, puede examinarse el contenido del fichero /var/log/squid/squid.out con el mandato less, more o cualquier otro visor de texto:

less /var/log/squid/squid.out

Ajustes para el muro corta-fuegos.

Si se tiene poca experiencia con guiones de cortafuegos a través de iptables, sugerimos utilizar Firestarter. éste permite configurar fácilmente tanto el enmascaramiento de IP como el muro corta-fuegos. Si se tiene un poco más de experiencia, recomendamos utilizar Shorewall para el mismo fin puesto que se trata de una herramienta más robusta y completa.

•	Firestarter: http://www.fs-security.com/
•	Shorewall: http://www.shorewall.net/

Re-direccionamiento de peticiones a través de iptables y Firestarter.

En un momento dado se requerirá tener salida transparente hacia Internet para ciertos servicios, pero al mismo tiempo se necesitará re-direccionar peticiones hacia servicio HTTP para pasar a través del el puerto donde escucha peticiones Squid (8080), de modo que no haya salida alguna hacia alguna hacia servidores HTTP en el exterior sin que ésta pase antes por Squid. No se puede hacer Servidor Intermediario (Proxy) Transparente para los protocolos HTTPS, FTP, GOPHER ni WAIS, por lo que dichos protocolos tendrán que ser filtrados a través del NAT.

El re-direccionamiento lo hacemos a través de iptables. Considerando para este ejemplo que la red local se accede a través de una interfaz eth0, el siguiente esquema ejemplifica un re-direccionamiento:

/sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Lo anterior, que requiere un guión de cortafuegos funcional en un sistema con dos interfaces de red, hace que cualquier petición hacia el puerto 80 (servicio HTTP) hecha desde la red local hacia el exterior, se re-direccionará hacia el puerto 8080 del servidor.

Utilizando Firestarter, la regla anteriormente descrita se añade en el fichero /etc/firestarter/user-post.

Re-direccionamiento de peticiones a través de la opción REDIRECT en Shorewall.

La acción REDIRECT en Shorewall permite redirigir peticiones hacia protocolo HTTP para hacerlas pasar a través de Squid. En el siguiente ejemplo las peticiones hechas desde la zona que corresponde a la red local serán redirigidas hacia el puerto 8080 del cortafuegos, en donde está configurado Squid configurado como Servidores Intermediario (Proxy) transparente.

#ACTION SOURCE DEST PROTO DEST

REDIRECT loc 8080 tcp 80

Fedora 12 "Lo Nuevo y Mejorado"

noreply@blogger.com (Anonymous) — Sat, 01 May 2010 21:22:00 +0000

Guía del usuario

Utilizando Fedora 12 para realizar tareas comunes en un equipo de escritorio

Edición 1.0

Fedora Proyecto de Documentación

fedora-docs-list@redhat.com

aviso legal

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

For guidelines on the permitted uses of the Fedora trademarks, refer to https://fedoraproject.org/wiki/Legal:Trademark_guidelines.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

All other trademarks are the property of their respective owners.

Resumen

La guía del usuario Fedora está pensada para que los usuarios finales puedan realizar tareas de computación relativamente sencillas, como por ejemplo navegar por la web, leer y enviar correos electrónicos, o utilizar el equipo para tareas propias de ámbitos laborales, pasatiempos o estudios.

Prefacio

1. Convenciones del documento

1.1. Convenciones tipográficas
1.2. Convenciones del documento
1.3. Notas y advertencias

2. ¡Necesitamos sus comentarios!

Introducción

1. Acerca de este documento

1. Los escritorios de Fedora

2. Ingresando al escritorio

2.1. Ingresando
2.2. Ingresando: una explicación técnica
2.3. No puedo ingresar: ¡AYUDA!

3. Paseo por el escritorio de GNOME

3.1. El escritorio de GNOME

3.1.1. El panel del menú principal
3.1.2. El área de escritorio
3.1.3. El panel de lista de ventanas

4. Paseo por el escritorio de KDE

4.1. El escritorio de KDE

4.2. El área de escritorio de KDE

4.3. El panel de KDE

4.3.1. El Lanzador de Aplicaciones

5. Paseo por el escritorio de Xfce

5.1. El escritorio de Xfce 4

5.1.1. El panel de menú de Xfce 4
5.1.2. El área de escritorio de Xfce 4
5.1.3. El panel de lista de ventanas de Xfce 4

6. Medios

6.1. Imágenes ISO

6.2. Escritura de CDs o DVDs

6.2.1. Utilizando CD/DVD Creator para quemar discos en GNOME
6.2.2. Utilizando K3b para quemar discos en KDE
6.2.3. Usando GnomeBaker en GNOME

6.3. Creación de un medio USB autoiniciable

6.3.1. Creación de una Imagen USB en Windows
6.3.2. Creación de la imagen USB en Fedora

7. Conectando a Internet

7.1. GNOME
7.2. KDE
7.3. Configurando PPPoE
7.4. Conexión DHCP
7.5. Dirección IP estática
7.6. NetworkManager
7.7. Inalámbrico
7.8. Escritorio remoto

8. Accediendo a la Web

8.1. Navegando páginas web

8.1.1. Usando Firefox
8.1.2. Usando Konqueror

8.2. Transferir archivos

8.2.1. Usando FileZilla
8.2.2. FTP por la línea de comandos

9. Comunicaciones

9.1. Evolution

9.1.1. Configuración de Evolution
9.1.2. Usando Evolution

9.2. Thunderbird

9.2.1. Configuración de Thunderbird
9.2.2. Moviendo los datos de Thunderbird desde Windows a Fedora
9.2.3. Usando Thunderbird

9.3. Claws Mail

9.3.1. Configuración de Claws Mail
9.3.2. Uso de Claws Mail

9.4. KMail

9.4.1. Configuración de Kmail
9.4.2. Usando Kmail

9.5. Pidgin

9.5.1. Configurando Pidgin
9.5.2. Usando Pidgin

9.6. Kopete

9.6.1. Configurando Kopete

9.7. XChat

9.7.1. Configurando XChat
9.7.2. Usando XChat

9.8. Konversation

9.8.1. Configurando Konversation
9.8.2. Usando Konversation

9.9. ChatZilla

9.9.1. Instalando ChatZilla
9.9.2. Configurando ChatZilla
9.9.3. Usando ChatZilla

10. Herramientas de Oficina

10.1. Aplicaciones OpenOffice.org

10.1.1. OpenOffice.org Impress
10.1.2. OpenOffice.org Calc
10.1.3. OpenOffice.org Writer

10.2. KOffice

10.2.1. KPresenter
10.2.2. KSpread
10.2.3. KWord

10.3. Aplicaciones de oficina de Gnome

10.3.1. AbiWord
10.3.2. Gnumeric
10.3.3. gLabels

11. Software Financiero

11.1. GnuCash

11.1.1. Configuración de GnuCash
11.1.2. Uso de GnuCash
11.1.3. Configurar acceso a bancos en línea

11.2. KMyMoney

11.2.1. Configuración de KMyMoney
11.2.2. Uso de KMyMoney
11.2.3. Configurar acceso a bancos en línea

12. Reproducción multimedia

12.1. La posición del Proyecto Fedora frente al soporte multimedia

12.2. Cheese Webcam Booth

12.2.1. Uso de Cheese Webcam Booth

12.3. Reproductor de Música Rhythmbox

12.3.1. Uso del reproductor de música Rhythmbox

12.4. Extractor de CD de Audio (Sound Juicer)

12.4.1. Uso de Sound Juicer

12.5. Grabadora de Sonido (Sound Recorder)

12.5.1. Usando la Grabadora de Sonido

12.6. Reproductor de Películas Totem

12.6.1. Uso del reproductor de películas Totem

12.7. Aplicaciones multimedia de GNOME

12.7.1. Creador de CD/DVD

12.8. Aplicaciones multimedia para GNOME en el repositorio

12.8.1. Brasero
12.8.2. GNOMEBaker

12.9. Aplicaciones multimedia de KDE

12.9.1. Amarok
12.9.2. Reproductor Dragon
12.9.3. JuK
12.9.4. Kaffeine
12.9.5. KMix
12.9.6. KsCD

12.10. Programas Multimedia en el Repositorio

12.10.1. K3b

12.11. Reproductores MP3

12.11.1. Grip
12.11.2. Conectividad iPod

12.12. Información Adicional

13. Juegos

13.1. Juegos de GNOME predeterminados
13.2. Juegos predeterminados de KDE

14. Administración de fotografías

14.1. Conexión de su cámara

14.2. Administrando sus fotografías en un escritorio GNOME

14.2.1. Organización e importación de fotografías

14.3. Administrando fotografías en un escritorio KDE

14.3.1. Importación de fotografías con digiKam
14.3.2. Organización de las fotografías con digiKam

15. Compartiendo su escritorio

15.1. GNOME
15.2. KDE
15.3. Otros escritorios

16. Personalización del escritorio

16.1. Cambio del tema

16.1.1. Cambio del tema en GNOME
16.1.2. Cambio del tema en KDE

16.2. Cambio del fondo

16.2.1. Cambio del fondo en GNOME
16.2.2. Cambio del fondo en KDE

16.3. Personalizando el comportamiento del navegador de archivos

16.3.1. Personalizando el comportamiento de navegación de archivos en GNOME
16.3.2. Personalizar el comportamiento de navegación de archivos en KDE

16.4. Compiz-Fusion

16.5. Widgets

16.5.1. GDesklets
16.5.2. Plasmoides de KDE

17. Administración del software

17.1. Uso de PackageKit

17.1.1. Instalación del software
17.1.2. Eliminación del software

17.2. Usando la interfaz de líneas de comando

17.2.1. Instalación del software
17.2.2. Eliminación del software

17.3. Yum Avanzado

17.3.1. Instalar nuevo software mediante Yum
17.3.2. Actualización del software con Yum
17.3.3. Eliminación de software con Yum

A. Contribuyentes y métodos de producción

A.1. Contribuyentes
A.2. Métodos de Producción

B. Historia de Revisiones

Problemas con Modem3G ZTE MF636 y Fedora 12

noreply@blogger.com (Anonymous) — Sat, 01 May 2010 21:17:00 +0000

Hace algun tiempo publique un post sobre lo bonito que estaba Fedora 12 y el modem3G, luego publique otro post donde exponia una solucion a un problema que he encontrado. Ahora tengo un par de cosas más que agregar, dos problemas… uno de ellos con solución.

El primer problema que me encontre es que luego de viajar mi modem3G no funciona. Una cosa no esta directamente relacionada con la otra. Pero me tomo tiempo entre la última vez que use mi modem3G y las siguiente vez porque estuve viajando. En medio de eso hice actualizaciones de mi laptop. Yo siempre hago las actualizaciones, será momento de cambiar de hábitos?

La cosa es que traté usando los kernel viejos que tengo en el menu del grub y nada. Tambien probé con un disco de Fedora 13 Alfa y tampoco funcionó. Revertí los cambios que habia echo el en post de troubleshooting, y nada. Me dice:

usb 1-3: new high speed USB device using ehci_hcd and address 8
usb 1-3: New USB device found, idVendor=19d2, idProduct=2000
usb 1-3: New USB device strings: Mfr=3, Product=2, SerialNumber=4
usb 1-3: Product: ZTE CDMA Technologies MSM
usb 1-3: Manufacturer: ZTE,Incorporated
usb 1-3: SerialNumber: 1234567890ABCDEF
usb 1-3: configuration #1 chosen from 1 choice
scsi8 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 8
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 8:0:0:0: CD-ROM ZTE USB SCSI CD-ROM 2.31 PQ: 0 ANSI: 2
sr1: scsi-1 drive
sr 8:0:0:0: Attached scsi CD-ROM sr1
sr 8:0:0:0: Attached scsi generic sg2 type 5

Pero no me aparece el icono en la pantalla y si le digo: “eject sr1″ me dice que:

eject: unable to find or open device for: `sr1′

Escribi en Fedora Forum, pero aun no he tenido respuesta sobre esto.

La otra cosa que hice fue cargar un liveCD de Fedora 12. Total antes me habia funcionado bien. Resulta ser que me encontre otro problema al usar el liveCD. Este otro problema es distinto a lo que habia reportado anteriormente.

La situación es que cargo el liveCD (Gnome), conecto el modem, expulso el icono que aparece en el escritorio, espero por que el NetworkManager encuentre el modem3G, configuro la conexión, intenta conectarse y la conexión falla. Vuelvo a intenatr y el intento de conexión falla de inmediato.

La solución: Desconectar físicamente el modem3G, volverlo a conectar, expulsar el icono del escritorio, esperar a que NetworkManager detecte el modem3G, decirle que se conecte a la conexión por defecto (la que se habia configurado anteriormente).

Asi es como estoy escribiendo este post. Parece que hay un problema para reconectar, y entonces al fisicamente desconectar el modem y volverlo a conectar funciona. Lo mismo me pasa si pierdo la conexión. Debo fisicamente desconectar el modem3G y volverlo a conectar.

Parece un problema de comunicación… entre el equipo de NetworkManager y el equipo que maneja udev para el reconocimiento de hardware.

Tengo fe que pronto estará resuelto, cada nueva versión trae mejoras. Espero que los datos que aporto les sean útiles.

Esta informacion fue probista por el compañero Linuxero Neville Cross.

Como instalar los repositorios Free y non-free de livna en Fedora 10 y 11.

noreply@blogger.com (Anonymous) — Thu, 18 Jun 2009 14:59:00 +0000

Que tal amigos y compañeros linuxeros aca les enseñare como montar los repos free y nonfree de livna.

Podremos hacerlo desde el sitio oficial de livna o desde consola

Desde el sitio.

para los free.

Esta es para las versiones de fedora 10 y 11.

http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm

2. Para los nonfree.

Esta es para las versiones de fedora 10 y 11.

http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

Para hacerlo desde consola solo debemos abrir el terminal, usamos el ejecutador de aplicacion para abrirlo mas rapido, en el escribimos gnome-terminal si usamos gnome, si usamos kde escribimos kterminal o konsole.

Una vez que ejecutamos nuestra terminal nos logeamos como super usuarios "su", escribimos.

su -c 'rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm'

Esto sirve para ambos, ya de una sola vez instalamos los dos.

Bueno nos vemos que la pasen bien.

Flisol 2009 en la UNI-IES

noreply@blogger.com (Anonymous) — Fri, 24 Apr 2009 15:35:00 +0000

Les hago la invitación a participar el dia sabado 25 de Abril del 2009 en el FLISOL 2009, este es un evento que se realiza cada año a nivel Latino Americano, en cual se brindaran conferencias e instalaciones conserniente a linux, sin importar la distribución, este evento es bastante educactivo y de mucha importancia para todos, pero mas aun para estudiastes de las carreras informaticas como son: Sistemas, Computación, Telecomunicaciones, Diseño grafico(Publicitario y pagina web).

Venga aprendan y diviertance :D acuerdate "El Conocimiento es Poder"

Curso de Cisco System y Examenes

noreply@blogger.com (Anonymous) — Mon, 20 Apr 2009 14:35:00 +0000

Hola como les va estimados lectores aca les dejo unos capitulos del primer modulo de Cisco System, mas adelante les estare subiendo mas modulos.

Descargar Primer modulo
Descargar Segundo Modulo

Aca les dejo los examenes completos de la curricula 4 de CCNA Eploration para su estudio

Descargar Examenes Primer modulo

Ojo: No me hago responsable si lo usan para otras cosas que no sea de estudio.

El segundo modulo se encuentra en formato de Microsoft Offices 2007 por si tienen una version anterior busquen el patch para que lo puedan abrir, todos los modulos vienen completos.

Aca les dejo unos videos instructivos

Configuración de RIP

Primera Parte

Segunda parte

Celebrando el Flisol 2009

noreply@blogger.com (Anonymous) — Wed, 08 Apr 2009 18:24:00 +0000

Amigos linuxeros y no linuxeros, les invito cordialmente a la celebración del Flisol 2009, el cual se llevara acabo en la Universidad Nacional De Ingenieria UNI, estaremos brindando conferencias, instalaciones, talleres, charlas, despejaremos cualquier duda que tengan.

Ven a esta magna celebración que se realiza en cada uno de los paises de este bello planeta, disfruta de la compañia de chavos y chavas de tu misma edad que estaran dispuesto a brindarte un poco del conocimiento que tiene, no es necesario que sepas de informatica, ven y a prende cosas nuevas.

Este Sabado 25 de Abril en La UNI estaremos desde las 8 am a las 5 pm, no faltes.

Descargar Radmin v3.2

noreply@blogger.com (Anonymous) — Mon, 16 Mar 2009 05:23:00 +0000

Software de control remoto rápido y fiable para el acceso remoto seguro a PC desde cualquier parte.

Sistemas operativos soportados: Windows Vista/XP/2008/2003/2000 (32-bit, 64-bit)

Radmin es el software de control remoto seguro premiado y reconocido en todo el mundo, que permite trabajar sobre un equipo remoto en tiempo real como si estuviera en su propio teclado y ratón. Este programa es la solución de acceso remoto ideal. Radmin supera en rendimiento al resto de controles remotos en velocidad, fiabilidad y seguridad.

Principales características

Control remoto
Visualización remota
Transferencia de archivos
Charla de voz y texto
Encendido, reinicio, acceso a la configuración de BIOS remoto de un equipo remoto con el NUEVO soporte Intel® AMT.
Funciona a través de Internet o LAN

Con Radmin es posible

Acceder y controlar su equipo de oficina o doméstico de forma remota desde cualquier parte
Administración de sistemas de forma remota
Ofrecer funciones Help Desk (soporte remoto) para usuarios remotos
Trabajar desde casa de forma remota
Gestionar de forma remota redes grandes, medianas y pequeñas
Organizar conferencias y presentaciones en línea
Compartir el escritorio
Dar clases y controlar actividades escolares de forma remota.

Descargar Radmin version Español dame un clic
Descargar Radmin version Inglesh dame un clic
Descargar Manual de usuario dame un clic
Descargar Crack dame un clic

Elissa

noreply@blogger.com (Anonymous) — Tue, 10 Mar 2009 15:00:00 +0000

Elisa es un centro multimedia de código abierto muy atractivo gráficamente con el que ver nuestras fotografías, películas y música, ya esté en nuestro disco duro, DVD, en una red compartida, o en nuestra cámara, disco externo o Ipod.

Soporta los formatos más usados gracias al uso de GStreamer, y puede reproducir nuestro propio contenido o acceder a contenido en línea, permitiendo también el acceso remoto.

Su entorno es muy accesible, con detalles gráficos muy conseguidos, como reproducir música mientras ves las carátulas de tus discos o escoger cómo serán las presentaciones de tu colección de imágenes.

Sin embargo, para poder usar Elisa necesitas un equipo potente y satisfacer una larga lista de dependencias.

Elisa soporta los siguientes formatos:

MP3, AVI, DivX, OGG, FLV, WMV, WMA, MPEG-1, MPEG-2, MPEG-3, MPEG-4, MOV

Cambios recientes en Elisa:

Búsqueda mejorada al escanear carpetas de música
Arreglado un error que impedía ver los vídeos más recientes de YouTube
Ahora Yes.fm muestra el título de la canción anterior

Para utilizar Elisa necesitas:

Sistema operativo: X11

Requisitos mínimos:

Python 2.4
python2.4-dev
python-setuptools
python-imaging
python-twisted 2.2
python-twisted-web
python-gnome2-extras
python-pysqlite2
python-gtk2
GStreamer 0.10 y vinculaciones Python
Pigment 0.3.3 y vinculaciones Python
xdg-user-dirs
python-xdg
Coherence (para soporte UPnP)
python-elementtree y python-celementtree (para descarga de carátulas vía Amazon)
gstreamer-plugins-bad, streamer-plugins-ugly y gstreamer-ffmpeg (opcionales)
lirc, liblircclient0 y pylirc (soporte lirc)
PythonDAAP, dbus, python-dbus, avahi y python-avahi (soporte DAAP)
libgpod, python-gpod, hal y python-dbus (soporte iPod)

Descarga Elissa dando clic

Linux Mint

noreply@blogger.com (Anonymous) — Tue, 10 Mar 2009 14:29:00 +0000

Linux Mint es una distribución de elegante diseño y muy fácil de usar basada en la popular Ubuntu, pero a la que poco tiene que envidiar.

Dispone de las últimas versiones de las aplicaciones más conocidas e incorpora Compiz Fusion, indexado de archivos, el buscador Tracker, Adept Manager y, ahora, entorno KDE.

En Linux Mint encontraremos programas como Amarok, Firefox, OpenOffice, Kopete, KTorrent, Konversation, KMyMoney, MPlayer, Kaffeine o Envy. Además, incorpora un buscador de aplicaciones, que enlaza con su propio portal, y mintUpdate, que avisa de nuevas versiones de programas ya instalados e indica la prioridad de la actualización.

Esta versión de Linux Mint incorpora las principales herramientas y aplicaciones del entorno KDE, además de MintAssistant y el Panel de Control de KDE para personalizar el sistema.

Podemos probarlo como LiveDVD o instalarlo en nuestro disco duro con la ayuda de un intuitivo asistente y soporte para múltiples idiomas.

Una distribución recomendable para primerizos que quieran tener un sistema operativo robusto y elegante, ahora con el aspecto KDE y un entorno oscuro y azulado distinto a su clásico verde menta.

Cambios recientes en Linux Mint:

Sistema de actualizaciones MintUpdate renovado
Instalador MintInstall mejorado
Optimización del uso de memoria
Soporte de traducciones mejorado
Se han añadido más paquetes al repositorio CNR

Para utilizar Linux Mint necesitas:

Sistema operativo: Consola/X11

Deceas mas información visita el sitio web oficial dando clic
Deceas ayuda sobre esta version de linux visita el foro dando clic
Deceas informacion en ingleas dame clic

Imagenes del sistema

Como instalar AppServ: php+mysql+apache sobre Windows

noreply@blogger.com (Anonymous) — Tue, 10 Mar 2009 05:47:00 +0000

Muchos nuevos linuxeros han preguntado de como practicar bajo windows, aqui se deja una pequena guia y el software que pueden utilizar bajo windows.

AppServ es un software que nos permite instalar sobre Windows Apache, PHP, MySQL y phpMyAdmin (interfaz gráfica para adminsitrar MySQL) de forma conjunta. Es una aplicación muy útil para empezar a familiarizarnos con Gestores de Contenidos, aprender a configurarlos e instalarlos, ya que nos permite realizar pruebas sobre nuestro pc y una vez que dominemos el tema podemos decidirnos a comprar un dominio y un alojamiento. Para instalar AppServ os dejamos un paso a paso que os hará la tarea más facil:

En primer lugar descargaremos el paquete de SourceForge, contando con dos versiones AppServ 2.5.5 (apache 2.0.55, MySQL 5.0.15 y PHP 5) o AppServ 2.4.5 (apache 1.3.34, MySQL 5.0.16 y PHP 4).

Una vez descargado el ejecutable procedemos a ejecutar la instalación, recibiendo un mensaje de bienvenida y hacemos Click en Next

Directorio de Instalación: en esta pantalla nos solicita el directorio en el que queremos instalar la aplicación, por defecto nos marca “c:/appserv”, lo cambiamos si queremos y pulsamos Next.

Tipo de Instalación: Elegimos Typical.

Server Information: La casilla Server Name la dejamos como viene por defecto con “Localhost” y en la casilla Administrator E-mail Address o lo dejamos como viene por defecto y luego lo cambiamos, o le introducimos una cuenta de correo que sera la del administrador. El campo “HTTP Port” lo dejamos como viene por defecto (80), salvo que queramos que el servidor atienda les peticiones en otro puerto. Pulsamos en Next

MySql Information: Este es uno de los apartados más importantes ya que empezamos a instalar MySQL. En la casilla Username introduciremos el nombre del administrador de la base de datos y en la casilla Password le introducimos la contraseña, aunque si queremos hacerlo más fácil ponemos como usuario: root y el apartado contraseña lo dejamos vacio ya que posteriormente podemos cambiarlo con phpMyAdmin. El apartado Charset lo dejamos tal como viene por defecto. Pulsamos en Next

Progreso de la instalación: Empieza realmente la instalación mostrandonos una barra de progreso hasta que aparece una pantalla que nos avisa de que ha finalizado la misma, debiendo dejar marcadas las opciones que vienen por defecto. Finalmente pulsamos en Close.

Comprobación de la instalación: Si hemos hecho bien los deberes al poner en nuestro navegador: http://localhost nos debe aparecer la pantalla siguiente:

Si esta pantalla no aparece supone que bien Apache o MySQL no están funcionado bien, y debemos volver a instalarlo En un paso a paso a realizar en las proximas semanas os enseñaremos a configurar algún gestor de contendos sobre este Apache, un Wiki utilizando WikiMedia el Software de la Wikipedia o un Meneame, lo dejo a vuestra elección. Decidnos vuestras preferencias en los comentarios. Descargar | AppServ
http://www.genbeta.com/2006/03/30-como-instalar-appserv-phpmysqlapache-sobre-windows

Tomado de : http://www.linux-org.ni

Las 12 principales razones por las que GNU/Linux no gusta entre los “no-informaticos"

noreply@blogger.com (Anonymous) — Tue, 10 Mar 2009 05:33:00 +0000

O las 12 razones por las que Windows es mejor que GNU/Linux para los “lusers“

Aquellos que nos siguen habrán leído el articulo traducido aquí de las “25 razones de peso para migrar a GNU/Linux“. Hoy, revisando mis feeds he encontrado una entrada muy curiosa sobre el porqué a los “no-informáticos” no les acaba de convencer GNU/Linux y prefieran Windows, Xp a poder ser…

Como nuestro compañero Linuxero corrijio a esa persona pos yo le hechare una manita en el punto 9 y en el 10 jejejee....

La entrada reza “12 razones por las que Windows es mejor que Linux”, y paso a traducirlo a continuación y a comentarlo entre paréntesis, pues no puedo evitar quedarme al margen después de leerlo entero:

“Hoy en día Ubuntu y otras distribuciones Linux se están volviendo muy populares. Mucha gente a dejado el uso de Windows y comenzado a usar Linux, pero el quid de la cuestión es como lo comparan con Windows aquellos usuarios “de andar por casa” o los usuarios de oficina (los no-informáticos, vaya…).

Es bastante fácil de instalar y configurar para un “entendido”, pero cuando hablamos de personas cuyos empleos no están relacionados con ordenadores, o que usen la computadora para escuchar música, ver películas, trabajar en documentos o enviar emails, la cosa cambia…

He enumerado algunas de las razones por las que Windows es mejor que Linux para los no-entendidos en base a mi experiencia y a lo que me preguntan estas personas a mi sobre Linux.

1) ¿Que distribución uso?
Como todos sabemos Linux tiene toneladas de distribuciones y este es el primer punto de confusión para los no-entendidos… Que distro es mejor para ellos.
(Claro, claro… ¿que Windows necesito yo? ¿Windows XP Home Edition? ¿Windows XP Profesional? ¿Windows Vista Home? ¿Windows Vista Premium Noseque? ¿Windows 7, eso que es?)

2) ¿Dónde consigo una copia?.
Linux no es tan popular como Windows, por lo que también es posible que no encuentren los CDs de Linux en las tiendas.
(Claro, como es tan difícil conseguir una copia de cualquier GNU/Linux… ¡Pero si no tienen ni que salir de casa! ¡Y por 0 leuros HOYGAN!)

3) Cómo instalo Linux.
Aunque Linux no es muy difícil de instalar, y Ubuntu ha proporcionado herramientas como Wubi, que permite instalar el sistema igual que si fuera una aplicación de Windows, en una partición NTFS, aún sigue siendo difícil de instalar para los no-entendidos. El concepto de partición es un poco difícil para ellos.
(¡Ah!, pero ¿saben instalar Windows?)

4) Configuración de escritorios y opciones
El Escritorio, la red, el panel de control y el salvapantallas es algo diferente si lo comparamos con sistemas GNU/Linux y es lo primero en lo que los no-entendidos se fijan. Ellos se confunden a la hora de configurar su escritorio.
(También se confunden con Windows, para que nos vamos a engañar. Que a mi me han llegado a llamar diciéndome que todo el escritorio estaba al revés, literalmente…)

5) Instalación de Software.
Este es el punto más confuso y difícil para ellos, porque la instalación de software es totalmente diferente en Linux. Ellos tienen que instalar desde las fuentes en vez de limitarse a ejecutar un archivo de configuración.
(Claro, como en Linux hay que “requetecompilar” doscientos mil archivos… pero hombre, en Ubuntu instalas una aplicación con 2 clics, 2, justos, ni uno más ni uno menos…)

6) Instalación de controladores.
Aunque Linux cuenta con controladores para algunos dispositivos plug-and-play, para ellos será un autentico quebradero de cabeza instalar un controlador de dispositivo que no esté disponible para Linux.
(¿Alguna vez han probado esos “no-entendidos” en hacer lo mismo en Windows? Es que cualquier GNU/Linux reconoce más componentes de hardware que Windows, y luego ponte a buscar por las paginas del fabricante los drivers de todo. Y si no tienes los manuales, ponte a desmontar el PC para saber que modelo de placa base, gráfica y demás tienes… Cualquier entendido sabe hacer esto, claro…)

7) Reproducción de archivos de música.
La mayoría de la gente tiene canciones u otros archivos de musica en formato MP3, WMA o cualquier otro formato y lo que pasa es que Linux por defecto no tiene instalados los codecs para reproducirlos.
(La inmensa mayoría de usuarios de Windows utilizan VLC precisamente porque Windows no incluye ningún códec, y este reproductor sí. Curiosamente el susodicho reproductor es software libre y viene en los repositorios de cualquier distro Linux. Es más, yo en Debian no he necesitado instalar ningún códec de nada…)

Jugar a juegos.
No todos los juegos están disponibles para Linux, y aquellos que si lo están son dificiles de instalar.
(Aquellos que sí lo están, son tan difíciles de instalar como en Windows. Para lo demás, os remito a otro post famoso por estos lares.)

9) Disponibilidad del software
Casi todos los programas informáticos más recientes están disponibles para Windows, pero no todos están disponibles para Linux. Esto hace que sea difícil para los no-informáticos encontrar alternativas de los programas que ellos utilizan en Linux.
(Bueno para eso en cada una de las empresa existen informaticos que les puedan orientar, si acaso no saben esos informaticos desconocen el tema hasta sus propios hijos o los amigos de sus hijos les podrian ayudar ya los GUL-NI estamos presentes en las universidades dando conferencias y ayudas a todos los usuarios tanto informaticos como no-informaticos, si en un dado caso no encuentras un programa que se asimile al que usas podes emularlo usando un programita pequeño pero muy bueno llamado wine)

10) Dificultad para obtener ayuda.
Ellos prefieren pedir ayuda a los demás en lugar de buscar en Google, ya que es complicado de entender para ellos y si piden ayuda a los miembros de su familia o a sus amigos muy pocos serán capaces de ayudarles, ya que la mayoría está familiarizado con las características de Windows.
(Resolviendo ese dilema en el punto 9 te doy una solución)

11) Particionado
También menciono en la razón 1 que la tabla de particiones de Linux es algo confusa comparada con las particiones de Windows.

/ hda1/disk8
/ hda2/disk4

y si echamos un vistazo a las particiones de Windows tenemos…

C:
D:
E:

Queda claro cual es más sencillo…
(Si, queda clarísimo…. Dile tu a uno de estos que te diga cual es la letra de su disco duro, ya verás que risas xD; otra cosita que pódemos añadir es que, para tener acceso a esas unidades tenes que entrar en "Mi PC", en linux no, ya que te monta un acceso directo en el escritorio.)

12) Se requiere la investigación.
Linux requiere un poco más de investigación en comparación con Windows y los no-informáticos no tienen tiempo o no quieren dedicarlo a investigar sobre Linux, ya que no es parte de su trabajo, por lo que prefieren Windows.
(Prefieren Windows por lo que se dice en el punto 10. Porque siempre conocen a algún amigo o primo o similar que les hace de “esclavo informático” y les soluciona todos los problemas que tienen. Sin la figura del “pringao informático”, todos estos “no-informáticos” se estarían gastando el sueldo en la tienda de informática de la esquina cada vez que el último virus les jodiera la partición, o lo que sea… )”

Tomado de :http://www.historiasdequeso.es/2009/01/las-12-principales-razones-por-las-que-gnulinux-no-gusta-entre-los-no-informaticos.html
Tomado de : http://www.linux.org.ni

Pizza Blash III

noreply@blogger.com (Anonymous) — Sat, 14 Feb 2009 00:49:00 +0000

Para todas las personas interesadas en aprender un poco de los sistemas y programas GNU pongan atencion.

Les escribo para invitarles al Pizza Bash III. Pizza bash es una actividad informal, sin agenda, donde usuarios novatos y avanzados ser eunen para hablar sobre software libre y en especial sobre GNU/Linux.

La actividad será el 20 de febrero iniciando a las 3pm y terminando a las 8pm. Como no hay agenda no hay problema con llegar tarde o tener que irse temprano.

La actividad será en el Salón Orquídea del Hotel Mansión Teodolinda.

Para más detalles por favor consultar el sitio web de Linux Tour

Aqui podran encontrar más detalles sobre la naturaleza de la actividad, como llegar a Hotel Mansión Teodolinda, contribuciones y más.

Curso de Cisco System y Examenes

noreply@blogger.com (Anonymous) — Sun, 01 Feb 2009 23:05:00 +0000

Hola como les va estimados lectores aca les dejo unos capitulos del primer modulo de Cisco System, mas adelante les estare subiendo mas modulos.

Descargar Primer modulo
Descargar Segundo modulo

Aca les dejo los examenes completos de la curricula 4 de CCNA Eploration

Descargar Examenes Primer modulo

Ojo: No me hago responsable si lo usan para otra cosa que no sea el de estudio.

El segundo Modulo se encuentra en formato de Offices 2007 por lo que me encontraba en una pc con Winbox :S

Bienvenidos nuevos usuarios de Linux Fedora

noreply@blogger.com (Anonymous) — Thu, 25 Sep 2008 17:45:00 +0000

Les doy la bienvenida a todos los felices nuevos usuarios de Linux Fedora que se les instalo el dia sabado 20 de sept en el evento del SFD2008, para los nuevos usuarios les pido que instalen las nuevas llaves de fedora con las cuales podran acceder a las nuevas actualizaciones de sistema y demas herramientas y programas que se encuentran en los repositorios

Con este comandito ustedes se bajan las nuevas llaves para fedora yum -y install fedora-release.noarch instalenlo, no se asusten si ven que tienen por lo menos unos 500 o mas paquetes que actualizar, esto es normal debido a unos cambios que la comunidad de fedora tuvo que realizar por fuerza mayor.

F.E.A.R: First Encounter Assault Recon

noreply@blogger.com (Anonymous) — Wed, 10 Sep 2008 13:58:00 +0000

Registrate y unete a los mas de cientos de felices usuarios "GAMERS", solo dame clic aca y podras bajarte todo tipo de video juegos para pc completos.

Descarga Fear Extraction Point (Expanción)

noreply@blogger.com (Anonymous) — Wed, 10 Sep 2008 13:52:00 +0000

Registrate y unete a los mas de cientos felices usuarios "Gamers" dame clic aca y entra a descargar todos los juegos que quiras completamente gratis.

Software Freedom Day 2008

noreply@blogger.com (Anonymous) — Mon, 01 Sep 2008 06:19:00 +0000

Deceas saber mas acerca de los eventos de SFD, deceas saber de nuestra historia como LUG-NI visita este link

El Nombre correcto es GNU con Linux por Richard Stallman

noreply@blogger.com (Anonymous) — Sat, 02 Aug 2008 18:47:00 +0000

Tutorial de SendMail

noreply@blogger.com (Anonymous) — Mon, 28 Jul 2008 21:32:00 +0000

Tutorial de Sendmail

Tabla de contenidos
Nota Introductoria
Una Configuraci�n T�pica
Conceptos
Empezando
Configuraci�n del sistema
Sistema de configuraci�n M4
El Procesamiento de los mensajes
Administraci�n de la cola de Sendmail
Dominios virtuales
Enmascaramiento
Sitios con m�s de un servidor
Performance/Tuning
Reglas y Rulesets
Ejemplo: Ambiente de alta seguridad
Ejemplo de configuraci�n de MUA
Referencias

Este tutorial pretende dar una visi�n general del MTA Sendmail. Los ejemplos asumen un sistema Linux RedHat 7.X, 8.0 y 9.0, pero pueden extenderse a cualquier otro sistema operativo soportado.
El lector realmente interesado en conocer este MTA debe consultar la referencia [1], a partir de la cual se ha hecho este tutorial.

Nota Introductoria

Si tuviera que buscar un adjetivo para calificar a Sendmail, pensar�a en "excesivo". Excesivo puesto que este programa intenta -y puede- satisfacer las necesidades de una audiencia extremadamente amplia... incluso, de una audiencia que hace a�os ha desaparecido.

En general, cuando un programa es "m�s y m�s flexible", los usuarios deben pagar el precio de "m�s y m�s complejidad" para asimilar toda aquella flexibilidad. Sendmail permite configurar aspectos que normalmente yacen ocultos en el c�digo compilado de otros programas similares... aspectos que en la pr�ctica diaria ya casi nadie usa.

Es por eso que usar Sendmail suele ser una experiencia desconcertante... desde el inicio y hasta el final. Y en ese sentido tengo que admitir que este peque�o texto tambi�n puede serlo, pese a que he procurado que no ocurra as�.

Sendmail es calificado de "inseguro", y con justa raz�n. Tiene una larga historia de "vulnerabilidades" que han conminado a algunos administradores a optar por soluciones supuestamente m�s seguras como postfix y qmail. En favor de Sendmail s�lo tengo que indicar que sus creadores han venido haciendo grandes esfuerzos para que esto cambie, y ciertamente los �ltimas versiones han consistido esencialmente en mejoras en esa direcci�n.

Un �ltimo adjetivo para Sendmail podr�a ser "legendario", en el sentido que es una de las utilidades m�s antiguas de los sistemas Unix, se proporciona en pr�cticamente todas sus variantes (y tambi�n en Linux), es el servidor de email m�s utilizado a nivel mundial, y sorprendentemente es a la vez una de las utilidades menos "dominadas" por los administradores debido a lo antes indicado - as� como a una muy deficiente documentaci�n!

C�mo se ha confeccionado este texto

En la medida que tengo costumbre de usar vi, pero no tengo costumbre de escribir y recordar los extensos y variados tags de Docbook, he usado mi script "QDK" disponible en Sourceforge a fin de generar el SGML respectivo. Recomiendo su uso al lector que est� acostumbrado a escribir Docbook directamente.

C�mo contactarme

Cualquier sugerencia para mejorar este texto, o el se�alamiento de alg�n error, agradecer�a me sea indicado escribiendo a: darksiteevil@fedora-ni.net

Managua, Nicaragua.

Una Configuraci�n T�pica

Empezaremos con una descripci�n general de los pasos que se requieren en una configuraci�n t�pica de Sendmail.

Los lectores que no disponen de absolutamente ninguna experiencia con Sendmail deber�an pasar previamente por la secci�n denominada "Conceptos".

Escenario

La gran mayor�a de sitios peque�os en Internet puede usar la configuraci�n que proporciona RedHat en forma autom�tica. Es el caso t�pico de una organizaci�n que disponde de un �nico servidor de correo electr�nico con conexi�n directa a Internet, y que posee un dominio tal como "laorganizacion.org".

Asumiremos que el servidor de correo designado se llama "correo.laorganizacion.org" y no consideraremos detalles de seguridad como firewalls y redes DMZ.

Asumiremos tambi�n que nuestros clientes son las estaciones de trabajo que se conectan con alg�n cliente de correo est�ndar como "Outlook Express", "Mozilla", etc.

Configurar el DNS

Asumiremos que las direcciones de correo de nuestros usuarios son de la forma "usuario@laorganizacion.org". En ese caso, en el archivo de configuraci�n de la zona "laorganizacion.org" deber� inscribirse el siguiente registro MX:

@ 1D IN MX 0 correo

Esto env�a los mensajes con ese formato a nuestro servidor "correo.laorganizacion.org". (He asumido el uso de BIND.)

Configurar las opciones del puerto SMTP

En RedHat 7.x, 8, 9 (y quiz� futuras versiones), Sendmail viene por defecto configurado para aceptar s�lo conexiones locales; es decir, no recibir� ning�n mensaje que llege desde el exterior.

Esto no sirve de mucho en ambientes t�picos de red, por lo que editaremos el archivo /etc/mail/sendmail.mc y modificaremos la siguiente l�nea:

DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')

por:

DAEMON_OPTIONS(`Port=smtp, Name=MTA')

Y regeneraremos la configuraci�n:

# cd /etc/mail
# m4 sendmail.mc > sendmail.cf

An�logamente, en RedHat 7.x se modificar� el archivo redhat.mc.

Configurar el archivo /etc/hosts

Asegur�monos de que existan las siguientes DOS l�neas, y que tengan un contenido como a este:

127.0.0.1 localhost
1.2.3.4  correo.organizacion.org correo

Obviamente, se deber� reemplazar "1.2.3.4" por la direcci�n IP asociada a la interfaz de la red local.

Configurar el archivo local-host-names

Como nuestras direcciones son "usuario@organizacion.org", nuestro servidor debe asumir como SUYOS todos los mensajes dirigidos a "@organizacion.org". Esto se consigue escribiendo "organizacion.org" en el archivo /etc/mail/local-host-names:

organizacion.org

En muchas versiones antiguas de Sendmail, el archivo equivalente se llama /etc/sendmail.cw.

Permitir el relay a nuestros clientes

Asumiremos que las estaciones de nuestra organizacion est�n contenidas en la subnet "1.2.3.0". En ese caso, a�adiremos la siguiente l�nea al archivo /etc/mail/access:

1.2.3  RELAY

Luego generaremos la versi�n indexada:

# cd /etc/mail
# make

N�tese que en muchos sistemas distintos a RedHat habr� que usar (en vez de "make") el comando "makemap" con las opciones correspondientes:

bash# cd /etc/mail
bash# makemap hash access <>

Esta funcionalidad viene activada normalmente en la configuraci�n proporcionada por RedHat. En otros sistemas probablemente esto se debe configurar expl�citamente como se indica m�s abajo.

Configurar servicios POP / IMAP

Estos dos servicios provienen del paquete "imap*.rpm". Se deber�n activar con el comando ntsysv o chkconfig (basta con uno de ellos.) Por ejemplo, para el �ltimo caso:

bash# chkconfig --level 345 ipop2 on
bash# chkconfig --level 345 ipop3 on
bash# chkconfig --level 345 imap on

Luego se deber� recargar la configuraci�n de xinetd:

# service xinetd reload

Ahora todo est� listo por el lado del servidor.

Pruebas con el cliente "mail"

En los sistemas Linux el comando mail permite enviar y leer mensajes de correo electr�nico mediante Sendmail. Por ejemplo, para enviar un mensaje a una cuenta exterior de test:

[diego@edithpiaf diego]$ mail test_user@yahoo.com
Subject: This is a test
There goes the challenger
.
Cc:
[diego@edithpiaf diego]$

La lectura de mensajes de correo recibidos se puede hacer tambi�n con el comando "mail":

[pedrito@correo pedrito]$ mail
Mail version 8.1 6/6/93.  Type ? for help.
"/var/spool/mail/pedrito": 1 message 1 new
>N  1 pepe@noskhon.com  Sun Jan 27 06:24 "prueba"
&
Message 1:
From root@noskhon.com Sun Jan 27 06:24 2002
Delivered-To: pedrito@abejas.org
Date: Mon, 25 Feb 2002 02:09:26 -0500
From: pepe 
To: pedrito@abejas.org
Subject: prueba

Esta es una prueba

&

Durante estas operaciones conviene verificar los mensajes del log desde otra ventana:

# tail -f /var/log/maillog

V�ase el ap�ndice intitulado "Ejemplo de configuraci�n de MUA" si requiere una idea acerca de c�mo se configura un cliente gr�fico de correo electr�nico.

Conceptos

Esta secci�n proporciona una serie de conceptos que se utilzar�n en lo que sigue.

Programas Involucrados

MUA/Cliente

El Mail User Agent o Cliente de correo electr�nico es un programa que ejecutan los usuarios para leer y escribir sus mensajes. En la mayor�a de casos se ejecuta en un computador personal. Este programa normalmente enviar� los nuevos mensajes redactados por el usuario al servidor de la organizaci�n/proveedor, y descargar� los mensajes pendientes para lectura del usuario desde el servidor de la organizaci�n/proveedor.

MTA/Servidor

El Mail Transfer Agent se encarga de enviar (y reintentar de ser necesario) los mensajes redactados por los usuarios de la organizaci�n. Igualmente, recibe los mensajes dirigidos a usuarios de la organizaci�n y los coloca en sus respectivas "casillas de correo" para su posterior lectura.

Protocolos

SMTP

El Simple Message Transfer Protocol se emplea para enviar mensajes de correo electr�nico entre servidores. En muchos casos, el programa cliente de correo electr�nico remite un nuevo mensaje al servidor usando tambi�n SMTP.

POP

El Post Office Protocol permite a los programas clientes de correo electr�nico extraer los mensajes pendientes en las casillas de correo del usuario para que �ste los pueda visualizar.

IMAP

El Internet Message Access Protocol, al igual que POP, permite a los programas clientes de correo electr�nico extraer los mensajes pendientes en las casillas de correo del usuario para que �ste los pueda visualizar. Tiene caracter�sticas adicionales a las proporcionadas por POP.

DNS

El Domain Name System permite que los mensajes de correo electr�nico sean dirigidos al servidor correspondiente en el Internet. En particular, a partir de una direcci�n de correo electr�nico de destino en un mensaje, se puede encontrar la direcci�n IP del computador que debe recibir dicho mensaje.

Mensajes

Header (cabecera)

Esta es una secci�n informativa que contienen todos los mensajes y que contiene datos relacionados a su env�o, tales como el nombre y direcci�n electr�nica del creador del mensaje, la lista de destinatarios, la fecha de env�o, los servidores intermedios por donde el mensaje ha pasado, etc.

Body

Contiene el texto del mensaje en s�. Est� compuesto por caracteres ASCII.

Envelope (sobre)

Contiene informaci�n usada para enrutar los mensajes, tal como los destinatarios inmediatos. Esta informaci�n normalmente tiene coincidencias con algunos componentes del header.

Attachment

Los archivos que no se componen de texto ASCII pueden ser enviados si primero se codifican como texto ASCII y se a�aden ordenadamente a un mensaje normal. Estos a�adidos al mensaje se denominan attachments.

Casilla del usuario

Los usuarios de correo electr�nico no est�n conectados a la red durante todo el d�a, y lo mismo ocurre con sus computadores. Debido a esto, los mensajes que est�n dirigidos a ellos normalmente se almacenan en un �rea temporal denominada "casilla de correo" a la espera de que el usuario la extraiga cuando est� listo.

Relay

Corresponde a la facultad del MTA de reenviar los mensajes provenientes de un computador hacia otro computador. Por ejemplo, cuando un usuario de la red local le proporciona un mensaje que en realidad est� dirigido hacia un usuario en Internet.

Empezando

Instalaci�n

RedHat Linux

En los sistemas Linux RedHat, el servidor Sendmail se distribuye mediante el paquete "sendmail". Sin embargo, se har� bien en instalar otros paquetes adicionales tales como sendmail-cf y sendmail-doc, que proporcionan herramientas de configuraci�n y documentaci�n adicional, respectivamente. Adicionalmente se requerir� el paquete "m4".

La instalaci�n en RedHat, como de costumbre, se har� mediante el comando RPM (o durante la instalaci�n del sistema operativo, eligiendo "Mail Server" entre las opciones.) Aqu� no explicaremos el comando RPM y nos limitaremos a mostrar c�mo se puede verificar si los paquetes han sido instalados:

bash# rpm -qa|grep sendmail
sendmail-cf-8.11.2-14
sendmail-8.11.2-14
sendmail-doc-8.11.2-14
bash# rpm -q m4
m4-1.4.1-4

La version de los paquetes indicados arriba puede ser distinta dependiendo de la versi�n de RedHat. El ejemplo anterior se refiere a una instalaci�n RedHat 7.1.

Otros Sistemas Operativos

En casi todos los sistemas operativos Linux y Unix principales, Sendmail se distribuye por el mismo proveedor (posiblemente con algunas alteraciones.) En estos casos el m�todo de instalaci�n de paquetes puede variar, y se deber� consultar la documentaci�n respectiva.

Desde la fuente

En RedHat y cualquier otro sistema operativo, siempre existe la posibilidad de descargar el c�digo fuente de Sendmail a fin de compilarlo e instalarlo manualmente. En este caso deber� descargarse el archivo ".tar" de:

ftp://ftp.sendmail.org/pub/sendmail/

Al desempacarse este archivo, se encontrar� documentos que explican el procedimiento de compilaci�n e instalaci�n (archivo READ_ME.)

Probando Sendmail

Asumiremos que Sendmail ya ha sido instalado. Para verificar la instalaci�n y obtener cierta informaci�n b�sica, usaremos el siguiente comando, cuyo resultado se muestra para mi computador:

# sendmail -d0.1 -bt
Version 8.12.5
Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX
            MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6
            NETUNIX NEWDB NIS PIPELINING SASL SCANF STARTTLS TCPWRAPPERS
            USERDB USE_LDAP_INIT

============ SYSTEM IDENTITY (after readcf) ============
  (short domain name) $w = edithpiaf
(canonical domain name) $j = edithpiaf.noskhon.com.pe
     (subdomain name) $m = noskhon.com.pe
          (node name) $k = edithpiaf.noskhon.com.pe
========================================================

ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter  
>
#

Para salir del prompt ">" se presion� [CTRL]+[D].

N�tese que este comando ha sido ejecutado por el administrador. Los usuarios normales normalmente deber�n especificar la ruta completa del ejecutable "sendmail" a fin de obtener algo similar:

[diego@edithpiaf diego]$ /usr/sbin/sendmail -d0.1 -bt
Version 8.12.5
Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX
            MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6
... siguen m�s l�neas ...

La opci�n "-bt" significa "modo de test", y el "-d0.1" significa "debug de aspectos generales (el cero), en nivel 1". Al modificar el nivel de debug se puede obtener m�s informaci�n. Por ejemplo, el lector podr�a observar la salida que presenta el comando anterior con "-d0.15".

Inicio autom�tico

Como se aprecia, el servidor "sendmail" puede ser invocado en modo interactivo con diversos prop�sitos, sin embargo, lo usual es que opere en forma "no interactiva", o como se suele decir en sistemas Unix, como un "demonio". Por lo general esto es configurado en los scripts de inicio del sistema operativo de modo tal que el "demonio sendmail" se inicie en forma autom�tica cada vez que el computador es iniciado.

En un sistema RedHat Linux (versiones 7 en adelante) se puede emplear el comando "service" para invocar a estos scripts en cualquier momento. Por ejemplo, para consultar acerca del estado actual del servicio Sendmail:

[root@edithpiaf root]# service sendmail status
sendmail est� parado

Para iniciarlo:

[root@edithpiaf root]# service sendmail start
Iniciando sendmail:                           [  OK  ]
Inicio de sm-client:                          [  OK  ]

Para detenerlo:

[root@edithpiaf root]# service sendmail stop
Apagando sendmail:                            [  OK  ]
Desactivaci�n de sm-client:                   [  OK  ]

En otros sistemas habr� que consultar la respectiva documentaci�n. El comando necesario podr�a ser como sigue:

bash# /etc/rc.d/init.d/sendmail start

bash# /etc/init.d/sendmail start

bash# /sbin/init.d/sendmail start

Y para detenerlo, reemplazar el "start" por un "stop".

Para que esto se ejecute autom�ticamente cuando el sistema se inicia, en RedHat se suele emplear los comandos ntsysv o chkconfig.

El log

Sendmail, como cualquier programa relacionado con el correo electr�nico, genera mensajes de eventos (logs) mediante syslog. En los sistemas RedHat normalmente syslog est� configurado para enviar los mensajes hacia el archivo /var/log/maillog. Cuando se hacen pruebas con Sendmail es muy conveniente tener una ventana o terminal abierta mostrando el log:

# tail -f /var/log/maillog
Oct 26 18:17:10 edithpiaf sendmail[1812]: h9QNHAM0001812:
from=root, size=421, class=0, nrcpts=1, msgid=<200310262317.>, relay=root@localhost
Oct 26 18:17:10 edithpiaf sendmail[1812]: h9QNHAM0001812:
to=root, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00,
mailer=relay, pri=30065, relay=localhost.noskhon.com.pe.
[127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused
by localhost.noskhon.com.pe.
Oct 27 17:52:14 edithpiaf sendmail[2299]: h9RMqEA5002299:
from=root, size=244, class=0, nrcpts=1, msgid=<200310272252.>, relay=root@localhost
Oct 27 17:52:14 edithpiaf sendmail[2299]: h9RMqEA5002299:
to=root, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00,
mailer=relay, pri=30065, relay=localhost.noskhon.com.pe.
[127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by
localhost.noskhon.com.pe.

Configuraci�n del sistema

Dividiremos esto en dos partes: configuraci�n del host y configuraci�n de programa Sendmail.

Configuraci�n del host

A continuaci�n algunos aspectos muy importantes relacionados al sistema operativo donde Sendmail se ejecutar�. Esto NO es propiamente la configuraci�n de Sendmail, pero �ste requiere interactuar con diversos elementos del sistema operativo.

DNS

A fin de poder enviar mensajes a destinatarios remotos, Sendmail debe ser capaz de obtener la informaci�n necesaria de un servidor DNS. Incluso en una red local puede ser conveniente el empleo de un servidor DNS.

Si se desea desactivar completamente el uso del servidor DNS (por ejemplo, si nunca se saldr� a Internet) entonces se debe recompilar Sendmail con las opciones apropiadas (no explicaremos esto aqu�.)

En la mayor�a de computadores Unix/Linux, la direcci�n del servidor DNS que usan las aplicaciones se configura en el archivo /etc/resolv.conf. Por ejemplo, si su servidor DNS m�s cercano (el de la organizaci�n o el que ha proporcionado su proveedor) tiene direcci�n ip 100.2.3.4, entonces el archivo "resolv.conf" del computador destinado para ejecutar Sendmail debe lucir as�:

nameserver 100.2.3.4

Por lo general se configuran dos o tres servidores DNS.

Por otro lado, a fin de que nos puedan enviar mensajes desde el exterior a nuestro servidor de correo, requerimos administrar un dominio (el dominio de la organizaci�n.) Esto implica que habr� un servidor DNS (posiblemente dentro de nuestra organizaci�n o administrado por un proveedor) que contenga la configuraci�n de nuestra zona.

Si el dominio de nuestra organizaci�n es "laorganizacion.org", es frecuente definir que las direcciones de los usuarios locales tendr�n la forma "usuario@laorganizacion.org". En algunos lugares, prefieren direcciones similares a "usuario@mail.laorganizacion.org" aunque esto es a gusto de la organizaci�n.

Esto debe reflejarse en la configuraci�n de nuestro dominio en el servidor DNS. Asumiendo que el servidor DNS que administra nuestra zona usa el software BIND, (puede ser cualquier otro) el archivo de la zona "organizacion.org" deber�a contener al menos estas l�neas para que las direcciones de formato "usuario@laorganizacion.org" llegen al servidor.

@ 1D IN MX 0 correo
correo 1D IN A  90.8.7.6

Si se desea el segundo formato ("usuario@mail.laorganizacion.org"), las l�neas correspondientes ser�an algo como:

mail 1D IN MX 0 correo
correo 1D IN A  90.8.7.6

Nosotros no detallaremos m�s la configuraci�n del servidor DNS por ser un tema fuera del �mbito que nos compete. En [2] se puede encontrar una excelente explicaci�n de todo esto.

N�tese que esto �ltimo se har� muy probablemente en un computador distinto al que ejecuta Sendmail.

Archivo hosts

El archivo /etc/hosts es complementario al sistema DNS. Para su correcta operaci�n Sendmail normalmente requiere que el computador en que se ejecuta tenga una configuraci�n como la siguiente:

127.0.0.1 localhost
90.8.7.6 correo.laorganizacion.org

N�tese que esto normalmente NO viene as� en RedHat.

La direcci�n IP suministrada debe coincidir con lo que se configur� en el DNS, y el nombre del host debe ser "full", es decir, debe incluir el nombre del dominio.

Hostname

El nombre del computador donde se ejecuta Sendmail debe corresponder a lo configurado en el DNS y el archivo hosts. Lamentablemente, la configuraci�n de este par�metro var�a de sistema en sistema. Por ejemplo, en RedHat, la configuraci�n del hostname se efect�a en el archivo /etc/sysconfig/network en la variable HOSTNAME.

[root@edithpiaf root]# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=edithpiaf.noskhon.com.pe
GATEWAY=172.192.12.1

La forma m�s f�cil -pero no la �nica- de proseguir tras modificar el hostname, consiste en reiniciar el computador.

Configuraci�n del programa Sendmail

Sendmail es extremadamente configurable -aunque no necesariamente de un modo sencillo. Para esto posee un archivo de configuraci�n principal que en RedHat 8 es:

/etc/mail/sendmail.cf

aunque en otros sistemas Linux/Unix es:

/etc/sendmail.cf

o incluso:

/var/adm/sendmail/sendmail.cf

La ruta exacta de este archivo normalmente se define durante la compilaci�n de Sendmail. Es conveniente que el lector lo encuentre antes de proseguir.

Este archivo de configuraci�n de aqu� en adelante ser� llamado el archivo "cf" por la extensi�n de su nombre.

Como quiz� ya haya observado el lector, el archivo "cf" tiene una sintaxis poco intuitiva, y ha sido dise�ado principalmente para que el computador lo lea de un modo eficiente (mas no los humanos.)

El archivo "cf" define generalmente la ruta de otros archivos de configuraci�n auxiliares que evitan la modificaci�n directa del primero, simplificando la administraci�n de Sendmail.

En las �ltimas versiones de sendmail (8.12 o superiores) es usual que se configure el servidor para que se ejecute "dividido" en dos programas complementarios a fin de elevar la seguridad del sistema. La siguiente salida (recortada) de RedHat Linux 8.0 ilustra esta idea:

# ps axuw|grep sendmail
root  16216  ?  S  15:43 sendmail: accepting connections
smmsp 16226  ?  S  15:43 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue

En este caso, el segundo proceso (client queue runner) es controlado mediante otro archivo de configuraci�n:

/etc/mail/submit.cf

Obviamente, en otros sistemas este archivo se puede encontrar en otros directorios.

Sistema de configuraci�n M4

Motivaci�n

Si el lector tuvo curiosidad de listar el archivo "cf", habr� notado seguramente que �ste tiene una sintaxis muy poco intuitiva. Este problema no ha pasado desapercibido para los desarrolladores de Sendmail (aunque la cura quiz� haya resultado peor que la enfermedad:)

A fin de facilitar la configuraci�n de Sendmail para los usuarios ocasionales y los administradores en general, existe un mecanismo complementario que evita la escritura y modificaci�n directa del archivo "cf". Este mecanismo consiste en escribir un archivo relativamente sencillo usando la sintaxis del lenguaje "M4", el cual se proporciona en pr�cticamente todos los sistemas Unix/Linux (a veces como software opcional.)

Mediante este sistema, el usuario crear� (o modificar�) un archivo relativamente breve, el cual se traducir� en muchas l�neas del archivo "cf".

Lo cierto es que es absolutamente impr�ctico escribir "desde cero" un archivo "cf" medianamente utilizable, as� que el m�todo M4 es una opci�n casi obligatoria.

Regenerando el archivo "cf"

Antes de hacer modificaciones, es recomendable conocer c�mo se gener� el archivo "cf" proporcionado por el sistema. Normalmente �ste proviene de un archivo tipo "M4". Lamentablemente esto no es v�lido en todos los casos, y las rutas de los archivos involucrados son muy variables.

En RedHat 8 el archivo "cf" distribuido (/etc/mail/sendmail.cf) se puede regenerar en cualquier momento a partir del archivo (/etc/mail/sendmail.mc) que usa la sintaxis "M4". Esto se puede hacer con el siguiente comando:

# cd /etc/mail
# m4 sendmail.mc > sendmail.cf

* NOTA: Aseg�rese de sacar una copia al archivo "cf" antes de hacer esto!

En RedHat 7 la secuencia es parecida, aunque los directorios difieren:

bash# cd /usr/share/sendmail-cf/cf
bash# m4 redhat.mc > /etc/sendmail.cf

En otros sistemas Unix/Linux (incluso RedHat en versiones anteriores) el archivo sendmail.mc puede tener un nombre distinto y una ubicaci�n distinta, y habr� que ver la documentaci�n respectiva. Por ejemplo, en RedHat 7 se llamaba redhat.mc y se ubicaba en /usr/share/sendmail-cf/cf.

Incluso puede ser que este archivo simplemente no exista y haya que generar uno nuevo. En ese caso Ud. deber� ubicar primero el directorio "cf" de Sendmail y crear un archivo (le llamaremos prueba.mc) tal como:

include(`../m4/cf.m4')
OSTYPE(hpux10)dnl
MAILER(local)dnl
MAILER(smtp)dnl

La directiva OSTYPE requiere que Ud. especifique su versi�n de sistema operativo (en el ejemplo, HP/UX V.10.) Para ver los sistemas disponibles, vea el directorio sendmail-cf/ostype o cf/ostype. En mi caso:

bash# ls ../ostype/
aix2.m4        bsdi2.0.m4   irix4.m4     powerux.m4
aix3.m4        bsdi.m4      irix5.m4     ptx2.m4
aix4.m4        darwin.m4    irix6.m4     qnx.m4
aix5.m4        dgux.m4      isc4.1.m4    riscos4.5.m4
altos.m4       domainos.m4  linux.m4     sco3.2.m4
amdahl-uts.m4  dynix3.2.m4  maxion.m4    sco-uw-2.1.m4
aux.m4         gnu.m4       mklinux.m4   sinix.m4
bsd4.3.m4      hpux10.m4    nextstep.m4  solaris2.m4
bsd4.4.m4      hpux11.m4    openbsd.m4   solaris2.ml.m4
bsdi1.0.m4     hpux9.m4     osf1.m4      solaris2.pre5.m4

Todo esto requiere que se trabaje en el subdirectorio sendmail-cf/cf o cf/cf. A continuaci�n, ejecutar m4:

bash# m4 prueba.mc > /etc/sendmail.cf

Volviendo a Linux RedHat, los archivos "M4" usados por Sendmail se proporcionan en el paquete "sendmail-cf". Obviamente requerir� tambi�n el paquete "m4" para poder usarlo. En otros sistemas Unix/Linux el software "M4" puede ser opcional o parte de las herramientas de desarrollo.

En Linux RedHat 8.0 y superiores, es tambi�n posible regenerar el archivo "submit.cf" a partir de:

# cd /etc/mail
# m4 submit.mc > submit.cf

Configuraci�n con M4

El sistema M4 de Sendmail permite generar configuraciones para distintos prop�sitos as� como alterar opciones bastante puntuales. A modo de ejemplo, el par�metro que controla el "tiempo de alerta" de un mensaje en cola (no se preocupe si no entiende esto, es s�lo un ejemplo), se configura con M4 mediante una l�nea como la siguiente:

define(`confTO_QUEUEWARN',`2h')

Lo cual se traduce en exactamente la siguiente l�nea en el archivo "cf" generado:

O Timeout.queuewarn=2h

T�ngase cuidado dentro del archivo "M4" de emplear las comillas adecuadas para cada caso (obs�rve que se han usado ambos tipos:

 ` y '

En resumen, mediante la sintaxis (simple) de "M4", se puede regenerar un archivo en la sintaxis (compleja) del "cf". Recu�rdese que al final, el programa Sendmail s�lo utilizar� el archivo "cf".

En lo que sigue, presentaremos la configuraci�n de Sendmail empleando ambos m�todos cuando sea posible, pero se preferir� el m�todo M4. Como se indic�, algunas directivas del m�todo "M4" se traducen a una gran cantidad de complejas directivas del archivo "cf", el cual resulta impr�ctico.

El Procesamiento de los mensajes

Los mensajes de correo electr�nico tienen principalmente dos tipos de procesamiento:

Local: Cuando el destinatario es un usuario perteneciente a nuestro servidorde correo electr�nico
Remoto: Cuando el destinatario est� ubicado en otro servidor

Estas "rutas" de env�o de mensaje se suelen denominar "mailers" y son implementadas por "delivery agents".

Env�os locales

Sendmail normalmente determina si un mensajes es local cuando la direcci�n de destino contiene s�lo un nombre de usuario (por ejemplo, "diego".) Asimismo, cuando la direcci�n de destino contiene un host que coincide con el "hostname" del servidor. Por ejemplo, en la direcci�n "diego@correo.caligula.net" el host especificado (lo que sigue a la @) es "correo.caligula.net"; si este coincide con el hostname del computador, entonces el mensaje debe ser considerado local.

Una excepci�n (extremadamente com�n) a lo �ltimo consiste en forzar que ciertas direcciones sean tratadas como locales. Para esto, el usuario generalmente configurar� el archivo /etc/mail/local-host-names con los nombres de host considerados "locales" o "sin�nimos" del host local. Por ejemplo, para que el mensaje con destino "diego@neron.org" sea tambi�n considerado local, habr�a que incluir en el archivo /etc/mail/local-host-names:

neron.org

Esto es muy importante, puesto que t�picamente las organizaciones deciden utilizar una direcci�n de email terminada en "@dominio", donde "dominio" casi nunca coincide exactamente con el hostname del servidor. De no configurarse el archivo local-host-names, todos los mensajes que lleguen al servidor con esta direcci�n ser�an considerados no locales, y por tanto ser�an rechazados.

En otros sistemas el nombre del archivo de configuraci�n local-host-names puede variar. Para averiguar o verificar esto, debemos consultar la documentaci�n o en �ltimo caso el archivo "cf":

# grep "^Fw" /etc/mail/sendmail.cf
Fw/etc/mail/local-host-names

En versiones anteriores de Sendmail, este archivo se denominaba /etc/sendmail.cw.

Si se dispone del archivo "M4" que dio origen al "cf", deber�amos buscar all� una l�nea tal como:

FEATURE(`access_db',`hash -T -o /etc/mail/access.db')dnl

En algunos casos (no en RedHat), esta funcionalidad puede no estar definida y se debe activar.

Sin embargo, esta configuraci�n tambi�n puede hacerse en el mismo archivo "cf" con el comando "class-macro-w" (clase w.) Por ejemplo, las siguientes l�neas muestran que las direcciones terminadas en "@localhost" y "@localhost.localdomain" tambi�n son consideradas locales.

# grep "^Cw" /etc/mail/sendmail.cf
Cwlocalhost.localdomain
Cwlocalhost

En otras palabras, la "clase w" se puede considerar un "array" que contiene los nombres de las direcciones consideradas "locales". Esta clase se puede configurar en el archivo "cf" mediante el comando "C" (seguido por el nombre de la clase, o sea "Cw") o mediante un archivo externo (definido por el comando "F", en nuestro caso "Fw".)

Los env�os locales conllevan a que los mensajes sean almacenados en la "casilla de correo" del usuario destinatario. El usuario deber� extraer estos mensajes con su programa "cliente", posiblemente mediante los protocolos IMAP o POP como se ver� despu�s.

La casilla de correo (inbox) es simplemente un archivo cuyo nombre coincide con el del usuario y se ubica en el directorio /var/spool/mail (como siempre, esto puede variar en otros Unix.) Como veremos, Sendmail no escribe directamente en este archivo y por tanto no es parte de su configuraci�n.

Definici�n del env�o local

Como se indic�, el env�o local conlleva a que el mensaje sea guardado en el archivo "inbox" o "casilla de correo". Sin embargo, Sendmail no realiza directamente este trabajo, sino que invoca a un programa auxiliar para esta tarea (aparentemente sencilla.)

Esto se configura en el archivo "cf" con la definici�n "Mlocal" (mailer local.) En el archivo "cf" de RedHat 8.0, esta secci�n luce as�:

Mlocal,  P=/usr/bin/procmail, F=lsDFMAw5:/|@qSPfhn9,
S=EnvFromL/HdrFromL,
R=EnvToL/HdrToL,
T=DNS/RFC822/X-Unix,
A=procmail -t -Y -a $h -d $u

Las l�neas que se inician con espacios o tabuladores se consideran la continuaci�n de la anterior, por tanto, el extracto mostrado arriba debe considerarse una sola l�nea.

Como se aprecia, Sendmail utiliza un programa auxliar llamado /usr/bin/procmail para el delivery local. En muchos sistemas Unix el programa usado es /bin/mail. No profundizaremos m�s sobre esto por ahora, pero en general "procmail" es mucho m�s flexible y eficiente que las alternativas tradicionales.

Env�os Remotos

Sendmail tiene la capacidad de hacer env�os remotos usando el protocolo SMTP (que opera usando TCP/IP.) En este caso, Sendmail no emplea un programa auxiliar como en los env�os locales.

Cuando un mensaje no puede ser enviado a uno de los destinatarios, el mensaje es "encolado" para un posterior reintento.

Para efectuar el env�o remoto, Sendmail requiere que los destinatarios del mensaje posean una "parte de host" distinta al hostname local (o a sus sin�nimos de la clase-w, como se vio en la secci�n anterior.)

Sendmail normalmente utilizar� el DNS a fin de encontrar el servidor remoto que recibir� el mensaje (espec�ficamente, el registro MX y el registro A) y abrir� una conexi�n SMTP.

El archivo "cf" define este env�o con una l�nea como la que sigue.

Msmtp, P=[IPC], F=mDFMuX, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP,
E=\r\n, L=990,
T=DNS/RFC822/SMTP,
A=TCP $h

De estos ejemplos se puede apreciar que las definiciones de los "mailers" o "agentes de delivery" siempre empiezan con el comando "M", inmediatamente seguido por el nombre del "mailer".

"mailers" en M4

Los mailers en el archivo M4 deben aparecer al final del archivo fuente M4. Para generar los dos mailers mencionados arriba, simplemente se requiere:

MAILER(smtp)dnl
MAILER(procmail)dnl

Esto lo puede observar el lector en el archivo "sendmail.mc" proporcionado por RedHat.

Administraci�n de la cola de Sendmail

Conceptos

Los mensajes que procesa Sendmail muchas veces no pueden ser enviados a su destino en forma inmediata. Por ejemplo, la l�nea que conecta nuestra organizaci�n a Internet puede estar detenida, o el mail server remoto puede haberse tornado inaccesible.

En estos casos Sendmail "encolar�" el mensaje a fin de intentar hacer posteriores reintentos a intervalos predefinidos. Cumplido cierto tiempo, Sendmail desistir� de reintentar y el env�o se considera fallido (el usuario que env�a recibe una notificaci�n.)

En RedHat 8 la cola de Sendmail se localiza en el directorio /var/spool/mqueue. Cada mensaje se compone de dos archivos (con prefijo "qf" y "df") que corresponden, respectivamente, al "archivo de control" y el "archivo de datos". El archivo de control contiene informaci�n respecto al env�o del mensaje, particularmente el header. El "archivo de datos" contiene el cuerpo del mensaje.

El directorio de cola se configura en el archivo "cf" del siguiente modo:

O QueueDirectory=/var/spool/mqueue

En el m�todo M4 se usar� (s�lo si se desea modificar el default):

define(`QUEUE_DIR',`/var/spool/mqueue')

Temporizaci�n del queue run

El "queue run" corresponde a un intento repetitivo que hace Sendmail para enviar los mensajes que por alg�n motivo quedaron encolados. El intervalo entre queue run's es configurable en las opciones de l�nea de comando de Sendmail. Por ejemplo, "sendmail -bd -q3h" significa que Sendmail se ejecutar� en background y que el procesamiento de la cola (queue run) se har� cada tres horas (3h.) Este lapso se configura en RedHat en el archivo que se muestra.

# cat /etc/sysconfig/sendmail
DAEMON=yes
QUEUE=1h

En otros sistemas, el lector deber� indagar por los scripts de inicio del servicio Sendmail para configurar el lapso de queue run.

Forzar el procesamiento de la cola

Si deseamos forzar el procesamiento de la cola completa (por ejemplo, si de pronto nuestra conexi�n a Internet se ha restablecido tras un corte), en cualquier momento esto se puede hacer con el comando:

# sendmail -q

Sin embargo, a fin de intentar el env�o de s�lo un mensaje en particular (o un conjunto de �stos), se puede usar lo siguiente:

# sendmail -qIsubstr

Donde "substr" es un substring del queue ID del mensaje a enviar (o de los mensajes.) Por ejemplo, si tenemos los siguientes mensajes encolados:

# sendmail -bp
            /var/spool/mqueue (4 requests)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
h8RKt4UX001163       16 Sat Sep 27 15:55 
             (Deferred: Name server: kika.noskhon.com.pe.: host name looku)
                                     
h8RKt4UZ001163       10 Sat Sep 27 15:55 
             (Deferred: Name server: kika.noskhon.com.pe.: host name looku)
                                     
h8PNiopq002785      298 Thu Sep 25 18:44 root
             (Warning: could not send message for past 4 hours)
                                     diego@kika.noskhon.com.pe
h8PNh4RM002734      298 Thu Sep 25 18:43 root
             (Warning: could not send message for past 4 hours)
                                     diego@kika.noskhon.com.pe
            Total requests: 4

Y queremos enviar los dos primeros de la lista (que tienen bastante tiempo en la cola), podemos especificar su Q-ID completo o un substring del mismo. Por ejemplo, puesto que sus Q-ID son "h8RKt4UX001163" y "h8RKt4UZ001163", podremos emplear el substring "1163" as�:

# sendmail -qI1163
[root@edithpiaf root]# sendmail -bp
            /var/spool/mqueue (2 requests)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
h8PNiopq002785      298 Thu Sep 25 18:44 root
             (Warning: could not send message for past 4 hours)
                                     diego@kika.noskhon.com.pe
h8PNh4RM002734      298 Thu Sep 25 18:43 root
             (Warning: could not send message for past 4 hours)
                                     diego@kika.noskhon.com.pe
            Total requests: 2

Nota: Como se indic� anteriormente, en las versiones recientes Sendmail viene dividido en "dos partes", una de las cuales se encarga del procesamiento de los mensajes enviados desde la l�nea de comando del servidor (sm-client) y otra de los mensajes recibidos desde la red. Ambas tienen su propia cola. A fin de ver la cola del "sm-client" es menester usar:

# sendmail -Ac -bp

Orden de env�o de los mensajes

Normalmente Sendmail ordena los mensajes a ser enviados durante un queue run de acuerdo a la "prioridad" del mensaje. La prioridad se calcula mediante:

PRI=msgsize-(class*ClassFactor)+(nrcpt*RecipientFactor)+(nrun*RetryFactor)

Donde msgsize es el tama�o en bytes del mensaje; "class" significa el valor num�rico asignado mendiante a las opciones "Precedence" en el header (por ejemplo, los mensajes para listas deben tener baja precedencia), y "nrcpt" es el n�mero de destinatarios del mensaje. ClassFactor y RecipientFactor son factores de ajuste (modificables) para proporcionar un peso relativo (normalmente 1800 y 3000 respectivamente.) Una valor m�s elevado de este resultado en realidad significa que el mensaje es tratado con menos prioridad.

Por �ltimo, en cada intento de env�o (cada queue run) un mensaje que no pudo ser enviado sufre una alteraci�n en su prioridad en "RetryFactor". El default para este par�metro es 90000.

El ordenamiento de la cola en base a la prioridad es la pol�tica por omisi�n de Sendmail; sin embargo, la opci�n QueueSortOrder permite alterar esto. Por ejemplo,

QueueSortOrder=host

O en M4:

define(`confQUEUE_SORT_ORDER',`host')

Encolar� los mensajes por el host de destino, estado de conexi�n con el host (primero se aprovechan las conexiones abiertas con el host) y luego la prioridad.

Esto es recomendado en conexiones de alta velocidad.

Dominios virtuales

En esta secci�n veremos la forma en que podamos administrar las cuentas de usuarios en diversos dominios. Por simplicidad, supondremos que los dominios son s�lo dos: "incacoca.com" y "dbe.org.pe". Las cuentas existentes deben ser:

oscar@incacoca.com
ana@incacoca.com
alex@incacoca.com
jose@incacoca.com

diego@dbe.org.pe
ana@dbe.org.pe
DiegoMaradona@dbe.org.pe

Cuentas en el sistema

Lo primero que har�amos en el caso est�ndar de un solo dominio es crear las cuentas de todos los usuarios:

# useradd oscar
# useradd ana
...

Pero hay dos inconvenientes. En primer lugar, hay dos cuentas distintas (para dos personas distintas) con el mismo usuario "ana". En segundo lugar, la cuenta "DiegoMaradona" no es v�lida en la medida que Sendmail intentar� enviar los mensajes de este destinatario a "diegomaradona" (en min�sculas.)

Una soluci�n a este dilema consiste en asociar nombres de usuario totalmente independientes de la direcci�n, m�s o menos del siguiente modo:

oscar@incacoca.com  -> vdu0001
ana@incacoca.com    -> vdu0002
alex@incacoca.com   -> vdu0003
jose@incacoca.com   -> vdu0004

diego@dbe.org.pe    -> vdu0005
ana@dbe.org.pe      -> vdu0006
DiegoMaradona@dbe.org.pe  -> vdu0007

Cualquier otra direcci�n en estos dominios (o cualquier nuevo dominio) recibir� as� un "username" formado por la palabra "vdu" y un n�mero secuencial ("vdu" es un prefijo cualquiera que acabo de imaginar. Para m� significa Virtual-Domain-User.)

Por tanto, crearemos los usuarios del siguiente modo:

# useradd vdu0001
# passwd vdu0001
...
# useradd vdu0007
# passwd vdu0007

Asociar direcciones electr�nicas a las cuentas

Para esto se emplea el archivo "virtusertable" localizado en el directorio "/etc/mail". All� colocar�amos simplemente:

oscar@incacoca.com  vdu0001
ana@incacoca.com    vdu0002
alex@incacoca.com   vdu0003
jose@incacoca.com   vdu0004
diego@dbe.org.pe    vdu0005
ana@dbe.org.pe      vdu0006
DiegoMaradona@dbe.org.pe   vdu0007

Luego ejecutar�amos "make" (estando todav�a en el directorio "/etc/mail") para regenerar la versi�n compilada.

El archivo "cf" que proporciona RedHat ya incluye la referencia a "virtusertable". Si se partiera de cero, lo m�s conveniente es usar el m�todo "M4" incluyendo una l�nea como la que sigue en el archivo "sendmail.mc":

FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl

Lo cual genera la referencia a este archivo as� como los rulesets necesarios para aprovecharlo.

DNS

Como cabr�a de esperarse, en el DNS debe configurarse los registros necesarios para que el correo de forma user@incacoca.com y user@dbe.org.pe se redirija a nuestro servidor. Esto se hace configurando el registro MX en los archivos de configuraci�n de esas zonas. Si nuestro servidor es "correo.laorganizacion.org", la configuraci�n de la zona "incacoca.com" deber�a contener:

@ 1D IN MX 0 correo.laorganizacion.org.

La zona "dbe.org.pe" tendr�a algo similar.

Local-host-names

Es necesario tambi�n indicar a Sendmail que los mensajes de dominios "incacoca.com" y "dbe.org.org" deben ser aceptados. Para esto, incluirlos en el archivo "/etc/mail/local-host-names".

Como siempre, la apertura del relay depender� de d�nde se ubican los clientes, cosa que no se repetir� aqu�.

Configuraci�n del MUA

La �nica diferencia con el caso "mono-dominio" en lo que compete al MUA, corresponde a la configuraci�n para RECIBIR el correo. Ya sea POP o IMAP, hay que indicar que la recepci�n se debe hacer con los usuarios "vduXXXX".

Por otro lado, el ENV�O s� se debe hacer con la direcci�n electr�nica completa (por ejemplo alex@incacoca.com)

Enmascaramiento

En una red conformada por un servidor de correo y un conjunto de estaciones (como nuestro dominio "laorganizacion.org") los usuarios de seguro redactan sus mensajes usando MUA's (clientes) que les permiten (y les exigen) especificar la direcci�n de correo con la que el mensaje aparente haberse originado (campo "From" en el header.) Esto se usa por lo general para que el destinatario pueda respondernos.

En nuestro caso, los usuarios configurar�n sus direcciones de origen con algo como "user@laorganizacion.org".

Sin embargo, hay algunos MUA's que no permiten especificar la direcci�n de origen (por extra�o que esto suene.) Por ejemplo, el comando "mail" disponible en la mayor�a de sistemas Unix permite enviar mensajes usando Sendmail, pero no especifica direcci�n de origen (por lo que Sendmail tiene que "imaginarla".)

A fin de no variar el escenario, supongamos que un usuario llamado "oscarin" se la conectado (usando telnet) al servidor de correo - no importa el motivo - y desea enviar un mensaje. Invoca a "mail" del siguiente modo:

oscarin$ mail pepebotella@yahoo.com

Sendmail tendr� ahora que crear el campo "From" del header, y lo har� usando el hostname (en nuestro caso, correo.laorganizacion.org), por lo que el correo que llega a "pepebotella@yahoo.com" aparece como proveniente de:

oscarin@correo.laorganizacion.org

No est� tan mal, pero no es lo correcto.

A fin de corregir esta situaci�n, simplemente definiremos lo siguiente en nuestro archivo M4 "sendmail.mc":

MASQUERADE_AS(`laorganizacion.org')

Lo que lograr� que el mensaje aparezca (correctamente) como enviado de:

oscarin@laorganizacion.org

Como siempre, regenerar el archivo "cf" con el comando "m4" y reiniciar Sendmail.

N�tese que esto puede no funcionar adecuadamente con el usuario "root" (para facilitar ciertos diagn�sticos) por lo que se deben emplear usuarios comunes.

Recu�rdese que esto s�lo es necesario cuando se emplean MUA's con "problemas" en el sentido explicado. M�s adelante veremos otros casos m�s interesantes de enmascaramiento.

Sitios con m�s de un servidor

Redundancia

Si nuestro servidor de email de pronto sufre un desperfecto, nuestros mensajes de email no podr�n salir. Esto es grave, pero se puede suplir con llamadas telef�nicas u otros medios.

Sin embargo, m�s grave es el no responder a los mensajes que nos env�an. En ciertos casos, los servidores remotos intentar�n reenviarnos los mensajes (durante cierto tiempo.) En otros, puede que esto nunca ocurra y que los mensajes "reboten" inmediatamente. En cualquier caso, es muy grave el hecho de perder estos mensajes. Aqu� analizaremos algunas medidas destinadas a contrarrestar estos inconvenientes.

Un servidor local adicional

Si nuestro servidor de email deja de operar por un problema (cualquiera) del computador, una forma de mantener el servicio consiste en disponer de un servidor de respaldo ubicado al interior de nuestra organizaci�n el cual puede continuar recibiendo los mensajes que nos env�an.

Esto es relativamente sencillo de implementar a�adiendo una entrada en el DNS:

@ MX 10 mailserver1
MX 20 mailserver2

Aqu� mailserver1 es el servidor "normal" que recibe los mensajes, mientras que mailserver2 es el "backup". Esta configuraci�n ocasionar� que los mensajes que llegan del exterior y no pueden ser enviados a mailserver1 sean enviados a mailserver2.

Frecuentemente estos servidores guardar�n los mensajes en las casillas de email de los usuarios destinatarios respectivos, a fin de que �stos los recojan v�a protocolos POP o IMAP. El problema es que la mayor�a de clientes de email POP/IMAP s�lo se pueden configurar para acceder a un servidor a la vez.

En otras palabras, si mailserver1 deja de operar y mailserver2 toma la posta, entonces todos los usuarios de la red local deber�n ser reconfigurados para que apunten a mailserver2.

Esto puede ser aceptable en ciertas circunstancias, como en el caso de tener pocos clientes.

A fin de evitar esto, es posible hacer algunos artificios asumiendo que mailserver1 est� inoperativo.

Si nuestros clientes est�n apuntando a mailserver1 mediante su direcci�n IP, entonces se puede asociar temporalmente esta direcci�n IP a mailserver2 por medio de un "IP virtual" o "IP alias".

Si nuestros clientes est�n apuntando a mailserver1 mediante su nombre (v�a DNS) entonces se puede modificar temporalmente la configuraci�n del DNS para que mailserver1 apunte al IP de mailserver2 (cambiar el registro A.)

Con esto los clientes acceder�n a mailserver2 de modo casi transparente... sin embargo, si usan IMAP y han creado carpetas en el servidor, obviamente estas carpetas no podr�n verse (pues se quedaron en mailserver1.) Informe a sus usuarios de esta situaci�n.

Otro inconveniente radica en el restablecimiento de mailserver1. Ciertos usuarios pueden haber dejado mensajes sin leer en mailserver2 que deber�n ser trasladados manualmente a mailserver1 para que est�n disponibles en su INBOX. Herramientas como fetchmail pueden ayudar en estos casos.

En general, si mailserver1 va a ser interrumpido por s�lo unos minutos, es mejor que mailserver2 NO se haga cargo del email entrante por los inconvenientes se�alados. Una soluci�n m�s adecuada (y costosa) consiste en que ambos servidores compartan un �rea de almacenamiento externo compartido.

Un servidor remoto

En el caso de que nuestra conexi�n a Internet se interrumpa, o en caso de un desastre general en nuestra organizaci�n, conviene disponder de un servidor ubicado en un lugar geogr�ficamente distante y accesible mediante proveedores distintos (a fin de aumentar la redundancia.) En algunos casos, este servidor puede ser el de otra organizaci�n, con la que pactaremos este servicio.

A la configuraci�n anterior del DNS, a�adiremos otra l�nea:

@ MX 10 mailserver1
MX 20 mailserver2
MX 30 email-friend-store.com.

Como se ve, una �ltima opci�n de env�o consiste en que los mensajes lleguen al servidor "email-friend-store.com". Normalmente este servidor rechazar�a nuestros mensajes (pues nuestras direcciones terminan en @laorganizacion.org.) Pero, puesto que hemos hecho un acuerdo previo, en "email-friend-store.com" han a�adido la siguiente l�nea en su archivo access:

laorganizacion.org RELAY

Ahora, en caso de que nuestra conexi�n se interrumpa, los MTA's remotos intentar�n como �ltima opci�n a email-friend-store.com, el cual recibir� nuestros mensajes y tratar� (infructuosamente) de reenviarlos a nuestros servidores mailserver1 y mailserver2. Como no puede, los encolar� y los intentar� reenviar posteriormente (ver la secci�n dedicada al encolamiento para m�s informaci�n.)

Organizaci�n con divisiones administrativas

En organizaciones muy grandes es frecuente que se establezcan �reas relativamente interdependientes pero separadas. Por ejemplo, geogr�ficamente.

A fin de optimizar el rendimiento, el dise�o de la configuraci�n de email debe aprovechar estas caracter�sticas.

Soluci�n trivial: Diversos dominios

Supondremos que nuestra organizaci�n se llama "inkacoca" y que tiene sucursales en las ciudades de Lima, Trujillo, Cuzco, Iquitos y Puerto Maldonado. Asumimos que la organizaci�n ha adquirido la autoridad del dominio "inkacoca.org".

En ese sentido, una manera de operar ser�a crear los siguientes subdominios, que corresponder�an a las direcciones email respectivas:

Tabla 1.

Ciudad	Dominio	Direcci�n email
Lima	lima.inkacoca.org	usuario@lima.inkacoca.org
Trujillo	trujillo.inkacoca.org	usuario@trujillo.inkacoca.org
Cuzco	cuzco.inkacoca.org	usuario@cuzco.inkacoca.org
Iquitos	iquitos.inkacoca.org	usuario@iquitos.inkacoca.org
Puerto Maldonado	pmaldonado.inkacoca.org	usuarios@pmaldonado.inkacoca.org

Luego se configurar�an servidores de email independientes para cada ciudad. Desde el punto de vista del email, cada subdominio viene a ser una organizaci�n independiente. En cada servidor (en cada ciudad) el administrador crea sus propias cuentas independientes.

El DNS deber� contener entradas independientes para cada uno de estos servidores (aqu� llamados lima-mail, tru-mail, cuzco-mail, iqui-mail, pto-mail.)

; archivo de zona de inkacoca.org
lima   IN MX 10 lima-mail
lima-mail IN A  18.1.3.40
trujillo IN MX 10 tru-mail
tru-mail IN A  18.1.4.40
cuzco  IN MX 10 cuzco-mail
cuzco-mail IN A  18.1.5.40
iquitos  IN MX 10 iqui-mail
iqui-mail IN A  18.1.6.40
pmaldonado IN MX 10 pto-mail
pto-mail IN A  18.1.7.40

Los problemas de este esquema son:

No se est� reflejando el dominio �nico de la organizaci�n (nadie tiene cuenta de la forma usuario@inkacoca.org)
Las direcciones de email son muy largas

Un s�lo dominio

Tratemos de mejorar el esquema anterior. Intentemos que todas las direcciones sean de la forma usuario@inkacoca.org, manteniendo los cinco servidores en cada ciudad. El primer inconveniente de este esquema es que si tenemos dos usuarios llamados "diego" en Lima y Cuzco, y ambos originalmente ten�an direcciones:

diego@lima.inkacoca.org
diego@cuzco.inkacoca.org

ahora habr� que buscar una forma de diferenciarlos. Por ejemplo, podr�amos usar "diego1" y "diego2". Esto, si bien no es est�ticamente agradable, puede ser mejorado con el uso de aliases. Pero dejaremos esto para m�s adelante.

Ahora bien, si un mensaje llega desde el exterior a "usuario@inkacoca.org", �qu� servidor lo recibe?

Una posibilidad es designar un servidor adicional (ubicado en cualquier ciudad) para que sirva como "switch", aunque podr�a ser cualquiera de los otros, como veremos.

Este servidor deber� ser capaz de redirigir el mensaje al servidor adecuado. Es decir, deber� disponer de una tabla similar a:

Tabla 2.

Usuario	Destino
diego1	lima.inkacoca.org
diego2	cuzco.inkacoca.org

Esto es prec�samente lo que hace el archivo virtusertable que se discuti� anteriormente en la secci�n "dominios virtuales".

Para esto, el archivo /etc/mail/virtusertable contendr� algo como:

diego1@incakoca.com  diego1@lima.inkacoca.org
diego2@incakoca.com  diego2@cuzco.inkacoca.org

Recu�rdese que se debe generar la versi�n "compilada" como se vio anteriormente.

Adicionalmente se requieren registros en el DNS para el "mail switch":

; archivo de zona de inkacoca.org
@  IN MX 10 switch
switch  IN A  18.1.3.41
lima   IN MX 10 lima-mail
lima-mail IN A  18.1.3.40
trujillo IN MX 10 tru-mail
tru-mail IN A  18.1.4.40
cuzco  IN MX 10 cuzco-mail
cuzco-mail IN A  18.1.5.40
iquitos  IN MX 10 iqui-mail
iqui-mail IN A  18.1.6.40
pmaldonado IN MX 10 pto-mail
pto-mail IN A  18.1.7.40

Todo esto permite que los mensajes destinados con @incakoca.org lleguen al servidor de correo local que les corresponde.

Los problemas pendientes son:

P�rdida de independencia

Cada administrador local debe notificar al administrador del switch de que se ha creado un usuario local a fin de que se le registre en virtusertable. Se pierde independencia y no hay una forma sencilla de evitar esto.

Ineficiencia en escritura de direcciones

Cuando un mensaje se env�a desde el interior de la organizaci�n a otro usuario de la organizaci�n, es necesario especificar la direcci�n de email completa (usuario@inkacoca.org.) Ser�a deseable usar s�lo el nombre del usuario y que el sistema asuma que se trata de la organizaci�n.

Ineficiencia en los env�os locales

Si se env�a un mensaje desde Iquitos a otro usuario en Iquitos usando su direcci�n email "usuario@inkacoca.org", el mensaje (de acuerdo al DNS) ir� primero al switch de la organizaci�n y luego !retornar�! a Iquitos. Esto es correcto pero ineficiente.

Ser�a deseable que si el usuario destinatario es local al remitente, entonces el mensaje no tenga que viajar hasta el switch.

* PENDIENTE.

Performance/Tuning

Balance con varios servidores

Normalmente los sitios que reciben una gran cantidad de email tienen una configuraci�n tipo "switch" como la que se coment� anteriormente en la secci�n "Organizaci�n con divisiones administrativas". En ese caso puede ser conveniente configurar varios computadores para que reciban la carga de mensajes entrantes y la redirijan a los computadores departamentales.

A fin de lograr esto, se suele aplicar dos t�cnicas, a saber, v�a DNS o mediante NAT. En el DNS es posible especificar varios servidores de switch para la organizaci�n con la misma preferencia. Siguiendo el ejemplo de la secci�n se�alada, habr�a que modificar esto:

; archivo de zona de inkacoca.org
@  IN MX 10 switch
switch  IN A  18.1.3.41
lima   IN MX 10 lima-mail
lima-mail IN A  18.1.3.40
...

Por lo siguiente:

; archivo de zona de inkacoca.org
@  IN MX 10 switch
switch  IN A  18.1.3.41
switch  IN A  18.1.3.42
switch  IN A  18.1.3.43
lima   IN MX 10 lima-mail
lima-mail IN A  18.1.3.40
...

Esto supone disponer de tres mailservers llamados "switch" asociados a las direcciones IP 18.1.3.4[123]. Bajo condiciones normales, esto balancear� la carga entre los tres servidores. Para m�s informaci�n, revise la referencia [2] en lo referente a "Round Robin Load Distribution".

El m�todo NAT consistir�a en nuestro ejemplo en redirigir las conexiones destinadas a la direcci�n 18.1.3.41 (no habr�a ning�n cambio en el DNS) hacia un grupo de otras direcciones (DNAT) que realmente est�n asociadas a los servidores de email. Los ruteadores normalmente disponen de estas facilidades (y por supuesto Linux cuando act�a como router, usando el comando iptables.) No lo explicaremos aqu�.

Intervalo de Queue Run

En sitios peque�os el intervalo debe ser corto a fin de asegurar el r�pido env�o (por ejemplo, 15 minutos.) En la mayor�a de sitios, sin embargo, una hora es un tiempo aceptable.

Como se indic�, el intervalo de Queue Run se especifica mediante opciones al ejecutarse sendmail (opci�n -q).

Procesos de ejecuci�n en Queue Run

Cuando el intervalo de Queue Run es corto, cuando los mensajes encolados son muchos, y cuando los servidores remotos son lentos, Sendmail puede lanzar muchos procesos "queue runners" concurrentes que intentan en paralelo limpiar la cola. Esto normalmente debe autocontrolarse, pero en situaciones extremas el n�mero de "queue runners" puede ser muy elevado al punto de crear un peligro para el sistema.

La opci�n MaxQueueChildren permite especificar el m�ximo n�mero de procesos "hijos" de Sendmail encargados de procesar la cola simult�neamente. Normalmente no hay l�mite.

El valor m�s adecuado se debe obtener observando el comportamiento "usual" de los queue runners de Sendmail, por ejemplo, mediante un comando como el que se muestra:

[root@edithpiaf root]# ps ax | grep sendmail | grep queue | wc -l
7

Esto se debe observar a distintas horas. Un valor razonable puede ser el m�ximo observado durante la semana multiplicado por dos.

Por otro lado, si el sistema constantemente tiene problemas de falta de memoria, y se sospecha que el problema est� asociado a un n�mero elevado de "queue runners", puede ser conveniente reducir esta opci�n gradualmente (quiz� reduciendo 10% al valor observado) a fin de aliviar este problema. Esto ocasionar� que algunos mensajes encolados tarden m�s en procesarse.

Limpiar m�s aprisa los mensajes en cola

La opci�n "Timeout.queuewarn" determina el lapso que permanece un mensaje en cola para generar un mensaje de alerta al redactor del mismo. Esta alerta le permite saber que el mensaje no pudo ser enviado (default=4 horas.)

La opci�n "Timeout.queuereturn" determina el tiempo m�ximo que el sistema mantendr� el mensaje en la cola (intentando enviarlo.) Cuando este tiempo se cumple, el mensaje es eliminado de la cola y se env�a una alerta al redactor (default=5 d�as.)

Por consistencia, Timeout.queuewarn <>

A fin de que los mensajes "reboten" m�s aprisa (y la cola se libere m�s aprisa), es conveniente en ciertos casos reducir estos valores, por ejemplo:

En el archivo "cf":

O Timeout.queuewarn=2h
O Timeout.queuereturn=1d

En M4:

define(`confTO_QUEUEWARN',`2h')
define(`confTO_QUEUERETURN',`1d')

Cola con varios directorios

El acceso a disco generado por las colas puede ser considerable en sistemas grandes. Una forma de balancear esta carga y mejorar la performance consiste en utilizar discos f�sicos distintos, los cuales pueden montarse y usarse simult�neamente para la cola.

Esto se puede consiguir creando varios subdirectorios a partir de un directorio principal (por ejemplo bajo /var/spool/mqueue) y configur�ndolos en el archivo "cf" (o v�a M4.)

[root@edithpiaf mqueue]# ls -ld /var/spool/mqueue/
drwx------    2 root     mail         4096 oct  5 13:39 /var/spool/mqueue/
[root@edithpiaf mqueue]# cd /var/spool/mqueue
[root@edithpiaf mqueue]# mkdir cola1
[root@edithpiaf mqueue]# mkdir cola2
[root@edithpiaf mqueue]# mkdir cola3
[root@edithpiaf mqueue]# chmod 700 cola*
[root@edithpiaf mqueue]# mount /dev/sdX cola1
[root@edithpiaf mqueue]# mount /dev/sdY cola2
[root@edithpiaf mqueue]# mount /dev/sdZ cola3
[root@edithpiaf mqueue]# chown root.mail cola*
[root@edithpiaf mqueue]# ls -l
total 12
drwx------    2 root     mail         4096 oct 11 13:01 cola1
drwx------    2 root     mail         4096 oct 11 13:01 cola2
drwx------    2 root     mail         4096 oct 11 13:01 cola3

En el archivo "cf" se colocar�a:

QueueDirectory=/var/spool/mqueue/cola*

Por el m�todo M4:

define(`QUEUE_DIR',`/var/spool/mqueue/cola*')

Tenga cuidado de no especificar "/var/spool/mqueue/*" pues esto har�a que Sendmail incluya (incorrectamente) los directorios "/var/spool/mqueue/." y "/var/spool/mqueue/..".

Encolar si hay mucha carga

Si la carga del sistema se hace muy elevada, es conveniente limitar la operaci�n de Sendmail, al menos para los mensajes de menor prioridad.

Cuando un nuevo mensaje es recibido, Sendmail le calcula su prioridad inicial "PRI" con la f�rmula se�alada anteriormente.

Si la carga es muy elevada, Sendmail tiene la opci�n de no intentar enviar el mensaje, sino, simplemente encolarlo para un intento posterior. Esto ocurrir� si se verifican las siguientes condiciones:

1) La carga promedio del sistema (load average) es mayor que el indicado en la opci�n configurable "QueueLA" (cuyo default es ocho.) La carga promedio es un valor proporcionado por el sistema operativo que se puede obtener con el comando "uptime".

2) Se verifica la ecuaci�n:

PRI > QueueFactor /(LA-QueueLA+1)

Recordar que un valor "PRI" m�s elevado es menor prioridad y por tanto hace m�s probable que la ecuaci�n anterior se verifique.

QueueFactor es una opci�n configurable cuyo valor por omisi�n es 600000.

En sistemas grandes puede ser necesario elevar el valor de QueueLA:

O QueueLA=15

En M4:

define(`confQUEUE_LA',`15')

Rechazar si hay mucha carga

La opci�n "RefuseLA" permite especificar un l�mite para la carga promedio del sistema (load average) a partir del cual Sendmail simplemente rechaza los mensajes que se le env�an. Esto, evidentemente asume que quien se est� intentando conectar lo intentar� nuevamente m�s adelante.

El valor por omisi�n de esta opci�n es doce. En sistemas grandes puede ser necesario elevar este valor.

O RefuseLA=18

En M4:

define(`confREFUSE_LA',`18')

Procesar lentamente las conexiones

La opci�n ConnectionRateThrottle permite "relentizar" las conexiones que llegan a un ritmo muy veloz. Por ejemplo, si este par�metro es igual a cinco, en caso de llegar m�s de cinco conexiones en menos de un segundo, s�lo las cinco son atendias inmediatamente. Otras cinco ser�n atendidas luego de un segundo, y as� sucesivamente.

Esta opci�n es adecuada cuando se usan las opciones QueueLA y RefuseLA.

O ConnectionRateThrottle=5

En M4:

define(`confCONNECTION_RATE_THROTTLE',`5')

Reglas y Rulesets

En una primera lectura de este tutorial sugiero evitar todo este material puesto que no es esencial para la gran mayor�a de administradores de Sendmail.

Las reglas son especificaciones de configuraci�n que sirven para modificar las direcciones electr�nicas y detectar errores en las mismas. Hay diversos motivos por los que una direccion electr�nica debe ser modificada; por ejemplo, si se desea que todos los mensajes luzcan como si hubieran sido enviados desde cierto computador aunque en realidad se han enviados desde diversos computadores de distinto nombre.

Los conjuntos de reglas se agrupan en los llamados "Rulesets" que funcionan a modo de "subrutina" de cualquier lenguaje de programaci�n. Los "Rulesets" se identifican con un n�mero, aunque en las �ltimas versiones de Sendmail es posible identificarlos con una palabra (que internamente es traducida a un n�mero por Sendmail.)

Algunos rulesets son definidos internamente (como los rulesets 0, 1, 2, 3, 4, y 5) mientras que otros se definen manualente en el archivo "cf".

Los rulesets se definen mediante el comando "S" y las reglas mediante el comando "R". A continuaci�n un extracto del archivo "cf" que viene con RedHat 8.0 en el que se ilustra el ruleset "0" o tambi�n denominado "parse". Obs�rvese que el ruleset termina donde empieza uno nuevo:

######################################
###   Ruleset 0 -- Parse Address   ###
######################################

Sparse=0

R$*                     $: $>Parse0 $1          initial parsing
R<@>                    $#local $: <@>          special case error msgs
R$*                     $: $>ParseLocal $1      handle local hacks
R$*                     $: $>Parse1 $1          final parsing

Esta salida puede ser muy distinta en otros sistemas Unix/Linux, pero por el momento eso no importa.

El ruleset 0 se pudo definir mediante "S0" en lugar de "Sparse", pero como "parse" es m�s "comprensible" que "0", entonces se prefiere esta �ltima forma (Sparse=0.)

Para verificar c�mo ha cargado Sendmail las reglas, se puede usar el modo de test de Sendmail con el comando "=S" y el n�mero del ruleset:

# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter  
> =S 0
R$*             $: $> Parse0 $1
R< @ >          $# local $: < @ >
R$*             $: $> ParseLocal $1
R$*             $: $> Parse1 $1

N�tese que esto coincide con la definici�n del archivo de configuraci�n. De igual modo puede consultarse con el nombre del ruleset:

# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter  
> =S parse
R$*             $: $> Parse0 $1
R< @ >          $# local $: < @ >
R$*             $: $> ParseLocal $1
R$*             $: $> Parse1 $1

Como es f�cil de apreciar, cada ruleset consiste de varias "reglas" definidas con el comando "R".

Cada regla consiste de dos partes separadas por un tabulador, posiblemente seguidas de un comentario (separado tambi�n por un tabulador.)

Ejemplo de ruleset con una regla

Para esta secci�n haremos algunas modificaciones al archivo de configuraci�n "cf". Sin embargo, a fin de evitar alterar la configuraci�n actual, trabajaremos sobre un archivo "cf" alternativo. Empecemos haciendo una copia del archivo "cf":

# cp /etc/mail/sendmail.cf prueba.cf

Ahora podremos hacer nuestros cambios en "prueba.cf". A�adiremos a �ste �ltimo las siguientes l�neas en la parte final:

D{MAILHUB}mail.peru.com.pe
Sprueba
R$+@$+  $1*${MAILHUB}       convierte user@host

Como se ve, hemos definido la macro "MAILHUB", el ruleset "prueba" y una �nica regla. Para que la regla est� adecuadamente definida, es imprescindible que sus tres partes est�n separadas por al menos un tabulador (no espacios):

R$+@$+  $1*${MAILHUB}  convierte user@host

Para probar nuestra regla, ejecutaremos Sendmail en modo de prueba pero especificando el nuevo archivo "cf":

# sendmail -Cprueba.cf -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter  
> prueba diego@hotmail.com
prueba             input: diego @ hotmail . com
prueba           returns: diego *mail . peru . com . pe
#

Como se aprecia, el modo de prueba permite especificar el nombre de cualquier ruleset seguido por una direcci�n electr�nica a procesar.

Partes de una regla

Cada regla tiene hasta tres partes (el comentario es opcional) separadas por tabuladores (puede haber espacios dentro de cada parte.)

Recu�rdese que las reglas alteran las direcciones de correo electr�nico.

La primera parte (que sigue inmediatamente al comando "R") es la "left hand side" (lado izquierdo o LHS) mientras que la segunda es la "right hand side" (lado derecho o RHS.) La LHS especifica un patr�n de b�squeda. De haber coincidencia con el patr�n de b�squeda, la direcci�n de correo electr�nico que se est� procesando es convertida en el RHS.

Tokens

A fin de comprender las reglas, es necesario conocer el concepto de "token".

Las direcciones electr�nicas procesadas en los rulesets por las reglas son internamente fraccionadas en varias unidades independientes denominadas "token". As�, la direcci�n proporcionada en el ejemplo de arriba: "diego@hotmail.com" es internamente dividida en los siguientes cinco tokens:

diego
@
hotmail
.
com

Los siguientes caracteres normalmente delimitan los tokens (y act�an ellos mismos como tokens adicionales):

.:@[]
()<>,;\"\r\n

Expresiones de b�squeda

En el ejemplo de arriba, la LHS est� conformada por dos "expresi�n de b�squeda" (comodines o wildcards) de tipo "$+". Estos sirven para buscar coincidencias de uno o m�s "tokens". M�s adelante veremos m�s de estos comodines.

En nuestro ejemplo, la direcci�n proporcionada hizo coincidir el primer "$+" con el token "diego" y el segundo "$+" con los tokens "hotmail", ".", "com".

Por el lado de la RHS, el contenido de cada "expresi�n de b�squeda" es accesible mediante los operadores $1, $2, ... respectivamente. Para nuestro caso, tendremos:

$1 = diego
$2 = hotmail . com

En nuestro ejemplo, el RHS es "$1*${MAILHUB}", lo que equivale a "diego*mail.peru.com.pe", cosa que se aprecia en la respuesta.

El modificador de debug 21.12 permite obtener m�s informaci�n acerca del procesamiento de cada regla.

# sendmail -d21.12 -bt -Cprueba.cf
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter  
> prueba diego@hotmail.com
prueba             input: diego @ hotmail . com
-----trying rule: $+ @ $+
-----rule matches: $1 *mail . peru . com . pe
rewritten as: diego *mail . peru . com . pe
-----trying rule: $+ @ $+
----- rule fails
prueba           returns: diego *mail . peru . com . pe

Rulesets Internos

Los rulesets 0, 1, 2, 3, 4, 5 est�n reservados para usos espec�ficos de Sendmail. A futuro Sendmail puede definir los rulesets 6, 7, 8, 9. En general, es conveniente que el usuario defina - si lo requiere - rulesets con textos identificatorios (para que Sendmail autom�ticamente los numere) con lo que se evitan conflictos innecesarios.

Es conveniente conocer el uso que da Sendmail a los rulesets internos. La siguiente figura intenta ilustrar este punto.

Figura 1.

En general, todas las direcciones electr�nicas pasan por el ruleset 3 apenas se inicia el procesamiento de las mismas. Entre otras cosas, el ruleset 3 extrae la direcci�n electr�nica "apta para procesamiento" a partir de la direcci�n electr�nica entregada por los clientes.

Por ejemplo, es usual que las direcciones electr�nicas luzcan as� (tal como las genera el programa cliente):

Pedro Escobedo

Obviamente, para efectos de la transferencia del mensaje, el nombre real no es importante. Probemos esto:

# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter  
> 3 Pedro Escobedo 
canonify           input: Pedro Escobedo <>
Canonify2          input: pescobedo < @ noskhon . com . pe >
Canonify2        returns: pescobedo < @ noskhon . com . pe . >
canonify         returns: pescobedo < @ noskhon . com . pe . >

Lo que hemos hecho es transformar la direcci�n electr�nica mediante el ruleset 3, el cual se encarga de "preprocesar" todas las direcciones electr�nicas. N�tese que la respuesta consiste de la direcci�n electr�nica en un formato especial usado internamente.

Es sencillo imprimir el ruleset 3 (o cualquier otro) desde Sendmail. Para esto, simplemente entrar en modo debug (con -bt) y tipear el comando "=S":

> =S 3
R$@             $@ < @ >
R$*             $: $1 < @ >
R$* < $* > $* < @ >             $: $1 < $2 > $3
...

Finalmente, todav�a en modo test, pru�bese el comando "/parse" que permite simular el procesamiento de una direcci�n de correo electr�nico (por ejemplo, pruebe "/parse user@localhost".)

Macros en el archivo "cf"

Para explicar esto, copiar� una parte del archivo "cf" que se vi� anteriormente (en la secci�n del delivery local.)

Mlocal,  P=/usr/bin/procmail, F=lsDFMAw5:/|@qSPfhn9,
S=EnvFromL/HdrFromL,
R=EnvToL/HdrToL,
T=DNS/RFC822/X-Unix,
A=procmail -t -Y -a $h -d $u

Como se aprecia, aqu� se emplearon las construcciones "$h" y "$n". Como ya sospechar� el lector, esto corresponde a la expansi�n de dos "macros".

En particular, la macro "h" (cuyo valor se obtiene con "$h") corresponde al host destinatario del mensaje, mientras que la macro "n" corresponde al usuario destinatario del mensaje. En este caso el valor de la macro es ajustado por Sendmail autom�ticamente para cada mensaje.

Las macros se pueden definir con el comando "D" en cualquier parte del archivo "cf". Por ejemplo, esto redefine la macro "w" al valor "jibaros":

Dwjibaros

Las macros cuyos nombres tienen m�s de un caracter deben usar llaves en su definici�n y su expansi�n:

D{PRUEBA}amazonas.com.pe
... ${PRUEBA} ...

La opci�n de debug -d35.9 permite obtener un extenso listado de macros definidas por Sendmail y v�a el archivo "cf".

Ciertas macros son asignadas internamente por el programa Sendmail (como la macro "w" que es inicializada al nombre del host "sin dominio") y otras son creadas expl�citamente en el archivo "cf" con diversos prop�sitos.

Clases

Las "clases" son una suerte de variables tipo "array", es decir, que pueden contener un conjunto de valores.

Las clases no se solapan con las macros. Por ejemplo, existe la clase "w" que no tiene relaci�n alguna con la macro "w". Los elementos de la clase se a�aden con el comando "C". Por ejemplo, los siguientes dos comandos a�aden los elementos "localhost" y "localhost.localdomain" a la clase "w" del archivo "cf":

[root@edithpiaf tmp]# grep '^Cw' /etc/mail/sendmail.cf
Cwlocalhost.localdomain
Cwlocalhost

Tal como se mencion� anteriormente, la clase "w" corresponde a los "nombres de host" que Sendmail considera "locales" y que permiten que un mensaje sea dirigido al mailbox en lugar de ser redirigido hacia otro destino.

Como se recordar�, esa configuraci�n la hac�amos mediante el archivo /etc/mail/local-host-names. En otras palabras, las l�neas de este archivo pasan a conformar la clase "w". Esto se define en el archivo "cf" mediante el comando "F":

[root@edithpiaf tmp]# grep '/etc/mail/local-host-names' /etc/mail/sendmail.cf
Fw/etc/mail/local-host-names

Evidentemente, esto tambi�n se pudo configurar a�adiendo directamente directivas "Cw..." al archivo "cf", pero es un m�todo menos flexible.

La clase w desde M4

Como se ve, esta clase es especial. A tal efecto si usamos el m�todo M4 y se desea generar un archivo "cf" que incluya la configuraci�n via el archivo local-host-names deber� usarse:

FEATURE(use_cw_file)dnl

Ejemplo: Ambiente de alta seguridad

Descripci�n

Supondremos que nuestra organizaci�n se desempe�a tras un Firewall. Podr�amos hacer que el esquema anterior siga sin variaciones simplemente habilitando los puertos respectivos en el filtro de paquetes. Sin embargo, aqu� consideraremos una situaci�n m�s complicada en la que se requiere de dos servidores de email. Asumimos que el lector conoce el concepto de una red DMZ (zona desmilitarizada) usada como primera l�nea de defensa para los servicios que deben dar cara al exterior.

Uno de estos servidores de email se encontrar� en la red DMZ (correo_dmz) y ser� accesible desde Internet (aunque pasando por el Firewall), y el otro se encuentra dentro de nuestra red LAN (correo_lan). Las estaciones seguir�n configuradas para conectarse a este �ltimo (correo_lan) por lo que no haremos cambios al respecto. Sin embargo, correo_lan NO enviar� mensajes al exterior directamente, sino a trav�s de correo_dmz, y viceversa, no recibir� mensajes desde el exterior, salvo desde correo_dmz. La siguiente figura esquematiza esta configuraci�n:

Figura 1. Soluci�n con red DMZ

N�tese que nosotros no indicaremos absolutamente nada acerca de la configuraci�n del firewall pues esto est� fuera de los objetivos de esta gu�a. Si se implementa el firewall con Linux, en Internet ya hay abundantes documentos acerca de c�mo configurarlo.

Configuraci�n de correo_dmz

Este servidor no almacenar� los mensajes pendientes en casillas, por lo que no requiere que se inscriban all� nuestros usuarios. A fin de que los mensajes que llegan al dominio "abejas.org" se redirijan a correo_lan, en el archivo /etc/mail/mailertable debemos inscribir la siguiente l�nea:

abejas.org    smtp:correo_lan.abejas.org

Ud. ahora debe generar la versi�n compilada con:

bash# cd /etc/mail
bash# make

Los detalles que vimos para el archivo access son aplicables a este archivo. En particular, para activar esta funcionalidad desde el archivo "mc", se debe incluir:

FEATURE(`mailertable',`hash -o /etc/mail/mailertable')dnl

Por otro lado, "correo_dmz" sirve de relay a "correo_lan", por lo que debemos inscribir a este �ltimo en /etc/mail/access como se vi� en una secci�n anterior:

correo_lan.abejas.org               RELAY

Configuraci�n del DNS

Desde Internet, los mensajes deben llegar a "correo_dmz", por lo cual �ste servidor deber� ser el destino especificado en el registro MX para nuestro dominio:

$TTL 86400
@       IN      SOA     @  root.localhost (
                    4 ; serial
                28800 ; refresh
                 7200 ; retry
               604800 ; expire
                86400 ; ttl
                      )
    IN      NS      ns1
    IN      MX  0   correo_dmz

correo_dmz  IN      A       100.4.244.191
correo_lan  IN      A       100.4.244.195
ns1         IN      A       100.4.244.193

Configuraci�n de correo_lan

Tal como vimos en una secci�n anterior, se debe modificar el archivo /etc/mail/local-host-names (o su equivalente) para que se acepten los mensajes con el formato deseado.

Ahora haremos que se env�e todo el correo no local hacia el computador "correo_dmz" en lugar del Internet. Para esto, debemos regenerar el archivo "cf" a partir del "mc", a�adiendo previamente la siguiente directiva a �ste �ltimo:

define(`SMART_HOST', `smtp:correo_dmz.abejas.org')dnl

Eso deber�a bastar. Revise los logs, verifique que el firewall no bloquee m�s de lo necesario.

Ejemplo de configuraci�n de MUA

Los clientes de nuestra red local acceder�n al servidor mediante programas especializados para la redacci�n y visualizaci�n de mensajes. Estos programas se conocen como MUA's (Mail User Agent.) Este es un asunto que estrictamente no tiene que ver con nuestra gu�a, pero creemos conveniente proporcionar alg�n ejemplo ilustrativo. Supondremos que los usuarios est�n utilizando Netscape Messenger, que es parte del Netscape Communicator. A continuaci�n mostramos la pantalla principal de Netscape Messenger:

Figura 1. Netscape Messenger

Vamos a configurar el MUA para que acceda a nuestro servidor de correo. Asumimos que ya est�n activos los servicios POP o IMAP. Cu�l de estos se usar� para traer los mensajes, y de qu� usuario, se selecciona en el menu Edit -> Preferences -> Mail Servers -> Incoming Mail Servers -> Edit o Add -> Server Name y Username , como se aprecia en la figura:

Figura 2. Configuraci�n de servidor POP

Asimismo, en Edit -> Preferences -> Mail Servers -> Outgoing (SMTP) server, se debe especificar nuevamente nuestro servidor de correo, puesto que hacia all� se enviar�n los mensajes que redactemos.

Finalmente, en Edit -> Preferences -> Identity , se debe especificar nuestra direcci�n de email y nuestro nombre real, tal como lo ver�n los destinatarios:

Figura 3. Configuraci�n de servidor POP

Ahora Ud. deber�a poder enviar mensajes a usuarios locales (de la forma user@abejas.org), y recibir mensajes desde cualquier lugar de Internet. Pruebe a crear algunos usuarios en el servidor y a hacer que se intercambien mensajes desde sus estaciones.

Referencias

[1] Bryan Costales & Erick Allman: Sendmail. 2th Edition. O'Reilly. USA. ISBN 1-56592-222-0

[2] Paul Albitz & Cricket Liu: DNS and BIND. 4th Edition. O'Reilly. USA. ISBN 0-596-00158-4. 2001