Dicas

Root login no Oracle Solaris 11

Recentemente criei uma máquina virtual x86 para rodar o Oracle Solaris 11 usando o VirtualBox. A ideia é utilizar essa VM como ambiente de prova de conceito para produtos da linha Oracle Fusion Middleware. Como todo sistema Unix-like o Solaris possui algumas restrições de segurança que impossibilita o acesso de root via SSH. Minha primeira tentativa foi editar a configuração do serviço sshd e habilitar a flag ‘PermitRootLogin’. Entretanto, isso não basta para que o login de root funcione no Solaris.

Após algumas “googladas” descobri que é necessário realizar os seguintes ajustes na configuração do S.O:

  • Habilitar o login de root no serviço sshd. Edite o arquivo /etc/ssh/sshd_config
# Are root logins permitted using sshd.
# Note that sshd uses pam_authenticate(3PAM) so the root (or any other) user
# maybe denied access by a PAM module regardless of this setting.
# Valid options are yes, without-password, no.
PermitRootLogin yes
  • Comentar a propriedade ‘CONSOLE’ no arquivo /etc/default/login
# If CONSOLE is set, root can only login on that device.
# If the specified device is /dev/console, then root can also log into
# any of the currently enabled /dev/vt/# virtual terminal devices.
# Comment this line out to allow remote login by root.
#
#CONSOLE=/dev/console
  • Editar a configuração do módulo PAM. Edite o arquivo /etc/pam.conf

Adicione a seguinte linha no fim do arquivo:

sshd-kbdint   account   required   pam_unix_account.so.1

Adicionado em 18/01/2013.

  • Para permitir o login de root pela console/shell da própria máquina é necessário alterar a role na qual o root está associado. Execute o seguinte comando como root.
root@solaris11:~# rolemod -K type=normal root
Found user in files repository.
UX: rolemod: root is currently logged in, some changes may not take effect until next login.

Agora tente executar o login como root pela console da máquina/VM (sem ser via ssh).

obs: obviamente, por questões de segurança, essa configuração não é interessante em ambiente de produção.

😉

Dicas

Bash Script: substituindo um texto em vários arquivos

Neste post quero compartilhar um bash script que criei para um necessidade bastante comum em ambientes Unix Like.

Necessidade:

“alterar um texto em vários arquivos de uma única vez”

Situação hipotética:

“vários arquivos texto (xml, properties, txt etc) espalhados dentro de um diretório raiz contendo um determinado termo (palavra, path de arquivo, propriedade etc)”

Esse tipo de situação é bastante comum no dia a dia de um administrador de sistemas e servidores. A abordagem da utilização de um script para automatizar esse tipode tarefa é bastante utilizada em ambientes baseados em Unix que possuam um shell com suporte a qualquer linguagem de script (bash, ksh, python, ruby etc).

No meu caso implementei um script bash para execução em sistemas Linux. Minha necessidade inicial foi alterar o caminho da instalação do Oracle Weblogic Application Server – WLS. A instalação do WLS escreve o caminho do diretório raiz da instalação em vários arquivos de configuração (arquivos .properties e .xml) e scripts de gerenciamento (arquivos .sh) espalhados por toda a sua estrutura de diretórios. Caso seja necessário alterar o caminho raiz da instalação do WLS, você tem duas alternativas: 1) instalar novamente o WLS; 2) alterar o path da instalação em todos os arquivos de configuração.

No meu caso meu WLS foi instalado em ‘/opt/Oracle/Middleware‘, porém precisei mudar o caminho raiz para ‘/opt/Oracle/Middlware11g.

Pois bem, meu scritpt recebe como entrada os seguintes parâmetros:

  1. path: diretório raiz onde os arqivos se encontram
  2. file pattern name: nome do arquivo a ser alterado (geralmente um coringa ‘*.’)
  3. old text: texto a ser alterado
  4. new text: novo texto

Quando executar o script sem parâmetros um pequeno help será exibido sugerindo um exemplo de uso.

# ~/replaceText.sh
invalid call!
 usage: ./replaceText <path> <file pattern name> <old text> <new text>
