Tuesday, November 27, 2012

SSL en IP compartida y suPHP en WHM

Otro poste seguidito para gestionar servidores virtuales (VPS) con WHM. Este post está relacionado con:

  • SSL en VPS con WHM
  • SSL con suPHP
  • Error 500 Internal Server Error despues de instalar certificado SSL al correr scripts PHP
  • Error "Mismatch between target UID (99) and UID (xxx) of file"
  • Error al correr scripts PHP en un servidor SSL con IP compartida (shared IP)

En este post voy a compartir como hacer que un dominio corra SSL con una IP compartida mientras se usa suPHP.

Actualmente tengo un servidor VPS corriendo suPHP por razones de seguridad. Para los que no saben, suPHP ejecuta cada script como su propietario en vez de como el usuario "nobody" (que se usa cuando PHP corre como móduilo DSO de Apache), previniendo que un script tenga acceso a los archivos de otros usuarios en el sistema.

Las versiones recientes de cPanel/WHM previenen mas o menos configurar un dominio con SSL (https) en una dirección IP compartida. Si quieres correr SSL en un dominio sobre una IP compartida, el certificado y la llave (key) deben ser configuradas como el usuario "nobody". El dominio funcionará bien, pero si corres un script PHP en ese dominio, no funcionará porque intenta correr como el usuario "nobody" y suPHP lo bloquea, mandando un error "500 Internal Server Error".

Así que lo que hay que hacer es lo siguiente (recuerda que necesitas acceso a WHM y vía SSH como root):

1) Ve a WHM y da click en "Install an SSL Certificate and Setup the Domain". Ahí puedes seleccionar a cargar tus archivos de cerificado (.crt y .key). Hay muchos tutoriales que muestran cómo generar certificados autofirmados (self-signed) inclusive desde WHM, o puedes obtener un certificado desde un CA.

2) En el campo "Domain" escribe el nombre de dominio que quieres configurar con SSL. Como ejemplo, usaremos el dominio "seguro.domino.net", que es propiedad del usuario de cPanel "usuariochido".

3) En el campo "User", escribe "nobody" (sí, nobody - sin comillas)

4) En el campo "IP Address" escribe tu dirección IP compartida (si no se autollenó el campo)

5) Pega o carga tus archivos .CRT y .KEY

6) Da click en Submit

Ya tienes tu dominio listo. Ahora te puedes conectar a https://seguro.dominio.net y va a funcionar, excepto por los scripts PHP. Para hacer correr los scripts PHP con suPHP en ese dominio con SSL, hay que hacer lo siguiente:

1) Conéctate vía SSH a tu servidor como root (u otro usuario con los permisos adecuados)

2) Cámbiate al directorio /var/cpanel/userdata/nobody, y escribe "ls" para obtener el listado del directorio

3) Debes de ver un archivo llamado "seguro.dominio.net_SSL" (con el dominio real, por supuesto)

4) Mueve ese archivo a /var/cpanel/userdata/usuariochido. Para eso puedes hacer:

mv ./seguro.dominio.net_SSL /var/cpanel/userdata/usuariochido/seguro.dominio.net_SSL

(Recuerda que estamos usando seguro.dominio.net y usuariochido como ejemplos; debes reemplazarlos con el dominio y nombre de usuario verdaderos)

5) Edita el archivo /var/cpanel/userdata/usuariochido/seguro.dominio.net_SSL usando un editor como nano o vi. Debes cambiar estas líneas:

documentroot: /home/usuariochido/public_html/seguro
homedir: /home/usuariochido
user: usuariochido
group: usuariochido

6) Ejecuta los siguientes comando para reconfigurar apache y reiniciarlo:

/scripts/rebuildhttpdconf
service httpd restart

O puedes saltarte "service httpd restart" y reiniciar Apache desde WHM, si prefieres.

7) Pruébalo.

Espero que esta info sea de ayuda =)

