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

Listando arquivos instalados por um RPM (–filesbypkg)

Olá pessoal, segue mais uma dica rápida e que sempre me faz ler o man do rpm quase inteiro quando preciso… hahaha

Desta vez vai ficar registrado… 

Com certeza, assim como eu, muitos já se depararam com a situação em que instalou um pacote RPM, via rpm ou até mesmo via yum, e não sabe quais são os binários e arquivos que este pacote instalou..    PUTS…

Isso aconteceu comigo agora a pouco, ao instalar o pacote thewidgetfactory-0.2.1-9.fc11.x86_64. Como instalei via YUM não fui atrás de informações do que ele instalaria, e adivinhem.. Não sabia como iniciar o SIMPLES programa TheWidgetFactory . Como sempre, minha memória me deu um golpe.. (como é que se lista os arquivos que um RPM instalou mesmo…?)

Lá vai o coitado para o “man rpm”… hehehehehe

Para listar os arquivos instalados por um determinado pacote é necessário passar para a opção -q (–query) do rpm a opção –filesbypkg, que será retornado a lista de arquivos que o pacote instalou. Segue o exemplo que gerou a ideia deste post    :

[root@MORETTI ~]# rpm -qa |grep widget
thewidgetfactory-0.2.1-9.fc11.x86_64

[root@MORETTI ~]# rpm -q –filesbypkg thewidgetfactory-0.2.1-9.fc11.x86_64
thewidgetfactory          /usr/bin/twf
thewidgetfactory          /usr/share/applications/fedora-thewidgetfactory.desktop
thewidgetfactory          /usr/share/doc/thewidgetfactory-0.2.1
thewidgetfactory          /usr/share/doc/thewidgetfactory-0.2.1/COPYING
thewidgetfactory          /usr/share/doc/thewidgetfactory-0.2.1/ChangeLog
thewidgetfactory          /usr/share/doc/thewidgetfactory-0.2.1/README

Que maravilha..! Eis o “maladeto” binário que eu queria… \o/ (/usr/bin/twf ).

Para termos o efeito contrário, no qual precisamos descobrir qual RPM instalou determinado arquivo, a opção a ser passada para o  -q (–query) é -f (–file). Na situação anterior ficaria assim:

[root@MORETTI ~]# rpm -qf /usr/bin/twf
thewidgetfactory-0.2.1-9.fc11.x86_64

Acho que é isso. Abraços..

Por: Franklin Moretti

Fonte: man rpm

Identificando novos devices SCSI no Linux

Essa dica é pra quem trabalha com STORAGE em Linux por exemplo, e precisa identificar devices de disco mapeados via fibra (esse foi o meu caso de uso).

Fazendo algumas alterações em arquivos “chave” do sistema de arquivos /proc, o sistema Linux é ensinado a fazer um “flush” nos devices e mapeá-los novamente.

Segue pequeno script, que pode ser nomeado como scsi-scan.sh:

#!/bin/sh
#
echo “1″ > /sys/class/fc_host/host5/issue_lip
echo “- – -” > /sys/class/scsi_host/host5/scan
#
echo “1″ > /sys/class/fc_host/host6/issue_lip
echo “- – -” > /sys/class/scsi_host/host6/scan

Neste momento, se tudo deu certo, os devices serão identificados e listados no dmesg.

Por: Hudson Murilo dos Santos

Referência:

http://www.scribd.com/doc/11477956/EMC-PowerPath-for-Linux-51-Install-and-Admin-Guide

Remontando a unidade RAIZ de um LINUX como RW

Olá pessoal…

Dica rápida mas muito útil… 

Muitas vezes, em sistemas RedHat ou SuSE (ou qualquer outra distro  =D ) o sistema acusa algum problema com algum sistema de arquivos, e cai diretamente no BASH em modo de manutenção. Geralmente só conseguimos reverter tal status realizando o fsck para correção de possíveis erros nos sistemas de arquivos, e estes com certeza estarão montados como Read-Only. Porém, muitas vezes precisamos realizar alguma alteração de urgência em casos de problemas com o fsck e/ou em casos de Backup emergencial antes que a “casa caia” de vez, porém nos deparamos com o sistema de arquivos montado como somente leitura…