NOTES:
 1) don't use the pattern '*', instead specify a file extension (eg: '*.sh', '*.txt', '*.properties', '*.xml')
 2) for text containing special chars you have to scape them with '\'
eg: ./replaceText "/opt/Oracle/Middleware" "*.xml" "Oracle\/Middleware\/" "Oracle\/Middleware11g\/"

Ao executar o script com todos os parâmetros o diretório raiz (primeiro argumento) será percorrido e, para cada arquivo encontrado (obedecendo o padrão informado no segundo argumento), será necessário confirmar a alteração.

# ~/replaceText.sh /opt/Oracle/Middleware/ "*.properties" "Oracle\/Middleware\/" "Oracle\/Middleware11g\/"
 alterar o arquivo: /opt/Oracle/Middleware/user_projects/domains/cluster-replicated-domain/init-info/tokenValue.properties
 deseja continuar? ([S]im/[n]ao/[t]odos) S
 substituir [Oracle\/Middleware\/] por [Oracle\/Middleware11g\/]
 diff /opt/Oracle/Middleware/user_projects/domains/cluster-replicated-domain/init-info/tokenValue.properties /opt/Oracle/Middleware/user_projects/domains/cluster-replicated-domain/init-info/tokenValue.properties.BAK
 ----------------------------------------
 21c21
 < @DOMAIN_HOME=/opt/Oracle/Middleware11g/user_projects/domains/cluster-replicated-domain
 ---
 > @DOMAIN_HOME=/opt/Oracle/Middleware/user_projects/domains/cluster-replicated-domain
 24c24
 < @USERDOMAIN_HOME=/opt/Oracle/Middleware11g/user_projects/domains/cluster-replicated-domain
 ---
 > @USERDOMAIN_HOME=/opt/Oracle/Middleware/user_projects/domains/cluster-replicated-domain
 ----------------------------------------

No exemplo acima alterei todos os arquivos de propriedades (*.properties). Observe que existe a opção de alterar todos os arquivos encontrados de uma única vez. Basta selecionar a opção [a]ll quando for solicitada a confirmação. Observe também que o script faz um backup de todos os arquivos alterados (.BAK).

Ok. Após todo esse bla bla bla o código do script:

#!/bin/bash

DIR_PATH=$1
FILE_SEARCH_PATTERN=$2
OLD_STRING=$3
NEW_STRING=$4

LAST_REPLY="S"

askToContinue(){
   if [[ ! $LAST_REPLY =~ ^[Aa]$  ]]
   then
      read -p "continue? ([Y]es/[n]o/[A]ll) " -n1
      echo

      LAST_REPLY=$REPLY
      if [[ ! $REPLY =~ ^[Yy]$ ]]
      then
         continue
      fi
   fi
}

usage(){
   echo
   echo -e "\r invalid call!"
   echo -e "   usage: ./replaceText    "
   echo
   echo -e "\r NOTES:"
   echo -e "\r\t 1) don't use the pattern '*', instead specify a file extension (eg: '*.sh', '*.txt', '*.properties', '*.xml')"
   echo -e "\r\t 2) for text containing special chars you have to scape them with '\'"
   echo
   echo -e "   eg: ./replaceText \"/opt/Oracle/Middleware\" \"*.xml\" \"Oracle\\/Middleware\\/\" \"Oracle\\/Middleware11g\\/\""
   echo
   exit
}

[[ ! "$#" = "4" ]] && usage

for file_name in `find "$DIR_PATH" -type f -name "$FILE_SEARCH_PATTERN"`
do
  #Testa se o arquivo contem o texto a ser substituido
  file $file_name | grep -i "text" > /dev/null
  [[ "$?" -eq "1"  ]] && continue
  grep $OLD_STRING $file_name > /dev/null
  [[ "$?" -eq "1"  ]] && continue

  echo -e "\r\r\r changes the file: $file_name \r"
  askToContinue

  echo -e "\t replace [$OLD_STRING] by [$NEW_STRING] \r"

  if [ -d $DIR_PATH  ];
  then
     sed -i.BAK -e "s/${OLD_STRING}/${NEW_STRING}/g" $file_name

     echo -e "\t\t diff $file_name $file_name.BAK"
     echo -e "\r ----------------------------------------"
     diff $file_name $file_name.BAK
     echo -e "\r ----------------------------------------"
  else
     echo -e "\r $PATH_DIR does not exists!"
     exit
  fi

