Os resultados demonstram uma distribuição bem definida, do software Open Source pelo mundo.

O estudo com os resultados, que também se encontra numa representação no Google Maps, que tem o intuito de mapear a utilização dos softwares livres e open source e sua atividade, numa perspectiva interessante que pode ser aproveitada por estudos academicos ou de mercado. Segundo a informação presente na FAQ da Red Hat sobre o estudo, os dados têm algum valor especulativo.

“Mesmo um país que não tenha um alto grau de penetração de open source, pode ter um número elevado número de usuários na Internet e ser possuidor de patentes na área de tecnologias de informação. Estes fatores podem indicar um ambiente favorável, para este software poder ser divulgado.”

Acesse o mapa com as Atividades Open Source

1-) Adicionar um “Mapped Raw LUN” no ESX, em Compatibility Mode “Physical”.
A “SCSI Controller” também precisa ser “Physical”, e o disco RAW precisa estar nesta controller dedicada

Ex:
Hard Disk 1 = SCSI Controller 0 = SCSI (0:0)
Hard Disk 2 = SCSI Controller 1 = SCSI (1:0)
Hard Disk 2 = SCSI Controller 1 = SCSI (1:1)

2-) Adicionar a LUN no Linux:

[root@cluster-02 ~]# cat /proc/scsi/scsi 
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: VMware   Model: Virtual disk     Rev: 1.0 
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: 1815      FAStT  Rev: 0914
  Type:   Direct-Access                    ANSI SCSI revision: 05
 
[root@cluster-02 ~]# echo "scsi add-single-device 1 0 1 0" > /proc/scsi/scsi
 
[root@cluster-02 ~]# cat /proc/scsi/scsi 
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: VMware   Model: Virtual disk     Rev: 1.0 
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: 1815      FAStT  Rev: 0914
  Type:   Direct-Access                    ANSI SCSI revision: 05
Host: scsi1 Channel: 00 Id: 01 Lun: 00
  Vendor: IBM      Model: 1815      FAStT  Rev: 0914
  Type:   Direct-Access                    ANSI SCSI revision: 05

Sendo: Host – Channel – ID – Lun
(um reboot também funcionaria )

3-) Configurar o Cluster de LVM

3a-) Criando um Logical Volume

# fdisk /dev/sdc (usar ID 8e = Linux LVM)
# partprobe (em todas as maquinas do cluster)
# lvmconf --enable-cluster
# pvcreate /dev/sdb1
# vgcreate -Ay -cy pre_homolog /dev/sdb1
# lvcreate -L 499G -n hotsites pre_homolog

ou

3b-) Aumentando um já existente

[root@cluster-01 ~]# pvs
  PV         VG          Fmt  Attr PSize   PFree
  /dev/sdb1  pre_homolog lvm2 a-   499.99G 1016.00M
  /dev/sdc1              lvm2 --   499.99G  499.99G
 
[root@cluster-01 ~]# vgextend pre_homolog /dev/sdc1
  Volume group "pre_homolog" successfully extended
 
[root@cluster-01 ~]# vgs
  VG          #PV #LV #SN Attr   VSize   VFree  
  pre_homolog   2   1   0 wz--nc 999.98G 500.98G
 
[root@cluster-01 ~]# pvs
  PV         VG          Fmt  Attr PSize   PFree
  /dev/sdb1  pre_homolog lvm2 a-   499.99G 1016.00M
  /dev/sdc1  pre_homolog lvm2 a-   499.99G  499.99G
 
[root@cluster-01 ~]# lvextend -Ay -l+128252 /dev/pre_homolog/hotsites
  Extending logical volume hotsites to 999.98 GB
  Logical volume hotsites successfully resized
 
[root@cluster-01 ~]# lvs
  LV       VG          Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  hotsites pre_homolog -wi-ao 999.98G
 
[root@cluster-01 ~]# vgs
  VG          #PV #LV #SN Attr   VSize   VFree
  pre_homolog   2   1   0 wz--nc 999.98G    0
 
[root@cluster-01 ~]# pvs
  PV         VG          Fmt  Attr PSize   PFree
  /dev/sdb1  pre_homolog lvm2 a-   499.99G    0
  /dev/sdc1  pre_homolog lvm2 a-   499.99G    0

4-) Aumentar o GFS

Com o /gfs montado, usando o gfs_grow

