Arquivo da categoria: Ubuntu

How to SSH into a Ubuntu server after getting a “permission denied (publickey)” error

Updating your SSH configuration to allow password authentication

  1. Once you’ve launched the console, it will ask you for your user name and password. If you had to reset your root password and are using your root user to log in, it will prompt you to create a new password by typing it twice.
  2. Once you are logged in, you will need to update your sshd_config file by typing:
vim /etc/ssh/sshd_config

or if you are accessing it with a non-root user with sudo privileges, type:

sudo vim /etc/ssh/sshd_config

3. From there, you want to type i for INSERT (to edit your file) and find the option that says PasswordAuthentication no and update it to

PasswordAuthentication yes 

Then, type:


followed by:


to write and quit out of the file, followed by hitting enter.

Configurando o Ubuntu Linux para o Rails

Atualize o Sistema Operacional

$ sudo apt­get update 
$ sudo apt­get upgrade

Instale os seguintes pacotes

$ sudo apt­get install ­y build­essential autoconf bison libssl­dev libyaml­dev libreadline6­dev zlib1g­dev libncurses5­dev libffi­dev libgdbm­dev

Instale o Git

$ apt­get install git

Configure o Git

$ git config ­­global '<seu nome>' 
$ git config ­­global <seu email>

Confirme as configurac?o?es

$ git config ­l

Instale o CURL

$ sudo apt­get install curl

Instalando o RVM

$ gpg ­­keyserver hkp:// ­­recv­keys 409B6B1796C275462A1703113804BB82D39DC0E3 
$ curl ­sSL | bash

Carregando o RVM a primeira vez

$ source /home/vagrant/.rvm/scripts/rvm

Listando as verso?es conhecidas do Ruby

$ rvm list known

Instalando a versa?o do Ruby desejada

$ rvm install 2.3

Verifique a versa?o instalada

$ rvm list

Use uma versa?o especi?fica e a torne padra?o

$ rvm use 2.3 ­­default

Instale o Rails

$ gem install rails ­v 4.2.5

Verifique se o Rails foi instalado

$ rails ­v

Instale o NodeJS

$ sudo apt­get install nodejs

Verifique se o NodeJS foi instalado

$ nodejs ­­version

Instale o MySQL

$ sudo apt­get install mysql­client mysql­server libmysqlclient­dev

Verifique se o MySQL foi instalado acessando sua CLI

$ mysql ­u root ­p

Instale o PostgreSQL

$ sudo apt­get install postgresql postgresql­contrib libpq­dev

Crie um usua?rio para acessar o PostgreSQL

$ sudo ­u postgres createuser ­rds vagrant

Crie um banco de dados com o mesmo nome de usua?rio

$ createdb vagrant

Acesse o PostgreSQL

$ psql

Deploying a Rails App on Ubuntu 14.04 with Capistrano, Nginx, and Puma


Rails is an open source web application framework written in Ruby. It follows the Convention over Configuration philosophy by making assumptions that there is the ‘best’ way of doing things. This allows you to write less code while accomplishing more without having you go through endless config files.

Nginx is a high performance HTTP server, reverse proxy, and a load balancer known for its focus on concurrency, stability, scalability, and low memory consumption. Like Nginx, Puma is another extremely fast and concurrent web server with a very small memory footprint but built for Ruby web applications.

Capistrano is a remote server automation tool focusing mainly on Ruby web apps. It’s used to reliably deploy web apps to any number of remote machines by scripting arbitrary workflows over SSH and automate common tasks such as asset pre-compilation and restarting the Rails server.

In this tutorial we’ll install Ruby and Nginx on a DigitalOcean Ubuntu Droplet and configure Puma and Capistrano in our web app. Nginx will be used to capture client requests and pass them over to the Puma web server running Rails. We’ll use Capistrano to automate common deployment tasks, so every time we have to deploy a new version of our Rails app to the server, we can do that with a few simple commands.


To follow this tutorial, you must have the following:

  • Ubuntu 14.04 x64 Droplet
  • A non-root user named deploy with sudo privileges (Initial Server Setup with Ubuntu 14.04 explains how to set this up.)
  • Working Rails app hosted in a remote git repository that’s ready to be deployed

Optionally, for heightened security, you can disable root login via SSH and change the SSH port number as described in Initial Server Setup with Ubuntu 14.04.

Warning: After disabling root login, make sure you can SSH to your Droplet as the deploy user and use sudo for this user before closing the root SSH session you opened to make these changes.

All the commands in this tutorial should be run as the deploy user. If root access is required for the command, it will be preceded by sudo.

Step 1 — Installing Nginx

Once the VPS is secure, we can start installing packages. Update the package index files:

sudo apt-get update

Then, install Nginx:

sudo apt-get install curl git-core nginx -y

Step 2 — Installing Databases

Install the database that you’ll be using in your Rails app. Since there are lots of databases to choose from, we won’t cover them in this guide. You can see instructions for major ones here:

Also be sure to check out:

Step 3 — Installing RVM and Ruby

We won’t be installing Ruby directly. Instead, we’ll use a Ruby Version Manager. There are lots of them to choose from (rbenv, chruby, etc.), but we’ll use RVM for this tutorial. RVM allows you to easily install and manage multiple rubies on the same system and use the correct one according to your app. This makes life much easier when you have to upgrade your Rails app to use a newer ruby.

Before installing RVM, you need to import the RVM GPG Key:

gpg --keyserver hkp:// --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3

Then install RVM to manage our Rubies:

curl -sSL | bash -s stable

This command uses curl to download the RVM Installation script from The -sSL option is composed of three flags:

  • -s tells curl to download the file in ‘silent mode’
  • -S tells curl to show an error message if it fails
  • -L tells curl to follow all HTTP redirects while retrieving the installation script

Once downloaded, the script is piped to bash. The -s option passes stable as an argument to the RVM Installation script to download and install the stable release of RVM.

