Para instalar 'VMware Workstation Player':
1) Nos descargamos 'VMware Workstation Player' en el enlace: http://www.vmware.com/go/tryplayerpro-linux-64 ofrecido en la página: http://www.vmware.com/products/player/playerpro-evaluation.html y lo
2) Lo instalamos ejecutando:
sudo ./VMware-Player-12.5.1-4542065.x86_64.bundle
Para desinstalar 'VMware Workstation Player':
1) Ejecutamos:
sudo vmware-installer -u vmware-player
Esto nos levantará un asistente de desinstalación que deberemos seguir.
miércoles, 30 de noviembre de 2016
Monitorización y afinamiento del rendimiento de aplicaciones en Tomcat con JVisualVM
Para monitorizar el estado de un servidor Tomcat podemos utilizar dos herramientas que vienen incluídas en el JDK. JConsole y la mas moderna JVisualVM. Esta segunda agrupa las funcionalidades de varias herramientas habituales: jstat, jconsole, jstack, jmap e jinfo, acercándose mucho a la utilidad de una herramienta comercial de perfilado.
Vamos a centrarnos en comentar JConsole y JVisualVM.
Lo mas correcto a la hora de utilizar cualquiera de las dos herramientas es conectar con el servidor mediante JMX (Java Management Extensions) que es una especificación que define un mecanismo para ajustar aplicaciones y servicios en caliente. La monitorización mediante JMX es la menos intrusiva, se estima que ronda el 5% de sobrecarga.
Para monitorizar nuestro servidor mediante JMX tendremos que realizar los siguientes ajustes:
1) Paramos nuestro servidor Tomcat:
$ /{tomcat-folder}/bin/shutdown.sh
2) Creamos (si no existe ya) el fichero /{tomcat-folder}/bin/setenv.sh con el siguiente contenido:
export JAVA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"
3) Rearrancamos nuestro servidor Tomcat:
$ /{tomcat-folder}/bin/shutdown.sh
A la hora de monitorizar el servidor tomcat desde nuestro PC podremos levantar JConsole o JVisualVM, ambas herramientas están disponibles en el JDK:
1) Levantamos cualquiera de las herramientas
$ /{jdk-folder}/bin/jconsole
$ /{jdk-folder}/bin/jvisualvm
2) Definimos la conexión remota JMX, para lo que necesitaremos conocer la IP y el puerto del servidor, sería siempre algo así "127.0.0.1:9999".
Con esto ya deberíamos poder monitorizar nuestra JVM en producción o en pruebas de carga (lanzadas por ejemplo con JMeter) en preexplotación y observando la evolución de:
Memoria Heap
Memoria PermGen
Threads
Garbage Collector
CPU utilizada
Clases cargadas en memoria
MBeans
etc
Aunque para una monitorización básica de la JVM ambas herramientas son válidas, JVisualVM es mucho mas potente, dado que ofrece muchas de las características de herramientas comerciales de "profiling" (que se puede traducir como "perfilado", "afinamiento" o "puesta a punto") como JProfiler y YourKitdado. Con JVisualVM podremos "afinar" el rendimiento de nuestra aplicación:
Nota. JVisualVM se puede ampliar con muchos plugins, se puede integrar con Eclipse, es gratuíta, ...
Vamos a centrarnos en comentar JConsole y JVisualVM.
Lo mas correcto a la hora de utilizar cualquiera de las dos herramientas es conectar con el servidor mediante JMX (Java Management Extensions) que es una especificación que define un mecanismo para ajustar aplicaciones y servicios en caliente. La monitorización mediante JMX es la menos intrusiva, se estima que ronda el 5% de sobrecarga.
Para monitorizar nuestro servidor mediante JMX tendremos que realizar los siguientes ajustes:
1) Paramos nuestro servidor Tomcat:
$ /{tomcat-folder}/bin/shutdown.sh
2) Creamos (si no existe ya) el fichero /{tomcat-folder}/bin/setenv.sh con el siguiente contenido:
export JAVA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"
3) Rearrancamos nuestro servidor Tomcat:
$ /{tomcat-folder}/bin/shutdown.sh
A la hora de monitorizar el servidor tomcat desde nuestro PC podremos levantar JConsole o JVisualVM, ambas herramientas están disponibles en el JDK:
1) Levantamos cualquiera de las herramientas
$ /{jdk-folder}/bin/jconsole
$ /{jdk-folder}/bin/jvisualvm
2) Definimos la conexión remota JMX, para lo que necesitaremos conocer la IP y el puerto del servidor, sería siempre algo así "127.0.0.1:9999".
- JConsole. Connection / New Connection / Remote Process / <hostname>:<port>
- JVisualVM. File /Add JMX Connection / <hostname>:<port>
Con esto ya deberíamos poder monitorizar nuestra JVM en producción o en pruebas de carga (lanzadas por ejemplo con JMeter) en preexplotación y observando la evolución de:
Memoria Heap
Memoria PermGen
Threads
Garbage Collector
CPU utilizada
Clases cargadas en memoria
MBeans
etc
Aunque para una monitorización básica de la JVM ambas herramientas son válidas, JVisualVM es mucho mas potente, dado que ofrece muchas de las características de herramientas comerciales de "profiling" (que se puede traducir como "perfilado", "afinamiento" o "puesta a punto") como JProfiler y YourKitdado. Con JVisualVM podremos "afinar" el rendimiento de nuestra aplicación:
- Monitorizando el tiempo de CPU consumido por nuestras clases/paquetes durante una tanda de pruebas, detectando cuellos de botella o problemas de programación que impliquen tiempos de respuesta muy elevados.
- Monitorizando la Memoria utilizada por nuestra aplicación, detectando que objetos aparecen con un frecuencia inesperada (posibles memory leaks), cual es el consumo de memoria de dichos objetos (posibles pool), etc.
Nota. JVisualVM se puede ampliar con muchos plugins, se puede integrar con Eclipse, es gratuíta, ...
miércoles, 16 de noviembre de 2016
Herramienta de cifrado RSA para Windows
Hola
Buscando en Internet una herramienta que permitiese a usuáriosde Windows enviarse ficheros cifrados con RSA me he topado con Kleopatra (https://www.gpg4win.org/download.html), así que lo he instalado y probado en una virtualización con Windows 7 y he verificado que funciona sin problemas y no es dificil de manejar.
Esta sería la secuencia de pasos básicos que deberán llevar a cabo dos personas que necesiten intercambiar ficheros cifrados con RSA:
1) Tareas previas del receptor.
1.1) Instalar Kleopatra lanzando el instalador 'gpg4win-2.3.3.exe' de Kleopatra. Durante la instalación pregunta qué componentes instalar, dejamos marcadas las opciones por defecto.
1.1) El receptor deberá sacar la clave pública del certificado a distribuir con su cadena de confianza, desde un navegador donde tengamos instalado el certificado a utilizar se hace fácilmente: Administrador de certificados/Sus certificados/Ver/Detalles/Exportar/Certifiacdo X.509 con cadena (PEM)
1.2) El receptor deberá hacer llegar al emisor dicha clave pública. Se generará un fichero xxxxxxxxxxx.cer
1.3) Arrancamos Kleopatra
1.4) El receptor deberá tener su certificado completo (clave pública+clave privada) de su certificado en Kleopatra. Para obtener dicho certificado lo mas sencillo es sacarlo del navegador donde lo tengamos instalado: Administrador de certificados/Sus certificados/Hacer copia, nos pedirá una password y generará un fichero xxxxxxxxxxxxxx.p12
1.5) Importamos el certificado completo del receptor (xxxxxxxxxxxxxx.p12) en Kleopatra, pulsamos el botón 'Import certificates' y seleccionamos el fichero xxxxxxxxxxx.p12 obtenido del navegador. Nos pedirá la password del almacen P12 y que definamos una password interna para el almacen interno de Kleopatra
2) Tareas del emisor de documentos cifrados
2.1) Instalar Kleopatra lanzando el instalador 'gpg4win-2.3.3.exe' de Kleopatra.
2.2) Importar la clave pública del certificado del receptor: pulsan el botón 'Import certificates' y seleccionan el fichero xxxxxxxxxxx.cer recibido desde el receptor
2.3) Ajustar la config de Kleopatra marcando el check 'Never consult CRL' de: Settings/Configure Kleopatra/S/MIME Validation/
2.4) Para cifrar un fichero lo localizamos con el Explorador de Archivos y tras pulsar sobre el mismo con el botón derecho del ratón seleccionaremos la opción 'Mas opciones de GpgEX/Cifrar', pulsaremos Next, seleccionamos la clave pública del INE con la que deseamos cifrar (xxxxxxxxxxx.cer), pulsamos el botón Add y el botón Encrypt.
2.5) Enviamos al receptor el fichero generado
3) Tareas en el receptor por cada documento cifrado
3.1) Recibimos un fichero cifrado con nuestra clave pública por parte de cierto organismo por lo que a priori solo nosotros podemos ver su contenido. Ojo como no está firmado cualquiera podría haber generado ese fichero.
3.2) Pulsamos con el botón derecho del ratón sobre el fichero, seleccionamos 'Mas opcioens de GpgEX/Descifrar' nos pedirá la password interna de la herramienta (definida al introducir el certificado completo del receptor en Kleopatra) y sobreescribirá el fichero cifrado con el fichero en claro.
Notas. He probado con ficheros desde 1KB, 2KB, 4KB,... hasta 1MB y el tiempo es inapreciable, luego he probado con un fichero de 17MB y ha taraddo un par de segundos, por último he probado con un fichero de 54MB y ha tardado 7 segundos en cifrarlo. Las operaciones de descifrado vienen a ser igual de rápidas.
Un saludo
Buscando en Internet una herramienta que permitiese a usuáriosde Windows enviarse ficheros cifrados con RSA me he topado con Kleopatra (https://www.gpg4win.org/download.html), así que lo he instalado y probado en una virtualización con Windows 7 y he verificado que funciona sin problemas y no es dificil de manejar.
Esta sería la secuencia de pasos básicos que deberán llevar a cabo dos personas que necesiten intercambiar ficheros cifrados con RSA:
1) Tareas previas del receptor.
1.1) Instalar Kleopatra lanzando el instalador 'gpg4win-2.3.3.exe' de Kleopatra. Durante la instalación pregunta qué componentes instalar, dejamos marcadas las opciones por defecto.
1.1) El receptor deberá sacar la clave pública del certificado a distribuir con su cadena de confianza, desde un navegador donde tengamos instalado el certificado a utilizar se hace fácilmente: Administrador de certificados/Sus certificados/Ver/Detalles/Exportar/Certifiacdo X.509 con cadena (PEM)
1.2) El receptor deberá hacer llegar al emisor dicha clave pública. Se generará un fichero xxxxxxxxxxx.cer
1.3) Arrancamos Kleopatra
1.4) El receptor deberá tener su certificado completo (clave pública+clave privada) de su certificado en Kleopatra. Para obtener dicho certificado lo mas sencillo es sacarlo del navegador donde lo tengamos instalado: Administrador de certificados/Sus certificados/Hacer copia, nos pedirá una password y generará un fichero xxxxxxxxxxxxxx.p12
1.5) Importamos el certificado completo del receptor (xxxxxxxxxxxxxx.p12) en Kleopatra, pulsamos el botón 'Import certificates' y seleccionamos el fichero xxxxxxxxxxx.p12 obtenido del navegador. Nos pedirá la password del almacen P12 y que definamos una password interna para el almacen interno de Kleopatra
2) Tareas del emisor de documentos cifrados
2.1) Instalar Kleopatra lanzando el instalador 'gpg4win-2.3.3.exe' de Kleopatra.
2.2) Importar la clave pública del certificado del receptor: pulsan el botón 'Import certificates' y seleccionan el fichero xxxxxxxxxxx.cer recibido desde el receptor
2.3) Ajustar la config de Kleopatra marcando el check 'Never consult CRL' de: Settings/Configure Kleopatra/S/MIME Validation/
2.4) Para cifrar un fichero lo localizamos con el Explorador de Archivos y tras pulsar sobre el mismo con el botón derecho del ratón seleccionaremos la opción 'Mas opciones de GpgEX/Cifrar', pulsaremos Next, seleccionamos la clave pública del INE con la que deseamos cifrar (xxxxxxxxxxx.cer), pulsamos el botón Add y el botón Encrypt.
2.5) Enviamos al receptor el fichero generado
3) Tareas en el receptor por cada documento cifrado
3.1) Recibimos un fichero cifrado con nuestra clave pública por parte de cierto organismo por lo que a priori solo nosotros podemos ver su contenido. Ojo como no está firmado cualquiera podría haber generado ese fichero.
3.2) Pulsamos con el botón derecho del ratón sobre el fichero, seleccionamos 'Mas opcioens de GpgEX/Descifrar' nos pedirá la password interna de la herramienta (definida al introducir el certificado completo del receptor en Kleopatra) y sobreescribirá el fichero cifrado con el fichero en claro.
Notas. He probado con ficheros desde 1KB, 2KB, 4KB,... hasta 1MB y el tiempo es inapreciable, luego he probado con un fichero de 17MB y ha taraddo un par de segundos, por último he probado con un fichero de 54MB y ha tardado 7 segundos en cifrarlo. Las operaciones de descifrado vienen a ser igual de rápidas.
Un saludo
jueves, 10 de noviembre de 2016
Problemas en Apache '/opt/apache/bin/httpd -k start'
Hola
He revisando cierto servidor Apache de desarrollo donde apache no respondía ni por el puerto 80 ni por el puerto 443 (timeout siempre), verifiqué que el Apache estaba aparentemente levantado mirando si había un proceso escuchando el 80 y el 443:
[usuarioxxxxxx@desa11 logs]$ sudo netstat -tulpn
tcp 0 0 :::443 :::* LISTEN 1662/httpd
tcp 0 0 :::80 :::* LISTEN 1662/httpd
Como sí que lo había, intenté pararlo/arrancarlo del modo habitual obteniendo un error relativo a que los puertos estaban siendo utilizados:
[usuarioxxxxxx@desa11 logs]$ sudo /etc/init.d/apache stop
[usuarioxxxxxx@desa11 logs]$ sudo /etc/init.d/apache start
Saqué toda la info posible del proceso 1662:
[usuarioxxxxxx@desa11 logs]$ ps -Af | grep 1662
root 1662 1660 0 09:54 ? 00:00:00 /opt/apache/bin/httpd -k start
Y me quedé rallado con '/opt/apache/bin/httpd -k start', de donde salía ese '-k' que nunca había observado.
Maté el proceso sin mas:
[usuarioxxxxxx@desa11 logs]$ sudo kill 1662
Volví a levantar el apache del modo habitual:
[usuarioxxxxxx@desa11 logs]$ sudo /etc/init.d/apache start
Apache/2.2.23 mod_ssl/2.2.23 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide the pass phrases.
Server www.example.com:443 (RSA)
Enter pass phrase:
OK: Pass Phrase Dialog successful.
Tras el rearranque anterior del Apache de ya funcionaba todo sin problemas, pero revisando de nuevo los puertos de nuevo SORPRESA!!!:
[usuarioxxxxxx@desa11 ~]$ sudo netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 :::443 :::* LISTEN 2417/httpd
tcp 0 0 :::80 :::* LISTEN 2417/httpd
[usuarioxxxxxx@desa11 ~]$ ps -Af | grep 2417
root 2417 1 0 10:33 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2419 2417 0 10:33 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2420 2417 0 10:33 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2421 2417 0 10:33 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2422 2417 0 10:33 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2423 2417 0 10:33 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2500 2417 0 10:48 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2501 2417 0 10:48 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2502 2417 0 10:48 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2503 2417 0 10:48 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2529 2417 0 10:52 ? 00:00:00 /opt/apache/bin/httpd -k start
Resulta que tenemos 'N threads' de Apache corriendo. Tiene pinta de que el proceso padre PID=2417 hace un fork de sí mismo por cada peticion recibida, creánmdose un proceso hijo (PIDs=2419...2529). Esto lo he verificado levantando un navegador y atacando uno de los portales del server.
Antes por lo que fuese, el proceso padre (1662) estaba tostado y no se dejaba parar del modo habitual, ahora el proceso padre (2417) lo paro sin problemas con:
sudo /etc/init.d/apache/start
sudo /etc/init.d/apache/stop
Como siempre usamos estos scripts no habíamos visto nunca que Apache se para/arranca/etc (a pelo) con la opción '-k':
/opt/apache/bin/httpd -k start|stop| ...
REFERENCIAS
http://httpd.apache.org/docs/current/programs/httpd.html
He revisando cierto servidor Apache de desarrollo donde apache no respondía ni por el puerto 80 ni por el puerto 443 (timeout siempre), verifiqué que el Apache estaba aparentemente levantado mirando si había un proceso escuchando el 80 y el 443:
[usuarioxxxxxx@desa11 logs]$ sudo netstat -tulpn
tcp 0 0 :::443 :::* LISTEN 1662/httpd
tcp 0 0 :::80 :::* LISTEN 1662/httpd
Como sí que lo había, intenté pararlo/arrancarlo del modo habitual obteniendo un error relativo a que los puertos estaban siendo utilizados:
[usuarioxxxxxx@desa11 logs]$ sudo /etc/init.d/apache stop
[usuarioxxxxxx@desa11 logs]$ sudo /etc/init.d/apache start
Saqué toda la info posible del proceso 1662:
[usuarioxxxxxx@desa11 logs]$ ps -Af | grep 1662
root 1662 1660 0 09:54 ? 00:00:00 /opt/apache/bin/httpd -k start
Y me quedé rallado con '/opt/apache/bin/httpd -k start', de donde salía ese '-k' que nunca había observado.
Maté el proceso sin mas:
[usuarioxxxxxx@desa11 logs]$ sudo kill 1662
Volví a levantar el apache del modo habitual:
[usuarioxxxxxx@desa11 logs]$ sudo /etc/init.d/apache start
Apache/2.2.23 mod_ssl/2.2.23 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide the pass phrases.
Server www.example.com:443 (RSA)
Enter pass phrase:
OK: Pass Phrase Dialog successful.
Tras el rearranque anterior del Apache de ya funcionaba todo sin problemas, pero revisando de nuevo los puertos de nuevo SORPRESA!!!:
[usuarioxxxxxx@desa11 ~]$ sudo netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 :::443 :::* LISTEN 2417/httpd
tcp 0 0 :::80 :::* LISTEN 2417/httpd
[usuarioxxxxxx@desa11 ~]$ ps -Af | grep 2417
root 2417 1 0 10:33 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2419 2417 0 10:33 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2420 2417 0 10:33 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2421 2417 0 10:33 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2422 2417 0 10:33 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2423 2417 0 10:33 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2500 2417 0 10:48 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2501 2417 0 10:48 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2502 2417 0 10:48 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2503 2417 0 10:48 ? 00:00:00 /opt/apache/bin/httpd -k start
apache 2529 2417 0 10:52 ? 00:00:00 /opt/apache/bin/httpd -k start
Resulta que tenemos 'N threads' de Apache corriendo. Tiene pinta de que el proceso padre PID=2417 hace un fork de sí mismo por cada peticion recibida, creánmdose un proceso hijo (PIDs=2419...2529). Esto lo he verificado levantando un navegador y atacando uno de los portales del server.
Antes por lo que fuese, el proceso padre (1662) estaba tostado y no se dejaba parar del modo habitual, ahora el proceso padre (2417) lo paro sin problemas con:
sudo /etc/init.d/apache/start
sudo /etc/init.d/apache/stop
Como siempre usamos estos scripts no habíamos visto nunca que Apache se para/arranca/etc (a pelo) con la opción '-k':
/opt/apache/bin/httpd -k start|stop| ...
REFERENCIAS
http://httpd.apache.org/docs/current/programs/httpd.html
Suscribirse a:
Entradas (Atom)