por mstislav | May 29, 2012 | Linux
Ando en este momento probando y migrando las cuentas de correo de la empresa a Google Apps (maravilla, por cierto) y me encuentro con que con el cambio, varios destinatarios de email tachan a los emails salientes del servidor nuestro como spam.
Investigando, observo que la cabecera de uno indica:
Received-SPF: neutral (google.com: 62.81.224.69 is neither permitted nor denied by best guess record for domain of usuario@dominio.com) client-ip=62.81.224.69;
Authentication-Results: mx.google.com; spf=neutral (google.com: 62.81.224.69 is neither permitted nor denied by best guess record for domain of usuario@dominio.com) smtp.mail=usuario@dominio.com
¿Qué es esto?
Para combatir el spam se desarrolló hace unos años el SPF (The Sender Policy Framework). Consiste en definir en los DNS del dominio a proteger qué IPs o máquinas están autorizadas para enviar correo de ese dominio. ¿Cuáles son estas IPs o máquinas?
Si al enviar un correo desde mi dirección loquesea@crein.com, y mi servidor de salida smtp es mail.crein.com, pues tendré que autorizar a mail.crein.com para que pueda enviar correo de loquesea@crein.com. Esto no siempre es así, porque dependiendo de diversas circunstancias es preciso en ocasiones autozar a más máquinas a enviar correos de determinado servidor (servidores web, servidores caseros…)
En la otra parte del asunto está el servidor receptor del email. Al llegar comprobará que el email que viene de loquesea@crein.com está autorizado a venir desde mail.crein.com
¿Cómo hace esto?
Consultando los DNS de crein.com. Si existe un registro SPF adecuado y bien configurado, indicará que mail.crein.com es una máquina autorizada a enviar mails de loquesea@crein.com y el email se tildará como legítimo. En caso contrario… unos servidores lo aceptan, otros lo rechazan y otros lo aceptan pero marcando como spam.
Hay miles de webs que hablan de la sintaxis de los registros SPF. Por poner un ejemplo, en la wikipedia está bastante bien documentado. Tan sólo citar una que me ha parecido interesante: SPF Record Testing Tools. Realiza un testeo de los SPF de los dominios que indiquemos.
por mstislav | Abr 26, 2012 | PHP
Si usamos PHP con Apache en Linux y la función de PHP mail() nos encontraremos con que, efectivamente el email se envía, pero el envelope generado es usuario_de_apache@localhostname en el mail from.
El problema de esto es que algunos servidores de correo rebotan este email porque el dominio no existe (lógicamente). Además, en caso de que el destinatario no exista, o tenga problemas, el mensaje rebotado retornará a nuestro servidor de correo, permaneciendo en una cola sin solución aparente.
Además, si añadimos un Header en el cuarto campo de la función mail(), cambiaremos el campo From en la cabecera del body del mensaje, pero no cambiaremos el envelope mail from.
La solución es sencilla. La función mail() tiene un 4 y 5º parámetro (opcionales). Es precisamente el 5º parámetro el que puede pasar determinadas opciones directamente a sendmail. Quedaría así:
mail('to@destinatario.com','subject!','body!','From: remitente
@dominio_remitente.com','-f remitente
@dominio_remitente.com
');
por mstislav | Jun 28, 2011 | Linux, Técnico
El otro día observé que las conexiones web a uno de nuestos servidores estaba tremendamente ralentizada
Hace unos minutos habrán notado que este blog y el resto de los blogs alojados en nuestro servidor dedicado iban bastante lentos. He mirado los logs y me he encontrado con una infinita lista de mensajes como este:
::1 – – [08/May/2011:07:12:03 +0200] «OPTIONS * HTTP/1.0» 200 – «-» «Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g (internal dummy connection)»
::1 – – [08/May/2011:07:24:12 +0200] «OPTIONS * HTTP/1.0» 200 – «-» «Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g (internal dummy connection)»
::1 – – [08/May/2011:07:41:34 +0200] «OPTIONS * HTTP/1.0» 200 – «-» «Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g (internal dummy connection)»
::1 – – [08/May/2011:07:41:35 +0200] «OPTIONS * HTTP/1.0» 200 – «-» «Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g (internal dummy connection)»
::1 – – [08/May/2011:07:41:36 +0200] «OPTIONS * HTTP/1.0» 200 – «-» «Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g (internal dummy connection)»
::1 – – [08/May/2011:07:41:37 +0200] «OPTIONS * HTTP/1.0» 200 – «-» «Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g (internal dummy connection)»
Además accediendo por ssh y ejecutando el comando top -c mostraba un infinito número de procesos root ejecutándose en la máquina. Ya os podéis imaginar el susto que me he llevado. He acudido rápidamente al Gran Hermano Google y, afortunadamente, he hallado la solución rápidamente. En realidad no había motivo de alarma, más allá de la ralentización provocada. Esos internal dummy connection no son más que llamadas del propio servidor hacia sí mismo, que al parecer se realizan cuando hay muchas peticiones, mucho tráfico entrante, y no es capaz de atenderlas a todas.
La solución es bien sencilla, tan sólo hay que colocar estas líneas en el archivo .htaccess del dominio principal del servidor:
RewriteCond %{HTTP_USER_AGENT} ^.*internal dummy connection.*$ [NC]
RewriteRule .* - [F,L]
por mstislav | Jun 7, 2011 | Linux, Técnico
[meño_on] Si tenemos varios equipos en su casa o en la oficina, el almacenamiento centralizado puede ser una tarea bastante desesperante. De forma hipotética, lo que queremos es que los archivos estén disponibles para todos los equipos. Con esto lo que podemos perseguir es tener un backup centralizado de todo, o tener un lugar en el que compartir todos los ficheros para todos los equipos. Hay varias maneras de lograr esto.
Para los usuarios de Windows, la forma más fácil es activar el intercambio de archivos (compartir, en otras palabras), pero hacerlo expone los archivos a un riesgo potencial importante de seguridad; además el rendimiento no es precisamente una maravilla. Es una solución perfecta para transfencia y/o almacenaje ocasional de archivos, pero no lo suficientemente rápido como para usar y abrir los archivos en tiempo real de un ordenador a otro. Además, compartir archivos en Windows no es tampoco la mejor opción para entornos con múltiples sistemas operativos como Mac OSX y Linux.
Una opción es utilizar un hardware basado en NAS (Network Attached Storage). Varios fabricantes ofrecen soluciones para compartir unidades de disco individuales. Estos dispositivos a menudo vienen en un tamaño reducido y son fáciles de instalar. Sólo tenemos que añadir una o más unidades de disco duro y conectarlo a la red Ethernet para comenzar a compartir archivos. Si bien esta es una buena opción para aquellos que quieren un sistema fácil, tiene algunas desventajas en comparación con la construcción de un sistema NAS que utilice un PC como base.
Desventajas de los sistemas NAS autónomos:
- Menos opciones de expansión. La mayoría de ellos tienen 3-4 bahías de expansión para introducir discos duros en su interior. Si se quedan cortos, en ocasiones existe la posibilidad de conectar unidades externas vía USB 2 o eSATA. El problema de añadir dispositivos externos es que se multiplican las posibilidades de fallo…
- Presentan un rendimiento potencialmente menor, ya que suelen usar CPUs de bajo consumo, poca memoria y conexiones Ethernet poco rápidas.
- Son menos flexibles, ya que suelen incorporar software propietario.
Algunas ventajas:
- Son sistemas muy fáciles de usar. No tenemos que comernos la cabeza con instalaciones complejas/más complejas/complejísimas.
- El hardware habitualmente está correctamente testeado y es perfectamente compatible entre sí. No tiene sentido que te vendan un NAS en el que la memoria da problemas de compatibilidad con la CPU…
Si queremos hacernos nuestro NAS basado en un PC, y tenemos una antigua máquina por casa o en la oficina muerta de la risa, lo tenemos muy fácil. De momento he encontrado dos alternativas fáciles posibles: Openfiler y FreeNAS.
Ventajas respecto a un NAS propietario:
- Al ser OS UNIX hablamos de sistemas robustos, seguros y gratuitos.
- Son soluciones potentes y altamente escalables. Incluso un PC viejo muerto de la risa es perfecto para construir un NAS.FreeNAS requiere una CPU Pentium con al menost 64 mb RAM mientras que Openfiler requiere una CPU de 32 bits con al menos 512 MB de RAM.
- Podemos ejecutar comandos UNIX en ellas, aplicaciones UNIX, retocar/tocar/construir cositas…
- Alto rendimiento. Posibilidad de instalar varias tarjetas de red funcionando simultáneamente. Esta posibilidad es muy interesante, podemos balancear la carga, crear conexiones de seguridad, redundantes…
- Se pueden implantar cositas que te harán la vida más fácil: servidor FTP, cliente bittorrent, administrador de impresoras, conexiones https, uso de rsync, VPNs, acceso LDAP, conexiones iSCSI, …
Y algunas desventajas:
- Hablamos de UNIX/Linux… [modo_caspa_on]. Linux/UNIX a veces puede ser un poco críptico. No esperes tener un manual de usuario encuadernado y en tapa dura 🙂
- Posibilidad de existir conflictos de hardware y problemas de configuración.
- Mayor tamaño y consumos de energía mayores que un NAS box.
Mis necesidades son las siguientes:
- Tengo unos 10 PCs en el trabajo y necesito un sistema en red en el que compartir de forma comunitaria los archivos.
- Dicho sistema calculo que puede rondar, para trabajar de forma holgada, en unos 2 Tb de capacidad.
- Necesito redundancia de datos, bien en la propia máquina o en una remota en espejo.
- Necesito altas velocidades de transferencia. Se manejan ficheros de cierto tamaño.
- Se requiere fiabilidad en la conexión. Muchos ficheros se van a editar a través de la red local. Un corte en la conexión de red debe estar contemplado y manejado.
- Debe ser un sistema que me permita hacer backup de mis servidores web/correo de manera fácil.
Visto todo esto, me decanto por lo siguiente:
- Dos discos duros sATA barracuda Green de 2 Tb para trabajar en Raid 1. Prefiero lógicamente seguridad y redundancia en vez de un Raid 0 que vía ethernet me va a aportar más bien poco. Descartado el Raid 5 por pasta… ¡por algún lado hay que cortar!
- Tarjetas de red Gigabit para todo el mundo. Muchas de las placas madres ya las incorporan, pero hay alguna que todavía usa 10/100 MBps.
- Un switch 3Com de 24 puertos Gigabit.
- Cableado de red de calidad. De nada sirve tener conexiones Gigabit o 10GigaBit y los cables son una castaña.
Y la pregunta del millón: ¿FreeNAS o Openfiler?
He leido hasta la saciedad pros y contras de cada uno de ellos. En términos generales se suele hablar de un mayor rendimiento de Openfiler, pero lo cierto es que la nueva release de FreeNas 8.0 gana cada vez gana más adeptos. Ha sido reescrita desde cero respecto a anteriores versiones y además incorpora el sistema de ficheros ZFS (las ventajas de usar ZFS son muchas). En Openfiler hay una cosita que me toca un poco los pies… ¡la documentación es de pago!
Hay innumerables diferencias entre ambos sistemas. Con un poco de Google se encuentran numerosos reviews que comparan ambos sistemas.
En principio me he decantado por usar FreeNas. Me ha encantado la idea de que el sistema base pueda incluirse en un pendrive de 1Gb. Esto te permite la posibilidad de usar todas las conexiones IDE/SATA para discos. Además, me quito un disco duro de encima… con las posibilidades de error, ruido y calor que conlleva.
¿Problemas? Unos cuantos:
- Si queremos usar ZFS hay que irse a una arquitectura de 64 bits. Existen versiones i386 y amd64 de FreeNas. El problema es que ZFS devora máquina y memoria. Hay quien recomienda al menos 4 Gb de ram y arquitectura amd64 para un sistema decente. Se habla incluso de 1 Gb de memoria ram extra por cada Tb de HD.
- Mi error: implantar un ZFS con los dos HDs de 2 Tb en raid 1 en un pc no demasiado moderno con 1 Gb de ram y una distro de FreeNas i386. Al poco tiempo empezaron a aparecer kernel panics de la forma kmem_malloc error. El error está bastante documentado pero no hay tu tía… he tenido que pillar una palca nueva y más memoria para implantar el NAS.
- El sistema recién instalado requiere rebootear. Me volví loco un buen rato probando opciones que no funcionaban. Al instalar… rebootea.
- La velocidad de momento no está mal, aunque necesito optimizarla. Me copia 1 Gb en menos de 30 segundos. Seguiré trabajando en ello…
- Los cuelgues que he tenido debido al kernel panic han sido nobles (hablando en términos taurinos). He reiniciado y todo estaba en su sitio. No se ha perdido información y no ha habido desastre alguno.
- ¡La password de root para acceder vía consola no cambia, aunque la cambies en una sesión SSH! hay que cambiarlo en el GUI web.
- La sincronización vía rsync con los servidores web/correo no ha dado ningún problema. Es una manera fácil y barata de tener todo con copia de seguridad.
- FreeNas se basa en FreeBSD. No he usado nunca FreeBSD y controlo poco… aunque al final todo se parece a todo…
- La password de root para acceso ssh no es el usuario/pass que se introdujo en la instalación. Ésta es siempre admin/freenas por defecto. (recuerda… cambiar vía web en la GUI…).
- De momento el NAS tiene sólo una tarjeta Gigabit. Mañana podré 1-2 más y jugaré con las opciones que ello me brinda (redundancia, balanceo de carga… suena interesante).
- La GUI me gusta. Simple y práctica, aunque echo de menos algunas cosas: acceder a crontabs, algunos comandos básicos de linux…
- El sistema para compartir ficheros tanto en Linux, como en Windows como en Mac ha funcionado a la maravilla desde el primer momento.
- Tengo pendiente monitorizarlo vía SNMP con Cacti. FreeNas permite hacerlo en principio sin problema.
- El sistema permite envía emails al admin con incidencias y avisos. Es una opción que me encanta de los raid por soft: te enteras de cosas que mediante los raid por hard en ocasiones ni hueles (a no ser que estén bien gestionados…).
- La instalación desde una ISO en CD al pendrive de 1 Gb ha ido sin problemas. Instalas el soft, arrancas desde el USB, y ya puedes acceder al NAS directamente.
Una curiosidad: en el desarrollo de FreeNas hubo una facción rebelde que se separó y se dedicó a migrarlo a Debian 🙂 El proyecto es Open Media Vault y parece que está a punto de salir a la luz. Me encantaría usar mis apt-gets para gestionar y actualizar mi NAS, pero ya veremos.
Hay otra alternativa a todo esto: montar un servidor Linux con lvm, samba, apache, ftp, smartmontools, hddtemp, rsync, … a pelo. Pero eso es harina de otro costal.
[meño_off]
por mstislav | Abr 26, 2011 | Técnico
Cuando subimos algún tipo de información a internet, y sobre todo consta en grandes páginas tipo google, el proceso de eliminar o editar dicha información puede ser realmente complejo.
¡¡Cuántas personas no saben qué hacer para eliminar su nombre, una noticia o una foto de ellos que pulula de caché en caché por internet!!
El problema básicamente reside en que los grandes sistemas no borran completamente su memoria caché (memoria empleada para transacciones cortas). En otras ocasiones la borran, pero pasado un año, con lo cual, siguen fastidiando lo mismo.
En ocasiones el caché de Facebook puede jugar una mala pasada (lo digo por experiencia). Además debemos de recordar que hemos consentido y firmado al crear nuestra cuenta en Facebook que lo que subimos a Facebook ya es propiedad de ellos así que… ¡¡ojo con las fotos que se envían a Facebook!!
Pero al grano: si intentamos hacer un link a una url de una web nuestra, por ejemplo, y que previamente ya hemos linkado, corremos el peligro de que Facebook tire de caché, en vez de la página real. Por lo visto tampoco está exento de errores el sistema de caché empleado.
Incluso puede usar el caché para páginas con distinto nombre, pero con cierta semejanza en contenido. No sé como es posible, pero lo hace (doy fe).
El truco consiste en enviar la url junto con algún dato inventado via GET. Por ejemplo, en vez de usar http://www.mstislav.com podemos enviar http://www.mstislav.com?loquesea=33429
Con este sencillo truco, Facebook interpreta que la url es nueva y la procesa de nuevo.
El truco funciona tanto cuando construimos nosotros vía javascript el enlace a compartir como cuando utilizamos los widgets. El enlace que envía a la página dónde va a estar instalado el widget debe agregar esa variable querystring.
por mstislav | Abr 26, 2011 | General, Técnico
Ha ocurrido. El otro día estuve investigando (gracias a Wirtanen por el descubrimiento) sobre WordPress y me entró la terrible sensación de que al crear íntegramente mi blog a pelo estaba luchando contracorriente.
la cantidad de facilidades, integración y sobre todo estandarización que ofrece WordPress es realmente impresionante.
Me he currado un Theme, imitando en lo posible a la estética de mi anterior blog y lo he puesto en marcha.
Ahora puedo hacer bastantes cosas más… incluso postear directamente desde mi iPhone con una app nativa.
Me queda hacer lo mismo con los dos blogs de Evaluna… pero bueno… con la experiencia adquirida será cuestión de un rato (espero).