Para remontar estas partições como RW para realizar alguma alteração em arquivos de configuração (tais como /etc/fstab ou /etc/mtab) deve-se remontar o filesystem como RW. Para isso deve ser feito o simples comando:

mount -o remount,rw /dev/UNIDADE_DISCO

Depois disso a unidade já estará disponível para escrita…

Abraços..!

Por: Franklin Moretti

Referência: man mount

Agendando backups temporários para serem removidos automaticamente com o at

Aproveitando informações postadas anteriormente no POST “Como fazer backup de arquivos com timestamp“, onde é explicado como fazer backup com timestamp em formato nome_do_arquivo_desejado.extensão_AAAAMMDD_HHMM, fica aqui outra dica de como programar para que essas cópias de segurança sejam automaticamente removidas após um determinado período de tempo.

Essa dica é útil para Administradores de grande quantidade de Servidores Linux, que, devido ao grande número de pequenos backups em disco para variados serviços de diferentes servidores em diferentes datacenters, eventualmente podem esquecer se é necessário manter um determinado backup. Isso acontece bastante comigo.

Para resolver esse problema, nada mais justo que o próprio Administrador definir no momento do backup, quanto tempo o mesmo deve permanecer em disco, e automaticamente o Linux ser encarregado de remover na hora certa.

Vamos ao que interessa…

A linha de comando para a geração de um backup do arquivo de nome arq com timestamp é a seguinte:

root@srv:/# cp -pa arq{,_`date ‘+%F_%R’ | tr -d – | tr -d :`}

Podemos fazer também a cópia do arquivo e na mesma linha de comando já agendar o “at” para remover o backup deste arquivo após um determinado período de tempo, conforme abaixo:

root@srv:/# T=`date ‘+%F_%R’ | tr -d – | tr -d :`
root@srv:/# cp -pa arq{,_$T}; echo rm -f arq_$T | at now +2 minutes

A primeira linha apenas especifica nosso timestamp que vai ser utilizado em dois comandos: cp e echo. O primeiro motivo de ter sido definido em uma linha separada é para encurtar a linha de código depois. O segundo motivo é que dependendo do tamanho do arquivo ou diretório que vamos copiar com o comando “cp“, pode passar de 01 minuto, então não seria legal mandar o “at” remover algo 01 minuto depois pois o arquivo/diretório já foi copiado 01 minuto antes com o timestamp do minuto anterior por exemplo.
A segunda linha começa com a cópia do arquivo usando o timestamp, em seguida, após o “ponto e vírgula”, executa o comando “echo” que vai apenas jogar o comando “rm -f arq_<timestamp>” na saída padrão (STDOUT) que será a entrada padrão (STDIN) para o comando “at“.

Para quem não conhece, o “at” recebe um determinado comando em sua entrada padrão (STDIN) e agenda para ser executado conforme  o tempo especificado (neste exemplo, 2 minutos depois).

No exemplo criado acima, após 2 minutos, podemos verificar que o arquivo será realmente removido. Sendo que o agendamento executado pelo “at” deve gerar um output parecido com este abaixo:

root@srv:/# cp -pa arq{,_$T}; echo rm -f arq_$T | at now +2 minutes
warning: commands will be executed using /bin/sh
job 12 at Sun Jul  5 15:06:00 2009

Para consultar as tarefas agendadas no “at“, basta digitar o comando “atq” conforme abaixo:

root@srv:/# atq
13    Sun Jul  5 15:06:00 2009 a root

Entrando em detalhes na documentação sobre o “at“, podemos ver que além de minutes o mesmo também trabalha com hours e days. Uma variação “at now +2 days” executada hoje (dia 5 de julho) gera o seguinte output e também funciona perfeitamente desde que o Linux esteja funcionando na hora que deverá executar o agendamento, no caso dois dias depois:

root@srv:/# cp -pa arq{,_$T}; echo rm -f arq_$T | at now +2 days
warning: commands will be executed using /bin/sh
job 14 at Tue Jul  7 15:25:00 2009

Obs.: Muito cuidado ao utilizar CTRL+C e CTRL+V nos comandos acima. Não recomendo pois a área de transferência copia alguns caracteres especiais de forma incorreta. Para fazer seus testes, recomendo digitar em seu terminal o que você lê aqui no BLOG, para não ter problemas de funcionamento das soluções aqui apresentadas.

Por: Hudson Murilo dos Santos
Referências:
man at
http://fixunix.com/networking/370467-using-command.html

Limpando cache de disco/memória no Linux

Quem nunca se confundiu com o output do comando “free -m” tentando monitorar a utilização de memória RAM no Linux ao verificar a quantidade de memória informada como “cached”?

Essa quantidade de memória indicada como “cached” está sempre sendo utilizada pelo sistema como “cache rápido” para posterior escrita em disco. Diga-se de passagem, “cache” é um termo inglês que significa “esconderijo”.

Existe no Linux uma forma simples de limpar esse cache, fazendo com que tudo que está em cache de memória RAM para ser gravado em disco, vá pra disco de uma vez. Isso torna a memória livre novamente. Segue abaixo sequência de comandos para você entender o que acontece:

[root@localhost ZimbraInside]# free -m
total       used       free     shared    buffers     cached
Mem:          3016        997       2019          0        339        458
-/+ buffers/cache:        198       2818
Swap:         5031         82       4949
[root@localhost ZimbraInside]# sync; echo 3 > /proc/sys/vm/drop_caches
[root@localhost ZimbraInside]# free -m
total       used       free     shared    buffers     cached
Mem:          3016        152       2864          0          0         27
-/+ buffers/cache:        124       2892
Swap:         5031         82       4949
[root@localhost ZimbraInside]#

Percebeu a mágica? Vale lembrar que o arquivo /proc/sys/vm/drop_caches existe apenas do release 2.6.16 do kernel em diante. Se tentar fazer em kernel antigo, não vai encontrar este arquivo.

O comando “sync” em conjunto com a alteração no /proc/sys/vm/drop_caches faz com que todo o cache do sistema de arquivos que está temporariamente armazenado em cache de memória RAM, seja despejado em disco e liberado.

Pelo comando free -m ou qualquer outro monitor de memória RAM podemos visualizar perfeitamente a queda de uso do cache.

Por: Hudson Murilo dos Santos
Referências:
man sync
info sync
man proc
http://www.scottklarr.com/
http://www.linuxinsight.com/proc_sys_vm_drop_caches.html

BONNIE++ , BenchMark de disco em sistemas Linux

A ferramenta Bonnie++ é uma ótima opção de BenchMark de disco, que oferece varias opções e condições variadas para realizar os testes de desempenho da unidade de disco. Esta ferramenta, oferece uma interface em linha de comando, tornando assim agradável a realização de testes de desempenho em servidores remotos. Para instalar, utilize o repositório preferido de sua distro Linux, ou de uma olhada na pagina refenciada no fim do post.

Bom, vamos a uma abordagem objetiva desta ferramenta… =D

As opções mais funcionais/usuais do bonnie++ (para as situações gerais) são:

-d <diretório>

Especificar o diretório onde será realizado o teste de desempenho. Este é um bom recurso, pois possibilita que o teste seja realizado não somente em unidades de disco em específico, abrindo um leque de opções de testes somente pelo fato de poder especificar o diretório onde os arquivos usados para o BENCHMARK serão escritos. Isso possibilitaria por exemplo, testar o desempenho de uma unidade mapeada na rede, via SAMBA ou NFS.

-s <valor>

Especificar o tamanho dos arquivos que serão escritos para o BENCHMARK. Este parâmetro permite dimensionar de forma mais específica o “poder” de benchmark. Com esta opção podemos moldar o teste de desempenho de acordo com a necessidade, como desempenho do filesystem para escrita de arquivos pequenos, médios ou de larga escala. A unidade padrão para o tamanho deste arquivos é em Mb.

