CentOS Linux 8, finalmente!

Marcelo Veriato Lima

Follow

Oct 1 · 15 min read

Buenas TechRebels, me chamo Marcelo Veriato Lima. Neste artigo vamos falar sobre a tão esperada distribuição CentOS Linux 8 e quais as novidades.

Fique à vontade para comentar e entrar em contato comigo pelo LinkedIn, estamos todos aqui para aprendermos juntos. Se gostou do artigo, incentive dando “claps” aí do lado esquerdo e compartilhe nos seus grupos. Não se esqueça de seguir a mim e à TechRebels clicando follow lá em cima :)

Vamos lá. Resumidamente para você entender, a distribuição CentOS Linux foi criada logo depois que a Red Hat deixou de disponibilizar o Red Hat Enterprise Linux (RHEL) de forma gratuita. É mantida pela comunidade CentOS Project e derivada do código fonte do RHEL distribuído gratuitamente pela Red Hat. Por isso é considerada uma distribuição de nível enterprise.

Para maiores informações sobre a comunidade e também sobre a história do CentOS Linux acesse a página do projeto.

A versão 8 do RHEL foi disponibilizada no dia 07 de maio de 2019 pela Red Hat, confira o press-release de lançamento. No mesmo dia a comunidade do CentOS Project iniciou os esforços para a criação do build e finalmente no dia 24 de setembro de 2019 a release final foi lançada. Confira o histórico do build do CentOS 8.

Repositórios “BaseOS” e “AppStream”

Uma novidade no CentOS 8 são os dois repositórios. O repositório principal chamado de “BaseOS” fornece o que chamamos de distribuição base, é recomendada para ambientes produtivos com máquinas virtuais, baremetal, instâncias em nuvem ou containers. O seu conteúdo é disponibilizado em formato RPM nos mesmos moldes das versões anteriores.

Já o repositório “AppStream” é um build intermediário entre o Upstream do Fedora e o Downstream do Red Hat Enterprise Linux (RHEL). Podemos descrever como uma melhoria no processo de lançamento de novas minor releases do CentOS, devido a interação entre outros desenvolvedores de código aberto. Esse modelo de desenvolvimento permite que a comunidade discuta, faça sugestões e contribua com funcionalidades e correções de forma mais rápida. Hoje o CentOS Stream está disponível com base nos pacotes do CentOS Linux 8 com o mais recente Kernel de desenvolvimento do RHEL8.

Nos próximos meses o CentOS Project e a engenharia da Red Hat planejam iniciar as atualizações de pacotes no CentOS Stream, refletindo o desenvolvimento da próxima minor release do RHEL. Pessoalmente vejo esse esforço como um grande avanço em ambas distribuições, CentOS e RHEL.

Não vou entrar muito a fundo nas questões que se referem aos Modules do AppStream, até porque essa frente ainda não iniciou no CentOS. Basicamente se trata de versões mais atualizadas de pacotes utilizados em User Space, atualizações mais frequentes do que as disponibilizadas pelo core do sistema operacional. Isso fornece maior flexibilidade para personalizar a instalação sem afetar a estabilidade do sistema e também para implantações específicas.

Cada módulo definirá seu próprio ciclo de vida, mais próximo do aplicativo em vez do ciclo de vida do sistema operacional. A Red Hat já disponibiliza alguns pacotes para o RHEL e uma página de consulta do ciclo de vida dessas Application Streams.

Cockpit Web Console

Muitos usuários do Linux não conhecem o Cockpit, se trata de uma interface web de administração do sistema operacional. Além de recursos de administração, nela você tem gráficos de performance em tempo real, acesso a console, administração de storage e rede, inspeção de logs, etc.

Abaixo algumas das suas funcionalidades:

• Gerenciamento de serviços: Iniciar, parar, reiniciar, desabilitar, habilitar, mascarar, etc;
• Gerenciamento de contas de usuários: Adicionar, deletar, bloquear, gerenciar grupos, trocar senha, configurar política de troca de senha, adicionar chaves SSH, etc;
• Gerenciamento de firewall;
• Gerenciamento de containers;
• Gerenciamento de políticas SELinux;
• Journal v2;
• Configurações de ISCSI;
• SOS-reporting;
• Configuração do cliente NFS;
• Configuração do OpenConnect VPN Server;
• Desligar ou reiniciar o sistema operacional;
• Adicionar a máquina em um domínio;
• Gerenciamento do hardware;
• Gerenciamento de Updates para dnf, yum e apt;
• Gerenciamento de Nodes Kubernetes;
• Gerenciamento de outros servidores a partir de um Cockpit centralizado.

