Limpiando Windows 10

Hace unos meses actualicé un portátil que tengo con Windows 7 a la última versión de Windows: Windows 10. Este equipo lo uso para distintas tareas, pero no tenía instalado ningún software que fuera indispensable, así que durante la instalación elegí la opción de hacer una instalación limpia.

Tengo que reconocer que funciona francamente bien. El buscador de programas integrado (cierto es que estaba disponible desde Windows 7), al estilo del que hay en diferentes escritorios de Linux, me parece un gran acierto. Hace ya un tiempo que el menú de Windows pasó de ser una referencia a ser un auténtico problema a gestionar. En su momento, especialmente en Windows XP, tuve que crear categorías (carpetas a las que añadía ' --') para anidar en las mismas software con similares funciones y hacer más sencilla la navegación por el menú. [Fin de Off Topic Abuelo Cebolleta]

En ese equipo hay una unidad SSD que tiende a llenarse, así que tras un análisis con WindirStat, he visto que había dos carpetas que desconocía completamente:

$Windows.~BT
$Windows.~WS

Una búsqueda en Google, me ha llevado a una entrada en el foro de Microsoft (aquí) donde explican no sólo que es seguro borrarla, si no cómo hacerlo. Reproduzco aquí los pasos ya que he tenido que modificar ligeramente los comandos propuestos para adaptarlos a la versión de Windows en español.

1. Abrir el símbolo del sistema en modo administrador.
• Pulsa la tecla de Windows o haz clic en el icono de Windows
• Teclea 'cmd'
• Haz clic con el botón derecho del ratón sobre la aplicación sugerida y elige 'Ejecutar como administrador'
2. En la línea de comandos ejecutar los siguientes comandos:

takeown /F C:\$Windows.~BT\* /R /A
icacls C:\$Windows.~BT\*.* /T /grant administradores:F
rmdir /S /Q C:\$Windows.~BT\
takeown /F C:\$Windows.~WS\* /R /A
icacls C:\$Windows.~WS\*.* /T /grant administradores:F
rmdir /S /Q C:\$Windows.~WS\

Terminados estos comandos, habréis conseguido liberar espacio en disco.

PMP + ITIL

Después de terminar la certificación del PMP, junto con unos colegas con lo que hicimos junto la certificación, nos encontramos con el problema de como aplicar el método a la vida real.

Uno de estos colegas (Raúl Casado, casi tan pesado que yo con el PMP) me comentaba que había tenido un momento de iluminación fusionando en la dirección de proyecto/servicio IT, la metodología de trabajo ITIL y la del PMP de gestión de proyectos.

La situación de un proyecto IT suele ser variopinta, pero normalmente parte de la obtención de un contrato para prestar un servicio IT durante un tiempo X (que puede dar lugar a posteriores renovaciones), estos están realizados pensando que vamos a darle un enfoque ITIL para el tratamiento del soporte del servicio (Incidencias, Problemas, Configuración, Entrega) y su provisión (SLA, Continuidad, Disponibilidad) durante el tiempo del contrato.

Inicialmente es difícil encajar esto con PMP desde la idea de Planificar, Ejecutar y Controlar, puesto que normalmente el proyecto objeto del contrato ya ha sido entregado y estamos en las fases posteriores donde hay que gestionarlo el resto del tiempo de vida del producto/servicio.

Durante la duración del contrato, suelen aparecer cambios en él. Son proyectos que buscan mejorar los operaciones que se prestan o añadir nuevas operaciones. Unos ejemplos son la implantación de un sistema de VPN o sustitución del Firewall para otra solución que integre un IDS en la que el enfoque ITIL no es el adecuado. 

Sin andarse por la ramas desde el enfoque ITIL como manejamos esto: ¿Se crea una petición donde te piden 'Quiero el servicio de VPN' o muchas peticiones donde van detallándose los requisitos de forma atomizada para la implantación del nuevo sistema? Sinceramente, no me parece la forma correcta de hacerlo. El sistema de gestión del Cambio propuesto por ITIL no creo que sea tampoco el sitio donde deba verse.

