Experiencia en GIGAS.es VPS Debian con Plesk

logo-gigas

Una nota muy muy rápida y escueta del corto periodo que llevamos en GIGAS.es.
Nos cambiamos de proveedor debido a que Silicontower nos había estado dando algunos problemas puntuales, pero después de dos o tres años, hemos preferido cambiar de hosting y probar nuevas experiencias.

  • La imagen de empresa y el entorno del panel de control da sensación de empresa profesional, con los recursos justos pero suficiente. El panel de control, es propio y bastante ágil, además de intuitivo.
  • La mayor parte de los servicios parece automatizados, excepto la instalación de licencias de plesk que hay que contratar a mano a coste 0, esperar el email de confirmación e instalarla manualmente en el servidor contratado. Esto creemos que podría ser automatizable para que la experiencia de cliente sea más confortable.
  • La IP asignada al servidor VPS tiene configurada la inversa en los DNS de GIGAS.es con lo que el servicio de correo puede petardear un poco dependiendo de las validaciones ( SPF , greylisting, DomainKeys, etc… )
  • La atención al cliente es bastante regular, dependiendo con qué técnico de soporte te encuentes puede que te conteste alguna cosa sin sentido, pero por desgracia esto pasa en casi todas las empresas de hosting. Los técnicos de soporte no suelen tener mucho conocimiento ‘técnico’ lo que es un poco irónico.
  • El servicio de backup es otro servidor VPS que hace de servidor de copias
  • Como punto positivo la atención al cliente es bastaste ágil.
  • Nos llamaron para confirmar la eliminación de un servicio y bueno, se agradece el trato humano telefónico.

Estas notas rápidas son las que queremos destacar, son nuestras percepciones personales que no deben generalizarse.

Esperamos que sean de utilidad por si alguien es cliente o quiere contratar servicios con GIGAS.es

Debian : ficheros temporales mejor en RAM o en disco ?

En este link podeis leer un interesante artículo resumiendo el hilo de debate que comenzó Sergue acerca de si es buena idea meter el directorio /tmp ( directorio para albergar los ficheros temporales en un sistema Unix/Linux ) en memoria. Para la nueva versión de Debian: Wheezy 7.0 se está valorando si sería recomendable montar /tmp en un sistema de ficheros tmpfs. No todo el mundo está conforme y ha creado una rama de debate bastante interesante.

El resumen es que hay gente que defiende que meter /tmp en tmpfs aumenta la velocidad del sistema ya que no hay accesos al disco para ficheros temporales. Parace que el ejemplo de Solaris que lo lleva haciendo desde hace mucho tiempo ha estado muy presente en el debate. En un entorno ideal en el que el sistema sólo use ficheros pequeños es ideal, pero si usamos un sistema en el que los ficheros temporales sean de gran tamaño, como cuando se descomprime un fichero .iso o ficheros temporales de streamming unidos junto con un uso de memoria de elevando, provocaría que el sistema tenga que usar swap para proporcionar memoria emulada al tmpfs y ofrecer espacio suficiente a /tmp.

En general es una lectura bastante interesante y recomendable:

Temporary files: RAM or disk?

Dinahosting : DELL R200 al 50%

A los clientes de dinashosting nos está llegando esta promo, por si a alguien le interesa:


TODOS LOS DELL R200 AL 50%
¡Y eso no es todo! Desde hoy mismo puedes encontrar nuestra gama de dedicados DELL R200 tanto administrados como no administrados con un 50% de descuento el primer año. Desde luego es una oportunidad única que no deberías dejar pasar por alto... Además todos los modelos vienen con 4GB de RAM o más; échale un vistazo a las configuraciones disponibles: https://dinahosting.com/promos/servidores-dell-r200-a-mitad-de-precio

Ahí va un ejemplo:
- R200 con un Quadcore, 2GB de RAM, 250GB de disco y 10TB de transferencia mensual te queda en solo 40€ al mes. ¡Además te regalamos la ampliación de RAM a 4GB!

Fallos de seguridad

Comprueba si tus sistemas están al día. Importantes fallos de seguridad en Apache y Rails han sido descubiertos y publicados, así como sus correspondientes parches.

En Apache se ha descubierto una vulnerabilidad que permite realizar un ataque de denegacion de servicio y en rails es posible realizar XSS y SQL Injection.

