Pareceu uma guerra interminável. E é compreensível, uma vez que nem todos estão acostumados com a idéia de “pedir gentilmente” a um programa que se feche, ainda mais explicitando a forma como isso deve ser feito. Acredito que principalmente quem nunca desenvolveu algo na vida tem os maiores problemas aceitando esse conceito.

Imagine um (ou vários) processos do Postgres rodando. Você decide que ele é um gargalo no seu sistema, e você quer fechá-lo (crianças, não façam isso em casa…). Existe uma diferença brutal entre mandar um kill -9 (sigkill) e um kill -3 (sigquit).

Segue abaixo uma tabelinha de diferentes sinais, que eu chupinhei da Wikipédia e deste outro site:

Sinal	Número correspondente	Descrição
SIGTERM	15	SIGTERM é o sinal padrão, usado para terminar um programa. Usar o comando kill sem especificar o sinal numérico no Linux irá usar SIGTERM por default.
SIGINT	2	SIGINT corresponde, no mundo dos mortais, à famosa combinação de Control+C. A aplicação decide, então, o que fazer com o sinal INT que recebeu. Em muitos casos (shell scripts, por exemplo) a aplicação é quebrada imediatamente. Noutros, porém, o tratamento do INT pode ser diferenciado - a aplicação pode decidir fechar suas conexões, por exemplo, antes de ser interrompida.
SIGQUIT	3	O sinal QUIT é o padrão para fechar aplicações não-responsivas "gentilmente". Ele é mais poderoso que o TERM, que muitas vezes simplesmente é incapaz de matar um processo. Este, porém, permite que o programa emita um core dump de sua operação, tornando possível a detecção de eventuais problemas.
SIGKILL	9	KILL é, definitivamente, o mais bruto dos sinais. Ele mata o processo independentemente das suas operações atuais. Não irá esperar por retornos, fechamento de conexões, dump de dados ou qualquer outro output. SIGKILL é usado para matar aplicações completamente não-responsivas, e deve ser usado com cautela, pois pode, no exemplo do banco de dados acima, corromper tabelas, índices, etc.
SIGHUP	1	HUP é usado para indicar desconexão de terminal, geralmente. Seja por uma queda na internet, ou telefonema, ou qualquer outro tipo de quebra de sinal. HUP é usado, por exemplo, numa sessão SSH com processos pendentes, quando de repente a conexão foi cortada.

A tabela com todos os sinais existentes e seus significados pode ser encontrada no link para a Wikipedia, porém estes são os mais usados.

Todos devem ser usados de acordo com a situação, e devidamente tratados no código do programa. Dependendo da vontade do programador, pode-se interpretar os sinais para processar uma série de rotinas antes do término real da aplicação, e é importante respeitar o processo, sob pena de eventual perda de dados.

Característica número 2: Nós usamos vi, não emacs e definitivamente não pico ou nano
Todos sabemos que o emacs é muito querido por uma grande quantidade de administradores Unix, porém também sabemos que ele é o equivalente Unix ao Microsoft Word. O vi — e implicitamente o vim — é a verdadeira ferramenta para os geeks veteranos em Unix que precisam de agilidade nas suas tarefas, e não querem se preocupar com o monte de coisas estranhas que vêm junto com o Emacs. O Emacs possui um jogo de Tetris embutido, pelo amor de Deus.

Podemos admitir grunhindo que recursos do vim como “code folding” e destaque de sintaxe de várias linguagens pode ser considerado “fofo” por alguns, mas no final do dia, tarefas de verdade no Unix combinam muito bem com os conceitos de edição modal do vi. Além disso, seu pequeno tamanho e portabilidade universal o transformam na melhor escolha de editor de textos. Obrigado Bill, obrigado Bram.

Característica número 3: Nós empunhamos expressões regulares como armas
Para os leigos, mesmo o mais simples regex pode soar como digitação de bêbado. Para nós, porém, é a mais pura poesia. O poder representado na complexidade da pcre (Perl Compatible Regular Expressions) não pode ser vencido por outra ferramenta alguma.
Se você precisar substituir todos os terceiros caracteres num arquivo de 100.000 linhas, exceto quando ele é sucedido pelo número 4, as expressões regulares não são apenas uma forma de ter o trabalho feito – elas são a única forma de conseguir isto. Aqueles que se recusam a aprender regex fazem a si mesmos e seus colegas um desserviço diário.
Em todo grupo de usuários Unix de tamanho razoável você irá encontrar um ou dois “savants” em regex. Estes pobres coitados vivem recebendo sequencias de strings em seus emails, acompanhados por pedidos de regex para traduzí-las. Usualmente seguidos pela promessa de algumas cervejas, que nunca chegam a ser entregues.

Característica número 4: Somos inerentemente preguiçosos
Quando alguém nos apresenta um problema que envolve muito trabalho manual e repetitivo, nós Unix de antigamente sempre iremos optar por escrever algum trecho de código que dê conta do recado. Isto normalmente toma menos tempo do que a opção manual, mas nem sempre. Porém isto não importa, nós sempre preferimos gastar estes minutos e horas construindo algo que poderá ser utilizado depois, ao invés de simplesmente consertar o problema imediatamente. Normalmente, isto nos rende bons momentos quando nos deparamos com um problema semelhante ao anterior alguns anos depois, e então poderemos simplesmente arrancar algumas centenas de linhas de Perl do nosso home directory, resolver o problema em questão de minutos, e tornar a resolver algum outro código. Ou então podemos jogar Angry Birds por mais tempo.

Característica número 5: Nós preferimos soluções elegantes
Se existem diversas maneiras de consertar um problema ou alcançar uma meta, nós iremos optar por gastar mais tempo desenvolvendo uma solução que resolva o problema e previna que ele torne a acontecer, ao invés de simplesmente puxar o Band-Aid. Isto tem a ver com o fato de odiarmos voltar a um problema que já “marcamos como resolvido” em nossos cérebros. A moral da história é que, se podemos resolver um problema de uma vez por todas gastando um pouco mais de tempo hoje, o faremos, para que tenhamos menos dores de cabeça no futuro.

Característica número 6: Nós geralmente assumimos que o problema está com a pessoa que faz a pergunta
Atingir um certo nível de expertise em Unix é ser extremamente confiante nas suas habilidades e conhecimentos. Isto significa que nós nunca pensamos que um problema existe até que possamos vê-lo pessoalmente. Falar para um veterano em Unix que um arquivo “simplesmente sumiu” vai resultar em zombaria na certa. Prove para ele que aquilo realmente aconteceu, e você irá se deparar com alguém que irá mergulhar no problema incansávelmente, até que uma causa razoável e sua soluções sejam encontradas.
Muitos podem achar que isso é um sinal de arrogância ou prepotência. E é, mas nós temos este direito.

Característica número 7: Nós temos mais em comum com os médicos legistas do que com doutores
Quando lidamos com um problema muito grande, nós iremos gastar muito mais tempo no “pós-morte” do que com a solução do problema. A menos que a carga de trabalho absolutamente não nos permita gastar um tempinho com a investigação, nós precisamos saber a causa absoluta do problema. Não existe mágica no mundo do administrador hardcore de Unix; cada situação precisa partir de uma certa lógica e seguí-la nos moldes corretos. Ou seja, existe uma razão para tudo, e nós não vamos deixar pedra sobre pedra até a encontrarmos.

Para nós, é fácil estancar o sangramento mandando um HUP para um processo ou mudando permissões num arquivo ou diretório para 777, mas esta não é nem metade da história. Porque o processo precisou ser reiniciado ? Isto não deveria ser necessário normalmente, e nós precisamos saber o porque das coisas.

Característica número 8: Nós sabemos mais de Windows do que deixamos transparecer
Apesar de não rodarmos Windows nos nossos computadores pessoais, e parecer que não nos importamos nem um pouco com servidores Windows, nós somos geralmente bastante capazes de diagnosticar e consertar problemas neste sistema. Isto porque nós precisamos lidar com estes problemas quando eles ultrapassam os limites e caem no nosso território.
No entanto, nós geralmente não gostamos de demonstrar estas habilidades, porque o Windows não segue os mesmos fundamentos lógicos do Unix, e isto nos incomoda. Vide características 5 e 6 acima.

Característica número 9: Reinicializar o sistema quase nunca é a solução
Servidores Unix não precisam de reboot. A menos que não haja absolutamente nenhuma outra opção, nós preferimos gastar horas e horas consertando um problema com um sistema online e funcional, do que reinicializá-lo. A moral da história é que não existe razão para um reboot a menos que precisamos efetuar mudanças no hardware, ou existe alguma atualização para o kernel que estejamos rodando. Reinicializar o servidor é apenas uma saída temporária para o problema. Se ele aconteceu uma única vez e foi “consertado” por um reboot, pode apostar que irá acontecer novamente. Nós preferimos consertá-lo já do que simplesmente puxar a tomada e esperar pela próxima ocorrência.