Lo más adecuado es tratarlo como un proyecto siguiendo la metodología del PMP, obviando ITIL. Es decir, reúnes los requisitos con el cliente, planificas los detalles de su alcance, tiempo y costes, estableces tus métricas de calidad, con sus riesgos asociados, en definitiva, planificas la implantación del proyecto. Luego lo ejecutas, resolviendo los problemas que pudieran surgir, controlando en todo momento que se están verificando todos los aspectos del proyecto y finalmente lo entregas. Una vez entregado al cliente, empezamos a llevar el servicio (como una operación más) con ITIL, resolviendo las incidencias y peticiones que surjan, provisionándolo para cumplir con los acuerdos del servicio, etc.

La idea es simple y versátil, combinando los dos métodos para alcanzar lo que el cliente pide, manteniendo separadas las cosas. Creo que tiene todo el sentido del mundo. Espero que con este artículo pueda poner en pie la escueta frase de tres líneas que me mandó Raúl a las 8 de mañana vía Telegram.

PD: Este artículo fue publicado inicialmente en PMP+ITIL

Una explicación de andar por casa de WebDAV

En mi anterior entrada hablada de una forma de tener los ficheros de claves de aplicaciones tipo keepass disponibles en internet para que fueran accesibles desde diferentes ubicaciones, permitiendo la posibilidad de realizar actualizaciones a las mismas desde cualquier sitio. Para poder hacer esto había recurrido a WebDAV, pero muchos de nosotros nos preguntaremos por ese desconocido.

De forma breve se puede decir que WebDAV no es más que el intento de establecer que la world wide web que conocemos disponga de la posibilidad de poder realizar modificaciones sobre los documentos publicados en la web. En realidad WebDAV son dos cosas, por un lado es un grupo de trabajo para definir el estándar que permita la funcionalidad descrita y por otro lado es un protocolo, surgido de ese grupo de trabajo, que lo define mediante una RFC de internet.

Lo que hace WebDAV es añadir varios métodos a los que define el estándar HTTP, que es el que se emplea en la comunicación entre los navegadores webs y los servidores webs. Típicamente, los métodos HTTP son GET, POST, PUT, CONNECT, HEAD (y algunos más) que nos permiten solicitar una página, enviar los datos de un formulario, subir un archivo, conectarnos al servidor y mandar las cabeceras (la información por ejemplo de las cookies se envía en el HEAD). Como vemos, aquí no hay nada que sirva para modificar el contenido de una página web (explícitamente, claro). El protocolo HTTP no lo permite.

En este punto es donde interviene WebDAV, proporcionando algunos métodos adicionales como COPY, MOVE, LOCK, UNLOCK, PROPFIND, PROPPATCH y MKCOL al protocolo HTTP para permitir copiar un recurso, moverlo de una ubicación a otra, bloquearlo/desbloquearlo, buscar propiedades, modificar propiedades, crear directorios (colecciones).

Como curiosidad sobre WebDAV, los sistemas de control de versiones como Subversion o Git lo utilizan internamente (clientes y servidor) cuando se accede al repositorio mediante HTTP. Es decir, ellos no han inventado la rueda para realizar las modificaciones sobre el servidor web que publica el contenido de sus repositorios, han utilizado el protocolo WebDAV implementando el cliente para comunicarse con un servidor HTTP como Apache, que dispone de la funcionalidad WebDAV activada (mediante los modulos dav y dav_fs para proporcionar la infraestructura necesaria).

También sistemas operativos permiten montar un recurso remoto del servidor web que dispone de la funcionalidad WebDAV como si fuera un directorio local, dejándonos modificar a nuestro gusto los contenidos que allí encontremos. O navegadores web que disponen de un cliente WebDAV (mediante plugins que se instala en el navegador) que ofrece la posibilidad de modificar al vuelo el contenido del servidor web sin recurrir a aplicaciones de terceros.

Esto también tiene una implicación interesante, al ser WebDAV un añadido al HTTP, podemos agregarle la capa de seguridad SSL para disponer de WebDAVS simplemente ofreciendo el contenido mediante el HTTPS, sin cambiar para nada el protocolo WebDAV.

De todas formas, las entradas de la wikipedia son mucho más amplias.

PD: Esta entrada fué publicada inicialmente en alidhaey.blogspot.com

Fichero de claves de keepass en apache con webdav

Un problema que se puede plantear es disponer de un lugar en internet en el que guardar tus ficheros de claves, accesible desde todos los sitios, que utilice algún protocolo seguro y que te permita también realizar las actualizaciones convenientes.

