Aunque ya no es necesario utilizar un servidor de aplicaciones como glassfish en nuestras aplicaciones, áun tenemos algunas que se ejecutan en uno.

Ahora me tocó instalar un servidor de aplicaciones desde cero. Entonces lo primero que hice fue instalar Ubuntu Server.
Una vez instalado, descargué Glassfish (Web Profile) con el comando:

wget http://download.java.net/glassfish/4.1/release/glassfish-4.1-web.zip -O ~/glassfish-4.1-web.zip

Para descomprimir el archivo, necesitamos primero instalar la herramienta unzip mediante el comando:

sudo apt-get install unzip

Para ejecutar el servidor vamos a necesitar, también, instalar java

sudo apt-get install openjdk-7-jdk

una vez instalados, hay que extraer los archivos de glassfish en alguna carpeta (yo elegí /opt)

cd /opt/
unzip ~/glassfish-4.1-web.zip

vamos a cambiar el propietario y el grupo de la carpeta por el nuestro

sudo chown usuario:grupo -R /opt/glassfish4

vamos a agregar temporalmente la carpeta de glassfish a nuestro PATH (también puedes hacerlo permanente) con el siguiente comando

export PATH=/opt/glassfish4/bin:$PATH

y vamos a iniciar el servidor de la siguiente manera

asadmin start-domain

si todo va bien, veremos el mensaje

Successfully started the domain : domain1
domain  Location: /opt/glassfish4/glassfish/domains/domain1
Log File: /opt/glassfish4/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.

Ahora hay que abrir en un navegador la ip del servidor en el puerto 4848. Dado que Ubuntu Server no tiene instalado por defecto una interfaz gráfica, tenemos que hacerlo desde otra computadora.
Por default Ubuntu server bloquea todos los puertos. Entonces tenemos que abrir el puerto 4848 para poder acceder a la consola de glassfish.

sudo ufw enable
sudo ufw allow 4848

Nota: Si tenías instalado el servidor ssh tienes que abrir nuevamente el puerto mediante el comando sudo ufw allow 22. Si no, puedes instalarlo con el comando

sudo apt-get install openssh-server

Al ingresar a la url, por ejemplo http://glassfish-server:4848 o http://192.168.0.15:4848

nos va a mostrar un error que dice que debemos activar la administración segura para poder acceder a la consola de forma remota

Configuration Error
Secure Admin must be enabled to access the DAS remotely.

para activar esto debemos primero asignar una contraseña para el usuario admin

asadmin change-admin-password
asadmin restart-domain

y luego ejecutar

asadmin enable-secure-admin
asadmin restart-domain

Si sólo ejecutas el comando enable-secure-admin te mostrará el siguiente error

remote failure: At least one admin user has an empty password, which secure admin does not permit. Use the change-admin-password command or the admin console to create non-empty passwords for admin accounts.
Command enable-secure-admin failed.

Listo, ya podemos entrar a la consola y, por ejemplo, hacer el deploy de nuestra aplicación.

Fuentes:
https://glassfish.java.net/documentation.html
https://charleech.wordpress.com/2012/03/23/glassfish-version-3-1-2-secure-admin-must-be-enabled-to-access-the-das-remotely/
https://help.ubuntu.com/community/EnvironmentVariables

I have a Java application configured with Maven. I have all my model and web services in this application (backend). In a Java app normally you would have your web client code in src/main/webapp (frontend). I scaffold-ed the client application with yeoman, so it uses grunt to build and bower to manage dependencies. Great! well, not so much, it runs perfectly in my local environment (I can run bower install, then grunt build and it would generate a “dist” folder with all my sources compiled and minified) but it doesn’t work on heroku’s platform.

The problem is heroku detects my app only as Java application so it doesn’t run bower install nor grunt build.

I tried to use heroku-buildpack-multi with some issues, I even created my own patched version that allows to specify a base path for each buildpack. With that I can push to heroku and it runs mvn package and then npm install for the node buildpack. I’ve added a postinstall script to run both bower install and grunt build, which in turn you need to add as dependencies in your package.json.

