Translate

domingo, noviembre 08, 2015

Instalar Windows 10 en la Teclast x98 3G / Air II

Instalar Windows 10 en la Teclast x98 3G / Air II

Bueno, muchos de los compradores de esta tablet la habrán adquirido por una de sus principales características, y es que Windows funciona bastante bien en esta tablet con un coste casi reducido, pero lo cierto es que tener una tablet en chino abreviado no nos gusta a muchos, y menos si no sabemos lo que trae de serie.

En mi caso Windows no venía en la tablet, he tenido que realizar todos los cambios posibles para poder ejecutarlo, he actualizado la BIOS a la versión 2.02 y he instalado los dos S.O. que "soporta" la X98 Air II.


Quería introducir cómo se hacía antes de que se nos ocurriera poner las instalaciones procedentes de ISOS originales, para cuando tenga más tiempo. La finalidad de esta entrada es un manual útil en el que ver cómo se instala Windows intentando aprovechar el máximo de espacio posible.

La instalación original trae una partición de más de 4GB para recuperación de datos, es absolútamente necesaria si se conserva el Windows de serie, pero nosotros no queremos eso, queremos ganar esos 4GB más quitarle peso a la instalación.

Para ello el primer paso es preparar una memoria USB, recomendamos usar el programa RUFUSporque sincéramente, funciona muy bien con sistemas UEFI, pero se puede utilizar la herramienta oficial de Microsoft (Windows USB/DVD Download Tool) o la propia que vamos a utilizar para descargar la iso original de la página de Microsoft.

Dependiendo de nuestro PC (Windows Anfitrión desde el que creamos el USB, si es de 32 bits o 64 bits, no confundir con la tablet) habrá que ejecutar o uno o el otro. Los enlaces de las herramientas son descarga directa de la página de Microsoft. Desde ahí podemos obtener el .iso del DVD de instalación.





El segundo paso es tener un HUB USB autoalimentado y un teclado. El proceso de instalación de Windows desde la iso original no permite táctil hasta que concluya, así que es absolutamente necesario, y es muy recomendable que sea autoalimentado porque la tablet no es un centro de carga, el USB-OTG tiene una instensidad bastante limitada para que un pincho pueda funcionar, pero a veces (no sólo durante el proceso de instalación) la corriente no es suficiente y da errores de lectura. En mi caso he utilizado uno con una intensidad de 1A.



Bien, arrancamos RUFUS, metemos el pincho usb que utilizaremos en el PC y seleccionamos la iso que vamos a utilizar para el proceso:


Es muy importante aclarar una cosa, la Teclast X98 3G / Air II lleva dentro una arquitectura de 64bits, pero la BIOS que trae la Teclast, hasta el momento, trae de serie un bloqueo de instalaciones de Windows a 32bits. En una futura entrada dedicada exclusívamente a las investigaciones sobre la BIOS lo explicaré más detenidamente, pero por el momento dejar claro: NO SE PUEDE INSTALAR UN WINDOWS DE 64 BITS, LA BIOS EN EL MOMENTO QUE SE ARRANCA LA INSTALACIÓN QUEDA BRICKEADA. Si se produce el caso más atentos a la entrada del blog sobre la BIOS.

Bueno, continuamos el proceso habiendo seleccionado una .iso de Windows 10 32bits con la opción de "Tipo de la partición y del sistema destino" en "GTP para UEFI", si se selecciona otra no arrancará.

Conectamos el HUB a la tablet, un teclado y un ratón al HUB y la memoria de instalación de Windows al HUB, y nada más encender pulsamos la tecla suprimir, eso nos llevará dentro de la BIOS.


Bien, una vez ahí tenemos que ir a la última pestaña, bajar hasta la opción donde se encuentre nuestra memoria USB (en mi caso UEFI: Sandisk) y pulsamos Intro. Si el pincho está bien hecho arrancará una pantalla negra con el icono de carga de Windows 8-8.1-10 y después el formulario de la instalación:

Yo he tenido que arrancar la tablet e inmediatamente pulsar F8, asi ademas de android sale en la elección de arranque una ventana de windows por usb, como en los mac




El siguiente paso importante es el particionado y donde vamos a instalar Windows, nuestro objetivo es aprovechar al máximo el espacio. Éste es el sistema de particiones explicado que un usuario normal debería de tener:





