Compreendendo o uso de SNAPSHOTs de unidades LVM

Olá pessoal,

A algum tempo atrás (ha um ano talvez) venho utilizando LVM2 para quase tudo. Este “cara” é simplesmente fantástico. Mas para muitos pode ficar algumas perguntas (que eu me fiz umas 400 vezes) …

Como funciona a utilização do espaço reservado para um SNAPSHOT de unidades LVM? Porque temos que informar um tamanho para esta “foto”? Em fim…

O tamanho que informamos no comando de criação de um SNAPSHOT (lvcreate -LXX{M,G,T…} -s /dev/VGNAME/LVNAME) é a quantidade de physical extents (PE, ou tamanho em Mb, Gb, etc) que reservamos no VG da unidade LVM para que seja armazenado os metadados das alterações que são sofridas na unidade LVM após a criação do SNAP.

Exemplo:

Se temos uma LV de 1024Bytes e criamos um SNAPSHOT de 300Bytes, e esta unidade de 1024Bytes sofrer alteração total de 300Bytes nosso SNAP aparecerá com 100% de uso. A partir deste momento já não se garante mais a integridade dos dados fotografados, pois o SNAPSHOT não possui mais recursos para armazenar os metadados.

Um teste mais interessante:

De uma LV de 50Gb, cria-se um SNAP de 500Mb:

[root@vostrolab2 ~]# lvcreate -L500M -s /dev/vg01/home -n home-SNAP
Logical volume “home-SNAP” created

Resultado:

[root@vostrolab2 ~]# lvs
LV                   VG   Attr         LSize      Origin   Snap%  Move Log Copy%  Convert

home              vg01 owi-ao  50.00G                        
home-SNAP vg01 swi-a-    500.00M  home    00.04

Vamos criar uma alteração na LV e observar o comportamento do SNAP:

[root@vostrolab2 ~]# dd if=/dev/urandom of=/home/arquivinho-teste.dd bs=1M count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 31.5512 s, 6.6 MB/s

Depois de 5 segundos podemos observar que o SNAP terá sua porcentagem de uso alterada:

[root@vostrolab2 ~]# lvs
LV                   VG   Attr         LSize        Origin Snap%  Move Log Copy%  Convert

home              vg01 owi-ao  50.00G
home-SNAP vg01 swi-a-    500.00M home    40.45

Então:

Regrinha de 3 pra entender os 40,45% de uso do SNAP:

500M ——- 100%
216M ——- X
216 * 100 / 500 = ~42%  =D

E se o SNAP atingir o seu limite de uso…?

Ai meu amigo, reza…  vamos ao lab2:

Crio a LV com 500M,  crio o filesystem ext3 e monto em /cialinux:

[root@vostrolab2 /]# lvcreate -L500M vg01 -n cialinux
Logical volume “cialinux” created
[root@vostrolab2 /]# mkfs.ext3 /dev/vg01/cialinux
[root@vostrolab2 /]# mount /dev/vg01/cialinux /cialinux

Resultado:

[root@vostrolab2 /]# df -h /cialinux
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg01-cialinux
485M   11M  449M   3% /cialinux

Vamos usar 40Mb dela:

[root@vostrolab2 /]# dd if=/dev/urandom of=/cialinux/file1.dd bs=1M count=40
40+0 records in
40+0 records out
41943040 bytes (42 MB) copied, 6.73183 s, 6.2 MB/s
[root@vostrolab2 /]#
[root@vostrolab2 /]# df -h /cialinux
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg01-cialinux
485M   51M  409M  11% /cialinux

Criamos um SNAP e montamos ele para comprovar que está integro e acessível:

[root@vostrolab2 /]# lvcreate -L40M -s /dev/vg01/cialinux -n cialinux-snap
Logical volume “cialinux-snap” created
[root@vostrolab2 /]#
[root@vostrolab2 /]# lvs
LV            VG   Attr   LSize   Origin   Snap%  Move Log Copy%  Convert
cialinux      vg01 owi-ao 500.00M
cialinux-snap vg01 swi-a-  40.00M cialinux   0.03