Para que sea accesible desde todos los sitios sin tener problemas con firewalls y restricciones de navegación, con comunicación cifrada, lo mejor es utilizar el protocolo https. El servidor apache nos da esa parte, si ademas le metemos la capacidad para manejar webdav que también es soportado por keepass, tenemos la funcionalidad de poder realizar las modificaciones desde donde realizamos las conexiones. En resumen, apache con modulo dav y dav_fs. El soporte para la comunicación cifrada con SSL es trivial.

En /etc/apache2/mods-available creamos el ficheros dav.conf con el siguiente contenido

Alias /ruta_publicacion/ /var/www/ruta_ficheros/
<Location /ruta_publicacion/ >
  DAV On
  Options -MultiViews
<Location>

 e igualmente creamos también dav_fs.conf (si no existe).

DAVLockDB ${APACHE_LOCK_DIR}/DAVLock

Lo primero establece un directorio donde se va a poder utilizar webdav, es decir, es el directorio donde podremos hacer modificaciones remotamente en los ficheros ofrecidos por el servidor apache. Lo segundo establece la ruta del fichero de bloqueos para el modulo webdav y no tener conflictos con actualizaciones simultáneas.

Nos aseguramos que el directorio /var/www/ruta_ficheros/ y sus ficheros son accesibles por el propietario que ejecuta apache (normalmente es www-data) y que los permisos adecuados para poder leer y escribir los ficheros (usualmente que coincida el propietario y grupo con los que se ejecuta el proceso apache). Luego ejecutamos la habilitación de los modulos y reiniciamos el apache con

$ a2enmod dav
$ a2enmod dav_fs
$ service apache2 restart

En /var/www/ruta_ficheros/ copiamos nuestros ficheros de claves que tenemos con keepass. Adicionalmente, podemos proteger con contraseñas el acceso al directorio /var/www/ruta_ficheros/ con las directivas dentro de las directivas Location de apache anteriores.

AuthType Basic
AuthUserFile /path/htpasswd/db
AuthName "Acceso restringido"
require valid-user

También podemos agregar el -Indexes a las opciones de Location, pero eso depende de los gustos del consumidor. Es importante la opción -MultiViews, de lo contrario aparecerá un error con el siguiente texto "Negotiation: discovered file(s) matching request:" en nuestro querido apache. Lo cual no te deja mucho margen de maniobra, salvo buscar en san google.

PD: Publicado inicialmente en Fichero de claves de keepass en apache con webdav.

VirtualBox Error VERR_VMX_NO_VMX

Hacía unos días que no ejecutaba la máquina virtual en el portátil y al intentarlo hoy me ha aparecido un error:

Fallo al abrir una sesión para la máquina virtual W XP Professional.
VT-x is not available. (VERR_VMX_NO_VMX).
Código Resultado: NS_ERROR_FAILURE (0x80004005)
Componente: Console
Interfaz: IConsole {8ab7c520-2442-4b66-8d74-4ff1e195d2b6}

Me ha descolocado el error porque hasta hace unos días, nunca habían protestado porque no tuviera habilitada la virtualización a nivel de BIOS, principalmente porque el microprocesador del portátil no soporta la virtualización a nivel de hardware.

Cómo recordaba que hacía poco que se había actualizado el equipo de la oficina, utilizando ahora VirtualBox 4.3.4, he mirado en los foros de virtualbox.org y he encontrado que precisamente se trata de un cambio introducido en dicha versión: por defecto, si no encuentra el hardware de aceleración, da error. Basta con indicarle el modo para que funcione correctamente:

$ VBoxManage modifyvm <vmname> --longmode off

No pierdas de vista que:

• La solución no puede ser aplicada desde la interfaz, sino que ha de emplearse la consola de administración.
• Debe lanzarse con el usuario que ejecutas las máquinas virtuales y no como root o cualquier otro.
• Se debe sustituir <vmname> por el nombre de la máquina virtual. Si el nombre contiene espacio, se han de usar las comillas (simples o dobles) para proteger los espacios.

Actualización (13/01/2014):
En configuraciones de 64 bit que no soportan virtualización, es necesario no sólo deshabilitar el longmode si no prácticamente cualquier función de virtualización de la CPU. La mejor forma de hacerlo es editando el fichero descriptor de la máquina virtual, que normalmente está ubicado en el directorio home o user, dependiendo del SO, de cada usuario del sistema.

