Carlos Rodrigues

Migrar certificados do Netscape/iPlanet para o Apache

Fri, 26 Dec 2008 18:34:00 GMT

Copiar os ficheiros correspondentes ao certificado que queremos extrair para uma directoria temporária na máquina de destino. Estes estão numa directoria chamada alias, dentro da instalação do iPlanet, e deverão ter nomes do tipo nome-cert.db e nome-key.db.

Na máquina de destino instalar o pacote nss-tools, se não estiver já instalado.

O primeiro passo na extracção dos certificados é a extracção da chave privada. Em primeiro lugar usa-se o comando pk12util para gerar um ficheiro em formato PKCS#12...

pk12util -d . -P nome- -n Server-Cert -o private.p12 -K password

...onde "password" é a senha de acesso ao ficheiro original (que o iPlanet pede quando arranca). É pedida outra senha (para proteger o ficheiro novo), que deverá ficar em branco.

Agora é necessário converter o resultado do comando anterior num ficheiro que possa ser usado pelo Apache (com a chave privada em base64)...

openssl pkcs12 -in private.p12 -out private.key -nodes -nocerts

Novamente, a senha pedida deverá ficar em branco.

Passamos então à extracção da chave pública (o certificado). Desta vez usamos o comando certutil duas vezes, uma para exportar o certificado em formato texto, outra para o exportar em base64. Na realidade apenas bastaria uma destas alternativas, mas assim o ficheiro fica mais completo.

certutil -d . -P nome- -L -n Server-Cert > certificate.crt
certutil -d . -P nome- -L -n Server-Cert -a >> certificate.crt

Se o certificado estiver assinado por uma CA intermédia (situação em que se torna necessário usar a directiva SSLCertificateChainFile no Apache), o root certificate desta pode ser extraído desta mesma forma.

Nota: Os nomes dos ficheiros originais não devem ser alterados, daí a utilização do parâmetro -P nome-, caso contrário torna-se impossível extrair a chave privada. Eu perdi horas por causa disto...

Cluster simples com Linux-HA

Fri, 26 Dec 2008 17:48:00 GMT

Os passos seguintes mostram como se pode configurar um cluster de dois servidores web Apache sobre RHEL 5 (64bit) em modo failover, usando o serviço heartbeat do projecto Linux-HA.

Salvo indicação em contrário, todas as acções indicadas referem-se a ambas as máquinas.

Requisitos

Apache instalado e configurado em ambas as máquinas.
As máquinas deverão estar ligadas directamente com um cabo de rede cruzado através de uma segunda interface de rede (por onde passará o tráfego de controlo do cluster). Para este exemplo, esta será a interface eth1, com os endereços 192.168.100.101 (nó primário) e 192.168.100.102 (nó secundário).

É também necessário que o Apache esteja parado e inibido de arrancar automaticamente, pois isto irá ser controlado pelo serviço heartbeat...

$ service httpd stop
$ chkconfig httpd off

Os endereços de serviço de ambos os nós deverão estar definidos no ficheiro /etc/hosts, para evitar dependências com o DNS:

192.168.10.11 node1.example.com node1
192.168.10.12 node2.example.com node2

Instalação

Agora é preciso instalar o software. Os pacotes necessários não fazem parte dos repositórios oficiais da Red Hat, mas podemos configurar o repositório do projecto que tem binários para o RHEL. Para isso cria-se um ficheiro /etc/yum.repos.d/lha-2.1-branch.repo com o seguinte conteúdo:

[lha-2.1-branch]
name=Linux HA v2.1.x branch (RHEL 5)
type=rpm-md
baseurl=http://download.opensuse.org/repositories/server:/ha-clustering:/lha-2.1/RHEL_5/
gpgcheck=1
gpgkey=http://download.opensuse.org/repositories/server:/ha-clustering:/lha-2.1/RHEL_5/repodata/repomd.xml.key
enabled=1

Agora já estamos em condições de os instalar com...

$ yum install heartbeat.x86_64

Nota: Numa instalação de 64bit é necessário indicar explicitamente "x86_64" para evitar que os pacotes de 32bit sejam instalados.

Configuração

Os ficheiros de configuração do heartbeat residem na directoria /etc/ha.d.

A comunicação entre os nós é autenticada, apesar de circular por uma rede dedicada. A configuração faz-se no ficheiro authkeys, que tem de estar acessível apenas ao root...

$ chmod 0600 authkeys

Para a autenticação precisamos de uma chave secreta. A forma mais fácil é gerar uma chave aleatória, por exemplo...

$ dd if=/dev/urandom count=1024 | sha1sum

Supondo que o resultado deste comando foi 46d2393c7ab52836b1169514e8cc857f511041b4, o ficheiro authkeys ficará com o seguinte formato:

auth 1
1 sha1 46d2393c7ab52836b1169514e8cc857f511041b4

Nota: Apesar do método de autenticação ser SHA-1 e de termos usado o comando sha1sum para gerar a chave secreta, uma coisa não tem relação com a outra.

O passo seguinte é definir no ficheiro haresources que recursos existem no cluster, e qual o nó primário para estes recursos. Neste caso existe um endereço partilhado 192.168.10.10 e o serviço httpd. Como ambos devem residir no mesmo nó, este ficheiro terá apenas uma linha...

node1.example.com MailTo::root::Apache-Cluster IPaddr2::192.168.10.10/24/eth0 httpd

Nota 1: O nome do nó deverá coincidir com o resultado do comando uname -m.
Nota 2: O httpd corresponde a um serviço na directoria /etc/init.d.

Os recursos são iniciados pela ordem em que estão definidos, pelo que o endereço do cluster é adicionado à interface eth0 e só depois é arrancado o serviço httpd. O comando MailTo permite enviar um alerta ao administrador quando os recursos arrancam ou quando são migrados para outro nó.

Partimos então para a configuração do serviço de heartbeat propriamente dito, no ficheiro ha.cf, que terá a seguinte forma no nó primário:

debugfile       /var/log/ha-debug
logfile         /var/log/ha-log
logfacility     local0

keepalive       2
deadtime        30
warntime        10
initdead        90

udpport 694
bcast   eth1
ucast   eth1 192.168.100.102

# If this remote host is unreachable for "deadping" seconds, the heartbeat
# enters a failed state and its resources are brought up in the other node.
# However, if the host is unreachable from both cluster nodes the failover
# does not happen (it would be pointless).
ping            192.168.10.254
deadping        20
respawn         hacluster /usr/lib64/heartbeat/ipfail

# Power-cycle the machine if it hangs...
watchdog        /dev/watchdog

auto_failback   on

node    node1.example.com
node    node2.example.com

Nota 1: A linha correspondente ao watchdog deverá ser eliminada se a máquina não tiver esta funcionalidade (ver p.ex. Watchdog em Debian).
Nota 2: O endereço 192.168.100.102 corresponde ao outro nó do cluster.

Esta configuração tem duas particularidades: os recursos voltam sempre ao nó primário assim que este volte a estar disponível (auto_failback on) e a conectividade de rede é monitorizada fazendo regularmente ping a uma terceira máquina (que normalmente será o router da rede).

No nó secundário a configuração será praticamente igual, alterando-se apenas o endereço "ucast", ficando:

debugfile       /var/log/ha-debug
logfile         /var/log/ha-log
logfacility     local0

keepalive       2
deadtime        30
warntime        10
initdead        90