[root@vostrolab2 /]# mount /dev/vg01/cialinux-snap /cialinux-snap/
[root@vostrolab2 /]#
[root@vostrolab2 /]# df -h /cialinux*
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg01-cialinux
485M   51M  409M  11% /cialinux
/dev/mapper/vg01-cialinux–snap
485M   51M  409M  11% /cialinux-snap

Agora, ao exceder o tamanho de alocação do SNAP (40Mb) com um arquivo de 50Mb, podemos observar a utilização de 100% do espaço reservado ao SNAP no VG01, e como consequência a perda da integridade do SNAP:

[root@vostrolab2 /]# umount /cialinux-snap/
[root@vostrolab2 /]#
[root@vostrolab2 /]# dd if=/dev/urandom of=/cialinux/arquivo-teste2.dd bs=1M count=50
50+0 records in
50+0 records out
52428800 bytes (52 MB) copied, 8.27271 s, 6.3 MB/s
[root@vostrolab2 /]#
[root@vostrolab2 /]# lvs
LV            VG   Attr   LSize   Origin                   Snap%  Move Log Copy%  Convert
cialinux      vg01 owi-ao 500.00M
cialinux-snap vg01 Swi-I-  40.00M cialinux 100.00
home          vg01 -wi-ao  50.00G
[root@vostrolab2 /]#
[root@vostrolab2 /]#
[root@vostrolab2 /]# mount /dev/vg01/cialinux-snap /cialinux-snap/
mount: you must specify the filesystem type
[root@vostrolab2 /]#

Com estes testes concluímos que toda e qualquer alteração de bits na unidade LVM é automaticamente adicionada ao espaço reservado para o SNAPSHOT. Com base nisso, temos sempre que saber a frequencia com a que unidade LVM sofre alterações, caso tenhamos como intenção manter o SNAP por muito tempo.

Um bom teste para um post futuro, seria realizar um lvresize ou lvextend no SNAPSHOT e avaliar se é saudável realizar o aumento no espaço reservado ao SNAPSHOT.

É isso, um post um pouco cansativo, porém pode esclarecer inúmeras dúvidas… Toda e qualquer sugestão/correção será muito bem vinda…

Por: Franklin Moretti

Referências:

testes

man lvcreate

man dd

man lvremove

Alguns termos usados

LV = Logical Volume

LVM = Logical Volume Manager

VG = Volume Group

Atualizando RedHat EL5 e CentOS em modo texto

Bom, para quem está iniciando com esta excelente distribuição Enterprise, e quer manter o sistema devidamente atualizado.

Registrando o sistema no RedHat Network (não necessário para CentOS)

O registro e cadastro do seu sistema junto a ReedHat Network pode ser feito em modo texto, com o comando rhn_register. O aplicativo fará o cadastro de seu sistema, pacotes instalados, configuração de hardware, etc. Isso habilita localmente os repositórios oficiais da RedHat para que posteriormente possamos utilizar o yum para os as atualizações do sistema.

Os passos a serem feitos no rhn_register são simples. neste deve ser informado o usuário e senha de registro de sua licença, informar os dados solicitados e relizar o upload do perfil. Feito isso, já podemos iniciar as atualizações.

Identificando as atualizações disponíveis (valido para CentOS)

Para listarmos as atualizações disponíveis, usaremos a opção check-update do yum:

yum check-update

Com isso já podemos ter uma noção das atualizações necessárias. Assim podemos realizar uma atualização completa:

yum -y update

Ou parcial:

yum -y update NOME_PACOTE

Dica: Sempre utilize o NOME_PACOTE conforme listado pelo comando yum check-update. Isto garante que o pacote a ser utilizado será exatamente o listado. Por que disso?

Ao listarmos os pacote disponíveis via yum check-update ou até mesmo com yum search podemos ter resultados diferentes, tais como:

libgcc.i686 : GCC version 4.4 shared support library
libgcc.x86_64 : GCC version 4.4 shared support library

Nestes casos, podemos ter certeza que o pacote a ser instalado é para a arquitetura desejada. Pacote de bibliotecas para desenvolvimento geralmente estão disponíveis em mais de uma arquitetura.

