Como sysadmins vez por outra a gente precisa dar acesso a clientes, parceiros ou outro tipo de usuário temporário/untrusted aos servidores. Apesar de criar um jail root completo ser a melhor solução muitas vezes é mais trabalho do que o necessário e começa a entrar naquele cenário em que a segurança atrapalha a usabilidade e os negócios.
Uma forma simples de conseguir uma segurança bacana é utilizar o modo restrito do bash. Com isso habilitado o shell irá desabilitar as seguintes funções:
Mudar o diretório (cd)
Mudar o valor das variáveis SHELL, PATH, ENV, or BASH_ENV
Comandos que incluem /
Especificar um arquivo que contenha / como fonte para o comando “.”
Usar redirecionamento de output (>, >>, |)
etc (man bash para todas as features)
Colocando para rodar:
Crie um link do bash para o rbash e adicione o mesmo em /etc/shells:
Depois é só mudar o shell do usuário a ser restringido para usar o rbash:
usermod -s /bin/rbash username
Combinando isso com traps (do CTRL+C, por exemplo) você consegue criar um ambiente seguro o suficiente para fornecer serviços e acessos aos seus servidores e ainda assim dormir à noite.
Recentemente coloquei no ar o FollowUpTime, que como já disse em outros posts é um sistema de monitoração para redes e servidores.
Como podem imaginar, um bocado de linhas de código está envolvida num sistema assim e a conta só do engine principal passa das 90 mil linhas. Isso sem incluir templates, javascripts, etc.
O sistema é composto de duas partes: Uma que roda num servidor principal gerenciando a maior parte das tarefas e as “probes”. As probes são pequenos scripts que recebem instruções sobre hosts a serem testados e respondem para o servidor principal com o tempo de resposta, um OK ou um FAIL. Simples assim.
São essas probes que temos espalhados por vários cantos do planeta.
Porém quando recebi a probe dos desenvolvedores me vi com um pequeno, mas incoveniente problema. Os desenvolvedores realmente optaram pelo princípio KISS. Eles me entregaram uma excelente probe que fazia o que era necessário. E nada mais. Eu tinha nas mãos um daemon que rodava em foreground e jogava mensagens para stdout e stderr e nada mais.
Eu não me demorei e ataquei o problema da forma errada, pensando como um programador e não como um administrador Unix. E acabei reinventado a roda.
Introdução – O problema
Quando percebi o que eu tinha nas mãos logo pensei nos problemas que eu precisava resolver:
Preciso iniciar o daemon sempre que der boot na máquina
Preciso ser capaz de rodar em daemon em background, ou vai me zoar a seqüencia de boot
Posso precisar parar/reiniciar/iniciar manualmente este daemon
Se o processo morrer eu tenho que ser notificado e que, de preferência, ele seja reiniciado automaticamente
E sim, esse processo não deve rodar como root
Já velhaco de Linux logo pensei num script para ser colocado em /etc/init.d/ que ia resolver boa parte dos meus problemas. Com uma combinação bonita de bash scripting, várias ferramentas e comandos Linux que só se conhece depois de muito tempo de casa (como nohup, pidof, &) e gambiarras na crontab eu consegui. Consegui reinventar a roda. Não vou entrar em detalhes da solução que fiz, pois apesar de 100% funcional não era nem de perto tão bonita quanto:
A solução – Daemontools
Nosso caro amigo D.J.B, autor do famoso Qmail também já passou por um problema parecido com o meu, mas ao invés de criar um solução simples para resolver um problema pontual ele foi mais longe. Ele criou uma solução global que atende o problema dele, o meu e provavelmente também o seu.
Na página oficial do daemontools tem uma tabela, que traduzo abaixo, comparando a ferramenta dele com outras abordagens (incluindo a minha, que utilizava init.d):
Funcionalidade
inittab
ttys
init.d
rc.local
/service
Fácil instalação e remoção de serviços
Não
Não
Sim
Não
Sim
Simples startup inicial
Não
Não
Não
Não
Sim
Reinicializações confiáveis
Sim
Sim
Não
Não
Sim
Sinalização simples e confiável
Não
Não
Não
Não
Sim
Estado de processo limpo
Sim
Sim
Não
Não
Sim
Portabilidade
Não
Não
Não
Não
Sim
Dá para perceber que o cara pensou em tudo e não tem porquê reinventar a roda. Vamos utilizar o daemontools!
Não sei ao certo como é o nome em português. Variáveis aninhadas?
Me deparei com um problema assim hoje: Eu tinha uma função num script shell que recebia um parâmetro de sucesso ou erro. Eu executava algumas coisas e depois tinha que jogar uns dados no arquivo respectivo.
Então inicialmente tinha setado uma variável com os paths dos caminhos:
Esses dias me deparei com a seguinte situação: Precisava implementar um serviço baseado em web. Esse serviço vai acumular bastante informações sobre a infra-estrutura da empresa e por isso precisa de autenticação para garantir que apenas as pessoas corretas tenham acesso a essas informações.
Mas por motivos que nem vale a pena citar, afinal não quero uma gastrite, o bagulho não aceita autenticação.
A forma que eu arranjei para resolver isso foi simples: A porta do serviço original é bloqueada via iptables e instalei o lighttpd para servir como proxy, já me aproveitando das features de autenticação dele.
Caso precise fazer algo parecido com isso um dia, segue abaixo como fiz:
Como já devem saber eu sou da turminha do vi. Nada contra o Emacs, lógico, mas vi é vi.
O relacionamento com ele nunca começa bem. Lembro-me que a primeira vez que abri o vi, num SCO Unix, o único jeito que consegui sair do editor foi rebootando a máquina. Eu não tinha nem idéia de que bastava um ESC:q! para cumprir a tarefa. Mas passados 11 anos ou mais deste início traumático, posso dizer que me dou bem com o editor hoje em dia, utilizando-o inclusive para escrever posts no meu blog, como neste momento o faço.
Às vezes o que sentia falta era de alguma coisa para facilitar minha vida quando estava fazendo meus scripts. Alguns pedaços de código você usa de novo, de novo e de novo. E é um saco ficar redigitando.
Importar para dentro do arquivo atual (ESC:r /path/arquivo) ajuda, mas não resolve.
A solução
Pesquisando achei o sensacional BASH-IDE para vim. Resolveu todos os meus problemas, exceto a falta de competência como programador.
Utilizando o BASH-IDE podemos configurar um template para novos arquivos, de forma que sempre que abro um novo arquivo .sh no vim ele já adiciona o cabeçalho com informação sobre o autor, data, tag $id$ pro cvs e algumas variáveis e funções que eu coloco em todos os meus script.
O autor do BASH-IDE foi cuidadoso para facilitar a documentação de forma que vários atalhos já são auto-documentados.
Uma nova função criada utilizando o BASH-IDE automaticamente terá o seguinte aspecto:
function teste ()
{
} # ---------- end of function teste ----------
E ao chamar o atalho para documentação de função você recebe este template:
Como tudo é baseado em arquivos texto, as customizações só dependem da sua boa vontade. E ainda vem com um uma cheat sheet em pdf pronta para imprimir e pendurar na sua baia!
Comentei em outro post sobre changes e minha experiência com elas.
Apesar de ser um assunto complexo por natureza e ainda contar com o agravante de que cada empresa implementa de uma forma diferente, algumas dicas gerais podem ser úteis.
Planeje seus passos com antecedência
Pode parecer besteira falar isso, mas já vi muita gente (incluindo eu no início) simplesmente chegando na hora da change pra ver no que dava.
Tenha em algum lugar todos os comandos que precisará executar, de preferência separados em sessões do tipo “verificação pré-change”, “comandos para os hosts X e Y”, “comandos para o database W”, “script de checagem –full”.
Eu gosto de já deixar copiado o full path do comando e anotar pelo menos umas opções úteis.
Se a change afetará vários servidores ou sistemas que dependem uns dos outros não esqueça de colocar no seu checklist a ordem de stop/start de cada um deles.
Exagere. Minta se precisar.
Baseado na suas anotações quanto tempo você estima que a change vai levar? Multiplique por três e abra o seu change request com esse número.
Normalmente as changes passam por um comitê revisor, conforme comentei no post anterior. Dependendo do nível de babaquice da política da empresa e da criticidade do sistema, eles vão falar pra você fazer em menos tempo. Como você já multiplicou por três pode dar um desconto pra eles.
Algumas empresas mais inteligentes te dão a opção de abrir a change com uma janela de X tempo e execução de Y tempo. Isso significa que você pode abrir uma janela que será das 22:00 às 00:00 para executar uma mudança de 10 minutos. Se você tem essa possibilidade, use-a!
