Sergio Sainz

Por circunstancias de la vida me veo obligado a trabajar con Plesk a diario. Cuando se trata de dar hosting a miles de usuarios está claro que hace falta automatizar estas cosas. Muchas empresas grandes cuentan con su propio panel de control, pero no es el caso de todas y las pequeñas normalmente no se pueden permitir el desarrollo de su propio panel .

Paralells Plesk Control Panel 8.6 lista 7 de sus “Advantages”, en este caso voy a centrarme en esta:

Most Secure

Not only does Plesk control panel contain new security measures but also, existing security features have been improved. The control panel’s redesigned subsystem improves overall system security as well as support for 3rd party FTP servers that make secure uploads possible.

Fuente: http://www.parallels.com/products/plesk/advantages/

Al probar la  versión 9 que aún está en BETA supuse que sería aún más “segura” que la actual. Lamentablemente me he llevado una desilusión en este aspecto.

Todo esto viene a cuento de que este panel mantiene una base de datos que es el corazón del mismo. PSA es el nombre de la base de datos que conoceréis de sobra si alguna vez habéis administrado un servidor Plesk. Y aunque la idea puede ser buena las formas en las que se utiliza no lo son.

• La bbdd NO guarda ninguna integridad referencial, y como es necesario meterla mano cada vez que falla una operación como crear o borrar alojamientos, bbdd, usuarios, buzones… sino se tiene cuidado es fácil perder el control.
• Cuando se hacen actualizaciones del panel a veces cambian tablas, columnas, … y el panel empieza a dar problemas. Un ejemplo es al pasar de Plesk 8.2 a la versión que hay en estos momentos, Plesk 8.6.
• Y el ultimo punto pero no por ello menos importante. Los datos de los usuarios se guardan en la bbdd en TEXTO PLANO.

Así que si eres usuario de este panel de control ten cuidado porque esas contraseñas que das SON visibles.

Algunos ejemplos:

Mostrar las contraseñas de administrador de mySQL, MSSQL, Postgresql o cualquier bbdd a la que este suscrito el panel de control:

SELECT type,admin_password FROM DatabaseServers

De la misma forma se almacenan los usuarios y contraseñas de buzones de correo, ftp, logins a Plesk, usuarios de bbdd, etc…

Todo esto hace que la seguridad de Linux, Windows, MySQL, MSSQL, Postgresql, Qmail, etc se vaya al traste teniendo en cuenta la regla de oro de que Un sistema es tan seguro como su eslabón más débil.

La verdad es que me pregunto si será tan difícil guardar las contraseñas encriptadas….

Un cliente quiere enfrentarse a la administración de su servidor web por sí mismo y me pregunta sobre cuales son las tareas básicas de un administrador de sistemas para hacerse una idea. En frío esto ha sido lo que se me ha ocurrido comentarle:

- Informarse de las vulnerabilidades y exploits que se detectan para poder responder a tiempo.

- Mantener actualizado el sistema, esto incluye además del propio SO a todas las aplicaciones que en el servidor haya instaladas.

- Desactivar aquellos servicios que no se utilicen y desinstalar todas las aplicaciones que no sean necesarias para el funcionamiento del servicio.

- Monitorizar los servicios críticos y tener un plan de contingencia que aplicar en caso de parada de cualquiera de ellos.

- Tener un backup disponible de los datos del servidor, este puede ser diario, varios al día. Depende de la criticidad y periodicidad de los cambios que se realicen y las perdidas que podamos asumir.

- Configurar alertas de sistema y revisar logs, sucesos, errores, que se vayan produciendo para poder tomar medidas.

- Monitorizar los recursos para detectar cuellos de botella, errores de memoria, prever fallos de discos, controlar el Raid…

Son sólo algunas de las tareas a las que debe enfrentarse a diario un sysadmin. El consejo es que si no puedes hacerlas, por el motivo que sea, busques a alguien que lo haga por ti.

Después de comentarle lo anterior se me han ido ocurriendo muchas más cosas…

- Diseñar y planificar.

- Tener controlados a los usuarios, los permisos de los mismos y las políticas.

- Formar a los usuarios para que sepan lo que pueden hacer, como deben hacerlo y aclarar sus dudas técnicas.

- Escribir scripts que sirvan a automatizar tareas habituales y configurar tareas programadas (crons) para diferentes tareas de mantenimiento (defrag, backups, limpieza de logs…).

- Documentar lo que se va haciendo, no para que el que venga detrás de ti a robarte el puesto tenga todo más fácil sino para que no se te olvide lo que vas haciendo y como lo has hecho ya que te será útil y evitarás romperte la cabeza cuando te enfrentes nuevamente a ese problema que te tuvo una noche o un fin de semana movidito, te lo aseguro.