Reloj de sistema en VPS con WHM/cPanel no está sincronizado

Este post va relacionado con:


  • NTP (Network Time Protocol) y su demonio NTPD
  • WHM y cPanel Time
  • Dovecot error "time just moved backwards"
  • Tiempo del servidor fuera de sincronización
  • Servidor VPS Linux (CentOS, WHM) con error de tiempo
  • Problema Time Drift, Time Skew, Clock Drift o Clock Skew


Hace unos días que me conseguí un VPS corriendo CentOS con WHM. Desde el principio noté que el IMAP (Dovecot) se reiniciaba con el mensaje de error "Time just moved backwards". Esto pasaba siempre después de realizar una sincronización de tiempo o cambiar la zona horaria.

Resulta que hay un efecto llamado "Time Skew" o "Time Drift" que ocurre en algunos sistemas (sobretodo VPS) que hace que el tiempo vaya más rápido de lo normal. Día tras día encontraba que el reloj del servidor VPS estaba adelantado unos 25 minutos. Esto es un problema crítico.

Después de bastante búsqueda, encontré dos posibles soluciones:

1) Instalar NTP
NTP (Network Time Protocol) es un servicio que nos permite sincronizar el reloj del sistema con internet. Al instalarlo, se instala también el demonio NTPD que ajusta  el reloj automaticamente y lo acelera o desacelera según sea necesario.

Para instalarlo basta con entrar como root vía SSH al VPS y ejecutar

yum install ntp

seguido de

/sbin/chkconfig ntpd on

(este último para que se inicie automaticamente el demonio al reiniciar el servidor).

Después tenemos que modificar el archivo /etc/ntp.conf con un editor como nano o vi. Lo que vamos a hacer es añadir la siguiente línea:

restrict default kod nomodify notrap

y comentar las siguientes (poniendo un gato # al inicio de cada una):

server 127.127.1.0
fudge 127.127.1.0 stratum 10

Guardamos el archivo de configuración. Reiniciamos NTPD y lo configuramos para que se inicie al rebootear el sistema:

service ntpd restart
/scripts/chkconfig ntpd on

Adicionalmente, si tenemos firewall hay que abrir el puerto 123 en UDP. Si tienes WHM con CSF+LDF, ingresa a WHM y ve a la opción "ConfigServer Security & Firewall", da click en el botón "Firewall configuration" y en la opción "UDP_OUT" añade el puerto 123.


2) Modificar el booteo (arranque)
Esta solución es la mejor (combinada con NTP) para un servidor VPS Linux que corre en Hyper-V sobre Windows Server 2008. Para esto, hay que entrar como root vía SSH al servidor VPS, y modificar el archivo /boot/grub/grub.conf.

En ese archivo encontraremos varios Kernels. En el Kernel predeterminado (generalmente el primero) hay que modificar la línea que inicia con "kernel /vmlinuz", agregandole al final "divider=10 clocksource=acpi_pm" (para 32 bits) o "notsc divider=10" (para 64 bits). Nuestro archivo debe quedar algo así:

#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
#          initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-164.6.1.el5)
 root (hd0,0)
 kernel /vmlinuz-2.6.18-164.6.1.el5 ro root=/dev/VolGroup00/LogVol00 hda=noprobe db=noprobe notsc divider=10
 initrd /initrd-2.6.18-164.6.1.el5.img
title CentOS (2.6.18-164.el5)
 root (hd0,0)
 kernel /vmlinuz-2.6.18-164.el5 ro root=/dev/VolGroup00/LogVol00
 initrd /initrd-2.6.18-164.el5.img

Después de modificar y guardar grub.conf, debemos ejecutar una sincronización manual del reloj y reiniciar el servidor usando los siguientes comandos:

service stop ntpd
ntpdate 0.pool.ntp.org
hwclock --systohc
reboot