Por: Franklin Moretti

Referências: man yum

Identificando e eliminando processos Zumbis em Linux

Post curto e muito útil…

Geralmente nos deparamos, ao utilizar o aplicativo de monitoramento de CPU top que nosso sistema Operacional Possui Processos Zumbis (defunct). Abaixo segue uma maneira rápida e simples de identificar e possivelmente eliminar estes processos (nem sempre é possível).

Identificando o processo ZUMBI:

ps aux | awk ‘{print $8 ” pid: ” $2 ” Descricao: ” $11}’ | grep Z

Este terá como saída a identificação Z+ de processo Zumbi, pid: Nº do PID e Descrição: Comando do processo.

Para simplificar podemos utilizar:

ps aux | awk ‘{print $8 ” ” $2 ” ” $11}’ | grep Z

Depois basta matar o PID com kill -1, -4 ou -9, identificando sempre se este não é o processo BASH de algum usuário crítico do sistema.

Outros Status de processos

Além do status Z (Zombie), podemos utilizar no comando ps os seguintes status:

+man ps

D    Uninterruptible sleep (usually IO) Não interrompível
R    Running or runnable (on run queue) Rodando
S    Interruptible sleep (waiting for an event to complete) Interrompível
T    Stopped, either by a job control signal or because it is being traced. Parado
W    paging (not valid since the 2.6.xx kernel) Em paginação (memória)
X    dead (should never be seen) Morto
Z    Defunct (“zombie”) process, terminated but not reaped by its parent. Zumbi

Por: Franklin Moretti

Referências:

http://www.cyberciti.biz/tips/killing-zombie-process.html

man ps

xm block-detach: Removendo um vdisk de uma PVM Xen

Outra dessa noite:

Precisei remover um dos vdisks de uma máquina para-virtualizada em tempo real, sem desligá-la. Tudo isso em cima de CentOS 5.2, com XEN 3.0 e kernel 2.6.18. Pra fazer isso, tem que identificar pela hospedeira qual o ID do disco da hospedada, e mandar fazer um block-detach.

Antes do detach:

[root@pvm /]# fdisk -l

Disk /dev/xvda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/xvda1   *           1        1208     9703228+  83  Linux
/dev/xvda2            1209        1273      522112+  82  Linux swap / Solaris

Disk /dev/xvdb: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/xvdb1               1        1305    10482381   83  Linux
[root@pvm /]#

Então, através da hospedeira, pode-se fazer o detach do xvdb da PVM:

[root@hospedeira /]# xm block-list 5
Vdev  BE handle state evt-ch ring-ref BE-path
51712    0    0     4      8      8     /local/domain/0/backend/vbd/5/51712
51728    0    0     4      9      9     /local/domain/0/backend/vbd/5/51728
[root@hospedeira /]# xm block-detach 5 51728

Sendo que esse ID do dispositivo de bloco é sempre igual para qualquer hospedeira XEN:

xvda = 51712
xvdb = 51728
xvdc = 51744
xvdd = 51760

Depois do detach, apenas um disco permanece na PVM:

[root@pvm /]# fdisk -l

Disk /dev/xvda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/xvda1   *           1        1208     9703228+  83  Linux
/dev/xvda2            1209        1273      522112+  82  Linux swap / Solaris
[root@pvm /]#

Por: Hudson Murilo dos Santos
Referências:  Franklin Moretti
man xm
nabble

Como reduzir o tamanho de um volume lógico sem estragar o sistema de arquivos em Linux

Então,

Essa noite precisei testar o ‘resize’ de uma unidade LVM, mas logo pensei: E o filesystem dentro da unidade, será que vai corromper? Logicamente que sim!

Fiz backup de tudo e iniciei os testes:

Segue ordem que deve ser feita para que você possa comprovar o teste em seu VG, sendo que tem que ter no mínimo 100M de espaço disponível.

Primeiro cria-se o volume LVM com nome teste dentro de um VG já existente (volume_group):

lvcreate –size=100M –name=teste volume_group

Unidade criada, cria-se o sistema de arquivos ext3 dentro dela para testes:

mkfs.ext3 /dev/mapper/volume_group-teste

Sistema de arquivos criado, unidade pode ser mapeada para escrever algo dentro:

mkdir /teste && mount /dev/mapper/volume_group-teste /teste
vi /teste/texto.txt (escreva algo dentro)

Agora, depois de desmontar a unidade com umount, pode-se fazer o shrink (encolhimento, redução, como quiser) de forma correta:
Deve ser feita a checagem com o e2fsck usando parâmetro -f para marcar o sistema de arquivos como ‘checado’ mesmo se ele está OK para o sistema operacional…

e2fsck -f /dev/mapper/volume_group-teste

Depois o resize propriamente dito do sistema de arquivos ext3:

resize2fs /dev/mapper/volume_group-teste 50M

Agora é a hora do que nos interessa: resize do volume lógico

lvresize -L 50M /dev/mapper/volume_group-teste

Pode-se então conferir que o sistema operacional continua conseguindo ler a partição, através de um particionador comum modo texto:

parted /dev/mapper/volume_group-teste

Pode-se também repetir o e2fsck para verificar que realmente o sistema de arquivos está sem problemas..
Pode-se conferir que os dados estão íntegros:

mount /dev/mapper/volume_group-teste /teste && cat /teste/texto.txt

Por fim, remove-se a unidade criada para testes:

lvremove /dev/mapper/volume_group-teste

Obs.: Se a ordem acima for ‘atropelada’ e o resize da partição LVM for feito antes do resize do sistema de arquivos, o sistema de arquivos vai corromper, porém arquivo teste.tx pode continuar sendo lido pelo sistema operacional. Dai para corrigir o sistema de arquivos, teria que passar um fsck e rezar para que tudo consiga ser re-construído.

Muito importante: Por mais que tudo isso tenha sido testado em CentOS 5.2 e CentOS 5.3, e que pela Internet a fora tenha mais um monte de posts informando que esse procedimento dá certo, o risco sempre existe! Então, nunca deixe de realizar backup completo (seguido de conferência do backup) antes de realizar esse tipo de manutenção para shrink de partição LVM. Fica a dica!

Por: Hudson Murilo dos Santos
Referências: Google
man lvresize
man e2fsck
man resize2fs

Muito importante: Por mais que

Como documentar soluções/tecnologias complexas em T.I.?

Bom,

Fugindo um pouco (bem pouco) da escovação de bits e bytes que costuma ser os posts aqui, vou abordar um tema um tanto quanto apavorante na vida de um analista de informática.

ONDE ESTÁ A DOCUMENTAÇÃO DOS SEUS PROJETOS, DAS TECNOLOGIAS QUE VOCÊ IMPLEMENTA?
ESSA DOCUMENTAÇÃO É MANTIDA ATUALIZADA POR ALGUÉM?
ESSA DOCUMENTAÇÃO SERVIRÁ PARA O PRÓXIMO ENTENDER MAIS RAPIDAMENTE A SOLUÇÃO E GARANTIR A CONTINUIDADE DE NEGOCIO?

De todas as empresas de T.I. que já trabalhei/prestei serviço/conhecí, nunca vi uma que consiga seguir à risca..

Embora existam N maneiras simples e conhecidas para documentar de forma simples e organizada aquilo que se faz (que geralmente sai do cérebro de analistas no dia-a-dia), muitas vezes o problema da não documentação nem parte da equipe técnica executora. Conheço casos em que a própria equipe gestora que não prevê tempo em cronograma de projeto para documentação, não fomenta a equipe com ferramentas/técnicas de documentação adequadas, e não exige com punho firme que a documentação seja minusciosamente elaborada…muito menos aloca uma pessoa operacionalmente para menter documentação..

A questão é que as equipes técnicas poderiam entregar muito mais, mas as equipes gestoras poderiam trabalhar melhor os os ítens mencionados acima…

Bom essa é minha humilde opinião, como diria o Franklin..

Segue algumas formas legais para documentação de infraestrutura de sistemas operacionais/redes/aplicações, etc.. Todos utilizaveis em ambiente 100% sofware livre..

