Encuentro Alternativo

Error from supplier: contains unsupported extensions CSR contains unsupported extensions

Este era el mensaje de error al generar el request del certificado (CSR) en un dominio alojado en un servidor cPanel, todo estaba perfecto, el dominio tenía una IP dedicada asignada, DNS bien apuntadas, todo excelente, pero a la hora de validar el CSR desde el proveedor de certificados SSL ese era el mensaje de error con que rebotaba.

Me tomó un tiempo averiguar la solución, pero finalmente aquí esta. Se trata de caracteres raros en el password del email de contacto del certificado, parece que cPanel y su generador de passwords incluye en muchos casos símbolos raros y especiales como “$”, “@”, “!”, entre otros, y no todos los proveedores de SSL parecen gustar de estos caracteres.

Solución, genera un password simple, con letras y números para el email de contacto, luego trata de generar otro CSR, debería funcionar.

Está abierto el caso en bugzilla: http://bugzilla.cpanel.net/show_bug.cgi?id=6394

Luego de haber usado durante 1 año la versión 7.04 de Ubuntu, procedí a actualizar mediante el gestor de actualizaciones y pude subir a 8.04. Lamentablemente esta versión me trajo muuuuchos problemas, se colgaba tanto o más que un Windows, así que se pueden imaginar. Fue un release muy prematuro, lleno de bugs y horrores por doquier.

Caliente, me decidí a instalar Debian Lenny y la verdad estoy encantado :D, cero cuelgues y una extraordinaria velocidad, instalación totalmente limpia desde internet con el formato netinst de 100 y pocos MB desde un DVD (no tenía CDs cuando lo quemé, se que es un desperdicio!).

Al ser un notebook (Dell Vostro 1500) el equipo donde lo instalé supuse que iba a tener problemas con los drivers, todo el hardware fue detectado perfectamente, incluso la tarjeta wireless integrada Broadcom así como la red alternativa de cable, video sin problemas y con altas resoluciones. Pero el sonido me dio problemas, bastantes, hasta que llegué a la solución, compilar todo a mano. Corremos los siguientes comandos para preparar el entorno, descargar y compilar:

aptitude install build-essential module-assistant
wget ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.16.tar.bz2
tar xvfz alsa-driver-1.0.16.tar.bz2
cd alsa-driver-1.0.16/
./configure && make && make install

Configuramos como paso final, cuando nuestra tarjeta sea detectada y damos siguiente con el comando:

alsaconf

Reinicia tu PC, o bien gdm y alsasound desde /etc/init.d/

Por ahora, bueno Debian.. vamos a ver más adelante como se comporta ante mis pruebas de estress

Vamos a documentar esto ya que el error de la función virtual fue bastante difícil de encontrar en la red, los recursos que hay nunca dan una solución.

Hoy a la madrugada tuve en mis manos un nuevo servidor RHEL 5.1 y procedí a restaurar algunos sitios que corrian archivos cgi (particularmente el script at3 de ArrowScripts) encontré con un problema referente a la función virtual, al parecer los archivos no podían ser incluídos usando dicha función. Esta función también puede reemplazarse por include o require, pero cuando cambiaba y usaba esas un error de compilación aparecía.

El código era este:

<?php virtual (”cgi-bin/at3/in.cgi”); ?>

Cgi estaba habilitado en el sitio, todo iba bien realmente, no entendía por qué no se podían realizar este tipo de includes. Hasta que mirando los logs de Apache pude ver erroes provenientes de otro sitio, pero que también usaba archivos cgi.

[Thu May 01 03:56:25 2008] [error] [client 99.163.176.182] in.cgi: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

En ese momento me di cuenta que faltaba una librería, investigando vi que era: compat-libstdc++

Para solucionar este error, simplemente instala el paquete compat-libstdc++, si no encuentra dicho paquete prueba con compat-libstdc++-33

Desde hace algún tiempo estaba buscando una utilidad que pudiera automatizar el trabajo de agregar registros SPF a cada dominio en un servidores RedHat Enterprise con cPanel, como no pude encontrar ninguna utilidad me dispuse a crear mi propia herramienta con un simple shell script (si, ya se que antes dije que no iba a programar más shell scripts, pero es lo más rápido y práctico que hay! :D). Éste es el resultado, SPFWiz, un script especialmente creado para ambientes de Hosting compartido, donde hay muchos sitios en un mismo servidor y la tarea de setear registros SPF en cada zona DNS se vuelve una tarea agobiante.

El funcionamiento del script es muy sencillo, recorre cada zona DNS y verifica si tiene un registro ya seteado, si no lo tiene muestra un mensaje de BAD en rojo y lo setea, si ya lo tenía simplemente muestra OK en verde. Imagina setear 200 registros, cuanto te tomaría hacerlo a mano, 45 minutos, 1 hora quizás? Con este script, tan solo 2 segudos

Advertencia: siempre haz un backup de la carpeta /var/named antes de realizar cualquier cambio a nivel global en la zonas DNS, y corre este script bajo tu propio riesgo, es una versión BETA, de puro testing.

Download | Código

