Como chegámos aqui
A distribuição CentOS sempre foi um animal estranho: como é que podia ser que a principal distribuição Linux de utilização exclusivamente paga (Red Hat Enterprise Linux, ou RHEL) tivesse um clone de utilização totalmente gratuita?
Por isso, e por razões que indicarei abaixo, não me surpreendeu completamente que as condições de acesso à distribuição CentOS tenham mudado, se bem que o método, o tempo e a forma como tudo foi comunicado vão ser um caso de estudo de como-não-fazer…
Fiquei curioso com as duas alternativas que se perfilaram, o Rocky Linux e o AlmaLinux, e decidi testar a migração de um sistema CentOS 8 para ambos, uma vez que tudo isto resultou no End-Of-Life do CentOS8 em Dezembro de 2021 em vez de 2029 como muita gente tinha planeado.
Fragmentação?
Como sempre no mundo FOSS, nunca há apenas uma única resposta a um problema - é uma força, e uma fraqueza. Neste caso creio que ambos os projectos têm o seu público-alvo, que talvez lhes permita manterem-se os dois activos e vigorosos:
| RockyLinux | AlmaLinux | |
|---|---|---|
| Base Territorial | EUA | Europa |
| Público-alvo | High-Performance Computing, hardware com drivers distribuídos em binário (estou-te a ver, HPE), ex-utilizadores do Scientific Linux | cPanel, servidores Web |
Veremos se ambos sobreviverão…
O teste
Para este teste, baseei-me num conjunto de VMs que simulava uma rede de serviços tipicamente Windows (AD-DC, SMB, impressão, Group Policies) com base num servidor CentOS8 e Samba (compilado da fonte).
O objectivo é fazer o sidegrade a este último (TJGGS) para as alternativas ao CentOS8: Rocky Linux e AlmaLinux, e testar a funcionalidade básica.
Preparativos
Os computadores estão no domínio DASILVAT e utilizadores do domínio podem-se logar nos computadores:
LOGONSERVER=\\TJGGS USERDNSDOMAIN=DASILVAT.LOCAL USERDOMAIN=DASILVAT
Loguei-me em TJGGS com o PuTTY, a partir do computador RSAT
Fora da caixa, o sistema está tal e qual o deixei em Junho de 2020, quando terminei o trabalho para o CINEL.
login as: formando Authenticating with public key "rsa-key-20200615" Passphrase for key "rsa-key-20200615": Last login: Sat Jun 27 20:31:21 2020 from 10.12.140.99 [formando@tjggs ~]$ uname -a Linux tjggs 4.18.0-147.8.1.el8_1.x86_64 #1 SMP Thu Apr 9 13:49:54 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
A primeira coisa que temos de fazer é uma actualização geral. E como há mais de um ano que os repositórios não são actualizados, é melhor usar --refresh
|
|
[...] Transaction Summary ==================================================================================================================================== Install 22 Packages Upgrade 518 Packages [...]
Depois de um reinício, passámos do CentOS 8.1 para 8.4:
|
|
Linux tjggs 4.18.0-305.19.1.el8_4.x86_64 #1 SMP Wed Sep 15 15:39:39 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Nos clientes Windows surgiu o aviso de que as credenciais precisavam de ser reintroduzidas; logoff, mudança de palavra-passe, e ao tentar de novo o logon, surgiu o erro de que o computador não estava registado no domínio.
Muito bem, loguei com o administrador local e tentei primeiro Remove-Computer -Credential DASILVAT\Administrator e depois Add-Computer; sempre não autorizado (Access is denied).
Loguei “localmente” em TJGGS e verifiquei os logs; /var/log/messages tinha uma indicação de que a sysvol estava com permissões erradas:
chdir_current_service: vfs_ChDir(/usr/local/samba/var/locks/sysvol) failed: Permission denied. Current token: uid=3000025, gid=3000026, 7 groups: 3000025 3000026 3000035 3000036 3000037 3000006 3000011
Apesar de ser um bocado perigoso, usei o esfregão de palha de aço:
|
|
systemctl status samba-ad-dc já deu o serviço como activo e sem erros. E quando tentei de novo logar um utilizador no computador CLIENTE, funcionou, e os GPOs estavam activos.
Resolver o mesmo problema no cliente RSAT foi um pouco mais complicado; primeiro tive de tirar o cliente do domínio pela GUI (Computer Preferences como Administrator local), e depois já foi possível abrir uma PowerShell de Administrador e usar os comandos
|
|
No entanto, passei a ter outro problema no log do serviço samba-ad-dc; imagino que devido a ter reinicializado as ACLs da sysvol, agora são as permissões das shares que dão erro:
chdir_current_service: vfs_ChDir(/mnt/dumdum/recursos) failed: Permission denied. Current token: uid=3000041, gid=3000026, 7 groups: 3000041 3000026 3000035 3000036 3000037 3000006 3000011
Este token, claro, corresponde ao computador que acabei de reintroduzir no domínio:
|
|
DASILVAT\WIN7-RSAT$ 1
A solução foi adicionar o grupo Domain Computers à share (bastaram permissões de leitura)
Agora que temos o sistema mais ou menos estabilizado, podemos testar a migração de TJGGS de CentOS 8 para Rocky Linux e para AlmaLinux
Rocky Linux
A página que documenta o processo de migração é https://docs.rockylinux.org/guides/migrate2rocky/ , e é aconselhado estarmos logados na conta root.
Para evitar o método curl <url> -o <script>.sh, que pode ser inseguro se houver um ataque Man-In-The-Middle, começamos por instalar o git:
|
|
Last metadata expiration check: 2:05:12 ago on Sun 31 Oct 2021 09:14:58 PM WET. Package git-2.27.0-1.el8.x86_64 is already installed. Dependencies resolved. Nothing to do. Complete!
Descarregamos os scripts do repositório e corremos o script de migração:
|
|
[...] Done, please reboot your system. A log of this installation can be found at /var/log/migrate2rocky.log
Depois de reiniciar, o GRUB tem uma entrada “Rocky Linux”:
O resultado de hostnamectl é:
Um utilizador pré-existente ainda pode logar-se no domínio:
Usando o RSAT, criei um novo utilizador com as mesmas características e o mesmo pacote de GPOs:
O novo utilizador também se logou e as mesmas configurações foram aplicadas, excepto a impressora partilhada que é uma configuração muito sensível em Samba; no entanto, o fundo de ecrã correcto carregou (especificado por GPO a partir de uma pasta partilhada), por isso não foi impedido por qualquer problema de permissões nas shares do domínio.
AlmaLinux
Para uma avaliação equilibrada, usou-se um segundo clone de TJGGS ainda em CentOS mas já com os problemas do Samba resolvidos (pelo menos, aqueles que detectei)
O processo de migração do AlmaLinux não está tão bem documentado como o Rocky; em vez de uma página de explicação, o botão Migrate em https://almalinux.org vai directamente para o repositório GitHub do script de migração, onde a documentação do processo fica a cargo do README. Não é a situação ideal.
Por outro lado, também não é mencionada a hipótese de clonar localmente o repositório, e apenas é dada a sugestão de descarregar o script por curl. Ainda menos ideal, e claramente inseguro.
Por isso, vamos repetir o processo mais seguro, como fizemos para o Rocky:
Abrimos uma root shell e clonamos o repositório:
|
|
Check root privileges OK Check centos-8.x86_64 is supported OK Download RPM-GPG-KEY-AlmaLinux OK Import RPM-GPG-KEY-AlmaLinux to RPM DB OK Download almalinux-release package OK Verify almalinux-release package OK Your OS is supported OK Remove OS specific rpm packages OK [...] All Secure Boot related packages which were released by not AlmaLinux are reinstalledOK Migration to AlmaLinux is completed
E reiniciei TJGGS
No RSAT criei um novo utilizador, agora na Active Directory baseada em AlmaLinux
Este novo utilizador também se logou no domínio a partir do computador Cliente, com as GPOs aplicadas correctamente (menos a impressora):
Conclusão
Como prometido, tanto o Rocky Linux como o AlmaLinux foram capazes de fazer a migração lateral de um servidor CentOS8 com alguns serviços (samba-ad-dc, chrony, RAIDs mdm, SSHd) sem grandes problemas.
Os problemas iniciais de permissões de certeza que foram causados por mim durante a configuração inicial do servidor, porque me lembro que tinha problemas com as permissões da sysvol que impediam alguns GPOs de funcionar correctamente; basicamente o problema arrastou-se até agora.
Editorial
O mundo do Free and Open Source sempre viveu um problema causado por “Liberdade” e “Gratuitidade” se escreverem exactamente da mesma maneira em Inglês: Free. E se a Liberdade é um valor relativo para muita gente, a Gratuitidade é um atractivo muito maior e que se pode medir directamente, por isso o mundo FOSS, pelo menos nos primeiros anos, pouco fez para frisar que, das duas possibilidades, a Liberdade é que é o objectivo principal do FOSS.
Obviamente que nada é “de graça”, tudo tem um custo que se não somos nós a pagar sendo o produto, alguém está a pagar por nós, seja em esforço humano, ciclos de CPU, armazenamento, conectividade, energia, hardware… Por isso quando os projectos FOSS atingem alguma maturidade e posição no mercado, tentam que os utilizadores contribuam com alguma coisa (qualquer coisa!) que beneficie o projecto directamente, mais do que a mera divulgação e promoção.
Deste modo, as companhias por trás de muitos projectos FOSS vendem serviços e suporte, mas cada vez mais também fecham certas conveniências por trás desses contratos, para incutir os utilizadores a pagarem dinheiro pelo produto FOSS. Essas conveniências extra (para além do simples suporte) costumam ser:
- Funcionalidade limitada: certas funcionalidades de uso mais empresarial são desenvolvidas com base numa licença não-FOSS e apenas são desbloqueadas contra o pagamento de uma licença ou compra de hardware em pacote
- OPNsense, e outros; notoriamente, quase todos os fornecedores de appliances de armazenamento baseadas em ZFS (como o TrueNAS) bloqueiam o acesso a funcionalidades de clustering e High-Availability à compra de hardware em pacote com o software.
- Acesso a actualizações: apenas são disponibilizados os binários da versão x.0.0, e quaisquer actualizações sob a forma de binários pré-compilados apenas estão disponíveis para utilizadores com contrato de suporte; no entanto, graças às licenças FOSS, quem quiser pode compilar o código-fonte (e assumir o suporte).
- Bareos, OPNsense
- Acesso a versões estáveis: em sentido contrário ao anterior, apenas são disponibilizadas em binário a compilação diária (nightly) do estado actual do processo de desenvolvimento, sem qualquer tipo de testes de funcionalidade (mas pelo menos a compilação terminou com sucesso); neste caso, para se obter uma versão estável é mais seguro ir buscar o código-fonte da nightly da versão principal (major version) anterior, que estará mais bem testada e cujas actualizações deverão corresponder a resoluções de erros - mesmo assim, sem nenhuma garantia de que não tenham sido introduzidos novos erros.
- VyOS
A RedHat decidiu-se por uma variante desta última opção: em vez de apenas disponibilizar as nightlies do CentOS, teve noção que isso seria um passo maior que as pernas (além de já terem o Fedora Rawhide para isso) e decidiu que o CentOS passaria a estar acessível em binário no estado de desenvolvimento da minor version actual
- Em vez de a versão 8.4 do CentOS ser lançada depois do RHEL 8.4 ser lançado, o RHEL estará na versão 8.4 e o CentOS estará na versão seguinte 8.5, e apenas quando o CentOS Stream 8.5 for julgado estável é que será convertido em RHEL 8.5 e o CentOS passará imediatamente a testar as correcções previstas para versão 8.6.
- Ou mais ainda, quem quiser testar as funcionalidades da versão 9 do RHEL, já pode tentar instalar o CentOS Stream 9…
Deste modo, os utilizadores do CentOS contribuirão com testes (e relatórios de erros, ou assim espera a RedHat), pagando qualquer coisa pelo uso do código desenvolvido pela RedHat.