Note: If the second command fails with the message “GPG signature verification failed”, that means the GPG Key has changed, simply copy the command from the error output and run it to download the signatures. Then run the curl command for the RVM Installation.

We need to load the RVM script (as a function) so we can start using it. We then need to run the requirements command to automatically install required dependencies and files for RVM and Ruby to function properly:

source ~/.rvm/scripts/rvm
rvm requirements

We can now install the Ruby of our choice. We’ll be installing the latest Ruby 2.2.1 (at the time of writing) as our default Ruby:

rvm install 2.2.1
rvm use 2.2.1 –default

Step 4 — Installing Rails and Bundler

Once Ruby is set up, we can start installing Rubygems. We’ll start by installing the Rails gem that will allow your Rails application to run, and then we’ll install bundler which can read your app’s Gemfile and automatically install all required gems.

To install Rails and Bundler:

gem install rails -V –no-ri –no-rdoc
gem install bundler -V –no-ri –no-rdoc

Three flags were used:

  • -V (Verbose Output): Prints detailed information about Gem installation
  • --no-ri – (Skips Ri Documentation): Doesn’t install Ri Docs, saving space and making installation fast
  • --no-rdoc – (Skips RDocs): Doesn’t install RDocs, saving space and speeding up installation

Note: You can also install a specific version of Rails according to your requirements by using the -v flag:

gem install rails -v 5.1.2 –no-ri –no-rdoc

Step 5 — Setting up SSH Keys

Since we want to set up smooth deployments, we’ll be using SSH Keys for authorization. First shake hands with GitHub, Bitbucket, or any other Git Remote where the codebase for your Rails app is hosted:

ssh -T
ssh -T

Don’t worry if you get a Permission denied (publickey) message. Now, generate a SSH key (a Public/Private Key Pair) for your server:

ssh-keygen -t rsa

