JBoss EAP 6

Configurando Ambiente de Produção no JBoss AS 7.1.3 (JBoss EAP 6.0.1) – Parte 4

Postado em

E ai galera blz?

Continuando os posts:

Anteriormente nós configuramos um balanceador de carga ( Apache + Mod Cluster ) , um Domain Controller e dois Host Controllers com uma instância cada. Ativamos também os recursos de cluster.

Hoje vamos aprender como encriptar o tráfego entre o Cliente<— —> Balancer <— —> Instâncias JBoss utilizando SSL.

Atualmente nós temos o seguinte cenário:

env-1

O dados estão trafegando sobre HTTP sem nenhuma criptografia podendo ser interceptado facilmente.

Então a primeira coisa a ser feita é utilizar SSL entre Cliente <—- —-> Balancer:

env-2

Antes de tudo quero deixar claro que vai ocorrer perda de performance já que o tráfego será encriptado.

Vamos gerar os certificado para ser utilizado no Apache Web Server que é o nosso Balancer.  Pelo fato de  utilizar o SSL/HTTPS devemos instalar o Mod SSL. Para isso, execute :

yum install mod_ssl

Vamos utilizar o openssl para geração dos certificados. Instale os pacotes necessários:

yum install openssl ca-certificates

Para melhor organização crie  um diretório dentro de /etc/ssl com o nome de server-certs:

mkdir /etc/ssl/server-certs

O primeiro passo é gerar uma chave privada.  Navegue até o diretório /etc/ssl/server-certs  e execute:

openssl genrsa -des3 -out my-server.key 2048

A chave gerada está encriptada e protegida por uma senha ou seja se nós utilizarmos essa chave no Apache, toda vez que reiniciarmos o serviço essa senha será solicitada causando alguns transtornos. Para solucionarmos essa questão podemos gerar uma chave “desprotegida” baseada na chave privada  my-server.key que não irá solicitar qualquer tipo de senha.

Execute comando abaixo para que a chave seja gerada:

openssl rsa -in my-server.key -out my-server.key.public

Tenha muito cuidado com a chave privada my-server.key, guarde-a em um local seguro e que seja acessível somente pelo root.

O próximo passo é gerar o Certificate Signing Request. Execute o comando abaixo:

openssl req -new -key my-server.key -out my-server.csr

O arquivo my-server.crt deveria ser enviado para a autoridade certificadora, que devolveria o certificado assinado. Neste caso, vamos utilizá-lo para criar um certificado auto assinado válido por 365 dias. Para isso execute:

openssl x509 -req -days 365 -in my-server.csr -signkey my-server.key -out my-server.cer

A criação dos certificados está concluída. Foram gerado os seguintes arquivos:

my-server.key – Chave privada.
my-server.key.public –  Chave sem password.
my-server.csr – Pedido de assinatura do certificado.
my-server.cer – Certificado auto assinado.

Edite o arquivo  vim /etc/httpd/conf.d/mod_cluster.conf  e deixe-o como  abaixo:

<VirtualHost 192.168.0.141:443>

SSLEngine on
SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL
SSLVerifyDepth 10
SSLCertificateFile /etc/ssl/server-certs/my-server.cer
SSLCertificateKeyFile /etc/ssl/server-certs/my-server.key.public

<Directory />
Order deny,allow
Allow from all
</Directory>

KeepAliveTimeout 60
ManagerBalancerName mycluster
MaxKeepAliveRequests 0
ServerAdvertise On

EnableMCPMReceive On

</VirtualHost>

<Location /mod_cluster-manager>
SetHandler mod_cluster-manager
Order deny,allow
Allow from all
</Location>

Reinicie o Apache e acesse  por exemplo https://192.168.0.140/cluster e observe que agora os dados já trafegam encriptados. Para verificar se os dados realmente estão encriptados utilize o Wireshark.

Essa foi a parte final. Você pode ter sentido falta de muitos  outros tópicos como configuração de datasource, tuning e algumas outras coisas mas a ideia dessa série foi configurar a infra para um ambiente JBoss moderno.

Nas próximas semanas estarei publicando novos posts relacionados a tuning.
Obrigado e Abraços 🙂

RESTful Web Services com RestEasy, Weld e Hibernate no JBoss AS 7.1.3 ( JBoss EAP 6.0.1 )

Postado em Atualizado em

Olá amigos,

Hoje vamos aprender um pouco sobre REST 🙂

O REST(Representational State Transfer) descreve arquiteturas que utilizam o protocolo HTTP ou protocolos similares, restringindo a interface para um conjuntos de operações conhecidas como por exemplo GET, POST, PUT e DELETE para HTTP.

O termo Representational State Transfer foi introduzido e definido em 2000 por Roy Fielding em sua tese de doutorado.

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Na plataforma Java temos o JAX-RS que fornece uma API padronizada para a construção de Web Services RESTful. Essa API possui um conjunto de anotações e interfaces que são aplicadas nos POJOs expondo assim facilemente recursos na web. Essa abordagem torna simples a criação de Web Services RESTful em Java.

Um conceito muito importante quando utilizamos REST é a existência de resources, onde cada resource possui um identificador global, isto é, uma URI.
Os resources podem ser representados em diversos formatos por exemplo html, xml ou json.

A anotação @Path define o caminho relativo da URI. Todo resource deve possuir uma URI que é definida por essa anotação.
Essa característica é bastante poderosa pois permite incorporar variáveis dentro da sintaxe da URI e essas variáveis podem ser substituídas em tempo de execução.

Com o JAX-RS  os métodos HTTP mapeados para métodos Java de um resource. As anotações @GET, @PUT, @POST, @DELETE e @HEAD são utilizadas para realizar esse mapeamento. Podemos ainda definir subresources detro de um resource utilizando a anotação @Path nos métodos.

A anotação @Produces é utilizada para especificar os tipos MIME que um resource pode consumir que foram enviados de um cliente. Tipos MIME incluem PLAIN_TEXT, TEXT_XML, APPLICATION_XML e APPLICATION_JSON.

No JBoss podemos utilizar o RESTEasy que é uma implementação da especificação JAX-RS e que  fornece uma API Java para Web Services RESTful através do protocolo HTTP.  No post de hoje vamos criar um pequeno exemplo que lista os estados e cidades de todo o Brasil armazenados no MySQL.

O primeiro passo é criar no MySQL um database chamado jbossdb  e criar as tabelas tb_estados e tb_cidades utilizando o seguite script: Cidades Estados.  Faça também os inserts com os nomes dos estados e das cidades.

Configure um datasource no arquivo JBOSS_HOME/standalone/configuration/standalone.xml para o MySQL:

<datasource jndi-name="java:/MySQLDS" pool-name="MySQLDS-Pool" enabled="true" use-java-context="true">
  <connection-url>jdbc:mysql://localhost:3306/jbossdb</connection-url>
  <driver>mysql-connector-java-5.1.22-bin.jar</driver>
  <security>
   <user-name>root</user-name>
   <password>jboss</password>
  </security>
</datasource>

