Como muitos programadores sabem, organização é tudo quando falamos sobre ” saber programar “. Uma pequena aula de “etiqueta” para quem está chegando ou até mesmo para aqueles que querem aprender a se organizar. Seguem 10 dicas úteis para todos nós, programadores, experientes ou não.

1. Especificar qual SHELL será utilizado

É pré-requisito em qualquer programa escrito em SHELL SCRIPT definir qual SHELL será utilizado.

A imagem acima ilustra como seria em sistemas GNU/Linux. No FreeBSD seria: #!/usr/local/bin/bash

2. Comentários e descrição do Script

Esta seção tem como objetivo descrever o objetivo do script e suas funcionalidades. Isso te ajuda a lembrar porque o script foi escrito, e para qual função.

3. Declarar variáveis

Muitas vezes, observo scripts sem declaração de variáveis. Isso impacta no funcionamento dos comandos ao longo do script.

Lembre-se: Quando o script é executado, será aberto um novo SHELL e com isso nenhuma variável declarada de sua sessão atual será utilizada. Declarar variáveis é PRIMORDIAL, assim como em qualquer outra linguagem de programação.

4. Identação

Muitas pessoas acreditam que identar scripts não é necessário. Para funcionar não, porém para entendimento próprio ou de outro DBA / analista é extremamente necessário. identação é sinônimo de organização e facilita o entendimento posterior.

5. Comentários fase-a-fase

Procure descrever em comentários o que cada parte do script irá executar. Isso lhe ajudará a fazer melhorias e “debugar” possíveis problemas futuros.

6. LOGs

Mantenha logs de todos os seus scripts. Preferencialmente especificando o arquivo de LOG dentro do script, como variável. Para análise posterior em execuções será muito mais fácil encontrar possíveis erros.

Utiliza preferencialmente arquivos de LOGs com datas, isso previne que arquivos de LOGs sejam sobrescritos.

7. Corpo do Script (Body)

Utilize suas variáveis declaradas no início do script. Isso ajuda a não fixar valores, podendo reaproveitar o script posteriormente.

8. Valide a execução de cada comando

De nada adianta um script que executa cem tarefas e não valida nenhuma. Isso é o mais COMUM de se ver em scripts. Um comando executao sem análise de “Return Code” não tem integridade alguma. Procure sempre analisar passo-a-passo sua execução.

9. Mantenha nomes coerentes

Procure manter o nome de seus scripts coerentes. Procure relacionar o nome com a atividade. Ex: “bkp_rman_full.sh”, “bkp_expdp_full.sh”, etc..

10. Valide sempre as execuções de seus scripts

Este provavelmente é o passo mais importante. Valide sempre as execuções de seus scripts, acompanhe os logs (diários, mensais etc). Neles você poderá encontrar erros ou melhorias. Se possível, implemente algum recurso de monitoração.

Fonte:Imasters

O nosso grande mestre de programação Shell, Júlio Cezar Neves, disponibiliza em seu site , um curso completo de programação shell.

A novidade maior é que os artigos já foram traduzidos integralmente para o espanhol e podem ser acessados a partir do mesmo endereço. Agradecemos a quem puder ajudar divulgando o trabalho para os países de língua espanhola.

A tradução dos artigos para o inglês ainda não foi completada. Procura-se voluntários 🙂

Finalizando, para usar esta página como um manual de referência, basta escrever na caixa de texto, que está no canto superior esquerdo de todas as páginas, o comando que você deseja se aprofundar e clicar no botão Procure Comando no Botequim.

Para finalizar, como diz o Júlio:

“Pra programar shell não é preciso Texaco”

Hoje venho falar de um complemento à segurança que é a visualização diária dos logs. Todo sysadmin deve olhar os logs diariamente para verificar possíveis problemas, tentativas de acessos não autorizados, ataques aos seus serviços, problemas com o hardware e por aí vai. Os logs estão aí para nos ajudar e embora seja um serviço trabalhoso, cansativo e chato, são os logs que nos salvam muitas das vezes.

O FreeBSD vem com uma ferramenta chamada Periodic que é um conjunto de shell scripts prontos e rodado pelo cron. Esses scripts são localizados em /etc/periodic, separados por:

daily
weekly
monthly
security

Os scripts nesses diretórios rodam diariamente, semanalmente e mensalmente. Os scripts em security também rodam diariamente mas são relacionados com segurança.

Se você gosta de aprender coisas novas e entende de shell script, dê uma olhada nesses scripts pois são muito interessantes e usam os comandos do sistema para isso. É uma forma de aprender mais sobre o sistema.