done

Eu usei o script sem problemas em um Linux Fedora (Linux Red Hat based). Mas creio que funcionará sem grandes problemas em qualquer Unix com um shell Bash.

Abraço 😉

Dicas, Java, JVM, Tools

Colhendo envidências em caso de erro (crash) na JVM

Sabe aquela situação em que a equipe responsável pelo ambiente de produção chega pra você e diz: “o servidor X está caindo toda hora… já olhamos os recursos da máquina (rede, memória, cpu e disco), inclusive o log do servidor, mas não identificamos nada…”

Isso mesmo! Há casos em que seu processo caiu sem dar explicações e sem deixar pista alguma.

Já tive a oportunidade de passar por essa situação algumas vezes… Trata-se de uma situação complicada, pois quase sempre ocorre em um momento e ambiente crítico onde o tempo para solução é o seu pior inimigo. Bem, após bater cabeça com esse tipo de problema, posso afirmar que a melhor opção é preparar o seu ambiente para colher algumas evidências quando o problema voltar a ocorrer. Como quase tudo na TI esse tipo de situação é inevitável. Softwares e Hardware podem falhar por “n” motivos. Nesse post deixo algumas dicas que podem lhe ajudar na investigação “pós queda” de um processo Java (rodando em cima de uma JVM).

Existem dois casos em que é bastante comum o processo da JVM cair:

  1. insuficiência de memória
  2. algum erro fatal da jvm

O tipo de erro relacionado à insuficiência de memória é o conhecido por OutOfMemoryError (OOM) e ocorre devido à algum memory leak no código da aplicação. Para analisar a causa desse tipo de erro é interessante ter em mãos o estado (snapshot) do Heap da JVM no momento em que o erro ocorre. Para isso é necessário habilitar alguns parâmetros na JVM conforme abaixo:

Geração do Dump (formato hprof) do Heap da JVM.

Adicionar as seguintes propriedades no comando que inicia a JVM. Caso o comando seja parametrizado em um arquivo de configuração, basta usar uma variável JAVA_OPTS como no exemplo abaixo.

# HeapDUMP e Core DUMP
# registra a data e hora de início do processo
DATE_START=`date  +%d-%m-%Y-%k%M`

# Habilita a geração do DUMP de memória (HPROF)
JAVA_OPTS="$JAVA_OPTS -XX:+HeapDumpOnOutOfMemoryError "
JAVA_OPTS="$JAVA_OPTS -XX:OnOutOfMemoryError=<execute algum comando shell aqui (ex: 'kill -9%p')> "
JAVA_OPTS="$JAVA_OPTS -XX:HeapDumpPath=/var/log/jvm/heapdump_$DATE_START.hprof "

 

NOTA:

  • Recentemente encontrei uma implementação alternativa à opção ‘-XX:OnOutOfMemoryError’ interessante. Vale a pena testar!
  • o arquivo de dump no formato .hprof pode ser aberto com os utilizatários jVisualvm (fornecido pelo JDK Sun/Oracle Hotspot) ou Eclipse Memory Analizer (MAT). É necessário que a versão e arquitetura do JDK utilizado na análise dump seja idêntica à JVM utilizada pelo servidor de aplicação onde o erro ocorreu.

O segundo caso de erro pode ser gerado por algum problema entre a JVM e SO. Um caso típico é o erro de estouro de pilha conhecido como StackOverflowError. Esse tipo de erro pode ocorrer caso a aplicação utilize algum tipo de loop infinito ou uma recursividade muito profunda. O tamanho da pilha alocada pela JVM durante a criação de uma thread java é de 1024KB (1mb) em um sistema Linux x64. É possível alterar esse valor para mais ou para menos a depender da necessidade da aplicação. O parâmetro da JVM -Xss:<n>k altera o valor da pilha, sendo que <n> é um valor inteiro.

Geração do coredump (threads e memória) da JVM

Adicionar as seguintes propriedades no comando que inicia a JVM.

# Habilita a geração de coredump (BIN)
JAVA_OPTS="$JAVA_OPTS -XX:OnError='gcore -o /var/log/jvm/jboss_PID%p_$DATE_START.coredump %p' "
JAVA_OPTS="$JAVA_OPTS -XX:ErrorFile=/var/log/jvm/hs_err_jboss_PID%p_$DATE_START.log "

NOTAS:

  • A opção ‘-XX:OnError‘ é executada apenas quando  a causa raiz do erro for Nativo devido a alguma falha fora da JVM – JVM Native Crash.
  • o arquivo de dump no formato hprof pode ser aberto com os utilizatários jVisualvm (fornecido pelo JDK) ou Eclipse Memory Analizer (MAT).  É necessário que a versão e arquitetura do JDK utilizado na análise dump seja idêntica à JVM utilizada pelo servidor de aplicação onde o erro ocorreu.
  • Para que o comando gcore (invocado pela JVM após o evento de erro) funcione é necessário que o pacote gdb (A GNU source-level debugger for C, C++, Fortran and other languages) esteja devidamente instalado no Sistema Operacional.

Uma opção mais eficiente para geração de Dumps em JVMs com Heaps grandes (>= 2gb)

Utilizar o jmap em heap muito grandes pode demorar horas para concluir. Em algumas situações é necessário reiniciar o serviço imediatamente após a falha para diminuir o tempo em que ele fica fora do ar. Uma excelente alternativa é descrita nesse artigo disponível no Blog da Atlassian: So you want your JVM’s heap…

Gerando dumps da JVM em tempo de runtime manualmente

O formato binário pode ser aberto com as ferramentas: jstack (JDK), jVisualVM (JDK), Eclipse MAT ou qualquer outro profiler Java que reconheça o formato HPROF.

jmap -dump:live,format=b,file=jvm_heap.bin <PID>

O formato texto pode ser aberto com as ferramentas: jVisualVM (JDK), IBM Thread Analizer ou qualquer outro profiler Java que reconheça dump de threads Java.

jstack -F -l <PID> > /tmp/jvm_thread.dump

NOTA: os procedimentos acima causam o travamento das threads (equivalente ao efeito Stop The World do FullGC). Portanto utilize com cautela em ambiente de produção!

A análise dos dumps citados neste post é assunto para um novo post. Existem várias ferramentas que podem ser utilizadas na análise. Além das ferramentas é importante ter conhecimento da arquitertura da Máquina Virtual Java utilizada. No caso do dump de memória (heap) é importante conhecer a divisão geracional dos pools de memória da JVM , bem como os vários mecanismos de coleta de lixo. Para o dump de threads é importante conhecer um pouco sobre a execução de threads na plataforma Java: sincronização, pilha de execução, thread monitor, thread status (WAINTING, RUNNING, BLOCKED, etc). Com a ferramenta certa e com um pouco de paciência é possível chegar a tão desejada causa raiz do problema: nome da classe, nome do método, nome da biblioteca ou até mesmo a linha de código que causa ou influência o crash do processo Java.

Dicas, JBoss

Configuração de Portas no JBoss AS 5 (Binding Service)

Serviço de Gerenciamento de Portas

O JBoss AS gerencia o mapeamento de portas utilizadas pelos diversos serviços do servidor através do mecanismo conhecido por Ports Bind.
Esse serviço é configurado no arquivo localizado em

JBOSS_HOME/server/default/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml

E possui o seguinte esquema:

  •  definição do bean ServiceBindingManagementObject que possui o conjunto de portas prédefinido no JBossAS.
 <bean name="ServiceBindingManagementObject"
       class="org.jboss.services.binding.managed.ServiceBindingManagementObject">
  <constructor>
   <parameter>${jboss.service.binding.set:ports-default}</parameter>
   <parameter>
    <set>
     <inject bean="PortsDefaultBindings"/>
     <inject bean="Ports01Bindings"/>
     <inject bean="Ports02Bindings"/>
     <inject bean="Ports03Bindings"/>
    </set>
   </parameter>
   <parameter><inject bean="StandardBindings"/></parameter>
  </constructor>
 </bean>
  • definição do conjunto de portas definidos no bean anterior
 <bean name="PortsDefaultBindings" class="org.jboss.services.binding.impl.ServiceBindingSet">
  <constructor>
   <parameter>ports-default</parameter>
   <parameter>${jboss.bind.address}</parameter>
   <parameter>0</parameter>
   <parameter><null/></parameter>
  </constructor>
 </bean>

Observe que, por padrão, o JBossAS fornece quatro conjunto de portas: PortsDefaultBindings, Ports01Bindings, Ports02Bindings e Ports03Bindings‘.

O que diferencia cada conjunto é o incremento aplicado a cada porta aberta pelos diversos serviços do JBoss. Por exemplo, o Ports01Bindings (ports-01) adiciona 100 ao valor da porta usada pelo conector http do JBoss Web, que por padrão é 8080, mas neste caso (usando o conjunto ports-01) passará a ser 8180.

Caso haja a necessidade de subir mais que quatro instâncias em um mesmo servidor utilizando o mecanismo de Ports Bind, será necessário definir novos conjuntos de portas (ex. Ports04Bindings, Ports05Bindings etc). Porém, é mais conveniente definir um conjunto de portas dinâmico. Dessa forma seu valor de incremento (padrão 100) pode ser parametrizado durante o statup do JBoss. Para isso precisamos fazer duas alterações no arquivo bindings-jboss-beans.xml.

  •  injetar um novo bean que define o conjuto de portas dinâmico/genérico.

Chamaremos esse novo bean de PortsDynaBindings.

<bean name="ServiceBindingManagementObject"
      class="org.jboss.services.binding.managed.ServiceBindingManagementObject">
 <constructor>
  <parameter>${jboss.service.binding.set:ports-default}</parameter>
  <parameter>
   <set>
    <inject bean="PortsDefaultBindings"/>
    <inject bean="Ports01Bindings"/>
    <inject bean="Ports02Bindings"/>
    <inject bean="Ports03Bindings"/>
 <inject bean="PortsDynaBindings"/>
   </set>
  </parameter>
  <parameter><inject bean="StandardBindings"/></parameter>
 </constructor>
</bean>
  •  definir o bean PortsDynaBindings.

Para isso basta copiar a definição do bloco PortsDefaultBindings as propriedades conforme destacado abaixo.

 <bean name="PortsDynaBindings" class="org.jboss.services.binding.impl.ServiceBindingSet">
  <constructor>
   <parameter>ports-dyna</parameter>
   <parameter>${jboss.bind.address}</parameter>
   <parameter>${jboss.bind.offset}</parameter>
   <parameter><null/></parameter>
  </constructor>
 </bean>

Agora para usar esse novo esquema basta informar no arquivo de parâmetros da JVM da instância (run.conf) ou no script de inicialização do JBoss o nome do novo conjunto de portas, bem como a propriedade jboss.bind.offset. Veja como fica no arquivo run.conf:

JAVA_OPTS=$JAVA_OPTS -Djboss.service.binding.set=ports-dyna
JAVA_OPTS=$JAVA_OPTS -Djboss.bind.offset=400

Esses parâmetros podem ser informados direto na linha de comando que inicia o JBoss:

JBOSS_HOME/bin/run.sh -c default -b 0.0.0.0 -Djboss.service.binding.set=ports-dyna -Djboss.bind.offset=400

Dessa forma o JBoss fará o bind das portas incrementando o valor 400 ao valor padrão definido para cada serviço. Por exemplo, o JBoss Web estará acessível através da porta 8480.

Para subir novas intâncias basta alterar o valor do parâmetro jboss.bind.offset

Dicas, JBoss

Configurando JBoss AS 5: principais arquivos de conf.