-r <valor>

Este parâmetro especifica quanto de memória RAM será utilizada para o teste de BENCHMARK. Dependendo dos demais parâmetros a serem utilizados, esta opção faz toda a diferença. Por exemplo, sempre que realizarmos um teste sem passar o parâmetro -r <valor> o programa bonnie++ devolve uma mensagem informando que para um teste melhor, deve ser informado o dobro da quantidade de memória RAM para o tamanho de arquivo (opção -s). Isso faz com que os testes com arquivos menores que sua quantidade de RAM seja inviável. Para contornar isso, devemos sempre passar a opção -r com um valor que seja a metade do tamanho do arquivo a ser utilizado, ou ainda passar o valor 0 para desativar esta checagem. Abaixo segue alguns exemplos:

- Teste com um arquivo de 1000Mb em um sistema com 2Gb de ram sem o parâmetro -r:

[root@localhost /]# bonnie++ -d /tmp/ -s 1000 -n 1 -x 1 -u cialinux

File size should be double RAM for good results, RAM is 1924M.

Neste podemos observar que o bonnie++ informa que o tamanho do arquivo deve ser o dobro da RAM para um bom resultado.

- Teste com um arquivo de 1000Mb em um sistema de 2Gb de ram com o parâmetro -r:

[root@localhost /]# bonnie++ -d /tmp/ -s 1000 -r 500 -n 1 -x 1 -u cialinux

Neste passamos para o bonnie++ que o sistema possui somente 500Mb de ram, sendo assim a metade do arquivo a ser escrito. Outra forma é passar o valor 0 para o parâmetro -r, para esta checagem ser desativada.

-n <valor>

Este parâmetro determina o número de arquivos a serem escritos durante o teste. Este parâmetro é muito útil para simular a escrita de vário arquivos no mesmo filesystem, e se bem explorado, da uma margem mais exata do uso real da unidade de disco.

-m <NOME>

Este parâmetro serve para identificar o teste realizado. Geralmente é indicado passar como valor o HOST da máquina que está sendo feito o BENCHMARK, para melhor leitura dos resultados, lembrando que este parâmetro não é obrigatório.

-x <valor>

Este parâmetro serve para determinar quantas vezes o teste será realizado seguidamente. Este parâmetro é muito útil para tirar uma média de desempenho em comparação com múltiplos testes.

-u <usuário>

Este parâmetro deve ser utilizado caso o teste seja realizado como root. Deve ser passado como valor do parâmetro um usuário válido do S.O a ser testado.

Saída dos resultados

O bonnie++ por padrão possui uma saída dos valores avaliados no formato CSV (valores separados por vírgula). Este resultado é realmente incomodo de se interpretar. Os desenvolvedores do bonnie++ disponibilizam duas ferramentas para tratar melhor a saída dos testes.

* bon_csv2html : Converte a saída padrão para um arquivo HTML. Este método é o melhor e mais legível.

* bon_csv2txt : Converte a saída padrão para o formato TXT.

A utilização de qualquer um destes métodos é simples, bastando somente concatenar a saída do bonnie++ com a ferramenta desejada. Segue um exemplo de como realizar um BENCHMARK com a saída para um arquivo html.

[root@localhost /]# bonnie++ -d /tmp -s 500 -r 250 -n 2 -m CIALINUX -x 3 -u cialinux | bon_csv2html > /tmp/RESULTADO.html

Este exemplo, realizará três testes com dois arquivos de 500Mb para cada teste. Ao concluir o bonnie++ gera o arquivo /tmp/RESULTADO.html que pode ser visualizado em qualquer navegador web. Veja como é mostrado o resultado no arquivo HTML:

Em resumo, a utilização do bonnie++ é muito indicada para testes em que necessitamos resultados mais precisos, e que explore realmente os recursos de nossos dispositivos de armazenamento.

Por: Franklin Moretti

referências: man bonnie++

http://www.coker.com.au/bonnie++/