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
martes, 18 de octubre de 2016
Ionic 2. Instalación, ajuste y subida de una aplicación híbria al movil en 5 min
Introducción
En unos pocos minutos podemos tener listo nuestro entorno de desarrollo Ionic 2 (sin plataforma), montar una aplicación de ejemplo y visualizarla en nuestro dispositivo movil.Los pasos a seguir son los siguientes:
Instalación y configuración
1) Descargamos Node.js desde https://nodejs.org/es/, para Linux debemos bajar 'node-v4.6.0-linux-x64.tar.xz' y lo llevamos a nuestra carpeta $HOME2) Lo descomprimimos mediante el comando:
tar -xvf node-v4.6.0-linux-x64.tar.xz
3) Lo renombramos a algo mas intuitivo como 'node-v4.6.0'
mv node-v4.6.0-linux-x64 node-v4.6.0
4) Ajustamos el fichero $HOME/.profile añadiendo:
#programacion moviles
export NODE_HOME=/home/miusuario/node-v4.6.0
export PATH="$NODE_HOME/bin:$PATH"
5) Recargamos las variables de configuración relanzando el fichero .profile con el comando:
$ . ./.profile
Aclaración. Este ajuste vale para la terminal actual, lo que nos permite seguir trabajando, si
queremos que el cambio sea permanente lo mejor es reiniciar sesión.
6) Verificamos que se ha instalado correctamente y que las variables de entorno están bien definidas con:
$ node -v
$ npm -v
7) Ajustamos la configuración de NPM para que use el proxy del INE mediante el comando:
$ npm config set proxy "http://usuario:password@ip-server-proxy:puerto-proxy/"
8) Verificamos que la configuración de NPM ha quedado bien ajustada con el comando:
npm config list
9) Instalamos Apache Cordova
$ npm install -g cordova
10) Verificamos que la instalación haya sido correcta:
$ cordova -v
11) Instalamos Ionic
$ npm install -g ionic
12) Verificamos que la instalación haya sido correcta:
$ ionic -v
Aclaración. Si se desea una versión expecifica de los mismos se pude poner por ejemplo:
$ npm install -g cordova@5.0.0
$ npm install -g ionic@1.5.0
13) Instalación de Git. Software de control de versiones
$ sudo apt-get install git
$ git --version
14) Instalación de Bower. Administrador de los paquetes (dependencias) de nuestro proyecto.
$ npm install -g bower
$ bower -v
15) Instalación de Gulp. Herramienta que permite automatizar tareas comunes de desarrollo.
$ npm install -g gulp
$ gulp -v
Creación de un aplicativo y visualización en el dispositivo
El entorno ya estaría listo, ahora vamos a generar una app de ejemplo y subirla a nuestro movil, para ello deberemos crear una cuenta en https://apps.ionic.io/login (con una dirección de correo y una contraseña que usaremos mas tarde).1) Ionic nos ofrece toda una serie de plantillas para generar el esqueleto inicial de nuestros proyectos, podemos conocer la lista completa mediante el comando:
$ ionic start --list
2) Nos colocamos en la carpeta $HOME y creamos el proyecto 'ejemplo1' usando la plantilla tabs
$ cd $HOME
$ ionic start -a "ejemplo1" -i es.ine.sgtic.ejemplo1 ejemplo1 tabs --v2
-a ejemplo1 -> Nombre del proyecto (aplicación)
-i es.casa.ejemplo1 -> Nombre del dominio/id de la aplicación
ejemplo1 -> Nombre del directorio donde generará el proyecto
blank -> Nombre de la plantilla que hemos usado
--v2 -> Parámetro con el que indicamos que queremos usar Ionic 2 (lo que implica: Angular 2, Typescript, etc).
Aclaración. Ionic 2 se basa en Angular 2, el cual trabaja por defecto con Typescript (aunque podría hacerlo con Javascript clásico ES5). Los Proyectos con Ionic 2 tienen una estructura interna completamente diferente. Con Angular 1 la estructura sería:
|-www/
|
|--js/
|--|-app.js
|--|-HomeCtrl.js
|--|-DetailCtrl.js
|
|--templates/
|--|-Home.html
|--|-Detail.html
|
|-index.html
Mientras con Angular 2 la estructura es:
|-www/
|
|--Home/
|--|-HomeCtrl.js
|--|-Home.html
|
|--Detail/
|--|-DetailCtrl.js
|--|-Detail.html
|
|-index.html
|-app.js
3) Subimos el app a nuestro movil (donde habremos instalado el app Ionic View):
$ cd ejemplo1
$ ionic upload (Nos pedirá la cuenta de correo y la password de nuestra cuenta en Ionic)
4) Con ésto ya tendríamos la aplicación disponible en Ionic View para verla funcionar en el dispositivo movil. Arrancaríamos Ionic View en el movil y en el área 'My apps' podremos ver la aplicación 'ejemplo1' que podremos descargar y ejecutar ejecutar pulsando 'View app'.
Trabajo en local
Ya hemos visto como generar y subir al dispositivo una aplicación de ejemplo, ahora vamos a ver cómo probarla/modificarla en el entorno de desarrollo para posteriormente volver a subirla:1) Nos movemos a la carpeta $HOME/ejemplo1
$ cd $HOME/ejemplo1
2) Levantamos el servidor embebido en Ionic con:
$ ionic serve --address localhost --port 8100
Aclaración. El comando podría no tener parámetros. Habitualmente funciona sin problemas con 'ionic serve', pero con las opciones indicadas podemos configurar tanto la dirección IP como el puerto por el que se despacharán peticiones. Estos ajustes son esenciales en máquinas con varias IP y/o otros servidores (Apache, Tomcat, etc) levantados.
3) Probamos la app en local en la URL: http://localhost:8100
Se nos abrirá el navegador con la siguiente URL: http://localhost:8100/
4) Podemos acceder a cualquiera de las páginas del aplicativo para ajustar tanto la página en sí (fichero *.html) como el controlador (fichero *.ts), tras efectuar el cambio simplemente refrescamos la página en nuestro navegador.
5) Al depurar con Chrome hemos visto que no podemos acceder a los scripts en la pestañan Sources, dado que no se ve la carpeta /top/localhost:8100/src/app/, para apañar este bug hemos tenido que lanzar el comando:
$ npm install @ionic/app-scripts@latest
Referencias:
http://ionicframework.com/docs/v2/
Recarga del .profile (bash) en Linux
En casi todas las distribuciones de Linux actuales tenemos Bash como intérprete de comandos.
El intérprete de comandos se cargará cuando iniciamos una sesión, por ello es importante conocer donde y cómo ajustar las variables de entorno de forma correcta.
Bash puede configurarse en varios ficheros, que sabemos que será ejecutados al iniciar la sesión en el siguiente orden (si es que existen):
/etc/profile
$HOME/.bash_profile
$HOME/.bash_login
$HOME/.profile
Si necesitamos ajustar varibles de entorno únicamente para las sesiones de nuestro usuario, típicamente $PATH, $JAVA_HOME, $M2_HOME, etc, lo mejor es ajustar el fichero .profile que encontraremos en $HOME.
Una vez ajustadas las variables tendríamos que reiniciar la sesión para que dichos ajustes sean recargados, pero hay una forma más rápida de recarga, consistente en ejecutar el comando:
$ . ./.profile
Tras ésto podríamos ver que los cambios en nuestra variable XXX ya están cargados lanzando el comando
$ echo $XXX
Un saludo
El intérprete de comandos se cargará cuando iniciamos una sesión, por ello es importante conocer donde y cómo ajustar las variables de entorno de forma correcta.
Bash puede configurarse en varios ficheros, que sabemos que será ejecutados al iniciar la sesión en el siguiente orden (si es que existen):
/etc/profile
$HOME/.bash_profile
$HOME/.bash_login
$HOME/.profile
Si necesitamos ajustar varibles de entorno únicamente para las sesiones de nuestro usuario, típicamente $PATH, $JAVA_HOME, $M2_HOME, etc, lo mejor es ajustar el fichero .profile que encontraremos en $HOME.
Una vez ajustadas las variables tendríamos que reiniciar la sesión para que dichos ajustes sean recargados, pero hay una forma más rápida de recarga, consistente en ejecutar el comando:
$ . ./.profile
Tras ésto podríamos ver que los cambios en nuestra variable XXX ya están cargados lanzando el comando
$ echo $XXX
Un saludo
lunes, 17 de octubre de 2016
Instalación y configuración GetSimple CMS
Los pasos a dar para la intalación del gestor de contenido getsimplecms son:
1) Instalar los siguientes paquetes:
sudo apt-get install apache2
sudo apt-get install php
sudo apt-get install libapache2-mod-php
sudo apt-get install php-xml
sudo apt-get install sendmail
2) Descargamos getsimplecms de la página: http://get-simple.info/
3) Descargamos el soporte español de la página: http://get-simple.info/extend/all_languages.php
4) Descomprimimos 'GetSimpleCMS-3.3.12.zip' en /var/www/html/ el contenido del zip en esta carpeta, deben por tanto quedar aquí las carpetas admin, backup, data, ...
5) Descomprimimos 'spanish-language-for-getsimple.zip' en /var/www/html/admin/lang el contenido del zip en esta carpeta, deben por tanto quedar aquí los ficheros en_US.php y es_ES.php
6) Ajustamos los permisos de acceso a /var/www por parte de apache/php
sudo chmod -R 777 /var/www
7) Ajustamos la visibilidad del apache en el fichero /etc/apache2/apache2.conf
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
Allow from all
</Directory>
8) Ajustamos el tamaño máximo de los ficheros a subir editando /etc/php/7.0/apache2/php.ini
upload_max_filesiza=10M
8) Paramos el apache y lo arrancamos:
/etc/init.d/apache2 stop
/etc/init.d/apache2 start
9) Accedemos a http://localhost/admin y seguimos el asistente:
- Ajustamos el idioma al Español
- Ajustamos la cuenta del administrador: admin/password
10) Acceso usuarios: http://localhost
11) Acceso administradores: http://localhost/admin
1) Instalar los siguientes paquetes:
sudo apt-get install apache2
sudo apt-get install php
sudo apt-get install libapache2-mod-php
sudo apt-get install php-xml
sudo apt-get install sendmail
2) Descargamos getsimplecms de la página: http://get-simple.info/
3) Descargamos el soporte español de la página: http://get-simple.info/extend/all_languages.php
4) Descomprimimos 'GetSimpleCMS-3.3.12.zip' en /var/www/html/ el contenido del zip en esta carpeta, deben por tanto quedar aquí las carpetas admin, backup, data, ...
5) Descomprimimos 'spanish-language-for-getsimple.zip' en /var/www/html/admin/lang el contenido del zip en esta carpeta, deben por tanto quedar aquí los ficheros en_US.php y es_ES.php
6) Ajustamos los permisos de acceso a /var/www por parte de apache/php
sudo chmod -R 777 /var/www
7) Ajustamos la visibilidad del apache en el fichero /etc/apache2/apache2.conf
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
Allow from all
</Directory>
8) Ajustamos el tamaño máximo de los ficheros a subir editando /etc/php/7.0/apache2/php.ini
upload_max_filesiza=10M
8) Paramos el apache y lo arrancamos:
/etc/init.d/apache2 stop
/etc/init.d/apache2 start
9) Accedemos a http://localhost/admin y seguimos el asistente:
- Ajustamos el idioma al Español
- Ajustamos la cuenta del administrador: admin/password
10) Acceso usuarios: http://localhost
11) Acceso administradores: http://localhost/admin
Suscribirse a:
Entradas (Atom)