- Intentar la configuración óptima del sistema para tratar de sacarle el mayor rendimiento posible. Muchas veces se amplía hardware innecesariamente cuando el problema real es que se desaprovechan recursos innecesariamente.

- Documentación e implantación de un buen plan de recuperación ante desastres que pueda llevar alguien a cabo si estás de vacaciones.

- Tener un sistema (puede ser virtualizado) para probar las cosas antes de ejecutarlas en producción.

Seguro que hay muchas más cosas, ¿se te ocurren?.

En este tip se indica como recuperar las excepciones que Plesk añade por defecto tras su instalación.

Desde %plesk_bin% ejecutar:

firewall.exe –s –i eth0

Donde “eth0” debe ser cambiado por el nombre de la interfaz de red.

Este comando sirve para redireccionar la salida en pantalla de un comando al portapapeles, es decir si queremos copiar el contenido de archivo.txt al portapapeles para poder pegarlo en cualquier sitio basta con ejecutar:

clip < archivo.txt

Si lo que queremos es pasarle el resultado de un comando basta con hacer un “pipe”: Por ejemplo:

dir | clip

Esta utilidad de la línea de comandos está incluida en Windows Vista pero puede utilizarse desde Windows XP u otras versiones copiando clip.exe en c:\Windows\System32

En el post anterior veíamos como reparar una bbdd. Si el estado es cualquiera de los otro dos (REPAIR MODE o EMERGENCY), entonces tendremos que recurrir a otro tipo de apaños. En mi caso he experimentado el problema tras tratar de recrear un nuevo transaction log para una bbdd, pero también puede servir en casos en el que el archivo de datos este dañado.

Voy a indicar lo que hice para reproducir el problema. Separé una bbdd y borré su .LDF, luego al adjuntarla obtenía este error:

Error al adjuntar las bases de datos. Haga clic en el hipervínculo de la columna de mensajes para obtener más información.

Crearlo a mano no es muy buena idea según nos muestra el siguiente error:

The operating system returned error 38(Se ha alcanzado el final del archivo.) to SQL Server during a read at offset 0000000000000000 in file ‘C:\Archivos de programa\SWsoft\Plesk\Databases\MSDE\MSSQL\Data\sergiodb_log.ldf’. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online. (Microsoft SQL Server, Error: 823)

Dado que no era posible adjuntar la bbdd, el siguiente paso fue renombrar el archivo de datos sergiodb.mdf por sergiodb_bak.mdf y crear una nueva bbdd con el nombre sergiodb. Con esto obtenemos un nuevo mdf y un ldf limpio.

El siguiente paso fue detener SQL Server y sobrescribir sergiodb.mdf por el bueno e iniciar de nuevo SQL. Con esto se produce el siguiente error al intentar por ejemplo ver las propiedades de la bbdd:

Unable to open the physical file “C:\Archivos de programa\SWsoft\Plesk\Databases\MSDE\MSSQL\Data\sergiodb.mdf”. Operating system error 5: “5(Acceso denegado.)”. (Microsoft SQL Server, Error: 5120)

Tras dar permisos NTFS al archivo de datos, el error cambiaba a:

Database ’sergiodb’ cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details. (Microsoft SQL Server, Error: 945)

Con todo esto el estado de mi BD era RECOVERY_PENDING

SELECT state_desc FROM sys.databases WHERE name =’sergiodb’;

SOLUCION

ALTER DATABASE sergiodb SET EMERGENCY ;– lo primero que haremos es pasar la bbdd del modo “RECOVERY_PENDING” al modo “EMERGENCY” (es necesario tener privilegio de sysadmin)

ALTER DATABASE sergiodb SET SINGLE_USER ;– La ponemos en modo de usuario único.

DBCC CHECKDB (sergiodb, REPAIR_ALLOW_DATA_LOSS )WITH NO_INFOMSGS ;– Chequeamos la bd con la opción REPAIR_ALLOW_DATA_LOSS

ALTER DATABASE sergiodb SET MULTI_USER ;– Por ultimo la ponemos en modo multiusuario

Ahora debería estar en modo ONLINE y funcionando.

Debido a múltiples circunstancias como cortes eléctricos inesperados, problemas de espacio en disco, fallos de hardware, que hayas borrado el archivo de log (.ldf), etc. Una bbdd puede corromperse, normalmente la mejor manera de solucionar esto es recurrir a la última copia de seguridad pero como puede ocurrir en estos casos no hay copia o la que tenemos disponible es ya algo vieja. En esos casos quizá aún podamos recuperar la información.

Una bbdd puede tener estos estados (LINK):

