Mover los archivos de una base de datos MSSQL Server

Hoy me he tenido que ver en la tesitura de mover los archivos de una BBDD SQL Server 2008 de un directorio a otro: el motivo, una BBDD que ha crecido de manera desmesurada en pocas horas, así que me he tenido que buscar las castañas para devolver el servicio a la plataforma. Y ya hablaremos con el cliente para ver qué quiere hacer.

El caso es que mover la BBDD ha sido sencillo, una vez he tenido un poco de idea de cómo hacerlo. En mi caso, lo he hecho para un MSSQL 2008, pero imagino que el procedimiento será el mismo en otras versiones.

Antes de empezar
1) tener claro dónde están los datos actuales de la BBDD y dónde lo vamos a mover, y sobre todo, si hay espacio suficiente. Sé que puede parecer una tontería, pero no lo es.
2) configuraremos el directorio destino. Con esto me refiero a que asignaremos los mismos permisos al directorio de destino que tiene el directorio origen. En mi caso, que trabajo con un usuario administrador, sólo me hizo falta añadir al usuario SQLUser con control total en el directorio, y después, al mover los archivos, y en los archivos.

Una vez tenemos el escenario preparado, los pasos serán los siguientes:
 - Arranca el SQL Server Management Studio
 - Expande la instancia de tu servidor SQL y las Bases de datos (Databases)
 - Botón derecho sobre la BBDD que quieres mover y elige 'Tasks' y después 'Detach'. Con esto, la BBDD queda desvinculada del servidor SQL, aunque sigue en nuestro disco duro. Haz con cuidado este paso y asegúrate que no hay activada ninguna opción tipo 'Drop'. Haz click en 'OK' cuando hayas comprobado toda la información de la ventana 'Detach'.
 - Desde el directorio origen de datos de SQL, mueve los datos (xxxx.mdf y xxxx.ldf) a su nuevo directorio. Recuerda comprobar los permisos unas vez movidos los archivos, y que sean los mismos que originalmente.
 - Botón derecho sobre 'Databases' y elige la opción 'Attach'; con esto, volveremos a vincular la BBDD al servidor SQL. Se abrirá una ventana que nos pedirá que ubiquemos los archivos de la BBDD que vamos a vincular; navegamos y seleccionamos el archivo .mdf que acabamos de mover, y 'OK'.
 - En el siguiente panel comprueba que la nueva localización está configurada tanto para el archivo .mdf como para el .ldf. Una vez comprobado, 'OK'.
 - Una vez se haya vinculado de nuevo la BBDD, comprueba que se haya hecho bien, refrescando la vista y comprobando que la BBDD se lista de nuevo correctamente.


Como véis, el proceso no es muy complicado, sólo que las primeras veces hay que ir con ojo. Aún así, me he encontrado con dos problemas, y paso a relatar cómo los he solucionado.

• Por un lado, al vincular la BBDD de nuevo, el SQL lo hacía en modo Read-Only. Esto ha sido debido a que los permisos del nuevo directorio y de los archivos copiados no eran los mismos que originalmente; por eso hago tanto hincapié durante la explicación.
• Por otro lado, una vez ha finalizado correctamente todo el proceso, otra BBDD se ha quedado en estado 'in recovery', y no se podía realizar ninguna acción sobre ella. En esta BBDD no se ha hecho ningún cambio, pero es posible que a nivel interno tuviera alguna relación con la BBDD que se ha movido; el caso es que pasados unos minutos en este estado, se ha solucionado solo, la BBDD ha salido de este estado una vez ha finalizado la recuperación.

Haciendo mis pinitos en Oracle: recursos en STOP_FAILED

En mi caso, alguna vez me he encontrado con que no se puede establecer una conexión entre un tomcat y una BBDD oracle; el error típico es el siguiente

[06/12/11 23:44:11:396] com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask run INFO: An exception occurred while acquiring a poolable resource. Will retry.
java.sql.SQLException: Listener refused the connection with the following error:

ORA-12519, TNS:no appropriate service handler found
The Connection descriptor used by the client was:
192.168.168.168:1521:BBDD01

Al acceder al nodo activo de oracle, y ver el estado, hay un recurso que ha intentado pararse pero no ha podido. Para consultar el estado, ejecutamos

scstat -g

y obtenemos

-- Grupos de recursos y recursos --             Nombre del grupo Recursos             ---------------- --------  Recursos:  grupo_recurso-rg servicio_01 servicio_02 servicio_03 servicio_n -- Grupos de recursos --             Nombre del grupo Nombre del nodo          Estado         Suspendido             ---------------- ---------------          ------         ----------      Grupo: grupo_recurso-rg BD1                     Error: parada no satisfactoria No      Grupo: grupo_recurso-rg BD2                     Offline        No -- Recursos --             Nombre del recurso Nombre del nodo          Estado         Mensaje de estado             ------------------ ---------------          ------         -----------------   Recurso:  servicio_01    BD1                      Online         Online - LogicalHostname online.   Recurso:  servicio_01    BD2                      Offline        Offline - LogicalHostname offline.   Recurso:  servicio_02 BD1                     Online         Online   Recurso:  servicio_02 BD2                     Offline         Offline   Recurso:  servicio_03 BD1                     Online         Online   Recurso:  servicio_03 BD2                     Offline         Offline   Recurso:  servicio_n BD1                     Parada no satisfactoria Con fallo   Recurso:  servicio_n BD2                     Offline       Offline

Localizamos que el problema está en el recurso servicio_pen-oracle_server del nodo BD11. El estado es STOP_FAILED. En este caso, lo que debemos hacer es poner el recurso en estado offline y después balancear el clúster al nodo pasivo para volver a tener servicio. Primer ejecutaremos

scswitch -c -h BD1 -j servicio_n -f STOP_FAILED

donde
-c: pasar a offline
-h: nodo
-j: recurso
-f: estado actual

Una vez ejecutado, nos devuelve el siguiente mensaje

scswitch: NOTICE: Operation succeeded, but resource group oracle-rg remains in ERROR_STOP_FAILED state on node server1 because some resources in the group remain
online while others are offline. To clear this condition, switch the resource group offline.

y ejecutamos el siguiente comando para pasar el grupo de recursos offline (es decir, todos los recursos, no sólo el que da problemas)

scswitch -F -g grupo_recurso-rg

Una vez ha finalizado, comprobamos que el todo ha quedado sin errores: scstat -g
Por último, para pasar el clúster al nodo inactivo, lo hacemos ejecutando

scswitch -z -g grupo_recurso-rg -h BD2

donde
-z: balanceo
-g: grupo de recursos
-h: nodo al que vamos a pasar el grupo de recursos

Una vez finalice, comprobamos que los servicios han quedado bien levantados con scstat -g

Reducir o truncar el ibdata1 de MySQL

Si estáis utilizando la configuración por defecto del motor de almacenamiento InnoDB para vuestras tablas MySQL, seguramente os habréis encontrado con un problema bastante molesto: el archivo 'ibdata1', que contiene todos los datos de la instancia MySQL (no es bien bien un log de transacciones) y que crece descontroladamente. Al principio pesa 10Mb, pero eso va creciendo y no se puede partir o cortar de ninguna manera. Ni siquiera con DELETE, TRUNCATE o DROPs a los datos almacenados en la BBDD harán que el archivo sea más pequeño. De hecho, cuando se libera espacio, el sistema lo marca como libre dentro del archivo y se puede reutilizar más adelante. Vamos, que podría llegar a ocupar todo el espacio libre en la partición. Y con lo crítico que es, este parámetro no viene preconfigurado en una instalación por defecto.

Bueno, el caso es que una vez configuras una BBDD para trabajar con InnoDB, pocas cosas puedes hacer con ella, una vez te has encontrado con el problema. Así que hay que empezar de nuevo, y para que no nos pase, vamos a intentar limitar estos parámetros y que no crezca de manera descontrolada.

Éste es el método que he utilizado en varias ocasiones. Al final tenéis el enlace al texto original, donde se comentan otras dos maneras de truncar el ibdata1. Yo utilizaré la más intuitiva.

Antes de nada, haced un backup completo de la BBDD. Es más, si puedes también parar el MySQL y copiar los binarios a otro directorio, mejor. Ya lo borrarás cuando puedas. Así tienes todos los backups habidos y por haber.

Yo mi backup completo lo hago con una query del estilo:

/usr/bin/mysqldump ––extended-insert ––all-databases ––add-drop-database ––disable-keys ––flush-privileges ––quick ––routines ––triggers > /root/all-databases.sql

Tarda, tarda bastante, pero es completo.

Una vez tengo hecho mi backup, paro el servidor MySQL y entonces me dedico a mover o a borrar el directorio de datos MySQL. Yo, en mi caso, siempre me gusta guardar el directorio por si hay que hacer un rollback, y es recomendable que lo hagáis. Si no podéis por problemas de espacio o algo, al menos esperad a comprobar que el proceso funciona.

Nos habíamos quedado en que tenéis que mover lo que hay en el directorio de datos de MySQL si queréis mantener el path (por defecto en Debian es /var/lib/mysql); otra opción es crear una carpeta nueva, por ejemplo si queréis mover el directorio de datos de filesystem a uno más grande. En ese caso, recordad configurar los mismos permisos

mkdir /path/to/mysql
chown mysql:mysql /path/to/mysql
chmod 770 /path/to/mysql

Ya casi estamos. Ahora toca reconfigurar el MySQL; por defecto el archivo en Debian es /etc/mysql/my.cnf pero en algunos sistemas es /etc/my.cnf; sólo tendréis que localizarlo y realizar las modificaciones que consideréis pertinentes. Yo, en mi última configuración, añadí estos parámetros

innodb_log_file_size    = 800M
innodb_buffer_pool_size = 1024M
innodb_file_per_table = 1
innodb_data_file_path=ibdata1:1024M

pero en el último algo andaría mal, porque el sistema ha pasado de mí. Lástima que lo vi cuando ya era demasiado tarde (era demasiado tarde porque había puesto la BBDD en producción y si me 'cargo' el ibdata1, me cargo la BBDD... y queda feo). Si habéis cambiado el path del directorio de datos, recordad que tenéis que modificar la variable 'datadir' y actualizarla.

Ahora que he hecho las modificaciones, inicializo la BBDD. Esto es que como no tengo nada, sólo un directorio vacío, vamos a crear la estructura de datos para que el MySQL pueda arrancar sin nada. Ya me encargaré después de cargarle los datos. Para ello, desde la línea de comandos ejecuto

sudo -u mysqld mysql_install_db
(si estoy como root sólo  mysql_install_db)

Y ya estará inicializada. Comprobad que no devuelva otro error, pero si todo va bien, ya tenéis la BBDD.

Ahora levanto el MySQL. En Debian da 'problemas' con el usuario debian-sys-maint, que es el que Debian utiliza para cualquier tarea de mantenimiento, como comprobar el estado de las tablas al arrancar el proceso. Nada, que da error porque el usuario no existe, así que no le hagáis mucho caso al amigo. Cuando importéis la BBDD y el usuario se cree, se resolverá el problema. El caso es que el servicio se levanta y podréis entrar al MySQL. Dentro de la consola ejecutar

SET FOREIGN_KEY_CHECKS=0;
SOURCE /path/to/backup-databases.sql;
SET FOREIGN_KEY_CHECKS=1;

El segundo paso importará la base de datos, y su duración dependerá de lo grande que sea ésta. Puede durar horas. No desesperéis.

Cuando por fin haya acabado, reiniciad el MySQL para que coja todos los cambios que habéis hecho al importar la base de datos. Comprobad que levanta bien y que todo funciona correctamente.

En el caso que tuviérais que volver atrás porque no ha salido bien y no tenéis tiempo de repetir el proceso, todo es tan sencillo como

1 - parar el MySQL
2 - editar /etc/mysql/my.cnf y deshacer los cambios
En mi caso sería eliminar las líneas añadidas y volver a poner /var/lib/mysql en el 'datadir'
3 - arrancar el MySQL de nuevo. Comprueba que todo funciona correctamente

El proceso sólo requiere mucho tiempo, siempre en función del tamaño de la BBDD, no es tan difícil como puede parecer antes de hacerlo

Y ya está!!

"Mi servidor no está bien..." - Manual para instalar RKHUNT

¿No os suena eso de 'Este servidor está haciendo cosas raras'? Yo lo suelo decir mucho. Demasiado tal vez... El caso es que, una vez analizado el caso, si sigue sin seguir ningún tipo de lógica y empiezas a pensar que tal vez tienes 'marcianitos' en tu servidor, ha llegado el momento de comprobar con un rootkit a ver qué hay ahí dentro.

Es muy sencillo, la verdad, no tiene misterio.
Instalamos la aplicación elegida; yo suelo trabajar con RKHUNTER

http://www.rootkit.nl/projects/rootkit_hunter.html 

y si puedo lo instalo directamente desde el repositorio; en caso de trabajar con sistemas tipo Debian:

apt-get install rkhunter

(además el sistema te instala libmd5-perl y el unhide; alguna vez me he encontrado que el unhide después devuelve algún aviso de seguridad al scanear)
Una vez instalados los paquetes, sólo queda escanear en busca de cosas 'raras'. Para ejecutarlo, invocamos en la shell

SERVER:~# rkhunter -c
[ Rootkit Hunter version 1.3.2 ]

Checking system commands...

  Performing 'strings' command checks
    Checking 'strings' command                               [ OK ]

  Performing 'shared libraries' checks
    Checking for preloading variables                        [ None found ]
    Checking for preload file                                [ Not found ]
    Checking LD_LIBRARY_PATH variable                        [ Not found ]

  Performing file properties checks
    Checking for prerequisites                               [ OK ]
    /bin/bash                                                [ OK ]
    /bin/cat                                                 [ OK ]
    /bin/chmod                                               [ OK ]
    /bin/chown                                               [ OK ]
    /bin/cp                                                  [ OK ]
    /bin/date                                                [ OK ]
    /bin/df                                                  [ OK ]

[...]

Al acabar, el log por defecto lo deja en

/var/log/rkhunter.log

La versión de rkhunter que viene con Debian, además, se puede programar de manera que no necesite interacción, ideal para automatizar vía cron.
Las entradas que yo tengo en mi cron respecto a esto son

rkhunter --update
rkhunter --cronjob --report-warnings-only

La primera entrada es para actualizar la base de datos del rkhunter. Para que funcione el sistema tiene que tener instalado algún navegador para utilizar desde la línea de comandos, tipo wget o lynx.
La segunda entrada es la que os comentaba, ya que ejecuta rkhunter de manera que no necesita interacción y sin reportar nada por pantalla. Para ello le ponemos el '--reports-warnings-only', y todo lo que analice lo envía al log por defecto.

Ahora sólo queda automatizar un proceso que revise el log y me avise vía mail si alguna vez hay algo raro. De momento estoy en ello, pero tengo que acabar de pulir los 'Warnings' que me devuelve el log, a ver qué se puede ignorar y qué no!



Fuentes:    http://www.rootkit.nl/projects/rootkit_hunter.html
               http://www.howtoforge.com/scan_linux_for_rootkits

MSSQL: Error al importar

Hoy he tenido que importar una BBDD MSSQL 2000 en MSSQL 2008. Y me daba una pequeña crujida:

El conjunto de copia de seguridad contiene una copia de una base de datos distinta de la existente
(The Backup set holds a backup of a database other than existing database)

y luego un montón de códigos raros a los MS es tan aficionado del tipo:

Microsoft.SqlServer.SmoExtended
System.Data.SqlClient.SqlError

El caso es que googleando he visto que lo único que tenía que hacer mientras importaba la BBDD era activar la opción WITH_REPLACE en las Opciones. Y ya está, la BBDD se ha importado correctamente ;)


Puedes consultar la fuente directamente aquí.

Quitar un servidor MySQL de la replicación

No sé si os ha llegado a pasar alguna vez: para poner dos BBDD MySQL en replicación hay información para parar un tren, pero para quitarlas, yo no he localizado tanta...

Aquí dejo mi pequeña receta.

Hasta hace nada tenía tres servidores MySQL, uno de maestro y dos esclavos que se replicaban automáticamente contra el maestro. Pero llegó el momento que necesité sacarlos y esto es lo que hice:

1. Editar el /etc/mysql/my.conf (cambiará según distribución, pero en esencia es el archivo de configuración del MySQL) y comentamos las siguientes líneas:
   #server-id = 6
   #log_bin = /var/log/mysql/mysql-bin.log
2. Movemos (por si hay que recuperarlo) el archivo master.info que se ubica donde se guardan los binarios del MySQL (por defecto en muchos casos es /var/lib/mysql/) y lo guardamos con otro nombre
3. Reiniciamos la BBDD

La comprobación de que todo ha ido bien y que ya no está vinculado a ningún maestro la podéis hacer consultando el estado del slave: show slave status. Ya veréis como no dice nada!

Revelación de información sensible en Apache Tomcat

Apache Software Foundation ha hecho pública la resolución de una nueva vulnerabilidad en Apache Tomcat. Esta vulnerabilidad con el CVE-2011-2729 (afecta a las versiones 5, 6 y 7), y queda definida con un nivel de severidad de "Importante" al permitir la revelación de información sensible.

Apache Tomcat es un servidor web que funciona como contenedor de servlets, desarrollado en código abierto por la Apache Software Foundation. Tomcat implementa las especificaciones de las tecnologías servlets Java y de páginas JSP.

Debido a un error en las políticas de seguridad del servicio jsvc se permitiría a las aplicaciones web tener acceso a ficheros y directorios pertenecientes al superusuario.

Esta situación sólo se daría si la instalación de Tomcat está bajo un sistema operativo Linux, el servicio jsvc fue compilado con libcap y se utilizó el parámetro -user.

Se recomienda actualizar Tomcat y aplicar las contramedidas necesarias:

Versiones afectadas
* Tomcat 7.0.0 a 7.0.19
Actualizar a la versión ya disponible 7.0.20:
http://tomcat.apache.org/download-70.cgi

* Tomcat 6.0.30 a 6.0.32 y Tomcat 5.5.32 a 5.5.33
Utilizar las contramedidas disponibles hasta que se hagan públicas las
nuevas versiones (6.0.33 y 5.5.34 respectivamente):
* Actualizar el servicio jsvc a la versión 1.0.7 o posterior.
* No utilizar el parámetro -user para cambiar de usuario
* Recompilar el servicio jsvc sin libcap.

Más información:

Fixed in Apache Tomcat 7.0.20
Important: Information disclosure CVE-2011-2729
http://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.20

Apache Tomcat - Security Updates
http://tomcat.apache.org/security.html


FUENTE: HispaSec

Roundcube: crear carpetas por defecto

Hace unos días me encontré que las cuentas nuevas de correo no creaban las carpetas típicas en el servidor (Enviados, Borradores y Papelera). Estas carpetas las tiene que crear el webmail (o el cliente IMAP que se utilice), pero en este caso mi roundcube no las estaba creando.

Buscando por internet he visto que hay una opción para ello.

Editamos el archivo de configuración main.inc.php y buscamos la línea donde esté el parámetro
create_default_folders
y de false lo cambio a true.

Las nuevas cuentas empiezan a crear sus carpetas correctamente.

En este caso, hay un pero del que no me he visto advertida en internet. Hay que tener cuidado, no es una opción que no tenga "efectos" secundarios. Yo lo testeé antes de pasarlo a producción, y días después me he encontrado con un usuario que ha "perdido" sus carpetas de Enviados, Borradores y Papelera. Se trata de un usuario antiguo, que tenía ya correo en la plataforma antes del cambio.
Para solucionarlo, he tenido que "resetear" los parámetros por defecto del usuario en roundcube. Para ello, me he ido a la BBDD de RC y he buscado en la tabla users a este usuario, y en el campo preferences le he dejado unas básicas.

mysql> select * from users where username like 'xxx@yyyy.tld';
+---------+-----------------------------+-----------+-------+---------------------+---------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| user_id | username | mail_host | alias | created | last_login | language | preferences |
+---------+-----------------------------+-----------+-------+---------------------+---------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 5 | xxx@yyyy.tld | localhost | | 2011-07-27 03:52:18 | 2011-08-10 15:31:50 | es_ES | a:7:{s:17:"message_threading";a:0:{}s:9:"junk_mbox";s:0:"";s:20:"default_imap_folders";a:4:{i:0;s:5:"INBOX";i:1;s:12:"INBOX.Drafts";i:2;s:10:"INBOX.Sent";i:3;s:11:"INBOX.Trash";}s:16:"message_sort_col";s:4:"date";s:18:"message_sort_order";s:4:"DESC";s:11:"search_mods";a:7:{s:1:"*";a:2:{s:7:"subject";i:1;s:4:"from";i:1;}s:10:"INBOX.Sent";a:2:{s:7:"subject";i:1;s:2:"to";i:1;}s:12:"INBOX.Drafts";a:2:{s:7:"subject";i:1;s:2:"to";i:1;}s:11:"INBOX.Trash";a:3:{s:7:"subject";i:1;s:4:"from";i:1;s:2:"to";i:1;}s:8:"Enviados";a:2:{s:7:"subject";i:1;s:4:"from";i:1;}s:5:"INBOX";a:2:{s:7:"subject";i:1;s:4:"from";i:1;}s:8:"Papelera";a:2:{s:7:"subject";i:1;s:4:"from";i:1;}}s:17:"collapsed_folders";s:11:"null&INBOX&";} |
+---------+-----------------------------+-----------+-------+---------------------+---------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> update users set preferences='a:2:{s:16:"message_sort_col";s:4:"date";s:18:"message_sort_order";s:4:"DESC";}' where username like 'xxx@yyyy.tld';
Query OK, 1 row affected (0.04 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from users where username like 'xxx@yyyy.tld';
+---------+-----------------------------+-----------+-------+---------------------+---------------------+----------+--------------------------------------------------------------------------------+
| user_id | username | mail_host | alias | created | last_login | language | preferences |
+---------+-----------------------------+-----------+-------+---------------------+---------------------+----------+--------------------------------------------------------------------------------+
| 5 | sheriff@chocolatfactory.com | localhost | | 2011-07-27 03:52:18 | 2011-08-10 15:31:50 | es_ES | a:2:{s:16:"message_sort_col";s:4:"date";s:18:"message_sort_order";s:4:"DESC";} |
+---------+-----------------------------+-----------+-------+---------------------+---------------------+----------+--------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql>

Una vez hecho este cambio, el usuario tiene sus preferencias modificadas, pero al menos ya ve sus carpetas. Seguro que hay alguna manera más "fina" de hacerlo, pero el usuario se impacientaba y ya me estaba gritando al teléfono... así que ajo y agua ;)

Cuidadín con lo que tocáis!

Roundcube: aumentar el tamaño máximo de archivos adjuntos

Hemos renovado nuestra interfaz de webmail, y ahora utilizamos RoundCube en el trabajo. La verdad es que el cambio de SquirrelMail a RC es abismal, y estamos encantados.

Pero hoy me encontrado con un usuario con un problema: no podía adjuntar archivos mayores de 2Mb, y en el anterior webmail se podía. Así que revisando la documentación he visto que RC coge directamente el valor máximo de los archivos adjuntos de la configuración PHP, así que ha sido tan fácil como buscar el php.ini y modificar el campo

upload_max_filesize = 8M

Y ya está. He hecho un reload del apache "por si las flies" y RC ha cogido el cambio automáticamente. Qué gusto!!!!

Liberar la RAM cacheada en Linux

¿No os ha pasado nunca que se os ha quedado un servidor sin RAM, y que no os ha quedado otra que reinciarlo? MIra que da rabia... y más si la RAM la estás viendo cacheada y no puedes/sabes liberarla.

Pues esto se va a acabar... más o menos. Buscando por la red, localizé un blog (Redes Privadas Virtuales) que daba una solución a este problemilla, y que la verdad es que funciona muy bien. La entrada original la podéis encontrar aquí, donde se explica un poco el porqué, y yo os dejo aquí mi pequeño script que automatiza el vaciado. Lo estoy implementando en los últimos servidores en los que estoy trabajando, y de momento da bastante buen resultado.

#! /bin/sh
sync
echo 3 > /proc/sys/vm/drop_caches
echo 0 > /proc/sys/vm/drop_caches

Yo pongo la entrada correspondiente en el cron y lo ejecuto una vez al día, a ser posible por la noche, y la verdad es que se nota.

Ya me diréis qué tal os funciona!

Hablitar SNMP en un Vmware ESX 3.5

Sé que a estas alturas, pocos serán los que utilicen vmware ESX 3.5, pero ahí va una cosilla que acabo de encontrar: cómo habilitar el SNMP.

En un principio podéis pensar que es una trivialidad, muy sencillo... pero bueno, no es tan trivial.

La "primera" parte consta en configurar y habilitar el servicio; de hecho ya viene configurado con la comunity public, y podéis mirar de arrancarlo y comprobar si funciona.
En esta primera parte, hay que comprobar que en el archivo de configuración

/etc/snmp/snmpd.conf

estén las entradas

rocommunity xxxx
dlmod SNMPESX /usr/lib/vmware/snmp/libSNMPESX.so

donde xxxx es la contraseña snmp para las consultas de sólo lectura.
Lo dicho, después arrancáis o reinciáis el SNMP

service snmpd start

La gracia de esta entrada es que, si esto no funciona, es porque el firewall del ESX está haciendo su trabajo, y no podemos obtener una respuesta. Hay que abrir el firewall para las peticiones SNMP, y eso lo hacemos de esta manera:

esxcfg-firewall -e snmpd
chkconfig snmpd on
service snmpd start

... y funciona!!! Ale, ahora a monitorizar ;)

Configurando los servicios en los runlevels

Alguna vez os habéis encontrado que habéis compilado una aplicación, y que por defecto no se añade a los runlevels para que se inicie al arrancar el servidor?

Es fácil, no os preocupéis.

En Red Hat, utilizamos chkconfig

chkconfig --list --> Listado de los servicios que hay en el servidor
chkconfig SERVICIO on --> Para añadir el servicio a la lista de servicios que arrancan por defecto
chkconfig SERVICIO off --> Para añadir el servicio a la lista de servicios que se paran por defecto

En Debian/Ubuntu, utilizamos update-rc.d

update-rc.d SERVICIO defaults --> Para añadir el servicio a la lista de servicios que arrancan por defecto
update-rc.d SERVICIO remove --> Para añadir el servicio a la lista de servicios que se paran por defecto

Si lo queréis más gráfico, podéis probar con rcconf

Compilar Encode::Detect

Tenía que compilar el módulo en perl Encode::Detect para un servidor que estaba instalando, y de repente me da el siguiente error:

gcc: error trying to exec 'cc1plus': execvp: No such file or directory
error: command 'gcc' failed with exit status 1

Buscando información del error, y después de pensar que la fuente que me había bajado tenía algún problema, he visto que era problema del compilador. He solucionado el problema instalando el g++, que el Debian se reduce a

apt-get install g++

Ubuntu (x64), Thunderbird 3 y Lightning

Menuda mañanita llevo para poder hacer el upgrade a thunderbird 3 (me he conformado con la rama 3.0 por desesperación). Primero que no hay disponibilidad en los repositorios por defecto que no sea de la rama 2. Después que el que hay de la rama 3.1 es una versión beta, y no me gusta... luego el Lightning que me está dando por saco...

Al final, esto es lo que me ha funcionado:

1) Utilizar el siguiente repositorio:
deb http://ppa.launchpad.net/eugenesan/mozilla/ubuntu karmic main
Para utilizarlo, lo añado a mano al /etc/apt/sources.list y después, recargo las fuentes con un
apt-get update
Instalo con normalidad
(sudo) apt-get install thunderbird
y la versión que me instala es la 3.0.3
Ya tengo la nueva versión de Thunderbird

2) Ahora, para instalar una versión compatible de Lightning (en castellano!!!!), la descargo de
http://stage.mozilla.org/pub/mozilla.org/calendar/lightning/releases/1.0b1/contrib/linux-x86_64/
y la instalo a través del propio Thunderbird
Herramientas (Tools) --> Add-ons

3) El siguiente paso ha sido migrar mi calendario Sunbird a Lightning. Fácil. Son hermanos así que ha sido muy sencillo. Primero he exportado desde Sunbird los datos que había a un archivo tipo .ics, y desde Ligtning los he importado. Me pregunta en qué calendatio quiero añadir las entradas (si tengo más de uno) y ya está.


Me queda pendiente traducir el Thunderbird a castellano, pero si lo consigo, ya os aviso!

Nuevo jailbreak para PS3 sin necesidad de hardware externo

Una de las charlas ofrecidas en el marco de la 27º Conferencia del Chaos Computer Club, tenía por título: "Console Hacking 2010". A pesar del genérico título destacaba una pequeña parte de su introducción: "We will detail the operation of current PS3 exploits, show a few new ones..." (detallaremos el funcionamiento de los exploit para PS3 actuales y unos cuantos nuevos...)

Mucha era la expectación ante lo que podría ser el anuncio de un exploit mejorado para la PS3 de Sony. Hasta ahora la PS3 podía ser liberada a través de sistemas que implican la conexión de un hardware externo. El sistema conocido como dongle. Pero hasta ahora no se había conseguido evadir la protección del sistema únicamente a través de código con la intención de hacer correr programas de manera no oficial.

fail0verflow, el equipo que lo ha conseguido, comenzó su charla hablando del estado actual de la seguridad en las consolas, haciendo un repaso por las que actualmente dominan el mercado, léase Wii, XBox360 o DSi. Tras ello repasaron el abanico de técnicas actuales de explotación centrándose en PS3.

Al final de la introducción pasaron al momento que todos esperaban. No defraudaron y presentaron un sistema de jailbreaking sin necesidad de apoyo de hardware externo (dongle-less) y algo no tan esperado y posiblemente más comprometedor: las claves privadas con las que se firma el software. Esto último posibilita que cualquiera pueda firmar código y hacerlo pasar por autorizado. El equipo las ha hecho públicas.

Según fail0verflow su meta era poder devolver la capacidad de instalar un sistema Linux en la PS3, opción que Sony eliminó en una de las actualizaciones del firmware. También anuncian que van a publicar la prueba de concepto y varias herramientas, pero dejan claro que no van a publicar ningún firmware no oficial, tarea que asumen se encargaran otros grupos.



Fuente: Hispasec