udpport 694
bcast   eth1
ucast   eth1 192.168.100.101

# If this remote host is unreachable for "deadping" seconds, the heartbeat
# enters a failed state and its resources are brought up in the other node.
# However, if the host is unreachable from both cluster nodes the failover
# does not happen (it would be pointless).
ping            192.168.10.254
deadping        20
respawn         hacluster /usr/lib64/heartbeat/ipfail

# Power-cycle the machine if it hangs...
watchdog        /dev/watchdog

auto_failback   on

node    node1.example.com
node    node2.example.com

Resta-nos iniciar e configurar o serviço heartbeat para arrancar automaticamente...

$ service heartbeat start
$ chkconfig heartbeat on

Verificação

Ao parar o heartbeat no nó primário, os serviços migram para o nó secundário, o que se pode verificar com...

$ ip address show eth0
$ service httpd status

Nota: O comando ifconfig não mostrará o endereço do cluster pois este é puramente um endereço secundário, e não uma interface de rede virtual.

Ao arrancar o heartbeat no nó primário, os serviços deverão migrar novamente.

Considerações

É importante aqui referir que o heartbeat não monitoriza o estado dos recursos. Isto é, se o serviço httpd parar, não é arrancado novamente nem ocorre uma migração para o nó secundário. Existem formas de o fazer, mas tal está fora do âmbito desta receita.

Quando um endereço partilhado migra de um nó para outro, o recurso IPaddr2 encarrega-se de enviar pedidos arp para a rede de modo a forçar a actualização das tabelas dos seus vizinhos. Isto pode verificar-se fazendo ping para o endereço de cluster durante uma migração e constatando que não se perdem pacotes.

Quando o serviço heartbeat é iniciado, aparece uma mensagem "INFO: Resource is stopped". Isto é normal.

TCP wrappers (hardening)

Fri, 26 Dec 2008 13:21:00 GMT

Mesmo com uma firewall local configurada, é conveniente ter os serviços que fazem uso dos tcp wrappers (p.ex. portmap) limitados à máquina local por omissão. Isto obtém-se editando o ficheiro /etc/hosts.deny para conter apenas a seguinte linha:

ALL: ALL EXCEPT 127.0.0.0/255.0.0.0

No entanto, o OpenSSH também faz uso dos tcp wrappers e este interessa-nos manter aberto. Para isso adiciona-se a linha seguinte ao ficheiro /etc/hosts.allow:

sshd: ALL

A partir daqui, se for necessário, basta adicionar mais linhas a este ficheiro. A lista dos processos que fazem uso dos tcp wrappers actualmente em execução pode obter-se com o seguinte comando:

$ lsof | grep libwrap | cut -d' ' -f1 | sort -u

Directorias ".DS_Store" na rede

Sat, 04 Oct 2008 15:31:00 GMT

Para impedir que o Mac OS X crie directorias .DS_Store em todas as partilhas de rede, abrir um terminal e escrever...

$ defaults write com.apple.desktopservices DSDontWriteNetworkStores true

Finalmente, fazer logoff e login novamente.

Esta é uma definição per user, pelo que é preciso correr este comando para cada uma das contas de utilizador da máquina.

Efeito "glass" na Dock

Sat, 04 Oct 2008 15:31:00 GMT

Para remover o efeito glass quando a Dock se encontra no fundo do ecrã, abrir um terminal e correr os seguintes comandos:

$ defaults write com.apple.dock no-glass -boolean true
$ killall Dock

Para reverter ao original, basta fazer...

$ defaults delete com.apple.dock no-glass
$ killall Dock

Passos pós-instalação para RHEL 5

Fri, 15 Aug 2008 19:53:00 GMT

Esta receita segue o meu gosto pessoal e refere-se a um servidor com Red Hat Enterprise Linux 5, não registado, sem actualizações, com o SELinux desactivado e sem nenhum role escolhido durante o processo de instalação.

Para começar, registar o sistema na Red Hat Network para podermos utilizar o yum:

$ rhn_register

Evitar ter de usar o vi para editar os ficheiros de configuração que se seguem...

$ yum install joe

Editar o ficheiro /etc/fstab e...

Para os volumes LVM, substituir as labels pelo nome do volume;
Acrescentar o parâmetro acl a todos os filesystems ext3 locais, excepto a /boot;
Adicionar uma entrada para o leitor de CD:

/dev/cdrom /media/cdrom auto defaults,ro,noauto 0 0

Não queremos mostrar demasiada informação sobre a máquina aos utilizadores que se ligam remotamente, portanto criamos um novo ficheiro /etc/issue.net. Por exemplo:

/*
 |
 | Welcome to <maquina>
 |
 | Authorized access only. All connections are logged.
 | Apenas acesso autorizado. Todas as ligacoes sao registadas.
 |
 */

Adicionar o utilizador criado durante a instalação ao grupo users com o comando:

$ usermod -G users <utilizador>

Editar o ficheiro /etc/ssh/sshd_config e definir...

PermitRootLogin no     # não queremos acessos remotos do root
AllowGroups users      # não queremos aceitar qualquer utilizador
Banner /etc/issue.net  # queremos mostrar uma mensagem antes do login

Correr o comando visudo para alterar a configuração do sudo e adicionar...

Defaults targetpw         # pedir a password do root em vez da password do utilizador
utilizador ALL=(ALL) ALL  # dar privilégios ao utilizador criado durante a instalação

Infelizmente, algum software proprietário ainda tem problemas com internacionalização. Por isso, edita-se o ficheiro /etc/sysconfig/i18n e substitui-se en_US.UTF-8 por...

LANG="en_US"

No ficheiro /etc/hosts, desassociar o hostname da máquina do nome localhost e adicionar a seguinte linha:

127.0.1.1       machine.example.com machine

Nota: Se irá existir algum serviço a correr que obrigue a que o hostname da máquina esteja associado ao mesmo endereço registado no DNS (p.ex. rmiregistry) e este for um endereço estático, deve ser usado em vez de 127.0.1.1. Se o endereço registado no DNS for atribuído dinamicamente, a linha deve ser omitida completamente.

Instalar o pacote sendmail-cf para podermos alterar a configuração do sendmail:

$ yum install sendmail-cf

Editar o ficheiro /etc/mail/sendmail.mc, configurar o SMART_HOST e correr make para gerar a configuração nova.

Editar o ficheiro /etc/aliases para enviar o email do root também para o endereço do administrador:

root: root,admin@example.com

Desactivar alguns serviços que não interessa ter a correr num servidor:

$ chkconfig avahi-daemon off
$ chkconfig rhnsd off
$ chkconfig yum-updatesd off

Activar o Name Service Caching Daemon:

$ chkconfig nscd on

Configurar a monitorização dos discos locais editando o /etc/smartd.conf.

Se a máquina suportar IPMI, instalar o software necessário e activar o serviço:

$ yum install OpenIPMI-tools
$ chkconfig ipmi on

Adicionalmente, editar o ficheiro /etc/sysconfig/ipmi para configurar o watchdog IPMI.

Remover alguns pacotes que não interessam:

$ rpm -e logwatch isdn4k-utils hplip irda-utils pcsc-lite \
         vnc-server ifd-egate ccid coolkey esc autofs bluez-gnome \
         bluez-libs bluez-utils ypbind yp-tools java-1.4.2-gcj-compat \
         libgcj gjdoc antlr hpijs libsane-hpaio sane-backends \
         sane-backends-libs sane-frontends xsane

