[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!

Anúncios

RedHat 7 (e similares) e novos conceitos/comandos – parte 2

Como relatei na parte 1, houve algumas modificações nesta versão 7 do RedHat (e seus similares). Uma das modificações foi o sistema de inicialização. O, até então predominante, sysVinit foi substituído pelo systemd.

Uma documentação completa sobre o systemd por ser encontrada aqui [1]. Recomendo também a leitura desta documentação [2] elaborada pela comunidade do Arch Linux.

Read more »

RedHat 7 (e similares) e novos conceitos/comandos – parte 1

Esta semana coloquei em produção um servidor Oracle Linux 7, uma das distribuições que se baseia na parte livre do RedHat para criar sua distribuição. Tenho usado tanto o RedHat como o CentOS a bastante tempo. E faz algum tempo, passei a utilizar o Oracle Linux para deixar ambientes homologados, ao gosto do cliente. RedHat e CentOS sempre mantiveram estrutura e comandos idênticos (a diferenciação fica em poucos programas e, essencialmente, na marca, logo, enfim, atributos “visuais”). Com o Oracle Linux, não é diferente.

Por isto, qualquer mudança que o RedHat 7 tenha incorporado, está refletida nas demais distribuições que acompanham a mesma release. Assim, minhas pesquisas, referências e citações, podem apontar para qualquer uma destas distribuições.

Um detalhe que sempre estranhei no instalador da RedHat foi o fato do arquivo /etc/hosts nunca ficar corretamente configurado quando definimos nome de máquina e IP fixo. Nesta minha instalação, o nome da máquina sequer foi ajustado a contento. E fiquei com o nome de localhost definido.

Como faria em qualquer versão anterior, eu apenas corrigiria o arquivo /etc/hosts (que o instalador nunca deixou corretamente ajustado) e o arquivo /etc/sysconfig/network (que nesta versão não foi configurado durante a instalação). Mas para minha surpresa, estas correções não foram suficiente para ajustar o nome do servidor.

Pesquisando, descobri [1] que o processo de ajuste de nomes nesta versão foi modificado. Precisei utilizar um utilitário para ajustar o nome (e acertar os arquivos que já havia acertado previamente):

# nmtui-hostname

Depois disso, é necessário reiniciar o serviço responsável pelo nome do servidor:

# systemctl restart systemd-hostnamed

e, para verificar se as alterações surtiram efeito, basta executar o seguinte comando:

# hostnamectl status

Mas para as alterações surtirem efeito na console, será necessário reiniciar o servidor.

Bom, enfrentei mais algumas novidades nesta versão, mas deixarei isto para outros textos que publicarei em breve. Espero que este breve artigo possa contribuir para algum leitor.

Referências

[1] Change HostName in CentOS 7 / RHEL 7 – IT’zGeek – http://www.itzgeek.com/how-tos/linux/centos-how-tos/change-hostname-in-centos-7-rhel-7.html#axzz3QgXE66S3

[CC] Desabilitar o envio de e-mails na crontab

Recentemente deparei-me com um servidor no qual não era feita uma manutenção preventiva a algum tempo (nem todo cliente opta pelo serviço!). Aproveitando uma necessidade criada, acabei fazendo uma verificação da situação do servidor.

E encontrei vários e-mails destinados ao “root”, ocupando espaço desnecessário (o volume era considerável!). Verifiquei que a maioria dos e-mails eram oriundos de processos executados na crontab.

Como ninguém estava acompanhando estas mensagens (e nem iria), achei mais conveniente desabilitá-las. Procurei então por uma maneira de eliminar o envio de forma geral e não para cada agendamento criado (outra possibilidade).

Na referência abaixo também é citada esta possibilidade individual. Mas fiquei com a opção de fazer isto através da variável MAILTO. Basta adicioná-la (caso não exista na cron) com o valor “zerado”:

MAILTO=""

Referência:

Disable The Mail Alert By Crontab Command – http://www.cyberciti.biz/faq/disable-the-mail-alert-by-crontab-command/

Versão 4 do awk e novas palavras reservadas

Nos primeiros dias de novembro foi lançada uma nova versão do Slackware e alguns dias depois me surgiu a necessidade de instalar um novo servidor firewall. Se fosse outra distro, eu esperaria a estabilização da versão para então instalar. Mas tratando-se do Slackware, tive confiança que poderia colocar em produção uma versão “saída do forno”.

Tenho um roteiro de instalação e algumas rotinas que utilizo de forma padronizada em todos os servidores administrados por mim. Dentre estas rotinas, uma que coleta dados de carga de CPU e memória para o MRTG. Venho utilizando estas rotinas a bastante tempo, baseadas neste artigo do Augusto Campos.

Pois bem, a rotina que coleta dados da CPU funcionava bem até que o Slackware passou a utilizar a versão 4 do awk. A partir desta versão, a palavra “load” (utilizada no script) passou a ser uma palavra reservada para o comando awk. Com isto, a geração de dados sobre CPU e memória deixou de ser gerada!

Como gastei um tempo até que descobrisse o motivo (o “load” como palavra reservada), achei melhor compartilhar com os meus leitores e deixar registrado aqui para referências futuras.

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/

[CC] Imprimindo via CUPS em impressora compartilhada em Windows

Sempre que preciso colocar a sintaxe de usuário e senha no “DeviceURI” do CUPS para imprimir em uma impressora compartilhada no Windows, preciso recorrer à internet para saber as opções corretas.

Para facilitar meu trabalho, resolvi criar aqui um post rápido para deixar documentado estas opções. Outras opções e configurações, por favor, procurem na referência usada ou na própria internet.

DeviceURI para impressão de CUPS em Windows:

smb://servidor/impressora
smb://grupo_de_trabalho/servidor/impressora
smb://usuario:senha@servidor/impressora
smb://usuario:senha@grupo_de_trabalho/servidor/impressora

Referência: SDB:Printing via SMB (Samba) Share or Windows Share – openSUSE – http://en.opensuse.org/SDB:Printing_via_SMB_%28Samba%29_Share_or_Windows_Share

[CC] Estendendo uma partição LVM

Embora seja uma tarefa simples e fácil de executar com LVM, até o momento eu ainda não tinha passado pela necessidade de estender uma partição lógica. Pois agora me surgiu a necessidade e fui executar em ambiente de testes antes de fazer em produção. Realmente é BEM SIMPLES e funcional!

Existem diversos tutoriais, mas acabei usando [1] e [2]. Do primeiro fica a dica que a extensão pode ser feita definindo um novo valor ou então através da adição de espaço que se deseja (e possua). Do segundo fica a dica sobre a execução do “e2fsck”. Nunca é demais conferir! 😉

Então seguem meus passos (para consultas futuras):

# umount /PARTIÇÃO
# lvextend -L<NOVO-TAMANHO><UNIDADE> /dev/<GRUPO-DE-VOLUME>/<NOME-PARTIÇÃO>
# e2fsck -f /dev/<GRUPO-DE-VOLUME>/<NOME-PARTIÇÃO>
# resize2fs -p /dev/<GRUPO-DE-VOLUME>/<NOME-PARTIÇÃO>
# e2fsck -f /dev/<GRUPO-DE-VOLUME>/<NOME-PARTIÇÃO>
# mount /PARTIÇÃO

Referências:
[1] Extending a logical volume – http://www.tldp.org/HOWTO/LVM-HOWTO/extendlv.html
[2] How to resize LVM logical volumes with ext4 as filesystem – http://pubmem.wordpress.com/2010/09/16/how-to-resize-lvm-logical-volumes-with-ext4-as-filesystem/

Resolvendo problema de encaminhamento X11 via SSH

Um recurso muito bom em ambientes gráficos (*nix) é a possibilidade de utilizá-lo em outras máquinas através da rede. Quando quero instalar um servidor com ambiente mínimo e executar a instalação de produtos Oracle (que são executados em interfaces gráficas), acabo utilizando este recurso.

Read more »

9 anos de idade e 10 dias de uso de Xubuntu

Hoje fazem 10 dias que reinstalei o notebook que meu filho “herdou”. Optei por instalar o Xubuntu. Achei que precisaria intervir mais, adicionando pacotes ou auxiliando no uso, mas, até o momento, foram 10 dias de tranquilidade!

Read more »