Em um post anterior, falei sobre haverem restrições do uso do rsync no Ubuntu.
Resolvi fazer um post espefíco sobre o assunto, para ajudar quem como eu passou por problemas assim.
As restrições resumem-se basicamente a três fatores principalmente:
1) Filesystems temporários
2) Uso de UUIDs ao invés de devices
3) Interfaces persistentes (vínculo entre mac address da placa e nome da interface)
Normalmente, no caso de uma sincronia de servidores temos 2 maneiras distintas de fazê-lo:
A) Podemos sincronizar o servidor em cima de um HD vazio, mas já particionado.
B) Podemos sincronizar o servidor em cima de um base system previamente instalado.
Maneira A
A maneira A é a mais “complicada” delas pois é preciso ter cuidado com os 3 fatores listados acima. Vamos por partes:
Fator 1:
O fator 1 é o que necessita de maior cuidado pois está ligado a forma de boot do Ubuntu (o fator 2 também tem relação com o boot, mas conseguimos bootar o servidor usando um init=/bin/bash, por exemplo). Para que o Ubuntu possa bootar é necessário que exista no filesystem root ( /) um diretório /var/run e um diretório /var/lock.
Essas pastas são necessárias antes que o /var seja montado (se ele for uma partição separada). Caso esses diretórios não existam o Ubuntu não irá bootar.
Solução: Ao criar a partição / (que normalmente é uma partição à parte, pois o /var normalmente é outra partição), crie os diretórios /var/run e /var/lock para garantir que seu Ubuntu suba.
ATENÇÃO: nunca efetuei diretamente a operação dessa maneira. Estou relatando o que é necessário para o sistema bootar, baseado em pesquisas e comentários encontrados pela rede (normalmente uso a segunda forma de sincronia para garantir o pleno funcionamento – com o base system pré instalado. Demora mais, mas é mais seguro 🙂 ). Se você optar sincronizar direto no HD vazio criando os diretórios, depois relate sua experiência, por favor.
Fator 2: O Ubuntu, ao invés de trabalhar com devices no /etc/fstab e no /boot/grub/menu.lst, trabalha já há algumas versões com UUIDs (não vou entrar no mérito de vantagens e desvantagens, muito menos dispor sobre o porque da mudança). Se esse formato não for alterado para o formato “antigo” (arquivos de dispositivos – /dev/sda1 ou /dev/hda1, por exemplo), ao tentar bootar o novo servidor, o sistema não irá subir pois não encontrará as partições.
Solução: Após sincronizar todo o servidor, antes de rebootar o mesmo, retorne seus arquivos /etc/fstab e /boot/grub/menu.lst para o formato convencional de device (no fstab, o nome do device está inclusive comentando na linha anterior). Sincronizando dessa forma, seu novo servidor não irá ter problemas no boot. Dica: no root do menu.lst coloque o device onde está o /.
Fator 3: O Ubuntu (7.10) guarda as interfaces de rede e seus respectivos nomes (nada mais do que um vínculo do mac address da placa de rede com o nome “ethX”) no arquivo /etc/udev/rules.d/70-persistent-net.rules (O Debian Etch usa o arquivo /etc/udev/rules.d/z25_persistent-net.rules de forma similar). Ao trazer esse arquivo do servidor antigo o servidor novo pode por exemplo então passar a reconhecer a sua eth0 como eth1 (pois a eth0 já vai estar associada ao mac da placa do servidor antigo).
Solução: Apague o arquivo /etc/udev/rules.d/70-persistent-net.rules. Com isso ele será recriado corretamente no próximo boot. Ou ainda, não sincronize o mesmo, colocando-o na lista de exclusão do rsyncd.conf.
ATENÇÃO: do Ubuntu 6.06 ao Ubuntu 7.04 e no Debian Sarge o nome do arquivo é /etc/iftab.
Maneira B
A maneira B é mais simples, pois será necessário lidar somente com os fatores 2 e 3 já explicados acima.
Acredito que com essas dicas, os problemas de usar o rsync com o Ubuntu sejam todos solucionados.
Pelo menos até o lançamento da versão 8.04 😉