• ONLINE: La base de datos está disponible para su acceso. El grupo de archivos principal está en línea, aunque la fase de deshacer de la recuperación puede no haberse completado.
• OFFLINE: La base de datos no está disponible. Una base de datos pasa a estar sin conexión por la acción explícita del usuario y permanece sin conexión hasta que el usuario toma otra acción. Por ejemplo, la base de datos puede desconectarse para mover un archivo a un nuevo disco. La base de datos se vuelve a poner en línea una vez completado el traslado.
• RESTORING: Uno o varios archivos del grupo de archivos principal se está restaurando, o uno o varios archivos secundarios se están restaurando sin conexión. La base de datos no está disponible.
• RECOVERING: Se está recuperando la base de datos. El proceso de recuperación es un estado transitorio, la base de datos se pone automáticamente en línea si la recuperación tiene éxito. Si la recuperación no tiene éxito, la base de datos pasa a ser sospechosa. La base de datos no está disponible.
• RECOVERY PENDING: SQL Server ha encontrado un error relacionado con un recurso durante la recuperación. La base de datos no está dañada pero pueden faltar archivos o bien limitaciones de recursos del sistema pueden estar impidiendo que se inicie. La base de datos no está disponible. Se necesita una acción adicional por parte del usuario para resolver el error y permitir que se complete el proceso de recuperación.
• SUSPECT: Como mínimo un grupo de archivos principal es sospechoso y puede estar dañado. La base de datos no se puede recuperar durante el inicio de SQL Server. La base de datos no está disponible. Se requiere una acción adicional por parte del usuario para resolver el problema.
• EMERGENCY: El usuario ha cambiado la base de datos y ha establecido el estado en EMERGENCY. La base de datos está en modo de usuario único y se puede reparar o restaurar. La base de datos está marcada como READ_ONLY, el registro está deshabilitado y el acceso está limitado a miembros de la función fija de servidor sysadmin. EMERGENCY se utiliza principalmente para solucionar problemas. Por ejemplo, una base de datos marcada como sospechosa se puede establecer en el estado EMERGENCY. Esto puede permitir al administrador del sistema acceso de sólo lectura a la base de datos. Sólo los miembros de la función fija de servidor sysadmin pueden establecer una base de datos en el estado EMERGENCY.

   

Cuando se corrompe la tendremos seguramente en Online, Recovery pending o Suspect.

Puedes ver el estado de la BD utilizando esta consulta (sustituye sergiodb por la bbdd a consultar):

SELECT state_desc FROM sys.databases WHERE name = 'sergiodb';

Si la bbdd está en estado ONLINE, lo más fácil es intentar un checkdb con la opción REPAIR_ALLOW_DATA_LOSS.

DBCC CHECKDB (MAGIC, REPAIR_ALLOW_DATA_LOSS)WITH NO_INFOMSGS

Más info en http://technet.microsoft.com/es-es/library/ms188422.aspx

Mañana publicaré como reparar si la bbdd se encuentra en alguno de los otros 2 modos o no se puede adjuntar.

El Transaction Log de SQL server es uno de los quebraderos de cabeza para muchos administradores noveles que no cuentan con un buen plan de mantenimiento o no conocen a fondo el funcionamiento de SQL como para reducirlo a mano. En este post trataré de explicar y dar algunas soluciones rápidas para evitar el aburrimiento. A quien quiera información más detallada le recomiendo los Libros en Pantalla de SQL o Googlear un poco que nunca está de más ;).

¿Qué es el Transaction Log?

Por cada bbdd (archivo .mdf) se crea un archivo de log (archivo .ldf) en el que se almacenan todos los cambios que se producen en la bbdd. En él se van guardando cambios que luego permitirán volver atrás (rollback) en una transacción o incluso hacer una recuperación a un estado anterior.

¿Por qué puede ocupar mucho más que la propia bbdd?

Cuando se ejecutan muchas consultas y/o afectan a un gran número de registros, produciendo cambios en la bbdd. Todos los cambios se van almacenando en el transaction log, si además no tenemos un plan de mantenimiento que reduzca este log de forma periódica el .ldf se irá llenando hasta ocupar una gran cantidad de espacio y terminará por llenar el disco.

¿Cómo se reduce el log de transacciones?

Existen varias maneras, la forma más recomendable es utilizando un plan de mantenimiento que realice una copia de seguridad del registro de transacciones. A continuación vamos a ver algunos ejemplos y posibilidades:

• Backup log: Guardamos un backup y luego reducimos el log de la bbdd “sergiodb” a 10 Mb

USE [sergiodb] – Utilizamos la bbdd sergiodb
CHECKPOINT – Para que todas las páginas de memoria se escriban en la bd
GO

