1. Introdução

O Red Hat Network é uma ferramenta que permite a gerência de sistemas Red Hat por parte dos administradores de forma prática e eficiente, através da rede. Estes podem aplicar patches, atualizar, monitorar e corrigir inconsistências no sistema de pacotes nos seus sistemas através de uma interface web externa ao sistema local.

A principal vantagem proveniente dessa característica é a simplificação na gerência de grande número de sistemas. O uso do RHN evita a necessidade de acesso físico ou via rede a cada um dos sistemas, permitindo que vários servidores possam sofrer manutenção a partir de uma única página centralizada, acessível de qualquer ponto da rede ou de fora dela (de acordo com a configuração do servidor web do RHN Satellite).

Tanto o servidor RHN Satellite quanto o RHN Proxy oferecem capacidades avançadas de gerência de sistemas, bem a possibilidade de receber updates diretamente dos servidores centrais da Red Hat com reduzido uso de largura de banda. Isso ocorre porque ambos funcionam como servidores espelho locais, evitando que cada máquina da rede use banda externa para acesso aos servidores centrais da Red Hat.

Existem 3 (três) tipos de arquitetura do Red Hat Network: via acesso direto aos servidores centrais, usando o modelo de proxy e usando o modelo de satélite.

No modelo de acesso direto, cada sistema Red Hat cliente acessa diretamente os servidores centrais do RHN da Red Hat (https://rhn.redhat.com/) através da internet trocando pacotes e informações.

Ao utilizar um modelo de proxy, cada sistema Red Hat cliente conecta a um RHN Proxy local à rede. Este Proxy coleta todos os dados necessários e realiza algumas tarefas localmente. Então ele se comunica via internet com os servidores centrais do RHN da Red Hat, trocando informações e pacotes. Todas as informações do banco de dados do RHN são mantidas nos servidores centrais.

Por fim, no modelo de satélite todos os dados referentes à funcionalidade, como sistemas cliente, usuários e tipos de acesso, perfis de sistemas, relatórios de dados, etc., são mantidos na rede local do usuário. O servidor RHN Satellite se conecta aos servidores centrais apenas para baixar as atualizações disponibilizadas.

Este último modelo apresenta avanços importantes para o administrador da rede. A principal delas é a possibilidade de manter a privacidade da solução RHN da empresa, restringindo dados importantes do trânsito na internet pública, mantendo todas as informações da empresa dentro da própria rede local. Outras vantagens patentes são a otimização e o controle dos sistemas internos.

Neste artigo trataremos da migração do RHN Satellite para a última versão, o Red Hat Network Satellite 5.3, a partir da versão 4.2 rodando originalmente sobre um sistema Red Hat Enterprise Linux 3 Update 9. Escolhemos esta versão de origem por ela representar um cenário complexo de migração que engloba, no formato de passos intermediários, possíveis etapas encontradas em migrações feitas a partir de versões mais recentes do Red Hat Network Satellite, rodando sobre versões também mais recentes do Red Hat Enterprise Linux.

Assumiremos também que o leitor já possui um Certificado de Direito de uso do RHN Satellite, assinado digitalmente e enviado via e-mail por um funcionário autorizado da Red Hat, bem como possui uma conta de acesso ao servidor central do RHN da Red Hat (https://rhn.redhat.com/), criada pela própria Red Hat.

Voltar para parte superior

2. Cenários Básicos de Migração

Antes de planejar a atualização, faz-se necessário compreender exatamente o cenário atual e o cenário a que se quer chegar. A despeito da aparência óbvia desta recomentação ressaltamos que, para o caso de uma migração do RHN Satellite, temos vários cenários possíveis e algumas restrições que podem vir a se tornar eventuais bloqueios ao processo, levando o administrador a encontrar surpresas desagradáveis se alguns cuidados não forem tomados de antemão.

O RHN Satellite Server 5.3 roda apenas sobre as versões 4AS e 5 Server do Red Hat Enterprise Linux.

Os cenários possíveis de migração são os seguintes:

• Atualizar o RHN Satellite Server para a versão 5.3 (última) e:
• Atualizar o sistema operacional de Red Hat Enterprise Linux 2.1AS ou 3AS para Red Hat Enterprise Linux 4AS ou; de Red Hat Enterprise Linux 2.1AS, 3AS ou 4AS para Red Hat Enterprise Linux 5
• Não atualizar o sistema operacional (permanecer com Red Hat Enterprise Linux 4AS ou 5 Server)

Uma vez que estamos assumindo no nosso caso fictício que estamos rodando o RHN Satellite Server 4.2, sobre o Red Hat Enterprise Linux 3 Update 9 precisaremos atualizar tanto o RHN Satellite Server quando o sistema operacional.

Em relação à configuração do banco de dados, existem 2 (dois) tipos do RHN Satellite:

• RHN com o banco de dados autônomo, isolado em uma máquina separada;
• RHN com o banco de dados incorporado, instalado na mesma máquina do servidor RHN Satellite.

Trataremos nesse artigo de uma migração utilizando o RHN com o banco de dados incorporado por motivos expostos mais adiante nesta mesma seção.

A versão 5.1 do Satellite também introduziu uma nova configuração de suporte de arquiteturas. A partir de então, temos os seguintes possíveis cenários:

• Há suporte para atualização de um RHN com banco de dados incorporado sobre i386 para um RHN com banco de dados incorporado sobre i386.
• Há suporte para atualização de um RHN com banco de dados incorporado sobre i386 para um RHN com banco de dados incorporado sobre x86_64.
• Não há suporte para atualização de um RHN com banco de dados incorporado sobre i386 para um RHN com banco de dados incorporado sobre s390.
• Não há suporte para atualização de um RHN com banco de dados incorporado sobre i386 para um RHN com banco de dados incorporado sobre s390x.
• Há suporte para atualização de um RHN com banco de dados autônomo sobre i386 para um RHN com banco de dados autônomo sobre qualquer arquitetura (i386, x86_64, s390 e s390x)
• Não há suporte para atualização de um RHN com banco de dados autônomo sobre i386 para um RHN com banco de dados incorporado.
• Não há suporte para atualização de um RHN com banco de dados incorporado sobre i386 para um RHN com banco de dados autônomo.

No nosso caso fictício, estaremos migrando de um servidor i386 com RHN com banco de dados incorporado para um servidor x86_64 com servidor de banco de dados também incorporado. Tomamos este caminho após compreendermos que este cenário objetivo elimina a necessidade de custos com a licença do banco de dados, necessária em caso de opção pelo uso de um banco de dados autônomo. A vantagem no uso de um banco de dados autônomo seria a direta distribuição de carga entre os dois servidores (o do banco de dados, e o do servidor em si).

O RHN Satellite Server historicamente utilizou o banco de dados Oracle como uma de suas bases. A partir da versão 5.2 do Satellite passou-se a utilizar a o Oracle 10g. Uma vez que optamos pelo uso do banco de dados incorporado, nenhuma ação extra específica será necessária. É importante ter em mente que não é possível migrar diretamente de versões anteriores ao Oracle 9.2.0.4. Se este for o caso, é necessário atualizar o Satellite de origem para alguma versão entre a 3.6 e a 5.1 antes de atualizar para o 5.3. Não é o nosso caso (fictício) também.

Voltar para parte superior

3. O Planejamento

Um bom planejamento requer um conhecimento prévio das etapas componentes do processo de migração. Eis uma lista das atividades, em alto nível de abstração:

• Após avaliar a tecnologia e o modelo a ser adotado, contacte um representante de vendas da Redhat e para comprar o serviço;
• Você receberá por e-mail um RHN Entitlement Certificate;
• Será criada também uma conta para sua empresa no servidor central do RHN;
• Acesse o servidor central (rhn.redhat.com) e baixe a ISO do sistema operacional a ser utilizado na aba Downloads da página Channel Details. Para o nosso exemplo, utilizaremos o Red Hat Enterprise Linux 5. Baixe também a ISO do RHN Satellite 5.3.0;
• Você pode baixar também as ISOs com os pacotes dos canais a serem servidos pelo RHN. Porém, isso é opcional. As outras maneiras de obter esses pacotes são: (i) transferindo do servidor de origem a ser migrado para o novo servidor ou, após importar o banco de dados no novo servidor, sincronizar com o RHN central da Red Hat. Esta última opção provavelmente levará muito mais tempo do que qualquer uma das outras opções;
• Em caso de uso de banco de dados autônomos, nessa fase se faz necessário o preparo do mesmo. Não cobriremos esta etapa neste artigo por não se aplicar ao nosso caso fictício;
• Instale o Red Hat Enterprise Linux e o RHN Satellite 5.3.0 no novo servidor;
• Prepare os dados a serem transferidos do servidor antigo para o novo. Descreveremos esses dados de forma mais precisa posteriormente. Copie esses dados para o novo servidor;
• Importe o banco de dados;
• Importe o banco de dados e atualize-o para os formatos do Oracle 10g;
• Atualize os diretórios de pacote recém transferidos;
• Sincronize com os servidores centrais do RHN;
• Aplique as personalizações apropriadas ao seu ambiente, caso existam;
• Faça testes. O ambiente é, de certo modo, complexo, com diversas variáveis, de Java a Oracle, passando pelo conjunto de certificados SSL, além da migração propriamente dita. Isso eleva o risco de surpresas.

Tenha em mente que, ao longo do processos, serão executados alguns scripts cujos objetivos são de reformatação do banco de dados e dos diretórios de pacotes. Dependendo da quantidade de usuários, pacotes, máquinas clientes e outros dados relacionados no banco de dados prévio o tempo de execução desses scripts é aumentado.

Existem várias abordagens a serem adotadas com a finalidade de diminuir o downtime do servidor em relação às máquinas clientes quando da migração. Escolher a melhor abordagem é uma decisão que cabe ao administrador do servidor e sua equipe, e vai variar de acordo com a experiência dos administradores com migrações do RHN, conhecimento dos internals e dos componentes do RHN, criticidade do servidor RHN Satellite dentro da rede da empresa, quantidade de sistemas clientes afetados e a criticidade desses, no que tange ao nível exigido de atualização e quantidade de usuários (humanos) afetados.

Outro item que merece cuidado nesse tipo de migração diz respeito ao novo hardware a ser utilizado. Faça cálculos prévios relacionando o hardware anterior (disco e partições, memória) e sua média de utilização, o número de clientes médios que conectam, a quantidade de canais e as atualizações dos componentes do RHN, principalmente do banco de dados.

Estas são as recomendações da Red Hat com relação ao hardware:

Em alguns ambientes, o RHN Satellite é utilizado como fonte de entrada de pacotes Red Hat na rede, podendo haver configurações complexas de distribuição dos mesmos dentro da rede. Para esses casos recomendamos que seja especificada na fase de planejamento as relações entre o RHN Satellite a ser migrado e os demais servidores secundários, de modo a identificar que tipo de interferência essa migração pode causar nos demais elementos da rede.

Voltar para parte superior

4. A Migração

Com um bom planejamento feito, podemos passar à fase de execução. Entretanto, mesmo um bom planejamento não oferece totais garantias de que tudo correrá bem. Com isso em mente, reserve uma janela de tempo razoável para as atividades de migração.

Se a opção for, por exemplo, por simular toda a migração antes de realizá-la oficialmente, a janela final poderá menor (ainda assim estamos falando de alguns poucos dias). Em caso de migração direta, é aconselhável reservar ao menos uma semana. Aconselhamos fortemente que seja adotado um modelo mais parecido com a primeira opção, com simulações do processo todo e testes anteriores à migração final. Além de aumentar a experiência da equipe com a ferramenta, reduz drasticamente a quantidade de surpresas no momento da migração final. Neste artigo exemplificaremos a migração adotando este modelo.

Não é viável colocar números precisos de estimativa aqui porque eles variam muito de acordo com o tamanho do banco de dados e, principalmente com a quantidade de canais/pacotes que são atualizados através deste servidor. Esta é mais uma razão pela qual aconselhamos optar por um período de simulações e testes.

Na seção seguinte descreveremos com maiores detalhes o processo pré migração final. Posteriormente, referenciaremos os passos a serem dados durante a janela reservada para a migração final, que é basicamente uma repetição de tudo que já foi feito na fase anterior, apenas com alguns cuidados específicos.

Voltar para parte superior

5. Simulações e Testes

O primeiro passo é obter o Certificado de Direito de uso do RHN Satellite com um representante da Red Hat. Esta mesma pessoa irá requerer uma conta de acesso ao servidor central do RHN. Baixe então, do RHN da Red Hat, as ISOs do Red Hat Enterprise Linux 5 Update 3 e do RHN Satellite 5.3.

Instale o Red Hat Enterprise Linux 5 Update 3, de acordo com as características já mencionadas anteriormente nesse artigo.

Para o nosso caso modelo, este é o conjunto de partições de discos rígidos no servidor a ser migrado:

Todas as partições estavam montadas sobre um mesmo disco rígido, local à máquina servidora.

Considerando ainda que:

• O diretório /var/satellite estava com ocupação de 60% no momento da migração;
• O diretório /rhnsat estava com ocupação de 44% no momento da migração;
• Faremos mirror de Red Hat Enterprise Linux 3, 4 e 5;

Optamos pela seguinte configuração para o novo servidor:

Utilizaremos um servidor de arquitetura x86_64, com 8G de memória principal. Não utilizamos nenhum RHN Proxy na rede e utilizaremos o RHN Satellite com banco de dados incorporado. É importante que o horário do sistema seja assegurado por um servidor externo NTP confiável. Não aprofundaremos em mais detalhes do hardware nem cobriremos os passos de instalação do Red Hat Enterprise Linux 5 Update 3 nesse artigo.

Após instalado o servidor, e configurado como cliente para receber atualizações a partir do servidor central RHN da Red Hat, deve-se instalar o pacote rhn-upgrade. Nele estão contidas as documentações oficiais da atualização do RHN Satellite. Opcionalmente, pode-se logar no RHN da Red Hat e baixar o pacote manualmente. A documentação fica armazenada no diretório /etc/sysconfig/rhn/satellite-upgrade. Merece especial atenção nesse momento o arquivo README.

Se o sistema operacional for instalado com suporte a SELinux, é o momento de desabilitá-lo ou mudar para os modos permissive ou enforcing.

5.1 Instalando o RHN Satellite

Monte a ISO do RHN Satellite (utilizando a opção -o loop):

mount -o loop /path/para/iso_do_RHN /media/cdrom

Assegure que o Certificado de Direito de Uso do RHN Satellite está em algum lugar no sistema de arquivos.

A partir do diretório /media/cdrom, rode o script de instalação:

./install.pl

O script irá checar alguns pré-requisitos antes de iniciar a instalação. Então será solicitado um endereço de e-mail para onde serão enviadas notificações do Satellite.

Então, o Satellite será registrado no servidor centrar como uma conta do tipo RHN Hosted e os pacotes do RHN serão instalados e atualizados. Posteriormente, as chaves RHN GPG serão instaladas em /root/.gnupg/, o banco de dados será criado e, inicialmente, populado e o ambiente e os usuários relacionados ao RHN serão configurados.

A próxima informação requerida será o path para o Certificado de Direito de Uso. Este será seguido pela entrada de dados a serem utilizados na geração do certificado CA Cert, a saber: uma senha para o certificado, o nome da organização, o e-mail, a cidade e o país. Tendo gerado o certificado CA Cert, o instalador fará algumas configurações finais e reiniciará o serviço.

A interface web do RHN Satellite poderá então ser visitada acessando-se a url atrelada ao IP do servidor (ou seja, em localhost, se acessado do mesmo sistema). Após instalado e conferido, pare os serviços do RHN:

/usr/sbin/rhn-satellite stop

5.2 Transferência de dados

Precisamos agora transferir alguns dados do servidor antigo para o novo, a saber:

• O banco de dados (um backup);
• O diretório /var/satellite;
• Alguns arquivos de configuração.

Com a finalidade de importarmos um backup do servidor antigo, podemos tanto utilizar alguns dos backups feitos regularmente naquele servidor quanto produzirmos um novo, recente. Para produzir um backup recente, a partir do shell do servidor antigo, pare os serviços e gere o novo backup como usuário 'oracle':

 
/sbin/service rhn-satellite stop 

su -c"db-control backup /path/para/backup" – oracle

su -c"db-control verify /path/para/backup" – oracle

su -c"db-control examine /path/para/backup" – oracle

/sbin/service rhn-satellite start

Empacote então o diretório /path/para/backup, envie para o novo servidor e desempacote novamente.

Para a transferência do diretório /var/satellite, recomendamos fortemente o uso do comando rsync, dado o volume de dados e sua constante mutabilidade. Esse processo pode demorar muito tempo, de acordo com a quantidade de pacotes armazenados e a velocidade da rede.

Além do banco de dados e do diretório /var/satellite, devemos transferir também os seguintes conteúdos:

• /var/www/html/pub/*
• /root/ssl-build/*
• /etc/tnsnames.ora

Evite copiar esses conteúdos diretamente para o path oficial. Prefira um diretório temporário (/home/usuario, /root, ou algo semelhante). Eles serão utilizados em tempo oportuno.

5.3 Importando o banco de dados

O primeiro passo é limpar o banco de dados criado durante a criação. O comando é:

/usr/share/spacewalk/setup/oracle/remove-db.sh

Caso haja alguma dificuldade com o script oficial, a maneira direta (não elegante, mas funcional) de fazer a mesma tarefa seria:

rm -rf /rhnsat/data/rhnsat/*

Agora, restaurando no novo servidor o banco de dados (backup do servidor antigo), como usuário 'oracle':

 
            
            /usr/sbin/rhn-satellite stop 

                su - oracle

                db-control restore /path/para/backup/

            exit
            
            

Para atualizar os arquivos do banco de dados para o formato do Oracle 10g Release 2 devemos rodar o script upgrade-db.sh da seguinte maneira:

/sbin/runuser oracle -c \ 

                '/bin/bash /usr/share/spacewalk/setup/oracle/upgrade-db.sh 2>&1' | \

                tee /var/log/rhn/upgrade_db.log
            

É necessário ainda rodar uma correção de sql como 'oracle', caso esteja instalando o RHN Satellite com banco de dados incorporado sobre um servidor 64-bit (nosso caso), e então reiniciar o serviço do banco de dados:

su - oracle

                cd /etc/sysconfig/rhn/satellite-upgrade/

                export ORACLE_SID=rhnsat

                sqlplus '/ as sysdba' @satellite-oracle-64bit-fix.sql

                exit
                /sbin/service oracle start
            

Nesse ponto, se torna interessante verificar o espaço alocado para as tabelas do banco, e, se necessário, aumentar o espaço. Para checar, como 'oracle', rode:

su - oracle

db-control report 

exit 

Se houver pouco espaço (espaço livre menor do que 10%), use a opção extend:

db-control extend nome_da_tabela 

5.4 Conversão do schema de pacotes

O RHN Satellite 5.3 usa um schema diferente para o armazenamento dos pacotes a serem disponibilizados para os sistemas cliente no diretório /var/satellite, introduzindo um novo sistema de diretórios com nomes contendo chaves, facilitando a busca pelos pacotes, por parte do próprio RHN. Veja a localização de uma versão do pacote zebra no servidor antigo, :

/var/satellite/redhat/NULL/zebra/0.92a-5.7.3/i386/zebra-0.92a-5.7.3.i386.rpm

Agora no novo servidor:

/var/satellite/redhat/NULL/09d/zebra/0.92a-5.7.3/i386/09d89f6a6d9ccb46bba080c6d7bc8b93/zebra-0.92a-5.7.3.i386.rpm

Recomendamos também dar um ls dentro do diretório /var/satellite/redhat/NULL/ nos dois servidores para ter uma melhor dimensão das diferenças.

Esse path dos pacotes é armazenado dentro do banco de dados do RHN para posterior capturação, quando solicitado por um sistema cliente. Assim, um dos passos que mais requerem tempo durante a migração é a atualização do schema antigo para o novo. Os scripts satellite-5.3.0-schema-upgrade e update-5.3.0-packages alteram tanto o banco de dados quanto o próprio path físico, dos arquivos, manipulando os diretórios afim de utilizar a nova configuração.

Durante esse processo, a tabela /temp_tbs/ é utilizada. Precisamos, portanto, prepará-la para receber os dados transitórios. Para estimar quanto de espaço será utilizado, usamos o seguinte comando:

cd /etc/sysconfig/rhn/satellite-upgrade

sqlplus -S rhnsat/rhnsat@rhnsat @satellite-temp_tbs-estimate.sql

Para checar a quantidade alocada atualmente, fazemos:

 su - oracle 

                cd /etc/sysconfig/rhn/satellite-upgrade

                ORACLE_SID=rhnsat sqlplus -S '/ as sysdba' @satellite-temp_tbs.sql 

        exit 

Se o espaço alocado for menor do que o estimado, podemos aumentá-lo com:

 su – oracle

                db-control extend TEMP_TBS

                exit 

Antes de finalmente rodar o script conversor do schema, devemos nos certificar de que o banco de dados (e apenas ele, dentre os serviços do RHN) está rodando:

 /usr/sbin/rhn-satellite stop
 /sbin/service oracle start 

E, por fim, rodamos o satellite-5.3.0-schema-upgrade, que deve tomar um longo tempo para finalizar. O comando é silencioso. Aguarde até que ele finalize sua atuação sem se precipitar, interrompendo-o.

 /usr/bin/satellite-5.3.0-schema-upgrade 

Agora verifique se o ambiente está pronto antes de prosseguir. O output dos dois comandos abaixo devem ser iguais:

 /usr/bin/rhn-schema-version
 rpm -q --qf '%{version}-%{release}\n' satellite-schema

Por fim, rodamos o script update-5.3.0-packages para finalizar o processo. Esse comando também leva algum tempo para terminar:

 /usr/bin/update-5.3.0-packages --db=rhnsat/rhnsat@rhnsat --debug 

5.5 Configurações

O primeiro passo é ativar o Certificado de Direito de Uso do RHN Satellite enviado pelo representante da Red Hat:

 rhn-satellite-activate --rhn-cert /path/para/ltc-admin.cert \
                --ignore-version-mismatch 

Esse passo precisará ser feito novamente no momento da migração final, a fim de habilitar o Certificado de Direito de Uso oficial utilizado pela empresa.

Para construir a estrutura da cache do RHN, usamos o rhn-search:

 /sbin/service rhn-search cleanindex 

Rodando o script rhn-load-config.pl algumas configurações padrão do RHN são aplicadas ao sistema:

 /usr/share/spacewalk/setup/upgrade/rhn-load-config.pl 

Esse script costuma apresentar alguns erros de configuração do osa que podem ser ignorados, uma vez que a configuração do mesmo será feita posteriormente.

A essa altura, reiniciamos o RHN:

 /usr/sbin/rhn-satellite restart 

Atualize o monitor do Satellite (mesmo que ele não esteja sendo usado no servidor antigo):

 /usr/share/spacewalk/setup/upgrade/rhn-update-monitoring.pl 

Copie as chaves ssh do usuário nocpulse do servidor antigo para o diretório /home/nocpulse/.ssh/ do servidor novo. Após a transferência, associe os arquivos ao owner:

 chown nocpulse.nocpulse /home/nocpulse/.ssh/nocpulse-identity* 

Para habilitar a função push, é preciso antes parar os daemons:

 /sbin/service jabberd stop

                /sbin/service osa-dispatcher stop 

E, então, rodar o script perl responsável:

 /usr/share/spacewalk/setup/upgrade/rhn-enable-push.pl 

Caso o script dê a deixa, use a opção –force. >

É necessário também verificar o arquivo principal de configuração /etc/rhn/rhn.conf. Deve-se comparar as opções do mesmo arquivo no servidor antigo, observando principalmente as linhas que trazem configurações específicas ao ambiente. Observe também a presença das linhas:

 web.satellite_install = 0

                default_db = user/password@sid 

E reiniciamos novamente o RHN Satellite:

 /usr/sbin/rhn-satellite restart 

5.6 Atualização dos canais

Dentre as tarefas cotidianas do RHN Satellite, uma essencial é a atualização dos canais com o servidor central do RHN. Essa tarefa é realizada com o comando:

 satellite-sync --email fulano@meudominio.com 

5.7 Testes

A essa altura o servidor estará apto a ser testado. Recomendamos que sejam realizados, no mínimo:

• Testes de interface web
• Login na interface web com vários usuários
• Revisão de associações entre usuários e sistemas cliente
• Aplicação de patches a sistemas clientes via interface web
• Testes a partir de sistemas clientes
• Registro de sistemas cliente
• Manipulações utilizando o comando yum

É interessante contar com a ajuda de usuários do dia a dia para testar o servidor.

Voltar para parte superior

6. A Migração Final

O processo da migração final é muitíssimo similar à fase de simulação. A esta altura a equipe que vai trabalhar na migração deve estar muito mais familiarizada com o ambiente e preparada para eventuais infelicidades que possam ocorrer.

As diferenças dentre a migração final e a fase simulação são descritas brevemente nesta seção.

6.1 Troca de IP

A intenção de trocar o IP do novo servidor para utilizar o antigo tem como objetivo minimar ao extremo o impacto que chega até os usuários. Os passos são simples.

Primeiro, deve-se realizar a troca dos IPs. O administrador da rede deve estar a par ou, até mesmo, trabalhar na mudança.

Após a troca, reiniciamos o servidor, verificamos se as mudanças estão funcionando corretamente e, então, avisamos o RHN Satellite da troca com o comando spacewalk-hostname-rename seguido do novo IP da máquina:

 spacewalk-hostname-rename 0.0.0.0 

6.2 Configurações pós-troca de IP

Com os IPs trocados, é preciso voltar a utilização dos certificados SSL. Removemos os pacotes com nome semelhante a rhn-org-httpd-ssl*.noarch.rpm.

Para pesquisar os pacotes instalados, usamos o comando:

rpm -qa | grep rhn-org-

Para remover:

rpm -e nome-do-pacote

Instalamos os pacotes utilizados no servidor antigo (consulte os pacotes instalados no servidor antigo). Eles foram copiados previamente para o novo servidor. No servidor antigo, estavam localizados nos path /root/ssl-build/ e /var/www/html/pub/. Salientamos que não se deve instalar todos os pacotes encontrados, mas apenas os que já estavam instalados no servidor antigo.

Caso use certificados SSL reconhecidos no Apache, lembre-se de copiá-lo do servidor antigo também.

Antes de liberar o servidor para os usuários, é recomendável realizar mais testes, rápidos, a fim de certificar que o RHN Satellite 5.3 continua funcionando bem após a troca de IP.

Voltar para parte superior

7. Conclusão

Longe de ser um artigo definitivo, este artigo busca ser um guia genérico com bom nível de completude.

Uma migração do RHN Satellite pode ser bastante simples se feito entre versões mais próximas, como do 5.2 para o 5.3 por exemplo. Mas pode apresentar desafios consideráveis caso haja um grande número de sistemas cliente, usuários, canais espelhados, além de altos níveis de disponibilidade pré-acordados.

Existem portanto diversas maneiras para se realizar essa tarefa. Escolhemos um cenário de complexidade média-alta.

Não tratamos, por razões óbvias, de personalizações no RHN Satellite, pois estas dependem diretamente do ambiente interno da rede e das características da corporação. Estas podem colaborar sensivelmente para o aumento da complexidade da tarefa.

Voltar para parte superior

8. Referências

[1] Installation Guide – Red Hat Network Satellite. Edition 5.3.0. Fonte: http://www.redhat.com/docs/en-US/Red_Hat_Network_Satellite/5.3/Installation_Guide/html/index.html

[2] Satellite Upgrade Documentation Package. Pacote RPM: rhn-upgrade-5.3.0.24-1.el5sat

Sobre o autor

Tiago Santos é engenheiro de software do Linux Technology Center da IBM. Bacharel em Ciência da Computação com extensa experiência tanto profissional quanto acadêmica, atualmente atua na administração de servidores que servem 7.000+ usuários. Casado com a Jéssica Santos, também é músico, poeta, e investidor.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• 1. Introdução
• 2. Cenários Básicos de Migração
• 3. O Planejamento
• 4. A Migração
• 5. Simulações e Testes
• 6. A Migração Final
• 7. Conclusão
• 8. Referências
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais