Posts Tagged ‘Sysadmin’

PostHeaderIcon Shell script: como fazer um loop até que uma tecla seja pressionada?

Recentemente, um amigo me mandou um email com uma dúvida: ele precisava desenvolver um shell script que ficasse executando uma determinada tarefa até que uma tecla pré-estabelecida fosse pressionada. Por imaginar que essa pode ser a necessidade de muitos outros sysadmins, usuários e desenvolvedores que trabalham com o mundo GNU/Linux, resolvi compartilhar essa rápida discussão por aqui.

Bem, existem várias maneiras para resolver esse problema e resolvi indicar uma das formas que julgo ser de fácil e rápido entendimento. O ponto chave é utilizar o comando read. Vejamos o exemplo a seguir:

#!/bin/bash
while read MyKey; do
        if [ "$MyKey" == "p" ]; then
                echo "Tecla escolhida foi pressionada. Saindo do loop."
                break
        fi

        # // Inclua aqui comandos a serem executados...
        # // ...enquanto a tecla nao e pressionada
        echo "Minhas tarefas estao sendo executadas"

done
echo "Fim."

Bem, isso não parece resolver o problema, certo? Isso porque as tarefas devem ficar sendo executadas enquanto uma tecla pré-determinada (nesse caso, “p”), não for pressionada. Por outro lado, no exemplo anterior, as tarefas serão executadas apenas quando uma tecla qualquer, que não seja o próprio “p”, for pressionada. Isso ocorre porque o comando “read” ficará aguardando indefinidamente que o usuário digite alguma tecla que, por sua vez, é inserida na variável MyKey . Bem, definitivamente, não é disso que precisamos, certo?

Poucas pessoas sabem, mas o comando read não precisa ficar aguardando infinitamente alguma entrada do usuário. Com o parâmetro “-t <seg>” você pode indicar quantos segundos o comando irá ficar aguardando para que algo seja digitado. Caso o tempo indicado, em segundos, expire e nada seja digitado, o comando encerra sua execução. Sabendo disso, algumas pequenas mudanças nos farão chegar onde precisamos:

#!/bin/bash
while true ; do          
        read -n 1 -t 1 MyKey
        if [ "$MyKey" == "p" ]; then
                echo "Tecla escolhida foi pressionada. Saindo do loop."
                break
        fi

        # // Inclua aqui comandos a serem executados
        # // ...enquanto a tecla nao e pressionada
        echo "Minhas tarefas estao sendo executadas"
done
echo "Fim."

Feito, não? Entretanto, para ser um pouco mais caprichoso com o exemplo, ainda é possível alterar um “pouquinho  mais” o exemplo:

#!/bin/bash
INTERVALO=2 
while true ; do          
        read -s -n 1 -t $INTERVALO MyKey
        if [ "$MyKey" == "p" ]; then
                echo "Tecla escolhida foi pressionada. Saindo do loop."
                break
        fi

        # // Inclua aqui comandos a serem executados...
        # // ...enquanto a tecla nao e pressionada
        echo "Minhas tarefas estao sendo executadas"
done
echo "Fim."

Duas pequenas mudanças, certo? A primeira, muito básica, consiste em colocar o intervalo de tempo do read em uma variável. Dependendo do script, isso pode ajudar para mudar o comportamento sem entrar muito no código. A segunda, igualmente simples, consiste na adição do parâmetro “-s” que faz com que a tecla pressionada pelo usuário não seja impressa no terminal. Puro capricho… :-)

Acho que é isso. Até a próxima!

PostHeaderIcon Problemas para remover volumes lógicos com LVM2?

Sem sombra de dúvidas, planejar o particionamento de um servidor GNU/Linux com LVM é uma opção muito interessante e praticamente obrigatória para um sysadmin precavido e organizado. Entretanto, podemos tratar um pouco mais sobre o LVM e suas vantagens em outra oportunidade. Esse rápido post é apenas para compartilhar uma situação que já passei em algumas oportunidades: em alguns servidores que administro, já tive problemas para remover volumes lógicos (LVs).

A maneira mais comum para remover um LV consiste, simplesmente, em utilizar o comando lvremove. Por exemplo:

# lvremove /dev/MyVG/lvol_test

Entretanto, em alguns sistemas, me deparei com o seguinte erro ao tentar remover LV:

# lvremove /dev/MyVG/lvol_test
Can't remove open logical volume "lvol_test"

Bem, caso você esteja com esse problema, existe uma solução muito simples por meio da utilização do dmsetup.

# dmsetup info -c MyVG-lvol_test
Name               Maj Min Stat   Open Targ Event  UUID
MyVG-lvol_test     253   8 L–w       1    1      0 XiuqlKY91paW...

Nesse caso, o valor que interessa é o da coluna Open. O  número “1” identifica que o LV encontra-se no status de aberto e isso pode ser a causa do problema. Se esse for o seu caso, execute o comando dmsetup da seguinte maneira:

# dmsetup remove MyVG-lvol_test

Em seguida, tente executar novamente o comando lvremove que, dessa vez, deve reportar a remoção com sucesso do LV:

# lvremove /dev/MyVG/lvol_test
Logical volume "lvol_test" successfully removed

Bem, acho que é isso.

PostHeaderIcon Você ainda apaga arquivos com o “rm”? Removendo arquivos de maneira segura com o shred.

Remover arquivos faz parte da rotina diária de qualquer usuário de um sistema operacional, não é mesmo? Provavelmente você deve fazer isso algumas dezenas de vezes ao longo de um dia de trabalho em frente ao computador. Caso um arquivo qualquer (como uma ISO de um sistema operacional, por exemplo) esteja sendo apagado simplesmente para liberar espaço em seus meios de armazenamento, que mal há utilizar o bom e velho “rm”? Por outro lado, tenho a impressão de que você não gostaria de saber que aquele script que contém todas as suas regras de firewall, por exemplo, ou qualquer outro arquivo com alguma informação sensível pode cair em mãos erradas se você confiar no apenas no “rm”.

Bem, primeiramente, permita que eu me desculpe por ‘descortinar’ essa verdade caso você ainda achasse, até o parágrafo anterior, que um “rm -f” era um comando forte e com tanta ‘personalidade’ ao ponto de mandar pro espaço qualquer arquivo ou diretório. O fato é que ao remover um arquivo com esse comando o sistema operacional, em poucas palavras, simplesmente retira os “ponteiros” para os blocos de dados que formavam o arquivo. Por outro lado, esses blocos estão lá em seu HD e podem, com a ajuda de algumas ferramentas, ser recuperados. Provavelmente esses blocos irão ser sobrescritos apenas quando novos arquivos forem utilizando aqueles mesmos espaços e isso pode demorar um tempo bastante considerável principalmente se o computador em questão não tiver operações um fluxo de gravação de arquivos muito intenso.

E, antes que você se pergunte, mas quem pode ter acesso ao meu HD? Bem, fácil. Seu computador pode ser invadido através da Internet, você pode perdê-lo, você pode ser roubado, você pode vendê-lo ou você pode mandá-lo para uma assistência técnica para consertar um problema, por exemplo. Enfim, são muitas as possibilidade, não é verdade? Pior ainda quando se está falando dos pequenos e portáteis pen drives que carregamos conosco o tempo todo para todo lugar. Quando é possível, pode-se utilizar os sistemas de arquivos criptografados. Entretanto, em situações onde não é possível utilizar essas soluções, é preciso tomar cuidado para garantir que arquivos sensíveis foram, de fato, removidos.

Read the rest of this entry »

PostHeaderIcon Reconhecendo um sistema operacional com o ping!

Recentemente, li um pequeno texto no site da Dicas-L a respeito de como se pode utilizar o comando ping como uma forma de detectar um sistema operacional remoto. Aliás, sempre que posso, ensino em sala de aula esse recurso.

