Archive for the ‘problemas e soluções’ Category

Usando YUM após fim do ciclo de atualizações do sistema operacional

Hoje eu estava fazendo a instalação de um servidor CentOS 5 e precisei adicionar alguns novos pacotes à instalação realizada. Então me deparei com erros do tipo:

YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
 Eg. Invalid release/

O ciclo de vida de atualizações do produto chegou ao fim, impedindo novas atualizações (o que pra mim não era problema!) e instalações de novos pacotes (este sim era problema!).

Talvez você se pergunte: Mas por que ainda usar uma versão tão antiga? Por que não atualizar para uma versão recente? Respondo: as vezes, por questões de compatibilidade e homologação de softwares, preciso manter versões antigas de linux!

Pesquisando um pouco descobri que a própria distribuição mantém uma base de repositórios antigos na estrutura do YUM, o que eu não sabia!

Talvez a maneira mais elegante ou indicada seria adicionar um apontamento para a versão 5.11 no arquivo /etc/yum.repos.d/CentOS-Vault.repo e fazer referência à este repositório na chamada do YUM. Mas isto tornaria a chamada do YUM menos prática! Então optei por realizar os passos indicados no fórum do CentOS, neste tópico [1]. Abaixo faço um resumo dos tópicos para futuras consultas.

  1. editar o arquivo /etc/yum.repos.d/CentOS-Base.repo
    1. em [base]
      1. comentar “mirrorlist=…”
      2. “baseurl=” já estava comentada pra mim
      3. adicionar nova entrada “baseurl=http://vault.centos.org/5.11/os/$basearch/”
    2. em [updates]
      1. adicionar “enabled=0”
    3. em [extras]
      1. igual a passos 1 e 2 de [base]
      2. adicionar nova entrada “baseurl=http://vault.centos.org/5.11/extras/$basearch/”

Com estas modificações, pude fazer uso do YUM sem maiores dificuldades!

 

Referências:

[1] yum fails – https://www.centos.org/forums/viewtopic.php?t=62106

Anúncios

Conectando OpenVPN com WatchGuard Firebox

Recentemente um cliente optou por trocar sua estrutura de segurança baseada em software livre por um produto “caixa preta” chamado WatchGuard Firebox (ou algo do tipo).

Como interajo apenas com servidores da rede interna, não conheço muito bem a estrutura de borda.

Até então utilizava-se um servidor OpenVPN e minha conexão era feita através de um cliente do OpenVPN.

Como temos um serviço de monitoramento através deste túnel, fiquei preocupado, pois o cliente apontou apenas um software para Windows como conexão. Posteriormente descobrimos que além de Windows, existe cliente para Mac e também para softwares com suporte a arquivos .ovpn!

Apenas fiz alguns ajustes no arquivo de configuração (para passar pela autenticação de usuários automaticamente), conforme sugestão apontada aqui [1] e a conexão via cliente OpenVPN foi estabelecida sem maiores dificuldades!

 

Referências:

[1] Connecting Linux to WatchGuard Firebox SSL (OpenVPN client) – http://jochen.kirstaetter.name/blog/linux/connecting-linux-to-watchguard-firebox-ssl.html

[Resolvido!] HAVP – Could not fork daemon

Esta semana eu estava implementando uma necessidade nova, solicitada por um cliente e precisei reproduzir o ambiente dele em uma máquina virtual para testes. Assim, instalei um Slackware mínimo, Clamav, HAVP e um Squid para criar um servidor proxy com análise de vírus do conteúdo.

Não entrarei em detalhes sobre esta configuração pois existem diversos tutoriais a respeito. O próprio HAVP oferece uma documentação detalhada sobre o assunto.

No entanto, ao tentar iniciar o serviço do HAVP, eu me deparava com o seguinte erro:

Starting HAVP Version: 0.92
Could not fork daemon
Exiting..

Infelizmente eu não encontrava detalhes suficientes para decifrar o mistério. Todos os fóruns e soluções que encontrei apontavam para o caminho de conflito de portas, o que não era o meu caso.

Em geral, eu não uso o Clamav como daemon, mas resolvi iniciá-lo neste formato para traçar um caminho diferente. Eis então que a “luz se fez”!!! Através do log do Clamav encontrei uma esperança na seguinte mensagem:

ERROR: daemonize() failed: Cannot allocate memory

Como eu tinha montado uma máquina virtual modesta, afinal era apenas para um teste local, aloquei apenas 512 MB de RAM. Infelizmente, como vim a descobrir, não era o suficiente para minhas necessidades.

Desliguei a máquina, reservei 1 GB de RAM, inicializei novamente o servidor virtual e voilà, o HAVP inicializou sem problemas!

Espero que este pequeno relato auxilie mais alguém, pois acabei dispendendo várias horas até encontrar esta solução!

Copiando arquivos com erros na leitura

Dizem que a necessidade é a mãe da criatividade. Ela é também a responsável por acumularmos conhecimentos a cada problema enfrentado! Pois esta semana passei por mais uma destas situações.

Analisando os logs de um servidor Linux, encontramos problemas com alguns setores de disco. Sendo um disco ligado em RAID, tratamos de identificar o disco com problema (ou discos) e, por segurança, resolvemos migrar os dados para um outro conjunto de discos. Embora apenas  um dos discos tenha acusado erro, aparentemente os setores defeituosos se replicaram para o segundo disco (que ainda não descartamos estar com problemas também). Poderia não ser tão problemático se os setores defeituosos não estivessem no arquivo de uma máquina virtual, essencial para a empresa.

Murphy nunca nos deixa desamparados! :p

Tentamos fazer a cópia deste arquivo com problemas de diferentes formas (scp, rsync, cp) e em nenhum dos casos obtivemos sucesso. Como se tratavam de 200GB de dados, cada tentativa tomava um precioso tempo. Tomava mais tempo pelo fato de, ao identificar erros de setor, o disco gastar mais tempo tentando corrigir a leitura antes de acusar erro (o famigerado “Input/output error”) e interromper a cópia!

Nosso tempo se esgotando e a esperança de conseguir copiar o arquivo diminuindo. Foi então que resolvi buscar uma maneira de copiar o arquivo, ignorando os erros de leitura. Encontrei em [1] um método através do simples e prático dd. Agora era só esperar o tempo de cópia e torcer para que a máquina virtual subisse sem problemas.

Já era dia claro quando concluímos a cópia, testamos a máquina virtual e, aparentemente, a situação estava normalizada!

Para consultas futuras, deixo o comando utilizado aqui registrado:

$ dd if=arquivo_com_erro of=arquivo_novo conv=noerror,sync

Referências:

[1] Not a complete failure – Benoît Joossen – http://aeroquartet.com/wordpress/2012/06/06/how-to-copy-a-file-with-io-errors/