O OSCAP add-on é habilitado por default no Red Hat Enterprise Linux 8.

O add-on Kdump adiciona suporte para configurar o despejo do kernel durante a instalação. Este add-on tem suporte total ao Kickstart (usando o comando don com_redhat_kdump e suas opções), e é totalmente integrado como uma janela adicional nas interfaces gráficas e de texto do usuário.

Um novo esquema de nomenclatura de dispositivos de rede que gera nomes de interface de rede baseados em um prefixo definido pelo usuário está disponível no Red Hat Enterprise Linux 8. A opção boot net.ifnames.prefix permite que o esquema de nomenclatura de dispositivos seja usado pelo programa de instalação e pelo sistema instalado. Veja a página de manual dracut.cmdline(7) para informações.

Desde o Red Hat Enterprise Linux 8.2, você pode registrar seu sistema, anexar assinaturas RHEL e instalar a partir da Red Hat Content Delivery Network (CDN) antes da instalação do pacote. Instalações interativas GUI, bem como instalações Kickstart automatizadas, suportam este recurso. Para mais informações, consulte o documento Notas de Lançamento RHEL 8.2.

Desde o Red Hat Enterprise Linux 8.2, você pode registrar seu sistema no Red Hat Insights durante a instalação. Instalações interativas GUI, bem como instalações Kickstart automatizadas, suportam este recurso. Para mais informações, consulte o documento RHEL 8.2 Notas de Lançamento.

No Red Hat Enterprise Linux 8, uma ISO unificada carrega automaticamente os repositórios de fontes de instalação BaseOS e AppStream. Este recurso funciona para o primeiro repositório base que é carregado durante a instalação. Por exemplo, se você iniciar a instalação sem nenhum repositório configurado e tiver a ISO unificada como repositório base na interface gráfica do usuário (GUI), ou se você iniciar a instalação usando a opção inst.repo= que aponta para a ISO unificada.

Como resultado, o repositório AppStream está habilitado na seção Additional Repositories da janela da GUI Installation Source. Você não pode remover o repositório AppStream ou alterar suas configurações, mas você pode desativá-lo em Installation Source. Este recurso não funciona se você iniciar a instalação usando um repositório base diferente e depois alterá-lo para a ISO unificada. Se você fizer isso, o repositório base é substituído. Entretanto, o repositório AppStream não é substituído e aponta para o arquivo original.

No Red Hat Enterprise Linux 8, múltiplas localizações de rede do stage2 ou arquivos Kickstart podem ser especificados para evitar falhas na instalação. Esta atualização permite a especificação de múltiplas opções de inicialização inst.stage2 e inst.ks com localizações de rede de stage2 e um arquivo Kickstart. Isto evita a situação em que os arquivos solicitados não podem ser alcançados e a instalação falha porque o servidor contatado com o stage2 ou o arquivo Kickstart está inacessível.

Com esta nova atualização, a falha de instalação pode ser evitada se forem especificados vários locais. Se todos os locais definidos forem URLs, a saber HTTP, HTTPS, ou FTP, eles serão testados sequencialmente até que o arquivo solicitado seja obtido com sucesso. Se houver um local que não seja um URL, somente o último local especificado será tentado. Os demais locais são ignorados.

Anteriormente, você só podia especificar um repositório base a partir dos parâmetros de inicialização do kernel. No Red Hat Enterprise Linux 8, um novo parâmetro do kernel, inst.addrepo=<name>,<url>, permite que você especifique um repositório adicional durante a instalação. Este parâmetro tem dois valores obrigatórios: o nome do repositório e a URL que aponta para o repositório. Para maiores informações, veja o uso instadd-adrepo.

O Red Hat Enterprise Linux 8 suporta a instalação a partir de um repositório em um disco rígido local. Anteriormente, o único método de instalação a partir de um disco rígido era usar uma imagem ISO como fonte de instalação. Entretanto, a imagem ISO do Red Hat Enterprise Linux 8 pode ser muito grande para alguns sistemas de arquivo; por exemplo, o sistema de arquivo FAT32 não pode armazenar arquivos maiores que 4 GiB. No Red Hat Enterprise Linux 8, você pode habilitar a instalação a partir de um repositório em um disco rígido local; você só precisa especificar o diretório ao invés da imagem ISO. Por exemplo: inst.repo=hd:<device>:<path to the repository>.

Para mais informações sobre os repositórios Red Hat Enterprise Linux 8 BaseOS e AppStream, veja a seção Repositories deste documento.

A janela Resumo da Instalação da instalação gráfica do Red Hat Enterprise Linux 8 foi atualizada para um novo layout de três colunas que fornece uma melhor organização das configurações gráficas da instalação.

Anteriormente, o programa de instalação do Red Hat Enterprise Linux não fornecia informações sobre o propósito do sistema ao Gerente de Assinaturas. No Red Hat Enterprise Linux 8, você pode definir o propósito pretendido do sistema durante uma instalação gráfica, usando a janela System Purpose, ou em um arquivo de configuração Kickstart, usando o comando syspurpose. Quando você define o propósito de um sistema, o servidor de direitos recebe informações que auxiliam na auto-instalação de uma assinatura que satisfaz o uso pretendido do sistema.

Anteriormente, não era possível para a biblioteca pykickstart fornecer informações sobre a finalidade do sistema ao Gerente de Assinaturas. No Red Hat Enterprise Linux 8, pykickstart analisa o novo comando syspurpose e registra o propósito pretendido do sistema durante a instalação automatizada e parcialmente automatizada. As informações são então passadas ao programa de instalação, salvas no sistema recém-instalado e disponíveis para o Gerente de Assinaturas ao assinar o sistema.

No Red Hat Enterprise Linux 8, o programa de instalação foi estendido para lidar com todas as características modulares. Os Kickstart scripts podem agora habilitar combinações de módulos e fluxos, instalar perfis de módulos e instalar pacotes modulares.

O comando auth ou authconfig Kickstart é depreciado no Red Hat Enterprise Linux 8 porque a ferramenta e o pacote authconfig foram removidos.

Da mesma forma que authconfig comandos emitidos na linha de comando, authconfig comandos em Kickstart scripts agora usam a ferramenta authselect-compat para executar a nova ferramenta authselect. Para uma descrição desta camada de compatibilidade e de seus problemas conhecidos, consulte a página do manual authselect-migration(7). O programa de instalação detectará automaticamente o uso dos comandos depreciados e instalará no sistema o pacote authselect-compat para fornecer a camada de compatibilidade.

O sistema de arquivo Btrfs não é mais suportado no Red Hat Enterprise Linux 8. Como resultado, a Interface Gráfica do Usuário (GUI) e os comandos Kickstart não suportam mais o Btrfs.

Se você estiver usando arquivos Kickstart de lançamentos anteriores da RHEL, consulte a seção Repositories do Considerations in adopting RHEL 8 documento para mais informações sobre os repositórios Red Hat Enterprise Linux 8 BaseOS e AppStream.

Os seguintes comandos e opções de Kickstart foram depreciados no Red Hat Enterprise Linux 8.

Onde apenas opções específicas são listadas, o comando base e suas outras opções ainda estão disponíveis e não são depreciadas.

Com exceção do comando auth ou authconfig, o uso dos comandos nos arquivos Kickstart imprime um aviso nos logs.

Você pode transformar os avisos de comando depreciados em erros com a opção de inicialização inst.ksstrict, exceto para o comando auth ou authconfig.

