Descargar desde sourceforge.net

Me entristeció mucho la noticia de que no se podía descargar de sourceforge.net gracias (o desgracias) a una indicación del Gobierno de USA de mantener a Cuba dentro de la lista negra de Internet. Intenté hacerlo mediante sourceforge. (por ejemplo sourceforge.jp) donde si se permite descargas pero al final la mayoría de las cosas salen por el sitio principal, el que tiene .net como nombre de dominio.

Me aventuré a descargar alguna cosa del sitio y la descarga entró en un ciclo de "espera que te lo descargo en unos segundos" y nada, pero como siempre muestran el vínculo "direct link" me atreví a copiarlo y pegarlo en mi administrador de descarga "DownThemAll" y no me lo van a creer pero comenzó la descarga y la alegría se me notaba en la cara. Entonces comencé a probar con varias cosas que quería descargar y todas funcionaron de esa forma. ¡¡ Vaya, un bug en el sitio que te permite descargar !! Le dije al compañero Pavel, mi amigo, que trabaja a mi lado y noté que también se puso contento. ¿Será a propósito este olvido? ¿Será que se les olvidó de verdad? Bueno, lo real es que si se puede descargar, en este momento que escribo el artículo estoy descargando el jmailserver.jar, para usarlo en un trabajo práctico que tengo mañana.

Arriba amigos, aprovechen antes de que se den cuenta.

Happy hacking!!

Variables de configuración del Postfix

La configuración de Postfix se hace por medio de variables predefinidas que pueden tener valores o listas de valores tomados de diversas fuentes. También se pueden declarar variables de usuario y usarlas en la configuración para mejor comodidad y claridad. La sintaxis de la declaración de variables en Postfix es sencilla:

<variable> = <valor>

donde <variable> es un identificador o cadena de caracteres que incluye solo los alfanuméricos y el signo de guión bajo (_), <valor> puede ser un valor cualquiera o una lista de ellos, que pueden estar separados por espacios o por comas, se hace evidente que un valor no puede tener espacios porque se usa como delimitador. Ejemplos:

dominios = dominio1.com dominio2.com dominio3.com
reglas_filtrado = regla1,no_entrada,permitir_todo
servidor = server.domain.com

Como ya se ha dicho el sistema ya trae un conjunto de variables predefinidas que cuando se les da valor estos ya tienen un significado y se hace una acción al respecto, pero este tema no lo voy a tratar aquí, en el sitio www.postfix.org están bien definidos esos significados.

Otra forma de asignar listas de valores a las variables en Postfix son las tablas lookup, estas pueden estar en un archivo o en bases de datos. Las tablas comúnmente tienen dos o tres columnas, siempre la primera es el índice (o algo que sirva para indicar) en la tabla y la segunda el valor, la tercera columna se usa mayormente para situar algún comentario, hay veces que no se usa. En estas tablas las dos primeras columnas no contienen espacios porque entre ellas se separan por estos o también usando tabuladores, la tercera si puede contener espacios y termina con el cambio de línea. Para definir que vamos a usar una tabla lookup como valor de una variable se usan varios modificadores, a continuación una lista de los que más se usan:

hash    - los índices son identificadores.
regexp - los índices son expresiones regulares.
pcre    - los índices son expresiones regulares compatibles con PERL.
mysql  - se trabaja con una tabla en una base de datos MySQL.
ldap    - se buscan los valores en un directorio LDAP.

Para usar una tabla lookup se pone el modificador y donde están los datos de la tabla, la sintaxis es como sigue:

<valor> = <modificador>:<identificador | camino a un archivo>

ejemplo:

usuarios = hash:/home/usuarios/lista

y el archivo /home/usuarios/lista debe contener algo como:
pepe    OK
lolo      OK
virus    NO

En el caso específico de hash se debe mapear la tabla con el comando postmap:

postmap /home/usuarios/lista