En él se explican todas las particiones de Android y las particiones de Windows para una instalación dual de Android y Windows 8.1, nosotros perseguimos mejorarla, por lo que necesitamos que Windows 10 no cree más particiones de las necesarias.

 ¿Por qué digo eso? Windows 10 crea un tipo de partición nueva de 16 MB de tipo MSR queobligatoriamente se necesita para poder instalar Windows 10. Pero es la única partición que nos va a requerir, por lo que nos podremos ahorrar la partición de Windows Recovery. Para el que la quiera tener le supondrá 450 MB adicionales como mínimo, no es mucho comparados con los más de 4 GB que ocupa la partición china que jamás utilizaremos.



Bien, sólo mirar la fila de arriba, la fila de abajo es una SD de 8Gb que tengo adicional. La partición con letra Q: es la última partición de Android (DATA) en formato ext3 y la siguiente es la partición C: que es la instalación de Windows, no hay particiones de Recovery ni nada por el estilo. ¿Cómo se consigue eso? Hay dos maneras:

- La correcta y sencilla (recomendada): Antes de arrancar la instalación de Windows debemos de tener las dos particiones creadas, entre Q: y C: hay una partición que no se aprecia de 16MB que es del tipo MSR que Windows solicita. Para crearla lo podemos hacer desde Android o desde una distro Linux, en otra entrada se explicará más a fondo cómo crear una live de Linux para poder hacer este proceso.

- La rápida con truco (no recomendada pero valorable porque se ganan los 450MB+250MB): El instalador de Windows es muy quisquilloso y no hace más que quejarse, cuando llegamos al sistema de particiones le decimos que la instalación vaya en el espacio libre sin ningún tipo de particionado, a continuación, cuando nos pregunte si queremos continuar con la instalación le decimos que sí, pero en ese momento cancelamos (se puede cancelar el paso o cancelar la instalación para volver a empezar). En ese momento cuando volvamos a la parte del instalador donde se encuentran las particiones veremos que Windows ha creado durante ese proceso las 4 particiones que él dice necesitar; podemos continuar así y decirle que nos instale Windows en la última partición, pero sólo necesitamos la primera de ellas (partición MSR de 16MB), así que eliminamos las otras tres particiones que no sean MSR y creamos una partición (nos obliga a usar NTFS) que ocupe el resto del espacio. En ese momento Windows dirá que puede continuar el proceso de instalación y aprovecharéis el espacio al máximo sin partición de recuperación ni partición de arranque UEFI, pero el proceso será correcto.




El siguiente paso es automático, no dista de lo que es una instalación clásica de Windows, hasta que lleguemos al último formulario de Windows que habla de la privacidad y del nombre de usuario y contraseña. Lo configuramos a nuestro gusto (en mi caso todas las opciones de privacidad bien configuradas).

Si se ha realizado el truco de las particiones (sin partición UEFI de Windows) es absolutamente necesario que se mantenga la memoria USB de instalación todo el tiempo conectada hasta que termine el proceso de instalación.

En Windows 10, al igual que cuando instalábamos Windows 8.1, nos faltaban todos los drivers, necesitamos instalarlos. Hay varias maneras, la clásica que todos hemos hecho, es ir uno a uno por todos los controladores e instalaros (tanto sobre el driver, botón derecho e instalar - como desde el administrador de dispositivos -> instalar controlador del hardware). Personalmente considero que es más sencillo utilizar un restaurador de drivers que los instale automáticamente, os dejo en el siguiente enlace uno de mi tablet (drivers).

Espero que os sirva de ayuda y que haya quedado lo más claro posible.

jueves, noviembre 05, 2015

Monitorización de Apache Tomcat con psi-probe.

Monitorización de Apache Tomcat con psi-probe.


0. Índice de contenidos.


1. Introducción

Psi-probe es un monitor de Apache Tomcat que nació como un fork de Lambda Probe, debido a la falta de soporte sobre el mismo y las dudas en cuanto a su futuro.
Psi-probe es un proyecto con licencia GPLv2 que, según describen en su propia documentación, permite monitorizar en remoto el estado del servidor en los siguientes aspectos:
  • peticiones: dispone de un monitor de tráfico en tiempo real,
  • sesiones: analizar atributos en sesión, estimar el peso de las mismas,
  • jsp: navegar, ver el código fuente, recompilar!.
  • fuentes de datos: analizar el uso del pool de conexiones, ejecutar queries.
  • logs: ver el contenido, descargar, cambiar el nivel de trazabilidad en caliente.
  • hilos: ver la pila de ejecución, “matarlos”.
  • conextores: ver el estado, usando gráficas.
  • cluester: ver el estado, usando gráficas.
  • JVM: ver el uso de memoria, lanzar el GC, reiniciar la JVM.
  • Sistema: uso de CPU, memoria,…