Nesse post, vamos instalar o portaudit, uma ferramenta que usamos para checar se temos alguma vulnerabilidade em pacotes que foram instalados do ports. Instalaremos o pacote ssmtp para envio dos logs por e-mail, para os servidores que vamos querer monitorar mas sem a necessidade de se ter um servidor de correio local. Por último faremos uma configuração no Periodic para que ele nos envie esses relatórios de segurança, diários, semanais e mensais.

Vamos começar com o portaudit que após instalado já adiciona um script dele para o periodic. O portaudit é usado para baixar uma listagem de vulnerabilidades do VuXML e checar se você tem alguma vulnerabilidade relacionada. Em caso positivo uma mensagem será mostrada apontando a vulnerabilidade ou vulnerabilidades que você tenha.

# cd /usr/ports/ports-mgmt/portaudit
# make install clean
# rehash       <- se tiver usando csh

O portaudit, como eu disse anteriormente, já instala um script no periodic conforme abaixo:

# pkg_info -L portaudit-0.6.0
Information for portaudit-0.6.0:

Files:
/usr/local/man/man1/portaudit.1.gz
/usr/local/sbin/portaudit
/usr/local/etc/portaudit.pubkey
/usr/local/etc/portaudit.conf.sample
/usr/local/etc/periodic/security/410.portaudit

Quando quiser checar manualmente por vulnerabilidades basta executar: portaudit -Fda

Nesse momento vamos instalar o ssmtp. Esse programa é útil quando a máquina monitorada não é um servidor de e-mail e você não quer instalar um SMTP  Server só para enviar os relatórios do periodic. Se a máquina estiver rodando um Servidor de Correio, não instale o ssmtp pois ele irá desconfigurar o seu servidor. Nesse caso pule a configuração abaixo e vá direto para a configuração do periodic.

# cd /usr/ports/mail/ssmtp
# make install clean
# make replace
# rehash     <- se tiver usando csh

Continuando a configuração do ssmtp, vamos precisar alterar 2 arquivos apenas que ficam em /usr/local/etc/ssmtp. Vamos supor que eu queira usar uma conta de e-mail qualquer, em algum servidor, para enviar os relatórios. Vamos aos dados fictícios abaixo:

• servidor de e-mail: smtp.teste.com.br – porta 587/tcp para envio de e-mail autenticado conforme recomendação do Comitê Gestor.
• conta de e-mail: relatorio@teste.com.br
• senha da conta de e-mail: zUngA2378

Iremos usar esses dados acima para o envio de qualquer e-mail desse servidor que estamos configurando. Agora faremos o seguinte:

# cd /usr/local/etc/ssmtp
# touch revaliases
# touch ssmtp.conf
# chmod 640 revaliases ssmtp.conf
# chown root:ssmtp revaliases ssmtp.conf

Dentro do arquivo ssmtp.conf colocaremos a seguinte configuração do nosso exemplo:

root=postmaster
mailhub=smtp.teste.com.br:587
rewriteDomain=teste.com.br
hostname=_HOSTNAME_
UseSTARTTLS
AuthUser=relatorio@teste.com.br
AuthPass=zUngA2378

Dentro do arquivo revaliases colocaremos a configuração abaixo:

root:relatorio@teste.com.br:smtp.teste.com.br:587

Lembrando que esses dados citados são fictícios e você deve substituí-los pelos seus dados reais.

Feito essas configurações você pode testar enviando um e-mail para você dessa forma:

# mailx -s teste joaobobo@gmail.com <<EOF
Teste de envio de e-mail.
EOF

Bem, se você fez o teste acima sem trocar o e-mail: joaobobo@gmail.com pelo seu e-mail, então pare por aqui e estude mais.  🙂

Se tudo der certo você receberá um e-mail vindo do e-mail configurado no ssmtp e provando que está tudo funcionando como deveria.

Vamos agora finalizar a nossa configuração do periodic. Criaremos o arquivo /etc/periodic.conf e dentro deste colocaremos essas 5 linhas abaixo:

#!/bin/sh
daily_output=”joaobobo@gmail.com”
weekly_output=”joaobobo@gmail.com”
monthly_output=”joaobobo@gmail.com”
daily_status_security_output=”joaobobo@gmail.com“

Nas linhas acima estaremos enviando os relatórios diários, semanais, mensais e de segurança para o e-mail: joaobobo@gmail.com.

Você pode consultar o arquivo /etc/defaults/periodic.conf para servir de referência e não deve alterar esse arquivo. Se quiser usar alguma variável de lá, copie ela e use no /etc/periodic.conf.

Bem, feito isso aguarde os relatórios que eles chegarão conforme configurado no /etc/crontab.

# Perform daily/weekly/monthly maintenance.
1       3       *       *       *       root    periodic daily
15      4       *       *       6       root    periodic weekly
30      5       1       *       *       root    periodic monthly