Se algumas dessas características parecerem anti-sociais ou difíceis de serem entendidas a partir da perspectiva de um leigo, é porque elas são. Onde alguns enxergam métodos super complicados ou intratáveis, nós vemos o caminho certo, oriundo de anos de aprendizado, experiência e, acima de tudo, lógica.

####

Este texto não foi escrito por mim. O original, de autoria de Paul Venezia, em inglês, se encontra neste endereço, e honestamente, fica bem mais divertido no idioma original do que traduzido.

Estou participando da promoção que o Augusto fez em um dos blogs dele, o Efetividade.net, e para isto eu precisava postar aqui uma foto da minha mochila, e de todo o conteúdo que carrego nela.

Tem muita tranqueira, coisa útil e alguns lixos que eu sempre esqueço de tirar dela.. Acho que todas têm, né.. Roubar minha bolsa seria BEM pior do que roubar meu carro, podem apostar.

Se você também quiser participar, clique aqui e siga as regras da promoção. É super simples, vai que você ganha um dos brindes divertidos que ele vai sortear ?

Bem, segue a foto da baderna – versão diminuta – pra não arruinar meu layout.

Clique para ver a versão gigante!

Eu pretendia postar a foto no Flickr pra fazer uso daquelas tags legais que eles têm, mas não estou afim de criar uma conta no Yahoo. Vou descrever tudo de maneira simples mesmo:

Da esquerda pra direita tem:
- O papelzinho indicando que não é fake
- Embaixo dele, um guarda-chuva. Fumar em locais descobertos tomando água na cabeça não é mole;
- Uma chave de fenda com multiplas pontas (eu esqueci de abrir o compartimento..) e com a ponta imantada;
- Pilhas normais, pilhas recarregáveis e o seu respectivo carregador;
- Um HD externo Western Digital de 1 TB;
- Um iPhone que eu uso basicamente pra jogar FieldRunners e outros TD’s básicos, porque, por N razões, comprei um Milestone pra substituí-lo..
- Fluído extra pro meu Zippo, que adora ficar sem nas horas mais cruéis da vida;
- O carregador, já com a extensão plugada, do meu Macbook Pro;
- O cabinho do iPhone;
- Cabo micro (ou mini, sei lá) USB pro Milestone e pro HD externo;
- Um pendrive DataTraveler de 4gb e outro de 16gb mais pra direita;
- O token de autenticação do Itaú;
- Dorflex e Salompas – Solução fail para as dores constantes na nuca e tendinite por excesso de horas no computador
- Cabos cross e normal, de rede;
- A apostila da Caelum;
- Caixa de fósforos, única coisa que nunca me deixa na mão;
- Alguns canivetes que nunca preciso mas esqueço de tirar lá de dentro. E um isqueiro à gás normal;
- O adaptador MiniDisplay Port do Macbook;
- Adaptador de cabos de energia elétrica do padrão novo, e idiota, da ABNT;
- O Magic Mouse;
- Mousepad do Slackware. Raramente o uso, mas carrego porque é leve e não custa nada;
- Livro para iniciantes de como desenvolver apps pro Android. Um dia eu chego lá !
- Guia de estudos pro SCSA (certificação de segurança do Solaris);
- Embaixo dos livros tem este suporte para laptops. Evita um pouco a dor na nuca que sinto frequentemente;
- Um frasco de álcool higienizador. Herança da paranóia da gripe H1N1, mas útil pra quando pego ônibus e fico com nojo das crianças passando as mãos sujas de Cheetos nas barras de segurança, bancos, e em todo o resto do veículo;
- O Macbook Pro itself;
- Fones de ouvido bluetooth da Nokia, que funcionam tanto no meu Android, quanto no PS3;
- Meu DINGOOOOO !
- GPS da Mio, aquela versão podre da Quatro Rodas que custa o triplo dos outros sem apresentar nada a mais por isso;
- Um gadget chamado O2 Cool, chinês, (que surpresa..) que funciona com uma única pilha e faz um ventinho razoável, além de borrifar água. Muito bom pra usar no verão.

E no fundão, claro, tem a mamãe (porque haja coração pra acolher tanto lixo), minha bolsa da Ogio, versão Ubuntu.

E é isso, um abraço !

>/dev/null 2>&1

Ou seja, se o job era:

0-59/5 * * * * root /usr/bin/fetchmail -f /root/.fetchmailrc -a -s -K -F

Ele vai ficar assim:

0-59/5 * * * * root /usr/bin/fetchmail -f /root/.fetchmailrc -a -s -K -F >/dev/null 2>&1

Tadá ! Sem mais aquela enxurrada de emails inúteis na sua caixa.
Claro, faça isso apenas para jobs que não exibem algo de útil no output, como por exemplo erros ao processar algo.

To check if a file exists and it’s executable, use:

#!/bin/bash
FILE=/usr/bin/passwd

if [ -x $FILE ];
then
 echo "File $FILE exists and it is executable"
else
 echo "File $FILE does not exists or it isnt executable"
fi

There are several other options. Here’s the full available conditional expressions:

-e: Returns true value if file exists
-f: Return true value if file exists and regular file
-r: Return true value if file exists and is readable
-w: Return true value if file exists and is writable
-x: Return true value if file exists and is executable
-d: Return true value if exists and is a directory

Have fun improving your scripts !

Ontem foi dia de análise de alguns servidores da GM, especialmente os SOX, por estarmos próximos à outra auditoria.
Numa empresa grande como a HP, temos centenas de funcionários de suporte ao ambiente – Pessoas lidando com o sistema operacional, outros com banco de dados, alguns especialistas em ferramentas de monitoração, entre outros.

A menos que sua rede toda esteja rodando NIS ou LDAP (o que raramente acontece), você acaba tendo que criar todos estes ID’s nos servidores, e ao longo dos anos isso vira bagunça, se não for administrado corretamente.

Nessa revisão de ontem constatamos que possuíamos muita gente com acesso demais nos servidores. Isto é, com regras de sudo excessivas, pelo fato de serem membros de grupos desnecessários.

Tente administrar mais de 3.000 servidores e ir, de um por um, removendo os grupos de algumas dezenas de usuários. Complicado né ?
Foi com isso em vista que fiz um simples shell script, com a função de fazer algo que, na minha opinião, deveria ser um recurso nativo do Unix.As regras de sudo, num ambiente bem estruturado, são, em sua maioria, desenhadas para grupos – e então usuários adicionados aos grupos, dando-os permissões para a execução dos comandos como root.

Imaginemos então que o usuário torvalds é membro dos grupos admin, monitoracao e impressoras. E que nosso objetivo é retirá-lo do grupo admin, pois este grupo possui permissões para executar sudo su -.

Seria simples, não ?

usermod -g monitoracao -G impressoras torvalds

Porém agora considere o seguinte: O cara vai estar no grupo admin em todos os servidores, porém os grupos secundários dele são desconhecidos.
Além disso, você não pode conectar-se a cada servidor, grepando o /etc/group pelo ID dele, e montando um script para cada ocasião. Total perda de tempo, certo ?
Ah sim, mais um probleminha: Você vai rodar o script em Solaris, HP-UX, AIX e em alguns poucos servidores Linux. Portanto nada de comandos específicos.

Foi pensando nisso que eu criei um script simples, feio, mal-feito mas que funciona Usando apenas as ferramentas encontradas em todos os sabores de Unix, como sed, while-do, grep, cut, entre outros.
Ele automatiza a coisa, fantástico para uma ocasião como a minha, onde tenho em mãos uma ferramenta web que é capaz de rodar o script em todos os servidores ao mesmo tempo.

Enfim, sem mais delongas – Segue o script. Torço pro Google indexar isso logo e outros que passaram pelo mesmo problema que eu tenham uma solução mais prática:

# Entrar num diretório temporário:
mkdir –p /tmp/controlid && cd /tmp/controlid
# Pegar do /etc/group os grupos atuais do cara e jogar num arquivo temp:
grep torvalds /etc/group | cut -d: -f1 > currgroups
# Botar o output do comando anterior, todos na minha linha, separados por virgula:
while read line; do echo -n "$line,"; done < currgroups > currgroups2
# Tirar a porcaria da virgula que sobrou no final da string:
cat currgroups2 |sed 's/\(.*\)./\1/' > currgroups3
# Remover o grupo admin da lista acima. Troque a palavra admin abaixo pelo grupo que deseja remover.
cat currgroups3 | sed 's#,admin##g' > groups
# Atualizar os grupos do cara !
usermod -G `cat groups` torvalds

Sugestões de otimização para o script são sempre bem-vindas.

Um abraço a todos !