3) Configurar el WallClock
Si NTP y la modificación de arranque no te funcionan, hay que desvincular el reloj del VPS de su nodo. Generalmente la vinculación del nodo VPS causa el Time Skew. Para hacerlo, hay que ingresar como root via SSH al VPS y ejecutar lo siguiente:

echo 1 > /proc/sys/xen/independent_wallclock

Si queremos que la configuración sea persistente después de un reinicio, debemos modificar el archivo "/etc/sysctl.conf" con un editor como nano o vi, y añadir la siguiente linea:

xen.independent_wallclock = 1

Con esto queda configurado nuestro servidor y ya no debemos de tener problemas con el tiempo. Si los problemas con la sincronización siguen, tal vez se deba a un problema de Kernel y debemos solicitar a nuestro proveedor del VPS que haga una actualización de Kernel.


Tuesday, August 28, 2012

Configurar Google Apps con WHM/cPanel

¿Cómo configurar Google Apps (Gmail, Calendar, Drive, etc.) en un hospedaje con WHM/cPanel?

Desde hace tiempo que tengo Google Apps configurado para mi dominio (gururojo.com) y me está funcionando de lujo. La sincronización del calendario y GMail con mi celular Android es espectacular, además de muy seguro.

He estado recientemente recomendando a mis clientes de Hosting que usen Google Apps para sus dominios. Algunos de ellos han aceptado, otros no. Hoy configuré Google Apps para 3 dominios, y después de hacerlo decidí escribir este post sobre esa configuración (Google Apps en cPanel/WHM) para que sea una información de ayuda para todos.

La configuración es muy sencilla, y va como sigue (suponiendo que ya cuentas con un dominio y cPanel/WHM). También asumo que ya tienes conocimientos básicos del manejo de dominios web con cPanel/WHM y nociones generales de lo que es el DNS.

1 - Registrarse en Google Apps para Empresas
Ingresa a http://www.google.com/a/cpanel/domain/new donde podrás registrar una cuenta gratuita. Te va a pedir el dominio, lo escribes y le picas al botón "Enviar" (Submit). Después rellenas la demás información que te pide, y picas en "Acepto, Crear mi cuenta".

Selecciona el asistente de la derecha. Te va a pedir que verifiques la propiedad del dominio subiendo un archivo .html a la raíz del dominio. Descargas el archivo, lo subes a tu dominio y le das "Verificar". Después de eso, seguirá el asistente de Google Apps. Puedes Saltarte los pasos si quieres, ya que la mayoría de las cosas las haremos manualmente, aunque antes de cualquier cosa te recomiendo agregar a todos los usuarios que tendrás en Google Apps (Gmail, Drive, etc.). Este proceso es muy sencillo y Google te guiará facilmente.

2 - Configurar los registros MX para Google Apps en WHM
Primero vamos a dar click en el menú "Setup" de Google Apps. A la izquierda vamos a seleccionar "Set up your apps", le damos Siguiente y Siguiente hasta que pregunte "Cómo deseas enrutar tu correo?" (How do you want to route your mail?), seleccionamos Google Servers y  le damos Next.

Ahora, nos vamos al panel de control WHM en nuestro hosting. Vamos a seleccionar "Edit MX Entry", seleccionamos el dominio para el que estamos configurando Google Apps y damos siguiente. Vamos a borrar todas las entradas MX que existan, y vamos a añadir las siguientes:



Priority (Prioridad) MX Destination (Destino MX)
1ASPMX.L.GOOGLE.COM.
5ALT1.ASPMX.L.GOOGLE.COM.
5ALT2.ASPMX.L.GOOGLE.COM.
10ASPMX2.GOOGLEMAIL.COM.
10ASPMX3.GOOGLEMAIL.COM.


Le damos click en "Save". Ahora regresamos a nuestro Dashboard de Google Apps y le damos "Next". Alomejor nos aparece que debemos esperar a que se propague la información. Propagar los registros MX para Google Apps no lleva más de 2 horas en la vida real, aunque teóricamente podría tardar hasta 48 horas, así que si no podemos enviar o recibir correo de inmediato, no te preocupes, va a llegar un momento donde funcione.