O interessante é que no CentOS 8 o Cockpit já vem instalado por padrão, basta subir o serviço e habilitar a permissão de acesso no firewall.

# systemctl enable --now cockpit.socket
# firewall-cmd --add-service=cockpit --permanent
# firewall-cmd --reload

Para acessá-lo utilize a url https://(endereço IP ou hostname):9090/

Novas ferramentas para Containers

O CentOS 8 suporta Linux Containers utilizado Podman. Para criação de imagens ou mesmo um Dockerfile agora se utiliza o Buildah. Se você não conhece ambas as ferramentas, saiba que elas eram utilizadas no projeto CoreOS (adquirido pela Red Hat no início de 2018) e também pelo projeto Atomic.

O interessante é que elas substituem o Docker e o Moby e não depende do root ou de um processo levantado. São compatíveis com imagens existentes de Docker.

Como usuários de Docker, você deve saber que é requerido um processo/daemon para o funcionamento correto, execução e coordenação de todas as tarefas. O objetivo de não utilizar um processo para a gestão dos containers é evitar um ponto único de falha (do próprio processo), melhorar a segurança e evitar vulnerabilidades na criação de containers já que as ações executadas pelo Docker utilizam todas o mesmo processo.

Desktop com Wayland por padrão

O Wayland se propõe ser um substituto mais simples para o X, mais fácil de desenvolver e manter. É o servidor X padrão do CentOS 8, mas ainda é possível utilizar o Xorg. Entre os seus benefícios o principal é uma melhor gestão sobre os conhecidos gargalos entre os clientes do X e o kernel do Linux.

O funcionamento do X sempre me chamou muito a atenção, não vamos entrar muito a fundo pois o tema não é tão simples. De forma extremamente resumida, existe um componente chamado compositor, ele é responsável por renderizar todo o conteúdo da tela com base em seus gráficos e no conteúdo das janelas do X. No entanto, ele precisa passar pelo servidor X para executar a renderização.

O servidor X recebe as solicitações de renderização do compositor e copia o back buffer para front buffer e ainda pode fazer uma inversão de página. Nesse caso o servidor X precisa executar esta etapa para poder contabilizar a sobreposição de janelas, o que pode exigir cortes e determinar se pode ou não virar a página. No entanto para o compositor, essa é uma opção de contexto desnecessária.

Existem alguns problemas nessa abordagem. O servidor X não tem as informações para decidir qual janela deve receber o evento, nem pode transformar coordenadas da tela em coordenadas locais da janela. Mesmo que o servidor X tenha entregado a responsabilidade ao composite manager, o X continua controlando o front buffer e o modesetting. Grande parte da complexidade que o servidor X lidava agora está disponível diretamente no kernel ou em bibliotecas independentes como KMS, evdev, mesa, fontconfig, freetype, cairo, Qt, etc. Em geral o servidor X agora é apenas um intermediário que inclui uma etapa extra entre os aplicativos e o compositor e também entre o compositor e o hardware.

No Wayland o compositor é o servidor X. O controle das bibliotecas KMS e evdev passaram para o compositor. O protocolo do Wayland permite que o compositor envie os eventos de entrada diretamente para os clientes X e permite ainda que o cliente envie os eventos de dado diretamente para o compositor.

Nesse formato, o Kernel pega um evento e envia ao compositor. No X o processo é semelhante, isso é bom porque é possível reutilizar todos os drivers de entrada no Kernel.