La configuración debería quedar tal que así:

...
 <CPU count="1" hotplug="false">
       <HardwareVirtEx enabled="false"/>
       <HardwareVirtExNestedPaging enabled="false"/>
       <HardwareVirtExVPID enabled="false"/>
       <HardwareVirtExUX enabled="false"/>
       <PAE enabled="false"/>
       <LongMode enabled="false"/>
       <HardwareVirtExLargePages enabled="false"/>
       <HardwareVirtForce enabled="false"/>
 </CPU>
...

Fuente: Foro VirtualBox

La breve chuleta del comando ip

El comando ip forma parte de iproute (o iproute2). Iproute en sí es un gran desconocido. De hecho, me he encontrado en varios clientes que la utilización de iproute lo ven como algo 'opcional'. Un sin sentido que muestra desconocimiento de los sistemas Linux actuales.

También parte es culpa de muchos manuales, que todavía nos hablan de los comandos ifconfig y route como la referencia para la configuración de la red, la realidad es que esto no es así, teniendo comportamientos inadecuados en ciertos escenarios. Bueno, al grano que me pierdo, que esto sólo iba a ser una breve chuleta de lo se puede hacer con ip para consulta rápida.

Configuración de la IP en una interfaz

Aunque la configuración de la IP en una interfaz de red se hace en los ficheros de configuración (/etc/network/interfaces en Debian o /etc/sysconfig/networking-scripts/ifcfgX en Red Hat) o con los comandos ifconfig, esto no hace más que llamar a ip para realizar las acciones convenientes. 

El esquema general de ip es

ip [OPTIONS] OBJECT { COMMAND }

Los objetos son link, addr (utilizados ambos por ifconfig para asignación de ip y activar la interfaz), route (empleado por el comando route). Hay otros objetos como rule (configuración de rutas más avanzada) o tunnel (para los túneles) por nombrar alguno.

Poner la ip 10.20.30.40 con mascara de red 255.255.255.0 a la interfaz eth0 es algo tan simple como

ip addr add 10.20.30.40/24 dev eth0

Para retirar la ip a la interfaz, sustituimos el add por un del.

ip addr del 10.20.30.40/24 dev eth0

Al ejecutar el comando asignación de ip, también estamos estableciendo una ruta para comunicarnos con la red 10.230.30.0/24. Podemos hacer la prueba viendo antes las rutas (con el comando ip route) antes y despues de quitar la ip a la interfaz eth0.

Rutas y rutas por defecto

Aunque antes lo dije, cuando se establece un ip a un dispositivo, ya estamos agregando una entrada de ruta. Esta ruta sirve para comunicarse con los dispositivos de la misma red. Para comunicarnos con dispositivos de otras redes, hay que poner rutas adicionales. Con estas rutas indicamos que dispositivos se puede utilizar para enviar esas comunicaciones (o que ips se deben utilizar para comunicarnos con esos elementos).

Para comunicarnos con un equipo que pertenece a una red 192.168.100.1/26 podemos hacerlo mediante la una ruta que utilice la interfaz eth0 o con un ruta por defecto (todas las comunicaciones que vayan fuera, utilizan la de por defecto)

ip route add 192.168.100.100/26 via eth0ip route add default via eth0

Para quitar las rutas, se emplan los mismos comandos pero se sustituyen los add por del.

En el 100% de los casos, con esto tenemos resuelto los problemas que puede traernos hacer la configuración ip de cualquier dispositivo en nuestro Linux. Los problemas que nos pueden surgir desde aquí, tendrán más bien relación con el establecimiento de rutas avanzadas (objeto rules) y quedan fuera de esta chuleta.

¡RaspberryPi en casa!

¡Por fin tenemos las placas!

Ayer, tras varios meses de espera, nos llegaron las placas de la RaspberryPi.

Ahora queda el proceso de ponerlas en marcha, que iremos detallando y sobre todo contando que uso hemos pensado darles.
Vienen tal cuales, desnuditas ... aunque compramos la carcasa blanca por aquello de la presentación y que no nos mataran en casa por tener otro "cacharro" más en medio.
Ahora a por una tarjeta SD, un cargador compatible con la placa, un cable HDMI y un cable de red.
Iremos dando detalles.