CentOS Linux 8, finalmente!

Marcelo Veriato Lima
Oct 1, 2019 · 15 min read
Image for post
Image for post
CentOS — Community Enterprise Operating System

Buenas TechRebels, me chamo Marcelo Veriato Lim. 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”

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.

Image for post
Image for post
Cockpit

Cockpit Web Console

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/

Image for post
Image for post
Podman e Buildah

Novas ferramentas para Containers

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.

Image for post
Image for post

Desktop com Wayland por padrão

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.

Image for post
Image for post
Atual arquitetura do X

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.

Image for post
Image for post
Arquitetura do Wayland

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.

Image for post
Image for post

Melhorias no stack TCP

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.

Image for post
Image for post
dnf package manager

Gerenciador de pacotes DNF

Image for post
Image for post

Secure-boot para Virtual Machines

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.

Image for post
Image for post

Mudanças na configuração de rede

# 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
Image for post
Image for post
Arquivo de configuração 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
Image for post
Image for post
Text interface 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.

Image for post
Image for post
nftables

Filtro de pacotes com nftables

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.

Image for post
Image for post

Suporte e gerenciamento de memória aprimorados

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.

Image for post
Image for post

Crash dump no boot do sistema operacional

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.

Image for post
Image for post

Chrony agora vem 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

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.

Referências

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

Image for post
Image for post

Marcelo Veriato Lima é CEO da Lotic Arquitetura de Soluções.

Especialista em arquitetura de infraestrutura para Datacenter e Cloud, trabalha com TI a pelo menos 20 anos, participa ativamente da comunidade Open-Source.

LinkedIn.

TechRebels

The day-to-day of the IT Infrastructure.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store