O compositor examina seu gráfico para determinar qual janela deve receber o evento. O gráfico corresponde ao que está na tela e o compositor entende as transformações que ele pode ter aplicado aos elementos do gráfico. Assim, o compositor pode escolher a janela correta e transformar as coordenadas da tela em coordenadas locais da janela. Os tipos de transformação que podem ser aplicados a uma janela são restritos apenas ao que o compositor pode fazer, desde que possa computar a transformação inversa para os eventos de entrada.
Como no caso X, quando o cliente recebe o evento, ele atualiza a interface do usuário como resposta. Porém, no caso de wayland a renderização acontece no cliente e o cliente envia uma solicitação ao compositor para indicar a região que foi atualizada.
Dessa forma o compositor atua diretamente com as bibliotecas, não dependendo mais de intermediários.

Melhorias no stack TCP

A pilha TCP foi atualizada para a versão 4.16 onde houve uma melhora significativa nas taxas de conexões de entrada.

Agora o Kernel Linux suporta novos algoritmos de controle de congestionamento, o BBR e o NV. Algoritmos de controle de congestionamento são executados dentro de cada equipamento, seja ele um servidor, desktop, smartphone, tablets, etc, conectados a uma rede. Sua função é decidir a rapidez com que os dados são enviados e recebidos.

Mas como um algoritmo de controle de congestionamento toma essa decisão? As redes usam amplamente o controle de congestionamentos com base em perdas desde o final dos anos 80, contando apenas com indicações de pacotes perdidos como sinal para desacelerar. Isso funcionou bem por muitos anos, porque os pequenos buffers dos switches e roteadores da rede correspondiam bem à baixa largura de banda dos links de dados. Como resultado, os buffers tendiam a encher e eliminar pacotes em excesso no momento em que os remetentes realmente começaram a enviar dados muito rápido.

O problema é que esse tipo de controle de congestionamento baseado em perdas é problemático nas diversas redes atuais:

Nos chamados shallow buffers, a perda de pacotes ocorre antes do congestionamento. Com os atuais links de alta velocidade e longa distância que usam switches commodities com buffers pequenos, o controle de congestionamento com base em perdas pode resultar em uma taxa de transferência péssima porque ela excede esse buffer, reduzindo pela metade a taxa de envio após a perda de pacotes, mesmo que a perda de pacotes ocorra por rajadas transitórias de tráfego. Esse tipo de perda de pacote pode ser bastante frequente, mesmo quando o link está ocioso.

Já nos deep buffers, o congestionamento ocorre antes da perda de pacotes. Nos limites das redes de hoje, o controle de congestionamento baseado em perdas causa o problema de “bufferbloat”, preenchendo repetidamente os deep buffers em muitos links de última milha e causando segundos de atraso desnecessário na fila.

O algoritmo BBR (desenvolvido pelo Google) resolve esse problema respondendo ao congestionamento real em vez da perda de pacotes através de uma reescrita básica do controle de congestionamento. O BBR considera a rapidez com que a rede está entregando dados. Para uma determinada conexão de rede, ela usa medições recentes da taxa de entrega da rede e do tempo de ida e volta para criar um modelo explícito que inclui a largura de banda máxima disponível para essa conexão e o atraso mínimo de ida e volta. O BBR usa esse modelo para controlar a rapidez com que envia dados e a quantidade máxima de dados que deseja permitir na rede a qualquer momento.

Em um simples testes com iperf, utilizando o algoritmo BBR em uma transferência de dados por 30 segundos, a diferença é tremenda:

Sem BBR: Transfer: 27.5 MBytes. Bandwidth: 7.15 Mbits/sec
Com BBR: Transfer: 127 MBytes. Bandwidth: 35.0 Mbits/sec

Sem dúvida o BBR é uma das melhores melhorias na pilha de rede do Linux nos últimos anos.

Já o algoritmo NV é um mecanismo de prevenção de congestionamento baseado em atraso para o TCP. Seu mecanismo de filtragem usa a melhor medida em um período específico para detectar e medir o congestionamento. Ele foi desenvolvido para coexistir com redes modernas, onde as larguras de banda dos links são 10 Gbps ou mais, onde os RTTs podem ter microssegundos, onde as funcionalidades interrupt coalescing e TSO/GSO podem introduzir ruídos e efeitos não lineares.

Gerenciador de pacotes DNF