[root@cluster-01 ~]# gfs_grow -v /gfs
FS: Mount Point: /gfs
FS: Device: /dev/mapper/pre_homolog-hotsites
FS: Options: rw,hostdata=jid=0:id=131073:first=0
FS: Size: 130809855
RGRP: Current Resource Group List:
RI: Addr 130744354, RgLen 5, Start 130744359, DataLen 65496, BmapLen 16374
RI: Addr 130678852, RgLen 5, Start 130678857, DataLen 65496, BmapLen 16374
RI: Addr 130613350, RgLen 5, Start 130613355, DataLen 65496, BmapLen 16374
...
...
RI: Addr 261895985, RgLen 15, Start 261896000, DataLen 243904, BmapLen 60976
RGRP: 539 Resource groups in total
Preparing to write new FS information...
Done.

Antes:

[root@cluster-02 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             6.9G  1.8G  4.7G  28% /
tmpfs                 1.9G     0  1.9G   0% /dev/shm
/dev/mapper/pre_homolog-hotsites
                      493G   12G  482G   3% /gfs

Depois:

[root@cluster-02 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             6.9G  1.8G  4.7G  28% /
tmpfs                 1.9G     0  1.9G   0% /dev/shm
/dev/mapper/pre_homolog-hotsites
                      994G   12G  983G   2% /gfs

Porém, fui tentar fazer isso em um Red Hat EL 5.2 e não funcionou. Seguindo a documentação, um simples trecho como este deveria ser suficiente:

AuthName “Autenticadao Fodastica”
AuthType Basic
AuthLDAPURL ldap://ldapserver.com.br:389/ou=People,dc=empresa,dc=com,dc=br?uid?one
require user huguinho zezinho luizinho
Allow from all

Porém, só colocando essas linhas antes, que a autenticação funcionou (tudo em um Directory, como de costume)

AuthBasicProvider ldap
AuthzLDAPAuthoritative off

E erro que dava era esse: access to / failed, reason: verification of user id ‘tiagocruz’ not configured

A dica está ae, para quando eu precisar disso novamente…

Portanto, para que todas as máquinas fiquem em sincronia, usaremos o ChironFS que é um Sistema de Arquivos Tolerante a Falhas com Replicação de Dados, no qual tive contato em Porto Alegre durante o FISL 9.0.

Você pode fazer da apresentação do mesmo aqui: ChironFS

O ChironFS é um Filesystem virtual que utiliza o FUSE. Funciona sincronizando dados entre dois ou mais diretórios, porém, cada um deste diretório pode ser um ponto de montagem de uma máquina remota. Desta forma, o ChironFS atua como uma camada de abstração, sincronizando, por exemplo, um Debian com ext3 local com um Red Hat usando ReiserFS remotamente, usando NFS, SSHFS ou qualquer outro sistema que trabalhe com pontos de montagem.

No Red Hat Enterprise, infelizmente não existe os pacotes para o fuse e nem para seu módulo do kernel, mas você pode busca-los nos repositórios “dag”

http://dag.wieers.com/rpm/packages/dkms-fuse/
http://dag.wieers.com/rpm/packages/fuse/

Neste caso, as 03 máquinas de front-end exportam o diretório /data/dominios via NFS para que seja possível a montagem remota destes diretórios:

# cat /etc/hosts
192.168.0.1 site-1 site-1.com.br
192.168.0.2 site-2 site-2.com.br
192.168.0.3 site-3 site-3.com.br

# cat /etc/fstab
nfsd /proc/fs/nfsd nfsd auto,defaults 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs auto,defaults 0 0
site-2:/data/sync/site-2 /data/sync/site-2 nfs soft,timeo=3 0 0
site-3:/data/sync/site-3 /data/sync/site-3 nfs soft,timeo=3 0 0

Portanto:

Site-1: monta a site-2 e a site-3
Site-2: monta a site-1 e a site-3
Site-3: monta a site-1 e a site-2

O ChironFS cuidará para que a escrita feita localmente seja replicada para as outras duas máquinas, configurado desta forma pelo /etc/fstab (atenção, um uma única linha!):

chironfs#/data/sync/site-1=:/data/sync/site-2=:/data/sync/site-3 /data/dominios
fuse allow_other,ctl=/var/run/chironctl,log=/var/log/chironfs.log 0 0

O que quer dizer:

O diretório /data/sync/site-1 (local) deve ser sincronizado com o /data/sync/site-2 (NFS, mais lento) e também com o /data/sync/site-3 (NFS) cada vez que houver escrita em /data/dominios.

Quando houver leitura em /data/domínios, o ChironFS irá dar preferência ao device local, pois é o único que não apresenta os dois pontos (“:”) em sua montagem no /etc/fstab.

Portanto, toda e qualquer escrita no disco que tenha o objetivo de ser sincronizada com as demais máquinas, devem ser feitas diretamente no /data/dominios de qualquer uma das máquinas.

- Monitoramento

O ChironFS a partir da versão 1.1 já vem pronto para ser monitorado pelo Nagios, bastando para isso acrescentar em seu nrpe.cfg:

command[check_site1]=/var/run/chironctl/_data_sync_site-1/check_chironfs.sh
command[check_site2]=/var/run/chironctl/_data_sync_site-2/check_chironfs.sh
command[check_site3]=/var/run/chironctl/_data_sync_site-3/check_chironfs.sh

- Em caso de Problemas

Algumas dicas retiradas do manual oficial: Capítulo 5. Falhas das Réplicas

Toda vez que uma réplica falha, o ChironFS tenta manter seus sistemas rodando. Se a falha ocorrer durante uma operação de leitura, o ChironFS tenta ler de alguma outra réplica e, se conseguir, retorna os dados para o chamador sem gerar erro.

Se a falha ocorrer durante uma operação de escrita, o ChironFS continua tentando escrever nas outras réplicas. Se ao menos uma das réplicas escrever com sucesso, o ChironFS retorna ao chamador sem gerar erro. Mas, desta vez, além de logar o evento, ele desabilita as réplicas que tiverem falhado. Isto significa que não haverá mais leituras ou escritas de/para as réplicas que falharam.

O crontab das máquinas possui um pequeno script para gerar gravação no /data/dominios a fim de tentar detectar quando alguma máquina do “cluster” está fora do ar:

# Verificacao ChironFS
* * * * * /bin/touch /data/dominios/`hostname`; sleep 15; /bin/rm -f /data/dominios/`hostname`

Outra dica importante é “congelar” updates no kernel, pois o ChironFS depende o FUSE que tem um módulo específico para um kernel específico. Portanto, se você atualizar o kernel no RHEL, provavelmente o módulo do fuse não irá mais funcionar e conseqüentemente, o chironfs também não. Para que isso não ocorra acidentalmente:

# cat /etc/yum.conf
[main]
cachedir=/var/cache/yum
distroverpkg=redhat-release
...
exclude=kernel* fuse-kmdl*

Você tem a opção de montar um sistema de arquivos semelhante ao /proc para controlar o ChironFS, que é um sistema de arquivos de controle é composto de um diretório para cada réplica. Seus nomes são o pathname completo da réplica com as barras (“/”) mudadas para caracteres de sublinha.

Cada um deles contém dois arquivos: o primeiro é chamado “status” e contém um número “0″ nas réplicas que estiverem em bom estado ou um número “2″ se a réplica estiver desabilitada e os dados inconsistentes. Basta gravar “0″ ou “2″ neste arquivo para habilitar ou desabilitar a réplica.

Enfim, depois de detectar a falha, corrija a sua causa no servidor de réplica falhado. VOCÊ DEVE PROVER POR SUA CONTA O RESTABELECIMENTO DA CONSISTÊNCIA DOS DADOS NO SERVIDOR DE RÉPLICA QUE FALHOU. EU SUGIRO O USO DO RSYNC PARA ATUALIZAR OS DADOS. ESTE PASSO DEVE SER EFETUADO ANTES DE COLOCAR A RÉPLICA EM ESTADO HABILITADO DE NOVO, CASO CONTRÁRIO, VOCÊ IRÁ CORROMPER SEUS DADOS NAS DEMAIS RÉPLICAS.

Para restabelecer o uso da réplica após o procedimento de recuperação:

# echo 0 > /var/run/chironctl/_data_sync_site-3/status

E acompanhe as mudanças em /var/log/chironfs.log:

2008/08/04 11:35 init: version 1.1.2
2008/08/04 11:44 open+chown failed accessing /data/sync/site-3/site/htdocs/pops/index.html Input/output error
2008/08/04 11:44 disabling replica failed accessing /data/sync/site-3
2008/08/04 11:55 trusting replica /data/sync/site-3 Forced by administrator

Ou simplesmente “reinicie” o ChironFS:

# umount /var/run/chironctl /data/dominios
# mount /data/dominios

DBRD é a acrônimo para o nome inglês Distributed Replicated Block Device. O DRBD consiste num módulo para o kernel de Linux que, juntamente com alguns scripts, oferece um dispositivo de bloco projetado para disponibilizar dispositivos de armazenamento distribuídos, geralmente utilizado em clusters de alta disponibilidade. Isto é feito espelhando conjuntos de blocos via rede (dedicada). O DRBD funciona, portanto, como um sistema RAID baseado em rede.

Referência: http://pt.wikipedia.org/wiki/DRBD

* GFS 1.x

O “Red Hat Global File System” é um Sistema de Arquivos para Cluster, que permite que vários nós leiam e escrevam dados simultaneamente em um dispositivo compartilhado.

O GFS suporta ACL’s e atributos extendidos, diferente se seu concorrente direto, o OCFS (Oracle Cluster File System)

Vale observar que a versão 2.0 do GFS ainda é considerado “Technology Preview” e não deve ser usado em produção.

Porém, o GFS congela todo o I/O se ele perde um nó (cliente), e fica congelado até o que o nó retorne ou que o mesmo seja “fenced”.

Referência: http://www.redhat.com/gfs/
http://en.wikipedia.org/wiki/Comparison_of_file_systems

* Fence Devices

Fence é algo difícil de traduzir para a nossa língua, assim como a palavra “proxy” O Babylon sugere “grade; muro; cercar; proteger” enquanto o Google Translator sugere “vedação”.

Enfim, é algo nesse sentido: Se um nó do cluster apresenta problemas, para evitar que esse cara escreva algo no FileSystem? e acabe por corromper o mesmo, é necessário que o mesmo seja “fenceado”, ou seja, tirado da jogada. As formas comuns se se fazer isso são:

- Desligando a alimentação de energia deles;
- Desligando a porta do switch;
- Reiniciando a máquina usando DRAC/RSA/ILO (Dell, IBM e HP respectivamente);
- Manualmente;

Utilizaremos a forma menos recomendada (manual) devido a falta de infra-estrutura para utilizarmos as demais. Um script do modificado do DRBD irá tornar o fencing_manual em um fencing automatizado

Referência: http://www.everlinux.com/blog/2008/04/22/redhat-enterprise-linux-51-cluster-suite/

* LVM

Usaremos LVM para garantir flexibilidade da solução:

Criar volumes LV nas duas máquinas

# pvcreate /dev/sda9
# vgcreate vol0 /dev/sda9
# lvcreate -L 105.94G -n lvm vol0

– Configurando o DRBD

Configurar o /etc/hosts para conter todas as maquinas, principalmente o hostname no IP principal e um nome para os IPs da rede de sincronismo:

127.0.0.1 localhost.localdomain localhost
10.10.10.1 hotsite-1.com.br
10.10.10.2 hotsite-2.com.br
192.168.0.3 drbd_hotsite-1 drdb_hotsite-1.com.br
192.168.0.4 drdb_hotsite-2 drdb_hotsite-2.com.br

Configurar o /etc/drbd.conf no master e slave

# DRDB Configuration
global {
        usage-count no;
}
 
resource hotsite {
        protocol C;
 
        startup {
                wfc-timeout 0;
                degr-wfc-timeout 120;
                become-primary-on both;
        }
        disk    {
                fencing resource-and-stonith;
        }
       handlers {
                outdate-peer "/sbin/obliterate";
        }
        net     {
                cram-hmac-alg sha1;
                shared-secret "senha_secreta";
                timeout 60;
                connect-int 10;
                ping-int 10;
                max-buffers 2048;
                max-epoch-size 2048;
                allow-two-primaries;
                after-sb-0pri discard-zero-changes;
                after-sb-1pri discard-secondary;
                after-sb-2pri disconnect;
                rr-conflict violently;
        }
        syncer  {
                rate 650M;
        }
 
        on hotsite-1.com.br {
                device    /dev/drbd0;
                disk      /dev/vol0/lvm;
                address   192.168.0.3:7789;
                flexible-meta-disk internal;
        }
 
 
 
        on hotsite-2.com.br {
                device    /dev/drbd0;
                disk      /dev/vol0/lvm;
                address   192.168.0.4:7789;
                flexible-meta-disk internal;
        }
}

Inicializar as partições para o drbd no master e slave

# drbdadm create-md hotsite |
# drbdadm attach hotsite | drbdadm up hotsite
# drbdadm connect hotsite |

# drbdadm -- --overwrite-data-of-peer primary hotsite
# watch -n1 cat /proc/drbd
# drbdadm primary hotsite


Obs: Caso de erro de carga de modulo inicie o drbd com “service drbd start” mesmo acusando erro, isso fará com que carregue o modulo corretamente.

Inicializar o drbd no master e slave

# service drbd start

- Configurando o cluster para o GFS

* Crie o arquivo de configuração do cluster (/etc/cluster/cluster.conf) para o gfs, em todas as maquinas:

Vou colocar ele em um arquivo separado pois o wordpress não está(va) gostando as tags do mesmo: cluster.conf

Update:

<?xml version="1.0"?>
<cluster name="hotsite" config_version="1">
 
<cman two_node="1" expected_votes="1"/>
 
<fence_daemon post_join_delay="60">
</fence_daemon>
 
<clusternodes>
<clusternode name="drdb_hotsite-1" nodeid="1">
        <fence>
                <method name="single">
                        <device name="node1" ipaddr="192.168.0.3"/>
                </method>
        </fence>
</clusternode>
<clusternode name="drdb_hotsite-2" nodeid="2">
        <fence>
                <method name="single">
                        <device name="node2" ipaddr="192.168.0.4"/>
                </method>
        </fence>
</clusternode>
</clusternodes>
 
<fencedevices>
        <fencedevice name="manual" agent="fence_manual"/>
</fencedevices>
</cluster>

Formatar a partição DRBD com GFS

# gfs_mkfs -t hotsite:gfs-00 -p lock_dlm -j 2 /dev/drbd0

Com isto ele irá iniciar o sincronismo com slave, pode ser observado executando o comando:

# watch -n 1 cat /proc/drbd

Inicie o serviços de cluster:

# service cman start

Testando

# mount -v /dev/drbd0 /data
# for i in `seq 1 10`; do a=`echo $RANDOM`; dd if=/dev/zero of=/data/$a bs=1k count=$a; sleep 1; done
# ls -ltrk /data

Forçando um reboot:
# echo 1 > /proc/sys/kernel/sysrq
# echo b > /proc/sysrq-trigger


Para forçar o sincronismo de uma máquina
(faça somente se souber o que está fazendo)
# drbdsetup /dev/drbd0 primary -o

Ordem dos scripts:

Essa deverá ser a ordem para init level 0 e 6, pois durante o reboot/ shutdown da máquina o procedimento é o seguinte:
- Desmonta a partição
- Tira a máquina do Cluster
- Para o DRBD

[root@hotsite-2 /etc/rc0.d]# ll | egrep '(partition|drbd|cman)'
lrwxrwxrwx 1 root root 12 Jun 13 11:57 K80partition -> ../init.d/partition
lrwxrwxrwx 1 root root 14 Jun 13 11:47 K81cman -> ../init.d/cman
lrwxrwxrwx 1 root root 14 Jun 13 11:57 K82drbd -> ../init.d/drbd

Para os init level 3, 4 e 5 deverá ser:
- Coloca a máquina do Cluster
- Inicia o DRBD
- Monta a partição do drbd (pois o mesmo irá falhar durante a inicialização)

[root@hotsite-2 /etc/rc3.d]# ll | egrep '(partition|drbd|cman)'
lrwxrwxrwx 1 root root 14 Jun 13 11:55 S21cman -> ../init.d/cman
lrwxrwxrwx 1 root root 14 Jun 13 11:55 S70drbd -> ../init.d/drbd
lrwxrwxrwx 1 root root 12 Jun 13 11:55 S91partition -> ../init.d/partition

O Script obliterate

O script Obliterate foi escrito pelo Lon Hohberger e está disponível aqui.

Eu alterei as últimas linhas pois o fence_manual precisa que o comando fence_ack_manual seja executado, senão o GFS não vai liberar o I/O do cluster enquanto o outro nó não retornar com sucesso…

#
fence_node $REMOTE
fence_ack_manual -O -e -n $REMOTE
 
if [ $? -eq 0 ]; then
	# Reference:
	# http://osdir.com/ml/linux.kernel.drbd.devel/2006-11/msg00005.html
	# 7 = node got blown away.  
	exit 7
fi
 
# Fencing failed?!
exit 1

Referência: http://sources.redhat.com/cluster/wiki/DRBD_Cookbook

“Recentemente precisei configurar um ambiente com RHEL 5.1 Cluster Suite.

Em contato com o pessoal do canal #linux-cluster no irc.freenode.net, eles me esclareceram algumas dúvidas e então consegui montar o ambiente.

Assim, resolvi criar um howto em português para que fosse disponibilizado na página do projeto de cluster da redhat, e aqui está o link para os interessados.”

http://sources.redhat.com/cluster/wiki/QuickStart-Portuguese

Este post é somente para agregar mais uns links interessantes sobre o assunto:

FAQ Sobre Fencing Devices

Replicated Failover Domain Controller and file server using LDAP

How to use GNBD to export and import devices for GFS

Teaching your cluster and storage systems to dance: An introduction to Conga

Using Red Hat GFS with Red Hat Cluster Suite

Por último, mas não menos importante, um “txt” tosco, mas nem por isso com menas informações do que os demais: cluster2-arch.txt. Lá existe uma seção muito esclarecedora sobre “Fencing: What, When, Why”.

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

$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