Está documentada su instalación tanto en Apache Tomcat como en Jboss Application Server, con el objetivo de reemplazar el tomcat manager oferciendo mucha más funcionalidad, para el primero, o simplemente de disponer de un monitor online de la salud de tu servidor, para el segundo.

2. Entorno.

El tutorial está escrito y la instalación realizada usando el siguiente entorno:
  • Hardware: Portátil MacBook Pro 15′ (2.3 GHz Intel Core i7, 16GB DDR3).
  • Sistema Operativo: Mac OS Mavericks 10.9.4
  • Apache Tomcat 7.0.54.
  • psi-probe 2.2.3.

3. Instalación en Apache Tomcat.

Tras descargar el paquete de instalación lo único que tenemos que hacer es “tirar el war” probe.war en el directorio de despliegue de Apache Tomcat y, en función de si tenemos configurado el despliegue automático o no, configurar la aplicación web como tal, por defecto, no habría que hacer nada más que revisar la política de autenticación y autorización de tomcat definida en el fichero tomcat-users.xml del directorio conf.
Se pueden definir 4 niveles de autorización, asumiendo que manager es la más alta, con lo que si ya tenías definido un usuario con ese rol para el Tomcat Manager, no necesitas tocar nada.
Por último, si quieres acceder a toda la información de la JVM desde probe debes habilitar el acceso en remoto a la consola de JVM.

4. Monitorización.

Una vez levantado el servidor y a través de la url que da acceso al contexto de la aplicación http://localhost:8080/probe podremos acceder con el usuario y contraseña configurados en Tomcat a la aplicación de monitorización.

4.1. Aplicaciones.

La primera interfaz que se muestra es la de las aplicaciones instaladas en la que se puede comprobar que aparece el propio probe.
Pulsando sobre una aplicación podemos acceder a un breve detalle de toda la información que se recolecta sobre la misma:
Pulsando sobre la sección correspondiente podemos analizar información sobre las sesiones activas:
se pueden eliminar las sesiones, estimar el tamaño que ocupan y pulsando sobre la misma podemos ver todos los objetos que se mantienen en la sesión del usuario en el servidor; pudiendo incluso realizar un segundo nicel de estimación del tamaño que ocupan dichos objetos en la memoria del servidor.
Existen más opciones en el menú izquierdo, entre ellas la de visualizar el contenido del descriptor de despliegue:
los servlets configurados
y los parámetros de inicialización y de contexto de los servlets.

4.2. Fuentes de datos.

En la opción de datasources podemos ver la configuración de los mismos:
y pulsando sobre uno de ellos, se pueden realizar consultas SQL a través del mismo.
Entre las fuentes de datos y los logs podemos acceder a una opción de despliegue en caliente de aplicaciones.

4.3. Logs.

En la opción de logs podemos acceder a un listado de los ficheros que trazamos
y pulsando sobre uno de ellos al tailing del fichero:
lo interesante de la opción anterior es la posibilidad, resaltada en rojo en la imagen, de modificar en caliente el nivel de trazabilidad del appender en cuestión.

4.4. Threads.

Desde la opción de hilos se puede acceder tanto a los que están en curso para incluso matarlos como a la configuración del pool de hilos.

4.5. Información del sistema.

En la opción para acceder a la información del sistema se puede echar un vistazo general
ver en detalle el uso de memoria de la JVM e invocar al garbage collector:
y analizar la información en relación a la memoria disponible en el sistema.

4.6. Conectores.

En la pestaña de conectores podemos acceder a la monitorización de las peticiones que se realizar a través de los distintos conectores, disponiendo de informción gráfica sobre número de peticiones, tiempo de proceso y volumen del tráfico de estas conexiones.

4.7. Quick check.

La última de las opciones es un chequeo rápido de la salud del servidor teniendo en cuenta el uso de las fuentes de datos, la memoria, el número de descriptores de fichero disponibles y si las aplicaciones están levantadas o no.

5. Referencias.


6. Conclusiones.

Si consigues colarlo en producción, disfrútalo!!! 😉
Si no, en cualquier entorno, incluso en el de desarrollo te puede servir como soporte de una monitorización del sistema durante pruebas de carga o estrés.
Un saludo.