Se você  está acostumado com a configuração do JBoss AS 4.x (baseado no Microkernel JMX do JBoss) e começou a trabalhar com a versão 5 deve estar, como eu no início, um pouco perdido para encontrar as principais configurações espalhadas pelos novos descritores de serviços (arquivos *-service/bean.xml) na nova estrutura do JBoss AS. Na nova versão boa parte dos arquivos de conf. foram alterados por conta da nova implementação do kernel do JBoss – agora chamado JBoss Microcontainer ou simplesmente JBossMC.

Neste post pretendo mostrar a localização e alguns trechos de configuração para alguns ajustes que considero importantes e que creio fazer parte do dia a dia de um Admin. de JBoss AS. Portanto meu objetivo neste post está longe de percorrer todas as mudanças e configurações da dessa versão do JBossAS!

1) Para começar mostro onde se encontra a configuração do serviço responsável pelo controle transacional do servidor – TransactionManager.

Descritor do serviço: $JBOSS_HOME/server/default/transaction-jboss-beans.xml

Uma propriedade que geralmente precisamos ajustar é o timeout da transação (lembrando que isso altera o timet global do AS)

Trecho de conf:

<property name="transactionTimeout">600</property> <!-- alterado para 10 min (600s). -->
<property name="objectStoreDir">${jboss.server.data.dir}/tx-object-store</property>
<property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property>

2) Agora o mecanismo responsável por “monitorar” o diretório de deploy e fazer o Hot Deployment é o HDScanner.

Descritor do serviço: $JBOSS_HOME/server/default/deploy/hdscanner-jboss-beans.xml

Trecho de conf:

<!-- Hotdeployment of applications -->
 <property name="deployer"><inject bean="ProfileServiceDeployer"/></property>
 <property name="profileService"><inject bean="ProfileService"/></property>
 <property name="scanPeriod">5000</property> <!-- intervalo do scanner -->
 <property name="scanThreadName">HDScanner</property>
 </bean>
...

Para desabilitar o HDScanner basta renomear o descritor hdscanner-jboss-beans.xml para extensão .rej (ou remover o arquivo).

3) Outro importante serviço é o ServiceBindManager. Ele é responsável por configurar as portas de cada connector/invoker de acesso aos serviços/containers internos do JBoss.

Por exemplo o conector HTTP do JBossWEB atende por padrão na porta 8080, quando se deseja subir mais de uma instância num mesmo Host (JBoss em MultiHomed), temos duas alteranativas: (a) definir um endereço  IP para cada instância (run.sh -c default -b x.x.x.x) ou (b) usar o ServiceBindManager para trocar as portas automaticamente durante o startup do AS.

Para informar ao JBoss como ele irá atribuir as portas aos conectores basta informarmos um propriedade à JVM na linha de comanda que inicia o servidor:

./run.sh -c default -Djboss.service.binding.set=ports-01

Em destaque o parâmetro que informa aos ServiceBindManager quel o conjunto de portas será atribuído aos conectores de cada serviço. Neste exemplo (ports-01) irá atribuir a porta 8180 ao conector HTTP por exemplo.

Descritor do serviço: $JBOSS_HOME/server/default/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml

Trecho de conf:

<!-- Provides management tools with a ProfileService ManagementView
     interface to the SBM and its components -->
<constructor>
<!-- The name of the set of bindings to use for this server -->
<parameter>${jboss.service.binding.set:ports-default}</parameter>
<!--  The binding sets -->
<parameter>
<set>
   <inject bean="PortsDefaultBindings"/>
   <inject bean="Ports01Bindings"/>
   <inject bean="Ports02Bindings"/>
   <inject bean="Ports03Bindings"/>
</set>
</parameter>

<!-- Base binding metadata that is used to create bindings for each set -->
<parameter><inject bean="StandardBindings"/></parameter>
</constructor>
</bean>

Como podemos ver, o JBoss fornece 4 conjuntos de portas prontos para uso. Os parâmetros que devem ser informados na propriedade da linha de comando são os seguintes:

  • ports-default
  • ports-01
  • ports-02
  • ports-03

