VPS Plesk no ejecuta cron.daily

En un par de máquinas VPS Plesk 10.4.4 que tenemos con Axarnet no funciona cron correctamente. El caso es que todo parece estar correcto, los ficheros del cron, permsisos, los logs no reflejan nada…

Nos pusimos a revisar ficheros y llegamos a este punto /etc/crontab. En crontab se definen las horas a las que se ejecutan los cron de hourly, daily, weekly y monthly.

En debian/ubuntu la forma de ejecutar estos cron es esta :

17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Con lo que si queremos testear la ejecución directamente vemos que si /usr/bin/anacron se puede ejecutar no se hace nada. Si vemos los permisos, comprobamos que sí es ejecutable :

 stat /usr/sbin/anacron
  File: `/usr/sbin/anacron'
  Size: 29632     	Blocks: 64         IO Block: 4096   regular file
Device: 92adh/37549d	Inode: 30526104    Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-01-11 12:59:10.000000000 +0100
Modify: 2009-11-02 04:48:41.000000000 +0100
Change: 2013-01-11 12:59:11.000000000 +0100

Esto huele a problema con la plantilla … y googleando un poco hemos encontrado algunas referencias y en concreto esta: http://forum.parallels.com/showthread.php?t=258358

La solución rápida es desinstalar y reinstalar el paquete anacron o crear los ficheros /etc/cron.{hourly,daily,weekly,monthly}/0anacron Que son los que faltan.

apt-get remove --purge anacron
apt-get install anacron

El contenido del fichero 0anacron:

/etc/cron.daily/0anacron 
#!/bin/sh
#
# anacron's cron script
#
# This script updates anacron time stamps. It is called through run-parts
# either by anacron itself or by cron.
#
# The script is called "0anacron" to assure that it will be executed
# _before_ all other scripts.

test -x /usr/sbin/anacron || exit 0
anacron -u cron.daily

SiliconTower.net : paradas en el serviciol

SilliconTower.net es nuestro proveedor de servicios, donde tenemos alojados además de este blog algunos otros servicios. Esta semana pasada hemos sufrido cortes en el servicio debido a problemas con los nodos de virtualización. No tenemos respuesta exacta, pero tiene pinta de un problema de hardware o botonazo. Son suposiciones pero los que hemos tratado con máquinas de Virtuozzo conocemos el infierno el recalculo de quotas, y suele venir por no parar la máquina correctamente.

Aunque es muy molesto sufrir estos problemas como cliente… por ahora seguimos pensado que SilliconTower.net, no es mal proveedor del todo. El problema es que da la sensación de que la plantilla es muy reducida y cualquier problema interno de la empresa puede dejarnos a los clientes en una posición bastante vulnerable.

Enterprise Virtualization Conference 2010

Redhat

RedHat ha organizado un evento para dar a conocer su propuesta de virtualización. Ayer día 26 se celebró en Barcelona y mañana 28 de Octubre de 2010, se celebra en Madrid.

Enterprise Virtualization Conference 2010, comienza a las 9.30 en el Hotel Puerta de América. La Agenda es la siguiente:

  • Registro y bienvenida
  • Apertura
  • Introducción al mercado de la virtualización
  • Propuesta de valor de RedHat
  • Rompiendo las barreras de la virtualización
  • Panel de expertos: Escenarios de migración
  • HP & AMD : Justos cimentando el camino hacia la eficiencia
  • Case Study virtualizatión: Bacerló Viajes ( muy interesante )
  • Caso práctico: Automatización de sistemas virtualizados ( muy interesante )
  • Conclusiones
  • Cocktail

Para los interesados, este es el enlace :
http://www.rompalasbarreras.es/

The problem with moving VPS due to non-compliance with versions of

Solution to this problem.

Stop the vps.

vzctrl stop vps_id

Run the script.

#!/bin/bash
for i in `find /vz/private/vps_id/fs/root/ -noleaf -type l -print | perl -nle '-e || print'|grep ._vzlnk_.`
do
ln -sf `ls -ga $i|grep ._vzlnk_.|awk '{print $9}'|sed 's//////vz/template/'` $i
done

Start the vps.

vzctrl start vps_id

PS should check directories in the folder template, so as not to create dead links.

taken from :

Error mounting VZ registry for VPS

Esto es porque cada VPS tiene sus propias claves de registro que almacenan en el registro en : HKEY_LOCAL_MACHINE

En el arranque se cargar se monta el vps usando estas entradas.

Para resolver este problema, necesita VPS para sustituir el ID, se puede reconstruir el campo de registro.
El método puede ser utilizado VZMC, haga clic derecho en VPS, seleccione Mover, a continuación, introduzca los nuevos números de identificación puede ser.

También puede utilizar las operaciones de línea de comandos:

vzmlocal 101:888 

Reinicie el VPS, ahora debe estar debidamente montado.

activar SLM en virtuozzo linux

Para activar el modo SLM en Virtuozzo con Centos/Fedora/Red Hat Enterprise seguid estos pasos:

/etc/sysconfig/vz cambiar SLM=»no» por SLM=»yes»
/etc/sysconfig/vzagent/vzagent.conf buscar la entrada en el xml slm y asignar en value 1.

reiniciar el servicio

vzagent_ctl restart

Fatal error: Unable to open key (SOFTWAREPleskPSA ConfigPSA Key): (5) Access is denied. in C:SWSoftPleskadminauto_prependauth.php3 on line 40

Este error aparece en casos muy puntuales de migraciones de vps windows y cambios entre versiones. Aparece cuando intentamos acceder al panel de control plesk mediante el navegador https://ip:8443 .
No es necesario logearse para que aparezca el error.

Fatal error:  Unable to open key (SOFTWAREPleskPSA ConfigPSA Key): (5) Access is denied. in C:SWSoftPleskadminauto_prependauth.php3 on line 40

Extamente el motivo no lo conocemos, debe ser algún bug en las plantillas de Parallels. La solución pasa por agregar al usuario psaadm a la cadena de registro HKEY_LOCAL_MACHINESOFTWAREWow6432NodePLESKPSA ConfigPSA Key con permisos de lectura.

Una vez hecho este cambio, con recargar la página del panel ya tendremos la entrada al login de forma correcta.

Este bug aún no aparece en el kb de parallels.

Exprime la tarjeta de red : gigabit en Debian

Por defecto, en linux, el autonegociado de las tarjetas no es posible ponerlas a gigabit ( 1000Mb/s ). Es necesario usar una herramienta que se llama ethtool. Para poder usarla la instalamos así

apt-get install ethtool

Una vez configurada ejecutamos esta linea ( hay que elegir el interface que pondremos a 1000 ). En nuestro caso la tarjeta de red que está a giga es eth1.

/usr/sbin/ethtool -s eth1 speed 1000 duplex full autoneg on

Para automatizar esta configuración lo pondremos en el fichero /etc/network/interfaces usando el parámetro pre-up

Un ejemplo sería este :

auto eth1
iface eth1 inet static
	address		192.168.201.10
	netmask		255.255.255.0
	pre-up	/usr/sbin/ethtool -s eth1 speed 1000 duplex full autoneg on

Virtuozzo API function call ‘VzkrnlStartVps’ failed dwErr=0x000004FB

Una mala actualización del servidor vps de windows provocar un error como este :

vzctl start 101
Starting container ...
Virtuozzo API function call 'VzkrnlStartVps' failed dwErr=0x000004FB
Container 101 is not started
Exec '@VzOnShutdown' failed in container 101

Para solucionarlo, podemos proceder de la siguiente manera:

vzctl mount 101
copy c:WINDOWSsystem32driverstcpip.sys c:vzroot101cWINDOWSsystem32drivers
vzctl start 101

Hay que recordar que nunca, nunca se debe actualizar un vps windows usando la página de actualizaciones de Microsoft ( windowsupdate.com) . Siempre hay que usar el servicio de actualizaciones automáticas que se provee con el sistema.

Más información en : http://kb.parallels.com/en/2095