Ferramentas/Programas/Comandos de Trabalho

Ferramentas/Programas/Comandos de Trabalho

Para agilizar e conseguir trabalhar é necessário o uso de algumas ferramentas para teste.

Fazemos a instalação de ambientes de testes para testarmos alguma funcionalidade antes de colocar em ambiente de produção.
Portanto, explorarei aqui, algumas dessa ferramentas e comandos uteis no dia a dia:]
1) Testar aplicações – Glassfish
Para testar uma nova aplicação é confortável ter um servidor de aplicações que você tenha completo e total controle, fazendo a sua instalação em sua máquina de uso diário.
Um container que recomendo é o Glassfish, ele é completo, possui diversas ferramentas para o administrador e é de fácil gerencia.
Após a descompactação, use o comando seguinte dentro do diretório do glassfish:/bin/asadmin start-domain, para iniciar o glassfish

e /bin/asadmin stop-domain, para finalizar o glassfish

Acesse a console de administração pela URL: http://localhost:4848/

2) Mudar o grupo do usuário no Linux/Unix

Muitas vezes é necessário que o usuário de administração copie arquivos, edite e apague diretórios, por exemplo. Para esses casos é importante ter direito na máquina que estamos usando.

Melhor que ficar dando direito a todo o momento, é mudar o grupo do seu usuário para o mesmo grupo do usuário privilégiado, tipo o root.

Use o comando: sudo vi /etc/passwd e edite a linha correspondente ao usuário que você usa para a administração. É claro que para isso é necessário que você possua o direito de sudo, ou seja, esteja listado na lista de sudors.

Vá até a linha do usuário e faça a alteração do 4o. campo, referente ao número do grupo.

3) Ter o linux sob o Windows

Muitas vezes temos uma máquina Windows e precisamos de comando o shell. Para resolver esses impasses instale o Cygwin sob sua máquina Windows e desfrute de todas as funcionaliades do linux sob o ambiente Windows.

Essa é uma alternativa superior à usar o Putty, pois assim você terá realmente o linux e seu poderoso shell usada em sua máquina local, sem depender de rede ou de configurações extras nos servidores linux ou unix da sua organização.

Baixe pela url: http://cygwin.com/

Perder acesso ao Jenkins/Hudson

Perder acesso ao Jenkins/Hudson

Um problema recorrente quando na configuração de segurança do Jenkins/Hudson é perder acesso a ele.
Vários sites, inclusive o próprio site do Jenkins, fala em ir até o diretório do Jenkins e alterar a configuração do arquivoconfig.xml e alterar o userSecutity para false:

<userSecurity>false</useSecurity>

Isto está completamente correto, no entanto, quando fui procurar o arquivo ele não estava lá no diretório do Jenkins, já que eu instalei usando o .WAR.
Se for o seu caso, o arquivo fica em outro lugar.

O arquivo config.xml está localizado no diretório home do usuário usado para carregar o jenkins.
Vá até lá e faça a alteração que está escrita acima, alterar o config.xml e mudar a tag userSecutity  para false.
Aproveite e apague as configurações dos usuários que você porventura já tenha criado.
Após você conseguir o acesso novamente, terá q refazer a configuração destes usuários.
Esta é a forma mais segura. No entanto, faça os seus testes 😀

Mudar entre logins de usuário – Unix/Linux

Mudar entre logins de usuário – Unix/Linux

É possível que você precise logar como um usuário diferente para realizar configurações e testes.
Quanto isso acontece não é necessário sair da sua conta, basta apenas usar:

sudo -u usuario bash

onde usuario é o login do usuário que você quer mudar e bash é o nome do shell que você deseja usar para esta nova conexão.

JBoss 5 com várias (múltiplas) instâncias

JBoss 5 com várias (múltiplas) instâncias

Recentemente precisei configurar o JBoss para funcionar com várias instâncias em uma mesma máquina.

Antes de inciarmos precisamos verificar os seguintes requisitos:

– Não podemos carregar múltiplas instâncias usando os mesmos arquivos de configuração;
– Devemos ter a certeza que todos os serviços de todas as instâncias estão usando portas diferentes entre si;
– Determinar como iremos parar cada um dos serviços.

Para realização desta tarefa, vamos seguir a seguinte estrutura:

1) Configuração das múltiplas instâncias
2) Uso de portas diferentes para serviços distintos entre as instâncias
3) Como parar as instâncias individualmente
4) Testando a aplicação

Vamos começar do início, claramente.

1) Configuração das múltiplas instâncias

Para a configuração dos arquivos em múltiplas instâncias é algo de cópia de arquivos.
Vá até o diretório /jboss/server, lá encontrará vários diretórios e entre eles o default.
Copie este diretório várias vezes quantas forem as instâncias que vc precisar.
Escolhi o diretório default pois este é o mais completo e que normalmente funciona com todas as aplicações. Se vc tem que fazer a configuração que estou explicando aqui, deve entender a diferença entre o minimal, default, web…

Pois bem, altere o nome do diretório para o nome da instância que vc quer, por exemplo, producao, treinamento, homologacao…

2) Uso de portas diferentes para serviços distintos entre as instâncias

O JBoss 5 e até versões anteriores possuem arquivos para a configuração das portas de acesso aos serviços. Geralmente o arquivo a ser configurado está no diretório /jboss/server/default/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml e melhor, normalmente já vem configurado com uma configuração padrão e mais 4 configurações.

Quando se carrega o JBoss normalmente ele utiliza a configuração padrão e assim não é necessário fazer nenhum tipo de configuração a mais. No nosso caso será necessário uma chamada diferente quando na execução do JBoss.

No arquivo referido, o bindings-jboss-beans.xml, possuímos no total 5 configurações, a padrão e mais outras quatro que podemos usar. Neste exemplo não iramos utilizar todas, mas se for necessário apenas acrescente novas configurações conforme explico neste exemplo.

No arquivo bindings-jboss-beans.xml existe:

 <!– Provides management tools with a ProfileService ManagementView 
        interface to the SBM and its components –>
   <bean name=”ServiceBindingManagementObject” 
         class=”org.jboss.services.binding.managed.ServiceBindingManagementObject”>
         
      <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”/>
               <inject bean=”Ports04Bindings”/>
            </set>
         </parameter>
         
         <!– Base binding metadata that is used to create bindings for each set –>
         <parameter><inject bean=”StandardBindings”/></parameter>
         
      </constructor>
   </bean>

que é onde os binds são criados.

Logo abaixo temos

<!– The ports-default bindings are obtained by taking the base bindings and adding 0 to each port value  –>
   <bean name=”PortsDefaultBindings”  class=”org.jboss.services.binding.impl.ServiceBindingSet”>
      <constructor>
         <!–  The name of the set –>
         <parameter>ports-default</parameter>
         <!– Default host name –>
         <parameter>${jboss.bind.address}</parameter>
         <!– The port offset –>
         <parameter>0</parameter>
         <!– Set of bindings to which the “offset by X” approach can’t be applied –>
         <parameter><null/></parameter>
      </constructor>
   </bean>

para a configuração da porta padrão, a configuração padrão conforme vimos anteriormente.

Depois existe a configuração da primeira configuração das portas:

 <!– The ports-01 bindings are obtained by taking the base bindings and adding 100 to each port value –>
   <bean name=”Ports01Bindings”>
      <constructor>
         <!–  The name of the set –>
         <parameter>ports-01</parameter>
         <!– Default host name –>
         <parameter>${jboss.bind.address}</parameter>
         <!– The port offset –>
         <parameter>100</parameter>
         <!– Set of bindings to which the “offset by X” approach can’t be applied –>
         <parameter><null/></parameter>
      </constructor>
   </bean>

Esta configuração diz que o nome dela é ports-01 e que deve usar o endereço padrão e acrescentar 100 à esta porta para a sua inicialização. O que quer dizer isso?

Simples, o JBoss já vem configurado para que você use-o com várias instâncias e essa configuração diz que você pode usá-la e o JBoss irá acrescentar 100 ao endereço padrão das portas dos serviços que a instância requisitar. Portanto, quando você carregar usando esta configuração o JBoss carrega e as portas entre as instâncias não irão ter conflitos.

Bom, para usar a configuração, carregue o JBoss usando o comando:

run -c intância -Djboss.service.binding.set=ports-01

Onde instância é o nome da instância que criou no passo1 e port-01 é o nome que vc pode escolher dentro do arquivo bindings-jboss-beans.xml. Importante salientar que é possível usar duas vezes em  uma mesma máquina o mesmo nome nem da instância, nem do ports-01.

3) Como parar as instâncias individualmente

Após tudo isso feitos, agora como iremos para o serviço?
Usando o comando:

shutdown -s localhost:1099 -S

onde localhost é o nome da máquina que precisamos parar o serviço, 1099 é o número da porta onde foi carregado o JMX da instância. A porta 1099 é para a configuração padrão, para a configuração ports-01 é só adicionar 100, portanto 1199 e assim por diante.

4) Testando a aplicação

Agora é a parte boa, testar e ter certeza que tudo está certo. Como tudo funciona de primeira, essa é a melhor parte 😀
Vamos lá.

Para saber a porta da aplicação é só fazer o mesmo esquema de acrescentar 100 a porta padrão da sessões anteriores, portanto, use o seguinte link para acessar a sua aplicação:

http://localhost:8180/aplicacao

Onde, localhost é o nome da sua máquina, 8180 é a porta para acessar o serviço. Neste exemplo, 8180 é para a configuração ports-01, se estiver usando a configuração padrão, vc já sabe: 8080. E aplicacao  nome da sua aplicação.

Feito.

Tudo é simples quando se sabe fazer 😉

Até a próxima.

Problemas com o Patch no SVN

Problemas com o Patch no SVN

Um problema comum  na aplicação de patchs no SVN é criar patchs usando o windows e aplicar em máquinas Unix/Linux. Normalmente este problema é resolvido sozinho pelas novas versões do patch do svn.
Ou usando o comando dos2unix para retirar o CR do arquivo.

No entanto, outro problema pode acontecer e que não é resolvido usando o dos2unix ou tenha relação com o caracter especial CR.