Cuando se hace esto se genera un archivo que se va a llamar lista.db que es el que se usa en realidad.
Con pcre y regexp es parecido a hash pero en estos casos no es necesario utilizar el comando postmap porque la tabla se toma del mismo archivo de texto.
Ejemplo:

correos_locales = regexp:/home/usuarios/locales

Y el archivo /home/usuarios/locales debe contener algo como:
/^[a-z][A-Z][0-9]@dominio.com.*/      OK Usuarios del dominio.

Cuando se usa el modificador mysql o el modificador ldap, lo que se hace en el archivo es especificar las variables de la conexión que se va a usar para extraer los datos.
En el caso de mysql se usan principalmente estas variables:

user          - Usuario para conectarse a la base de datos.
password   - Contraseña del usuario.

dbname     - Nombre de la base de datos.

table         - Tabla a la que va a acceder para acceder a los datos.

host          - Nombre o IP del servidor de bases de datos.

where_field -  Para la condición del WHERE.

select_field - Campo que se va a usar en la consulta.

ejemplo de uso con MySQL:

usuarios = mysql:/home/usuarios/usuarios.mysql.cf

e el archivo /home/usuarios/usuarios.mysql.cf debe contener:

user=usuario
password=qwerty

dbname=directorio

table=usuario

host=mysql.dominio.com

En el caso de un directorio LDAP las variables más usadas son:

server_host      - Nombre o IP del servidor LDAP.

search_base     - DN base donde se van a buscar los datos.

query_filter       - Filtro o condición de búsqueda.

result_attribute - Atributo LDAP donde está el dato que se quiere obtener.

bind                - "yes" o "no", dice si hay que autenticarse en el servidor LDAP.

bind_dn           - DN del usuario con el cual hay que autenticarse (en caso que bind sea yes).

bind_pw          - Contraseña del usuario que se va a autenticar.

Cuando se usa LDAP hay dos variantes, una es usar un archivo y la otra es poner la configuración dentro del mismo main.cf. Vamos a ver el ejemplo en las dos variantes seguido este párrafo.

Eejemplo en un fichero:

usuarios = ldap:/home/usuarios/usuarios.ldap.cf

y el archivo /home/usuarios/usuarios.ldap.cf va a contener:

server_host = ldap.dominio.com
search_base = ou=usuarios,ou=dominio,ou=cu
query_filter = (mail=%s)
result_attribute = nombre
valiases_bind = no

para hacerlo dentro del mismo main.cf sería así:

usuarios = ldap:usuarios

usuarios_server_host = ldap.dominio.com

usuarios_search_base = ou=usuarios,ou=dominio,ou=cu
usuarios_query_filter = (mail=%s)
usuarios_result_attribute = nombre
usuarios_valiases_bind = no

En nuevas versiones de Postfix se han adicionado nuevos modificadores como por ejemplo el pgsql que es para bases de datos PostgreSQL y se usa con las mismas variables que el de mysql. Para profundizar más en las variables que se usan y los modificadores remitimos al lector al sitio oficial del software, www.postfix.org .

Dominios Virtuales Postfix

Para hacer dominios virtuales en Postfix hay que crear un usuario y un grupo que a partir de ahora son los que van a trabajar sobre los directorios de los usuarios. Normalmente las carpetas del correo de los usuarios están en su propio directorio personal, con los dominios virtuales el buzón también se va a crear en un directorio virtual. En muchos manuales se recomienda darle al usuario y al grupo de buzones virtuales el ID 5000, nosotros vamos a usar estos mismos IDs, ejemplo:

Para crear el grupo:
groupadd –g 5000 virtualmail

Para crear el usuario:
useradd –g 5000 –u 5000 virtualmail

Entonces creamos la carpeta que va a contener los buzones y le damos al usuario y al grupo virtualmail la propiedad de esta carpeta y todo su contenido:

mkdir /home/vmail
chown –R virtualmail.virtualmail /home/vmail