{
  "name": "webapp",
  "version": "0.0.0",
  "dependencies": {
    "grunt": "^0.4.1",
    "grunt-cli": "~0.1.13",
    "bower": "~1.3.9",
    "grunt-autoprefixer": "^0.7.3",
    "grunt-concurrent": "^0.5.0",
    "grunt-contrib-clean": "^0.5.0",
    "grunt-contrib-compass": "^0.7.2",
    "grunt-contrib-concat": "^0.4.0",
    "grunt-contrib-connect": "^0.7.1",
    "grunt-contrib-copy": "^0.5.0",
    "grunt-contrib-cssmin": "^0.9.0",
    "grunt-contrib-htmlmin": "^0.3.0",
    "grunt-contrib-imagemin": "^0.7.0",
    "grunt-contrib-jshint": "^0.10.0",
    "grunt-contrib-uglify": "^0.4.0",
    "grunt-contrib-watch": "^0.6.1",
    "grunt-filerev": "^0.2.1",
    "grunt-google-cdn": "^0.4.0",
    "grunt-karma": "^0.8.3",
    "grunt-newer": "^0.7.0",
    "grunt-ngmin": "^0.0.3",
    "grunt-svgmin": "^0.4.0",
    "grunt-usemin": "^2.1.1",
    "grunt-wiredep": "^1.7.0",
    "jshint-stylish": "^0.2.0",
    "karma": "^0.12.17",
    "karma-jasmine": "^0.1.5",
    "karma-phantomjs-launcher": "^0.1.4",
    "load-grunt-tasks": "^0.4.0",
    "time-grunt": "^0.3.1"
  },
  "engines": {
    "node": ">=0.10.0"
  },
  "scripts": {
    "test": "grunt test",
    "postinstall": "./node_modules/bower/bin/bower install && ./node_modules/grunt-cli/bin/grunt build"
  }
}

It effectively run bower install and then grunt build, but it failed because my scaffold-ed client uses compass which in turn requires ruby, arrrgh! This is where I stopped looking into this path, I’ve decided to build on my local computer and include the “dist” folder on source control (against all my principles), as suggested by various websites, for now.

Sources:
https://github.com/ddollar/heroku-buildpack-multi
https://discussion.heroku.com/t/grunt-task-after-deployment/253

jboss logo

El servidor de apliaciones JBoss tiene un modo sencillo para ejecutar tus aplicaciones, standalone. Para implementar/instalar tu aplicación simplemente copia la carpeta o archivo war al directorio “jboss-home/standalone/deployments” y ejecuta el servidor mediante

cd {JBOSS_HOME}
./bin/standalone.sh

para detener el servidor solo necesitas presionar CTRL+C.

Pero que pasa si necesitas que se siga ejecutando en el fondo, podemos utilizar nohup, disown o screen.

En este caso para detener el servidor necesitamos ejecutar el siguiente comando

{JBOSS_HOME}/bin/jboss-cli.sh --connect command=:shutdown

y finalmente para reiniciar el servidor podríamos crear un script de la siguiente manera

#!/bin/bash
#
# detener jboss as
{JBOSS_HOME}/bin/jboss-cli.sh --connect command=:shutdown
#
# Aquí podrías establecer algunas variables de ambiente para tu aplicación, p.ej.
# export DATABASE_URL="jdbc:oracle:thin:scott/tiger@localhost:1521:oratest"
# iniciar jboss en modo standalone
{JBOSS_HOME}/bin/standalone.sh

Fuentes:
https://community.jboss.org/thread/165815

Es común tener carpetas compartidas en nuestros lugares de trabajo. Para conectarte a una carpeta compartida de Windows en Ubuntu 13.10 sólo tienes que abrir el nautilus y poner en la barra de direcciones la ip o el nombre de la computadora con el recurso compartido de la siguiente manera (también puedes seleccionar el menú Files->Connect to Server)

smb://192.168.0.2/

opcionalmente el nombre de la carpeta

smb://192.168.0.2/Compartido

Si necesitas conectarte como un usuario distinto al tuyo, basta con agregar en la url el nombre del usuario

smb://jhondoe@192.168.0.2/Compartido

si seleccionas guardar la contraseña para la conexión y después la quieres eliminar, puedes administrarla a través de la aplicación ‘passwords and keys’ (seahorse)