BLOG – Jogue no Blog que você sempre terá onde recorrer quando não lembra algum procedimento, ou quando alguém lhe pergunta como faz “tal coisa”…

MediaWiki – Quem não conhece o estilão Wiki do WikiPedia? O MediaWiki é um tanto quanto simples de implementar, basta uma máquina Linux, o banco de dados e os pacotes baixados no próprio site oficial…
Para documentar é muito legal, além de ser simples de outras pessoas exercitarem “colaboração” nas páginas de documentação..
Vale ressaltar a importância de se estruturar bem a árvode de assuntos antes de iniciar as documentações, sempre linkando na página inicial os artigos e manuais que vão sendo publicados (estilo main menu).

gtk-recordMyDesktop – Muita gente não conhece essa poderosa ferramenta para gravação da área de trabalho… Geralmente utilizo ela em Linux, pra executá-la em outros sistemas operacionais, basta adequar as libs do GTK. Ela possibilita inclusive a gravação de som através de microfone junto com o vídeo. Da pra fazer uns tutoriais legais…

freemind e xmind – Fluxograma é coisa do passado? Pode ser que o nome sim, mas a idéia dos Mapas Mentais continua firme e forte simplificando o raciocínio a cerca de estruturas complexas. Pra que dificultar se podemos facilitar?

Era isso… Utilizando esse conjunto de técnicas acima, com um pingo de criatividade / organização / disciplina, é possível documentar em tempo real tudo o que se faz no dia-a-dia de Infraestrutura. Se fizermos o mínimo de nossa parte como técnicos, poderemos exigir melhores condições de planejamento da parte da equipe gestora dos projetos

A todos eu desejo um ótimo início de 2010.

Por: Hudson Murilo dos Santos

Referências:
Dias de trabalho com o Franklin;
Experiência em diversos ambientes não documentados;
Professores do curso GerProTI;
As demais referências foram linkadas no nome dos produtos de software;

PAM: Module is unknown ao tentar logar

Hola, que tal?

Este erro me perturbou a manhã de hoje, então resolvi compartilhar o conhecimento..

Quando digtava usuário e senha no console pra logar na máquina CentOS 5, dava essa mensagem e retornava para o prompt solicitando usuário e senha:

Module is unknown

Por sorte, eu tinha acesso SSH na mesma máquina, e por SSH isso não aconteceu..

Dei uma checada no /var/log/secure:

Dec  3 11:31:01 maq01 login: PAM unable to dlopen(/lib/security/pam_limits.so)
Dec  3 11:31:01 maq01 login: PAM [error: /lib/security/pam_limits.so: wrong ELF class: ELFCLASS32]
Dec  3 11:31:01 maq01 login: PAM adding faulty module: /lib/security/pam_limits.so
Dec  3 11:31:05 maq01 login: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
Dec  3 11:31:05 maq01 login: Module is unknown

Então, após algumas pesquisas na Internet, cheguei à conclusão que comentando as seguintes linhas no arquivo /etc/pam.d/login resolveria:

#session    required     /lib/security/pam_limits.so
#session    required     pam_limits.so

Feito. Sucesso! /var/log/secure após a alteração:

Dec  3 11:40:12 maq01 login: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
Dec  3 11:40:13 maq01 login: ROOT LOGIN ON xvc0

Como a máquina é x86_64 e o módulo é 32-bits, talvez fosse um problema de arquitetura, e teria que instalar os módulos do pam em sua compilação x86_64:

[root@maq01 security]# uname -a
Linux maq01.localdomain 2.6.18-53.1.21.el5xen #1 SMP Tue May 20 10:03:27 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
[root@maq01 security]# file /lib/security/pam_limits.so
/lib/security/pam_limits.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped

Mas como o tempo é curto, e outros Linux da rede não tinham aquelas duas linhas no /etc/pam.d/login, resolvi comentando a linha mesmo e vou tirar um tempo pra estudar melhor o que tudo isso faz, motivos, etc.. (escovação de bit)

Por: Hudson Murilo dos Santos
Referência: http://www.centos.org/modules/newbb/print.php?form=1&topic_id=16329&forum=44&order=ASC&start=0