Um problema que apareceu comigo mesmo já tendo funcionado o patch várias vezes antes sem problemas.
Foi uma mensagem com algo do tipo:

Hunk #1 FAILED at 933.
Hunk #2 FAILED at 964.

O comando de patch que eu usava era este:

patch -p0 < arquivo.patch

e funcionava corretamente. Depois de várias tentativas e erros, estou usando hoje o comando:

patch -p0 -l –binary –posix –verbose < arquivo.patch

Tente e veja se irá funcionar.

Está funcionando corretamente quando uso máquinas windows para gerar o patch e o meu servidor está usando o linux para rodar a máquina virtual onde aplico o patch.

Transferência de Arquivos: SSH, SCP, authorized_keys…

Transferência de Arquivos: SSH, SCP, authorized_keys…

Recentemente comecei a configuração de uma novo servidor e precisei usar o SCP.
Utilizo o Jenkins, antigo Hudson, para execução dos meus scripts.
Quando tentei fazer o SCP, que usa o SSH, não funcionou.
Então para que isso funcionasse é necessário a configuração do Sistema Operacional (SO) para funcionar sem ser necessário o uso de senhas, já que eu preciso usar via comando script.

Para que isso seja possível é necessário verificar:
1) O usuário do servidor de origem possui direito no diretório onde está o arquivo de origem;
2) O usuário que será usado para autenticar no servidor destino deve possuir direito no diretório do servidor destino;
3) Possuir o SCP e SSH instalados em ambos os servidores.

Com isto pronto, e normalmente, todos os servidores vem com isso funcionando, vamos começar a configuração.

Serão necessários os seguintes passos para a execução:

a) Acessar o servidor de origem via SSH;
b) Criar o par de chaves assimétricas (chave pública e privada);
c) Colocar a chave pública no servidor de destino;
d) Realizar a cópia do arquivo.

Isto posto, vamos aos seguintes passos:

a) Acessar o servidor de origem via SSH

Acesse o servidor de origem, por exemplo, usando o seguinte comando:

ssh expert@10.1.1.2

onde SSH é o comando para acessar o servidor através de um canal seguro, expert é o nome do usuário e 10.1.1.2 é o endereço do servidor onde está o arquivo que preciso passar ao outro servidor.

b) Criar o par de chaves assimétricas (chave pública e privada)

Vamos criar o par de chaves que irá capacitar aos servidores transitar arquivos entre eles, mas apenas em um sentido. Se for necessário o contrário, também será necessário configurar o outro servidor para isto.

No servidor de origem, vamos executar o comando:

ssh-keygen -t rsa

Irá ser pedido, uma palavra senha, mas como queremos que não seja necessário senha, pressione ENTER para todas as perguntas. Assim serão criadas as chaves públicas e privadas.

c) Colocar a chave pública no servidor de destino

Vamos agora copiar o arquivo de chave pública para o servidor de destino.
Logue o servidor de origem, por exemplo:

ssh expert@10.1.1.2

Vá até o home do usuário:

cd ~

entre no diretório .ssh

copie o arquivo id_rsa.pub para a sua máquina.

Agora vá até o servidor de destino, por exemplo:

ssh expert@10.1.1.3

Vá ao diretório home:

cd ~

entre no diretório .ssh

copie o arquivo id_rsa.pub para este diretório.

Renomeie o arquivo id_rsa.pub para authorized_keys* Este ponto é muito importante para o funcionamento.
Caso já exista este arquivo será necessário fazer o append neste arquivo.

d) Realizar a cópia do arquivo

Se tudo correu bem agora é só realizar a copia do arquivo usando um canal seguro sem o uso de senha.

Para tanto, logue no servidor de origem:

ssh expert@10.1.1.2

e execute o comando para a cópia do arquivo desejado, por exemplo:

scp log.txt expert@10.1.1.3:/proj1

onde SCP é o programa que realiza a cópia do arquivo usando SSH, log.txt é o arquivo que preciso cópia, expert é o nome do usuário que eu configurei o home no servidor de destino, 10.1.1.3 é o servidor de destino e proj1 é o diretório que eu quero o arquivo fique armazenado.

Tomara que com você tenha dado certo na primeira tentativa 😀

Pronto, agora você tem os servidores configurados para a transferência segura entre os dois servidores sem a necessidade colocar senha em nenhum lugar.

Isto é bastante útil para a automatização de tarefas. Você poderá criar tarefas agendadas de cópia entre os dois servidores sem a necessidade de escrever a senha nos arquivos de scripts o que poderia causar problemas na segurança do seu serviço.

Aquele abraço.

Experts Programming

Image

Após muito tempo fazendo códigos e procurando soluções entre os amigos, os conhecidos e também na internet, hoje tenho uma boa ideia sobre como é difícil achar uma solução real para problemas não triviais.

Este é objetivo do blog, colocar bons códigos, soluções de problemas que atrapalham os mais experientes no ramo e principalmente, ter tudo isso on-line e para fácil e rápido acesso.

Não trabalho na área de design nem fotografia, então aquela besteirada de câmera isso ou fonte aquilo, você não encontrará aqui. Só pra constar.

Zx Spectrum