Archive for the ‘linux’ Tag

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

[CC] Habilitando impressoras CUPS via linha de comando

Quando adicionamos um impressora em rede (em geral ligado numa estação de trabalho) no CUPS, é comum que a impressora fique desabilitada, por falta de comunicação, por exemplo.

Para que ela volte a funcionar, é necessário habilitá-la. Para isto, em geral, se faz via uma interface (seja o administrativo do próprio CUPS via interface web, ou seja em uma interface gráfica instalada em sua distribuição Linux.

Agora quando o serviço do CUPS está instalado em um servidor sem interface gráfica, servindo à um sistema local e você tem apenas acesso remoto, via SSH, como fazer?

Tradicionalmente o comando seria este (vem desde o tempo dos “Unix’s”):

$ enable nome-da-impressora

No entanto, no sistema que eu estava administrando (e acredito que seja verdade para um grande número de Linux atualmente), o comando “enable” faz parte do shell [1], assim, não funciona para o propósito que eu precisava (o de habilitar a impressora!).

Pesquisando um pouco [2], descobri que existe uma alternativa do CUPS, que coloco abaixo:

$ cupsenable nome-da-impressora

Simples e direto assim! Espero que seja útil a mais alguém!

 

Referências:

[1] https://pt.wikipedia.org/wiki/Shell_(computação)

[2] http://www.linuxquestions.org/questions/linux-newbie-8/help-how-to-enable-printer-in-cups-using-command-line-839898/

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

Samba 4 e compartilhamento público (“security=share”)

Venho relatando aqui no blog os ajustes de serviços e configurações necessários em função da nova versão 7 do RedHat (e similares). Mais detalhes podem ser encontrados na parte 1 e parte 2.

Um dos serviços que precisei configurar e que também sofreu alteração, foi o compartilhamento de arquivos via protocolo SMB, feito com o nosso amigo Samba. Embora a nova configuração que precisei fazer tenha sido em função da versão 7, esta mudança ocorreu com a versão 4 do Samba, estando assim disponível em outras distribuições atuais.

Precisei fazer um compartilhamento de arquivos público, sem restrições de acessos nem autenticação de usuários. Em versões anteriores do Samba, isto era feito através da seguinte configuração (no smb.conf):

security = share

Usei a mesma diretiva, ajustei as demais configurações que eu precisava e fui rodar um testparm (para verificar se estava tudo correto). Para minha surpresa o teste acusou:

WARNING: The security=share option is deprecated

Fui então pesquisar o que poderia estar errado, pois meu compartilhamento não estava funcional. Em [1] encontrei a nova versão de  configuração para esta versão do Samba.

Mesmo na versão 3.6 do Samba que está em meu computador pessoal, este aviso já aparece. Não consegui identificar a partir de qual versão ocorreu esta mudança.

Em suma, as configurações ficam assim:

[global]
# (...)
security = user
map to guest = Bad User
guest ok = yes

Referências:

[1] Set up Samba without using Deprecated “share” Security Setting – https://vicidi.wordpress.com/2012/01/23/set-up-samba-without-using-deprecated-share-security-setting/

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

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.

Continue lendo

[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