O pom.xml deverá ser algo como:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.jbossdivers</groupId>
 <artifactId>rest</artifactId>
 <packaging>war</packaging>
 <version>1.0</version>
 <name>rest Maven Webapp</name>
 <url>http://maven.apache.org</url>

 <repositories>
   <repository>
    <id>JBoss repository</id>
    <url>https://repository.jboss.org/nexus/content/groups/public/</url>
   </repository>
  </repositories>

  <dependencies>

   <dependency>
     <groupId>org.jboss.spec</groupId>
     <artifactId>jboss-javaee-6.0</artifactId>
     <version>1.0.0.Final</version>
     <type>pom</type>
     <scope>provided</scope>
   </dependency>
   <dependency>
     <groupId>org.jboss.resteasy</groupId>
     <artifactId>resteasy-jaxrs</artifactId>
     <version>2.2.2.GA</version>
     <scope>provided</scope>
   </dependency>
   <dependency>
     <groupId>org.jboss.resteasy</groupId>
     <artifactId>resteasy-jaxb-provider</artifactId>
     <version>2.2.2.GA</version>
     <scope>provided</scope>
   </dependency>
   <dependency>
     <groupId>org.jboss.resteasy</groupId>
     <artifactId>resteasy-jettison-provider</artifactId>
     <version>2.2.2.GA</version>
     <scope>provided</scope>
   </dependency>
   <dependency>
     <groupId>org.hibernate</groupId>
     <artifactId>hibernate-core</artifactId>
     <version>4.0.1.Final</version>
     <scope>provided</scope>
   </dependency>
   <dependency>
     <groupId>org.hibernate</groupId>
     <artifactId>hibernate-entitymanager</artifactId>
     <version>4.0.1.Final</version>
     <scope>provided</scope>
   </dependency>
   <dependency>
     <groupId>org.hibernate</groupId>
     <artifactId>hibernate-annotations</artifactId>
     <version>3.5.6-Final</version>
     <scope>provided</scope>
   </dependency>
   <dependency>
     <groupId>org.jboss.weld</groupId>
     <artifactId>weld-api</artifactId>
     <version>1.0</version>
     <scope>provided</scope>
    </dependency>
   </dependencies>
   <build>
    <plugins>
     <plugin>
       <artifactId>maven-resources-plugin</artifactId>
       <version>2.4.3</version>
       <configuration>
         <encoding>UTF-8</encoding>
       </configuration>
     </plugin>
     <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.3.2</version>
        <configuration>
           <source>1.6</source>
           <target>1.6</target>
        </configuration>
     </plugin>
     <plugin>
        <artifactId>maven-war-plugin</artifactId>
        <version>2.1.1</version>
        <configuration>
            <failOnMissingWebXml>false</failOnMissingWebXml>
        </configuration>
        </plugin>
     </plugins>
        <finalName>restapp</finalName>
     </build>
  </project>

Crie as entidades State e City para representar as tabelas tb_estados e tb_cidades:

Estado:

package com.jboss.rest.entity;

import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.Table;
import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement
@Entity
@Table(name="tb_estados")
public class State {

  @Id
  private Long id;
  private String uf;
  private String nome;

  //getters and setters
}

Cidade:

package com.jboss.rest.entity;

import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.Table;
import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement
@Entity
@Table(name="tb_cidades")
public class City {

  @Id
  private Long id;
  private Long estado;
  private String uf;
  private String nome;

  //getters and setters
}

O nosso serviço conterá os métodos para Listar todos os Estados e Listar as Cidades por Estado:

package com.jboss.rest.service;

import com.jboss.rest.entity.City;
import com.jboss.rest.entity.State;

import java.awt.print.Book;
import java.util.List;
import javax.inject.Inject;
import javax.persistence.EntityManager;

import javax.persistence.Query;
import javax.ws.rs.*;

@Path("/service")
public class MyService {

  @Inject
  private EntityManager em;

  @GET
  @Produces("application/json")
  @Path("/liststates")
  public List<State> listAllStates() {

    Query query = em.createQuery("FROM com.jboss.rest.entity.State");
    List <State> stateList =  query.getResultList();

    return stateList;
  }

  @GET
  @Produces("application/json")
  @Path("/listcitiesbystate/")
  public List<City> listAllCitiesByState(@QueryParam("uf")String uf) {

    Query query = em.createQuery("FROM com.jboss.rest.entity.City c where c.uf =:uf ").setParameter("uf",uf);
    List <City> cityList =  query.getResultList();

    return cityList;
  }
}

No serviço estamos injetando o EntityManager então crie um resource como abaixo:

package com.jboss.rest.qualifier;

import javax.enterprise.inject.Produces;

import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

public class Resources {

  @PersistenceContext
  @Produces
  private EntityManager em;
}

Em resource/META-INF/ crie o persistence.xml:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">

  <persistence-unit name="persistenceUnit" transaction-type="JTA">
    <provider>org.hibernate.ejb.HibernatePersistence</provider>
    <jta-data-source>java:/MySQLDS</jta-data-source>

    <properties>
      <property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect" />
    </properties>
  </persistence-unit>
</persistence>

Em webapp/WEB-INF crie o arquivo beans.xml para conseguirmos utilizar o CDI:

<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">

</beans>

Configure também o web.xml:

<!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd" >