3 - Habilitar autenticación DKIM y SPF para el correo (Gmail) de Google Apps
Ahora en el Dashboard le vamos a dar en "Advanced Tools". Bajamos hasta donde dice "Authenticate email" y le damos en "Set up email authentication (DKIM)". Le vamos a dar en "Generate New Record". Nos va a preguntar el prefijo, le dejamos "google" y aceptamos. En el recuadro gris aparecerá el nombre del registro DNS TXT que debe ser "google._domainkey" y el valor del TXT que debe empezar con "v=DKIM1; k=rsa.......". Vamos a copiar todo ese valir desde "v=" hasta donde termine (generalmente termina con "AB").

Regresamos a nuestro panel de control WHM y seleccionamos la opción "Edit DNS Zone". Si ya tenemos un registro que comienza con "default._domainkey" le vamos a cambiar el nombre a "google._domainkey" (sin comillas) y le pegamos el valor que copiamos anteriormente. IMPORTANTE: el valor debe ir entrecomillado. Si no tenemos un registro "default._domainkey" vamos a generar uno nuevo que tenga de nombre "google._domainkey" (sin comillas), TTL 14400, IN TXT y  le pegamos el valor que copiamos.

Aprovechando que estamos en el editor de zona DNS, vamos a añadir dos nuevos registros:

a. Registro SPF: Debe de llevar por nombre tu dominio, sin "www" y con punto final, por ejemplo "midominio.com." (sin comillas). TTL 14400, IN TXT y de valor le ponemos "v=spf1 include:_spf.google.com ~all" CON comillas.

b. Registro CNAME para ingresar al correo desde nuestro dominio: Para facilitar las cosas seguro querrás entrar por ejemplo a "correo.midominio.com" en vez de a "www.google.com/a/bla.bla.bla". El nuevo registro debe llevar como nombre "correo" así solo, TTL 14400, IN CNAME y de valor "ghs.googlehosted.com." (sin comillas y con el punto final). No olvides dar click en el botón "SAVE".

Como recordatorio, nuestros registros DNS para Google Apps en WHM (editor de zona DNS) deben de quedar algo así (además de los MX que añadimos previamente):


Nombre TTL IN Value
google._domainkey 14400 IN TXT "v=DKIM1; k=rsa; p=MIG... ..."
midominio.com. 14400 IN TXT "v=spf1 include:_spf.google.com ~all"
correo 14400 IN CNAME ghs.googlehosted.com.

Ahora vamos a regresar a Google Apps y le vamos a dar click en "Start Authentication", y listo, con esto ya configuramos la autenticación DKIM y SPF para Gmail de Apps en nuesto dominio.


4 - Configurar el subdominio "correo.midominio.com" para ingresar a nuestro correo de Google Apps
Estando en el Dashboard, vamos a ir a Settings y seleccionamos Email en la parte izquierda. En Web Address vamos a darle en Change URL. Seleccionamos "custom" que empieza con http://, sigue un cuadro de texto y después nuestro dominio. En ese cuadro de texto vamos a meter la palabra "correo". Damos click en Continue. Si nos pregunta que si ya realizamos el registro del CNAME, le decimos que sí (esto lo hicimos en el paso anterior aprovechando que estabamos en el editor de zona DNS).

5 - No hay paso 5! Ya está todo configurado para utilizar Google Apps en nuestro servidor con cPanel/WHM. Simplemente debemos esperar a que toda la información nueva se propague por internet y con eso estamos listos.

En este post/tutorial aprendimos a:

1 - Registrarse en Google Apps para Empresas
2 - Configurar registros MX para usar el correo de Google
3 - Habilitar autenticación DKIM y SPF para el correo
4 - Configurar el subdominio "correo.midominio.com"

Espero les haya servido. Saludos!