Dentro de este directorio creamos los de cada dominio que vayamos a trabajar en el Postfix, si tenemos un dominio dominio1.com y otro que sea dominio2.com entonces debemos crear dos carpetas que se llamen así como los dominios, ejemplo:

mkdir /home/vmail/dominio1.com
mkdir /home/vmail/dominio2.com

Ahora los buzones de los usuarios del dominio 1 se pueden crear en la carpeta /home/vmail/dominio1.com y los del dominio 2 en /home/vmail/dominio2.
Pasamos a configurar el Postfix para que trabaje con los dominios virtuales. Para la autenticación de los usuarios es recomendado usar SASL, con el software saslauthd, luego de instalar Postfix hay que instalar también el saslauthd y configurarlos los dos para que trabajen juntos. Primero configuramos el SASL. En el archivo /etc/default/saslauthd hay que asegurarse de que las variables START y MECHANISMS estén correctamente asignadas:

START=”yes”
MECHANISMS=”valor” # valor puede se ldap,mysql,pam, etc. Depende de donde estén almacenados los usuarios.

Después hay que vincular el Postfix con SASL en el fichero /etc/postfix/sasl/smtpd.conf, dentro de él hay que poner lo siguiente:

pwcheck_method: saslauthd
mech_list: plain login

Con esto decimos que el chequeo de autenticación de los usuarios en Postfix lo hace el software saslauthd. Después, ya dentro de la configuración del Postfix, hay que configurar y autorizar el SASL. Esto de instalar y configurar SASL no tiene nada que ver con los dominios virtuales pero es recomendado para la autenticación. Bueno, vemos como configurarlo. El archivo de configuración es el /etc/postfix/main.cf, aquí vamos a escribir lo siguiente:

smtp_sender_dependent_authentication = yes
smtpd_sasl_local_domain = # se deja vacío.
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination

Con esto ya autorizamos al SASL a que autentique los usuarios del Postfix. Ahora pasamos a lo que realmente interesa, la configuración de los dominios virtuales.
Todo se hace dentro del fichero /etc/postfix/main.cf.

# Aquí se configura que el trasporte va a ser virtual.
virtual_transport = virtual
# Especificamos el directorio donde van a estar los dominios.
virtual_mailbox_base = /home/vmail/
# Los dominios que se van a ver en el servidor.
virtual_mailbox_domains = dominio1.com,dominio2.com
# Id donde comienzan los de los usuarios del sistema (esto es a conveniencia)
virtual_minimum_uid = 100
# Id del usuario que tiene permiso en los buzones,
# el mismo que creamos al principio.
virtual_uid_maps = static:5000
# Id del grupo que tiene permiso en los buzones,
# también el que creamos.
virtual_gid_maps = static:5000

Yo en particular no recomiendo configurar trasporte local en un servidor que maneja dominios virtuales, lo dejo que funcione con la configuración que trae por defecto.

Luego de tener esto solo queda especificarle al Postfix donde se encuentran los alias y los usuarios. Estos pueden estar en un archivo de texto, un directorio LDAP, una base de datos MySQL, etc. Los alias se configuran con la variable virtual_maps y los usuarios con la variable virtual_mailbox_maps. Cuando se configuren los usuarios, en el soporte que se escoja, hay que fijarse que el campo que especifique la carpeta del buzón debe especificar también el dominio, si no el servidor no la puede encontrar. Ejemplo: se puede decir que el buzón del usuario pepe está en la carpeta dominio1.com/pepe/. Así cuando el servidor vaya a buscar el buzón lo busca en /home/vmail/dominio1.com/pepe/ porque se configuró que en /home/vmail están los buzones.

Nota:
Cuando haya problemas de permisos entre el Postfix y los buzones de los usuarios la solución es rectificar que el propietario de /home/vmail y todo su contenido sea el usuario virtualmail del grupo virtualmail. Esto se logra con el siguiente comando:

chown –Rv virtualmail.virtualmail /home/vmail

A continuación voy a poner un ejemplo de configuración de alias y buzones de usuarios que hice una vez con un directorio LDAP y el servidor de entrega era un Courier.

