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.

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.