6.5.5. Trabalho em rede
O utilitário iptables agora solicita o carregamento de módulos para comandos que atualizam uma cadeia, independentemente da bandeira NLM_F_CREATE
Anteriormente, ao definir a política de uma cadeia, o utilitário iptables-nft gerava uma mensagem NEWCHAIN, mas não colocava a bandeira NLM_F_CREATE. Como conseqüência, o kernel RHEL 8 não carregou nenhum módulo e o comando de corrente de atualização resultante falhou se os módulos do kernel associados não foram carregados manualmente. Com esta atualização, o utilitário iptables-nft agora solicita o carregamento de módulos para todos os comandos que atualizam uma cadeia e os usuários são capazes de definir a política de uma cadeia usando o utilitário iptables-nft sem carregar manualmente os módulos associados.
(BZ#1812666)
O suporte para atualização de contadores de pacotes/bytes no kernel foi alterado incorretamente entre o RHEL 7 e o RHEL 8
Ao se referir a um comando ipset com contadores habilitados a partir de uma regra iptables, que especifica restrições adicionais sobre entradas ipset correspondentes, os contadores ipset são atualizados somente se todas as restrições adicionais corresponderem. Isto também é problemático com restrições --packets-gt ou --bytes-gt.
Como resultado, ao migrar um conjunto de regras iptables da RHEL 7 para a RHEL 8, as regras que envolvem as pesquisas ipset podem parar de funcionar e precisam ser ajustadas. Para contornar este problema, evite usar as opções --packets-gt ou --bytes-gt e substitua-as pelas opções --packets-lt ou --bytes-lt.
(BZ#1806882)
O descarregamento de programas XDP falha nos cartões de rede Netronome que utilizam o driver nfp
O driver nfp para cartões de rede Netronome contém um bug. Portanto, a descarga dos programas eXpress Data Path (XDP) falha se você usar tais cartões e carregar o programa XDP usando a função IFLA_XDP_EXPECTED_FD com a bandeira XDP_FLAGS_REPLACE. Por exemplo, este bug afeta os programas XDP que são carregados usando a biblioteca libxdp. Atualmente, não há nenhuma solução disponível para o problema.
O Anaconda não tem acesso à rede quando utiliza DHCP na opção de inicialização do ip
O disco RAM inicial(initrd) utiliza o NetworkManager para gerenciar a rede. O módulo NetworkManager dracut fornecido pelo arquivo ISO RHEL 8.3 assume incorretamente que o primeiro campo da opção ip nas opções de inicialização do Anaconda está sempre definido. Como conseqüência, se você usar DHCP e definir ip=:::::
Você tem as seguintes opções para contornar o problema:
Defina o primeiro campo na
opção ip` para `.(período):ip=::::
Note que este trabalho não funcionará em versões futuras da RHEL quando o problema tiver sido resolvido.
-
Recriar o arquivo
boot.isousando os últimos pacotes do repositório BaseOS que contém uma correção para o bug: .
# lorax '--product=Red Hat Enterprise Linux' --version=8.3 --release=8.3 \
--source=<URL_to_BaseOS_repository> \
--source=<URL_to_AppStream_repository> \
--nomacboot --buildarch=x86_64 '--volid=RHEL 8.3' <output_directory>. Note que a Red Hat não suporta arquivos ISO auto-criados.
Como resultado, a RHEL recupera um endereço IP do servidor DHCP, e o acesso à rede está disponível no Anaconda.
(BZ#1902791)