A continuación más detalles :

Apache: http://www.debian.org/security/2011/dsa-2298

CVE-2010-1452, CVE-2011-3192.

Rails: http://www.debian.org/security/2011/dsa-2301

CVE-2011-2930, CVE-2011-2931, CVE-2011-3186, CVE-2009-4214.

[kvm] Webminar de redhat : Virtualización

El miércoles 10 de noviembre de 2011 Redhat ofrece un webminar acerca de la virtualización con su producto de virtualización (kvm). La agenda es la siguiente:

Agenda

11:00 – 11:30
RHEV y la Virtualización
de Desktops

  • Overview del offering the
    Red Hat para VDI
  • SPICE: el nuevo protocolo
    de desktops remotos open source
  • Arquitectura y Sizing de entornos
    de escritorio virtualizado

11:30 – 12:00
RHEV y la Virtualización
de Servers

  • Overview del offering de Red
    Hat para virtualización de servidores
  • Atajando el «VM sprawling»
    con estrategias de gestión de sistemas
  • De la virtualización al cloud

Más información en: http://twitter.com/RedHat_Neovalia

[plesk] Parallels Plesk Panel 10: capturas de pantalla

Primeras capturas de pantallas :

Plesk Panels 10 - general server configuration
Plesk Panels 10 - general server configuration
Plesk Panels 10 - server health, apache status
Plesk Panels 10 - server health, apache status
Plesk Panels 10 - server health, apache status and more options
Plesk Panels 10 - server health, apache status and more options
Plesk Panels 10 - system statistics
Plesk Panels 10 - system statistics

Como podeis observar, el interface ha sido retocado para ser más claro y además es bastante más ligero. Aún así guarda el 95% de parecido con la versión anterior. Echaremos un vistazo más a fondo para ver que se esconde por dentro.

[xploit] Grave fallo de seguridad en el kernel 2.6

Aunque llegamos tarde para anunciar la noticia, es necesario comentar aquí la necesidad de aplicar los parches que salieron hace dos días 21 de Septiembre que corrijen un grabe fallo de seguridad en los kernels 2.6 bajo máquinas con arquitectura x86_64.

El fallo se puede explotar localmente en la máquina y consiste en acceder vía  «compat_alloc_user_space()» esta función no está correctamente securizada y no se verifican los tamaños de los punteros con lo que se puede hacer un buffer overflow y todo lo que ello conlleva… Al parecer el fallo lleva 2 años en el kernel y no fué comunicado en todo este tiempo por la gente que ha desarrollado el xploit pero sí lo han utilizado para su beneficio propio:

  • Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
  • Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
  • Signed-off-by: David S. Miller <davem@davemloft.net>

El exploit lo podeis localizar en ABftw.c al menos se han preocupado de eliminar las partes jugosas para que los scriptkidies no hagan de las suyas.