Os seguintes comandos e opções de Kickstart foram completamente removidos no Red Hat Enterprise Linux 8. O uso deles nos arquivos Kickstart causará um erro.

Onde apenas opções e valores específicos são listados, o comando base e suas outras opções ainda estão disponíveis e não são removidos.

Os seguintes comandos e opções foram adicionados no Red Hat Enterprise Linux 8.2.

Os seguintes comandos e opções foram adicionados no Red Hat Enterprise Linux 8.

A ferramenta Image Builder permite que os usuários criem imagens RHEL personalizadas. A partir do Red Hat Enterprise Linux 8.3, o Image Builder é executado como um serviço de sistema osbuild-composer pacote.

Com o Image Builder, os usuários podem criar imagens personalizadas do sistema que incluem pacotes adicionais. A funcionalidade do Image Builder pode ser acessada através dele:

Os formatos de saída do Image Builder incluem, entre outros:

Para saber mais sobre o Image Builder, veja o título da documentação Composição de uma imagem personalizada do sistema RHEL.

YUM v4 tem as seguintes vantagens em relação ao anterior YUM v3 utilizado no RHEL 7:

Para informações detalhadas sobre as diferenças entre a nova ferramenta YUM v4 e a versão anterior YUM v3 da RHEL 7, veja Mudanças no DNF CLI em comparação com o YUM.

Instalação de software

YUM v4 é compatível com YUM v3 ao usar da linha de comando, editar ou criar arquivos de configuração.

Para instalar o software, você pode usar o comando yum e suas opções particulares da mesma forma que no RHEL 7.

Veja informações mais detalhadas sobre a instalação de software com yum.

Disponibilidade de plug-ins

O legado YUM v3 plug-ins são incompatíveis com a nova versão de YUM v4. Os plug-ins e utilitários selecionados foram portados para o novo DNF back end, e podem ser instalados com os mesmos nomes que no RHEL 7. Eles também fornecem links simbólicos de compatibilidade, para que os binários, arquivos de configuração e diretórios possam ser encontrados nos locais habituais.

Caso um plug-in não esteja mais incluído, ou um substituto não atenda a uma necessidade de usabilidade, por favor entre em contato com o Suporte da Red Hat para solicitar um Aperfeiçoamento de Recursos conforme descrito em Como eu abro e administro um caso de suporte no Portal do Cliente?

Para mais informações, consulte Interface Plugin.

Disponibilidade de APIs

Note que o API Python API legado fornecido por YUM v3 não está mais disponível. Os usuários são aconselhados a migrar seus plug-ins e scripts para a nova API fornecida por YUM v4 (DNF Python API), que é estável e totalmente suportada. O projeto upstream documenta o novo DNF Python API - veja o DNF API Reference.

Os APIs Libdnf e Hawkey (ambos C e Python) devem ser considerados instáveis, e provavelmente mudarão durante o ciclo de vida do RHEL 8.