#Alias virtuales
virtual_maps = ldap:valiases
valiases_server_host = ldap.dominio.com
valiases_search_base = ou=alias,dc=dominio,dc=com
valiases_query_filter = (&(mail=%s)(objectClass=CourierMailAlias))
valiases_result_attribute = maildrop
valiases_bind = no

#Usuarios virtuales
virtual_mailbox_maps= ldap:ldapvirtualmap
ldapvirtualmap_server_host = ldap.dominio.com
ldapvirtualmap_search_base = ou=usuarios,dc=dominio,dc=com
ldapvirtualmap_query_filter =(mail=%s)
ldapvirtualmap_result_attribute = mailbox
ldapvirtualmap_bind = no

Aparte de esto tuve que configurar el SASL para que “viera” los usuarios en el servidor LDAP, en el fichero /etc/saslauthd.conf tuve que escribir estas líneas:

ldap_servers: ldap://ldap.dominio.com
ldap_bind_dn: cn=admin,dc=dominio,dc=com
ldap_bind_pw: password
ldap_search_base: ou=usuarios,dc=dominio,dc=com
ldap_filter: (uid=%U)
ldap_scope: sub
ldap_auth_method: bind

Bueno, espero sirva este manual, gracias por leerlo.

Para Migrar Al Software Libre

¿Qué gana en concreto una entidad con el uso total de software libre?
Muchas veces se pone adelante de todas las ventajas el ahorro monetario.
Según los sistemas instalados, sus costos, y las herramientas disponibles
para reemplazarlas, este ahorro puede ser realmente importante, pero puede
ser mermado a corto plazo por los costos de realizar la transición de los
sistemas. Aún así, existen muchas otras ventajas en el uso de software libre,
que son inmediatas y más importantes, al punto de ser cruciales para la
adopción de estas políticas por cualquier entidad:

• Independencia tecnológica: Mediante el uso de software libre, se deja de tener sus sistemas controlados por una entidad externa (confrecuencia empresas extranjeras). De esta forma rompe la dependencia tecnológica que lo tiene actualmente atado y obtiene las libertades que el software libre otorga.
  

• Control de la información: Esto sale directamente como consecuencia directa de las libertades del software libre. Al tener la libertad de inspeccionar el mecanismo de funcionamiento del software y la manera en que almacena los datos, y la posibilidad de modificar (ocontratar a alguien que modifique) estos aspectos, queda en sus manos la llave del acceso a la información (en vez de quedar en manos privadas).
  

• Confiabilidad y estabilidad: El software libre, al ser público, está sometido a la inspección de una multitud de personas, que pueden buscar problemas, solucionarlos, y compartir la solución con los demás. Debido a esto, y a lo que se llama "el principio de Linus" (dada la suficiente cantidad de ojos, cualquier error del software es evidente), los programas libres gozan de un excelente nivel de confiabilidad y estabilidad, requerido para las aplicaciones críticas de cualquier entidad.
  

• Seguridad: Este es uno de los puntos clave. Mucha de la información que se maneja puede ser peligrosa en manos incorrectas. Es por esto que es crítico que se pueda fiscalizar que su software no tenga puertas de entrada traseras, voluntarias o accidentales, y que pueda cerrarlas en caso de encontrarlas; tal inspección sólo es posible con el softwarelibre.
  