O DNF é o novo gerenciador de pacotes do CentOS 8. Introduzido no Fedora 18, o DNF ou “Dandified yum” é a versão de próxima geração do yum. Mantém a compatibilidade da CLI com o yum e define uma API poderosa para extensões e plugins. Os plug-ins podem modificar ou estender os recursos do DNF ou fornecer comandos CLI adicionais. Resumindo, é a evolução do tradicional yum, com menor uso de recursos de memória, método mais rápido e matematicamente correto para resolver a resolução de dependências, uma API Python “clean” e bem documentada com ligações em C para bibliotecas de baixo nível como hawkey, librepo e libcomps além do suporte para Python 3.

Secure-boot para Virtual Machines

Desde sempre fizemos piadinhas com a BIOS, “é problema de BIOS”. O processo de execução da BIOS passa tão desapercebido que não damos importância a ela, simplesmente queremos a tela de login do sistema operacional o mais rápido possível. A BIOS é o primeiro software a ser executado pelo computador logo que o ligamos, ela serve como uma ponte do hardware com o sistema operacional. Sua primeira ação é inicializar o hardware e procurar um sistema operacional transferindo então o controle do hardware para o sistema instalado. Como nesse intervalo entre o load da BIOS e o boot do sistema operacional é mais difícil ter um software que analise uma vulnerabilidade, os malfeitores começaram a explorá-lo com os chamados Bootkits. Dessa forma é possível executar códigos maliciosos antes que a camada de segurança (antivírus, antimalware) instalada no sistema operacional seja inicializada.

Por esse motivo foi desenvolvido o UEFI (Unified Extensible Firmware Interface) visando tornar esse processo de inicialização mais seguro. De forma resumida, o UEFI protege contra a inicialização de um sistema não autorizado através do “secure-boot”. O secure-boot é uma configuração do UEFI que verifica assinaturas de criptografia no bootloader do sistema operacional junto com o Kernel, visando garantir que não tenham sido violados ou ignorados no processo de inicialização. Saiba que já existem bootkits para UEFI.

Agora no CentOS 8 é possível utilizar essa funcionalidade para a inicialização de máquinas virtuais buscando garantir a essa integridade também no ambiente virtual.

Mudanças na configuração de rede

Anunciado no RHEL 8 e consequentemente no CentOS 8, os populares “network-scripts” foram marcados como deprecated, ou seja, os usuários devem começar a utilizar o NetworkManager de maneira definitiva. Eu particularmente não gostava do NetworkManager mas a partir do CentOS 7 fui obrigado a estudá-lo e realmente, é uma ferramenta muito boa, simples e fácil de usá-la. Caso você ainda não se sinta confortável com o NM, ainda é possível instalar os network-scripts através do comando abaixo:

# yum install network-scripts

Existem três formas de configurar a rede no CentOS 8 / RHEL 8 via console. Também é possível configurar via interface gráfica, todas utilizando o NetworkManager. Vamos falar apenas das maneiras via console.

• 1ª forma editando manualmente os arquivos de configuração da respectiva placa de rede. Os arquivos de configuração continuam no mesmo diretório das versões anteriores: /etc/sysconfig/network-scripts/ifcfg-(interface-name). Depois de editá-los basta reiniciar o processo do Network Manager.

# vi /etc/sysconfig/network-scripts/ifcfg-enp0s3

# systemctl restart NetworkManager

• 2ª forma é utilizando a ferramenta nmtui. Ela é uma “text user interface” onde através de menus ela facilita a configuração.

# nmtui

• 3ª forma é utilizando o comando nmcli. Esta ferramenta é a “command line interface” do NetworkManager. Gaste um tempo lendo a documentação do nmcli, entenda a sua sintaxe e passe a utilizá-la para configurações de IP, rotas estáticas, bonding/teaming, bridge, etc.

No site da Red Hat você encontra a documentação completa do NetworkManager, confira aqui.

Filtro de pacotes com nftables

O nftables é um framework do projeto Netfilter que provê filtros, tradução de endereços (NAT) e marcação de pacotes. Ele combina todas as ferramentas do framework iptables (iptables, ip6tables, arptables e ebtables) em uma única ferramenta. Sua performance é superior comparado ao framework anterior.