Mapeando partições em LVs LVM (kpartx)

Esta dica é especial para quem trabalha com virtualização (Xen/KVM), e faz muito uso de unidades lógicas LVM, mas não significa que não possa ser usada para outros fins …

Bom normalmente em ambientes de virtualização com XEN ou KVM utilizamos unidades lógicas LVM para servirem de disco para as VMs. Pois bem, isso leva a unidade LVM a ser formatada e particionada, tornando ela uma “mini fortaleza”, hehehe. Caso seja necessário visualizar e montar estas partições criadas na unidade lógica temos que mapea-las como device no S.O Linux. Para isso, podemos utilizar o comando kpartx, conforme sintaxe abaixo:

kpartx -a /dev/NOME_VG/UNIDADE_LOGICA

Isso vai mapear e disponibilizar todas as partições desta unidade lógica para serem manipuladas a gosto… As partições, ficarão visíveis em /dev/mapper/UNIDADE_LOGICA1, /dev/mapper/UNIDADE_LOGICA2, /dev/mapper/UNIDADE_LOGICA3 e assim por diante.

Um exemplo rápido.

Criamos uma unidade lógica LVM com o nome cialinux:

[root@xen01 mapper]# lvcreate -L5G LVM -n cialinux
Logical volume “cialinux” created

Nela criamos 3 partições com o fdisk:

[root@xen01 mapper]# fdisk -l /dev/LVM/cialinux

Disk /dev/LVM/cialinux: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/LVM/cialinux1               1          13      104391   83  Linux
/dev/LVM/cialinux2              14          76      506047+  82  Linux swap / Solaris
/dev/LVM/cialinux3              77         652     4626720   83  Linux

Agora vamos mapear as partições que criamos para poder formata-las:

kpartx -a /dev/LVM/cialinux

Isso nos disponibiliza:

[root@xen01 mapper]# ls -l /dev/mapper/cialinux*
brw-rw—- 1 root disk 253,  8 Aug 23 14:05 /dev/mapper/cialinux1
brw-rw—- 1 root disk 253,  9 Aug 23 14:05 /dev/mapper/cialinux2
brw-rw—- 1 root disk 253, 10 Aug 23 14:05 /dev/mapper/cialinux3

Agora podemos fazer oque quiser com estas partições. Vamos criar um sistema de arquivos ext3 na partição 3, e depois monta-la em /mnt/cialinux:

[root@xen01 mapper]# mkfs.ext3 -v /dev/mapper/cialinux3

[root@xen01 mapper]# mount /dev/mapper/cialinux3 /mnt/cialinux/

E o resultado…

[root@xen01 mapper]# df -h /mnt/cialinux
Filesystem                                      Size  Used Avail Use% Mounted on
/dev/mapper/cialinux3             4.4G  137M  4.0G   4% /mnt/cialinux

Para retirarmos o mapeamento destas unidades, basta usar a opção -d do comando kpartx (com tas as partições desmontadas):

[root@xen01 mapper]# kpartx -d /dev/LVM/cialinux

Era isso pessoal. Abraços..!

Por: Franklin Moretti

Gerando LOG de execução de scripts

Cada administrador de redes/datacenter tem sua própria forma de administrar servidores/serviços. Uma coisa que todo mundo faz, ou pelomenos deveria fazer é a avaliação de logs.

Quando estamos falando em recursos nativos do sistema operacional, eles já vem programados para serem logados pelo syslogd, gerando assim output em diferentes arquivos dentro de /var/log/<tipo>.

Mas e quando estamos falando de análise de logs daquelas rotinas de automação implementadas por nós mesmos?? Como gerar estes logs e administrá-los de forma simples e objetiva?

Existem variadas formas de se fazer. Nesse POST estão algumas das formas que conheço e utilizo bastante…

Uma delas é através do comando logger, que gera entradas nos logs do syslogd. Para utilizá-lo basta fazer algo do tipo:

#!/bin/sh

echo “Inicio de rotina..” | logger

comando_01 | logger
comando_02        # esse não quero output…
comando_n   | logger