<web-app>

  <display-name>Rest App</display-name>

  <context-param>
    <param-name>resteasy.servlet.mapping.prefix</param-name>
    <param-value>/rest</param-value>
  </context-param>

  <context-param>
    <param-name>resteasy.scan</param-name>
    <param-value>true</param-value>
  </context-param>

  <servlet>
    <servlet-name>RestServlet</servlet-name>
    <servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>

  <servlet-mapping>
    <servlet-name>RestServlet</servlet-name>
    <url-pattern>/rest/*</url-pattern>
  </servlet-mapping>

</web-app>

A estrutura final do projeto deverá ficar da seguinte maneira:

project

Agora faça o deploy da aplicação e acesse as urls dos serviços criados.

http://192.168.0.127:8080/restapp/rest/service/liststates

restestadoshttp://192.168.0.127:8080/restapp/rest/service/listcitiesbystate/?uf=mt

restcidades

Voce pode por exemplo criar um dropwdonw para listar as cidades quando um estado específico for selecionado:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script type="text/javascript" src="<c:url value="/js/jquery-1.9.1.min.js" />"></script>

<script type="text/javascript" charset="utf-8">

 $(document).ready(function() {

    $.ajax({
      contentType: 'application/x-www-form-urlencoded; charset=UTF-8',
      type: "GET",
      url: "/restapp/rest/service/liststates",
      dataType:"json",
      success: function(json) {
      $.each(json, function(i, value) {

         $('#state').append($('<option>').text(value.uf).attr('value', value.uf));

         $('#state').change(function() {

         $('#city').empty();

         $.ajax({
           contentType: 'application/x-www-form-urlencoded; charset=UTF-8',
           type: "GET",
           url: "/restapp/rest/service/listcitiesbystate/",
           data: 'uf='+ $('#state').val(),
           dataType:"json",
           success: function(json) {
           $.each(json, function(i, value) {
               $('#city').append($('<option>').text(value.nome).attr('value', value.nome));
           });
        }
     });

   });

  });
 }
});
});

</script>

</head>
<body>
  <form action="" id="test">
       <h2>Rest Service</h2>

       <select id="state" name="state"></select>
       <br />
       <select id="city" name="city"></select>
  </form>
</body>
</html>

restapp

Para mais informações consulte a JAX-RS 1.1 specification, JSR-311: http://jcp.org/en/jsr/detail?id=311

A aplicação utilizada nesse post está no github ( Sem querer comitei as confs do Intellij depois deleto!)

Espero que tenha ajudado.

Abraços

Mauricio Magnani Jr

Utilizando Múltiplas Versões de Drivers JDBC no JBoss AS 7.1.3 (JBoss EAP 6.0.1)

Postado em

E ai galera blz?

Em algumas situações precisamos utilizar várias versões de drivers JDBC do mesmo fabricante. Imagine uma empresa em que existem por exemplo 3 versões do Sistema de Gestao de Contratos que estão sendo executadas no JBoss AS 7 e cada uma delas utilize uma versão específica do Driver JDBC do MySQL:

  • Sistema de Gestao de Contratos Versão 1.0 – mysql-connector-java-5.1.19
  • Sistema de Gestao de Contratos Versão 2.0 – mysql-connector-java-5.1.23
  • Sistema de Gestao de Contratos Versão 3.0 – mysql-connector-java-5.1.24

A melhor abordagem na minha opnião é criar módulos globais (global module) e adicionar slots com diferentes versões de drivers.

Baixe os pacotes mysql-connector-java-5.1.19.zipmysql-connector-java-5.1.23.zip  e mysql-connector-java-5.1.24.zip no site do fabricante.

drivers-pack

Crie a estrutura de diretório para armazenar os arquivos dos módulos:

 mkdir -p jboss-eap-6.0/modules/com/mysql/main
 mkdir -p jboss-eap-6.0/modules/com/mysql/5.1.19
 mkdir -p jboss-eap-6.0/modules/com/mysql/5.1.23

Copie os arquivos .JAR para os diretórios dos módulos conforme abaixo:

 cp /tmp/mysql-connector-java-5.1.24-bin.jar jboss-eap-6.0/modules/com/mysql/main/
 cp /tmp/mysql-connector-java-5.1.19-bin.jar jboss-eap-6.0/modules/com/mysql/5.1.19/
 cp /tmp/mysql-connector-java-5.1.23-bin.jar jboss-eap-6.0/modules/com/mysql/5.1.23/

Perceba que o arquivo mysql-connector-java-5.1.24-bin.jar foi copiado para o “main” pois ele será a nossa versão principal. O próximo passo é cria o arquivo module.xml para cada versão:

Versão 5.1.19

Crie o arquivo jboss-eap-6.0/modules/com/mysql/5.1.19/module.xml e adicione o seguinte conteúdo:

<?xml version="1.0" ?>

<module xmlns="urn:jboss:module:1.1" name="com.mysql" slot="5.1.19">

 <dependencies>
   <module name="javax.api"/>
   <module name="javax.transaction.api"/>
 </dependencies>

 <resources>
   <resource-root path="mysql-connector-java-5.1.19-bin.jar"/>
 </resources>

</module>

Versão 5.1.23

Crie o arquivo jboss-eap-6.0/modules/com/mysql/5.1.23/module.xml e adicione o seguinte conteúdo:

<?xml version="1.0" ?>

<module xmlns="urn:jboss:module:1.1" name="com.mysql" slot="5.1.23">

 <dependencies>
   <module name="javax.api"/>
   <module name="javax.transaction.api"/>
 </dependencies>

 <resources>
   <resource-root path="mysql-connector-java-5.1.23-bin.jar"/>
 </resources>

</module>

Versão 5.1.24 “main”

Crie o arquivo jboss-eap-6.0/modules/com/mysql/main/module.xml e adicione o seguinte conteúdo:

<?xml version="1.0" ?>

<module xmlns="urn:jboss:module:1.1" name="com.mysql" slot="main">

 <dependencies>
   <module name="javax.api"/>
   <module name="javax.transaction.api"/>
 </dependencies>

 <resources>
   <resource-root path="mysql-connector-java-5.1.24-bin.jar"/>
 </resources>

</module>

No arquivo standalone.xml ou domain.xml (profile) adicone as seguintes propriedades no  <subsystem xmlns=”urn:jboss:domain:ee:1.1″>:

<global-modules>
  <module name="com.mysql" slot="5.1.19"/>
  <module name="com.mysql" slot="5.1.23" />
</global-modules>

No datasource faça a referência do slot desejado como por exemplo:

<drivers>
  <driver name="mysql" module="com.mysql:5.1.23"/>
</drivers>
<datasource jndi-name="java:/MySQLDS" pool-name="MySQLDS-Pool" enabled="true" use-java-context="true">
  <connection-url>jdbc:mysql://localhost:3306/jbossdb</connection-url>
  <driver>mysql</driver>
  ....

Faça o deploy da aplicação testdriver e verifique o driver que está sendo utilizado no momento pela aplicação:

1drivers-pack12drivers-pack2Eu não consegui alterar o módulo on-the-fly  utilizando o CLI ( talvez tenha esqueçido algo =/ ):

/subsystem=datasources/jdbc-driver=mysql:write-attribute(name=driver-module-name,value=com.mysql:5.1.19)
 {
  "outcome" => "failed",
  "failure-description" => "JBAS014639: Attribute driver-module-name is not writable",
  "rolled-back" => true
 }

Então editei manualmente e testei:

<drivers>
  <driver name="mysql" module="com.mysql:5.1.19"/>
</drivers>

drivers-pack3

Para utilizar o módulo principal deixe o driver configurado da seguinte maneira:

<drivers>
   <driver name="mysql" module="com.mysql"/>
</drivers>

drivers-pack4

Por hoje é só!

Grande Abraço

Mauricio Magnani Jr

Criptografando Senhas e Informações Sensíveis no JBoss AS 7.1.3 ( JBoss EAP 6.0.1 )

Postado em Atualizado em

increase-internet-security

Olá amigos,

O JBoss AS 7 possui um utilitário JBOSS_HOME/bin/vault.sh que permite criptografar informações sensíveis como senhas e amazenar em encrypted keystores.

Por exemplo, atualmente temos  o datasource do MySQL com a senha configurada em plaintext:

<datasource jndi-name="java:/MySQLDS" pool-name="MySQLDS-Pool" enabled="true" use-java-context="true">
  <connection-url>jdbc:mysql://localhost:3306/jbossdb</connection-url>
  <driver>mysql-connector-java-5.1.22-bin.jar</driver>
  <security>
     <user-name>root</user-name>
     <password>123456</password>
  </security>
</datasource>

Para realização dos testes de lookup no Datasource java:/MySQLDS  estou utilizando a aplicação dstest.war Perceba que fiz o lookup e realizei um select com sucesso!

1

testds2testds-select

Objteivo é criptografar o atributo passsword utilizando o JBOSS_HOME/bin/vault.sh  e realizar novamente os testes.

Como pré-requisito precisamos de uma Java Keystore e consequentemente que um JDK esteja configurado corretamente pois vamos utilizar o Keytool  para gerar a keystore.

O primeiro passo é criar um diretório para armazenar a keystore.

Crie um diretório chamado vault:

  mkdir  /home/jboss/vault

Navegue até o diretório criado e execute os comandos para gerar a keystore:

  keytool -genkey -alias vault -keystore vault.keystore -keyalg RSA -keysize 1024 -storepass 123456 -keypass 123456 -dname "CN=Mauricio Magnani,OU=JBossDivers,O=JBoss,L=Sao Paulo,ST=SP,C=BR"

Execute o script JBOSS_HOME/bin/vault.sh e siga os procedimentos informados:

[jboss@localhost /]$ ./usr/local/jboss/7.1.3/jboss-eap-6.0/bin/vault.sh
=========================================================================

JBoss Vault

JBOSS_HOME: /usr/local/jboss/7.1.3/jboss-eap-6.0

JAVA: java

VAULT Classpath: /usr/local/jboss/7.1.3/jboss-eap-6.0/modules/org/picketbox/main/*:/usr/local/jboss/7.1.3/jboss-eap-6.0/modules/org/jboss/logging/main/*:/usr/local/jboss/7.1.3/jboss-eap-6.0/modules/org/jboss/common-core/main/*:/usr/local/jboss/7.1.3/jboss-eap-6.0/modules/org/jboss/as/security/main/*
=========================================================================

**********************************
****  JBoss Vault ********
**********************************
Please enter a Digit::   0: Start Interactive Session  1: Remove Interactive Session  2: Exit
0
Starting an interactive session
Enter directory to store encrypted files (end with either / or \ based on Unix or Windows:/home/jboss/vault/
Enter Keystore URL:/home/jboss/vault/vault.keystore
Enter Keystore password:
Enter Keystore password again:
Values match
Enter 8 character salt:12345678
Enter iteration count as a number (Eg: 44):40

Please make note of the following:
********************************************
Masked Password:MASK-EjBzy4a2hjd
salt:12345678
Iteration Count:40
********************************************

Enter Keystore Alias:vault
Obtained Vault
Initializing Vault
Apr 2, 2013 11:29:38 PM org.picketbox.plugins.vault.PicketBoxSecurityVault init
INFO: PBOX000361: Default Security Vault Implementation Initialized and Ready
Vault is initialized and ready for use
Handshake with Vault complete
Please enter a Digit::   0: Store a password  1: Check whether password exists  2: Exit
0
Task:  Store a password
Please enter attribute value: jboss
Please enter attribute value again: jboss
Values match
Enter Vault Block:MySQLDS
Enter Attribute Name:password
Attribute Value for (MySQLDS, password) saved

Please make note of the following:
********************************************
Vault Block:MySQLDS
Attribute Name:password
Shared Key:YjVmN2RjMTgtOTIxNi00MDA4LWI5NmEtMThjYTRhOTc4NzY2TElORV9CUkVBS3ZhdWx0
Configuration should be done as follows:
VAULT::MySQLDS::password::YjVmN2RjMTgtOTIxNi00MDA4LWI5NmEtMThjYTRhOTc4NzY2TElORV9CUkVBS3ZhdWx0
********************************************

Please enter a Digit::   0: Store a password  1: Check whether password exists  2: Exit

Abaixo de <extensions> adicione os atributos da keytore para o vault:

<vault>
  <vault-option name="KEYSTORE_URL" value="/home/jboss/vault/vault.keystore"/>
  <vault-option name="KEYSTORE_PASSWORD" value="MASK-EjBzy4a2hjd"/>
  <vault-option name="KEYSTORE_ALIAS" value="vault"/>
  <vault-option name="SALT" value="12345678"/>
  <vault-option name="ITERATION_COUNT" value="40"/>
  <vault-option name="ENC_FILE_DIR" value="${user.home}/vault/"/>
</vault>

Perceba que os valores utilizados na configuração do vault são os mesmos gerados pelo JBOSS_HOME/bin/vault.sh.

Agore adicione a senha criptografada no Datasource, deixando-o como abaixo:

<datasource jndi-name="java:/MySQLDS" pool-name="MySQLDS-Pool" enabled="true" use-java-context="true">
   <connection-url>jdbc:mysql://localhost:3306/jbossdb</connection-url>
   <driver>mysql-connector-java-5.1.22-bin.jar</driver>
   <security>
      <user-name>root</user-name>
      <password>${VAULT::MySQLDS::password::YjVmN2RjMTgtOTIxNi00MDA4LWI5NmEtMThjYTRhOTc4NzY2TElORV9CUkVBS3ZhdWx0}</password>
   </security>
</datasource>

Inicie o JBoss e faça os testes novamente com a aplicação dstest.war.

1

testds2dstest-final


Perceba que conseguimos realizar o lookup e o select com sucesso utilizando o password criptografado com o utilitário  JBOSS_HOME/bin/vault.sh.

O objetivo do post foi mais prático mesmo mas se desejar informações detalhadas aconselho a documentação oficial do produto:

Espero que tenha ajudado 🙂

Aquele Abraço

Configurando Ambiente de Produção no JBoss AS 7.1.3 (JBoss EAP 6.0.1) – Parte 3

Postado em Atualizado em

Olá amigos,

Hoje vamos continuar a configuração do ambiente criado nos posts anteriores:

No post anterior nós terminamos a configuração do balanceamento de carga. Hoje vamos aprender como adicionar recurso de cluster ao nosso ambiente. Portanto se sua intenção não é a de utilizar recursos clusterizados aguarde a próxima parte e pule essa etapa.

A arquitetura  do JBoss AS 7 foi totalmente redesenhada para que seus recursos possam ser iniciados de modo concorrente ou sob demanda. Anteriormente nós definimos que o profile utilizado seria o ha (high availability) que possui tecnologias (subsystems) para utilização de cluster. Nesse perfil podemos encontrar o JGroups que é a tecnologia utilizada no JBoss para fazer a comunicação entre os nós do cluster e replicar o estado dos mesmos (entre muitas outras coisas). No post anterior deployamos uma aplicação  web que não estava preparada para cluster portanto tais recursos não foram ativados. Utilizando a tag <distributable/> no web.xml estamos “basicamente” habilitando clusterização para nossa aplicação.

<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">

   <distributable/>

</web-app>

Mais informações podem ser encontradas na documentação: https://docs.jboss.org/author/display/AS71/AS7+Cluster+Howto

Então ao deployarmos uma aplicação <distributable/> os recursos de cluster serão carregados automaticamente. É claro que existem outras configurações a serem feitas mas podem variar conforme o ambiente de cada administrador. Por exemplo, por padrão é utilizado UDP para comunicação entre os “nós do cluster”, então é necessário que o ambiente esteja preparada para multicast.

Para testes,  basta adicionar uma nova rota:

route add -net 224.0.0.0 netmask 224.0.0.0 dev ethXYZ

Na inicialização basta fazer o binding com a opção -b IP ou -Djboss.bind.address=IP.

Para realização dos testes eu criei uma simples aplicação Web com um contador utilizando um Bean @Stateful.

@Stateful
@SessionScoped
@Clustered
@Named
public class CounterBean implements Serializable{

  private static final long serialVersionUID = -6708383025283195006L;
  private int count;

  public int getCount() {
    return count;
  }

  public void setCount(int count) {
    this.count = count;
  }

  public void increment() {
    count++;
  }
}

Vou deixar o projeto e a aplicação para que vocês possam realizar os testes.  Vamos utilizar a estrutura criada no Configurando Ambiente de Produção no JBoss AS 7.1.3 (JBoss EAP 6.0.1) – Parte 2.

Inicei o Domain Controller (master):

 ./usr/local/jboss/7.1.3/jboss-eap-6.0/bin/domain.sh
 -Djboss.domain.base.dir=/usr/local/jboss/7.1.3/jboss-eap-6.0/master
 -Djboss.host.default.config=host-master.xml
 -Djboss.bind.address=192.168.0.128
 -Djboss.bind.address.management=192.168.0.128

Vamos conectar o primeiro Host Controller 01 (slave01) ao Master:

 ./usr/local/jboss/7.1.3/jboss-eap-6.0/bin/domain.sh
 -Djboss.domain.base.dir=/usr/local/jboss/7.1.3/jboss-eap-6.0/slave01
 -Djboss.host.default.config=host-slave.xml
 -Djboss.domain.master.address=192.168.0.128
 -Djboss.bind.address.management=192.168.0.140
 -Djboss.bind.address=192.168.0.140
 -Djboss.server.name=server-one

Observe os logs no Domain Controller e perceba que o Host Controller 01 se conectou do Domain:

JBAS010918: Registered remote slave host "slave01", JBoss EAP 6.0.1.GA (AS 7.1.3.Final-redhat-4)

Agora temos um Domain Controller e um Host Controller com Server ( instância JBoss) chamada server-one. Vamos realizar o deploy da aplicação  cluster-example.war que responderá no contexto cluster (http://192.168.0.140/cluster/). Acesse a interface web no endereço http://192.168.0.128:9990/console/ e será solicitado usuário e senha. Podemos utilizar o usuário jboss e a senha 123456 criadas nas etapas anteriores. Para realizar o deploy siga os passos baixo:

deploy1

deploy2

deploy3

deploy4

deploy5

Ao realizarmos o assign da aplicação o serviço de cluster é inicializado:

[Server:server-one] 20:48:49,847 INFO  [stdout] (ServerService Thread Pool -- 66)
[Server:server-one] 20:48:49,847 INFO  [stdout] (ServerService Thread Pool -- 66) -------------------------------------------------------------------
[Server:server-one] 20:48:49,848 INFO  [stdout] (ServerService Thread Pool -- 66) GMS: address=slave01:server-one/ejb, cluster=ejb, physical address=192.168.0.140:55200
[Server:server-one] 20:48:49,853 INFO  [stdout] (ServerService Thread Pool -- 66) -------------------------------------------------------------------
[Server:server-one] 20:48:49,884 INFO  [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.cluster-example.war:main" from Service Module Loader
[Server:server-one] 20:48:50,117 INFO  [stdout] (ServerService Thread Pool -- 67)
[Server:server-one] 20:48:50,122 INFO  [stdout] (ServerService Thread Pool -- 67) -------------------------------------------------------------------
[Server:server-one] 20:48:50,122 INFO  [stdout] (ServerService Thread Pool -- 67) GMS: address=slave01:server-one/web, cluster=web, physical address=192.168.0.140:55200
[Server:server-one] 20:48:50,123 INFO  [stdout] (ServerService Thread Pool -- 67) -------------------------------------------------------------------

Acesse a url http://192.168.0.14o/cluster ( url do balanceador Apache nada tem a ver com a localização da instância JBoss)  e perceba que a aplicação iniciará a contagem.

app

Agora conecte o segundo Host Controller 02 (slave02) ao Master:

 ./usr/local/jboss/7.1.3/jboss-eap-6.0/bin/domain.sh
 -Djboss.domain.base.dir=/usr/local/jboss/7.1.3/jboss-eap-6.0/slave02
 -Djboss.host.default.config=host-slave.xml
 -Djboss.domain.master.address=192.168.0.128
 -Djboss.bind.address.management=192.168.0.117
 -Djboss.bind.address=192.168.0.117
 -Djboss.server.name=server-two

Pare a instância instância server-one.

stop01

stop02

A  aplicação passará a reponder no server-two pela mesma url http://192.168.0.14o/cluster e a contagem será continuada da onde havia parado no server-one. Com isso percebemos que o estado da nossa aplicação foi replicado entre os nós.

deployfinal

Por hoje é isso ai galera. Na próxima parte vamos habilitar o SSL para o Mod Cluster e realizar algumas configurações de segurança no JBoss.

Abraços!

Proteja-se: Evitando Session Fixation Attack no JBoss EAP 6

Postado em Atualizado em

Hackers-Attack

Olá amigos,

Session Fixation Attack pode ser feito através de um link enviado pelo atacante para a vítima com um ID de Sessão ( no nosso caso o Jsessionid ) incluso, essa técnica é conhecida como client-side scripting (existem muitas outras). Então a vitima se autentica e logo após isso o atacante pode ter acesso total a conta  já que para a aplicação Web o atacante é o mesmo usuário que está autenticado pois o ID de Sessão é válido.

Fazendo uma rápida pesquisa no google encontrei algumas pessoas se aproveitando desse tipo de vulnerabilidade aplicando outras técnicas:

A solução para evitar todo esse problema é bem simples: basta que o  ID de Sessão seja alterado após a autenticação!

No JBoss EAP 6 abaixo de </extensions> (standalone.xml, etc ou domain.xml) adicione a seguinte propriedade:

<system-properties>
      <property name="org.apache.catalina.authenticator.AuthenticatorBase.CHANGE_SESSIONID_ON_AUTH" value="true"/>
</system-properties>

Isso vai garantir com que um novo ID de Sessão seja alterado após a autenticação do usuário!

Quem curtiu dá joinha ai!!!!!! haha brincadeirinha 😛

Se você nao entendeu nada do que eu disse ( eu escrevo meio esquisito ) consulte os links abaixo:

Se eu falei alguma bobagem ou deixei de falar alguma coisa, por favor deixe nos comentários que verifico na mesma hora!

Espero que tenha ajudado!!!

Aquele Abraço!

Alterando o Local de Gravação dos Logs no JBoss AS 7.1.2 (JBoss EAP 6)

Postado em

Olá amigos,

Hoje precisei alterar o local em que os logs do JBoss estavam sendo gravados e achei bem simples.

Se estiver utilizando o JBoss em modo Standalone edite o arquivo  ${JBOSS_HOME}/standalone/configuration/standalone.xml e  em Domain edite o arquivo ${JBOSS_HOME}/domain/configuration/domain.xml. Logo abaixo da tag </extensions> adicione um novo path como abaixo:

<paths>
   <path name="jbossdivers.log.dir" path="/home/jboss/logs"/>
</paths>

Agora adicione um novo handler ao subsystem logging como abaixo:

<file-handler name="SERVER" autoflush="true">
   <formatter>
     <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
   </formatter>
   <file relative-to="jbossdivers.log.dir" path="server-request.log"/>
</file-handler>

E adicione também uma category. Não esqueça de alterar a category para o pacote do seu projeto.

<logger category="br.com.jbossdivers.example" use-parent-handlers="false">
  <level name="DEBUG"/>
  <handlers>
    <handler name="SERVER"/>
  </handlers>
 </logger>

Salve as alterações e reinicie o JBoss. Verifique em /home/jboss/logs se o log foi gerado corretamente.

Você pode ainda usar o path  relative-to=”jbossdivers.log.dir”  em outros handlers como por exemplo o FILE.

Espero que tenha ajudado.

Abs

Fonte: https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/sect-Filesystem_Paths.html

Configurando Ambiente de Produção no JBoss AS 7.1.3 (JBoss EAP 6.0.1) – Parte 2

Postado em Atualizado em

Olá amigos,

Continuando o post anterior hoje nós vamos iniciar a configuração do JBoss AS 7.1.3 (JBoss EAP 6). Muitos pessoas que acompanham o blog devem estar se perguntando o por que de utizar o JBoss EAP 6 e não o JBoss AS 7.1.1.
Isso é bem simples!! O JBoss EAP 6 é baseado no JBos AS 7.1.1. Nessa versão Enterprise todos os bugs que tínhamos no JBoss AS 7.1.1 já estão corrigidos e futuramente todas essas correções irão voltar para a versão comunidade que virá a ser o JBoss AS 7.2.0. Para baixar o JBoss EAP é necessário ter uma conta em http://access.redhat.com/.Você pode criar uma conta de testes e ter acesso por 30 dias. Se decidir comprar o produto terá a sua disposição um dos melhores suportes do mundo (sem propaganda). Caso nao tenha grana como eu, você ainda poderá continuar utilizando o JBoss EAP 6 só que você estará por sua conta. O JBoss EAP 6 não “trava” depois de 30 dias, você apenas perde o direito de baixar os produtos e acessar a base de conhecimento disponibilizada no portal.

Você pode ainda compilar o JBoss EAP 6 🙂

Para facilitar vou deixar aqui os binários do JBoss EAP 6 que vamos utilizar nesse post.

Para colocar o JBoss AS 7, como serviço no Linux, existem alguns pré-requisitos. Em hipótese alguma inicie o JBoss utilizando o usuário root, pois a plataforma Java oferece APIs para execução de códigos nativos do sistema operacional e mecanismos de gerenciamento remoto. No Linux crie um usuário com privilégios adequados para iniciar o serviço do JBoss. Já no Windows crie um usuário com poderes administrativos, mas com privilégios reduzidos.

Incialmente vamos criar um grupo:

  groupadd jboss

Adicione o usuário:

  useradd -s /bin/bash -d /home/jboss -m -g jboss jboss

Vamos baixar o JBoss no diretório tmp:

 cd /tmp
 wget https://www.dropbox.com/s/nbij0z285i376h2/jboss-eap-6.0.1.zip

Crie a estrutura de diretórios para armazenar o JBoss:

 mkdir /usr/local/jboss
 chown jboss:jboss /usr/local/jboss
 su jboss
 mkdir /usr/local/jboss/7.1.3
 cd /usr/local/jboss/7.1.3
 unzip /tmp/jboss-eap-6.0.1.zip

Como boa prática antes de iniciar o JBoss pela primeira vez, faça uma cópia do perfil Domain ou Standalone  e renomeie com algum nome objetivo:

 $ cp –Rap /usr/local/jboss/7.1.3/jboss-eap-6.0/domain  /usr/local/jboss/7.1.3/jboss-eap-6.0/example-domain

Uma vez instalado é fortemente aconselhável iniciar o JBoss AS para verificar se existe alguma incompatibilidade com a arquitetura do JDK utilizado ou até mesmo se a memória disponibilizada é suficiente.

 ./usr/local/jboss/7.1.3/jboss-eap-6.0/bin/domain.sh
 -Djboss.domain.base.dir=/usr/local/jboss/7.1.3/jboss-eap-6.0/example-domain/

 JBoss EAP 6.0.1.GA (AS 7.1.3.Final-redhat-4) started in 29604ms - Started 162 of 245 services (82 services are passive or on-demand)

Para esse post eu decidi utilizar duas instâncias para testarmos o balanceamento de carga com o mod_cluster. Inicialmente vamos subir o Domain Controller  e depois vamos conectar dois Host Controller com uma Instância  JBoss em cada.

ModoDomain

Como já configuramos o Apache Web Server com SSL e Mod Cluster agora devemos criar e configurar o nosso Domain. Um Domain nada mais é que um conjunto de instãncias JBoss (Não tem nada a ver com cluster).  Existem alguns elementos envolvidos nessa arquitetura por exemplo o modelo Domain oferece:

  • Gerenciamento Centralizado;
  • Configuração Centralizada;
  • Deploy Centralizado;
  • Manutenção Centralizada;

A única diferença entre o modo Standalone e modo Domain é a capacidade de gerenciamento. Características como clustering, high availability,  fail-over e outros recursos do Java EE  estão disponíveis nos dois modelos!

Domain Controller  é o ponto central de controle onde está toda política de gerenciamento de todos os servidores. Nele estão as configurações de todas as instâncias que participam do domínio. O Domain Controller é basicamente um processo Host Controller onde dependendo da arquitetura se torna o Domain Controller.

Host Controller  também coordena as instâncias do domain. Por exemplo, ele é o responsável por fazer algo semelhando ao Farm Deployment(nao existe nessa versão), ou seja ele distribui o arquivo deployado para todas as instâncias do domain.

Server são as instâncias em si, onde estão as aplicações deployadas. Um ponto importante é que cada server é  um processo Java.

Continuando a configuração, execute  add-user.sh e siga as instruções como abaixo:

[jboss@localhost /]$ ./usr/local/jboss/7.1.3/jboss-eap-6.0/bin/add-user.sh

What type of user do you wish to add?
a) Management User (mgmt-users.properties)
b) Application User (application-users.properties)
(a): a

Enter the details of the new user to add.
Realm (ManagementRealm) : ManagementRealm
Username : jboss
Password :
Re-enter Password :
About to add user 'jboss' for realm 'ManagementRealm'
Is this correct yes/no? yes
Added user 'jboss' to file '/usr/local/jboss/7.1.3/jboss-eap-6.0/standalone/configuration/mgmt-users.properties'
Added user 'jboss' to file '/usr/local/jboss/7.1.3/jboss-eap-6.0/domain/configuration/mgmt-users.properties'
Is this new user going to be used for one AS process to connect to another AS process?
e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
yes/no? yes
To represent the user add the following to the server-identities definition &lt;secret value=&quot;MTIzNDU2&quot; /&gt;

Foi adicionado um usuário chamado jboss com a senha 123456 para que ser utilizado na conexão entre o Host Controller e o Domain Controller.

Crie três novos perfis baseados no modo Domain e renomeie como abaixo:

$ cp -Rap /usr/local/jboss/7.1.3/jboss-eap-6.0/domain  /usr/local/jboss/7.1.3/jboss-eap-6.0/master
$ cp -Rap /usr/local/jboss/7.1.3/jboss-eap-6.0/domain  /usr/local/jboss/7.1.3/jboss-eap-6.0/slave01
$ cp -Rap /usr/local/jboss/7.1.3/jboss-eap-6.0/domain  /usr/local/jboss/7.1.3/jboss-eap-6.0/slave02

Como vimos anteriormente todas as configurações e gerenciamento é realizado de forma centralizada no Domain Controller. Quando for necessário adicionar um novo grupo de servidores, configurar logs, criar datasources, alterar portas entre outras coisas, tudo isso deverá ser feito no domain.xml do Domain Controller que no nosso caso será chamado de master. Sendo assim todas as nossas instâncias JBoss usufruirão das configurações realizadas para o Domain ou para o Server Group em questão.

A primeira coisa a ser feita é definir qual o conjunto de tecnologias (subsystems) serão utilizadas na aplicação. Isso pode variar conforme os requisitos de cada sistema. Um conjunto de tecnologias (subsystems) no JBoss 7 é chamado de profile.

 <profile name="full-ha">

O JBoss AS 7 possui 4 profiles por padrão: “default”, “full”, “ha”, “full-ha” , mas nada impede de nós copiarmos qualquer um deles e renomeá-los conforme nossos requisitos.  No Java EE 6 foi introduzido o conceito de Profiles, onde pode-se criar um subconjunto de tecnologias presentes na spec  Java EE ou até mesmo adicionar novas definidas pela JCP (Java Community Process).

Mais informações: https://community.jboss.org/wiki/JavaEE6UtilizandoWebProfileOuFullProfileNoJBossAS7

Nós vamos utilizar o profile ha pois se precisarmos utilizar o recurso de cluster vamos conseguir por que essa tecnologia (subsystem JGroups) já está pré configurada. Nós definimos que vamos utilizar um profile quando vamos criar um Grupo de Servidores: Server Group. Um server group nada mais é que um agrupamento de instâncias JBoss. Nessa arquitetura vamos utilizar apenas um server group. Isso pode ser definido na tag <server-groups> no domain.xml do master (Domain Controller). Crie um Server Group chamado grupo-apps que utilize o profile ha:

vim /usr/local/jboss/7.1.3/jboss-eap-6.0/master/configuration/domain.xml

Deixe-o como abaixo:

<server-groups>
 <server-group name="grupo-apps" profile="ha">
  <jvm name="default">
    <heap size="1303m" max-size="1303m"/>
    <permgen max-size="256m"/>
  </jvm>
  <socket-binding-group ref="ha-sockets"/>
  </server-group>
</server-groups>

No profile ha especificamente no subsystem web adicione o atributo instance-id:

<subsystem xmlns="urn:jboss:domain:web:1.2" default-virtual-server="default-host" instance-id="${jboss.server.name}" native="false">

O instance-id será passado como parâmetro na inicialização do Host Controller.

É de grande importância remover  a “silent authentication” do CLI.  Por padrão nenhum password é solicitado para usuários “locais” do CLI deixando assim uma porta para pessoas mal intencionadas realizarem o que desejarem com nossas instâncias JBoss.  Para remover essa autenticação remova as tags  <local default-user=”$local” /> e  <local default-user=”$local” allowed-users=”*” /> nos arquivos:

vim /usr/local/jboss/7.1.3/jboss-eap-6.0/master/configuration/host-master.xml
vim /usr/local/jboss/7.1.3/jboss-eap-6.0/slave01/configuration/host-slave.xml
vim /usr/local/jboss/7.1.3/jboss-eap-6.0/slave02/configuration/host-slave.xml

Agora devemos configurar a autenticação dos Host Controllers. Anteriormente adicionamos um usuário chamado jboss e nesse processo foi gerado um hash com um tag <secret value=”MTIzNDU2″ />. Essa tag será utilizada nos nossos Host Controllers para se autenticarem no Domain Controller.

Edite o arquivo:

vim /usr/local/jboss/7.1.3/jboss-eap-6.0/slave01/configuration/host-slave.xml

Adicione a tag <secret value=”MTIzNDU2″ /> em <server-identities> removendo a que estava configurada por default.

<server-identities>
   <secret value="MTIzNDU2" />
</server-identities>

Em  <domain-controller> na tag  <remote> adicione a propriedade username:

<domain-controller>
   <remote host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm" username="jboss"/>
</domain-controller>

Na tag <servers> é onde estão de fato as nossas instâncias JBoss. Quando criamos uma novo  <server> estamos criando uma nova instância JBoss.  Isso é algo similar ao copiarmos um profile all, production, web, etc em versões anteriores.

Conforme definimos o Host Controller 01 conterá apenas uma instância JBoss chamada server-one. Deixe o <servers> como abaixo:

<servers>
  <server name="server-one" group="grupo-apps">
  </server>
</servers>

Definimos que a instância JBoss server-one fará parte do Server Group “grupo-apps”.

Para finalizar na tag  <host> adicione o name slave01.

  <host name="slave01" xmlns="urn:jboss:domain:1.3">

Repita os procedimentos realizados no slave01 para o slave02 alterando apenas o nome do servidor que será server-two  e  do <host> será slave02.

No meu ambiente possuo 3 servidores:

  • Domain Controller + Apache Web Server: 192.168.0.128
  • Hostr Controller 01: 192.168.0.140
  • Hostr Controller 02: 192.168.0.117

Inicie o Domain Controler (master) utilizando os seguintes parâmetros:

./usr/local/jboss/7.1.3/jboss-eap-6.0/bin/domain.sh
-Djboss.domain.base.dir=/usr/local/jboss/7.1.3/jboss-eap-6.0/master
-Djboss.host.default.config=host-master.xml
-Djboss.bind.address=192.168.0.128
-Djboss.bind.address.management=192.168.0.128

Verifique  o log:

JBAS015874: JBoss EAP 6.0.1.GA (AS 7.1.3.Final-redhat-4) (Host Controller) started in 6181ms - Started 11 of 11 services (0 services are passive or on-demand)

O Domain Controller foi iniciado com sucesso!

Vamos conectar o primeiro Host Controller 01 (slave01) ao Master. Inicie o Perfil slave01 utilizando os seguintes parâmetros:

./usr/local/jboss/7.1.3/jboss-eap-6.0/bin/domain.sh
-Djboss.domain.base.dir=/usr/local/jboss/7.1.3/jboss-eap-6.0/slave01
-Djboss.host.default.config=host-slave.xml
-Djboss.domain.master.address=192.168.0.128
-Djboss.bind.address.management=192.168.0.140
-Djboss.bind.address=192.168.0.140
-Djboss.server.name=server-one

Agora observe os logs no Domain Controller e perceba que o Host Controller 01 se conectou do Domain:

JBAS010918: Registered remote slave host "slave01", JBoss EAP 6.0.1.GA (AS 7.1.3.Final-redhat-4)

Abra também o Mod Cluster Manager em http://192.168.0.140/mod_cluster-manager e veja que a nossa primeira instância já apareceu:

node01

Inicie o Host Controller 02 (slave02) utilizando os seguintes parâmetros:

./usr/local/jboss/7.1.3/jboss-eap-6.0/bin/domain.sh
-Djboss.domain.base.dir=/usr/local/jboss/7.1.3/jboss-eap-6.0/slave02
-Djboss.host.default.config=host-slave.xml
-Djboss.domain.master.address=192.168.0.128
-Djboss.bind.address.management=192.168.0.117
-Djboss.bind.address=192.168.0.117
-Djboss.server.name=server-two

Agora observe novamente os logs no Domain Controller e perceba que o Host Controller 02 se também conectou:

JBAS010918: Registered remote slave host "slave02", JBoss EAP 6.0.1.GA (AS 7.1.3.Final-redhat-4)

Novamente no Mod Cluster Manager agora temos as nossas duas instâncias:

node2

Para testar o Balanceamento vamos fazer o deploy da aplicação SystemProps que pode ser baixada  aqui.

Para fazer o deploy conecte do domain controller utilizando o CLI:

$ ./usr/local/jboss/7.1.3/jboss-eap-6.0/bin/jboss-cli.sh -c --controller=192.168.0.128:9999
Authenticating against security realm: ManagementRealm
Username: jboss
Password:
[domain@192.168.0.128:9999 /]

Faça o deploy da aplicação:

[domain@192.168.0.128:9999 /] deploy /home/jboss/jboss-files/systemprops.war --server-groups=grupo-apps

A aplicação foi deployada para as instâncias do server group ( server-one e server-two).

Acesse a url do nosso balanceador e verifique se a aplicação está disponível: http://192.168.0.140/systemprops/

server-2

Perceba que estamos no server-two. Entao para testarmos o funcionamento do balanceador vamos parar o server-two e quando tentarmos um novo acesso seremos redirecionados para o server-one.

No CLI execute o seguinte comando para parar o server-two:

[domain@192.168.0.128:9999 /] /host=slave02/server-config=server-two:stop
{
"outcome" => "success",
"result" => "STOPPING"
}

Acesse novamente a aplicação: http://192.168.0.140/systemprops/

server-1

Perceba que agora estamos no server-one.

Nosso objetivo foi alcançado 🙂

Na proxima parte vamos aprender como tornar esse ambiente clusterizado!

Abraços

Resolvendo WARNING JBOSS_HOME may be pointing to a different installation

Postado em

Olá amigos,

Hoje pela manhã estava realizando o deploy de uma aplicação utilizando o CLI:

/app/server/jboss-eap-6.0/bin/jboss-cli.sh --connect --controller=177.45.111.78:9999 --user=myuser '--password=mypass' '--commands=undeploy myapp.war --server-groups=my-server-group, deploy /home/desenv/.jenkins/jobs/myapp-qa/workspace/target/myapp.war --server-groups=my-server-group'
WARNING JBOSS_HOME may be pointing to a different installation - unpredictable results may occur.

Observem que o seguinte Warning ocorreu:

JBOSS_HOME may be pointing to a different installation - unpredictable results may occur.

Isso indica que a variável de ambiente JBOSS_HOME não está definida ou está errada. Para resolver esse Warning basta configurar corretamente a variável  JBOSS_HOME.

Windows:

  set PATH=c:\home\user\jboss7\

Linux:

  export PATH=/home/user/jboss7/

É isso ai galera.

Abraços

Snapshots e Backup das Configurações no JBoss AS 7.1.2 ( JBoss EAP 6 )

Postado em Atualizado em

Olá amigos,

Uma das grandes vantagens do JBoss AS 7 é a de que podemos ter todo o “desenvolvimento” das nossas configurações á nossa disposição sempre que precisarmos.  Caso ocorra algum problema com as novas configurações podemos restaurar um snapshot, pegar uma configuração salva em determinado dia e horário ou até mesmo restaurar a configuração inicial. Todas esses snapshots e configurações  no standalone mode ficam salvas no diretório $JBOSS_HOME/standalone/configuration/standalone_xml_history.

standalone.initial.xml – Esse arquivo contém a configuração original do servidor. Esse arquivo nunca é substituído pelo JBoss. Se você precisar restaurar a configuração inicial basta substituir o standalone.xml atual pelo standalone.initial.xml, evitando a necessidade de baixar o JBoss novamente.

standalone.boot.xml – Esse arquivo contém a configuração da última inicialização bem sucedida do servidor. Ele é  substituído toda vez que o servidor iniciar com êxito. Se você quer desfazer todas as alterações da  atuais, basta substituir
o arquivo standalone.xml pelo standalone.boot.xml.

standalone.last.xml – Esse arquivo contém a ultima configuração válida, “comitada” no servidor de aplicação.

Diretório current –  Esse diretório é utilizado como pasta temporária para armazenar alterações na configuração na sessão atual. Toda alteração realizada no arquivo standalone.xml resultará em um arquivo standalone.v[n].  Quando o JBoss é reiniciado, esses arquivo são movidos para diretórios “timestamped” com a data e horário das últimas alterações. Esses diretórios “timestamped” são “rotated” a cada 30 dias pelo JBoss.

Diretório snapshot – O  CLI  tem a capacidade de criar snapshots das configurações que estamos realizando no JBoss. Esses snapshots ficam armazenados do diretório snapshot. Então sempre que desejar guardar a configuração atual faça um snapshot utilizando o CLI. Veja:

 :take-snapshot

O retorno será:

 {
  "outcome" => "success",
  "result" => "/home/mmagnani/Development/jboss-final/jboss-as-7.1.1.Final/standalone/configuration/standalone_xml_history/snapshot/20121116-135607885standalone.xml"
 }

Você pode verificar a lista de snapshots disponíveis usando o comando:

 :list-snapshots

Ele retornará o snapshot que criamos acima:

 {
  "outcome" => "success",
  "result" => {
  "directory" => "/home/mmagnani/Development/jboss-final/jboss-as-7.1.1.Final/standalone/configuration/standalone_xml_history/snapshot",
  "names" => ["20121116-135607885standalone.xml"]
 }

Se desejar excluir o snapshot execute:

 :delete-snapshot(name="20121116-135607885standalone.xml")

Listando os comandos no CLI não encontrei nenhum que realize o restore do snapshot.

Espero que tenha ajudado.

Abraços