Tutorial para servidores CentOS 3/4/5 y RedHat Enterprise 3/4/5

Muchas veces tenemos que migrar sitios de personas que poseen un sitio web X en X servidor, lo malo es que estas personas no tienen acceso root al server, sino solo FTP/cPanel. Hoy me paso este caso, y se me ocurrió una pequeña idea que dió resultado :D. Con esta forma, podremos bajarnos los backups utilizando la amplia transferencia de un servidor, cosa que agilizará mucho la migración, es casi igual de rápido como migrar usando SCP.

1.- Conectarnos a nuestro servidor mediante SSH. Loguearnos como root y correr el comando “lynx http://www.sitio.com/cpanel/“, si no tienes instalado Lynx, podrás instalarlo usando yum install lynx o bien up2date –install lynx (una vez lo hayas usado, te recomiendo desintalarlo, ya que es una potencial amenaza de seguridad: rpm -e lynx).

(more…)

Teniendo en cuenta el advenimiento de PHP 6, la ya estandarización definitiva de PHP 5 como versión estable de este lenguaje, y que PHP 4 dejará de tener soporte a finales del próximo mes de Diciembre, decidí actualizar un sistema con PHP 4.4.7 y Apache 1.3.3.9 a PHP 5.2.5, y Apache 2.0.61.

Todo el proceso de upgrade fue bien, por las dudas obviamente hice backups de los respectivos archivos de configuración de cada servicio. Luego del upgrade, procedí a reinstalar ciertos añadidos como ZendOptimizer, Eaccelerator, Mod_Security, etc, todo salió perfectamente y sin problemas.

Faltaba la verificación final de las páginas, por ello cargué página por página que había en este server, y todas me dieron bien, excepto una que usaba includes remotos, generaba el siguiente error:

URL file-access is disabled in the server configuration

Al parece la variable allow_url_fopen desaparece de php.ini, y debe ser reemplazada para que los includes remotos funcionen, simplemente reemplacen:

allow_url_fopen = On

Por:

allow_url_include = On

Luego de eso, reinician el servidor web y listo

Hoy un programador que trabaja en un servidor me solicitó hacer un upgrade a MySQL 5, la plataforma era RHEL 4. Esta versión de RHEL (al igual que la 3) traen por defecto las ramas 4.x de MySQL (al igual que PHP), la forma más simple de hacer el upgrade hacia MySQL 5 fué esta:

Detenemos MySQL

service mysql stop
mkdir /root/temp && cd /root/temp

Bajamos los paquetes server, client,  shared compatibility libraries y devel como RPM desde: http://dev.mysql.com/downloads/mysql/5.0.html#downloads

Actualizamos

rpm -Uvh MySQL-server-community-5.0.45-0.rhel4.i386.rpm
rpm -Uvh MySQL-client-community-5.0.45-0.rhel4.i386.rpm
rpm -Uvh MySQL-shared-compat-5.0.45-0.rhel4.i386.rpm
rpm -Uvh MySQL-devel-community-5.0.45-0.rhel4.i386.rpm

Editamos el archivo /etc/my.cnf y comentamos la variable base_dir.

pico /etc/my.cnf

Finalmente, agregamos el usuario MySQL, seteamos propietarios y reiniciamos el servicio:

adduser mysql
chown -R mysql:mysql /var/lib/mysql
service mysql start

Luego de esto, deberia estar todo normal corriendo bajo MySQL 5.x

eAccelerator es un acelerador y optimizador de scripts PHP, además también sirve para reducir la carga de servidores con alto consumo de PHP, al menos a mi siempre me ha sido muy útil, sus versiones actuales tienen soporte para PHP 4.x.x y 5.x, este tutorial cubrirá su instalación y configuración en el servidor, todo lo expuesto está testeado en servidores RedHat Enterprise 3 y 4 bajo cPanel, pero en CentOS 3 y 4 también debería funcionar.

Copia de seguridad en caso de que algo salga mal:

cp /usr/local/lib/php.ini /usr/local/lib/php.ini.bak

Comenzamos la instalación

ea=/usr/local/eainstall
bz=eaccelerator-0.9.5.2
mkdir $ea && cd $ea
wget http://ufpr.dl.sourceforge.net/sourceforge/eaccelerator/$bz.tar.bz2
tar -xjvpf $bz.tar.bz2
cd $bz
export PHP_PREFIX=”/usr”
$PHP_PREFIX/bin/phpize
./configure –enable-eaccelerator=shared –with-php-config=$PHP_PREFIX/bin/php-config
make
make install
mkdir /php-cache
chmod 0777 /php-cache
cp /usr/lib/php/extensions/no-debug-non-zts-20020429/eaccelerator.so /usr/lib/php/extensions/ -fv –reply=yes

Configuramos las opciones en php.ini (copiar y pegar todas las líneas de una sola vez)

echo ‘
;;eAccelerator
extension=”eaccelerator.so”
eaccelerator.shm_size=”16″
eaccelerator.cache_dir=”/php-cache”
eaccelerator.enable=”1″
eaccelerator.optimizer=”1″
eaccelerator.check_mtime=”1″
eaccelerator.debug=”0″
eaccelerator.filter=”"
eaccelerator.shm_max=”0″
eaccelerator.shm_ttl=”0″
eaccelerator.shm_prune_period=”0″
eaccelerator.shm_only=”0″
eaccelerator.compress=”0″‘ >> /usr/local/lib/php.ini