Resumindo um pouco do que se trata. Para que sistemas operacionais diferentes possam se comunicar normalmente em uma rede, é preciso que todos “falem” a mesma língua. No caso da Internet e na maioria das redes da atualidade, essa língua significa os protocolos que compõem a arquitetura TCP/IP cujas especificações, conhecidas como RFC (Request For Comments) são públicas e podem, portanto, ser consultadas livremente através do site http://www.ietf.org. Em outras palavras, cada fabricante deve consultar essa documentação para implementar em seu sistema operacional os protocolos da arquitetura TCP/IP, seguindo as recomendações que irão garantir a correta interoperabilidade em rede.

Read the rest of this entry »

PostHeaderIcon Reiniciando um servidor Linux a partir do diretório /proc – PARTE II

Já convencido de que o Magic SysRQ Key pode ser um "truque" importante no seu dia-a-dia de sysadmin GNU/Linux, o próximo passo é conhecê-lo um pouco melhor para poder utilizá-lo de maneira mais segura e eficiente.

Uma vez que esse recurso esteja habilitado em seu kernel, a primeira saída para reiniciar um sistema GNU/Linux que já não tenha à disposição comandos como o reboot, o shutdown ou o init, consiste em executar o seguinte comando:

root@scadufax:~# echo "b" > /proc/sysrq-trigger

Esse comando irá reiniciar o seu sistema imediatamente, sem qualquer preocupação com o sincronismo e a desmontagem dos sistemas de arquivos presentes em seus discos. Isso, evidentemente, pode provocar problemas e provocar algumas outras instalabilidades no seu sistema que, a essas alturas, já deve estar bastante "sacrificado". O que fazer, então?
Read the rest of this entry »

PostHeaderIcon “cat”, tudo bem. Mas e o “tac”?

Dia desses, tive que recorrer, como é de rotina na vida de um administrador de sistemas, à memória, para lembrar de alguns comandos que você, pode até não utilizar com muita frequência no seu dia-a-dia, mas que, por sua utilidade, você sabe que é bom aprender porque um dia ele poderá lhe ser muito útil.

Lidando com um ambiente no qual um determinado pacote e todas as suas dependências foram instaladas por meio da orientação de um arquivo que continha o nome desses pacotes listados na ordem exata de instalação, a tarefa era fazer exatamente o inverso: remover o pacote e suas dependências. Simples, não? Bastava seguir a ordem inversa do arquivo que continha a sequência de instalação. Essa lista, entretanto, não era tão pequena e seria, no mínimo, pouco desafiador, invertê-la manualmente. O que fazer, então?

Obviamente que qualquer usuário iniciante da linha de comando conhece o comando cat, utilizado, dentre outras coisas, para exibir o conteúdo de arquivos texto. Entretanto, quem conhece o tac? Como o próprio nome sugere, o tac produz o resultado inverso do cat, mostrando o conteúdo de arquivos em ordem inversa. Isso resolveria o problema de desistalar o pacote e suas dependências na ordem correta, certo? Nesse caso, com o uso do pipe e do poderoso xargs (assunto para outras oportunidaes) sequer foi necessário criar um novo arquivo contendo a lista inversa dos pacotes:

$ tac install_order | xargs -t -i pkgrm -n {}

Pronto, tudo desinstalado corretamente!

O tac está presente em muitas distribuições GNU/Linux e em outros tipos de sistemas Unix, apesar de ser desconhecido de muitos. Guarde-o em bom lugar!

 

PostHeaderIcon Reiniciando um servidor Linux a partir do diretório /proc.

Dia desses, procurando por informações a respeito de métodos de reinicialização de um servidor para casos de emergência, encontrei um pequeno e interessante artigo publicado no site da Linux Journal, a respeito de uma maneira simples, entretanto, útil, de reiniciar um sistema GNU/Linux a partir do diretório /proc. Reproduzo, então, alguns comentários a respeito desse que pode ser um interessante recurso para um sysadmin GNU/Linux guardar nas mangas!
Read the rest of this entry »