Add the newly created public key (~/.ssh/ to your repository’s deployment keys:

If all the steps were completed correctly, you should now be able to clone your git repository (over the SSH Protocol, not HTTP) without entering your password:

git clone

If you need a sample app for testing, you can fork the following test app specifically created for this tutorial: Sample Rails App on GitHub

The git clone command will create a directory with the same name as your app. For example, a directory named testapp_rails will be created.

We are cloning only to check if our deployment keys are working, we don’t need to clone or pull our repository every time we push new changes. We’ll let Capistrano handle all that for us. You can now delete this cloned directory if you want to.

Open a terminal on your local machine. If you don’t have a SSH Key for your local computer, create one for it as well. In your local terminal session:

ssh-keygen -t rsa

Add your local SSH Key to your Droplet’s Authorized Keys file (remember to replace the port number with your customized port number):

cat ~/.ssh/ | ssh -p your_port_num deploy@your_server_ip ‘cat >> ~/.ssh/authorized_keys’

Step 6 — Adding Deployment Configurations in the Rails App

On your local machine, create configuration files for Nginx and Capistrano in your Rails application. Start by adding these lines to the Gemfile in the Rails App:

group :development do
    gem 'capistrano',         require: false
    gem 'capistrano-rvm',     require: false
    gem 'capistrano-rails',   require: false
    gem 'capistrano-bundler', require: false
    gem 'capistrano3-puma',   require: false
gem 'puma'

Use bundler to install the gems you just specified in your Gemfile. Enter the following command to bundle your Rails app:


After bundling, run the following command to configure Capistrano:

cap install

This will create:

  • Capfile in the root directory of your Rails app
  • deploy.rb file in the config directory
  • deploy directory in the config directory

Replace the contents of your Capfile with the following:

# Load DSL and Setup Up Stages
require 'capistrano/setup'
require 'capistrano/deploy'

require 'capistrano/rails'
require 'capistrano/bundler'
require 'capistrano/rvm'
require 'capistrano/puma'

# Loads custom tasks from `lib/capistrano/tasks' if you have any defined.
Dir.glob('lib/capistrano/tasks/*.rake').each { |r| import r }

This Capfile loads some pre-defined tasks in to your Capistrano configuration files to make your deployments hassle-free, such as automatically:

  • Selecting the correct Ruby
  • Pre-compiling Assets
  • Cloning your Git repository to the correct location
  • Installing new dependencies when your Gemfile has changed

Replace the contents of config/deploy.rb with the following, updating fields marked in red with your app and Droplet parameters:

# Change these
server 'your_server_ip', port: your_port_num, roles: [:web, :app, :db], primary: true

set :repo_url,        ''
set :application,     'appname'
set :user,            'deploy'
set :puma_threads,    [4, 16]
set :puma_workers,    0

# Don't change these unless you know what you're doing
set :pty,             true
set :use_sudo,        false
set :stage,           :production
set :deploy_via,      :remote_cache
set :deploy_to,       "/home/#{fetch(:user)}/apps/#{fetch(:application)}"
set :puma_bind,       "unix://#{shared_path}/tmp/sockets/#{fetch(:application)}-puma.sock"
set :puma_state,      "#{shared_path}/tmp/pids/puma.state"
set :puma_pid,        "#{shared_path}/tmp/pids/"
set :puma_access_log, "#{release_path}/log/puma.error.log"
set :puma_error_log,  "#{release_path}/log/puma.access.log"
set :ssh_options,     { forward_agent: true, user: fetch(:user), keys: %w(~/.ssh/ }
set :puma_preload_app, true
set :puma_worker_timeout, nil
set :puma_init_active_record, true  # Change to false when not using ActiveRecord

## Defaults:
# set :scm,           :git
# set :branch,        :master
# set :format,        :pretty
# set :log_level,     :debug
# set :keep_releases, 5

## Linked Files & Directories (Default None):
# set :linked_files, %w{config/database.yml}
# set :linked_dirs,  %w{bin log tmp/pids tmp/cache tmp/sockets vendor/bundle public/system}

namespace :puma do
  desc 'Create Directories for Puma Pids and Socket'
  task :make_dirs do
    on roles(:app) do
      execute "mkdir #{shared_path}/tmp/sockets -p"
      execute "mkdir #{shared_path}/tmp/pids -p"

  before :start, :make_dirs

namespace :deploy do
  desc "Make sure local git is in sync with remote."
  task :check_revision do
    on roles(:app) do
      unless `git rev-parse HEAD` == `git rev-parse origin/master`
        puts "WARNING: HEAD is not the same as origin/master"
        puts "Run `git push` to sync changes."

  desc 'Initial Deploy'
  task :initial do
    on roles(:app) do
      before 'deploy:restart', 'puma:start'
      invoke 'deploy'

  desc 'Restart application'
  task :restart do
    on roles(:app), in: :sequence, wait: 5 do
      invoke 'puma:restart'

  before :starting,     :check_revision
  after  :finishing,    :compile_assets
  after  :finishing,    :cleanup
  after  :finishing,    :restart

# ps aux | grep puma    # Get puma pid
# kill -s SIGUSR2 pid   # Restart puma
# kill -s SIGTERM pid   # Stop puma

This deploy.rb file contains some sane defaults that work out-of-the-box to help you manage your app releases and automatically perform some tasks when you make a deployment:

  • Uses production as the default environment for your Rails app
  • Automatically manages multiple releases of your app
  • Uses optimized SSH options
  • Checks if your git remotes are up to date
  • Manages your app’s logs
  • Preloads the app in memory when managing Puma workers
  • Starts (or restarts) the Puma server after finishing a deployment
  • Opens a socket to the Puma server at a specific location in your release

You can change all options depending on your requirements. Now, Nginx needs to be configured. Create config/nginx.conf in your Rails project directory, and add the following to it (again, replacing with your parameters):

upstream puma {
  server unix:///home/<span class="highlight">deploy</span>/apps/<span class="highlight">appname</span>/shared/tmp/sockets/<span class="highlight">appname</span>-puma.sock;
server {
  listen 80 default_server deferred;
  # server_name;
  root /home/<span class="highlight">deploy</span>/apps/<span class="highlight">appname</span>/current/public;
  access_log /home/<span class="highlight">deploy</span>/apps/<span class="highlight">appname</span>/current/log/nginx.access.log;
  error_log /home/<span class="highlight">deploy</span>/apps/<span class="highlight">appname</span>/current/log/nginx.error.log info;
  location ^~ /assets/ {
    gzip_static on;
    expires max;
    add_header Cache-Control public;
  try_files $uri/index.html $uri @puma;
  location @puma {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://puma;
  error_page 500 502 503 504 /500.html;
  client_max_body_size 10M;
  keepalive_timeout 10;

Like the previous file, this nginx.conf contains defaults that work out-of-the-box with the configurations in your deploy.rb file. This listens for traffic on port 80 and passes on the request to your Puma socket, writes nginx logs to the ‘current’ release of your app, compresses all assets and caches them in the browser with maximum expiry, serves the HTML pages in the public folder as static files, and sets default maximum Client Body Size and Request Timeout values.

Step 7 — Deploying your Rails Application

If you are using your own Rails app, commit the changes you just made, and push them to remote from your Local Machine:

git add -A
git commit -m “Set up Puma, Nginx & Capistrano”
git push origin master

Note: If this is the first time using GitHub from this system, you might have to issue the following commands with your GitHub username and email address:

git config –global ‘Your Name’
git config –global

Again, from your local machine, make your first deployment:

cap production deploy:initial

This will push your Rails app to the Droplet, install all required gems for your app, and start the Puma web server. This may take anywhere between 5-15 minutes depending on the number of Gems your app uses. You will see debug messages as this process occurs.

If everything goes smoothly, we’re now ready to connect your Puma web server to the Nginx reverse proxy.

On the Droplet, Symlink the nginx.conf to the sites-enabled directory:

sudo rm /etc/nginx/sites-enabled/default
sudo ln -nfs “/home/deploy/apps/appname/current/config/nginx.conf” “/etc/nginx/sites-enabled/appname“

Restart the Nginx service:

sudo service nginx restart

You should now be able to point your web browser to your server IP and see your Rails app in action!

Normal Deployments

Whenever you make changes to your app and want to deploy a new release to the server, commit the changes, push to your git remote like usual, and run the deploy command:

git add -A
git commit -m “Deploy Message”
git push origin master
cap production deploy

Note: If you make changes to your config/nginx.conf file, you’ll have to reload or restart your Nginx service on the server after deploying your app:

sudo service nginx restart


Okay, so by now you would be running a Rails app on your Droplet with Puma as your Web Server as well as Nginx and Capistrano configured with basic settings. You should now take a look at other docs that can help you optimize your configurations to get the maximum out of your Rails application:

Instalando, iniciando, testando e parando o JBoss AS 6 no Linux Ubuntu 10.04

Checando os pré-requisitos para a instalação

O JBoss é uma aplicação 100% Java, que pode ser executado em qualquer sistema operacional que tenha um Java Development Kit (JDK) instalado na versão 1.5 ou superior.

Como requisitos de hardware, Peter Johnson, um dos autores do livro JBossInActionrecomenda que seja utilizado no mínimo um processador single-core (como o Pentium IV), 1 GB de RAM e 500 MB de espaço livre em disco. É claro que estes requisitos são afetados pela quantidade de usuários que irão utilizar a aplicação e o correto, em qualquer situação, é a ocorrência de testes de carga e de desempenho para avaliar se o hardware que executará o JBoss aguentará a demanda.

Devido ao melhor desempenho do JDK 1.6 em relação as versões anteriores, seu uso é recomendado. Dependendo do hardware, a versão do JDK pode ser a de 32 ou a 64 bits. Entretanto é importante estar atento as características da execução de uma versão JVM 64 bits num hardware compatível:

  • Em máquinas de 64 bits:
    • Canais duplicados de comunicação entre RAM e CPU melhoram o desempenho para aplicações com grande consumo de memória;
    • O endereçamento de memória é virtualmente ilimitado (até 1 hexabyte). Entretanto, grandes heaps afetam o desempenho do coletor de lixo;
  • Aplicações que precisam executar com mais de 1,5 GB de RAM (incluindo o espaço livre para otimizações do coletor de lixo) deveriam utilizar JVMs de 64 bits;
  • Aplicações que executam numa JVM de 32 bits e não exigem mais que os tamanhos mínimos de heap não irão se aproveitar dos recursos oferecidos por uma JVM de 64 bits;

Nosso próximo passo então será a instalação de um JDK.

Este tutorial, poderá ter seus passos seguidos através do uso da vm-curso-ladoservidor. Isto é recomendável e facilitará as atividades a seguir que, mesmo assim, podem ser executadas em qualquer Ubuntu na versão 10.04.

Instalando um Java Development Kit (JDK)

Versões anteriores a 10.04 do Ubuntu costumavam instalar um JDK através dos pacotes sun-java*. Entretanto nesta versão, o pacote sun-java6-jdk foi movido para outro repositório. Isto tornou sua instalação um pouco mais complexa. Contudo, o objetivo desta mudança foi dar maior visibilidade a versão open source equivalente (o OpenJDK) que pode ser facilmente instalado através dos repositórios de pacotes já configurados.

Instalando o OpenJDK

A instalação do OpenJDK (e o teste das versões de seus binários) é realizada pela execução dos comandos a seguir:

$ sudo apt-get install openjdk-6-jdk
$ java -version
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-0ubuntu1)
OpenJDK Client VM (build 14.0-b16, mixed mode, sharing)
$ javac -version
javac 1.6.0_18

Na vm-curso-ladoservidor o pacote openjdk-6-jdk já está instalado. Logo, o comando acima não efetua nenhum download/instalação nesta VM. Entretanto, se o removessemos e mandássemos reinstalá-lo, o download deste pacote iria exigir que alguns outros também fossem baixados. É fácil saber quais são eles através da execução do comando abaixo:

$ apt-cache depends openjdk-6-jdk

Se solicitarmos a remoção completa do pacote openjdk-6-jdkpodemos notar que, mesmo assim, o comando java continuará a funcionar. Por que? Vamos descobrir, seguindo a execução (e visualizando o resultado) dos comandos abaixo:

$ sudo apt-get purge openjdk-6-jdk
$ java -version
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-0ubuntu1)
OpenJDK Client VM (build 14.0-b16, mixed mode, sharing)
$ which java
$ ls -la /usr/bin/java
lrwxrwxrwx 1 root root 22 2010-06-30 11:17 /usr/bin/java -&gt; /etc/alternatives/java
$ ls -la /etc/alternatives/java
lrwxrwxrwx 1 root root 40 2010-06-30 11:17 /etc/alternatives/java -&gt; /usr/lib/jvm/java-6-openjdk/jre/bin/java
$ ls -la /usr/lib/jvm/java-6-openjdk/jre/bin/java
-rwxr-xr-x 1 root root 38548 2010-04-15 00:43 /usr/lib/jvm/java-6-openjdk/jre/bin/java
$ dpkg -S /usr/lib/jvm/java-6-openjdk/jre/bin/java
openjdk-6-jre-headless: /usr/lib/jvm/java-6-openjdk/jre/bin/java

Pela saída apresentada acima, notamos que o comando java é um link simbólico em /usr/bin/java. Este link aponta para outro (/etc/alternatives/java) que por sua vez, aponta para o binário disponibilizado em /usr/lib/jvm/java-6-openjdk/jre/bin/java. Com base na localização real deste binário, o utilitário dpkg-query pode ser utilizado para então determinar qual o pacote que o contém. Por fim, sua saída nos indica que este pacote é o openjdk-6-jre-headless. Ou seja, se apenas desejássemos ter instalado a JRE (e não o JDK), este seria o pacote que deveriamos utilizar.

Para que todo este uso de links simbólicos? Este mecanismo é utilizado no Linux para possibilitar que diferentes alternativas de JDK/JRE possam ser instaladas. O link /etc/alternatives/java é atualizado quando se instala uma versão diferente de JRE, mas o /usr/bin/javanão. Para testar isto, vamos executar a instalação do pacote sun-java6-jdk através dos comandos do tópico a seguir.

Instalando o JDK da Sun

Talvez, por qualquer motivo que seja, desejemos não utilizar a versão open source do JDK. Se isto ocorrer, o JDK da falecida Sun (comprada pela Oracle) pode ser instalado no Ubuntu de acordo com os comandos a seguir:

$ sudo bash -c '
add-apt-repository "deb lucid partner"
apt-get update
apt-get install sun-java6-jdk sun-java6-plugin
update-java-alternatives -s java6-sun

Os comandos acima irão:

  1. Adicionar o repositório de pacotes para o qual foram movidos os pacotes sun-java6-*;
  2. Atualizar a lista de pacotes do Ubuntu;
  3. Implantar a JDK da Sun e o plugin para browsers Mozilla (incluindo o Firefox);

Após ter realizado a instalação, note que o link /etc/alternatives/java agora estará apontando para outro binário, conforme apresentado pela saída do comando a seguir:

$ readlink /etc/alternatives/java

Note também que as versões apresentadas na execução dos binários do JDK/JRE também mudam:

$ java -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)
$ javac - version
javac 1.6.0_20

Para vermos que outras alternativas teríamos para os binários do JDK, o comando a seguir poderia ser utilizado:

$ update-java-alternatives -l
java-6-openjdk 1061 /usr/lib/jvm/java-6-openjdk
java-6-sun 63 /usr/lib/jvm/java-6-sun

Sendo assim, podemos novamente apontar os links para os binários do OpenJDK (reinstalando-o) através dos comando a seguir:

$ sudo bash -c '
apt-get install openjdk-6-jdk icedtea6-plugin
update-java-alternatives -s java-6-openjdk

O pacote icdetea6-plugin é similar em funcionalidades ao sun-java6-plugin mas, é open source.

Na opinião do Lado Servidor, o OpenJDK é o futuro que já se tornou presente em termos de Java livre! E, sendo assim, ele merece nossa total chance de uso. Neste tutorial, a versão de JDK de nossa escolha para a execução do JBoss é o OpenJDK.

Baixando e instalando o JBoss

As tarefas relativas ao download e a instalação do JBoss são muito simples e podem ser realizados de maneira manual através de quatro passos (sendo um opcional):

  • Baixar um arquivo compactado da Internet;
  • Verificar se o download foi efetuado corretamente, utilizando o utilitário md5sum; (passo opcional)
  • Descompactar este arquivo no sistema de arquivos local;
  • Ajustar algumas variáveis de ambiente;

Para automatizar este trabalho, deixando-o ainda mais simples, iremos criar e executar um shell-script que poderá ser utilizado várias vezes para refazer as tarefas acima. Além de torná-las automáticas e padronizadas, o script também verificará possíveis erros, como:

  • Download incompleto ou errado;
  • Impossibilidade de baixar ou extrair o arquivo de instalação do JBoss por qualquer motivo; (Ex.: falta de espaço em disco)

Vamos gerar o script pela execução do seguinte comando:

$ cat &gt; instalar-jboss &lt;&lt;'FIM'
ok_ou_falha() { [ $? = 0 ] &amp;&amp; echo Ok || { echo "Falhou! Veja $LOG"; exit 1; }; }
  [ -f "$JBOSS_ZIP" -a -f "$JBOSS_ZIP.md5" ] || {
    for f in $JBOSS_ZIP $JBOSS_ZIP.md5; do
      [ -f "$f" ] &amp;&amp; continue
      echo -n "Baixando $f... "
      wget "`echo $JBOSS_DOWNLOADS_URL | sed s,ARQUIVO,$f,g`" &amp;&gt; $LOG
echo -n "Verificando o checksum do arquivo $JBOSS_ZIP... "
test `md5sum $JBOSS_ZIP | cut -d ' ' -f 1` = `cat $JBOSS_ZIP.md5`
mkdir -p $FERRAMENTAS_DIR &amp;&amp; cd $FERRAMENTAS_DIR
echo -n "Extraindo $JBOSS_ZIP... "
rm -rf $JBOSS_DIR; unzip $INSTALADORES_DIR/$JBOSS_ZIP &amp;&gt; $LOG
echo -n "Criando o link jboss para $JBOSS_DIR... "
rm -f jboss; ln -s $JBOSS_DIR jboss
grep '^# Ajusta.*JBoss$' ~/.bashrc &amp;&gt; /dev/null &amp;&amp; exit 0
echo -n "Ajustando as variáveis de ambiente para o funcionando do JBoss... "
cat &gt;&gt; ~/.bashrc &lt;&lt;'EOF'
# Ajusta as variáveis de ambiente para o funcionamento do JBoss
export JAVA_HOME=/usr/lib/jvm/java-6-openjdk

Após a execução do comando acima, será criado o script instalar-jboss, que realiza as seguintes tarefas:

  • Ajusta algumas variáveis que representam:
    • O log de execução para algumas tarefas ($LOG), que será gerado no diretório /tmp com o nome do arquivo sendo o número do processo em execução;
    • O diretório que conterá o instalador do JBoss: $INSTALADOR_DIR
    • O diretório que conterá o JBoss após sua instalação: $FERRAMENTAS_DIR
    • O zip do JBoss: $JBOSS_ZIP
    • A URL base que será utilizada para o download do zip do JBoss: $JBOSS_URL
    • O diretório que será construído pela extração do JBoss: $JBOSS_DIR
  • Cria a função ok_ou_falha que verificará se houve erro na execução do comando anterior e, em caso positivo, abortará a execução do mesmo;
  • Cria o diretório $INSTALADOR_DIR e efetua a mudança para ele (mkdir -p ...);
  • Baixa, caso não existam, o zip de instalação do JBoss e o arquivo que contém seu checksum ($JBOSS_ZIP.md5) redirecionando a saída do comando para $LOG;
  • Verifica o resultado do comando anterior e, em caso de insucesso, aborta a continuação do script informando a ocorrência de um erro;
  • Testa o md5sum do $JBOSS_ZIP;
  • Verifica o resultado do comando anterior e, em caso de insucesso, aborta a continuação do script informando a ocorrência de um erro;
  • Cria o diretório $FERRAMENTAS_DIR e efetua a mudança para ele (mkdir -p ...);
  • Remove o diretório de instalação do JBoss (caso exista) e extrai o conteúdo o zip do JBoss (unzip ...);
  • Verifica o resultado do comando anterior e, em caso de insucesso, aborta a continuação do script informando a ocorrência de um erro;
  • Remove (caso exista) e cria o link simbólico jboss apontando para o diretório no qual foi extraído o JBoss (ln -s ...);
    • A criação deste link simbólico simplificará o valor da variável $JBOSS_HOME tornando mais fácil a substituição do JBoss por outra versão, caso precisemos realizar esta tarefa no futuro;
  • Utiliza o grep para verificar se o conteúdo do arquivo $HOME/.bashrc já foi atualizado com as configurações das variáveis de ambiente e, em caso positivo, encerra a execução do script;
  • Adiciona conteúdo ao arquivo ~/.bashrc ajustando o valor para algumas variáveis de ambiente utilizadas pelo JBoss na sua execução. As seguintes variáveis de ambiente são adicionadas:
    • $JAVA_HOME, que guarda a localização do diretório de instalação do JDK;
    • $JBOSS_HOME, que guarda a localização do diretório de instalação do JBoss;
    • $PATH, que agora agregará a localização para os binários do JBoss ($JBOSS_HOME/bin);
  • Utiliza o sed para alterar o conteúdo do arquivo ~/.bashrc e substituir a string FERRAMENTAS_DIR pelo valor correspondente a variável $FERRAMENTAS_DIR;
  • Verifica o resultado do comando anterior e, em caso de insucesso, aborta a continuação do script informando a ocorrência de um erro;

A execução do script instalar-jboss, e o carregamento das variáveis de ambientes necessárias para a execução do JBoss AS, podem ser realizadas através da execução dos comandos a seguir (observe a saída de execução do instalar-jboss):

$ chmod +x instalar-jboss &amp;&amp; ./instalar-jboss
Baixando Ok
Extraindo Ok
Criando o link jboss para jboss- Ok
Ajustando as variáveis de ambiente para o funcionando do JBoss... Ok
$ source ~/.bashrc

O script instalar-jboss poderá ser executado quantas vezes for necessário. Ele sempre apagará a instalação anterior do JBoss e refazê-la. Só baixará o instalador do JBoss caso ele não seja encontrado. Verificará se o checksum MD5 do instalador está correto e, só reajustará o conteúdo de ~/.bashrc caso isto já não tenha sido realizado.

Você pode verificar se o ajuste do arquivo ~/.bashrc foi realizado com sucesso através da execução do comando tail, com o parâmetro -n 4 para solicitar apenas a impressão das quatro últimas linhas deste arquivo:

$ tail -n 4 ~/.bashrc
# Ajusta as variáveis de ambiente para o funcionamento do JBoss
export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
export JBOSS_HOME=/home/aluno/ferramentas/jboss

Quando o comando source ~/.bashrc é executado, o shell corrente refaz a leitura deste arquivo. Com isto, as variáveis de ambiente ficam disponíveis. Como este arquivo é lido a cada vez que se abre um shell no Linux, estas variáveis estarão disponíveis toda vez que isto ocorrer.

A partir deste ponto, estamos preparados para executar o JBoss. Isto é o que faremos nos próximos passos.

Iniciando e parando o JBoss

Da forma mais básica e simples possível

A execução do JBoss pode ser realizada através do comando a seguir:


Quando o comando acima é invocado, o JBoss inicia sua execução. Vários serviços serão levantados por ele e o log de execução aparece na tela aberta.

Após o JBoss subir todos os serviços da configuração corrente e estar pronto para ser executado, uma mensagem como a apresentada a seguir, deverá estar presente na console de sua execução:

07:59:50,725 INFO  [org.jboss.bootstrap.impl.base.server.AbstractServer] JBossAS [ "Neo"] Started in 38s:311ms

Este é o sinal visível pelo log, de que o JBoss foi iniciado.

Para finalizar a execução do JBoss existem várias alternativas. A mais simples delas, caso tenhamos acesso a console de sua execução, é pressionar, simultaneamente, as teclas Ctrl e C (Ctrl+C). Desta forma, um sinal de shutdown será enviado ao JBoss para que ele possa encerrar sua execução, educadamente. Isto significa que ele solicitará, para cada um dos serviços em execução, o seu encerramento. Quando tudo estiver consumado ;-), no log da console aberta deveremos notar uma frase como a apresentada a seguir:

08:09:59,379 INFO  [AbstractServer] Stopped: JBossAS [ "Neo"] in 7s:999ms

Colocando o JBoss em background

Talvez não queiramos que a execução do JBoss esteja atrelada a uma console. Sendo assim, a forma correta de iniciarmos o JBoss seria através do comando a seguir:

$ JBOSS_CONSOLE=/tmp/jboss.log; nohup &amp;&gt; $JBOSS_CONSOLE &amp;

Com isto, o log de execução do JBoss (tanto para a saída padrão quanto de erros) será direcionado ao arquivo /tmp/jboss.log. O comando nohup desatrela a execução do comando do shell corrente e o &, ao final do comando, coloca a execução do JBoss em background, liberando o shell corrente para a digitação de novos comandos.

Uma característica desta forma de inicialização do JBoss é que não veremos mais o seu log na tela aberta. Para podermos então acessá-lo, faremos uso do comando tail, conforme demonstrado a seguir:

$ tail -f $JBOSS_CONSOLE

Outra característica importante é que, mesmo fechando o shell corrente, o JBoss continuará em execução. Experimente isto! Feche a console corrente, e abra uma nova. Após fazer isto, verifique que o processo de execução do JBoss ainda está ativo, através da chamada ao seguinte comando:

$ ps -ef | grep org.jboss.Main

A classe org.jboss.Main é classe que inicializa o JBoss, e que é executada na execução do comando java através script

Outra forma de verificar a execução de uma aplicação Java, de uma forma mais portável, é utilizar o comando jps. Ele é um utilitário do JDK e, sendo assim, pode ser utilizado nos diferentes sistemas operacionais que suportam o Java. O uso do jps, para saber se o JBoss está em execução, é exemplificado a seguir:

$ jps -l | grep org.jboss.Main

Agora que não temos mais acesso a console de execução do JBoss, como encerrá-lo? Alguns brutos diriam: kill -9 no process id (PID) do JBoss ;-). Mas, nós somos educados! A menos que o JBoss não o seja conosco, nós não iremos utilizar o comando kill e, em seu lugar, invocaremos o comando a seguir:

$ -S

Isto fará com que o JBoss entenda que queremos tirá-lo de campo ;-).

No Linux, mesmo que o JBoss já esteja em execução, podemos colocá-lo em background. Para isto, os procedimentos são:

  • Iniciar o JBoss da forma mais básica e simples possível ( Como vimos, ele ficará atrelado a execução da console corrente;
  • Digitar, simultaneamente, as teclas Ctrl e Z (Ctrl+Z). Isto fará com que o processo em execução do JBoss seja parado;
  • Executar o comando bg. Isto colocará a execução do JBoss em background. Mas, trará o inconveniente de que qualquer log de sua execução ainda aparecerá na tela da console aberta.

Execute os procedimentos acima antes de prosseguir!

Permitindo o acesso para além de localhost

Por medida de segurança o JBoss não permite, nas formas de inicialização que foram apresentadas anteriormente, que ocorra o acesso aos serviços levantados por ele, fora de localhost. Isto significa, por exemplo, que não conseguiriamos acessar as interfaces administrativas do JBoss a partir de outra máquina. Como testar isto? Existem algumas formas. Uma delas é observar que portas estão sendo utilizadas pelo processo do JBoss, como apresentado no tópico “Verificando as portas utilizadas pelo JBoss“. Execute os comandos daquele tópico e depois retorne a este.

Pelo que podemos observar, por padrão todas as portas TCP abertas pelo JBoss são acessíveis apenas pelo endereço IP (localhost). Logo, tirando a própria máquina que executa o JBoss, nenhuma outra poderá acessar seus serviços.

Liberar o acesso ao JBoss para outras máquinas, implica em reinicializá-lo com um parâmetro que informe que ele deverá se ligar a uma interface de rede que tenha um IP acessível por outras máquinas, ou, que ele deverá se ligar a todas as interfaces de rede. Estas tarefas podem ser realizadas através do parâmetro de inicialização “-b <IP_OU_NOME>“. Vamos então parar o JBoss em execução e levantá-lo novamente, com este parâmetro:

$ -S; tail -f $JBOSS_CONSOLE

Ao perceber que o JBoss foi finalizado com sucesso através da observação do log, damos um Ctrl+C na execução do tail e reinicializamos o JBoss:

$ JBOSS_CONSOLE=/tmp/jboss.log; nohup -b &amp;&gt; $JBOSS_CONSOLE &amp;

Agora, pelo uso do parâmetro “-b” passado ao, estamos solicitando ao JBoss que ele entre em execução aguardando conexões oriundas de qualquer uma de suas interfaces de rede.

Após reexecutar o comando que nos possibita averiguar as portas utilizadas pelo JBoss (sudo netstat -tulpn | grep `ps -ef | grep org.jboss.Main | awk '{print $2}'`), poderemos observar um resultado semelhante ao apresentado a seguir (são mostradas apenas algumas linhas):
[code type=txt]
tcp 0 0* LISTEN 13415/java
tcp 0 0* LISTEN 13415/java
tcp 0 0* LISTEN 13415/java
tcp 0 0* LISTEN 13415/java

Vendo a saída apresentada, notamos que conexões as portas 8080, 8083, etc, podem ser realizadas a partir de qualquer uma das interfaces de rede. Isto é identificado na saída pelo número do IP apresentado antes do número da porta: “”.

Podemos testar o acesso a uma porta servida pelo JBoss, através do comando telnet, como exemplificado a seguir: (Substitua o IP apresentado por um IP válido em tua máquina, diferente do IP

$ telnet 8080
Connected to
Escape character is '^]'.
^]Connection closed by foreign host.

Se desejássemos que o JBoss se ligasse apenas a uma interface de rede específica informaríamos, no lugar de “-b“, o IP ou o nome da máquina associada a ele (pelo arquivo /etc/hosts ou pelo DNS). Por exemplo, -b

Colocando uma instância diferente em execução

Uma instância de JBoss, é uma configuração em execução. O JBoss, ao ser instalado, vem com diferentes configurações e cada uma delas é localizada no diretório $JBOSS_HOME/server, conforme apresentado na saída do comando a seguir:

$ tree -L 1 -d $JBOSS_HOME/server
??? all
??? default
??? jbossweb-standalone
??? minimal
??? osgi
??? standard

A saída acima apresenta 6 configurações distintas. Por padrão, quando não é especificado que configuração será executada, o jboss levantará a “default“.

Cada configuração, possui um conjunto próprio de diretórios e arquivos. Por exemplo, na configuração “default“, temos os seguintes diretórios no primeiro nível:

$ tree -L 1 -d $JBOSS_HOME/server/default
??? conf
??? data
??? deploy
??? deployers
??? lib
??? log
??? tmp
??? work

O escopo deste tópico não abrange a explicação de cada um destes diretórios. Isto é abordado em outra parte do treinamento “`JBAS-1-T”. Entretanto, é aqui que informamos que, para levantar uma instância diferente de JBoss, o parâmetro “-c <configuracao>” deve ser passado ao script Devemos também notar que “” ou “ -c default” significam a mesma coisa. Para testar o uso deste parâmetro, vamos finalizar a instância corrente:

$ -S; tail -f $JBOSS_CONSOLE

Agora, vamos iniciar uma instância diferente do JBoss, a “minimal“:

$ -c minimal

Podemos observar que esta instância sobe em bem menos tempo que a “default“. Dê um Ctrl+C em sua console para finalizá-la.

Também foge do escopo deste tópico as explicacões para as configurações de JBoss. Mais informações sobre isto podem ser obtidas no treinamento “`JBAS-1-T”.

Colocando mais de uma instância em execução

É possível subir várias instâncias do JBoss ao mesmo tempo. Basicamente, existem duas alternativas para isto: utilizar um IP diferente para cada instância ou, utilizar um conjunto de portas diferente para cada uma delas.

A alternativa mais comum para administradores de servidores Linux, após terem conhecido o uso do parâmetro “-b <IP_OU_NOME>“, discutido no tópico anterior, é realizar a criação de uma interface de rede (virtual ou não) e levantar cada instância de JBoss num IP específico. Esta alternativa entretanto, exige o domínio de comandos do Linux. A outra solução, utilizar portas diferentes para o JBoss, não exige conhecimentos específicos de Linux e pode ser aplicada em diferentes sistemas operacionais.

Através de portas diferentes

A execução de mais de uma instância de JBoss através do uso de um conjunto diferente de portas, para cada uma delas, é realizada na versão 6 pelo uso de uma propriedade de sistema, passado para a JVM que executará a instância.

O procedimento é bem simples. Uma segunda instância baseada em “default” poderá subir da seguinte forma:

  • Copiamos o conteúdo de “default” para outro diretório, também abaixo de $JBOSS_HOME/server/, com o nome que desejarmos. Por exemplo: “instancia2“;
  • Executamos o de “instancia2” informando a propriedade de sistema com o parâmetro “-Dpropriedade=valor“;

Estes são os comandos que irão criar “intancia2” e colocá-la em execução, ao mesmo tempo em que será realizada a inicialização da instância “default“:

$ bash -c '
cp -r $JBOSS_HOME/server/default $JBOSS_HOME/server/instancia2
nohup &amp;&gt; /tmp/jboss.default.log &amp;
nohup -c instancia2 -Djboss.service.binding.set=ports-01 &amp;&gt; /tmp/jboss.instancia2.log &amp;

Para parar a segunda instância, podemos executar o seguinte comando:

$ -S -s jnp://localhost:1199

Nos parâmetros passados ao, além do -S que já conhecíamos, desta vez também informamos -s jnp://localhost:1199. Isto significa que queremos parar o JBoss que está sendo executado localmente, enviando um comando que será transmitido a porta 1199 do JBoss em execução. Por padrão, quando não informamos estes parâmetros/valores, é como se estivéssemos escrito -S -s jnp://localhost:1099. O parâmetro -sou --server= especifica uma URL para o endereço de um servidor de nomes JNDI (Java Naming and Directory Interface).

Quando utilizamos o valor ports-01 para a propriedade jboss.service.bind.set cada uma das portas utilizadas pela configuração default (sem o uso desta propriedade) tem o seu valor incrementado de 100. Se utilizarmos o valor ports-02, ao valor padrão é somado 200, e assim por diante… Podemos observar isto pelo uso do netstat:

Obtendo as portas utilizadas pela primeira instância (ordenando e mostrando apenas as seis primeiras linhas da saída gerada):
[code type=txt]
$ sudo netstat -tulpn | grep $(ps -ef | grep org.jboss.Main$ | awk ‘{print $2}’) | sort | head -n3
tcp 0 0* LISTEN 19352/java
tcp 0 0* LISTEN 19352/java
tcp 0 0* LISTEN 19352/java
tcp 0 0* LISTEN 19352/java
tcp 0 0* LISTEN 19352/java
tcp 0 0* LISTEN 19352/java

Obtendo as portas utilizadas pela segunda instância (ordenando e mostrando apenas as seis primeiras linhas da saída gerada):
[code type=txt]
$ sudo netstat -tulpn | grep $(ps -ef | grep org.jboss.Main.*ports-01$ | awk ‘{print $2}’) | sort | head -n6
tcp 0 0* LISTEN 19357/java
tcp 0 0* LISTEN 19357/java
tcp 0 0* LISTEN 19357/java
tcp 0 0* LISTEN 19357/java
tcp 0 0* LISTEN 19357/java
tcp 0 0* LISTEN 19357/java

Através de IPs diferentes

Executar outra instância do JBoss através de IPs diferentes já foi explicado. Não é mais novidade que o parâmetro “-b <IP_OU_NOME>“, passado ao, possibilita a execução de uma outra instância do JBoss num IP diferente mas, escutando o mesmo conjunto de portas. A questão é: e se tivermos apenas uma interface de rede, por exemplo, a eth0? Bem, neste caso, se não quisermos mesmo utilizar um conjunto diferente de portas, a solução é criar uma interface de rede virtual.

Uma interface de rede virtual pode ser criada no linux com o comando ifconfig. Supondo que estamos na rede e que o IP esteja disponível, o comando a seguir criaria a interface virtual eth0:0:

ifconfig eth0 add netmask

Agora, teríamos uma interface de rede virtual, associada a mesma placa de rede mas com um IP diferente e, com isto, poderíamos iniciar o JBoss neste novo IP através de -b Não haveria nenhum problema nesta abordagem e nem conflitos no uso de portas.

Para remover a interface virtual o mesmo ifconfig poderia ser utilizado, informando-se os parâmetros abaixo:

  ifconfig eth0 del

Verificando as portas utilizadas pelo JBoss

O comando netstat possibilita-nos averiguar que portas são utilizadas por um processo em execução. Para testá-lo, caso o JBoss não esteja no ar, vamos iniciá-lo:

$ JBOSS_CONSOLE=/tmp/jboss.log; nohup &amp;&gt; $JBOSS_CONSOLE &amp;

Agora, a partir da execução do comando a seguir, solicitaremos ao netstat que nos informe que portas estão sendo utilizadas pelo PID do JBoss:

$ sudo netstat -tulpn | grep `ps -ef | grep org.jboss.Main | awk '{print $2}'`

A linha acima merece algumas explicações! Nela, o netstat está sendo executado com o comando sudo logo, é como se ele estivesse sendo rodado pelo superusuário (root) e, portanto, imprime a informação de todos os processos em execução na máquina. Mas, nós só queremos as informações do processo que executa a JVM do JBoss (ps -ef | grep org.jboss.Main). A partir do resultado obtido com este comando, queremos pegar o PID do processo. Em sua saída já temos isto, mas queremos apenas um número, que é representado pelo segundo campo (na saída do ps). Logo, utilizamos o canivete suiço awk para obter apenas este campo. O número obtido é passado ao grep que, por sua vez, recebe como entrada, a saída do netstat filtrando assim, apenas as portas utilizadas pelo JBoss (colhemos da saída do netstat apenas os processo com o PID do mesmo).

A saída do comando executado obviamente varia entre máquinas diferentes mas, deverá ser algo próximo ao apresentado abaixo:
[code type=txt]
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
tcp 0 0* LISTEN 11068/java
udp 0 0* 11068/java
udp 0 0* 11068/java

Na quarta coluna, temos um par de valores IP:porta. A sexta coluna, onde para as conexões do tipo tcp está escrito LISTEM, indica que tais IPs/portas estão aguardando conexões. A sétima coluna nos informa o PID do processo que está escutando tal porta. Logo, neste exemplo, o PID do JBoss é de nr. 11068 e está escutando todas as portas listadas acima.