Reiniciamos apache:

/etc/init.d/httpd restart

Para verificar si está correctamente instalado, tipeamos ‘php -v‘, debería aparecer algo como esto:

PHP 4.4.7 (cli) (built: Aug 11 2007 00:21:49)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
with eAccelerator v0.9.5.2, Copyright (c) 2004-2006 eAccelerator, by eAccelerator

Si no se muestra, prueben editar el archivo php.ini:

pico /usr/local/lib/php.ini

y dejan la variable “extension_dir” como se muestra aquí:

extension_dir = “/usr/lib/php/extensions/”

Finalmente reinician apache y verifican con ‘php -v‘:

/etc/init.d/httpd restart

Tenía un tema pendiente para publicar en este blog, y era sobre cómo conectar a un servidor SSH sin usar password. La conexión se realiza a través de llaves púbicas, dándonos la posibilidad de realizar diversas tareas con mayor potencia que al usar passwords, backups remotos automatizados, logueos más rápidos, sincronización de archivos, etc, etc.

Primero, desde la terminal origen (tu pc por ejemplo) generaremos nuestra clave privada:

ssh-keygen -t dsa

Nos pedirá un password, simplemente, le damos enter a todo, sin especificar password.

Luego veremos que contiene el archivo con la clave generada leyendo su contenido:

cat ~/.ssh/id_dsa.pub

Verás que por la pantalla sale un montón de datos, debes copiarlos desde el primero hasta el último caracter, señalas el código y lo copias.

Luego de eso, nos vamos al servidor SSH al cual queremos loguearnos, una vez allí nos movemos hacia el /home del usuario al que conectaremos (sea root u otro usuario primario) y nos aseguramos que el directorio .ssh existe, creamos y seteamos permisos a archivos necesarios.

mkdir ~/.ssh ; chmod 700 ~/.ssh ; cd ~/.ssh
touch authorized_keys ; chmod 644 authorized_keys

Ahora solo resta que pegues el contenido que copiaste del archivo ~/.ssh/id_dsa.pub en el archivo que acabamos de crear: authorized_keys

Puedes editar el archivo authorized_keys tipeando:

nano authorized_keys

Luego pega el contenido, y para guardar el archivo presiona CTRL + W, y luego “S” o “Y”.

Pues, ya está, ahora deberías poder loguearte sin password desde la terminal origen al server destino.

La parte mala de todo esto, es que si alguien roba tu clave privada, seguramente podrán loguearse a tus servidores, pero como todo, existen medidas alternativas para prevenir eso, que explicaré próximamente.

El otro día estaba investigando un problema de correos en un servidor de los que administro, por alguna razón, los correos enviados desde todas las casillas del dominio pepito.com (dominio ficticio) no podían enviar correos a hotmail.com, primero el problema se dió desde un formulario en PHP, luego verificando, vi que también afectaba a envíos desde webmail usando IMAP o clientes de correo con POP3. Verificando los logs de Exim pude ver (además de la información del envío del mail) lo siguiente que resaltaba entre todo el logueo:

550 Your e-mail was rejected for policy reasons on this gateway.
Reasons for rejection may be related to content with spam-like
characteristics or IP/domain reputation problems. If you are not an
e-mail/network admin please contact your E-mail/Internet Service
Provider for help. For e-mail delivery information, please go to
http://postmaster.live.com

Investigando en listas y foros, llegué a saber que hotmail está denegando (o enviando los correos hacia la carpeta SPAM directametne) muchas conexiones de hosts que no poseen registros SPF activados en la zona DNS del dominio, es una forma más de protegerse contra la falsificación de correos.

Para solucionarlo, encontré un sitio que te ayuda a generar el registro SPF (http://openspf.org) para luego insertarlo en la zona DNS de tu dominio, el siguiente es un registro SPF genérico que he generado que funciona en la mayoría de los casos, para insertarlo:

Editamos la zona DNS

pico /var/named/domini.com.db

Y agregamos al final de la zona el siguiente texto, hay que reemplazar dominio.com, ip-del-servidor (por la ip del server) y hostname-del-serer por el hostname real del servidor:

dominio.com. 14400 IN TXT “v=spf1 ip4:ip-del-servidor a mx a:hostname-del-server ~all”

Luego solo resta resteartear el servidor de nombres, en este caso bind y esperar la propagación de las DNS unas 48-72 horas:

/etc/init.d/named restart

Finalmente, debemos agregar nuestra IP a https://postmaster.live.com/snds/addnetwork.aspx , además también debes llenar el siguiente formulario https://support.msn.com/eform.aspx?productKey=senderid&ct=eformts especificando si tienes registro SPF y los dominios que quieres agregar a la lista de SenderID de Microsoft.

Este tutorial se aplica a servidores cPanel, bajo CentOS y RedHat Enterprise 3 y 4.