Posts Tagged ‘comandos’

PostHeaderIcon Quando a ajuda cai do “shell”…

Muitos administradores de sistemas, desenvolvedores e até usuários (mais avançadas) de GNU/Linux (e outros tipos de Unix, na verdade) costumam lidar com a famosa “tela preta” por horas todos os dias. E, como não poderia ser diferente, mudar de diretórios é uma tarefa executada dezenas ou centenas de vezes em uma simples jornada de trabalho. Com isso, errar o caminho do diretório é algo bem comum e que, além de fazer você perder tempo, pode prejudicar sua paciência!

Uma das formas de facilitar sua vida no poderoso mundo da “tela preta” é o próprio recurso do auto completion, presente em shells com o bash. Outro truque bem simples e interessante, mas deconhecido por muitos, é comando shopt. Com ele, pode-se pedir uma ajuda da shell para completar seus comandos “cd” para mudar de diretório quando há apenas um pequeno erro de digitação.

Por exemplo, suponha que ao tentar entrar no diretório /tmp, vc execute o seguinte comando:

$ cd /tmx

Obviamente que você receberá uma mensagem de que esse diretório (/tmx) não existe. Entretanto, tente executar o comando shopt dessa maneira:

$ shopt -s cdspell

Em seguinda, tente executar o comando “cd /tmx” e confira que, mesmo tendo errado o caminho, você estará dentro do diretório pretendido, ou seja, o /tmp. Se você quiser que todas os seus terminais de comandos sejam executados já com essa opção, basta inserir o comando “shopt -s cdspell” no arquivo .bashrc ou .bash_profile (conforme sua distribuição Linux ou versão de Unix).

Antes de terminar, logicamente que o título desse pequeno post é completamente baseado nas “peripécias criativas” de meu grande amigo e mestre do shell Júlio Neves. Por fim, como se pode ver, mesmo no mundo da “tela preta”, às vezes, a ajuda cai do “shell”. Até a próxima!

PostHeaderIcon Como copiar sua chave SSH mais rapidamente.

Resolver problemas remotamente utilizando SSH é um recurso presenta no dia-a-dia dos sysadmins, desenvolvedores e até usuários mais avançados de ambientes Unix/Linux. Aliás, esse é um recurso seguro e muito útil, não é mesmo? Com isso, é comum que, ao longo de suas atividades diárias, um usuário que se vale desse recurso necessite abrir sessões SSH em muitas máquinas. Obviamente que a criptografia inerente ao protolo SSH não evita a existência de um processo de autenticação. São recursos de segurança complementares. Portanto, da maneira tradicional, cada abertura de sessão SSH necessita que o usuário insira uma senha. Com o tempo, principalmente para quem costuma fazer dezenas de sessões SSH diariamente, essa pode ser uma tarefa cansativa, não é mesmo?

Para evitar isso, o protocolo SSH possui um recurso muito interessante: a autenticação por meio de chaves públicas, que evita a necessidade de prover senhas durante a abertura de sessões SSH em máquinas remotas onde a chave pública do usuário já foi previamente copiada. Normalmente, esse processo se dá através da criação de um par de chaves criptográficas por meio do comando ssh-keygen, conforme apresentado no exemplo a seguir:

jansen@scadufax $ ssh-keygen -t dsa

Nesse caso, um par de chaves (pública e privada) está sendo criado usando-se o algorimo DSA. As chaves privada e pública, recém-criadas, são gravadas, nesse caso, nos arquivos id_dsa e id_dsa.pub, respectivamente, e ficam localizadas no diretório .ssh, dentro do home do usuário. Para se valer do recurso de não precisar prover senhas é preciso, então, copiar a chave pública para o arquivo .ssh/authorized_keys nos diretórios home dos usuários remotos, usando-se, por exemplo, o seguinte comando:

jansen@scadufax $ scp ~/.ssh/id_dsa.pub jsena@smeagol:~/.ssh/authorized_keys

Nesse caso, quando o usuário jansen, a partir da máquina scadufax, tentar abrir uma sessão SSH com o usuário jsena na máquina smeagol, nenhuma senha será necessária. O processo de autenticação se dará através das chaves criptográficas. Até nenhuma novidade, certo? Entretanto, imagine que mais de um usuário deseje acessar a conta jsena na máquina smeagol. Pode até ser a mesma pessoa utilizando um par de chaves criptográficas diferentes do anterior, gerado, por exemplo, em outro computador. Nesse caso, se o mesmo procedimento anterior for utilizado, o arquivo authorized_keys, que já contém a chave pública de outro usuário, será sobrescrito, passando a invalidar o acesso cadastrado anteriormente. Para evitar esse problema, a partir do segundo usuário, seria necessário adotar outros procedimentos para a cópia da chave-pública de forma a não sobrescrever o conteúdo já existente no arquivo authorized_keys.

