Archive for February, 2008

Se você vive compilando módulos Perl em máquinas sem saída para a Internet, ou se você sofre com problemas de lentidão ou disponibilidade de links externos, seus problemas acabaram :-)

Utilizando o CPAN-Mini (sua única dependência é o File-HomDir) você pode construir um repositório interno com menos de 1 GB e mante-lo atualizado diariamente com a seguinte entrada no crontab:

# Repositorio CPAN
30 04 * * * /usr/bin/minicpan -l /var/www/cpan/ -r http://cpan.kinghost.net/

Para utiliza-lo, você pode alterar o arquivo /etc/perl/CPAN/Config.pm da seguinte forma (no Debian/ Ubuntu):

'urllist' => [q[http://cpan.empresa.com.br/]],

Para os Red Hat’s da vida, você pode utilizar esta configuração:

[root@xen4-vm3 ~]# cat /usr/lib/perl5/5.8.5/CPAN/Config.pm

# This is CPAN.pm's systemwide configuration file. This file provides
# defaults for users, and the values can be changed in a per-user
# configuration file. The user-config file is being looked for as
# ~/.cpan/CPAN/MyConfig.pm.

$CPAN::Config = {
'build_cache' => q[10],
'build_dir' => q[/root/.cpan/build],
'cache_metadata' => q[1],
'cpan_home' => q[/root/.cpan],
'ftp' => q[/usr/kerberos/bin/ftp],
'ftp_proxy' => q[],
'getcwd' => q[cwd],
'gpg' => q[/usr/bin/gpg],
'gzip' => q[/bin/gzip],
'histfile' => q[/root/.cpan/histfile],
'histsize' => q[100],
'http_proxy' => q[],
'inactivity_timeout' => q[0],
'index_expire' => q[1],
'inhibit_startup_message' => q[0],
'keep_source_where' => q[/root/.cpan/sources],
'links' => q[/usr/bin/links],
'make' => q[/usr/bin/make],
'make_arg' => q[],
'make_install_arg' => q[],
'makepl_arg' => q[],
'ncftp' => q[],
'ncftpget' => q[],
'no_proxy' => q[],
'pager' => q[/usr/bin/less],
'prerequisites_policy' => q[ask],
'scan_cache' => q[atstart],
'shell' => q[/bin/bash],
'tar' => q[/bin/tar],
'term_is_latin' => q[1],
'unzip' => q[/usr/bin/unzip],
'urllist' => [q[http://cpan.empresa.com.br/]],
'wget' => q[/usr/bin/wget],
};
1;
__END__

Depois basta deixa-lo disponível a partir de algum webserver como por exemplo o apache, algo mais ou menos assim:

< VirtualHost cpan.empresa.com.br:80 >
ServerName cpan.empresa.com.br:80
ServerAdmin implantacao@dc.com.br
DocumentRoot /var/www/cpan
ErrorLog /var/www/cpan/logs/cpan-error_log
CustomLog /var/www/cpan/logs/cpan-access_log combined env=!gif-image

< Directory "/var/www/cpan" >
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from 192.168.44.0/22 192.168.50.0/22
< / Directory >
< / VirtualHost >

Se as entradas estiverem todas corretas, para testar você pode fazer o seguinte:

# perl -MCPAN -e shell
cpan> install Crypt::SmbHash

Saiu uma nota muito interessante neste final de semana no Dicas-L, uma dica de Rogerio Acquadro:

“Buscando na Internet, encontrei uma ferramenta chamada MySQLDiff (http://www.mysqldiff.org). Trata-se de um software em PHP que faz a comparação entre duas bases de dados (não necessariamente locais) e, como resultado da análise, gera um script SQL. A idéia é que, ao aplicar esse script SQL à base local, esta fique com a estrutura idêntica da base final.

O programa é bem completo e ainda conta com alguns filtros. Por exemplo, o programador pode optar se o MySQLDiff vai trazer no script apenas as alterações estruturais (que era o que eu buscava) ou se também analizará o conteúdo das tabelas, entre outras opções. “

A nota completa encontra-se no Dicas-l, eu só precisava anotar aqui para não esquecer… vivo precisando de coisas como essa :-)

Atendendo a pedidos, este post visa informar os desavisados que o FISL 9.0 ocorrerá em Porto Alegre nos dias 17, 18 e 19 de Abril de 2008, na PUC-RS — mesmo local onde eu participei em 2004/ 2005 e bem melhor dos lugares que foram em 2006/ 2007.

O site oficial do evento pode ser encontrado aqui: http://fisl.softwarelivre.org/9.0/www/

Só não sei se poderei participar este ano, devido a problemas pessoais… :-(
Mas de qualquer forma, quem for irá aprender e se divertir muito!
Abraços a todos!

- Introdução:

O netcat é um utilitário que permite escrita e leitura de dados atraves de conexão de rede, usando o proolo TCP/IP. Ele ainda permite especificar a porta que será transmitido, independe de onde será o server (listen) se na origem ou destino.
No caso de substituição do scp, permite usar o processamento que seria p/ encriptar no processo de compactação da
transmissão.

O NetCat (ou nc) é extremamente útil onde os principais meios de troca de arquivos não estão presentes ou suas portas estão filtradas em firewalls e roteadores (ex: scp, rsync, nfs…)

Usando o programa pv se consegue ter uma visualização da taxa de transmissão

- Copia de diretório
- Na maquina destino

nc -vlp port_escuta_detino | tar xzvp

-Na maquina origem

tar cpz ./ | nc ip_destino port_escuta_detino

- Copia de partição

- Na maquina origem

dd if=/dev/hdb5 | gzip -9 | nc -l porta_escuta_origem

- Na maquina destino

nc ip_origem porta_escuta_origem | pv -b > myhdb5partition.img.gz

- Transferindo arquivo

- Na maquina origem

cat backup.iso | nc -l 3333

- Na maquina destino

nc ip_origem porta_escuta_origem > backup.iso

Com status da transferência
- Na maquina origem

cat backup.iso | pv -b | nc -l 3333

- Na maquina destino

nc ip_origem porta_escuta_origem | pv -b > backup.iso

- Exemplo:

[root@squid-xen chroot]# nc -vl 6969 | tar zxv

[root@squid-producao chroot]# tar zcv var/ | nc squid-xen 6969
var/
var/named/
var/named/data/
var/named/slaves/
var/named/named.pid
var/named/localhost.zone
var/named/localhost.rev
var/named/named.cache
var/run/
var/run/named/
var/run/named/named.pid
var/run/dbus/
var/tmp/

Dica de Edson Moreno - jemorenojr AT ig.com.br

FAUS significa “Ferramenta de Administração de Usuários do Samba” e é um CGI escrito em Perl para permitir a administração de usuários via uma interface web.

FAUS versão 1.4.5 lançada

A versão 1.4.5, além dos bugs corrigidos, trouxe também algumas novidades como por exemplo o suporte completo ao SaMBa 3.x, inclusive alterando de base de dados smbpasswd para tdbsam. Foi possível fazer isso deixando de editar o smbpasswd diretamente e voltando a usar os programas do SaMba. Com isso, foi retirado o suporte ao SaMBa 2.x.

Também é possível agora alterar o nome de usuário, sem precisar deletar e cria-lo novamente :) O FAUS se encarrega de alterar no sistema e no SaMBa.

O instalador, anteriormente só funcionava em Debian agora funciona em suas variações (Kurumin, xUbuntu) e também em distribuiçoes baseadas em RPM (testada no Mandriva 2007, fácilmente portado à outros). E todos aqueles módulos perl chatos de instalar estão agora incluídos no próprio tarball do FAUS para evitar problemas com falta de conexão ou versões incompatíveis dos módulos com o FAUS.

Em caso de problemas, críticas ou sugestões procure-nos na lista faus-users.

1-) Estou armazenando as VMs no LVM:

# lvcreate -Ay -L 60G -n vm00 Vol_LVM
# lvcreate -Ay -L 60G -n vm01 Vol_LVM
# lvcreate -Ay -L 60G -n vm02 Vol_LVM

2-) Estou usando o “partimage-0.6.7_beta2.tar.bz2″, pois a versão stable não funciona bem em 64 bits:

3-) A primeira VM deve ser instalada/ configurada manualmente/normalmente. Depois você pode tirar uma cópia dela:

# kpartx -a /dev/mapper/Vol_LVM-vm01
# partimage -z1 save /dev/mapper/Vol_LVM-vm01p1 /LVM/vm01p1.partimg.gz

ou
# partimage -z0 -c -d -f0 save /dev/mapper/Vol_LVM-vm01p1 /LVM/vm01p1.partimg
# kpartx -d /dev/mapper/Vol_LVM-vm01

PS: Note que se você usar compressão (-z1) a geração da imagem vai demorar mais para ser criado, porém com o tamanho bem menor (515M vs 3.7GB) . A restauração da mesma também será mais lenta.

4-) Com base na primeira VM:

# fdisk -l /dev/mapper/Vol_LVM-vm00
Disk /dev/mapper/Vol_LVM-vm00: 64.4 GB, 64424509440 bytes
255 heads, 63 sectors/track, 7832 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/mapper/Vol_LVM-vm00p1 * 2 7395 59392305 83 Linux
/dev/mapper/Vol_LVM-vm00p2 7396 7832 3510202+ 82 Linux swap / Solaris

Você poderá preparar um arquivo, por exemplo, /tmp/parttable, com as especificações das demais partições.
1,7394,83,*
7395,,82,-

Estou usando uma partição primária para o raiz “/” (tipo 83) com ~ 60 GB e o restante para swap (tipo 82).

Você poderá usar o sfdisk e especificar os dados em: sectors, blocks, cylinders ou megabytes.

5-) Crie as partições para a segunda VM:

# dd if=/dev/zero of=/dev/mapper/Vol_LVM-vm01 count=1 bs=512
# sfdisk -uC /dev/mapper/Vol_LVM-vm01 < /tmp/parttable

Se preferir, simplesmente faça o processo manualmente:
# fdisk /dev/mapper/Vol_LVM-vm01

6-) Crie a SWAP para o segundo device:

Será necessário usar o “kpartx” para “mapear” as partições que existem dentro do device LVM:

# kpartx -a /dev/mapper/Vol_LVM-vm01
# ll /dev/mapper/Vol_LVM-vm01*
# mkswap /dev/mapper/Vol_LVM-vm01p2

7-) Restaure a imagem da primeira VM:

- Restauração com GZIP:

# partimage restore /dev/mapper/Vol_LVM-vm02p1 /LVM/vm01p1.partimg.gz
Time elapsed: 10m:59sec
Speed: 5.16 GiB/min
Data copied: 56.64 GiB

- Restauração sem GZIP:

# partimage restore /dev/mapper/Vol_LVM-vm03p1 /LVM/vm01p1.partimg.000
Time elapsed: 1m:15sec
Speed: 2.90 GiB/min
Data copied: 3.62 GiB

8-) Monte a VM e troque endereços de IP, hostname e MAC Address:
# mount /dev/mapper/Vol_LVM-vm01p1 /mnt/xen/
# vi /mnt/xen/etc/sysconfig/network-scripts/ifcfg-eth0
# vi /mnt/xen/etc/sysconfig/network
# vi /mnt/xen/etc/hosts

PS: Use o macgen.py para alterar o MAC address:

$ cat macgen.py
#! /usr/bin/python
# macgen.py script generates a MAC address for Xen guests
#
import random
mac = [ 0×00, 0×16, 0×3e,
random.randint(0×00, 0×7f),
random.randint(0×00, 0xff),
random.randint(0×00, 0xff) ]
print ‘:’.join(map(lambda x: “%02x” % x, mac))

9-) Desmonte a partição, e arrume seu /etc/xen/vm02:

# umount /mnt/xen
# kpartx -d /dev/mapper/Vol_LVM-vm02

Utilize o “uuidgen” para gerar um novo UUID para sua VM.
Não esqueça de trocar também o MAC no campo “vif” e o device LVM, ex:

name = “vm02″
uuid = “82f89076-487e-4de5-ab4a-99ce07c586eb”
maxmem = 1000
memory = 800
vcpus = 1
bootloader = “/usr/bin/pygrub”
on_poweroff = “destroy”
on_reboot = “restart”
on_crash = “restart”
vfb = [ “type=vnc,vncunused=1,keymap=en-us” ]
disk = [ “phy:/dev/Vol_LVM/vm01,xvda,w” ]
vif = [ “mac=00:16:3e:5a:02:a6,bridge=xenbr0″ ]

10-) Inicie a VM e corra para o abraço:

# xm create vm02 -c

Em caso de problemas, consulte este artigo: Xen: Dicas rápidas e problemas resolvidos

Este post abrange o Storage AMS500 da Hitachi, comercialmente conhecido pelo modelo DF700M.

O Storage possui RAID Groups em Fibre Channel usando RAID5 (5D+1P), e algumas RAID Groups de discos SATA usando RAID6 (7D+2P).

AMS 500

Sobre o Multi Path (HDLM) do Storage Hitachi

Conforme o desenho, pode-se observar que será necessário um software multipath para controlar os vários caminhos que os servidores “server-spo-la-1″ e “server-spo-la-2″ podem fazer para chegar até os discos do storage.

Para exemplificar, o server-spo-la-1 pode fazer os seguintes caminhos:
- Passar pela fibra saindo pela HBA0 até o Switch 1, e chegar no storage pela Controller 0, porta A;
- Passar pela fibra saindo pela HBA1 até o Switch 2, e chegar no storage pela Controller 0, porta B;
- Passar pela fibra saindo pela HBA1 até o Switch 2, e chegar no storage pela Controller 1, porta A;
- Passar pela fibra saindo pela HBA0 até o Switch 1, e chegar no storage pela Controller 0, porta B;

É aí que entra o HDML (Hitachi Dynamic Link Manager). O problema é que para cada caminho que o SO faz até o Storage, ele encontra discos e “pensa” que são discos diferentes. Portanto, se você tem 25 LUNs exportadas para o server-spo-la-1, ele irá “enxergar” 100 discos (25*4=100). Será algo parecido com isso:

root@server-spo-la-1 ~# fdisk -l 2> /dev/null | grep "38.6 GB"
Disk /dev/sdb: 38.6 GB, 38654705664 bytes
Disk /dev/sdc: 38.6 GB, 38654705664 bytes
Disk /dev/sdd: 38.6 GB, 38654705664 bytes
Disk /dev/sde: 38.6 GB, 38654705664 bytes
Disk /dev/sdf: 38.6 GB, 38654705664 bytes
Disk /dev/sdg: 38.6 GB, 38654705664 bytes
Disk /dev/sdh: 38.6 GB, 38654705664 bytes
Disk /dev/sdi: 38.6 GB, 38654705664 bytes
Disk /dev/sdj: 38.6 GB, 38654705664 bytes
Disk /dev/sdk: 38.6 GB, 38654705664 bytes
Disk /dev/sdl: 38.6 GB, 38654705664 bytes
Disk /dev/sdm: 38.6 GB, 38654705664 bytes
Disk /dev/sdn: 38.6 GB, 38654705664 bytes
Disk /dev/sdo: 38.6 GB, 38654705664 bytes
Disk /dev/sdp: 38.6 GB, 38654705664 bytes
Disk /dev/sdq: 38.6 GB, 38654705664 bytes
Disk /dev/sdr: 38.6 GB, 38654705664 bytes
Disk /dev/sds: 38.6 GB, 38654705664 bytes
Disk /dev/sdt: 38.6 GB, 38654705664 bytes
Disk /dev/sdu: 38.6 GB, 38654705664 bytes
Disk /dev/sdv: 38.6 GB, 38654705664 bytes
Disk /dev/sdw: 38.6 GB, 38654705664 bytes
Disk /dev/sdx: 38.6 GB, 38654705664 bytes
Disk /dev/sdy: 38.6 GB, 38654705664 bytes
Disk /dev/sdz: 38.6 GB, 38654705664 bytes
Disk /dev/sdaa: 38.6 GB, 38654705664 bytes
Disk /dev/sdab: 38.6 GB, 38654705664 bytes
Disk /dev/sdac: 38.6 GB, 38654705664 bytes
Disk /dev/sdad: 38.6 GB, 38654705664 bytes
Disk /dev/sdae: 38.6 GB, 38654705664 bytes
Disk /dev/sdaf: 38.6 GB, 38654705664 bytes
Disk /dev/sdag: 38.6 GB, 38654705664 bytes

Completamente bizarro 8-)

Instalação do HDLM

O processo de instalação é um tanto chato, e cada servidor precisa de uma licença diferente. Em termos gerais, seria mais ou menos isso:

-> Verificar se o server acha os discos com um fdisk -l

-> Copiar o license key para:
/var/tmp/hdlm_license
/etc/opt/DynamicLinkManager/dlm.lic_key

-> Rodar o /media/cdrom/installhdml

-> No /etc/profile

PATH=$PATH:/opt/DynamicLinkManager/bin ; export PATH

-> Reboot

-> Verificar se o fdisk -l mostra mais discos :)

Se tudo der certo, além dos 100 discos de outrora, seu servidor irá enxergar mais 25 (!!!) mas agora com outro nome. E será esse device que você irá utilizar para guardar os dados:

Disk /dev/sddlmaa: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmab: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmac: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmad: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmae: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmaf: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmag: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmah: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmai: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmaj: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmak: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmal: 38.6 GB, 38654705664 bytes

Configuração do HDLM

Caso você queira testar se o HDML está mesmo funcionando, você poderia tirar uma fibra enquanto copia os dados, chutar o switch ou algo do tipo :-)

# dlnkmgr set -lb on
# dlnkmgr set -pchk on -intvl 5
# dlnkmgr set -afb on -intvl 5
# dlnkmgr set -ellv 2
# dlnkmgr set -systflv 1
# dlnkmgr set -elfs 1000
# dlnkmgr set -elfn 5
# dlnkmgr set -systfs 2000
# dlnkmgr set -systfn 10

Para verificar:

# dlnkmgr view -path | more
# dlnkmgr view -sys
# dlnkmgr view -lu | more

Este setup irá ativar o Load Balance, verificação de PATH, auto Failback em caso de falhas e etc.

Configurando o LVM

Existe ainda mais um cuidado a ser tomado antes de você conseguir brincar com o Storage. O LVM é uma ferramenta muito esperta, e ele identifica cada disco com uma assinatura, individual e intransferível, mais ou menos como a sua impressão digital.

Portanto, ao adicionar um disco do HDLM ao LVM, você verá algo parecido com isso:

root@server-la-2 ~# pvcreate /dev/sddlmaa
Physical volume “/dev/sddlmaa” successfully created

root@server-la-2 ~# pvs
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sdb not /dev/sddlmaa
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sdch not /dev/sdb
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sdbf not /dev/sdch
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sdad not /dev/sdbf
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sddlmaa not /dev/sdad
PV VG Fmt Attr PSize PFree
/dev/sda2 Vol_LVM lvm2 a- 408.17G 0
/dev/sddlmaa lvm2 — 36.00G 36.00G

O que acontece é que o LVM está vendo o mesmo disco (mesma LUN, na verdade) pelos 04 caminhos diferentes e mais o novo caminho, do HDLM.

O que você deve fazer, é editar o arquivo /etc/lvm/lvm.conf e criar um filtro separando os devices que devem de fato serem manipulados pelo LVM, algo deste tipo:

filter = [ “a/sda1-9$/” “a/sddla-za-za-z$/” “r/.*/” ]

Após isso, basta rodar um ‘vgscan -vv’ para refazer o cache.

Passos rápidos para configurar o LVM no Storage

Papo rápido:


# for i in `fdisk -l 2> /dev/null | grep "sddl" | awk '{print $2}' | cut -d : -f 1`; do pvcreate $i; done


# vgcreate -Ay AMS500 /dev/sddlmaa /dev/sddlmab /dev/sddlmac /dev/sddlmad \
/dev/sddlmae /dev/sddlmaf /dev/sddlmag /dev/sddlmah /dev/sddlmai /dev/sddlmaj \
/dev/sddlmak /dev/sddlmal /dev/sddlmam /dev/sddlman /dev/sddlmao /dev/sddlmap \
/dev/sddlmba /dev/sddlmbb /dev/sddlmbc /dev/sddlmbd /dev/sddlmbe /dev/sddlmbf \
/dev/sddlmbg /dev/sddlmbh /dev/sddlmbi /dev/sddlmbj /dev/sddlmbk /dev/sddlmbl


# lvcreate -Ay -L 1.2T --name u01 AMS500

# mkfs.ext3 /dev/AMS500/u01

# mkdir /u01; mount /dev/AMS500/u01 /u01

Pronto! 1.2 TB para brincar :-D

Ganhando desempenho fazendo Stripe no LVM

É possível fazer Stripe do lado do Sistema Operacional, visando um maior desempenho :)

Cada servidor está “enxergando” 28 LUNs do Storage, como se cada LUN fosse um disco.

Utilizei o “dd” para criar arquivos de 10 e 40 GB nos servidores, tanto na “Barriga” da máquina (Dell PowerEdge 2950 em RAID 10) quanto no Storage. Depois disso, irei utilizar nos servidores Stripes com granulação de 128 KB, sempre no FileSystem com Block Size de 4KB para comparar:

# Teste Storage Billing
# LVM padrão (sem stripe) e Block Size de 4KB

=> 10 GB com LVM default:
root@server-la-1 ~# Storage: 1m38.939s
root@server-la-1 ~# Barriga: 1m22.395s

root@server-la-2 ~# Storage: 1m57.203s
root@server-la-2 ~# Barriga: 1m15.134s

=> 40 GB com LVM default:
root@server-la-1 ~# Storage: 10m23.250s
root@server-la-1 ~# Barriga: 06m04.812s

root@server-la-2 ~# Storage: 11m22.150s
root@server-la-2 ~# Barriga: 06m01.234s

# lvcreate -Ay -i 28 -I 128 -l258020 –name u01 AMS500
# 28 Stripes com granulação de 128 KB cada (Block size=4096)

=> 10 GB com LVM + Stripe 128K
root@server-la-2 ~# Storage: 1m02.411s
root@server-la-2 ~# Barriga: 1m18.440s

=> 40 GB com LVM + Stripe 128K
root@server-la-2 ~# Storage: 4m49.578s
root@server-la-2 ~# Barriga: 5m50.452s

# lvcreate -Ay -i 28 -I 64 -l258020 –name u01 AMS500
# 28 Stripes com granulação de 64 KB cada (Block size=4096)

=> 10 GB com LVM + Stripe 64K
root@server-la-1 ~# Storage: 1m42.396s
root@server-la-1 ~# Barriga: 1m44.903s

=> 40 GB com LVM + Stripe 64K
root@server-la-1 ~# Storage: 5m04.977s
root@server-la-1 ~# Barriga: 5m55.737s

Teste de desempenho

Resultados dos testes de desempenho do Storage feitos por uma ferramenta mais profissional (Bonnie++), que faz vários testes além do qual eu fiz:

http://everlinux.com/raid/bonnie.html

Testei na minha máquina de casa (IDE) e do escritório (SATA) também, só para lembrar que eu preciso trocar meu velho Athlon 2000 :-)