¿Qué problemas puede enfrentar implementar estas políticas?
Obviamente, una propuesta de implementación reduciría los beneficios de los
vendedores de software cerrado. Es de esperar que éstos ejerzan toda la
presión a su disposición para evitar que se tomen medidas que involucren
migración a software libre. Frente a ese peligro, hay que considerar que está
en juego el control de la información por parte de la entidad y las libertades
individuales de los usuarios. Debe tenerse en cuenta que una política de este
tipo no discrimina en contra de productos o proveedores específicos, sino
contra ciertas prácticas nocivas que involucran el control de la información del
usuario por parte del proveedor. Es fundamental no someterse a estas
presiones. Eso es lo que motiva las restricciones de esta política, que tienen
como fin establecer cualidades mínimas para garantizar los derechos de los
ciudadanos, la calidad del software y la seguridad de la información. Toda
empresa que acepte proveer sus productos sin comprometer estos derechos
no tendrá problema alguno al hacerlo.
¿No es conveniente dejar que se seleccione el mejor software, sea libre
o propietario?
Obviamente, a cualquiera le conviene elegir la solución más apta para sus
necesidades. La clave del problema está en el significado de "más apta". La
solución más apta no es necesariamente la solución más usada en el
mercado; muchas veces la solución más exitosa lo es solamente por que la
empresa que la promovió tuvo una mejor campaña publicitaria, porque atrapó
al mercado en un monopolio, porque hizo una buena movida comercial, etc.
Tampoco es necesariamente más apta la que tiene toda la funcionalidad
necesaria; se necesita más que eso: se necesita ser independiente
tecnológicamente, poder tener control sobre su propia información y poder
proteger la seguridad de sus datos. Esas son algunas de las aptitudes que
sólo el software libre puede otorgar, aptitudes que uno no puede dejar de
lado (sí puede dejar de lado, en cambio, funcionalidad no crítica). Por ello, la
solución más apta, sea cual fuere, será un programa libre; los programas no
libres tienen características que los hacen completamente inutilizables para
una entidad, por someterlo a riesgos importantísimos, aún cuando la solución
libre que se otorga, sea ligeramente menos funcional (mientras no se trate de
funcionalidad crítica), o más costosa.
¿No sería costosa una migración si se tiene algo que ya funciona?
Sí, lo sería. Una migración involucra costos en relevamientos, toma de
decisiones para implementar los nuevos sistemas, mano de obra para
implementar el cambio, conversión de datos, reentrenamiento del personal, y
eventualmente gastos en licencias y/o desarrollo (no todo el software libre es
gratis) y tiempo. Todos estos son costos fijos, que se pagan una vez. El
software propietario en funcionamiento ahora, también tuvo sus costos fijos
que fueron pagados y no pueden ser recuperados. Pero además de éstos,
hay otros costos involucrados en el software propietario: actualizaciones
permanentes (a veces acentuadas por un efecto de monopolio
autosostenido), pérdida de interoperabilidad, mantenimiento (con un
contratista con el monopolio sobre el mantenimiento, y capaz de cobrar lo
que quiera) y por sobre todo, el inmenso precio que tiene la pérdida de las
libertades que le garantizan el control de su propia información.
Estos costos son permanentes y crecientes a lo largo del tiempo (incluso si
sólo se consideran los monetarios), y tarde o temprano, superarán a los
costos fijos de realizar una migración. Por lo tanto, dado que la migración, a
la larga, nos beneficiará económicamente conviene llevarla a cabo lo antes
posible, en vez de esperar que los costos crezcan hasta volverse
incontrolables. Es un costo a corto plazo, pero un ahorro enorme a largo
plazo. Y que además produce beneficios mayores.
¿No es necesario ocultar el código en ciertas áreas?
¿La publicidad del código no facilita el acceso indebido a los criminales
informáticos?
El software de seguridad (que es el que está en discusión en esta pregunta)
es como un seguro de caja fuerte: aunque se sepa cómo funciona, es
necesario conocer la "clave" o "combinación" que su dueño fijó para abrirla.
La seguridad depende de la protección de esa combinación, no del
mecanismo en sí, siempre y cuando el mecanismo sea lo suficientemente
bueno.
Hay programas libres para usar los mecanismos de seguridad más fuertes
conocidos. El hecho de que sean libres les da una garantía de calidad, ya
que su publicidad permite que cualquiera pueda detectar y reparar los fallos y
riesgos a la seguridad que contenga. Cuando se oculta el funcionamiento,
sólo aquéllos que tienen intenciones de vulnerar esta seguridad se toman el
trabajo de desarmarlo y ver cómo funciona, aumentando el riesgo.
En resumen: es posible tener programas libres de máxima seguridad, y es
más fácil controlar que funcionen correctamente y auditarlos.
¿Forzar una política de uso de software libre no es equivalente a forzar
el uso de un producto determinado?
No es comparable el software libre a una marca determinada, ya que para
que un programa sea libre basta con que se otorguen las facultades
apropiadas al usuario, condición que cualquier empresa nacional o extranjera
puede cumplir. Esto es diferente a decir "se exige marca X", que es una
condición que sólo la empresa X puede cumplir. Además no hay imposición
sobre la libertad de decisión de los ciudadanos, ya que una política de uso
exclusivo de software libre es una decisión de la entidad y para la entidad, es
decir, de administración de sus sistemas internos. Es lo que le corresponde a
una administración: organizarse internamente de la mejor forma posible para
defender los derechos de los usuarios y trabajadores y proteger su propia
seguridad.
¿Cuales son los riesgos con el software propietario?
Gracias a las restricciones de libertades que impone el software propietario,
las organizaciones que desarrollan este tipo de software pueden (y lo han
hecho): Ocultar el código fuente para mantener a los desarrolladores
divididos, privados de derechos, y dependientes; atar productos inferiores a
los dominantes; violar y evitar órdenes judiciales de forma desafiante;
aplastar emprendimientos competitivos y prometedores; destruir mercados
para eliminar la competencia real; utilizar prácticas de depredación de precios
para eliminar a la competencia; transformar a sus clientes en objetos-
mercadería a través de la cautividad; hacer, mediante el ocultamiento del
código fuente, que los desarrolladores deban re-inventar la rueda
permanentemente; ejercer comportamiento extorsivo en sus tratos
comerciales; obligar a los competidores débiles a destruir sus propios
productos innovativos para proteger a los ya establecidos; no responder a las
necesidades y pedidos de los clientes en tiempo razonable; aprovechar
estrangulamientos económicos naturales para su propio beneficio; manipular
y demorar el progreso tecnológico para mantener la supremacía; esconder
sus errores de programación, arriesgando la seguridad y estabilidad;
introducir "puertas traseras" a sus programas para obtener acceso a la
información de sus clientes; deshumanizar a los desarrolladores de software
tratándolos como "ingresos" o "activos"; detener la innovación; tomar
estándares abiertos, adoptándolos y extendiéndolos, o contaminándolos de
otras formas, para romperlos y apropiárselos; usar cláusulas de exclusión en
contratos para sostener su censura a la publicación de errores y defectos;
apagar o bloquear los canales de distribución de competidores legítimos;
anunciar falsos avances ("vaporware") para evitar la adopción de productos
reales competitivos; frustrar, oponerse y burlarse de oficiales
gubernamentales que protegen el interés público; limitar la libertad de
elección; producirle confusión y frustración a los usuarios al venderle
productos inferiores; tomar las innovaciones desarrolladas por otros como
propias; practicar políticas de precios diferenciales para castigar a los que se
oponen; malinformar y explotar a los usuarios; usar características no
documentadas como un dispositivo anti-competencia; suprimir la naturaleza
abierta, eficiente y libre del método científico a través del ocultamiento del
código; romper intencionalmente el código de la competencia para crear
inoperabilidad de código entre productos; prohibir que la gente comparta el
software con sus amigos; forzar a sus usuarios a dejar pasar tecnologías
competitivas y prometedoras; usar contratos excesivamente restrictivos y
excluyentes contra competidores menores; y realizar otros actos impropios,
antisociales y anticompetitivos, para establecer, mantener y extender sus
monopolios de software.
Estas son todas razones por las cuales una entidad no debe usar software
propietario, arriesgando a sus clientes y trabajadores a que ellos o su
información pública sean sometidas a estas prácticas. Además y
principalmente, está en riesgo la independencia tecnológica, el control de la
información y la seguridad informática.