Monday, June 11, 2012

Segundo Debate 2012 México


Sobre el Segundo Debate para las Elecciones de 2012 en México:


Ojalá la gente se haya dado cuenta que en el debate de anoche se demostró que JVM, EPN y AMLO no saben debatir. No respondían preguntas, sólo ataques. Como lo mencioné varias veces en twitter, el debate debería haber sido sobre propuestas y no sobre personas o personajes.


Noté a Josefina atancando más y repitiendo el mismo choro de siempre con una sonrisa algo hipócrita y nuevamente, aprovechándose de su género (amo y respeto a las mujeres, pero JVM se pasa al mencionar que es mujer para todo) y queriendo parecer la persona que más comprende a los mexicanos. Por cierto, el tono de su voz me aburre y cansa.


A Peña lo vi minimizando y esquivando problemas como otras veces. Mostró buenas ideas y propuestas, pero algunas no tan viables o que sólo suenan bonito pero sabemos que no van a pasar. Ahora no hubo tantas aclaraciones sobre lo que dice de él, y evitó el tema de la Ibero.


Vi a un AMLO más tranquilo, no tan atacante como siempre. Ahora propuso y explicó más sus estrategias; sin embargo considero que muchas de sus ideas carecen de bases reales. A veces las cifras que menciona parecen irreales (habría que estudiarlas bien) y no muestra bien sus fuentes. Me recordó a Tercer Grado, donde nomás no mostró al público los "estudios" que llevaba consigo.


Así esta vez noté a un Gabriel Quadri nervioso al principio pero que se fue destensando. Quadri fue el único que estaba debatiendo, el único que hacía preguntas para realmente debatir sobre los temas. Lo considero una persona preparada e inteligente. Sus propuestas (que son MUCHAS) tienen bases realmente tanto financieras como ecológicas y sociales. Desafortunadamente evitó contestar directamente sobre el cuestionamiento de su relación con Elba Esther Gordillo, aunque hizo el importante señalamiento sobre cómo llamó alguna vez JVM "querida amiga" a Gordillo.


Creo que la relación de Quadri con Gordillo es algo que pesa, pero que podríamos dejar de lado. Todos los candidatos se han relacionado con personajes que le han hecho daño al país de una forma u otra y por supuesto de forma más directa que Quadri con Gordillo.


Pongámoslo de esta manera: Se supone que los ultimos presidentes del PRI, así como Fox y Calderón (sobretodo éste último) han tenido algún tipo de pacto o relación con Gordillo que le permite de alguna manera influir. Quadri es un tipo mucho más astuto, preparado, inteligente y letrado que los presidentes anteriores. Un tipo así, no se dejaría mangonear tanto como dicen de los demás. Un tipo así llevará a cabo las excelentes propuestas de educación que ha hecho, porque inclusive si fuera cuestión de la maestra, ahora le conviene y necesita quedar mucho mejor que la CNTE con los paros que está haciendo, y eso sólo se lograría mediante una amplia mejora a la educación en México.


Por otro lado, a quienes piensan que votar por Quadri es inutil por que no tiene chance de ganar, les pongo un ejemplo que puse anoche en Twitter: El no votar por Quadri por que no tiene chance, es como no probar los nuevos tacos mejor preparados por que la competencia es entre los de siempre. Esto es democracia, señores. Esto es México, señores. En México no hay un sistema bipartidista como en EEUU; aquí tenemos 4 opciones. Nosotros podemos sin temor hacer que Quadri sea nuestro representante y presidente los próximos 6 años. ¿Qué pensamiento tan conformista es ese de no votar por alguien "por que no tiene chance"? Vamos, si Quadri no tiene chance, con nuestro voto podemos dárselo.


Si consideras que Gabriel Quadri es la mejor opción, VOTA por él. Haz que tu voz, tu opinión y tu elección sean escuchadas. Yo ya me decidí por él, ¿y tú?.