E instalar alguns pacotes interessantes:

$ yum install sysstat procinfo iptraf strace ltrace screen lynx lsscsi gcc gcc-c++

Criar um script executável /etc/profile.d/profile.local.sh com definições específicas desta máquina (aliases, acrescentos à PATH, ...).

Criar uma directoria /root/bin para colocar eventuais scripts de administração.

Fechar o acesso aos serviços que usam tcp wrappers (ver: TCP wrappers (hardening)).

Configurar a firewall com a ferramenta system-config-securitylevel.

Finalmente, fazer as actualizações do sistema e limpar o lixo:

$ yum update
$ yum clean all
$ rpm --rebuilddb

Reiniciar a máquina para tornar as configurações efectivas.

Bloquear ARP

Sun, 24 Feb 2008 19:47:00 GMT

Problema 1 (balanceamento de carga)

Temos várias máquinas em cluster com um load balancer à frente. O load balancer responde num endereço 10.0.0.2 (endereço do cluster) e reencaminha o tráfego para uma das máquinas backend fazendo forward dos pacotes, sem alterar o endereço IP. Neste caso, para estas máquinas não rejeitarem os pacotes, têm de ter o endereço de cluster configurado como alias numa das suas interfaces (normalmente no loopback). Se não fizermos nada, cada uma delas vai assumir o endereço como seu e responder a pedidos ARP, e aí temos confusão...

Solução

Em cada uma das máquinas backend configuramos o endereço do cluster e bloqueamos os pedidos ARP com...

$ ip addr add 10.0.0.2/32 label lo:0 dev lo
$ arptables -F
$ arptables -A IN -d 10.0.0.2 -j DROP

Como salvaguarda para o caso das máquinas lançarem acidentalmente pedidos ARP na rede com o endereço de cluster, fazemos ainda...

$ arptables -A OUT -s 10.0.0.2 -j mangle --mangle-ip-s $IP_ADDRESS

Onde $IP_ADDRESS é o endereço real da máquina.

Problema 2 (máquina invisível)

Suponhamos agora que temos uma máquina a capturar tráfego na rede e queremos que ela esteja completamente invisível aos utilizadores. No entanto, também queremos que esteja acessível a partir da máquina do administrador de rede.

Solução

Na máquina que queremos que seja invisível bloqueamos todos os pedidos ARP e configuramos estaticamente o endereço MAC da máquina do administrador:

$ arptables -F
$ arptables -A IN -j DROP
$ arptables -A OUT -j DROP
$ ip neigh add $ADMIN_BOX_IP lladdr $ADMIN_BOX_MAC nud permanent dev eth0

Adicionalmente, se quisermos que esta máquina consiga resolver nomes por DNS, configuramos também o endereço MAC do servidor DNS:

$ ip neigh add $DNS_SRV_IP lladdr $DNS_SRV_MAC nud permanent dev eth0

Para que a máquina do administrador de rede consiga iniciar ligações para a máquina invisível, temos de configurar lá o endereço MAC desta...

$ ip neigh add $INVISIBLE_IP lladdr $INVISIBLE_MAC nud permanent dev eth0

Nota

Os comandos arptables indicados acima funcionam em RHEL 5. Noutras distribuições (ex: Debian 4.0) poderá ter de usar-se INPUT/OUTPUT em vez de IN/OUT. Para verificar quais os nomes correctos, basta correr o comando arptables -L.

Storage em Linux com LVM

Sat, 23 Feb 2008 18:28:00 GMT

Fundamentalmente, o Logical Volume Manager (LVM) permite-nos agrupar conjuntos de physical volumes em volume groups, onde um physical volume pode ser um disco inteiro (ex: /dev/sda), uma partição (ex: /dev/sda1), um RAID por software (ex: /dev/md0), um disco remoto (ex: /dev/etherd/e0.0), ou qualquer outro device que se comporte como um disco.

O espaço total num volume group pode então ser dividido em múltiplos volumes lógicos, sem quaisquer preocupações acerca da sua estrutura física. Mais concretamente, os volumes lógicos podem ser criados com qualquer tamanho, e ser aumentados ou encolhidos conforme necessário. A única limitação é o espaço livre no volume group pois, como é óbvio, não podemos expandir um volume lógico se o volume group a que pertence estiver totalmente alocado, por exemplo. Na prática os volumes lógicos são equivalentes a partições, e podem ser formatados com filesystems, usados como tablespace devices para bases de dados, etc.

As instruções seguintes mostram como se pode configurar um volume group LVM sobre dois discos de 100Gb (por exemplo) contendo alguns volumes lógicos.

Assim, o primeiro passo na criação do novo volume group é a inicialização dos dois discos como physical volumes. Como vamos usar todo o espaço disponível nos discos, podemos optar por criar uma partição em cada disco ou podemos simplesmente usar cada um deles directamente, sem partições. O resultado final é idêntico mas, por uma simples questão de gosto, eu prefiro criar partições quando se trata de discos locais.

$ pvcreate /dev/sda1
$ pvcreate /dev/sdb1

Nota: Quando estamos a usar partições de discos como physical volumes LVM, convém que estas sejam do tipo Linux LVM. Não é obrigatório que assim seja, mas recomenda-se.

Em seguida, criamos o volume group com o nome vg0, composto pelos dois physical volumes inicializados acima:

$ vgcreate vg0 /dev/sda1 /dev/sdb1

Depois, podemos experimentar alocar parte dos 200Gb agora disponíveis no volume group a três volumes lógicos, ficando ainda com algum espaço livre (para expansão futura, ou para permitir a criação de snapshots):

$ lvcreate -L 50G -n lv0 vg0
$ lvcreate -L 100G -n lv1 vg0
$ lvcreate -L 5.5G -n lv2 vg0

Nota: Os nomes dos volumes não têm de ter esta forma (vg0, lv0, ...), podem perfeitamente chamar-se "joaquim", ou "manuel", ou o que o utilizador achar que faz sentido.

Finalmente, podemos experimentar formatar um deles que fica assim pronto para ser utilizado:

$ mkfs.ext3 /dev/vg0/lv0

Activação manual

Em geral, os volume groups são activados automaticamente, quer seja durante o processo de arranque ou (implicitamente) no momento da sua criação. No entanto, se um ou mais discos contendo volumes LVM for adicionado depois do arranque, é preciso activá-los manualmente. Isto faz-se correndo os comandos:

$ vgscan
$ vgchange -ay

Nesta forma o comando vgchange activa todos os volume groups detectados pelo comando vgscan. Se quisermos activar apenas um volume group em particular, podemos passá-lo como parâmetro:

$ vgchange -ay vg1

Nota 1: Se existir colisão de nomes entre os novos volume groups e os volume groups já existentes na máquina, este procedimento não pode ser utilizado. Perante esta situação é necessário usar o comando vgexport (na máquina de origem) e depois utilizar o comando vgimport (renomeando os volumes) antes da activação poder ser efectuada.

Nota 2: Sabendo que a activação manual é mais frequentemente utilizada em situações de emergência, convém referir que na maioria dos rescue disks apenas está disponível o comando lvm crú, pelo que todas as operações devem ser invocadas na forma lvm <comando> (ex: lvm vgscan).

Informação sobre physical volumes, volume groups e volumes lógicos

Para ver o espaço alocado por um volume group, os volumes lógicos que contém e os physical volumes que o compõem, usamos o comando vgdisplay -v vg0. Adicionalmente, podemos obter um resumo de todos os volume groups, volumes lógicos e physical volumes disponíveis na máquina com os comandos vgs, lvs e pvs respectivamente.

Renomear volume groups e volumes lógicos

Se for necessário, tanto os volumes lógicos como os volume groups podem ser renomeados a qualquer momento, desde que estejam activos, mesmo quando têm filesystems montados. Para tal usam-se os comandos vgrename e lvrename. Por exemplo, o seguinte comando muda o nome do volume lógico lv0 para bob:

$ lvrename vg0 lv0 bob

Eliminar volume groups e volumes lógicos

Desde que não esteja em uso, um volume lógico pode ser eliminado com o comando lvremove /dev/vg0/lv0. O espaço libertado fica disponível para reutilização no volume group a que pertencia.

Apesar de ser uma operação menos comum, um volume group também pode ser eliminado. Para o fazer é necessário eliminar primeiro todos os volumes lógicos nele contidos, e só depois correr o comando vgremove vg0.

Se não for utilizado o parâmetro -f, ambos os comandos pedem a confirmação do utilizador.

Expandir ou encolher volumes LVM

Sat, 23 Feb 2008 18:27:00 GMT

Um dos principais benefícios do LVM é a possibilidade de alterar os tamanhos dos volumes sempre que tal seja necessário, incluindo a alteração do espaço disponível nos volume groups através da adição ou remoção de discos, sem reiniciar a máquina.

Expandir um volume lógico

Como se compreende facilmente, para expandir um volume lógico é necessário que o volume group a que pertence tenha espaço disponível. No entanto, o espaço não tem de ser contíguo nem adjacente ao volume lógico a expandir. Posto isto, e como exemplo, para atribuir mais 10Gb ao volume lv0 usa-se o comando lvextend:

$ lvextend -L +10G /dev/vg0/lv0

Mas isto só aumenta o tamanho do volume lógico. Se este contiver um filesystem, é preciso redimensioná-lo também, e a forma de o fazer vai depender do sistema de ficheiros em causa. Se for ext3, basta usar o comando resize2fs, sem necessidade de fazer umount:

$ resize2fs -p /dev/vg0/lv0

Para outros sistemas de ficheiros existirá um comando semelhante, ou até algo completamente diferente, como é o caso do jfs:

$ mount -o resize,remount /dev/vg0/lv0

Encolher um volume lógico

Para reduzir o tamanho de um volume lógico pode usar-se o comando lvreduce. No entanto, é preciso ter em conta que a maioria dos sistemas de ficheiros não suportam a redução de tamanho e os que suportam não o permitem fazer sem um umount prévio.

A título de exemplo, eis como se encolhe um volume lógico lv0, contendo um sistema de ficheiros ext3, de 20Gb para 15Gb...

Para evitar erros nas contas que possam provocar perdas de dados, primeiro encolhemos o filesystem para um tamanho inferior ao que terá no final:

$ umount /mnt/filesystem
$ e2fsck -f /dev/vg0/lv0
$ resize2fs -p /dev/vg0/lv0 12G

De seguida, reduzimos o volume lógico para a dimensão pretendida:

$ lvreduce -L -5G /dev/vg0/lv0

Finalmente, expandimos o filesystem para a totalidade do espaço no volume lógico:

$ resize2fs -p /dev/vg0/lv0

Nota: Se o volume lógico não contiver um filesystem, mas sim um tablespace de uma base de dados (por exemplo), a forma mais segura de fazer a redução de tamanho deverá ser semelhante.

Alterar o tamanho de um volume group (adicionar e remover discos)

Para adicionar um novo disco ao volume group vg0, e assim aumentar o espaço disponível para criar ou expandir volumes lógicos, basta correr os comandos seguintes:

$ pvcreate /dev/sdc1
$ vgextend vg0 /dev/sdc1

Por outro lado, para remover um disco é preciso mover o espaço nele alocado (volumes lógicos) para outras zonas do volume group. Para isto usa-se o comando pvmove e, como é natural, o volume group tem de ter espaço livre suficiente para acomodar a migração dos dados...

$ pvmove -v /dev/sdb1
$ vgreduce vg0 /dev/sdb1

Alterar o tamanho de um physical volume (expansão implícita do volume group)

Se um physical volume tiver aumentado de tamanho (ex: um RAID por software que foi expandido), para que expaço extra fique disponível no volume group a que pertence é necessário executar o comando...

$ pvresize /dev/md0

Expandir um array RAID-1 (software) em Linux

Sat, 23 Feb 2008 18:15:00 GMT

Os passos seguintes mostram como se pode expandir um array RAID-1 (software) sem perigo de perder dados e minimizando os tempos de espera enquanto os seus componentes se sincronizam. Se os discos forem hot-swappable, todas as operações podem ser efectuadas com a máquina em funcionamento e sem reiniciar o sistema.

Tomemos o array md0, composto por dois discos de 120Gb com uma partição cada (sdb1 e sdc1). Queremos expandir este array com dois discos novos de 400Gb.

Em primeiro lugar expulsamos o primeiro disco do array:

$ mdadm --fail /dev/md0 /dev/sdb1
$ mdadm --remove /dev/md0 /dev/sdb1

Removemos este disco da máquina e colocamos no seu lugar um disco maior. Com o cfdisk (ou outra ferramenta de particionamento) criamos neste novo disco uma partição de tipo Linux raid autodetect e adicionamo-la ao array:

$ mdadm --add /dev/md0 /dev/sdb1

Agora esperamos que o array se sincronize, o que poderá demorar bastante tempo. Para observar o progresso podemos fazer cat /proc/mdstat.

Com os dados já replicados no disco novo, expulsamos o segundo disco antigo do array:

$ mdadm --fail /dev/md0 /dev/sdc1
$ mdadm --remove /dev/md0 /dev/sdc1

Nesta altura já podemos expandir o array para o novo espaço disponível, usando o comando:

$ mdadm --grow --size=max /dev/md0

Podemos confirmar que o array aumentou verificando o número de blocos reportados pelo ficheiro /proc/mdstat ou através do comando mdadm --detail /dev/md0.

Removemos então o segundo disco antigo disco da máquina e colocamos no seu lugar um disco maior. Para este segundo disco já não precisamos de criar a partição manualmente, podemos simplesmente copiar a tabela de partições do primeiro disco (assumindo que os discos são iguais) e adicioná-la ao array:

$ sfdisk -d /dev/sdb | sfdisk /dev/sdc
$ mdadm --add /dev/md0 /dev/sdc1

Novamente, o array inicia a sincronização dos dados para o novo disco. No entanto, desta vez não temos de esperar pelo fim deste processo para o continuar a utilizar.

Passos seguintes

Se o array tiver um sistema de ficheiros ext3 em cima, este pode ser expandido (mesmo sem fazer umount) com o comando:

$ resize2fs /dev/md0

Se o array estiver integrado num volume group LVM como um physical volume, o espaço extra só estará disponível para utilização em volumes lógicos após executado o comando:

pvresize /dev/md0

Segurança dos dados

A expulsão dos discos antigos do array não destrói quaisquer dados, pelo que qualquer um deles (ou ambos) pode ser usado para activar o array na sua forma inicial em caso de problemas. Desta forma pode dizer-se que a expulsão do primeiro disco constitui imediatamente um backup.

Notas

Tal como acontece ao criar um novo array, ao colocarmos discos novos convém criar as partições destinadas ao RAID com um tamanho ligeiramente inferior ao do disco físico. Isto permite substituir um disco avariado por outro de um fabricante diferente já que, para um dado tamanho anunciado, discos de fabricantes diferentes podem ter tamanhos reais distintos.

RAID-1 (software) em Linux

Sat, 23 Feb 2008 18:12:00 GMT

Em Linux, qualquer block device pode ser usado como componente de um array RAID por software, desde discos físicos a volumes lógicos LVM. No entanto, o mais comum é usar partições de discos, e é isso que vamos usar nos exemplos abaixo.

Antes de seguir em frente, é necessário instalar a ferramenta mdadm. Em Debian, basta fazer...

$ aptitude install mdadm

Como extra, este pacote configura imediatamente a monitorização de todos os arrays RAID activos, enviando notificações para o email do root sempre que ocorra algo importante (avaria num disco, por exemplo).

Criação do array

Para colocar dois discos em RAID-1 (mirror), começamos por criar no primeiro uma partição de tipo Linux raid autodetect usando o cfdisk (ou outra ferramenta de particionamento). Esta partição deverá ser ligeiramente inferior à capacidade total do disco para permitir a sua substituição por um disco de outro fabricante em caso de avaria. (Para uma dada capacidade anunciada, discos de fabricantes diferentes podem ter capacidades ligeiramente diferentes.)

No segundo disco deverá ser criada uma partição equivalente. Se os discos são iguais, isto pode ser feito através da simples cópia da tabela de partições do primeiro disco:

$ sfdisk -d /dev/sdb | sfdisk /dev/sdc

Se os discos são diferentes, a partição do segundo disco deverá ser criada manualmente. Se, por alguma razão, não se conseguir criar uma partição com exactamente a mesma capacidade da partição do primeiro disco, também não há problema, pois o array ficará com o tamanho da partição mais pequena. Neste aspecto o RAID por software em Linux é bastante flexível.

Criamos então um array de nome md0 usando o seguinte comando:

$ mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1

Nesta altura inicia-se o processo de sincronização, cujo progresso pode ser acompanhado com cat /proc/mdstat. O array pode começar a ser utilizado imediamente, mesmo enquanto este processo decorre.

Criação do array (modo degradado)

É possível criar um array com apenas um disco, utilizando missing no lugar do outro disco:

$ mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 missing

Isto pode ser útil quando, por exemplo, queremos começar a utilizar um array imediatamente e ainda não temos o segundo disco disponível. Este pode ser adicionado mais tarde com o comando...

$ mdadm --add /dev/md0 /dev/sdc1

Debian

Em Debian, por omissão, todos os módulos associados ao RAID por software são carregados durante o arranque do sistema. Para que apenas sejam carregados os módulos necessários para o RAID-1, devemos actualizar o ficheiro de configuração /etc/mdadm/mdadm.conf e a imagem initrd do sistema. Isto faz-se executando os comandos:

$ /usr/share/mdadm/mkconf force-generate
$ update-initramfs -u -k all

Note-se que isto é recomendado, mas não é obrigatório. O próprio kernel detecta e inicializa automaticamente os RAIDs baseados em partições de tipo Linux raid autodetect, e ter módulos carregados relativos a níveis RAID não utilizados também não faz mal, para além de consumir um pouco de memória.

Mais informação

Para listar os arrays RAID disponíveis na máquina, pode usar-se o comando:

$ mdadm --detail --scan

Para obter mais detalhes sobre um array, para além do que se pode ver no ficheiro /proc/mdstat, faz-se...

$ mdadm --detail /dev/md0

Remover e adicionar discos

Para remover um disco (partição) de um array usam-se os comandos seguintes:

$ mdadm --fail /dev/md0 /dev/sdc1
$ mdadm --remove /dev/md0 /dev/sdc1

Quando um disco avaria, o sistema marca-o como failed, pelo que apenas é necessário executar o segundo comando (--remove) antes de o remover fisicamente da máquina.

Para adicionar um disco (partição) novo em substituição de um disco avariado, ou para voltar a adicionar um disco (partição) anteriormente removido:

$ mdadm --add /dev/md0 /dev/sdc1

Se adicionarmos um terceiro disco a um array criado com --raid-devices=2, este torna-se um spare. Em caso de avaria de um dos discos activos, o spare é colocado no seu lugar automaticamente.

Activação manual

Em alguns casos pode ser necessário activar um array manualmente. Imaginemos que, por alguma razão, um dos discos de um array RAID-1 é colocado numa caixa de discos externos e ligada a outra máquina. Para activar um novo array na máquina de destino, utilizando apenas este disco, é necessário fazer:

$ mdadm --assemble --run /dev/md1 /dev/sdd1

Onde md1 é um nome livre na máquina de destino e sdd1 é o nome atribuído ao disco externo.

A opção --run é necessária para activar o array em modo degradado (sem estarem presentes todos os seus componentes). Se todos os componentes estiverem disponíveis, podemos usar o comando:

$ mdadm --assemble /dev/md1 /dev/sdd1 /dev/sde1

Destruição de um array

Não existe propriamente um comando para destruir um array. A única forma de o fazer consiste em desactivá-lo e, de seguida, escrever zeros sobre cada um dos componentes. Assim:

$ mdadm --stop /dev/md0
$ mdadm --zero-superblock /dev/sdb1
$ mdadm --zero-superblock /dev/sdc1

Assim, mesmo que as partições sdb1 e sdc1 tenham o tipo Linux raid autodetect, não serão reconhecidas como tal nem activadas automaticamente durante o arranque.

Criar snapshots com o LVM

Sat, 23 Feb 2008 14:55:00 GMT

No LVM, as snapshots funcionam numa lógica copy-on-write e inicialmente não ocupam espaço em disco. No entanto, as necessidades de espaço vão aumentando à medida que o volume lógico original vai sendo alterado (e que a própria snapshot vai sendo alterada, se a estivermos a usar em modo read-write). Por esta razão é necessário especificar o tamanho máximo que poderão atingir. Claramente este valor depende do tipo de utilização dos volumes em causa, e pode até ser bastante reduzido para snapshots que irão existir apenas durante um curto período de tempo, mas em geral deverá estar entre 15 e 20% do tamanho do volume original.

Nota: Se o espaço alocado à snapshot se esgotar, esta deixa de poder ser utilizada mas o volume lógico original não sofre quaisquer consequências.

Assim, para capturar instantaneamente o estado actual do volume lógico /dev/vg0/lv0 para dentro de uma snapshot de nome lv0-snap, com um tamanho máximo de 2Gb, faz-se...

$ lvcreate -L 2G -n lv0-snap -s /dev/vg0/lv0

Nota: Como se torna óbvio, não é possível criar snapshots se o respectivo volume group estiver completamente alocado.

A partir daqui a snapshot funciona como um volume perfeitamente normal. Ou seja, se contiver um filesystem ext3 pode ser usada fazendo...

$ mkdir /mnt/snapshot
$ mount -t ext3 /dev/vg0/lv0-snap /mnt/snapshot

E quando já não for necessária, pode ser eliminada com:

$ lvremove -f /dev/vg0/lv0-snap

Sistemas de ficheiros e UUID's

Um filesystem contido numa snapshot é uma cópia do filesystem original, pelo que ambos partilham o mesmo identificador único (UUID). Se isto constitui, ou não, um problema depende do sistema de ficheiros em causa e de estarmos, ou não, a montar filesystems por UUID. Em geral, devemos alterar o UUID do filesystem contido na snapshot sempre que esta não seja descartável a curto prazo e sempre que o UUID esteja a ser usado para montar o filesystem original.

Cada sistema de ficheiros tem um comando diferente para alterar o UUID:

$ tune2fs -U time /dev/vg0/lv0-snap                 # ext3
$ reiserfstune --uuid $(uuidgen) /dev/vg0/lv0-snap  # reiserfs
$ jfs_tune /dev/vg0/lv0-snap -U time                # jfs
$ xfs_admin -U generate /dev/vg0/lv0-snap           # xfs

Quanto a montar múltiplos filesystems com o mesmo UUID, com ext3 ou reiserfs não existe qualquer tipo de problema, mas com xfs é necessário indicar que o UUID do filesystem contido na snapshot deve ser ignorado:

$ mount -o nouuid -t xfs /dev/vg0/lv0-snap /mnt/snapshot

Já com o sistema de ficheiros jfs a restrição é diferente: antes de montar uma snapshot é sempre necessário correr um fsck, mesmo que o seu UUID tenha sido alterado:

$ jfs_fsck /dev/vg0/lv0-snap

Manipular PDFs com o Ghostscript

Tue, 29 Jan 2008 00:55:00 GMT

Concatenar um conjunto de ficheiros PDF num só:

$ gs -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=output.pdf -dBATCH file1.pdf file2.pdf ... fileN.pdf

Extraír uma sequência de páginas para um ficheiro separado:

$ gs -sDEVICE=pdfwrite -dNOPAUSE -dQUIET -dBATCH -dFirstPage=m -dLastPage=n -sOutputFile=output.pdf file.pdf

Nota: Em Windows o Ghostscript é invocado com o comando gswin32 em vez de gs.

Cliente para o Tivoli Storage Manager Backup em Debian

Sat, 15 Dec 2007 14:20:00 GMT

A última versão do cliente de backup do Tivoli Storage Manager para Linux pode ser obtida no site da IBM. Neste caso, iremos usar a versão 5.5.0.1 (que funciona perfeitamente com servidores de versões mais antigas, se tal for necessário).

Para começar, vamos precisar do rpm e de algumas bibliotecas de compatibilidade:

$ aptitude install rpm libstdc++5

Depois, descomprimimos e instalamos o cliente TSM. Neste passo é preciso ter atenção ao facto do pacote descomprimir directamente para a directoria corrente, pelo que convém fazê-lo numa directoria vazia:

$ mkdir tsm
$ cd tsm
$ tar xvf ../5.5.0.1-TIV-TSMBAC-LinuxX86.tar
$ rpm -Uvh --nodeps TIVsm-API.i386.rpm TIVsm-API.i386.rpm

Por alguma razão os ficheiros de localização não são correctamente instalados, pelo que o cliente (dsmc) retornará este erro:

$ /opt/tivoli/tsm/client/ba/bin/dsmc
ANS0101E Unable to open English message repository 'dsmclientV3.cat'.

A solução é simples, basta criar o symlink que está em falta...

$ cd /opt/tivoli/tsm/client/ba/bin
$ ln -s ../../lang/en_US en_US
$ ln -s ../../lang/en_US pt_BR

O segundo symlink (pt_BR) evita que o cliente web se queixe da falta dos ficheiros de localização para português do Brasil (que estão disponíveis em formato rpm no site da IBM, se os quisermos instalar).

O passo seguinte é a configuração do cliente. Na directoria /opt/tivoli/tsm/client/ba/bin criamos o ficheiro dsm.opt com o seguinte conteúdo:

SErvername TSM

E também um ficheiro dsm.sys contendo:

SErvername  TSM
   COMMmethod         TCPip
   TCPPort            1500
   TCPServeraddress   tsmserver.example.com

NODename LINUXBOX1

PASSWORDACCESS  GENERATE

SCHEDLOGNAME            /var/log/tsm/dsmsched.log
SCHEDLOGRETENTION       15
ERRORLOGNAME            /var/log/tsm/dsmerror.log
ERRORLOGRETENTION       15

COMPRESSIon Yes

Como é óbvio, o conteúdo acima deverá ser alterado de forma a reflectir a configuração do servidor em causa. No entanto, convém notar três coisas:

Em ambos os ficheiros de configuração, servername é o nome atribuído ao serviço Tivoli que queremos usar, não o nome da máquina onde este está a correr;
O nodename pode ser omitido se o cliente estiver registado no servidor com um nome igual ao output do comando hostname;
A directoria /var/log/tsm tem de ser criada à mão.

Assumindo que a máquina cliente já está configurada correctamente do lado do servidor, podemos verificar se tudo está a funcionar listando (por exemplo) as tapes disponíveis:

$ /opt/tivoli/tsm/client/ba/bin/dsmadmc
> q vol

Se ocorrer um erro relacionado com a falta da biblioteca libgpfs.so, criamos um ficheiro /etc/ld.so.conf.d/tsm-client.conf contendo:

/opt/tivoli/tsm/client/api/bin

...e corremos o comando ldconfig.