Basicamente o ServiceBindManager adiciona 100 ao número padrão de cada porta, ou seja, para a porta HTTP padrão (8080) quando usamos o conjunto ports-01 ela passará a ser 8180.

4) O serviço de LOG do JBoss continua sendo o Log4j. Nesse serviço geralmente temos a necesside alterar somente o nível (DEBUG,INFO,WARN,ERROR,FATAL) de saída do LOG geral do AS conforme a necessidade do ambiente. Na versão 5 do JBoss podemos informar esse nível de log via uma outra propriedade do sistema passada via linha de comando:

./run.sh -c default -Djboss.server.log.threshold=DEBUG

Neste caso informamos que o nível de log do servidor será DEBUG (geralmente utilizado em ambiente de desenvolvimento).

Outros ajustes do Log4j continuam sendo feitas no descritor do serviço tais como a configuração de appenders e category.

Descritor do serviço: $JBOSS_HOME/server/default/conf/jboss-log4j.xml

Por enquanto ficamos com esses pontos da configuração do JBoss AS. Posteriormente falarei sobre a configuração de classloaders isolados em aplicações WEB.

Abaixo algumas referências ([1] e [2]) sobre as principais mudanças no AS 5 descritas no wiki oficial do JBoss.ORG.

Abraço!

________

Ref.
[1] http://community.jboss.org/wiki/JBossAS50xChangesFAQ
[2] http://community.jboss.org/wiki/JBossAS5FAQ

Dicas, JBoss

Enpcriptando o tráfego entre Apache HTTP e JBoss/Tomcat

Em um ambiente com Apache HTTP Server como front-end de requisições HTTP e JBoss/Tomcat como back-end AS geralmente se usa o mod_jk (protocolo AJP) ou mod_proxy (protocolo HTTP) como mediador da comunicação entre esses dois servidores.
No protocolo AJP os dados são enviados em formato binário do apache para o AS, já o HTTP os dados são enviados em texto claro.

Sempre alguém pergunta se é possível encriptar o tráfego entre o Apache e o JBoss/Tomcat quando este está atrás do Apache HTTP. De acordo com a ref. [1] isso parece ser possível usando mod_proxy no Apache.

Aproveitando o assunto tem uma forma mais fácil (uma alternativa ao mod_jk) de se implementar o load-balance com Apache – JBoss/Tomcat. A partir da versão 2.2.x do Apache HTTP Server a distro padrão vem com o módulo mod_proxy_balancer que permite uma configuração mais simples para load-balancing e também suporta o comunicação pelo protocolo AJP.

No wiki do JBoss existe um roteiro simples e completo para a implementação, configuração e ajuste fino do load-balancing com Apache e JBoss: OptimalMod_jk1.2Configuration

obs: caso queira usar mod_jk use a versão 1.2 A versão mais nova (2.0) foi descontinuada e não é indicada para uso em produção.

A documentação do balancer na Apache não possui muitos exemplos. Depois eu posto um breve howto aqui no blog…

falou!

[1] http://wiki.jboss.org/wiki/EncryptHttpd_TC

Dicas, JBoss

TheServerSide Application Server Matrix

No site TheServerSide existe uma lista com a comparação das principais características dos principais servidores de aplicação do mercado. Achei bem interessante e posto o link aqui:

TheServerSide Application Server Matrix

Poucos da lista são certificados J2EE 1.4,  o JBoss é um deles. Na verdade recentemente o JBoss AS, na versão  5 CR2, se certificou JEE 5. Veja a release notes dessa versão.

Dicas

A difícil tarefa de acordar cedo…

Caracas!

Um dos meus maiores problemas pessoais é a falta de disciplina para acordar cedo. Eu tenho a terrível mania de ficar enrolando na cama por mais 10 minutinhos até entrar em “loop” e levar mais de 1 hora para pular da cama.

Como tudo, hoje em dia, se acha no google resolvi buscar algumas dicas sobre como acordar mais cedo. Para minha surpresa – achava que só acharia “ladainha” – consegui achar boas dicas. Segue alguns links interessantes:

Quase todos fazem referência a este:

Vou seguir as dicas e depois eu digo se obtive sucesso ou não…

[]s