3 Preparando o upgrade #
Antes de iniciar o procedimento de upgrade, verifique se o sistema está preparado apropriadamente. Entre outras coisas, a preparação envolve o backup dos dados e a verificação das notas de versão. O capítulo a seguir orientará você durante essas etapas.
3.1 Verificar se o sistema está atualizado #
O upgrade do sistema apenas é suportado do nível de patch mais recente. Verifique se as atualizações mais recentes do sistema estão instaladas por meio da execução do zypper
patch
ou da inicialização do módulo do YaST.
3.2 Ler os detalhes da versão #
Encontre uma lista de todas as mudanças, os novos recursos e os problemas conhecidos nas release notes. Você também pode encontrar as notas de versão na mídia de instalação no diretório docu
.
Geralmente, os detalhes da versão contêm apenas as mudanças entre duas versões subsequentes. Se você está ignorando um ou mais Service Packs, consulte também os detalhes da versão dos Service Packs ignorados.
Consulte os detalhes da versão para verificar se as seguintes afirmativas são verdadeiras:
Seu hardware precisa de considerações especiais
Qualquer pacote de software usado foi significativamente modificado
Sua instalação requer cuidados especiais
3.3 Fazer um backup #
Antes de fazer upgrade, faça backup dos dados copiando os arquivos de configuração existentes para um meio separado (como dispositivo de fita, disco rígido removível etc). Isso se aplica basicamente aos arquivos armazenados em /etc
e a alguns diretórios e arquivos em /var
e /opt
. Você também pode gravar os dados do usuário em /home
(os diretórios HOME
) em um meio de backup.
Faça backup de todos os dados como root
. Apenas o usuário root
tem permissões suficientes para todos os arquivos locais.
Se você selecionou /etc/sysconfig
. Entretanto, esse não é um backup completo, já que todos os outros diretórios importantes mencionados anteriormente não estão incluídos. Encontre o backup no diretório /var/adm/backup
.
3.4 Verificar o espaço em disco disponível #
O software tende a crescer a cada versão. Portanto, verifique o espaço da partição disponível antes de atualizar. Se você suspeitar que esteja ficando sem espaço em disco, faça backup dos dados antes de aumentar o espaço disponível redimensionando as partições, por exemplo. Não há uma regra geral sobre a quantidade de espaço que cada partição deve ter. As exigências de espaço dependem do seu perfil de particionamento específico e do software selecionado.
Durante o procedimento de atualização, o YaST verificará a quantidade disponível de espaço livre em disco e mostrará um aviso para o usuário se houver a possibilidade de a instalação exceder essa quantidade. Nesse caso, a atualização pode tornar o sistema inutilizável! Somente se você souber exatamente o que está fazendo (testando com antecedência), poderá ignorar o aviso e continuar a atualização.
3.4.1 Verificando o espaço em disco em sistemas de arquivos não Btrfs #
Use o comando df
para listar o espaço em disco disponível. Por exemplo, em Exemplo 3.1, “Listagem com df -h
”, a partição raiz é /dev/sda3
(montada como /
).
df -h
#Filesystem Size Used Avail Use% Mounted on /dev/sda3 74G 22G 53G 29% / tmpfs 506M 0 506M 0% /dev/shm /dev/sda5 116G 5.8G 111G 5% /home /dev/sda1 44G 4G 40G 9% /data
3.4.2 Verificando o espaço em disco em sistemas de arquivos raiz Btrfs #
Em um sistema de arquivos Btrfs, a saída do df
pode gerar confusão, porque além do espaço alocado pelos dados brutos, esse sistema de arquivos também aloca e usa espaço para os metadados.
Consequentemente, um sistema de arquivos Btrfs pode informar que está sem espaço mesmo que pareça ter bastante espaço ainda disponível. Nesse caso, todo o espaço alocado para os metadados está em uso. Para obter detalhes sobre como verificar o espaço usado e disponível em um sistema de arquivos Btrfs, consulte o Section 1.2.2.3, “Checking for free space”. Para obter mais informações, consulte man 8
btrfs-filesystem
e https://btrfs.wiki.kernel.org/index.php/FAQ.
Ao usar o Btrfs como sistema de arquivos raiz em sua máquina, verifique se há espaço livre suficiente. Verifique o espaço disponível em todas as partições montadas. Na pior das hipóteses, um upgrade precisará do mesmo espaço em disco que o sistema de arquivos raiz atual (sem /.snapshot
) para um novo instantâneo.
As recomendações a seguir foram comprovadas:
Para todos os sistemas de arquivos, incluindo o Btrfs, você precisa de espaço livre suficiente em disco para fazer download e instalar RPMs grandes. O espaço dos RPMs antigos serão liberados apenas depois da instalação dos novos RPMs.
Para Btrfs com instantâneos, você precisa, no mínimo, do mesmo espaço livre que a instalação atual usa. Recomendamos ter o dobro de espaço livre da instalação atual.
Se você não tiver espaço livre suficiente, poderá tentar apagar instantâneos antigos com o comando
snapper
:#
snapper
list#
snapper
delete NUMBERPorém, isso talvez não ajude em todos os casos. Antes da migração, a maioria dos instantâneos ocupa apenas um pouco de espaço.
3.5 Listando os pacotes e repositórios instalados #
É possível gravar uma lista dos pacotes instalados, por exemplo, ao fazer uma nova instalação de uma versão principal do SLE mais recente ou ao reverter para a versão antiga.
Saiba que nem todos os pacotes instalados ou repositórios usados estão disponíveis nas versões mais novas do SUSE Linux Enterprise. Alguns podem ter sido renomeados, e outros substituídos. É possível também que alguns pacotes ainda estejam disponíveis para fins legados, enquanto outro pacote é usado por padrão. Portanto, talvez seja necessária a edição manual nos arquivos. Isso pode ser feito com qualquer editor de texto.
Crie um arquivo denominado
repositories.bak.repo
com uma lista de todos os repositórios usados:#
zypper
lr -e repositories.bakCrie também um arquivo denominado
installed-software.bak
com uma lista de todos os pacotes instalados:#
rpm
-qa --queryformat '%{NAME}\n' > installed-software.bakFaça backup dos dois arquivos. Os repositórios e os pacotes instalados podem ser restaurados com os comandos a seguir:
#
zypper
ar repositories.bak.repo#
zypper
install $(cat installed-software.bak)Nota: O número de pacotes aumenta com a atualização para uma nova versão principalUm sistema do qual foi feito o upgrade para uma nova versão principal (SLE X+1) pode conter mais pacotes do que o sistema inicial (SLE X). Ele também terá mais pacotes do que uma nova instalação do SLE X+1 com a seleção do mesmo padrão. Os motivos para isso são:
Os pacotes foram divididos para permitir uma seleção de pacote mais detalhada. Por exemplo, 37 pacotes texlive no SLE 11 foram divididos em mais de 3.000 pacotes no SLE 15.
Quando um pacote é dividido, todos os novos pacotes são instalados no caso de upgrade para manter a mesma funcionalidade da versão anterior. No entanto, o novo padrão para uma instalação recente do SLE X+1 pode ser de não instalar todos os pacotes.
Os pacotes legados do SLE X podem ser mantidos por questões de compatibilidade.
As dependências de pacotes e o escopo dos padrões podem ter mudado.
3.6 Desabilitar a extensão LTSS #
Se você fizer upgrade de um sistema SUSE Linux Enterprise Server com o Long Term Service Pack Support (LTSS) para uma versão que ainda esteja sob suporte geral, haverá falha no upgrade com o erro No migration available
(Nenhuma migração disponível). Isso acontece porque o comando zypper migration
tenta migrar todos os repositórios, mas ainda não há um repositório LTSS para a nova versão.
Para corrigir esse problema, desabilite a extensão LTSS antes do upgrade.
Verifique se a extensão LTSS está habilitada:
>
sudo
SUSEConnect --list-extensions | grep LTSS SUSE Linux Enterprise Server LTSS 12 SP4 x86_64 (Installed) Deactivate with: SUSEConnect -d -p SLES-LTSS/12.4/x86_64Desabilite a extensão LTSS com o comando da saída
SUSEConnect
acima:>
sudo
SUSEConnect -d -p SLES-LTSS/12.4/x86_64 Deregistered SUSE Linux Enterprise Server LTSS 12 SP4 x86_64 To server: https://scc.suse.com/Verifique se o repositório LTSS não está mais presente com
zypper lr
.
3.7 Migrar o banco de dados PostgreSQL #
O SUSE Linux Enterprise Server 15 SP5 é fornecido com as versões 13 e 14 do banco de dados PostgreSQL. A versão 14 é a padrão, mas a versão 13 ainda é fornecida por meio do módulo Legacy
para upgrades de versões anteriores do SUSE Linux Enterprise Server.
Por causa do trabalho de migração do banco de dados necessário, não existe um processo de upgrade automático. Dessa forma, a mudança de uma versão para outra precisa ser feita manualmente.
O processo de migração é realizado pelo comando pg_upgrade
, que é um método alternativo do clássico dump e recarregamento. Em comparação com o método “dump e recarregamento”, o pg_upgrade
reduz o tempo da migração.
Os arquivos de programas para cada versão do PostgreSQL são armazenados em diretórios diferentes dependentes da versão. Por exemplo, no /usr/lib/postgresql96/
para a versão 9.6, no /usr/lib/postgresql10/
para a versão 10 e no /usr/lib/postgres13/
para a versão 13. Observe que a política de controle de versão do PostgreSQL foi modificada entre as versões principais 9.6 e 10. Para obter os detalhes, consulte https://www.postgresql.org/support/versioning/.
Ao fazer upgrade do SLE 11, o postgresql94
será desinstalado e não poderá ser usado para migração do banco de dados para uma versão superior do PostgreSQL. Portanto, migre o banco de dados PostgreSQL antes de fazer upgrade do sistema neste caso.
O procedimento a seguir descreve a migração do banco de dados da versão 12 para 13. Ao usar uma versão diferente como inicial ou destino, substitua os números das versões adequadamente.
Para executar a migração do banco de dados, faça o seguinte:
Verifique se as seguintes pré-condições foram atendidas:
Caso ainda não tenha sido feito, faça upgrade de qualquer pacote da versão antiga do PostgreSQL para a versão mais recente por meio de uma atualização de manutenção.
Crie um backup do seu banco de dados existente.
Instale os pacotes da nova versão principal do PostgreSQL. Para o SLE 15 SP5, isso significa instalar o postgresql13-server e todos os pacotes dos quais ele depende.
Instale o pacote postgresql13-contrib, que contém o comando
pg_upgrade
.Verifique se você tem espaço livre suficiente na área de dados do PostgreSQL, que é
/var/lib/pgsql/data
por padrão. Se o espaço for pouco, tente reduzir o tamanho com o seguinte comando SQL em cada banco de dados (pode levar muito tempo!):VACUUM FULL
Pare o servidor PostgreSQL usando qualquer um destes comandos:
#
/usr/sbin/rcpostgresql
stopou
#
systemctl stop postgresql.service(dependendo da versão do SLE que você usa como a versão inicial para o upgrade).
Renomeie o diretório de dados antigo:
#
mv
/var/lib/pgsql/data /var/lib/pgsql/data.oldInicialize a nova instância do banco de dados manualmente com
initdb
ou iniciando e parando o PostgreSQL, que fará isso automaticamente:#
/usr/sbin/rcpostgresql
start#
/usr/sbin/rcpostgresql
stopou
#
systemctl start postgresql.service#
systemctl stop postgresql.service(dependendo da versão do SLE que você usa como a versão inicial para o upgrade).
Se você modificou os arquivos de configuração na versão antiga, considere transferir essas modificações para os novos arquivos de configuração. Isso pode afetar os arquivos
postgresql.auto.conf
,postgresql.conf
,pg_hba.conf
epg_ident.conf
. As versões antigas desses arquivos estão localizadas em/var/lib/pgsql/data.old/
, e as versões novas estão disponíveis em/var/lib/pgsql/data
.Não é recomendado copiar os arquivos de configuração antigos, pois isso pode sobregravar as novas opções, os novos padrões e os comentários modificados.
Inicie o processo de migração como usuário
postgres
:#
su - postgres postgres >pg_upgrade
\ --old-datadir "/var/lib/pgsql/data.old" \ --new-datadir "/var/lib/pgsql/data" \ --old-bindir "/usr/lib/postgresql12/bin/" \ --new-bindir "/usr/lib/postgresql13/bin/"Inicia a nova instância de banco de dados usando um destes comandos:
#
/usr/sbin/rcpostgresql
startou
#
systemctl start postgresql.service(dependendo da versão do SLE que você usa como a versão inicial para o upgrade).
Verifique se a migração foi bem-sucedida. O escopo do teste depende do seu caso de uso, e não há nenhuma ferramenta geral para automatizar esta etapa.
Remova qualquer pacote antigo do PostgreSQL e o diretório de dados antigo:
#
zypper
search -s postgresql12| xargs zypper rm -u#
rm
-rf /var/lib/pgsql/data.old
Para obter mais informações sobre o upgrade de bancos de dados ou o uso de métodos alternativos, como replicação lógica, consulte a documentação oficial do PostgreSQL em https://www.postgresql.org/docs/13/upgrading.html.
3.8 Migrar o banco de dados MySQL ou MariaDB #
A partir do SUSE Linux Enterprise 12, o SUSE trocou o MySQL pelo MariaDB. Antes de você começar qualquer upgrade, é altamente recomendável fazer backup do banco de dados.
Para executar a migração do banco de dados, faça o seguinte:
Crie um arquivo de dump:
#
mysqldump
-u root -p --all-databases --add-drop-database > mysql_backup.sqlPor padrão, o
mysqldump
não descarrega o banco de dadosINFORMATION_SCHEMA
ouperformance_schema
Para obter mais detalhes, consulte https://mariadb.com/kb/en/mariadb-dumpmysqldump/.Armazene o arquivo de dump, o arquivo de configuração
/etc/my.cnf
e o diretório/etc/mysql/
para investigação futura (não para instalação!) em um local seguro.Faça o upgrade do SUSE Linux Enterprise Server. Após o upgrade, o arquivo de configuração antigo
/etc/my.cnf
ainda estará intacto. Você encontra a nova configuração no arquivo/etc/my.cnf.rpmnew
.Configure o banco de dados MariaDB de acordo com as suas necessidades. Não use o arquivo de configuração e o diretório antigos, mas use-os como base e adapte-os.
Inicie o servidor MariaDB:
#
systemctl
start mariadbPara iniciar o servidor MariaDB em cada boot, habilite o serviço:
#
systemctl
enable mariadbVerifique se o MariaDB está sendo executado apropriadamente conectando-se com o banco de dados:
#
mariadb
-u root -p
3.9 Criar certificações de servidor não MD5 para aplicativos Java #
Como medida de segurança, os certificados baseados em MD5 não são mais suportados no Java. Se você criou certificados como MD5, recrie-os seguindo estas etapas:
Abra um terminal e efetue login como
root
.Crie uma chave privada:
#
openssl
genrsa -out server.key 1024Para uma chave mais forte, substitua
1024
por um número mais alto. Por exemplo,4096
.Crie uma Solicitação de Autenticação de Certificado (CSR, Certificate Signing Request):
#
openssl
req -new -key server.key -out server.csrAutoassine o certificado:
#
openssl
x509 -req -days 365 -in server.csr -signkey server.key -out server.crtCrie o arquivo PEM:
#
cat
server.key server.crt > server.pemArmazene os arquivos
server.crt
,server.csr
,server.key
eserver.pem
nos respectivos diretórios onde estão as chaves. Para o Tomcat, por exemplo, o diretório é/etc/tomcat/ssl/
.
3.10 Encerrar convidados de máquinas virtuais #
Se a sua máquina atuar como Servidor de Host de VM do KVM ou Xen, encerre apropriadamente todos os Convidados de VM em execução antes da atualização. Do contrário, pode não ser possível acessar os convidados após a atualização.
3.11 Ajustar a configuração do cliente SMT #
Se a máquina que você deseja fazer upgrade estiver registrada como um cliente em um servidor SMT, tome os seguintes cuidados:
Verifique se a versão do script clientSetup4SMT.sh
no seu host está atualizada. O clientSetup4SMT.sh
de versões mais antigas da SMT não pode gerenciar clientes da SMT 12. Se você aplica patches de software regularmente a seu servidor SMT, pode sempre encontrar a versão mais recente do clientSetup4SMT.sh
em <SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh
.
Em caso de falha no upgrade da máquina para uma versão superior do SUSE Linux Enterprise Server, cancele o registro da máquina do servidor SMT, conforme descrito no Procedimento 3.1. Em seguida, reinicie o processo de upgrade.
Efetue login na máquina do cliente.
A etapa seguinte depende do sistema operacional atual do cliente:
Para o SUSE Linux Enterprise 11, execute os seguintes comandos:
>
sudo
suse_register -E>
sudo
rm -f /etc/SUSEConnect>
sudo
rm -rf /etc/zypp/credentials.d/*>
sudo
rm -rf /etc/zypp/repos.d/*>
sudo
rm -f /etc/zypp/services.d/*>
sudo
rm -f /var/cache/SuseRegister/*>
sudo
rm -f /etc/suseRegister*>
sudo
rm -f /var/cache/SuseRegister/lastzmdconfig.cache>
sudo
rm -f /etc/zmd/deviceid>
sudo
rm -f /etc/zmd/secretPara o SUSE Linux Enterprise 12, execute os seguintes comandos:
>
sudo
SUSEConnect --de-register>
sudo
SUSEConnect --cleanup>
sudo
rm -f /etc/SUSEConnect>
sudo
rm -rf /etc/zypp/credentials.d/*>
sudo
rm -rf /etc/zypp/repos.d/*>
sudo
rm -f /etc/zypp/services.d/*
Efetue login no servidor SMT.
Verifique se o registro do cliente foi cancelado com êxito listando todos os registros de clientes:
>
sudo
smt-list-registrationsSe o nome de host do cliente ainda constar na lista retornada por esse comando, obtenha o
Unique ID
do cliente na primeira coluna. (O cliente pode ser listado com vários IDs.)Apague o registro desse cliente:
>
sudo
smt-delete-registration -g UNIQUE_IDSe o cliente estiver listado com vários IDs, repita a etapa acima para cada um dos IDs exclusivos.
Agora, verifique se o registro do cliente foi cancelado com êxito executando novamente:
>
sudo
smt-list-registrations
3.12 Mudanças nos perfis do AutoYaST do SLE 12 para 15 #
Para saber como migrar perfis do AutoYaST, consulte o Appendix D, Differences between AutoYaST profiles in SLE 12 and 15.
3.13 Fazendo upgrade de um servidor SMT (Subscription Management Tool) #
Um servidor que executa a SMT requer um procedimento de upgrade especial. Consulte Chapter 3, Migrate from SMT to RMT no Repository Mirroring Tool Guide.
3.14 Desabilitando temporariamente o suporte à multiversão do kernel #
O SUSE Linux Enterprise Server permite instalar várias versões do kernel habilitando as respectivas configurações em /etc/zypp/zypp.conf
. O suporte a esse recurso precisa ser temporariamente desabilitado para fazer upgrade de um pacote de serviço. Quando a atualização for concluída com êxito, o suporte à multiversão poderá ser reabilitado. Para desabilitar o suporte à multiversão, comente as respectivas linhas em /etc/zypp/zypp.conf
. O resultado deve ser semelhante a:
#multiversion = provides:multiversion(kernel) #multiversion.kernels = latest,running
Para reativar esse recurso após a atualização bem-sucedida, remova os sinais de comentário. Para obter mais informações sobre o suporte à multiversão, consulte o Section 27.1, “Enabling and configuring multiversion support”.
3.15 Fazendo upgrade no IBM Z #
O de uma instalação do SUSE Linux Enterprise no IBM Z requer o parâmetro de kernel Upgrade=1
Upgrade=. . Por exemplo, usando o parmfile. Consulte a Seção 5.5, “Parmfile: automatizando a configuração do sistema”.
3.16 IBM POWER: Iniciando um servidor X #
No SLES 12 para IBM POWER, o gerenciador de exibição é configurado para não iniciar um servidor X local por padrão. Essa configuração foi revertida no SLES 12 SP1: o gerenciador de exibição agora inicia um servidor X.
Para evitar problemas durante o upgrade, a configuração do SUSE Linux Enterprise Server não é mudada automaticamente. Para que o gerenciador de exibição inicie um servidor X após o upgrade, mude a configuração de DISPLAYMANAGER_STARTS_XSERVER
em /etc/sysconfig/displaymanager
da seguinte maneira:
DISPLAYMANAGER_STARTS_XSERVER="yes"