EXEC sp_addumpdevice ‘disk’ ,‘CopiaMiBase_sergiodb’ ,‘c:\LogMiBase_sergiodb.bak’ – Creamos un punto donde guardaremos el log y procedemos a hacer el backup con truncado del log

BACKUP DATABASE sergiodb TO CopiaMiBase_sergiodb
BACKUP LOG pruebamm WITH TRUNCATE_ONLY
DBCC SHRINKFILE (’sergiodb_log’, 10) –- Dejamos el archivo de log con un tamaño de 10 Mb

• Reducir sin hacer backup:

USE [sergiodb] – Utilizamos la bbdd sergiodb
CHECKPOINT – Para que todas las páginas de memoria se escriban en la bd
GO
BACKUP
LOG sergiodb WITH TRUNCATE_ONLY – Truncamos el registro
DBCC SHRINKFILE (sergiodb _Log, 10) – Lo reducimos a 10 Mb

• Eliminar el archivo de log para que se genere de nuevo: Esta solución es más arriesgada, aunque a veces es necesario tirar de ella por ejemplo cuando el log es tan grande que el servidor no tiene espacio o memoria como para gestionarlo.

ALTER DATABASE [sergiodb] SET SINGLE_USER; – Ponemos la bbdd en single user
GO
sp_detach_db ’sergiodb’ – Separamos la bbdd

Ahora es necesario localizar el archivo de log, en mi caso C:\Archivos de programa\SWsoft\Plesk\Databases\MSDE\MSSQL\Data\sergiodb_log.ldf y eliminarlo. Luego ejecutamos esta nueva consulta para adjuntarla de nuevo.

USE [master]
CREATE</SPANDATABASE [sergiodb] ONFILENAME=(‘C:\Archivos de programa\SWsoft\Plesk\Databases\MSDE\MSSQL\Data\sergiodb.mdf’),
(FILENAME=‘C:\Archivos de programa\SWsoft\Plesk\Databases\MSDE\MSSQL\Data\sergiodb_log.LDF’)
FOR ATTACH
ALTER DATABASE sergiodb SET MULTI_USER; – Ponemos la bbdd en multi user

Me he encontrado con este problema al pasar de PS 1 en español a la versión PS 2 la cual sólo he encontrado en inglés. Al no coincidir los locales, esto es lo que ocurre cuando se intenta obtener la ayuda de un comando.

PS C:\> get-help get-childitem

Get-Help : Error loading help content for Get-ChildItem from file “Microsoft.PowerShell.Commands.Management.dll-Help.xml”. Details: Microsoft.PowerShell.Commands.Management.dll-Help.xml.

At line:1 char:9

+ get-help <<<< get-childitem

PS C:\> get-help

Get-Help : Cannot find Help for topic “default”.

At line:1 char:9

+ get-help <<<<

SOLUCION:

Copiar el directorio C:\windows\system32\windowspowershell\v1.0\en-US en C:\windows\system32\windowspowershell\v1.0\es-ES

Cuando se instala SQL Server, este se configura teniendo en cuenta las interfaces habilitada en ese momento. Pero si más tarde habilitamos una nueva interfaz o la deshabilitamos esta no aparece/desaparece de la configuración de red.

La forma que he encontrado para hacer esto es editando el registro, toda la información se guarda en:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer\SuperSocketNetLib\Tcp\]

Por tanto una forma de quitar una IP es borrar su registro y para añadirla lo que yo hago es exportar una clave ya existente y editarla como deseo antes de ejecutar el .reg para que inserte los cambios.

Cariño esta noche tengo que trabajar hasta tarde… ha salido una vulnerabilidad grave y tengo que hacer una importante actualización de seguridad en los equipos de la empresa no me esperes en toda la noche….

He aquí la actualización en cuestión que ocupa más de 60 mb y catalogada de IMPORTANTE para que ningún administrador se la pase por alto.

Sin embargo, leyendo un poco el resumen de la actualización la verdad es que no parece muy importante.

Mejor leer un poco más detallada la actualización por si hay letra pequeña…. http://support.microsoft.com/kb/955020

Tras leer detenidamente, la verdad es que para actualizar un problema de que al seleccionar el diccionario inglés o alemán no reconozca las palabras y sean subrayadas como que no están bien escritas no me parece importante y sobre todo no entiendo porque ocupa tanto.

Las palabras en cuestión son:

El ejemplo del que puede ser víctima el usuario de no aplicar el parche es (copio literal):

Consider the following example scenario:

In this scenario, this word is flagged as being misspelled.

Note This issue also occurs if the application uses the German dictionary.

La verdad es que no me convence y me voy a “arriesgar” no aplicando este parche y ahorrando un poco de espacio en mi disco que parece que últimamente hay que malgastarlo al ser el almacenamiento barato…