Esta seção resume as mudanças nas opções dos arquivos de configuração entre o RHEL 7 e o RHEL 8 para os arquivos /etc/yum.conf e /etc/yum.repos.d/*.repo.

Algumas das características do YUM v3 podem ter um comportamento diferente em YUM v4. Se qualquer mudança desse tipo impactar negativamente seus fluxos de trabalho, favor abrir um caso com o Suporte Red Hat, conforme descrito em Como abro e administro um caso de suporte no Portal do Cliente?

[…​]
package-1.2    repo1
package-1.2    repo2
[…​]

[…​]
package-1.2    repo1
[…​]

Esta seção resume as mudanças nos arquivos de histórico de transações entre a RHEL 7 e a RHEL 8.

Na RHEL 7, o arquivo /var/log/yum.log armazena:

No RHEL 8, não há um equivalente direto ao arquivo /var/log/yum.log. Para exibir as informações sobre as transações, incluindo o PackageKit e microdnf, use o comando yum history.

Alternativamente, você pode pesquisar o arquivo /var/log/dnf.rpm.log, mas este arquivo de log não inclui as transações do PackageKit e microdnf, e tem uma rotação de log que fornece a remoção periódica das informações armazenadas.

A RHEL 7 suportou duas implementações do protocolo NTP ntp e chrony.

No RHEL 8, o protocolo NTP é implementado apenas pelo daemon chronyd, fornecido pelo pacote chrony.

O daemon ntp não está mais disponível. Se você usou ntp em seu sistema RHEL 7, talvez você precise migrar para chrony.

Possíveis substituições para os anteriores ntp características que não são suportadas por chrony estão documentados em Alcançar alguns ambientes anteriormente suportados pela ntp em chrony.

chrony é uma implementação do NTP, que funciona bem em uma ampla gama de condições, incluindo conexões de rede intermitentes, redes muito congestionadas, temperaturas variáveis (os relógios comuns de computador são sensíveis à temperatura), e sistemas que não funcionam continuamente, ou funcionam em uma máquina virtual.

Você pode usar chrony:

Para mais informações sobre chronyver Configuração das configurações básicas do sistema.

Para mais informações sobre como configurar NTP usando o chrony veja Configurando as configurações básicas do sistema.

O Print Settings ferramenta de configuração, que era usada no RHEL 7, não está mais disponível.

Para realizar várias tarefas relacionadas à impressão, você pode escolher uma das seguintes ferramentas:

Para mais informações sobre as ferramentas de configuração de impressão no RHEL 8, consulte Implantação de diferentes tipos de servidores.

A CUPS fornece três tipos de troncos:

No RHEL 8, os logs não são mais armazenados em arquivos específicos dentro do diretório /var/log/cups, que foi usado no RHEL 7. Em vez disso, todos os três tipos são registrados centralmente em sistema-jornald junto com os logs de outros programas.

Para mais informações sobre como usar os logs CUPS no RHEL 8, consulte Implantação de diferentes tipos de servidores.

Para mais informações sobre como configurar a impressão no RHEL 8, consulte Implantação de diferentes tipos de servidores.

No RHEL 8, o perfil Tuned recomendado, reportado pelo comando tuned-adm recommend, é selecionado com base nas seguintes regras:

Observe que a primeira regra que combina entra em vigor.

Crypto-policies é um componente do Red Hat Enterprise Linux 8, que configura os subsistemas criptográficos centrais, cobrindo os protocolos TLS, IPsec, DNSSEC, Kerberos e a suíte OpenSSH. Ele fornece um pequeno conjunto de políticas, que o administrador pode selecionar usando o comando update-crypto-policies.

A política criptográfica do sistema DEFAULT oferece configurações seguras para os modelos de ameaça atuais. Ela permite os protocolos TLS 1.2 e 1.3, assim como os protocolos IKEv2 e SSH2. As chaves RSA e os parâmetros Diffie-Hellman são aceitos se forem maiores que 2047 bits.

Veja o artigo Segurança consistente por políticas criptográficas no Red Hat Enterprise Linux 8 no Blog da Red Hat e na página de manual update-crypto-policies(8) para mais informações.

A lista a seguir contém conjuntos de cifras e protocolos removidos das bibliotecas criptográficas centrais no RHEL 8. Eles não estão presentes nas fontes, ou seu suporte é desativado durante a construção, de modo que as aplicações não podem usá-los.

Os seguintes conjuntos de cifras e protocolos são desativados em todos os níveis da política criptográfica. Eles só podem ser habilitados através de uma configuração explícita de aplicações individuais.

As políticas criptográficas de todo o sistema contêm um nível de política que permite a auto-verificação dos módulos criptográficos de acordo com os requisitos da Publicação 140-2 do Federal Information Processing Standard (FIPS). A ferramenta fips-mode-setup que habilita ou desabilita o modo FIPS internamente usa o nível de política criptográfica em todo o sistema FIPS.

Para mudar o sistema para o modo FIPS no RHEL 8, digite o seguinte comando e reinicie seu sistema:

# fips-mode-setup --enable

Consulte a página de manual fips-mode-setup(8) para mais informações.

Os protocolos TLS 1.0 e TLS 1.1 estão desabilitados no nível da política criptográfica do sistema DEFAULT. Se seu cenário, por exemplo, uma aplicação de videoconferência no navegador Firefox, exigir o uso dos protocolos depreciados, mude a política de criptografia de todo o sistema para o nível LEGACY:

# update-crypto-policies --set LEGACY

Para maiores informações, veja o artigo da Base de Conhecimento de criptografia forte no RHEL 8 e a depreciação de algoritmos criptográficos fracos no Portal do Cliente da Red Hat e na página de manual update-crypto-policies(8).

Esta atualização permite a Segurança da Camada de Transporte (TLS) 1.3 por padrão em todas as principais bibliotecas de criptografia back-end. Isto permite baixa latência em toda a camada de comunicação do sistema operacional e aumenta a privacidade e segurança das aplicações, aproveitando novos algoritmos, como RSA-PSS ou X25519.

O Algoritmo de Assinatura Digital (DSA) é considerado depreciado no Red Hat Enterprise Linux 8. Os mecanismos de autenticação que dependem das chaves DSA não funcionam na configuração default. Note que os clientes OpenSSH não aceitam chaves de host DSA, mesmo no nível da política de criptografia do sistema LEGACY.

A Camada de Segurança de Transporte (TLS) versão 1.2 e anterior permite iniciar uma negociação com uma mensagem Client Hello formatada de forma retrocompatível com a Camada de Tomadas Seguras (SSL) versão 2 do protocolo. O suporte a este recurso na biblioteca Network Security Services (NSS) foi depreciado e está desativado por padrão.

As aplicações que requerem suporte para este recurso precisam usar o novo SSL_ENABLE_V2_COMPATIBLE_HELLO API para habilitá-lo. O suporte a este recurso pode ser removido completamente em futuros lançamentos do Red Hat Enterprise Linux 8.

As bibliotecas dos Network Security Services (NSS) agora usam o formato de arquivo SQL para o banco de dados de confiança por padrão. O formato de arquivo DBM, que era usado como formato padrão de banco de dados em versões anteriores, não suporta acesso simultâneo ao mesmo banco de dados por vários processos e tem sido depreciado no upstream. Como resultado, aplicações que usam o banco de dados de confiança NSS para armazenar chaves, certificados e informações de revogação agora criam bancos de dados no formato SQL por padrão. Tentativas de criar bancos de dados no formato DBM antigo falham. Os bancos de dados DBM existentes são abertos em modo somente leitura, e são automaticamente convertidos para o formato SQL. Note que o NSS suporta o formato de arquivo SQL desde o Red Hat Enterprise Linux 6.

Os pacotes openssh foram atualizados para a versão upstream 7.8p1. Mudanças notáveis incluem:

Esta mudança introduz libssh como um componente criptográfico central no Red Hat Enterprise Linux 8. A biblioteca libssh implementa o protocolo Secure SHell (SSH).

Note que libssh não está de acordo com a política de criptografia do sistema.

A obsoleta biblioteca libssh2 perde recursos, tais como suporte para curvas elípticas ou Interface de Programa de Aplicação de Serviços Genéricos de Segurança (GSSAPI), e foi removida da RHEL 8 em favor de libssh

Os arquivos de configuração nos pacotes rsyslog agora usam o formato não legado por padrão. O formato legado ainda pode ser usado, embora a mistura de declarações de configuração atual e legado tenha várias restrições. As configurações realizadas a partir de versões anteriores da RHEL devem ser revisadas. Consulte a página de manual rsyslog.conf(5) para mais informações.

Para evitar a duplicação de registros que poderiam aparecer quando journald rotacionou seus arquivos, a opção imjournal foi adicionada. Note que o uso desta opção pode afetar o desempenho.

Note que o sistema com rsyslog pode ser configurado para proporcionar melhor desempenho conforme descrito no artigo Configuring system logging without journald or with minimized journald use Knowledgebase article.

A configuração padrão do ambiente de registro pode consumir 4 GB de memória ou até mais e os ajustes dos valores-limite de taxa são complexos quando systemd-journald está rodando com rsyslog.

Veja os efeitos negativos da configuração de registro padrão da RHEL sobre o desempenho e suas mitigações Artigo da Base de Conhecimento para mais informações.

Esta atualização fornece a biblioteca compartilhada API do OpenSCAP que foi consolidada. 63 símbolos foram removidos, 14 foram adicionados e 4 têm uma assinatura atualizada. Os símbolos removidos no OpenSCAP 1.3.0 incluem:

No RHEL 8.2, foi introduzido um novo utilitário para segurança e verificação de conformidade de contêineres. A ferramenta oscap-podman fornece um equivalente do utilitário oscap-docker que serve para escaneamento de imagens de contêineres e contêineres no RHEL 7.

Para mais informações, consulte a seção Scanning container e imagens de container para ver as vulnerabilidades.

Com esta atualização, a funcionalidade de audispd foi movida para auditd. Como resultado, audispd opções de configuração agora fazem parte de auditd.conf. Além disso, o diretório plugins.d foi movido para /etc/audit. O status atual de auditd e seus plug-ins podem agora ser verificados executando o comando service auditd state.

A política da RHEL 8 SELinux fornece os seguintes tipos de portas adicionais:

Além disso, as definições dos tipos de portos dns_port_t e ephemeral_port_t foram alteradas, e o tipo de porto gluster_port_t foi removido.

Os comandos useradd e groupadd não permitem nomes de usuários e grupos que consistem puramente de caracteres numéricos. A razão para não permitir tais nomes é que isto pode confundir potencialmente muitas ferramentas que funcionam com nomes de usuários e grupos e ids de usuários e grupos (que são números). Observe que os nomes totalmente numéricos de usuários e grupos são depreciados no Red Hat Enterprise Linux 7 e seu suporte é completamente removido no Red Hat Enterprise Linux 8.

Devido à natureza dinâmica dos arquivos de dispositivos tty nos sistemas Linux modernos, o módulo securetty PAM foi desativado por padrão e o arquivo de configuração /etc/securetty não está mais incluído no RHEL. Como /etc/securetty listou muitos dispositivos possíveis para que o efeito prático na maioria dos casos fosse permitir por padrão, esta mudança tem apenas um impacto menor. Entretanto, se você usar uma configuração mais restritiva, você precisa adicionar uma linha que permita o módulo pam_securetty.so aos arquivos apropriados no diretório /etc/pam.d, e criar um novo arquivo /etc/securetty.

O pino Clevis HTTP foi removido do RHEL 8, e o sub-comando clevis encrypt http não está mais disponível.

Os scripts de rede são depreciados no Red Hat Enterprise Linux 8 e não são mais fornecidos por default. A instalação básica fornece uma nova versão dos scripts ifup e ifdown que chamam NetworkManager através do nmcli ferramenta. No Red Hat Enterprise Linux 8, para executar os scripts ifup e ifdown, NetworkManager deve estar funcionando.

~]# yum instalar os roteiros de rede

No Red Hat Enterprise Linux 8, NetworkManager permite configurar o número de funções virtuais (VF) para interfaces que suportam virtualização de E/S de raiz única (SR-IOV). Além disso, NetworkManager permite configurar alguns atributos das VFs, como o endereço MAC, VLAN, a configuração spoof checking e bitrates permitidos. Observe que todas as propriedades relacionadas à SR-IOV estão disponíveis na configuração de conexão sriov. Para mais detalhes, consulte a página de manual nm-settings(5).

Anteriormente, era possível restringir uma conexão a uma determinada interface usando apenas uma correspondência exata no nome da interface. Com esta atualização, as conexões têm uma nova propriedade match.interface-name que suporta wildcards. Esta atualização permite aos usuários escolher a interface para uma conexão de uma forma mais flexível usando um padrão curinga.

Com este aprimoramento, NetworkManager suporta a configuração de recursos offload ethtool, e os usuários não precisam mais usar scripts init ou um script do despachante NetworkManager. Como resultado, os usuários podem agora configurar o recurso de offload como parte do perfil de conexão usando um dos seguintes métodos:

Note que este recurso não é atualmente suportado em interfaces gráficas e no utilitário nmtui.

NetworkManager apóia os plug-ins internal e dhclient DHCP. Por default, NetworkManager no Red Hat Enterprise Linux (RHEL) 7 usa o dhclient e RHEL 8 o plug-in internal. Em certas situações, os plug-ins se comportam de forma diferente. Por exemplo, dhclient pode usar configurações adicionais especificadas no diretório /etc/dhcp/.

Se você atualizar de RHEL 7 para RHEL 8 e NetworkManager se comportar de forma diferente, adicione a seguinte configuração à seção [main] no arquivo /etc/NetworkManager/NetworkManager.conf para usar o plug-in dhclient:

[main]
dhcp=dhclient

O pacote NetworkManager-config-server só é instalado por padrão se você selecionar o ambiente base Server ou Server with GUI durante a configuração. Se você selecionou um ambiente diferente, use o comando yum install NetworkManager-config-server para instalar o pacote.

A estrutura nftables oferece facilidades de classificação de pacotes e é o sucessor designado para as ferramentas iptables, ip6tables, arptables, e ebtables. Ela oferece inúmeras melhorias em conveniência, características e desempenho em relação às ferramentas de filtragem de pacotes anteriores, mais notadamente:

Da mesma forma que iptables, nftables utiliza tabelas para o armazenamento de correntes. As cadeias contêm regras individuais para a realização de ações. A ferramenta nft substitui todas as ferramentas das estruturas anteriores de filtragem de pacotes. A biblioteca libnftables pode ser usada para interação de baixo nível com nftables Netlink API sobre a biblioteca libmnl.

As ferramentas iptables, ip6tables, ebtables e arptables são substituídas por ferramentas drop-in baseadas em nftables com o mesmo nome. Enquanto o comportamento externo é idêntico ao de suas contrapartes legadas, internamente eles usam nftables com módulos de kernel legados netfilter através de uma interface de compatibilidade onde for necessário.

O efeito dos módulos sobre o conjunto de regras nftables pode ser observado usando o comando nft list ruleset. Como estas ferramentas adicionam tabelas, correntes e regras ao conjunto de regras nftables, esteja ciente de que as operações do conjunto de regras nftables, como o comando nft flush ruleset, podem afetar os conjuntos de regras instalados usando os comandos herdados anteriormente separados.

Para identificar rapidamente qual variante da ferramenta está presente, as informações da versão foram atualizadas para incluir o nome do back-end. No RHEL 8, a ferramenta nftables baseada em iptables imprime a seguinte seqüência de versões:

$ iptables --version
iptables v1.8.0 (nf_tables)

Para comparação, as seguintes informações da versão são impressas se a ferramenta iptables estiver presente:

$ iptables --version
iptables v1.8.0 (legacy)

A funcionalidade da cadeia arptables FORWARD foi removida no Red Hat Enterprise Linux (RHEL) 8. Agora você pode usar a cadeia FORWARD da ferramenta ebtables adicionando as regras a ela.

No RHEL 8, o comando ebtables é fornecido pelo pacote iptables-ebtables, que contém uma reimplementação da ferramenta baseada em nftables. Esta ferramenta tem uma base de código diferente, e sua saída se desvia em aspectos que são negligenciáveis ou escolhas deliberadas de projeto.

Conseqüentemente, ao migrar seus scripts analisando alguma saída do ebtables, ajuste os scripts para refletir o seguinte:

Esta atualização acrescenta as ferramentas iptables-translate e ip6tables-translate para converter as regras existentes iptables ou ip6tables nas equivalentes para nftables. Note que algumas extensões carecem de suporte de tradução. Se tal extensão existir, a ferramenta imprime a regra não traduzida prefixada com o sinal #. Por exemplo, a regra não traduzida:

| % iptables-translate -A INPUT -j CHECKSUM --checksum-fill
| nft # -A INPUT -j CHECKSUM --checksum-fill

Além disso, os usuários podem usar as ferramentas iptables-restore-translate e ip6tables-restore-translate para traduzir um lixão de regras. Note que antes disso, os usuários podem usar os comandos iptables-save ou ip6tables-save para imprimir um dump das regras atuais. Por exemplo:

| % sudo iptables-save >/tmp/iptables.dump
| % iptables-restore-translate -f /tmp/iptables.dump
| # Translated by iptables-restore-translate v1.8.0 on Wed Oct 17 17:00:13 2018
| add table ip nat
| ...

No Red Hat Enterprise Linux (RHEL) 8, o pacote wpa_supplicant é construído com CONFIG_DEBUG_SYSLOG habilitado. Isto permite a leitura do log wpa_supplicant usando o utilitário journalctl ao invés de verificar o conteúdo do arquivo /var/log/wpa_supplicant.log.

O pacote wpa_supplicant não suporta extensões sem fio. Quando um usuário está tentando usar wext como argumento de linha de comando, ou tentando usá-lo em adaptadores antigos que só suportam extensões sem fio, não será capaz de executar o daemon wpa_supplicant.

Um novo algoritmo de controle de congestionamento TCP, largura de banda de gargalo e tempo de ida e volta (BBR) é agora suportado no Red Hat Enterprise Linux (RHEL) 8. BBR tenta determinar a largura de banda do link de gargalo e o tempo de viagem de ida e volta (RTT). A maioria dos algoritmos de congestionamento é baseada na perda de pacotes (incluindo CUBIC, o algoritmo padrão de controle de congestionamento TCP do Linux), que tem problemas em links de alta produtividade. O BBR não reage diretamente a eventos de perda, ele ajusta a taxa de pacotes TCP para corresponder com a largura de banda disponível. Os usuários do TCP BBR devem mudar para a configuração de fila de espera fq em todas as interfaces envolvidas.

Note que os usuários devem usar explicitamente fq e não fq_codel.

Para mais detalhes, consulte a página de manual tc-fq.

No Red Hat Enterprise Linux 8.0, o kernel inclui suporte a drivers de rede virtual IPVLAN. Com esta atualização, as placas de interface de rede virtual IPVLAN (NICs) permitem a conectividade de rede para múltiplos containers expondo um único endereço MAC à rede local. Isto permite que um único host tenha muitos containers superando a possível limitação do número de endereços MAC suportados pelo equipamento de rede peer.

O firmware de certos adaptadores de rede não suporta totalmente o padrão 802.1ad, que também é chamado de Q-in-Q ou redes locais virtuais empilhadas (VLANs). Contate seu fornecedor de hardware para saber como verificar se seu adaptador de rede utiliza um firmware que suporta o padrão 802.1ad e como atualizar o firmware. Como resultado, com o firmware correto, configurar as VLANs empilhadas na RHEL 8.0 funcionam como esperado.

o mecanismoControl group v2 é um grupo de controle unificado de hierarquia. Control group v2 organiza os processos hierarquicamente e distribui os recursos do sistema ao longo da hierarquia de forma controlada e configurável.

Ao contrário da versão anterior, control group v2 tem apenas uma única hierarquia. Esta hierarquia única permite que o kernel Linux o faça:

Control group v2 suporta numerosos controladores:

As informações acima foram baseadas em cgroups-v2 online documentation. Você pode consultar o mesmo link para obter mais informações sobre determinados controladores control group v2.

Com esta atualização, está disponível suporte para endereçamento físico de 52 bits (PA) para a arquitetura ARM de 64 bits. Isto proporciona um espaço de endereçamento físico maior do que o anterior PA de 48 bits.

Com o Red Hat Enterprise Linux 7, o barramento de memória existente tinha 48/46 bits de capacidade de endereçamento de memória virtual/física, e o kernel Linux implementou 4 níveis de tabelas de páginas para gerenciar esses endereços virtuais para endereços físicos. A linha de endereçamento do barramento físico colocou a capacidade limite superior de memória física em 64 TB.

Estes limites foram estendidos para 57/52 bits de endereçamento de memória virtual/física com 128 PiB de espaço de endereço virtual (64PB usuário/64PB kernel) e 4 PB de capacidade de memória física.

Com a faixa de endereços ampliada, o gerenciamento de memória no Red Hat Enterprise Linux 8 adiciona suporte para a implementação da tabela de 5 níveis de página, para poder lidar com a faixa de endereços ampliada. Por default, o RHEL8 desabilitará o suporte à tabela de 5 níveis de página, mesmo em sistemas que suportam este recurso. Isto é devido a uma degradação potencial de desempenho ao usar tabelas de 5 níveis de páginas se não for necessário um espaço de endereço físico ou virtual estendido. Um argumento de inicialização permitirá que sistemas com hardware que suporta este recurso o utilizem.

O utilitário bpftool que serve para inspeção e manipulação simples de programas e mapas baseados na Filtragem de Pacotes Berkeley estendida (eBPF) foi adicionado ao kernel Linux. bpftool é uma parte da árvore de fontes do kernel, e é fornecido pelo pacote bpftool, que está incluído como um sub-pacote do pacote kernel.

O recurso extended Berkeley Packet Filtering (eBPF) está disponível como uma Technology Preview tanto para rede quanto para rastreamento. eBPF permite ao espaço do usuário anexar programas personalizados em uma variedade de pontos (soquetes, pontos de rastreamento, recepção de pacotes) para receber e processar dados. O recurso inclui uma nova chamada de sistema bpf(), que suporta a criação de vários tipos de mapas, e também a inserção de vários tipos de programas no kernel. Note que o syscall bpf() pode ser usado com sucesso somente por um usuário com a capacidade CAP_SYS_ADMIN, como um usuário root. Veja a página de manual bpf(2) para mais informações.

BPF Compiler Collection (BCC) é um kit de ferramentas de espaço do usuário para criar programas eficientes de rastreamento e manipulação de kernel, disponível como Technology Preview no Red Hat Enterprise Linux 8. BCC fornece ferramentas para análise de E/S, rede e monitoramento de sistemas operacionais Linux usando o extended Berkeley Packet Filtering (eBPF).

A especificação do carregador de inicialização (BLS) define um esquema e um formato de arquivo para gerenciar as configurações do carregador de inicialização para cada opção de inicialização em um diretório drop-in. Não há necessidade de manipular os arquivos de configuração individuais do carregador de inicialização. Esta premissa é particularmente relevante no Red Hat Enterprise Linux 8 porque nem todas as arquiteturas usam o mesmo bootloader:

Cada bootloader tem um arquivo de configuração e formato diferente que deve ser modificado quando um novo kernel é instalado ou removido. Nas versões anteriores do Red Hat Enterprise Linux, o componente que permitia este trabalho era o utilitário grubby. No entanto, para o Red Hat Enterprise Linux 8, a configuração do carregador de inicialização foi padronizada pela implementação do formato de arquivo BLS, onde grubby funciona como um invólucro fino em torno das operações BLS.

Anteriormente, o serviço kdump começou tarde demais para registrar as falhas de kernel que ocorreram nos estágios iniciais do processo de inicialização. Como resultado, as informações sobre o travamento, juntamente com uma chance de solução de problemas, foram perdidas.

Para resolver este problema, a RHEL 8 introduziu um suporte em early kdump. Para saber mais sobre este mecanismo, consulte o arquivo /usr/share/doc/kexec-tools/early-kdump-howto.txt. Veja também O que é suporte inicial do kdump e como eu o configuro?

O suporte para os seguintes drivers de dispositivos foi removido no RHEL 8:

O suporte para os adaptadores listados abaixo foi removido no RHEL 8. O suporte para outros adaptadores além dos listados dos drivers mencionados permanece inalterado.

Os PCI IDs estão no formato de vendor:device:subvendor:subdevice. Se a entrada subdevice ou subvendor:subdevice não estiver listada, os dispositivos com quaisquer valores de tais entradas em falta foram removidos.

Para verificar as IDs PCI do hardware em seu sistema, execute o comando lspci -nn.

O sistema de arquivo Btrfs foi removido no Red Hat Enterprise Linux 8, o que inclui os seguintes componentes:

Você não pode mais criar, montar ou instalar em sistemas de arquivo Btrfs no Red Hat Enterprise Linux 8. O instalador Anaconda e os comandos Kickstart não suportam mais o Btrfs.

O sistema de arquivos XFS suporta a funcionalidade compartilhada de cópia-em-escrita de dados. Esta funcionalidade permite que dois ou mais arquivos compartilhem um conjunto comum de blocos de dados. Quando um dos arquivos que compartilham blocos comuns muda, o XFS quebra o link para blocos comuns e cria um novo arquivo. Isto é similar à funcionalidade copy-on-write (COW) encontrada em outros sistemas de arquivos.

As extensões de dados compartilhados por meio de cópia-em-escrita são:

Os utilitários de espaço do usuário podem usar extensões de dados compartilhadas de cópia-em-escrita para:

Esta funcionalidade também é utilizada pelos subsistemas de kernel como Overlayfs e NFS para uma operação mais eficiente.

As extensões de dados compartilhados de cópia-em-escrita são agora ativadas por padrão ao criar um sistema de arquivos XFS, começando com a versão do pacote xfsprogs 4.17.0-2.el8 .

Observe que os dispositivos de Acesso Direto (DAX) atualmente não suportam XFS com extensões de dados compartilhados de cópia-em-escrita. Para criar um sistema de arquivo XFS sem este recurso, use o seguinte comando:

# mkfs.xfs -m reflink=0 block-device

O Red Hat Enterprise Linux 7 pode montar sistemas de arquivo XFS com extensões de dados compartilhadas de cópia-em-escrita somente no modo somente-leitura.

Com esta atualização, os metadados ext4 são protegidos por checksums. Isto permite que o sistema de arquivos reconheça os metadados corruptos, o que evita danos e aumenta a resiliência do sistema de arquivos.

No Red Hat Enterprise Linux 8.0, a configuração do NFS passou do arquivo de configuração /etc/sysconfig/nfs, que foi usado no Red Hat Enterprise Linux 7, para /etc/nfs.conf.

O arquivo /etc/nfs.conf usa uma sintaxe diferente. O Red Hat Enterprise Linux 8 tenta converter automaticamente todas as opções de /etc/sysconfig/nfs para /etc/nfs.conf ao atualizar a partir do Red Hat Enterprise Linux 7.

Ambos os arquivos de configuração são suportados no Red Hat Enterprise Linux 7. A Red Hat recomenda que você use o novo arquivo /etc/nfs.conf para tornar a configuração NFS em todas as versões do Red Hat Enterprise Linux compatível com sistemas de configuração automatizada.

Além disso, os seguintes aliases de serviço NFS foram removidos e substituídos por seus nomes a montante:

BOOM é um gerenciador de inicialização para sistemas Linux que utilizam carregadores de inicialização que suportam a especificação BootLoader para configuração de entrada de inicialização. Ele permite uma configuração de inicialização flexível e simplifica a criação de entradas de inicialização novas ou modificadas: por exemplo, para inicializar imagens instantâneas do sistema criado usando LVM.

BOOM não modifica a configuração existente do carregador de inicialização, e apenas insere entradas adicionais. A configuração existente é mantida, e qualquer integração de distribuição, como scripts de instalação e atualização do kernel, continua a funcionar como antes.

BOOM tem uma interface simplificada de linha de comando (CLI) e API que facilitam a tarefa de criar entradas de inicialização.

Stratis é um novo gerente de armazenamento local. Ele fornece sistemas de arquivos gerenciados em cima de pools de armazenamento com características adicionais para o usuário.

Stratis permite realizar mais facilmente tarefas de armazenamento como, por exemplo

Para administrar o armazenamento do Stratis, use o utilitário stratis, que se comunica com o serviço de fundo stratisd.

Stratis é fornecido como uma Pré-visualização Tecnológica.

Para mais informações, consulte a documentação do Stratis: Gerenciamento de armazenamento local em camadas com Stratis.

No RHEL 8, o formato LUKS versão 2 (LUKS2) substitui o formato antigo LUKS (LUKS1). O subsistema dm-crypt e a ferramenta cryptsetup usam agora o LUKS2 como o formato padrão para volumes criptografados. O LUKS2 fornece volumes criptografados com redundância de metadados e auto-recuperação no caso de um evento de corrupção parcial de metadados.

Devido ao layout flexível interno, LUKS2 é também um capacitador de características futuras. Ele suporta o desbloqueio automático através do token genérico de kernel-keyring construído em libcryptsetup que permite aos usuários desbloquear volumes LUKS2 usando uma senha armazenada no serviço de retenção de kernel-keyring.

Outras melhorias notáveis incluem:

Para mais detalhes, consulte as páginas de manual cryptsetup(8) e cryptsetup-reencrypt(8).

Os dispositivos de bloco agora usam o agendamento de múltiplas filas no Red Hat Enterprise Linux 8. Isto permite que o desempenho da camada de bloco seja bem dimensionado com drives de estado sólido rápido (SSDs) e sistemas multi-core.

O driver SCSI Multiqueue (scsi-mq) está agora habilitado por padrão, e o kernel boots com a opção scsi_mod.use_blk_mq=Y. Esta mudança é consistente com o kernel Linux upstream.

O Device Mapper Multipath (DM Multipath) requer que o driver scsi-mq esteja ativo.

O Virtual Data Optimizer (VDO) está agora disponível em todas as arquiteturas suportadas pela RHEL 8.

A funcionalidade de cache de leitura foi removida do Virtual Data Optimizer (VDO). O cache de leitura está sempre desabilitado nos volumes do VDO, e você não pode mais ativá-lo usando a opção --readCache do utilitário vdo.

A Red Hat pode reintroduzir o cache de leitura VDO em um lançamento posterior do Red Hat Enterprise Linux, usando uma implementação diferente.

O pacote dmraid foi removido do Red Hat Enterprise Linux 8. Os usuários que requerem suporte para hardware e software combinados RAID host bus adapters (HBA) devem usar o utilitário mdadm, que suporta software nativo RAID MD, o SNIA RAID Common Disk Data Format (DDF), e os formatos Intel® Matrix Storage Manager (IMSM).

Para mais informações, veja Seção 11.1.3.2, “Remoção do software FCoE”.

O serviço multipathd agora suporta a melhor detecção de caminhos marginais. Isto ajuda os dispositivos multicaminhos a evitar caminhos que podem falhar repetidamente, e melhora o desempenho. Os caminhos marginais são caminhos com erros de E/S persistentes mas intermitentes.

As seguintes opções no arquivo /etc/multipath.conf controlam o comportamento dos caminhos marginais:

DM Multipath desabilita um caminho e o testa com E/S repetidas para o tempo de amostragem configurado se:

Se o caminho tiver mais do que a taxa de erro configurado durante este teste, a DM Multipath o ignora durante o tempo de intervalo configurado, e então o retesta para ver se está funcionando bem o suficiente para ser restabelecido.

Para mais informações, consulte a página de manual multipath.conf.

O arquivo /etc/multipath.conf agora inclui uma seção overrides que lhe permite definir um valor de configuração para todos os seus dispositivos. Estes atributos são usados pela DM Multipath para todos os dispositivos a menos que sejam sobrescritos pelos atributos especificados na seção multipaths do arquivo /etc/multipath.conf para os caminhos que contêm o dispositivo. Esta funcionalidade substitui o parâmetro all_devs da seção devices do arquivo de configuração, que não é mais suportado.

O tipo de transporte NVMe sobre Fibre Channel (NVMe/FC) agora é totalmente suportado em modo iniciador quando usado com Broadcom Emulex e Marvell Qlogic Fibre Channel 32Gbit adaptadores que apresentam suporte NVMe.

O NVMe sobre canal de fibra é um tipo adicional de transporte de tecido para o protocolo Nonvolatile Memory Express (NVMe), além do protocolo Remote Direct Memory Access (RDMA), que foi introduzido anteriormente no Red Hat Enterprise Linux.

Habilitação de NVMe/FC:

Restrições adicionais:

DIF/DIX é uma adição ao padrão SCSI. Ele permanece em Technology Preview para todos os HBAs e arrays de armazenamento, exceto para aqueles especificamente listados como suportados.

DIF/DIX aumenta o tamanho do bloco de disco de 512 bytes comumente usado de 512 para 520 bytes, adicionando o Campo de Integridade de Dados (DIF). O DIF armazena um valor de soma de controle para o bloco de dados que é calculado pelo Adaptador de Barramento Host (HBA) quando ocorre uma gravação. O dispositivo de armazenamento confirma então o checksum no recebimento e armazena tanto os dados quanto o checksum. Por outro lado, quando ocorre uma leitura, o checksum pode ser verificado pelo dispositivo de armazenamento, e pelo HBA receptor.

O pacote libstoragemgmt-netapp-plugin utilizado pela biblioteca libStorageMgmt foi removido. Ele não é mais suportado porque:

A LVM não usa mais clvmd (cluster lvm daemon) para o gerenciamento de dispositivos de armazenamento compartilhado. Em vez disso, a LVM agora usa lvmlockd (daemon lvm lock).

A LVM não usa mais o daemon lvmetad para cachar metadados, e sempre lerá metadados do disco. A leitura em disco LVM foi reduzida, o que reduz os benefícios do caching.

Anteriormente, a ativação automática dos volumes lógicos estava ligada indiretamente à configuração use_lvmetad no arquivo de configuração lvm.conf. A forma correta de desativar a auto-ativação continua a ser a configuração auto_activation_volume_list no arquivo lvm.conf.

O LVM não pode mais gerenciar dispositivos formatados com o GFS pool volume manager ou o formato`lvm1` metadados. se você criou seu volume lógico antes da introdução do Red Hat Enterprise Linux 4, então isto pode afetá-lo. Grupos de volume usando o formato lvm1 devem ser convertidos para o formato lvm2 usando o comando vgconvert.

A biblioteca lvm2app e as ligações Python da LVM, que foram fornecidas pelo pacote lvm2-python-libs, foram removidas. A Red Hat recomenda, ao invés disso, as seguintes soluções:

Você deve portar quaisquer aplicações usando as bibliotecas removidas e as ligações para o D-Bus API antes de atualizar para o Red Hat Enterprise Linux 8.

A característica de registro espelhado de volumes LVM espelhados foi removida. O Red Hat Enterprise Linux (RHEL) 8 não suporta mais a criação ou ativação de volumes LVM com um registro espelhado de espelho.

As substituições recomendadas são:

Subversion 1.10 introduz uma série de novas características desde a versão 1.7 distribuída na RHEL 7, bem como as seguintes alterações de compatibilidade:

Os administradores do sistema podem configurar o comando python não versionado, localizado em /usr/bin/python, usando o comando alternatives. Note que o pacote necessário, python3, python38, ou python2, precisa ser instalado antes de configurar o comando não versionado para a respectiva versão.

pathfix.py -pn -i %{__python3} PATH ...

O Red Hat Enterprise Linux 8 é distribuído com PHP 7.2. Esta versão introduz as seguintes mudanças principais sobre PHP 5.4, que está disponível no RHEL 7:

As seguintes extensões foram removidas:

Perl 5.26, distribuído com a RHEL 8, introduz as seguintes mudanças em relação à versão disponível na RHEL 7:

A RHEL 8 fornece Ruby 2.5, que introduz inúmeras novas características e melhorias em relação a Ruby 2.0.0, disponível na RHEL 7. As mudanças notáveis incluem:

RHEL 8 inclui o Empacotador Simplificado e o Gerador de Interface (SWIG) versão 3.0, que fornece inúmeras novas características, melhorias e correções de bugs sobre a versão 2.0 distribuída no RHEL 7. Mais notavelmente, o suporte ao padrão C 11 foi implementado. SWIG agora suporta também Go 1.6, PHP 7, Octave 4.2, e Python 3.5.

Node.js, uma plataforma de desenvolvimento de software para a construção de aplicações de rede rápidas e escaláveis na linguagem de programação JavaScript, é fornecida pela primeira vez na RHEL. Anteriormente, estava disponível apenas como uma Coleção de Software. A RHEL 8 fornece Node.js 10.

Tool command language (Tcl) é uma linguagem de programação dinâmica. O intérprete para esta linguagem, juntamente com a biblioteca C, é fornecido pelo pacote tcl.

Usando Tcl emparelhado com Tk (Tcl/Tk) permite a criação de aplicações GUI em várias plataformas Tk é fornecido pelo pacote tk.

Note que Tk pode se referir a qualquer um dos seguintes itens:

O Apache HTTP ServerEsta versão atualizada inclui várias novas características, mas mantém compatibilidade com a versão RHEL 7 no nível de configuração e Interface Binária de Aplicação (ABI) dos módulos externos.

As novas características incluem:

Outras mudanças notáveis incluem:

Para instruções sobre como implantar, consulte Configurando o servidor web Apache HTTP.

A RHEL 8 apresenta nginx 1.14, um servidor web e proxy que suporta HTTP e outros protocolos, com foco em alta concorrência, desempenho e baixo uso de memória. nginx estava anteriormente disponível apenas como uma Coleção de Software.

O servidor web nginx agora suporta o carregamento de chaves privadas TLS a partir de tokens de segurança de hardware diretamente dos módulos PKCS#11. Como resultado, uma configuração nginx pode usar PKCS#11 URLs para identificar a chave privada do TLS na diretiva ssl_certificate_key.

O servidor Apache Tomcat foi removido do Red Hat Enterprise Linux. O Apache Tomcat é um recipiente servlet para as tecnologias Java Servlet e JavaServer Pages (JSP). A Red Hat recomenda que os usuários que requerem um recipiente de servlet usem o Servidor Web JBoss.

Varnish Cache, um proxy HTTP reverso de alto desempenho, é fornecido pela primeira vez na RHEL. Anteriormente estava disponível apenas como uma Coleção de Software. Varnish Cache armazena arquivos ou fragmentos de arquivos em memória que são usados para reduzir o tempo de resposta e o consumo de largura de banda da rede em futuras solicitações equivalentes. O RHEL 8.0 é distribuído com Varnish Cache 6.0.

O RHEL 8.0 é distribuído com Squid 4.4, um servidor proxy de cache de alto desempenho para clientes web, suportando FTP, Gopher, e objetos de dados HTTP. Este lançamento fornece inúmeras novas características, melhorias e correções de bugs sobre a versão 3.5 disponível no RHEL 7.

As mudanças notáveis incluem:

MariaDB 10.3 oferece inúmeras novidades sobre a versão 5.5 distribuída na RHEL 7, como por exemplo:

Além disso, os novos pacotes mariadb-connector-c oferecem uma biblioteca comum de clientes para MySQL e MariaDB. Esta biblioteca é utilizável com qualquer versão dos servidores de banco de dados MySQL e MariaDB. Como resultado, o usuário é capaz de conectar um build de uma aplicação a qualquer um dos servidores MySQL e MariaDB distribuídos com a RHEL 8.

Outras mudanças notáveis incluem:

Veja também Usando o MariaDB no Red Hat Enterprise Linux 8.

A RHEL 8 é distribuída com MySQL 8.0, que fornece, por exemplo, os seguintes aperfeiçoamentos:

Além disso, o servidor MySQL 8.0 distribuído com o RHEL 8 está configurado para usar mysql_native_password como o plug-in de autenticação padrão porque as ferramentas e bibliotecas do cliente no RHEL 8 são incompatíveis com o método caching_sha2_password, que é usado por padrão na versão upstream MySQL 8.0.

Para alterar o plug-in de autenticação padrão para caching_sha2_password, edite o arquivo /etc/my.cnf.d/mysql-default-authentication-plugin.cnf da seguinte forma:

[mysqld]
default_authentication_plugin=caching_sha2_password

RHEL 8.0 fornece duas versões do servidor de banco de dados PostgreSQL, distribuído em dois fluxos do módulo postgresql: PostgreSQL 10 (o fluxo padrão) e PostgreSQL 9.6. O RHEL 7 inclui PostgreSQL versão 9.2.

As mudanças notáveis em PostgreSQL 9.6 são, por exemplo:

As principais melhorias em PostgreSQL 10 incluem:

Veja também Usando o PostgreSQL no Red Hat Enterprise Linux 8.

No Red Hat Enterprise Linux 8, o conjunto de ferramentas GCC é baseado na série de lançamentos GCC 8.2. Mudanças notáveis desde o Red Hat Enterprise Linux 7 incluem:

Esta seção descreve em detalhes as mudanças no GCC relacionadas à segurança e acrescentadas desde o lançamento do Red Hat Enterprise Linux

C ABI muda em std::string e std::list

A Interface Binária de Aplicação (ABI) das classes std::string e std::list da biblioteca libstdc mudou entre a RHEL 7 (GCC 4.8) e a RHEL 8 (GCC 8) para estar em conformidade com o padrão C 11. A biblioteca libstdc suporta tanto a antiga como a nova ABI, mas algumas outras bibliotecas do sistema C não suportam. Como conseqüência, as aplicações que se ligam dinamicamente a essas bibliotecas precisarão ser reconstruídas. Isto afeta todos os modos padrão C, incluindo o C 98. Também afeta as aplicações construídas com compiladores Red Hat Developer Toolset para RHEL 7, que mantiveram a antiga ABI para manter a compatibilidade com as bibliotecas do sistema.

O GCC não constrói mais código Ada, Go e Objective C/C

A capacidade de construir código no Ada (GNAT), GCC Go e Objective C/C languages foi removida do compilador GCC.

Para construir o código Go, use o Go Toolset em seu lugar.

Como ntpd foi depreciado em favor de chronyd no RHEL 8, os servidores IdM não são mais configurados como servidores Network Time Protocol (NTP) e são configurados apenas como clientes NTP. O papel do servidor IdM da RHEL 7 NTP Server também foi depreciado na RHEL 8.

O conjunto OpenLDAP nas versões anteriores do Red Hat Enterprise Linux (RHEL) utilizava o Mozilla Network Security Services (NSS) para fins criptográficos. Com o RHEL 8, o OpenSSL, que é suportado pela comunidade OpenLDAP, substitui o NSS. O OpenSSL não suporta bancos de dados NSS para armazenamento de certificados e chaves. Entretanto, ele ainda suporta arquivos de correio com privacidade aprimorada (PEM) que servem ao mesmo propósito.

No Red Hat Enterprise Linux (RHEL) 8, o pacote python-gssapi substituiu os pacotes Python Kerberos tais como python-krbV, python-kerberos, python-requests-kerberos, e python-urllib2_kerberos. Os benefícios notáveis incluem:

Os pacotes baseados em GSSAPI permitem o uso de outros mecanismos API de Serviços Genéricos de Segurança (GSSAPI) além do Kerberos, tais como o NT LAN Manager NTLM por razões de compatibilidade retroativa.

Esta atualização melhora a capacidade de manutenção e depuração da GSSAPI no RHEL 8.

No RHEL 8, a configuração padrão para a opção ad_gpo_access_control é enforcing, o que garante que as regras de controle de acesso baseadas nos Objetos de Políticas de Grupo do Active Directory (GPOs) sejam avaliadas e aplicadas.

Em contraste, o padrão para esta opção no RHEL 7 é permissive, que avalia mas não aplica regras de controle de acesso baseadas em GPO. Com o modo permissive, uma mensagem do syslog é gravada toda vez que um usuário seria negado o acesso por um GPO, mas esses usuários ainda têm permissão para fazer o login.

Para mais informações sobre os GPOs, consulte Aplicando o controle de acesso a objetos de política de grupo na RHEL e a entrada ad_gpo_access_control na página sssd-ad do Manual.

No RHEL 8, o utilitário authselect substitui o utilitário authconfig. authselect vem com uma abordagem mais segura ao gerenciamento de pilha PAM que torna as mudanças de configuração do PAM mais simples para os administradores do sistema. authselect pode ser usado para configurar métodos de autenticação como senhas, certificados, cartões inteligentes e impressão digital. authselect não configura os serviços necessários para entrar em domínios remotos. Esta tarefa é realizada por ferramentas especializadas, tais como realmd ou ipa-client-install.

No RHEL 8, o armazenamento padrão do cache de credenciais é o Kerberos Credential Manager (KCM), que é apoiado pelo deamon sssd-kcm. O KCM supera as limitações do KEYRING usado anteriormente, tais como sua dificuldade de uso em ambientes de contêineres por não ser espaçado por nomes, e para visualizar e gerenciar cotas.

Com esta atualização, o RHEL 8 contém um cache de credenciais que é mais adequado para ambientes de contêineres e que fornece uma base para a construção de mais recursos em lançamentos futuros.

Com esta atualização, a utilidade sssctl da Daemon System Security Services (SSSD) pode imprimir um relatório de controle de acesso para um domínio de Gerenciamento de Identidade (IdM). Este recurso atende à necessidade de certos ambientes de ver, por razões regulatórias, uma lista de usuários e grupos que podem acessar uma máquina cliente específica. Executando sssctl access-report domain_name em um cliente IdM imprime o subconjunto de regras de controle de acesso baseado em host (HBAC) no domínio IdM que se aplicam à máquina cliente.

Note que nenhum outro fornecedor além da IdM suporta esta característica.

No RHEL 8, o System Security Services Daemon (SSSD) atende usuários e grupos dos arquivos /etc/passwd e /etc/groups por padrão. O módulo sss nsswitch precede os arquivos do arquivo /etc/nsswitch.conf.

A vantagem de servir os usuários locais através do SSSD é que o módulo nss_sss tem um rápido memory-mapped cache que acelera as consultas ao Name Service Switch (NSS) em comparação com o acesso ao disco e a abertura dos arquivos em cada solicitação NSS. Anteriormente, o daemon de cache do Name Service (nscd) ajudava a acelerar o processo de acesso ao disco. Entretanto, usar nscd em paralelo com o SSSD é complicado, já que tanto o SSSD quanto o nscd usam seu próprio cache independente. Consequentemente, a utilização do nscd em configurações onde o SSSD também serve usuários de um domínio remoto, por exemplo LDAP ou Active Directory, pode causar um comportamento imprevisível.

Com esta atualização, a resolução dos usuários e grupos locais é mais rápida no RHEL 8. Note que o usuário root nunca é tratado pelo SSSD, portanto a resolução root não pode ser impactada por um possível bug no SSSD. Note também que se o SSSD não estiver rodando, o módulo nss_sss lida com a situação graciosamente, caindo de volta para nss_files para evitar problemas. Não é necessário configurar o SSSD de forma alguma, o domínio dos arquivos é adicionado automaticamente.

Por padrão, o System Security Services Daemon (SSSD) tenta detectar automaticamente um dispositivo para autenticação de cartão inteligente. Se houver vários dispositivos conectados, o SSSD seleciona o primeiro que ele detecta. Consequentemente, não é possível selecionar um determinado dispositivo, o que às vezes leva a falhas.

Com esta atualização, você pode configurar uma nova opção p11_uri para a seção [pam] do arquivo de configuração sssd.conf. Esta opção permite definir qual dispositivo é usado para autenticação de cartão inteligente.

Por exemplo, para selecionar um leitor com o slot id 2 detectado pelo módulo OpenSC PKCS#11, adicionar:

p11_uri = biblioteca-descrição=estrutura do smartcard OpenSC;slot-id=2

para a seção [pam] de sssd.conf.

Para mais detalhes, consulte a página man sssd.conf.

O componente sssd-secrets do System Security Services Daemon (SSSD) foi removido no Red Hat Enterprise Linux 8. Isto porque a Custodia, um provedor de serviços secretos, não está mais ativamente desenvolvida. Use outras ferramentas de Gerenciamento de Identidade para armazenar segredos, por exemplo, o Cofre de Gerenciamento de Identidade.