Para poder controlar o calendário de backups a partir do servidor, e para que o cliente web esteja disponível (em http://localhost:1581), é necessário colocar o agente a correr:

$ /opt/tivoli/tsm/client/ba/bin/dsmcad

Para que isto aconteça automaticamente no arranque da máquina, acrescentamos ao ficheiro /etc/rc.local:

# Tivoli Storage Manager
if [ -x /opt/tivoli/tsm/client/ba/bin/dsmcad ]; then
        echo "Starting TSM agent service..."
        /opt/tivoli/tsm/client/ba/bin/dsmcad
fi

Agora, experimentamos fazer backup de um ficheiro:

$ /opt/tivoli/tsm/client/ba/bin/dsmc incremental <ficheiro>

Será necessário fazer login (com o utilizador definido para o cliente, que poderá ser o utilizador de administração do Tivoli, ou não), mas isto apenas acontece da primeira vez que este comando é executado.

Usar sempre o caminho completo nos comandos não é simpático, pelo que acrescentamos ao ficheiro /etc/profile:

#
# Tivoli Storage Manager Client
#
if [ -d /opt/tivoli/tsm/client/ba/bin ]; then
        export PATH="${PATH}:/opt/tivoli/tsm/client/ba/bin"
fi

Nota

Sempre que for instalada uma nova versão do cliente TSM é necessário criar novamente os symlinks para os ficheiros de localização/tradução. Isto é verdade inclusivamente em distribuições baseadas em rpm, como o Red Hat Enterprise Linux.

Cliente para DB2 em Debian

Thu, 01 Nov 2007 16:04:00 GMT

A IBM apenas suporta o DB2 nas distribuições enterprise da Red Hat e SUSE, pelo que são necessários alguns procedimentos manuais para instalar o runtime client em distribuições que não usam rpm, como a Debian.

O primeiro passo é importar o runtime client a partir do site da IBM. Não é necessário ter um CD original, os fix packs também permitem fazer uma instalação de raíz. Neste caso vamos usar o DB2 8.1 FixPak 14 (FP14) para sistemas de 32bit.

Excepto indicação em contrário, todos os passos seguintes deverão ser efectuados como utilizador root.

$ mkdir /tmp/DB2-FP14
$ cd /tmp/DB2-FP14
$ wget ftp://ftp.software.ibm.com/ps/products/db2/fixes2/english-us/db2linux2632/client/runtime/FP14_MI00176_RTCL.tar

As únicas dependências explícitas são a korn shell (para correr o script de instalação) e uma versão da libstdc++ anterior à versão instalada por omissão no Debian 4.0 (etch). Para evitar problemas, não vamos optar pela conversão dos .rpm para .deb, pelo que o rpm também tem de ser instalado...

$ aptitude install ksh libstdc++5 rpm

Como a base de dados do rpm está em branco, temos de forçar a instalação dos pacotes sem verificação de dependências (--nodeps). Para isso, criamos um script que irá invocar o rpm com os parâmetros necessários. Como a directoria /usr/local/bin aparece primeiro na $PATH do root, este script pode ser criado lá (como /usr/local/bin/rpm), evitando mexer no verdadeiro rpm:

#!/bin/bash

if [ "$1" == "-ivh" ]; then
        shift
        /usr/bin/rpm -ivh --nodeps "$@"
else
        /usr/bin/rpm "$@"
fi

Tornar este ficheiro executável...

$ chmod +x /usr/local/bin/rpm

Em Red Hat, ou SUSE, usar-se-ia o instalador gráfico (db2setup) e este faria todo o trabalho de instalação e configuração, mas aqui teremos de usar o instalador de texto (db2_install), que deixa algumas configurações por fazer...

$ cd /tmp/DB2-FP14
$ tar xf FP14_MI00176_RTCL.tar
$ cd rtcl
$ ./db2_install

Após terminado o processo acima, criar uma instância do DB2 (e respectivos utilizadores)...

$ groupadd db2iadm1
$ groupadd db2fadm1

$ useradd -g db2iadm1 -m -d /home/db2inst1 db2inst1
$ useradd -g db2fadm1 -m -d /home/db2fenc1 db2fenc1

$ /opt/IBM/db2/V8.1/instance/db2icrt -u db2fenc1 db2inst1

Ao contrário de outras SGBDs, para aceder a uma base de dados remota em DB2 é necessário registá-la no catálogo local...

$ su - db2inst1
$ db2 catalog tcpip node <server_alias> remote <server> server 50000
$ db2 catalog database <db> as <db_alias> at node <server_alias>

Os comandos acima assumem que o servidor estará à escuta na porta tcp/50000, o que é o normal.

Antes de fazer exit para voltar ao utilizador root, convém verificar que tudo está a funcionar normalmente. Para isso, deveremos fazer uma query à base de dados. Neste caso vamos apenas listar as tabelas:

$ db2 connect to <db_alias> user <username> using <password>
$ db2 list tables
$ db2 terminate

Para que qualquer utilizador da máquina possa ligar-se à base de dados remota, é preciso acrescentar as linhas seguintes ao ficheiro /etc/profile:

if [ -f /home/db2inst1/sqllib/db2profile ]; then
        . /home/db2inst1/sqllib/db2profile
        export PATH="${PATH}:/opt/IBM/db2/8.1/bin"
fi

Ou, para quem usar shells derivadas da csh:

$ ln -s /home/db2inst1/sqllib/db2cshrc /etc/csh/login.d/

Para terminar, podemos remover o script /usr/local/bin/rpm para que tudo fique como estava inicialmente.

Envio de e-mail externo através de um smarthost autenticado (Exim 4)

Sun, 23 Sep 2007 22:02:00 GMT

Para que uma instalação Debian consiga enviar e-mail para fora usando um servidor SMTP que força o uso de autenticação necessitamos de, em primeiro lugar, reconfigurar o Exim:

$ dpkg-reconfigure exim4-config

Nos painéis de configuração apresentados pelo debconf, estas são as opções mais importantes:

Escolher a opção «mail sent by smarthost; received via SMTP or fetchmail» no painel «General type of mail configuration»;
Inserir o nome do servidor de mail que irá fazer relay (p.ex: smtp.telepac.pt) no painel «IP address or host name of the outgoing smarthost»;
Responder sim à questão «Hide local mail in outgoing mail?»;
O passo anterior faz com que os e-emails enviados a partir da máquina local possam ter como remetente user@dominio.valido. A configuração deste domínio faz-se no painel «Visible domain name for local users».

Isto seria suficiente para enviar e-mail para fora a partir de, por exemplo, uma rede interna de uma empresa, mas muitos ISPs configuram os seus servidores para negarem o relay de e-mail a utilizadores não autenticados, mesmo a partir das suas próprias redes, por questões de segurança.

Sempre que o Exim contactar o servidor smtp.telepac.pt para envio de e-mail, deverá fazer login com o utilizador utilizador e password password. Tal consegue-se acrescentando uma linha ao ficheiro /etc/exim4/passwd.client...

smtp.telepac.pt:utilizador:password

Se o servidor do ISP só aceita autenticação simples (sem cifra), é ainda preciso criar um ficheiro /etc/exim4/exim4.conf.localmacros contendo a seguinte linha:

AUTH_CLIENT_ALLOW_NOTLS_PASSWORDS=1

Para tornar a configuração efectiva, reiniciar o Exim:

$ invoke-rc.d exim4 restart

Para verificar que tudo está a funcionar correctamente, experimentar enviar um e-mail para um endereço externo...

$ echo "corpo da mensagem" | mail alguem@algures.com -s "teste de envio de email externo"

E, já agora, verificar também que a entrega de e-mail local continua a funcionar...

$ echo "corpo da mensagem" | mail utilizador -s "teste de envio de email local"
$ mail -u utilizador

Nota

Antes de tentar fazer login, o Exim faz um reverse lookup ao endereço IP do servidor que está a tentar contactar, e é o resultado desse reverse lookup que é pesquisado no ficheiro passwd.client.

Assim, no exemplo da Telepac acima, podemos confimar que o nome smtp.telepac.pt funciona com:

$ host smtp.telepac.pt
smtp.telepac.pt has address 212.55.154.44
$ host 212.55.154.44
44.154.55.212.in-addr.arpa domain name pointer smtp.telepac.pt.

Mas no exemplo a seguir já teriamos de usar outmail.example.com em vez de smtp.example.com...

$ host smtp.example.com
smtp.example.com has address 172.16.1.10
$ host 172.16.1.10
10.1.16.172.in-addr.arpa domain name pointer outmail.example.com.

Activação do módulo 'vmxnet' em Debian

Sun, 23 Sep 2007 21:07:00 GMT

Para evitar que o módulo pcnet32 capture a placa de rede antes do módulo vmxnet, é preciso que este último seja carregado o mais cedo possível, pelo initrd.

Em primeiro lugar, adicionar o seguinte ao ficheiro /etc/initramfs-tools/modules:

# Override "pcnet32"...
vmxnet

Em seguida, é necessário regenerar o initrd.img do kernel que está activo actualmente, correndo...

$ update-initramfs -u -k $(uname -r)

Para confirmar que tudo ficou a funcionar, reiniciar a máquina virtual. Depois, como root, fazer...

$ rmmod pcnet32
$ ping www.google.com

Se tudo estiver bem, a remoção do módulo pcnet32 não terá qualquer efeito e o ping funcionará correctamente.

Nomes fixos para dispositivos USB

Sun, 09 Sep 2007 21:44:00 GMT

Numa situação em que existem diversos dispositivos USB idênticos ligados a uma máquina, a ordem pela qual são associados a devices na directoria /dev depende da ordem pela qual são ligados. Nestes casos, desligar e voltar a ligar um dispositivo, bem como diferentes ordens de inicialização dos dispositivos após um reboot, pode resultar num device diferente.

Para evitar depender dos devices directamente, podemos usar o udev para criar um symlink com um determinado nome, que apontará sempre para o device associado ao dispositivo que queremos.

Por exemplo, se tivermos uma máquina fotográfica digital e uma pen USB, e uma vez que ambas são reconhecidas como discos, tanto podemos ter a máquina fotográfica como /dev/sda1 e a pen como /dev/sdb1, como podemos ter o contrário, dependendo de qual dos dispositivos ligamos primeiro.

Para ter a máquina fotográfica sempre acessível através de /dev/mycamera, começamos por a ligar e descobrir qual o device que lhe foi atribuído (usando o comando dmesg). Por exemplo, para uma máquina fotográfica da Olympus, poderíamos fazer...

$ dmesg | grep -A 2 -i olympus

...e ficaríamos a saber que a máquina ficou associada ao disco sdb a partir do seguinte resultado...

  Vendor: OLYMPUS   Model: X100,D540Z,C310Z  Rev: 1.00
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sdb: 512000 512-byte hdwr sectors (262 MB)

Podemos então obter mais informação acerca do dispositivo (/dev/sdb1) com o objectivo de descobrir algo que o identifique unicamente...

$ udevinfo -a -p $(udevinfo -q path -n /dev/sdb1)

O resultado deste comando é uma lista enorme de atributos, mas o que realmente interessa é encontrar o bloco onde aparece a marca e/ou o modelo do dispositivo. No caso da máquina fotográfica acima, seria...

  looking at parent device '/devices/pci0000:00/0000:00:07.2/usb1/1-1':
    KERNELS=="1-1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{serial}=="000365241020"
    ATTRS{product}=="X100,D540Z,C310Z"
    ATTRS{manufacturer}=="OLYMPUS"
    ATTRS{maxchild}=="0"
    ATTRS{version}==" 2.00"
    ATTRS{devnum}=="7"
    ATTRS{speed}=="12"
    ATTRS{bMaxPacketSize0}=="8"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceClass}=="00"
    ATTRS{bcdDevice}=="0100"
    ATTRS{idProduct}=="0105"
    ATTRS{idVendor}=="07b4"
    ATTRS{bMaxPower}=="  0mA"
    ATTRS{bmAttributes}=="c0"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bNumInterfaces}==" 1"