Después de haber instalado un servidor LAMP, para depurar aplicaciones web, con el comando

sudo apt-get install lamp-server^

creé un enlace simbólico a una carpeta de mi directorio, /home/cirovladimir/Projects/websites/agenda que representa mi proyecto.

cd /var/www
sudo ln -s /home/cirovladimir/Projects/websites/agenda
Al intentar acceder desde un navegador a la URL

http://localhost/agenda

me arrojaba un error 403 – Forbidden, y en el log de apache el mensaje “Symbolic link not allowed or link target not accessible”

después de hacer una búsqueda exhaustiva y probar diferentes configuraciones. Llegué a esta página dónde se encontraba la respuesta.
El problema es que el directorio raíz, Projects, no tenía permisos ni de lectura ni de ejecución. Lo solucioné con el comando

chmod 755 -R /home/cirovladimir/Projects

Fuentes:
google search
stackexchange

Para configurar un servidor de git local podemos seguir la guía oficial.
La guía nos muestra los pasos necesarios para acceder a un repositorio de git mediante ssh, que es la forma más común para acceder (leer y escribir) a un repositorio. Esto debido a la seguridad y eficiencia que ofrece el protocolo ssh. Puedes leer sobre los distintos protocolos (local, http[s], git, ssh) disponibles en git aquí.

Bueno, lo primero que necesitamos es tener un servidor de ssh

sudo apt-get install openssh-server

Luego tenemos que crear al usuario ‘git’. Yo especifiqué el directorio del usuario para que no me creara el directorio /home/git

sudo adduser --home /home/cirovladimir/Apps/git

nos va a pedir una contraseña y algunos datos, podemos dejar vacíos los demás campos.

Luego nos logeamos como el usuario git y creamos el directorio ‘.ssh/’

sudo su git
cd
mkdir .ssh

a continuación vamos a generar las llaves para nuestros usuarios

ssh keygen -t rsa -C 'usuario_1@gmail.com' -f usuario_1_rsa
ssh keygen -t rsa -C 'usuario_2@gmail.com' -f usuario_2_rsa

nos va a generar un par de llaves para cada usuario, una pública (extensión .pub) y una privada

Hay que agregar las llaves públicas al archivo .ssh/authorized_keys

cat usuario_1_rsa.pub >> .ssh/authorized_keys
cat usuario_2_rsa.pub >> .ssh/authorized_keys

Ahora vamos a iniciar un repositorio para nuestro proyecto

mkdir -p repos/proyecto.git
cd repos/proyecto.git
git --bare init

cerramos la sesión del usuario git

exit

si ya tenemos un repositorio local que queremos sincronizar con el servidor que acabamos de configurar, hacemos lo siguiente

cd miproyecto
git remote add origin git@localhost:repos/proyecto.git
git push origin master

en este caso el servidor es local, si lo configuras en otra máquina puedes sustituir localhost por el nombre de la máquina o su ip.

Si al ejecutar el ‘push’ te arroja un error parecido al siguiente

Error: Agent admitted failure to sign

lo puedes resolver con el comando

ssh-add /ruta/usuario1

y te va a pedir el passphrase que utilizaste cuando generaste la llave.

Fuentes:
http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server
http://git-scm.com/book/ch4-1.html
https://help.github.com/articles/generating-ssh-keys
https://help.github.com/articles/error-agent-admitted-failure-to-sign

Al hacer un debug de un servicio web, me aparecía la siguiente excepción

Error initializing server: At least one valid code-source or import-shared-library element is required for shared-library “global.libraries” embedded-oc4j/config/server.xml

Al parecer, el problema se debe a que moví el directorio donde instalé JDeveloper, y este guarda la ubicación en el archivo de configuración ~/jdevhome/system/oracle.j2ee.10.1.3.41.57/embedded-oc4j/config/server.xml

Así que tuve que sustituir todas las rutas a la nueva ubicación.

Por ejemplo, cambié

<code-source path="/opt/jdeveloper10133/j2ee/home/applib"/>

por

<code-source path="/home/cirovladimir/Apps/jdeveloper/jdeveloper10133/j2ee/home/applib"/>

Fuentes:
https://forums.oracle.com/forums/thread.jspa?threadID=592789