É isso e vejo vocês em breve.

Comecei minha vida *NIX usando Xenix e SCO Unix, nessa época usava “sh” como shell e “vi” como editor, isso era em 1991 à 1994 se eu me recordo bem. Nessa época eu era Programador Clipper Summer 87 no mundo DOS e Programador COBOL no mundo *NIX. Em 1996 me apresentaram minha primeira distribuição GNU/Linux, o Slackware cujo kernel era o Linux 1.2.13. Com o tempo comecei à usar o bash e o vim no lugar dos anteriores e gostei destes pois eram mais amigáveis e no caso do bash parecia ter mais recursos.  🙂  Em 2010 quando comecei à usar o FreeBSD tentaram me convencer à usar o csh/tcsh, tentei mas o vício no bash foi mais forte. rsrsrs  Então resolvi adaptar o ambiente shell que eu tinha no GNU/Linux para o FreeBSD e baseado nessa tentativa fiz um script para automatizar o processo. O script abaixo é livre para ser usado e alterado e estou aceitando melhorias.  😀

O que esse script faz é o seguinte:

1º – Atualiza o Ports.

2º – Instala o bash.

3º – Muda a shell do root para bash.

4º – Muda o prompt na shell para um prompt mais informativo. Fique à vontade de alterar para o seu gosto, se já possuir algum. Se estiver logado como root a palavra “root” fica em vermelho para lembrar de ter cuidado por estar logado como root.

5º – Cria os aliases: “l” para listar muito mais informação como arquivos e diretórios que comecem com “.”, com identificação colorida diferenciando diretórios, arquivos executáveis dentre outros. Também inclui na listagem a coluna de flags modificada pelo utilitário chflags que é um utilitário muito importante em configurações de segurança. “rm”, “mv”, “cp” com o parâmetro “-i” para forçar uma confirmação se realmente quer apagar, mover ou copiar por questões de segurança. Como os aliases possuem o mesmo nome dos comandos se quiser rodá-los em sua forma original, ou seja, sem o “-i” basta rodar o comando com uma “\” antes. Exemplos:

Usando o alias com o “-i”:

# rm teste
remove teste?

Usando o comando sem o “-i”, anulando o alias:

# \rm teste
#

Também é adicionado o alias “vi” apontando para o editor vim.

6º – Instala e configura o vim.

7º – Configura teclas como home, end e del para funcionarem amigavelmente.

Abaixo o script:

#!/bin/sh
# MyFreeHome 1.2: Configura ambiente amigavel no FreeBSD
# ======================================================
# Data: 20/09/2011
# Hora: 23:59
# Baseado no documento: http://www.cyberciti.biz/faq/freebsd-install-vim-editor-without-x11-gui/
##############################################################
clear
echo “=== MyFreeHome 1.2 ===”
echo
echo “Atualizando Ports…”
echo
portsnap fetch update
echo
echo “Instalando BASH…”
echo
cd /usr/ports/shells/bash
make install clean distclean
echo
echo “Mudando shell do root para bash…”
pw usermod root -s /usr/local/bin/bash
echo
echo “Instalando novo prompt e aliases…”
echo “if [ \`/usr/bin/whoami\` = ‘root’ ]” >> /root/.profile
echo ”   then” >> /root/.profile
echo ”        PS1=’\[\033[36m\](\[\033[01;31m\]\u\[\033[01;37m\]@\h\[\033[00m\]\[\033[36m\])\[\033[00m\]\[\033[36m\][\[\033[01;37m\]\w\[\033[00m\]\[\033[36m\]]\[\033[01;37m\]\[\033[36m\]\\$ \[\033[00m\]'” >> /root/.profile
echo ”   else” >> /root/.profile
echo ”          PS1=’\[\033[36m\](\[\033[32;33;1m\]\u\[\033[01;37m\]@\h\[\033[00m\]\[\033[36m\])\[\033[00m\]\[\033[36m\][\[\033[01;37m\]\w\[\033[00m\]\[\033[36m\]]\[\033[01;37m\]\[\033[36m\]\\$ \[\033[00m\]'” >> /root/.profile
echo “fi” >> /root/.profile
echo “” >> /root/.profile
echo ‘alias l=”ls -laAGo”‘ >> /root/.profile
echo ‘alias rm=”rm -i”‘ >> /root/.profile
echo ‘alias mv=”mv -i”‘ >> /root/.profile
echo ‘alias cp=”cp -i”‘ >> /root/.profile
echo ‘alias vi=”vim”‘ >> /root/.profile
echo
echo “Instalando VIM sem suporte a X11…”
cd /usr/ports/editors/vim
make WITHOUT_X11=yes install clean distclean
cp /usr/local/share/vim/vim73/vimrc_example.vim /usr/local/share/vimrc
touch /root/.vimrc
echo “set nocompatible” >> /root/.vimrc
echo “filetype on” >> /root/.vimrc
echo “filetype plugin on” >> /root/.vimrc
echo “set laststatus=2” >> /root/.vimrc
echo “syntax on” >> /root/.vimrc
echo
echo “Criando melhorias no sistema…”
echo
echo “export INPUTRC=/usr/local/etc/inputrc” >> /etc/profile
echo “set meta-flag on” >> /usr/local/etc/inputrc
echo “set input-meta on” >> /usr/local/etc/inputrc
echo “set convert-meta off” >> /usr/local/etc/inputrc
echo “set output-meta on” >> /usr/local/etc/inputrc
echo “” >> /usr/local/etc/inputrc
echo ‘”\e[1~”: beginning-of-line’ >> /usr/local/etc/inputrc
echo ‘”\e[4~”: end-of-line’ >> /usr/local/etc/inputrc
echo ‘”\e[5~”: beginning-of-history’ >> /usr/local/etc/inputrc
echo ‘”\e[6~”: end-of-history’ >> /usr/local/etc/inputrc
echo ‘”\e[3~”: delete-char’ >> /usr/local/etc/inputrc
echo ‘”\e[2~”: quoted-insert’ >> /usr/local/etc/inputrc
echo ‘”\e[5C”: forward-word’ >> /usr/local/etc/inputrc
echo ‘”\e[5D”: backward-word’ >> /usr/local/etc/inputrc
echo
echo ” Fim de instalacao! Favor relogar e bom uso!”
echo

Testem o script primeiramente em um ambiente de testes, se gostarem do resultado então façam bom proveito deste.

Para quem ainda não tem um script para fazer seus backups. Abaixo um script que utilizo muito e venho compartilhar com todos vocês. Tirando a brincadeira de ser Sexta-Feira 13 um bom backup já salvou minha cabeça muitas vezes e pelos diversos motivos. Alguns deles:

1) HD foi pro saco. Esse sem dúvida é o mais comum.
2) Programador fez uma besteira e ferrou uma determinada tabela da base de dados MySQL. Aconteceu 2 ou 3 vezes comigo. Não sou o programador, só avisando. rsrsr
3) O mesmo programador apagou alguns arquivos de desenvolvimento dele.

E por aí vai… não importa o que foi apagado e sim o dano que isso lhe causará se não tiver o devido backup.
Ou como eu diria em outras palavras: “O salame vai vir você só vai ter que escolher se inteiro ou fatiado!”

Para esse script funcionar basta configurar as variáveis no topo e criar o diretório definido na variável TEMP. Não esqueça de configurar a senha e usuário do mysql para que o script possa fazer os backups e o seu e-mail para que recebas uma notificação sempre que o backup for concluído.

Outra coisa: esse script na verdade gera o backup sempre no mesmo lugar do servidor. Você deveria ter um outro script para coletar esse backup já no Servidor de Backup e armazená-lo conforme suas necessidades. Ex.: com separação por data, mas isso colocarei em um próximo post. Fiquem à vontade em melhorar esse script e se puderem compartilhar as melhorias, elas serão muito bem vindas.  😀

Alguns admins já usam o DNSSec e provavelmente já fizeram alguma ferramenta para administrar sua lista de domínios. Agora se você tem diversos domínios para converter em DNSSec, precisa fazer a atualização dos mesmos periodicamente e não possui nenhuma ferramenta para isso, seus problemas acabaram. rsrsr Vou mostrar aqui 2 scripts que fiz a long long time que podem lhe ajudar nessa tarefa. Ah! Se você não sabe ainda o que é o DNSSec, porque ele é necessário e como ele funciona aqui vai uma leitura bem bacana nesse link: Porque DNSSec

Então vamos para o nosso primeiro script, o dnssecconv.sh, onde este irá pegar todos os arquivos de domínios com extensão .db, criar as chaves deles, fazer as devidas modificações no named.conf e gerar um arquivo com os dados que precisa para cadastro no Registro.br:

O script dnssecconv.sh deve estar no mesmo diretórios dos arquivos de domínio e antes de rodá-lo faça um backup, porque não me responsabilizo por qualquer dano que esse script possa causar. Estou aqui para ajudar e não para ser responsabilizado por algo.  🙂

Em tempo o arquivo gerado com as informações que você vai precisar é este: dnsseclist.txt

O segundo script é mais simples e só serve para atualizar as chaves, porque de tempo em tempo o Registro.br solicita essa atualização senão o domínio pára de funcionar. Esse script se chama dnssecsync.sh e também deve ser rodado no diretório onde se encontram os arquivos de domínios. Mais uma vez não esqueça do backup. 😉