Para facilitar esse processo, existe um utilitário chamado ssh-copy-id que é desconhecido por uma parcela considerável dos usuários de SSH. Essa pequena ferramenta resolve esse problema da cópia de diversas chaves para um mesmo arquivo authorized_keys:

jansen@scadufax $ ssh-copy-id jsena@smeagol

Caso seja necessário copiar outras chaves para acessar a conta jsena na máquina smeagol, basta utilizar o mesmo comando. Caso um mesmo usuário tenha mais de um par de chaves (sim, isso é possível), pode-se indicar quais delas se deseja copiar para a máquina remota:

jansen@gandalf $ ssh-copy-id -i .ssh/id_rsa.pub jansen.sena@boromir

Simples, não? Bem, acho que é isso.

IMPORTANTE: Para que o mecanismo de autenticação através de chaves públicas funcione corretamente, é necessário que o servidor SSH esteja configurado para tal. Mas isso é assunto para outro momento!

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 Histórico de comandos no Linux com data e hora.

Passo por aqui para deixar uma recomendação bem rápida.

Quem lida com um terminal de comandos em ambientes Linux frequentemente, especialmente através do bash, sabe o quanto o histórico de comandos é útil. Ele economiza ao longo do dia um bom tempo de digitação ajudando com a reutilização de comandos que já foram executaados anteriormente. Com alguns atalhos disponibilizados pela própria shell é possível tirar proveito ainda mais eficiente desse poderoso recurso, útil aos administradores de sistemas e a todos os usuários que necessitam do terminal. Além de facilitar a utilização, o histórico de comandos também é uma ferramenta importante para conduzir algumas investigações do que pode ter sido feito em um determinado sistema, uma vez que ele mostra a sequência de comandos executados. Para vê-lo, como muitos já estão cansados de saber, basta executar o comando "history".

E o que tem de novidade nisso? Nada a não ser pelo fato de que, muitas das vezes, os horários em que os comandos foram executados podem representar uma valiosa informação para quem está consultando o histórico. Essa informação torna-se ainda mais importante quando se tenta correlacionar comandos executados em computadores diferentes. O que poucos sabem, entretanto, é que isso é possível de configurar utilizando um recurso muito simples disponibilizado pela prória shell bash. Outra novidade? Essa informação está na própria man page da bash.

Para habilitar esse recurso, basta, por exemplo, abrir um terminal e definir a variável de ambiente HISTTIMEFORMAT por meio da execução do seguinte comando:

$ export HISTTIMEFORMAT="[%y%m%d %H:%M:%S] "

Feito isso, experimente executar o comando "history" novamente… Interessante, não? Note que você pode definir o formato e quais informações de tempo mais lhe interessam. Para tal, utilize a mesma representação de tempo implementada no comando date.

Para fazer com que os históricos de comandos sempre apresentem as informações de tempo, insira a definição dessa variável nos arquivos apropriados do seu sistema como os arquivos .bashrc e .bash_profile que ficam nos diretórios home dos usuários, por exemplo.

Bem, é isso.

PostHeaderIcon Precisa de mais swap no Solaris?

Dia disses, para atender aos requisitos de instalação de um aplicativo para um ambiente de testes, tive de aumentar o tamanho do espaço de swap de uma estação Solaris/OpenSolaris. O particionamento do computador não permitia criar ou mesmo aumentar o espaço de swap. Portanto, a saída mais rápida seria utilizar arquivos para tal finalidade. Já realizei esse procedimento inúmeras vezes, mas julguei interessante publicar essa dica por aqui. Sem uma solução como essas, você pode ser levado a acreditar que seja necessário reinstalar o sistema inteiro para aumentar a partição de swap. Esse é um truque bom para um sysadmin guardar na manga!

Os passos são bem simples: somente por organização, crie um diretório onde seja possível salvar os arquivos a serem adicionados ao espaço de swap; crie um arquivo com o tamanho desejado; adicione-o ao swap do sistema operacional:
# mkdir /swapfiles
# mkfile 1024m /swapfiles/swap1.swp
# swap -a /swapfiles/swap1.swp

Depois, para verificar a adição do arquivo de swap swap1.swp ao sistema, basta executar o seguinte comando:

# swap -l
swapfile             dev    swaplo  blocks   free
/dev/dsk/c0t0d0s1    136,9  16      4194224  4194224
/swapfiles/swap1.swp -      16      2097136  2097136
Ou ainda, para verificar o tamanho total de seu espaço de swap:

# swap -s

 total: 527464k bytes allocated + 43112k reserved = 570576k used, 4088424k available

Vale ressaltar que aumentar o tamanho do swap em um sistema que faz uso dessa memória frequentemente, não é uma boa alternativa. A utilização intensa de swap em um servido, por exemplo, é um sinal de que você precisa, urgentemente, aumentar a RAM.

PostHeaderIcon Dicas rápidas para impressão de man pages

Essa dica é simples porém útil. Diferente de sistemas como Windows, onde o help incluso no próprio sistema operacional é pouco útil, sistemas GNU/Linux possuem uma documentação muito rica a respeito de seus comandos, configurações, chamadas de sistemas, dentre outros por meio das man pages.

Mesmo para os administradores de sistemas mais experientes, as consultas às man pages são recorrentes e, portanto, para todos os que lidam com esses manuais, algumas dicas podem ser úteis.

Por exemplo, para imprimir uma man page em uma formatação adequada, diferente do texto padrão, você pode utilizar o seguinte comando:

$ man -t cut | lpr -P <nome da sua impressora>

Se, por outro lado, você deseja criar um PDF com formatação adequada de uma man page, você pode se valer do comando "man", do pipe e do comando ps2pdf:

$ man -t cut | ps2pdf – finger.pdf

Por fim, se você deseja ver o texto de uma man page formatado em HTML e já aberto em seu browser preferido, basta executar o seguinte:

$ man -H/usr/lib/firefox cut

Vale lembrar que, para esse último comando funcionar adequadamente, você precisa ter instalado em seu sistema o groff:

# apt-get install groff

Bem, era isso. Uma dica simples. Apenas para registrar.

PostHeaderIcon O desafio: “chmod 000 /bin/chmod”. E agora? O que fazer?

Recentemente, postei em minha página no Twitter o desafio de como resolver o seguinte problema:

"chmod 000 /bin/chmod"

Com esse comando, você está utilizando o chmod, responsável por mudar as permissões de um arquivo, para retirar todas as permissões do próprio comando chmod. Feito isso, ninguém, nem o administrador de sistemas, estará apto a alterar as permissões dos arquivos do sistema utilizando o próprio comando chmod. Diante disso, o que fazer para resolver o problema?

Bem, uma das saidas, utilizando apenas recursos dos comandos do próprio sistema operacional e propriedades dos sistemas de arquivos, consiste em utilizar as permissões de um outro arquivo que tenha o modo de execução habilitado substituindo seu conteúdo pelo do próprio comando chmod. Não entendeu? Então, permita-me explicar um pouco melhor.

Em um sistema de arquivo como o EXT2/EXT3 (e agora o EXT4), por exemplo, os metadados de um arquivo ficam em um local separado do seu conteúdo. Dentre esses metadados estão informações como a data da última modificação, o dono e o grupo do arquivo, seu tamanho e as próprias permissões atribuídas a ele. Em outras palavras, ao substituir o conteúdo de um arquivo, não se altera os atributos tais como as permissões.

Retomando o cenário após a execução do comando "chmod 000 /bin/chmod", o que nos restará é o comando /bin/chmod com essas características:

root@scadufax:~# ls -l /bin/chmod
———- 1 root root 46664 2008-06-26 21:31 /bin/chmod

Como foi dito anteriormente, utilizando o chmod, não é possível, mesmo para o super-usuário, alterar permissões de outros arquivos:

root@scadufax:~# chmod 000 /bin/cp
-su: /bin/chmod: Permission denied

Para resolver o problema, é possível aproveitar as permissões de um arquivo que já tenha privilégio de execução e depois substituir o seu conteúdo pelo o do comando chmod. Para isso, basta pegar qualquer comando do diretório /bin e copiá-lo para um diretório qualquer:

root@scadufax:~# cp -p /bin/cp /tmp
root@scadufax:~# ls -l /tmp/cp
-rwxr-xr-x 1 root root 75492 2009-11-01 09:37 /tmp/cp

Observe que as permissões de execução encontram-se configuradas. Depois, deve-se substituir o conteúdo desse arquivo pelo do comando chmod que não possui quaisquer permissões e copiá-lo novamente para o diretório /bin renomeando-o para chmod novamente:

root@scadufax:~# cat /bin/chmod > /tmp/cp
root@scadufax:~# mv /tmp/cp /bin/chmod
root@scadufax:~# ls -l /bin/chmod
-rwxr-xr-x 1 root root 46664 2009-11-01 09:42 /bin/chmod

Pronto… era isso! Antes de você se perguntar o porquê de tudo isso, eu me adianto: pra NADA a não ser se divertir um pouco e conhecer algo a mais  dos sistemas GNU/Linux e de suas características!