Os atributos manufacturer, product e serial identificam esta máquina fotográfica sem qualquer sombra de dúvida mas, na prática, o atributo serial acaba por ser suficiente, já que é pouco provável que alguém tenha o "azar" de ter dois dispositivos USB diferentes com o mesmo número de série...

Criamos então um ficheiro na directoria /dev/udev/rules.d com as nossas regras (apenas uma, por agora). O nome a dar a este ficheiro dependerá da distribuição, mas terá sempre um prefixo que determinará a sua posição na ordem pela qual o udev interpreta os ficheiros de regras existentes nesta directoria (ordem alfabética). Em Debian podemos chamar-lhe z25_mysymlinks.rules. O seu conteúdo será...

BUS=="usb", ATTRS{serial}=="000365241020", SYMLINK+="mycamera"

Para verificar que esta configuração funciona, desliga-se a máquina fotográfica e volta-se a ligar.

$ ls -l /dev/mycamera
lrwxrwxrwx 1 root root 4 2007-09-09 23:19 /dev/mycamera -> sdb1

Vemos então que funcionou. A partir de agora podemos ignorar o device atribuído à máquina fotográfica e usar /dev/mycamera sempre que for necessário.

Referências:

Writing udev rules

Configurar virtual-hosts no Apache

Sat, 08 Sep 2007 13:24:00 GMT

Em Debian é bastante fácil configurar virtual-hosts no Apache. Para começar, copia-se a configuração default para servir de base ao novo virtual-host...

$ cd /etc/apache2/sites-available/
$ cp default www-example-com

Partindo para a edição do ficheiro www-example-com, começa-se por remover a linha...

NameVirtualHost *:80

...uma vez que não podem existir duas directivas NameVirtualHost para a mesma combinação endereço:porta (*:80 significa que o virtual-host está acessível através de qualquer endereço IP configurado na máquina, na porta 80).

De seguida, adicionam-se as directivas que permitem que os acessos ao endereço http://www.example.com sejam respondidas pelo virtual-host www-example-com e não pelo virtual-host default. Logo após o início do bloco <VirtualHost *:80>...

ServerName www.example.com
ServerAlias www

Altera-se então a directiva DocumentRoot para apontar para a directoria correcta. Por exemplo...

DocumentRoot /var/www/sites/www-example-com

Para terminar, alteram-se as restantes directivas Directory de acordo com a DocumentRoot e activa-se o novo virtual-host...

$ a2ensite www-example-com
$ invoke-rc.d apache2 restart

Nota: Para os virtual-hosts que irão ser configurados com SSL importa ter em atenção que existem algumas limitações (ver: Activar HTTPs no Apache).

Configuração automática de proxy (PAC)

Sat, 08 Sep 2007 12:14:00 GMT

Os ficheiros .pac permitem configurar automaticamente as definições de proxy para qualquer um dos browsers modernos, evitando a necessidade de especificar manualmente os endereços do(s) servidor(es) e quais as máquinas que devem ser acedidas directamente. Adicionalmente, permitem ao administrador de rede alterar estas definições nos clientes sem pedir a intervenção dos utilizadores.

A sintaxe é um subconjunto relativamente simples da linguagem javascript, apenas com algumas funções para tomar decisões baseadas em endereços IP e URLs. O ficheiro seguinte demonstra uma possível configuração...

//
// proxy.pac - proxy auto-config for the internal LAN at "example.com"
//

function FindProxyForURL(url, host)
{
        // Clients in the "10.1.1.x" network don't need a proxy...
        if (isInNet(myIpAddress(), "10.1.1.0", "255.255.255.0")) return "DIRECT";

        // Addresses without a explicit domain are considered local...
        if (isPlainHostName(host)) return "DIRECT";

        // Local networks...
        if (isInNet(host, "127.0.0.0", "255.0.0.0")) return "DIRECT";
        if (isInNet(host, "10.0.0.0", "255.0.0.0")) return "DIRECT";
        if (isInNet(host, "172.16.0.0", "255.240.0.0")) return "DIRECT";
        if (isInNet(host, "192.168.0.0", "255.255.0.0")) return "DIRECT";

        // Our domain...
        if (shExpMatch(host, "*.example.com")) return "DIRECT";

        // FTP connections don't require a proxy...
        if (shExpMatch(url, "ftp://*")) return "DIRECT";

        // Everything else has to use our proxy server...
        return "PROXY proxy.example.com:8080";
}

Para terminar, basta colocar este ficheiro num servidor web que possa ser contactado directamente pelos clientes, e pedir aos utilizadores para colocarem o seu endereço (p.ex. http://internal.example.com/proxy.pac) no campo de "configuração automática de proxy" existente no painel de configuração do browser.

De notar que os browsers só consultam este ficheiro ao arrancar.

Referências:

Navigator Proxy Auto-Config File Format