Resumidamente a ferramenta nft trabalha como um compilador e descompilador. Uma virtual machine adicionada ao Kernel Linux pelo nftables compila o set de regras no bytecode da VM no formato Netlink, depois envia ao kernel por meio de uma API própria. Ao recuperar o set de regras, o bytecode da VM é descompilado de volta à sua apresentação original de regras. Isso tudo faz com que o desempenho aumente expressivamente.

Através de mapas e concatenações, a inspeção linear do set de regras não aumenta, ou seja, é possível estruturar seu set de regras para reduzir o número de inspeções visando encontrar de forma mais rápida a ação final a ser tomada em cima do pacote.

Entre outras melhorias podemos citar:

• Menor base de código no Kernel, a inteligência é colocada na ferramenta CLI nft em userspace. O código base do nft é consideravelmente mais complexo do que o iptables, no entanto, ele oferece novos recursos apenas atualizando a ferramenta nft em userspace, sem a necessidade de atualizações do Kernel.
• Pesquisa em tabelas ao invés de processamento linear;
• Estrutura única para protocolos IPv4 e IPv6;
• Regras aplicadas de forma atômica ao invés de buscar, atualizar e armazenar o set de regras;
• Suporte à depuração e rastreamento no set de regras (nftrace);
• Sintaxe mais consistente e compacta, sem extensões específicas de protocolos;
• API Netlink para aplicativos de terceiros.

O CentOS 8 utiliza o firewalld como frontend para o nftables.

Suporte e gerenciamento de memória aprimorados

No CentOS 7 o barramento de memória tinha 48 bits de capacidade de endereçamento virtual e 46 bits para memória física. O barramento físico era limitado a 64 TB de memória RAM.

No CentOS 8 os limites foram estendidos para 57 bits de memória virtual e 52 bits de memória física, ou seja, 128PB para virtual (64PB user / 64 PB kernel) e 4 PB de memória RAM.

Crash dump no boot do sistema operacional

O kdump é um recurso do Kernel Linux que cria despejos de memória no caso de falha do Kernel. Quando acionado, o kdump exporta uma imagem de memória que pode ser analisada com a finalidade de depurar a causa da falha.

No CentOS 8 é possível capturar a falha do Kernel durante todas as fases da inicialização do sistema operacional, o que no CentOS 7 não era possível.

Chrony agora vem por padrão

Agora no CentOS 8 o sincronismo de tempo é através do software Chrony por padrão.

Ele sincroniza o relógio do sistema operacional com servidores NTP (Network Time Protocol) e relógios de referência (receiver GPS). Também pode operar como servidor NTPv4 (RFC5905) fornecendo o serviço de sincronismo de tempo para outros equipamentos na rede.

Dois programas fazem parte do chrony, o chronyd é o daemon que pode iniciar junto com o sistema operacional e o chronyc que é chamado via CLI, ele pode ser utilizado para monitorar o desempenho do chronyd e alterar diversos parâmetros operacionais estiver em execução.

Conclusão

Tchê, para encerrar, esse é um resumo com algumas novidades do CentOS 8, espero que vocês baixem a ISO de instalação e comecem a brincar com as novas ferramentas para já irem se habituando com o sistema.

Eu havia prometido no artigo anterior onde falamos sobre as Distribuições Linux que o próximo seria sobre a instalação do CentOS 7 em ambientes de produção. Bom, agora com o CentOS 8 vamos direto nele, portando nos acompanhe aqui no TechRebels e não esqueça de compartilhar nossos artigos com seus amigos.

Espero que tenham gostado, não esqueçam de comentar e de seguir o nosso blog TechRebels. Até o próximo artigo.

Link reference:

CentOS Project — https://www.centos.org/

CentOS 8 (1905) Release Notes — https://wiki.centos.org/Manuals/ReleaseNotes/CentOS8.1905

CentOS 8 Stream Release Notes — https://wiki.centos.org/Manuals/ReleaseNotes/CentOSStream

Download — http://isoredirect.centos.org/centos/8/isos/x86_64/

Sobre o autor

Marcelo Veriato Lima é CTO da Adentro Cloud Solutions.

Especialista em tecnologias para Datacenter, certificado RHCE e CCNP-DC, trabalha com TI a pelo menos 20 anos, participa ativamente da comunidade Open-Source. LinkedIn.