Más interesante que leerse el exploit es comprobar que tu máquina no esté infectada y para ello debes descargar este binario y ejecutarlo con un usuario que no sea root ( recuerda que es sólo para máquinas x86_64 ->  uname -p  )$ wget -N https://www.ksplice.com/support/diagnose-2010-3081
$ chmod +x diagnose-2010-3081
$ ./diagnose-2010-3081
Diagnostic tool for public CVE-2010-3081 exploit — Ksplice, Inc.
(see http://www.ksplice.com/uptrack/cve-2010-3081)

$$$ Kernel release: 2.6.18-194.11.3.el5
$$$ Backdoor in LSM (1/3): checking…not present.
$$$ Backdoor in timer_list_fops (2/3): not available.
$$$ Backdoor in IDT (3/3): checking…not present.

Your system is free from the backdoors that would be left in memory
by the published exploit for CVE-2010-3081.

Para evitar que se explote el fallo hay una solución que lo mitiga y consiste en no permitir ejecutar binarios x86 o i386 en la máquina usando esta linea# echo ‘:32bits:M::x7fELFx01::/bin/echo:’ > /proc/sys/fs/binfmt_misc/register

Provoca que los binarios de 32 bits sólo hagan un «echo» con su nombre de fichero y sus parámetros. El problema es que necesites algunos binarios de 32 bits como es el caso del drweb-update.

De todas formas ya hay kernel nuevo para instalar, reiniciar y listo.

Más información en :

https://access.redhat.com/kb/docs/DOC-40265
https://www.ksplice.com/uptrack/cve-2010-3081
https://rhn.redhat.com/errata/RHSA-2010-0704.html
https://rhn.redhat.com/errata/RHSA-2010-0705.html
http://seclists.org/fulldisclosure/2010/Sep/268

[php] Depurando / Profiling en php ( II )

En este caso analizamos un hecho real, una web que tarda en cargar aleatoriamente entre 10 y 12 segundos. El problema es que al medir los tiempos en otro servidor no llega a 2 segundos. Después de revisar conectividad, carga de sistema, carga de apache … y demás parámetros habituales; todo estaba perfecto. Así que decidimos relizar el profiling de la web para localizar el cuello de botella dentro de los scripts php.

En el artículo anterior [php] Depurando / Profiling en php ( I ) dejamos instalado el módulo APD para capturar la información necesaria y luego procesarla. Recordamos que hay que usar la función apd_set_pprof_trace(); para que se generen los datos. En nuestro caso hemos seleccionado la ruta /tmp en donde se almacenarán estos ficheros.

Ejecutamos unos cuantas veces el script php que nos interesa. Generamos una captura de una ejecución en 1-2 segundos (/tmp/pprof.32231.1) y seguimos ejecutando hasta que conseguimos una captura de datos de una ejecución que tardó unos 10-11 segundos (/tmp/pprof.01666.0)

Vamos a comparar la captura de los datos :

La ejecución buena :

# pprofp -R /tmp/pprof.32231.1

Trace for /var/www/vhosts/hostingaldescubierto.com/httpdocs/index.php
Total Elapsed Time = 0.36
Total System Time  = 0.03
Total User Time    = 0.07

Real         User        System             secs/    cumm
%Time (excl/cumm)  (excl/cumm)  (excl/cumm) Calls    call    s/call  Memory Usage Name
--------------------------------------------------------------------------------------
100.0 0.00 0.36  0.00 0.07  0.00 0.03     1  0.0000   0.3589            0 main
96.1 0.00 0.34  0.00 0.08  0.00 0.03     5  0.0000   0.0690            0 require_once
59.1 0.00 0.21  0.00 0.01  0.00 0.00     8  0.0000   0.0265            0 include
58.9 0.00 0.21  0.00 0.01  0.00 0.00     1  0.0000   0.2113            0 call_user_func_array
58.9 0.00 0.21  0.00 0.01  0.00 0.00     1  0.0000   0.2113            0 Pages->index
58.9 0.00 0.21  0.00 0.01  0.00 0.00     1  0.0000   0.2112            0 Pages->show
58.9 0.00 0.21  0.00 0.01  0.00 0.00     1  0.0000   0.2112            0 Template->build
58.8 0.00 0.21  0.00 0.01  0.00 0.00     2  0.0000   0.1054            0 MY_Loader->view
58.6 0.00 0.21  0.00 0.01  0.00 0.00     2  0.0000   0.1052            0 MY_Loader->_ci_load
56.8 0.00 0.20  0.00 0.00  0.00 0.00     1  0.0000   0.2038            0 weather_google_api
56.8 0.20 0.20  0.00 0.00  0.00 0.00     1  0.2037   0.2037            0 simplexml_load_file
29.4 0.00 0.11  0.00 0.05  0.00 0.02     1  0.0000   0.1054            0 Pages->Pages
29.2 0.00 0.10  0.00 0.05  0.00 0.02     1  0.0000   0.1048            0 Pages->Public_Controller
13.9 0.00 0.05  0.00 0.03  0.00 0.02     1  0.0000   0.0497            0 Pages->MY_Controller
13.4 0.00 0.05  0.00 0.02  0.00 0.03     2  0.0000   0.0241            0 MY_Loader->_ci_autoloader
12.2 0.00 0.04  0.00 0.01  0.00 0.00     3  0.0000   0.0146            0 Banners_model->get_by_section
11.7 0.00 0.04  0.00 0.00  0.00 0.00    25  0.0000   0.0017            0 CI_DB_mysql_driver->query
11.5 0.00 0.04  0.00 0.01  0.00 0.00     6  0.0000   0.0069            0 Banners_model->add_hit
11.4 0.04 0.04  0.03 0.03  0.01 0.01    65  0.0006   0.0006            0 defined
10.9 0.00 0.04  0.00 0.00  0.00 0.00    25  0.0000   0.0016            0 CI_DB_mysql_driver->simple_query

El fichero de 10-12 segundos :

# pprofp -R /tmp/pprof.01666.0

Trace for /var/www/vhosts/hostingaldescubierto.com/httpdocs/index.php
Total Elapsed Time = 10.34
Total System Time  = 0.02
Total User Time    = 0.08

Real         User        System             secs/    cumm
%Time (excl/cumm)  (excl/cumm)  (excl/cumm) Calls    call    s/call  Memory Usage Name
--------------------------------------------------------------------------------------
100.1 0.00 10.35  0.00 0.09  0.00 0.02     5  0.0000   2.0692            0 require_once
100.0 0.00 10.34  0.00 0.08  0.00 0.02     1  0.0000   10.3394            0 main
99.1 0.00 10.24  0.00 0.01  0.00 0.00     8  0.0000   1.2802            0 include
99.0 0.00 10.24  0.00 0.01  0.00 0.00     1  0.0000   10.2409            0 call_user_func_array
99.0 0.00 10.24  0.00 0.01  0.00 0.00     1  0.0000   10.2409            0 Pages->index
99.0 0.00 10.24  0.00 0.01  0.00 0.00     1  0.0000   10.2409            0 Pages->show
99.0 0.00 10.24  0.00 0.01  0.00 0.00     1  0.0000   10.2409            0 Template->build
99.0 0.00 10.24  0.00 0.01  0.00 0.00     2  0.0000   5.1202            0 MY_Loader->view
99.0 0.00 10.24  0.00 0.01  0.00 0.00     2  0.0000   5.1200            0 MY_Loader->_ci_load
99.0 0.00 10.23  0.00 0.00  0.00 0.00     1  0.0000   10.2335            0 weather_google_api
99.0 10.23 10.23  0.00 0.00  0.00 0.00     1  10.2333   10.2333            0 simplexml_load_file
0.7 0.00 0.08  0.00 0.06  0.00 0.01     1  0.0000   0.0766            0 Pages->Pages
0.7 0.00 0.08  0.00 0.05  0.00 0.01     1  0.0000   0.0761            0 Pages->Public_Controller
0.5 0.00 0.05  0.00 0.04  0.00 0.01     2  0.0000   0.0266            0 MY_Loader->_ci_autoloader
0.5 0.00 0.05  0.00 0.04  0.00 0.01     1  0.0000   0.0524            0 Pages->MY_Controller
0.4 0.04 0.04  0.04 0.04  0.01 0.01    65  0.0006   0.0006            0 defined
0.4 0.00 0.04  0.00 0.02  0.00 0.01    38  0.0000   0.0010            0 MY_Loader->helper
0.3 0.00 0.04  0.00 0.03  0.00 0.00    10  0.0000   0.0036            0 MY_Loader->model
0.3 0.00 0.03  0.00 0.02  0.00 0.01     1  0.0000   0.0312            0 Pages->Controller
0.3 0.00 0.03  0.00 0.02  0.00 0.01     1  0.0000   0.0311            0 Pages->_ci_initialize

Vemos claramente esta linea que es la que penaliza el tiempo de ejecución del script:

99.0 10.23 10.23  0.00 0.00  0.00 0.00     1  10.2333   10.2333            0 simplexml_load_file

Perfecto, ya sabemos lo que tenemos que buscar el uso de la función simplexml_load_file. Buscamos los ficheros que usan esta funcion, por ejemplo así :

find -name "*php" -exec grep -l simplexml_load_file {} ;

Entre los resultados encontramos uno, que llama especialmente la atención, en el que solicita un fichero xml de google http://www.google.com/ig/api?weather=madrid&oe=utf-8.
Vamos a medir cuanto tiempo tarda en descargarlo :

# time wget 'http://www.google.com/ig/api?weather=madrid&oe=utf-8'
--2010-07-26 18:27:47--  http://www.google.com/ig/api?weather=madrid&oe=utf-8
Resolving www.google.com... 66.249.92.104
Connecting to www.google.com|66.249.92.104|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/xml]
Saving to: `api?weather=madrid&oe=utf-8.1'

[ <=>                                                                                                                                      ] 1,291       --.-K/s   in 0s

2010-07-26 18:27:57 (12.0 MB/s) - `api?weather=madrid&oe=utf-8.1' saved [1291]

real    0m10.157s
user    0m0.002s
sys    0m0.001s

Parece bastante claro que la ejecución se ralentiza por la petición a google… una caché que se actualice cada día, hora o cada minuto solucionaría este problema.

[php] Depurando / Profiling en php ( I )

Para poder diagnosticar qué sucede en la máquina cuando se ejecuta un script en php es necesario instalar un depurador o profiler. En este caso instalamos Advanced Php Debugger.

En máquinas Centos, como es usual no lo tenemos en el repositorio así lo instalaremos manualmente usando ‘pecl‘ que lo provee el paquete de php-pear .

pecl install apd

Será necesario tener instalado make, gcc  y autconf

Nos podemos encontrar con este error :

# pecl install apd
WARNING: channel "pear.php.net" has updated its protocols, use "channel-update pear.php.net" to update
downloading apd-1.0.1.tgz ...
Starting to download apd-1.0.1.tgz (36,643 bytes)
..........done: 36,643 bytes
15 source files, building
running: phpize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20060613
Zend Extension Api No:   220060519
building in /var/tmp/pear-build-root/apd-1.0.1
running: /tmp/pear/download/apd-1.0.1/configure
checking for egrep... grep -E
checking for a sed that does not truncate output... //bin/sed
checking for cc... cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
ERROR: `/tmp/pear/download/apd-1.0.1/configure' failed

Normalmente es debido a que tenemos /var y /var/tmp con la opcion de noexec. Para poder ejecutarlo correctamente pondremos temporalmente estos puntos de montaje con permisos de ejecución y luego lo restauramos:

mount -o,remount,rw,exec /var/tmp
mount -o,remount,rw,exec /tmp
pecl install apd
mount -o,remount,rw,noexec /var/tmp
mount -o,remount,rw,noexec /tmp

Nos insteresa quedarnos con este contenido para configurar el fichero .ini :

running: make INSTALL_ROOT="/var/tmp/pear-build-root/install-apd-1.0.1" install
Installing shared extensions:     /var/tmp/pear-build-root/install-apd-1.0.1/usr/lib64/php/modules/
running: find "/var/tmp/pear-build-root/install-apd-1.0.1" | xargs ls -dils
  12   1 drwxr-xr-x 3 root root   1024 Jul 23 18:33 /var/tmp/pear-build-root/install-apd-1.0.1
2057   1 drwxr-xr-x 3 root root   1024 Jul 23 18:33 /var/tmp/pear-build-root/install-apd-1.0.1/usr
4113   1 drwxr-xr-x 3 root root   1024 Jul 23 18:33 /var/tmp/pear-build-root/install-apd-1.0.1/usr/lib64
6169   1 drwxr-xr-x 3 root root   1024 Jul 23 18:33 /var/tmp/pear-build-root/install-apd-1.0.1/usr/lib64/php
8225   1 drwxr-xr-x 2 root root   1024 Jul 23 18:33 /var/tmp/pear-build-root/install-apd-1.0.1/usr/lib64/php/modules
8226 129 -rwxr-xr-x 1 root root 130196 Jul 23 18:33 /var/tmp/pear-build-root/install-apd-1.0.1/usr/lib64/php/modules/apd.so

Build process completed successfully
Installing '/usr/lib64/php/modules/apd.so'
install ok: channel://pear.php.net/apd-1.0.1

Tendremos que crear un fichero en /etc/php.d/apd.ini con este contenido

zend_extension = /usr/lib64/php/modules/apd.so
apd.dumpdir = /tmp
apd.statement_tracing = 0

y comprobamos que el modulo carga con php -m

#php -m

....

[Zend Modules]
Advanced PHP Debugger (APD)
Zend Optimizer

Ahora ya podemos lanzar el profiling en nuestras páginas, para ello podemos incrustar este fragmento de código y activarlo sólamente cuando accedamos nosotros y no los clientes:

 <?php
 $DEBUGIPS = array('93.174.6.8','192.168.1.1');
 if(array_search($_SERVER[REMOTE_IP], $DEBUGIPS)) {
   apd_set_pprof_trace();
 }
?> 

Y con esto acabamos la primera parte, atentos a la segunda 😀