Inicialmente, postei essa questão no Twitter e, pelo menos dois amigos postaram outras soluções. Vou pedir a ambos que postem essas soluções aqui. Se você tiver outras alternativas, registre-as por aqui!

 

PostHeaderIcon Criptografia rápida com o GPG.

Muitos sabem da importância de se utilizar dos recursos criptográficos para proteger informações críticas, entretanto, são poucos os que utilizam em suas rotinas diárias esses artifícios. Ferramentas (livres) existem muitas e um dos maiores exemplos é o próprio GPG (GNU’s PGP), presente, por padrão, na maioria das distribuições GNU/Linux.

Obviamente que, criptografia não se resume apenas a confidencialidade, que corresponde ao mecanismo de tornar restrito o acesso à alguma informação contida em um arquivo, por exemplo. Entretanto, esse é um dos seus serviços mais populares. Partindo de um exemplo muito simples e didático. Suponha que, em um arquivo texto, você guarde algumas senhas importantes para acesso a sistemas sobre sua administração. É mais do que prudente evitar que o conteúdo desse arquivo seja exposto facilmente e, nesse caso, confiar apenas nos recursos de controle de acesso do sistema de arquivo não é, certamente, uma prática muito segura.

Para essa finalidade é possível "criptografar" esse arquivo utilizando-se uma senha, simplesmente por meio do seguinte comando:

myhost$ gpg -c /home/user/passwords.txt

Em seguida, será solicitada uma senha e sua posterior confirmação. A proteção do conteúdo do seu arquivo será proporcional à complexidade da senha utilizada em seu processo de cifragem. Portanto, não escolha senhas fracas e fáceis de serem exploradas. O resultado da execução do comando anterior é a geração de um arquivo com mesmo nome daquele informado como parâmetro acrescido da extensão ".gpg". O arquivo original, a partir desse momento, pode ser descartado:

myhost$ rm /home/user/passwords.txt

Para obter o arquivo original novamente, deve-se "descriptografar" o conteúdo do arquivo /home/user/passwords.txt.gpg. Para isso, basta utilizar o seguinte comando:

myhost$ gpg -d /home/user/passwords.txt.gpg > /home/user/passwords.txt

Tão logo a senha utilizada no processo de cifragem seja inserida, o arquivo original será recuperado imediatamente. Esse mesmo recurso pode ser utilizado para "criptografar" arquivos de quaisquer formatos. Suficientemente simples para não deixar mais arquivos críticos desprotegidos em seu sistema de arquivos, não?

Vale lembrar que no exemplo apresentado utiliza-se criptografia simétrica, ou seja, tudo que é feito com uma chave (senha) é desfeito com a mesma chave. Portanto, é importante saber que se você esquecer a senha utilizada para criptografar um arquivo não será mais possível recuperar seu conteúdo.

O GPG tem muitos outros recursos interessantes, tais como a utilização de criptografia assimétrica, assinatura digital, dentre outros. Vale a pena conhecer!

PostHeaderIcon Um (ascii)aquário no seu terminal…

É uma prática que me acompanha há anos: aproveitar meu pouco tempo livre para procurar por "inutilidades engraçadas e divertidas". Fã confesso da linha de comandos e defensor do poder de um bom terminal como uma ferramenta poderosa para o dia-a-dia de qualquer administrador de sistemas Unix ou qualquer outro tipo de profissional que necessite interações mais avançadas com esse tipo de sistema operacional, dediquei parte desse período de decanso para, exatamente, encontrar "futilidades" voltadas o terminal que possui, frequentemente, fama de "carrancudo" e "pouco divertido".

Tema de um post recente aqui do meu site, o "sl" (Steam Locomotive) provê uma forma, no mínimo engraçada, para lidar com um dos erros mais comuns dentre aqueles que utilizam o terminal de comandos: trocar as letras do popular comando "ls" por "sl", foi. Nesse caso, ao invés de receber um frio "comando não encontrado" (ou "command not found" nos sistemas instalados em inglês), uma locomotiva em formato texto atravessa sua janela de comandos.

O período de busca ainda me permitiu conhecer o Asciiquarium, um verdadeiro aquário dinâmico que exibe a vida marinha em seu terminal. Peixes dos mais variados formatos e tamanhos, baleias e barcos fazem parte do cenário. E, como não poderia deixar de ser, regido pelas leis naturais, até o tubarão faz uma aparição repentina, devorando os peixes menores que encontra pela frente… De vez em quando, um barco a velas também passa pela superfície, alheio a toda a movimentação marinha submersa nos mares dos caracteres.

Quer instalar o Asciiquarium? Dá uma olhada no restante do post, 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!