echo “Fim de rotina..” | logger

Através do “logger”, a entrada no log já acontece com timestamp e usuário, conforme abaixo:

hudson@vostrolab:~$ tail -3 /var/log/messages
Aug 23 11:55:37 vostrolab logger: Inicio de rotina…
Aug 23 11:55:51 vostrolab logger: tramite
Aug 23 11:56:00 vostrolab logger: Fim de rotina

Outra forma que é amplamente utilizada é o Administrador criar um arquivo de log e jogar todo output desejado dentro, criando seu próprio timestamp conforme abaixo:

#!/bin/sh
LOG=/var/log/arquivo.log

echo “[`date`] ==== Inicio de rotina…” >> $LOG

comando_01 >> $LOG
comando_02                                 # esse não quero output…
comando_n   >> $LOG

echo “[`date`] ==== Fim de rotina…” >> $LOG

Esse método acima é ótimo, e possibilita gravar em log apenas pontos específicos do shellscript.. O output fica mais ou menos assim:

[Sun Aug 23 12:03:53 BRT 2009] ==== Inicio de rotina…
output do tramite de comandos
[Sun Aug 23 12:04:01 BRT 2009] ==== Fim de rotina…

Existe outra forma bem conhecida e menos “suja” pro código, de gravar toda a saída de um script em um arquivo de log.. com uma desvantagem de não se conseguir especificar exatamente os pontos que se deseja gravar no log…
Segue:

#!/bin/sh
LOG=/var/log/arquivo.log
exec 1>>${LOG}
exec 2>&1
echo “[`date`] ==== Inicio de rotina…”
comando_com_output01
comando_com_output02
echo “[`date`] ==== Fim de rotina…”

Assim não é necessário ficar colocando “>>” para redirecionar a saída em todos os comandos… basta fazer o comando dentro do script e todo o STDOUT e STDERR será colocado no log especificado.

Boas práticas que recomendo:

1.Não use mais de 01 arquivo de log por script, pois dificulta a administração depois;
2.Faça logs bonitos e organizados, você vai ver como isso é importante o dia que tiver que levar um log impresso na mesa da diretoria de sua empresa;
3.Crie um diretório /var/log/scripts_locais/ para armazenar os logs de todos os scripts customizados de rotina de determinado sistema operacional;
4. Dentro desse diretório acima, tente usar o nome do shell para gerar o log;

Pode ser algo mais ou menos assim na hora de definir a variavel LOG:

SCRIPT=`basename $0`
LOG=`echo /var/log/scripts/$SCRIPT | sed s/’.sh’/’.log’/g`

Fica aí a dica!! Se achar interessante em algum caso, aproveite…

Por: Hudson Murilo dos Santos

Referências:

man logger
man bash

LOG=`echo /var/log/scripts/$_SCRIPT | sed s/’.sh’/’.log’/g`

Sistemas em diferentes fuso horários – timezone TZ

Dica rápida para quem administra servidores que hospedam sistemas que devem ser acessados por diferentes fuso horários.

Imagine que você hospeda um sistema qualquer que grava a hora em que um pedido foi cadastrado na base de dados. Seus clientes gostam do sistema e tudo funciona muito bem até que um dia você tem clientes que estão em Manaus/AM por exemplo, onde o fuso horário é diferente.

E agora? Como é que o mesmo sistema vai entender isso?

Em ambientes Unix like existe a variavel de ambiente TZ, que permite que diferentes programas/bancos de dados sejam carregados com diferentes configurações de fuso horário (timezone).

A seguir tem um breve video caseiro demonstrando como funciona… Vale lembrar que utilizei apenas o comando “date” pra mostrar a alteração no horário, mas qualquer software/sistema/banco que for carregado com a variavel TZ configurada, vai entender que o horário é aquele.

Por: Hudson Murilo dos Santos

Referências:

Daniel Bristot de Oliveira
http://www.cyberciti.biz/faq/howto-linux-unix-change-setup-timezone-tz-variable/
http://ingleses.datasul.com.br/blog/post/2009/01/28/Bases-Progress-com-fuso-horario-diferentes.aspx