Sergio Sainz

1. En Windows tenemos que tener un directorio compartido con permisos para el usuario que queramos utilizar.

2. En LINUX se crea el directorio donde queremos montar el directorio compartido:

# mkdir /mnt/equipowin/

3. Para montar hay que especificar la ruta del directorio compartido (//10.0.0.1/recurso), el usuario (sergiosainz), la contraseña (qwerty) y donde queremos montar (/mnt/equipowin), Sustituye esos valores por los que correspondan en tu caso y ya tienes la partición montada.

 
# mount -t cifs //10.0.0.1/recurso -o username=sergiosainz,password=qwerty /mnt/equipowin/

En Windows 2008, Vista SP1 y XP SP3 se utiliza el protocolo RDP 6.1*. En estás versiones se el parámetro /console deja de estar soportado y se sustituye por /admin. Por tanto la cosa quedaría así:

mstsc /v:192.168.0.100 /admin

Es importante tener esto en cuenta sobre todo si tenéis aplicaciones que utilicen este modificador ya que no van a “cantar” ningún error ignorando esta opción.

Los parámetros soportados por esta nueva versión son:

—————————
Remote Desktop Connection Usage
—————————
MSTSC [<connection file>] [/v:<server[:port]>] [/admin] [/f[ullscreen]]

[/w:<width> /h:<height>] [/public] | [/span] [/edit "connection file"] [/migrate]

"connection file" — Specifies the name of an .rdp file for the connection.

/v:<server[:port]> — Specifies the remote computer to which you want to

connect.

/admin — Connects you to the session for administering a server.

/f — Starts Remote Desktop in full-screen mode.

/w:<width> — Specifies the width of the Remote Desktop window.

/h:<height> — Specifies the height of the Remote Desktop window.

/public — Runs Remote Desktop in public mode.

/span — Matches the remote desktop width and height with the local

virtual desktop, spanning across multiple monitors if necessary. To span

across monitors, the monitors must all have the same height and be aligned

vertically.

/edit — Opens the specified .rdp connection file for editing.

/migrate — Migrates legacy connection files that were created with

Client Connection Manager to new .rdp connection files.

Muy recomendable el siguiente artículo que explica, mucho mejor de lo que yo lo haría, los motivos que han propiciado este cambio.

* RDP = Remote Desktop Protocol.      ** RDC = Remote Desktop Connection (cliente)

En la primera parte de este post aprovechaba para recomendar VisionApp para Windows porque es la aplicación que yo utilizo desde hace ya bastante tiempo, pero existe otra parecida llamada ROYALTS por si os apetece probar (cuestión de gustos):

Por defecto Windows viene con un par de sesiones de TS. En entornos de trabajo en los que varios acceden a administrar una máquina vía TS, es habitual encontrarse con gente a la que se le olvida cerrar su sesión porque simplemente cierra el cliente de Remote Desktop sin usar la opción cerrar sesión, con lo que cuando un tercero necesita acceder para algo se encuentra con el siguiente mensajito:

Es entonces cuando en mi oficina se escucha el grito de "¿quien coño esta dentro del server XXX ?“.  Obviamente nadie responde porque nadie está dentro ni nadie ha tocado nada…

La solución a este problema es tan simple como conectarse físicamente al server, iniciar sesión, ver quién está dentro y cerrar las sesiones. Pero ¿que pasa cuando no estás en el CPD y el servidor no está a tu alcance inmediato?. La solución está en acceder usando el parámetro /console. Por ejemplo (sustituye 192.168.0.100 por la IP del server):

mstsc /v:192.168.0.100 /console

Todos los clientes gráficos que conozco también incluyen la opción console.

Los clientes que recomiendo para sesiones terminal server:

- Windows: VisionApp

- MAC: CORD.

- Linux: Krdc

Antes de nada, quiero aclarar que me refiero únicamente al motor web que sirve Plesk como panel de control, no a las aplicaciones y dominios que se crean a través del panel y se lanzan a través de IIS. Estas sí que van bien realizando algunos ajustes previos que si interesa puedo comentar en otro post.

Me he encontrado con varios problemas al trabajar con Plesk sobre IIS, pero el problema lo he notado más aún al probar IIS 7 con Plesk 9 y tras realizar algunas sencillas pruebas desde las que he podido reproducir varios errores a partir de una instalación básica he podido comprobar que muchos de ellos se solucionan al pasar Plesk a funcionar sobre Apache.

Para cambiar Plesk a funcionar sobre Apache basta con ejecutar desde shell:

%plesk_bin%\reconfigurator.exe –switch-plesk-web-server –new-provider=apache

Con ello, también he notado un mejor rendimiento y velocidad de carga del panel apreciable desde el primer momento.

Recomiendo al que pueda que lo pruebe. Espero que Parallels le de una vuelta al funcionamiento de su panel sobre IIS 7 y poder escribir lo contrario para futuras versiones…

Si necesitas volver a IIS

%plesk_bin%\reconfigurator.exe –switch-plesk-web-server –new-provider=iis

Por lo general los clientes de ftp intentan conectar por defecto en modo pasivo por lo que conviene habilitar nuestro servidor ftp y firewall para aceptar este tipo de conexiones.

Lo primero es acceder al administrador de IIS e indicar al servidor de ftp que rango de puertos puede utilizar para aceptar conexiones pasivas, puedes ampliar este rango según tus necesidades. En mi caso he decidido habilitar el rango 5000-5050.

Tras eso abrimos una shell y creamos la correspondiente regla para abrir el puerto 21:

C:\>netsh advfirewall firewall add rule name="FTP (non-SSL)" action=allow protocol=TCP dir=in localport=21

Y habilitamos el modo stateful FTP (*):

C:\>netsh advfirewall set global StatefulFtp enable

(*): El modo stateful FTP filtering permitirá abrir y cerrar ventanas de comunicación observando el tráfico en tiempo real y de una  manera dinámica. El modo de conexión "PASV" hace que el servidor de ftp abra un puerto libre dentro del rango que hemos indicado en la configuración de FTP7 y acepte conexiones del cliente en él.

Este sólo es un tip rápido, para más información recomiendo el siguiente enlace.

Útil sobre todo para un entorno Server Core:

Para habilitar ICMP (los pings):

netsh firewall set icmpsetting 8 enable

Siguiendo la misma regla, para desactivar:

netsh firewall set icmpsetting 8 disable

Si queremos ver el estado del firewall y un listado de los puertos abiertos en todas las interfaces:

netsh firewall show state

Al pasar a actualizar a la versión de Plesk 8.6 (la última que hay actualmente) desde Plesk 8.2 me he encontrado con problemas diversos por culpa de que la base de datos que utiliza Plesk (llamada psa) ha cambiado columnas en unas cuantas de sus tablas lo cual genera diversos problemas a la hora de trabajar con Plesk, hacer backups, etc…

Tomando como referencia la psa de un Plesk 8.6 y otro 8.2 se puede comparar las columnas de las diferentes tablas y crear un script que realice los ALTER TABLE correspondientes, pero sino te quieres complicar mucho la vida este programita puede arreglarte la bd y solucionarte la papeleta.

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?.

Esta es la última conferencia a la que he podido asistir en la OSWC debido a que esta misma tarde me vuelvo a Bilbao.

El nombre de la sesión tecnológica es “LINUX en el corazón del DATACENTER: cómo implantar infraestructuras basadas en estándares abiertos y optimizadas para aplicaciones de misión crítica”. Por Adriano Galano de Fujitsu-Siemens.

He anotado tan sólo los puntos que me han parecido interesante con intención de resumir lo que me interesaba y descartando todo el rollo comercial.

• Repaso sobre la evolución de los datacenters. Mainframes > Distributed Computing > Server Farms (Hoy) >  Vitualización > automatización > Utility computing (servicios en lugar de servidores).
• Servidores PRIMERGY: Desde 1 socket y 8 gb hasta 96 socket y 2.304 Gb de RAM.Preparados para Xen, VMWare, Hypervisor. Virtualización embebida, Tecnologia de virtualización de I/O y PAN Manager.
• Soporte técnico para Linux.
• kernel patch desarrollados para permitir reemplazar memoria y cpus en caliente.

Vamos a ver si nos da tiempo a dar una vuelta y ver algo más antes del viaje de vuelta a casa.