Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Guia de Planejamento de Migração

Red Hat Enterprise Linux 6

Migrar para o Red Hat Enterprise Linux 6

Edição 6.1

Logo

Red Hat Inc.

Resumo

Este guia documenta a migração de sistemas rodando o Red Hat Enterprise Linux 5 para o Red Hat Enterprise Linux 6.

Capítulo 1. Introdução

O Guia de Planejamento de Migração documenta a migração de qualquer versão menor de uma instalação do Red Hat Enterprise Linux 5 para o Red Hat Enterprise Linux 6 destacando as mudanças chaves de comportamento a serem notadas quando fizer a migração.
Este guia tem o objetivo de aumentar a facilidade do uso do Red Hat Enterprise Linux 6 fornecendo diretrizes para as mudanças entre os produtos Red Hat Enterprise Linux 5 e Red Hat Enterprise Linux 6. Este guia não é entretanto desenvolvido para explicar todos os novos recursos: ele é focado nas mudanças nos comportamentos das aplicações ou componentes que eram parte do Red Hat Enterprise Linux 5 e foram alterados no Red Hat Enterprise Linux 6 ou das quais funcionalidades foram substituidas por outros pacotes.

1.1. Red Hat Enterprise Linux 6

O Red Hat Enterprise Linux é a plataforma líder de computação de código aberto. Ela é vendida através de subscrições, oferecendo valor contínuo e é certificada pelos principais fornecedores de hardware e software. Do desktop ao datacenter, o Enterprise Linux junta a inovação das tecnologias de código aberto e a estabilidade de uma plataforma de classe corporativa.
O Red Hat Enterprise Linux 6 é a próxima geração das suítes de sistemas operacionais da Red Hat, desenhados para computação corporativa de missão crítica e certificada pelos principais fornecedores de software e hardware. Este lançamento está disponível como um kit único nas seguintes arquiteturas:
  • i386
  • AMD64/Intel64
  • System z
  • IBM Power (64-bit)
Neste lançamento, a Red Hat traz melhorias para o servidor, desktop e toda experiência geral de código aberto da Red Hat. A seguir estão algumas das muitas melhorias e novos recursos que estão incluídos neste lançamento:
Gerenciamento de Energia

Melhorias no kernel através da pilha de aplicações para reduzir inicializações, medição do consumo de energia pelo PowerTOP, Gerenciamento de Energia (ASPM, ALPM), e ajuste de sistema adaptativo pelo Tuned.

Próxima Geração de Relacionamento de Rede

Suporte compreensivo a IPv6 (NFS, CIFS, suporte móvel [RFC 3775], suporte ISATAP), FCoE, iSCSI e um novo e melhorado mac80211 wireless stack.

Confiabilidade, Disponibilidade e Facilidade de manutenção

Melhorias em nível de sistema com colaborações da área para tirar o máximo das capacidades de hardware RAS e arquiteturas NUMA.

Gerenciamento e Controle Refinados

Agendador melhorado e melhor gerenciamento de recursos no kernel via Completely Fair Scheduler (CFS) e Control Groups (CG).

Sistemas de Arquivos Escaláveis

O ext4 é o sistema de arquivo padrão, e o xfs oferece solidez, escalabilidade e alto desempenho.

Virtualização

O KVM inclui melhorias no desempenho e novos recursos, o sVirt protege o host, VMs e dados de um visitante, o SRIOV e NPIV oferecem uso virtual de alto desempenho de dispositivos físicos e o libvirt potencializa a funcionalidade do controlador CG do kernel.

Melhorias na Segurança Corporativa

O SELinux inclui facilidade de uso melhorada, sandbox de aplicações e cobertura aumentada significativamente dos serviços do sistema, enquando o SSSD fornece acesso unificado para identificar e autenticar serviços tanto quanto cache para uso off line.

Suporte à Desenvolvimento e Período de Execução

O SystemTap (permite instrumentação de um kernel em execução sem recompilação), o ABRT (coleção simples de informações de bug), e melhorias ao GCC (versão 4.4.3), glibc (versão 2.11.1) e GDB (versão 7.0.1).

1.2. Compatibilidade de Aplicações

Este lançamento do Red Hat Enterprise Linux fornece dependências, então aplicações desenvolvidas para rodar em versões antigas do sistema operacional continuam a rodar com mínimo trabalho. Para esse efeito, versões antigas de bibliotecas chaves estão incluídas para preservar legacias nas interfaces que podem ter mudado entre esta versão e anteriores. Estas bibliotecas servem como dependências primariamente para aplicações escritas em C/C++.
Observe por favor que não é nessário re-testar ou re-certificar aplicações entre os lançamentos menores do Red Hat Enterprise Linux. A compatibilidade de políticas do Red Hat Enterprise Linux garantem que aplicações rodando em uma versão, continuarão rodando por todo tempo de vida desta versão. Por exemplo, aplicações certificadas para o Red Hat Enterprise Linux 6.0 serão totalmente compatíveis com o Red Hat Enterprise Linux 6.1 e assim por diante.
Consulte a seguinte tabela para detalhes sobre a compatibilidade dos pacotes:

Tabela 1.1. Bibliotecas de Compatibilidade

Pacote Descrição
compat-db A biblioteca de compatibilidade do banco de dados Berkeley DB. O Berkeley Database (Berkeley DB) é um conjunto de ferramentas programáticas que fornecem suporte à banco de dados incorporados para ambos tradicionais e aplicações cliente/servidor. Este pacote contém várias versões do Berkeley Database que foram incluídas em lançamentos anteriores.
compat-expat1 Expat é um interpretador de fluxo orientado. Este pacote fornece compatibilidade de bibliotecas com versões anteriores.
compat-glibc O glibc é a biblioteca C usada para chamadas do sistema e outras facilidades básicas. Este pacote fornece compatibilidade (e bibliotecas de tempo de execução) para a compilação de binários que requerem versões antigas do glibc e permitem roda-los neste lançamento do Red Hat Enterprise Linux.
compat-libf2c-34 Este pacote fornece versões anteriores das bibliotecas compartilhadas Fortran 77, que são necessárias para rodar programas Fortran 77 dinâmicamente ligados.
compat-libgcc-296 Contém a biblioteca 2.96 libgcc.a e arquivos de objetos de suporte para reter compatibilidade com versões anteriores do GCC.
compat-libgfortran-41 Este pacote inclui uma biblioteca de tempo de execução Fortran 95 para compatibilidade com as aplicações compiladas do GCC 4.1.x.
compat-libstdc++-295 Fornece compatibilidade com a biblioteca C++ GNU padrão versão 2.95.
compat-libstdc++-296 Fornece compatibilidade com a biblioteca C++ GNU padrão versão 2.96.
compat-libstdc++-33 Fornece compatibilidade com a biblioteca C++ GNU padrão versão 3.3
compat-libtermcap Este pacote fornece compatibilidade para programas baseados em termcap antigos.
compat-openldap O OpenLDAP é um conjunto de código aberto das aplicações LDAP (Lightweight Directory Access Protocol) e ferramentas de desenvolvimento. O pacote de compatibilidade openldap inclui versões antigas das bibliotecas compartilhadas OpenLDAP que podem ser requeridas por algumas aplicações.
openssl098e Este pacote fornece o OpenSSL 0.98e, que pode ser requerido para algumas aplicações SSL.

Capítulo 2. Instalação

Esta seção descreve as diferenças entre os procedimentos de instalação entre Red Hat Enterprise Linux 6 e Red Hat Enterprise Linux 5. Dependendo de qual versão do Red Hat Enterprise Linux 5 de que você está migrando, nem todas as opções e técnicas listadas aqui podem ser relevantes ao seu ambiente já que eles podem estar presentes no seu ambiente do Red Hat Enterprise Linux 5.

2.1. Opções do Kernel e do Boot

  • Você pode realizar um teste de memória antes de instalar o Red Hat Enterprise Linux, digitando memtest86 no prompt do boot:. Esta opção roda o software the teste de memória único Memtest86 no lugar do instalador de sistema Anaconda. Uma vez iniciado, o teste de memória Memtest86 faz loops continuamente até que a tecla Esc seja pressionada.
  • O parâmentro do kernel rdloaddriver é agora necessário para definir a ordem dos módulos de carregamento, em vez da opção antiga scsi_hostadapter.

2.2. Instalador Gráfico

Esta seção descreve quais comportamentos foram alterados no instalador gráfico.

2.2.1. Discos e Dispositivos

  • O uso do nome de dispositivo /dev/hdX está obsoleto na arquitetura i386 e x86_64 para drives IDE e foi mudado para /dev/sdX. Esta mudança não se aplica à arquitetura PPC.
  • Se você tiver dificuldades com a instalação em não detectar uma placa Smart Array, digite linux isa no prompt do instalador. Isso lhe permite selecionar manualmente a placa requerida.
  • Enquanto que drivers IDE antigos suportavam até 63 partições por dispositivo, os dispositivos SCSI são limitados para 15 partições por dispositivo. O Anaconda usa o novo driver libata da mesma maneira que o resto do Red Hat Enterprise Linux, então ele é incapaz de detectar mais de 15 partições em um disco IDE durante a instalação ou processo de atualização. Se você estiver atualizando um sistema com mais de 15 partições, você pode precisar migrar o disco para um Gerenciador de Volume Lógico (LVM).
  • Uma mudança na maneira que o kernel lida com os dispositivos de armazenamento significa que os nomes como /dev/hdX ou /dev/sdX podem ser diferentes dos valores usados em versão anteriores. O Anaconda resolve este problema utilizando rótulos de partição. Se os rótulos não estiverem presentes, então o Anaconda fornece um aviso de que as partições precisam ser rotuladas. Os sistemas que usam o LVM e o mapeador de dispositivos normalmente não requerem que sejam rotulados novamente.
  • O suporte é incluído para instalação para dispositivos de blocos criptografados, incluindo o sistema de arquivos root.
  • Nem todos os controladores IDE RAID são suportados. Se seu controlador RAID não é suportado pelo dmraid, você pode combinar os drives com matrizes RAID configurando o Software RAID do Linux. Para controladores suportados, configure as funções RAID na BIOS do computador.
  • A versão do GRUB incluída no Red Hat Enterprise Linux 6 agora suporta ext4, então o Anaconda agora permite que se use o sistema de arquivos ext4 em qualquer partição, incluindo a /boot e partições root.

2.2.2. Kickstart

Esta seção descreve quais comportamentos foram alterados nas instalações automatizadas (Kickstart).

2.2.2.1. Mudanças de Comportamentos

  • Anteriormente, um arquivo de Kickstart que não tinha uma linha network, supunha que o DHCP deveria ser usado para configurar a rede. Isto era inconsistente com o resto do Kickstart em que todas as outras linhas não presentes significavam que a instalação tinha de parar e esperar por uma entrada. Agora, não tendo a linha network significa que a instalação parará e esperará por uma entrada. Também, a opção --bootproto=query se tornou obsoleta. Se você quer continuar a usar o DHCP sem interrupção, adicione network --bootproto=dhcp ao seu arquivo Kickstart.
  • Tradicionalmente, discos são referidos através do Kickstart por um nome de dispositivo de nó (tal como sda). O kernel do linux passou para um método mais dinâmico onde nomes de dispositivos não são garantidos de serem consistentes após reinicializações, então isso pode complicar o uso de scripts de Kickstart. Para se ter uma nomeação de dispositivo estável, você pode usar qualquer ítem do /dev/disk no lugar de um nome de nó. Por exemplo, em vez de: 
    part / --fstype=ext4 --onpart=sda1
    Você pode usar uma entrada similar a uma das seguintes: 
    part / --fstype=ext4 --onpart=/dev/disk/by-path/pci-0000:00:05.0-scsi-0:0:0:0-part1
part / --fstype=ext4 --onpart=/dev/disk/by-id/ata-ST3160815AS_6RA0C882-part1
    Isto fornece uma maneira consistente de se referir a discos que faz mais sentido que somente o sda. Isto é especialmente útil em ambientes de armazenamento grandes.
  • Você pode também usar entradas do tipo shell para se referir aos discos. Isto é para se fazer mais fácil o uso dos comandos clearpart e ignoredisk em grandes ambientes de armazenamento. Por exemplo, em vez de: 
    ignoredisk --drives=sdaa,sdab,sdac
    Você pode usar uma entrada similar ao seguinte: 
    ignoredisk --drives=/dev/disk/by-path/pci-0000:00:05.0-scsi-*
  • O Kickstart parará com um erro mais vezes do que nas versões anteriores. Por exemplo, se você se referir a um disco que não existe, a instalação parará e lhe informará do erro. Isto foi desenvolvido para ajudar a detectar erros nos arquivos de Kickstart antes de se tornarem um problema maior. Como efeito colateral, os arquivos são desenvolvidos para serem genéricos para todas as configurações das diferentes máquinas podem falhar com mais frequencia. Isto deve ser lidado de uma maneira caso a caso.
  • O arquivo /tmp/netinfo usado para informações de rede Kickstart foi removido. O Anaconda usa o NetworkManager para configuração de interface e armazena a configuração nos arquivos ifcfg no /etc/sysconfig/network-scripts/. É possível usar esta nova localização como uma fonte de configurações de rede para os scripts %pre e %post.

2.2.2.2. Mudanças em Comandos

Esta seção lista as mudanças mais importantes nos comandos e suas opções:
  • A opção network --device pode agora se referir a dispositivos pelos endereços MAC em vez do nome do dispositivo. Similar aos discos, os nomes dos dispositivos de rede podem também mudar em reinicializações dependendo da ordem em que os dispositivos são examinados. Para permitir consistência na nomeação no Kickstart, você pode usar uma entrada similiar ao seguinte: 
    network --device=00:11:22:33:44:55 --bootproto=dhcp
  • Os comandos langsupport, key e mouse foram removidos. Qualquer uso destes comandos resultará em um erro de sintaxe. O comando monitor também está obsoleto.
    Em vez langsupport, adicione o grupo apropriado à seção %packages de seu arquivo Kickstart. Por exemplo, para incluir suporte ao Francês, adicione @french-support.
    Não há substituto para a opção key, já que uma chave de instalação não é mais requerida durante a instalação. Simplesmente remova esta opção de seu arquivo.
    Os comandos mouse e monitor não são requeridos já que o X pode detectar e configurar os ajustes automaticamente. Pela mesma razão, o comando xconfig --resolution= não é mais válido, e estes podem ser seguramente removidos do arquivo.
  • Os comandos part --start e part --end se tornaram obsoletos e não têm mais efeito. O Anaconda não permite mais criação de partições em limites específicos do setor. Se você precisar um nível mais rigoroso de particionamento, use uma ferramenta externa no %pre e então diga ao Anaconda para usar as partições existentes com o comando part --onpart. Senão, crie partições com um certo tamanho ou use grow.
  • Em vez de criar grupos manualmente no %post, você pode agora usar o comando group para cria-los. Por favor consulte a documentação completa do Kickstart para mais detalhes.
  • O algorítimo padrão autopart foi mudado. Para todas as máquinas, o autopart criará um /boot (ou outras partições especiais bootloader conforme requeridas pela arquitetura) e swap. Para máquinas com ao menos 50 GB de espaço livre no disco, o autopart criará uma partição root de tamanho razoável (/) e o resto será atribuído ao /home. Para as máquinas com pouco espaço, somente o root (/) será criado.
    Se você não quer que um volume /home seja criado, não use o autopart. Em vez disso, especifique o /boot, swap e /, certificando-se de permitir o volume root crescer conforme necessário.
  • O Anaconda agora inclui uma nova interface de filtro de armazenamento para controlar quais dispositivos são visíveis durante a instalação. Esta interface corresponde aos comandos ignoredisk, clearpart e zerombr. Pelo motivo do ignoredisk ser opcional, exclui-lo do arquivo Kickstart não fará o filtro UI aparecer durante a instalação. Se você desejar usar esta interface, adicione: 
    ignoredisk --interactive
  • A opção --size=1 --grow do arquivo /tmp/partition-include não pode ser mais usada. Você deve especificar um tamanho padrão razoável e as partições aumentarão de acordo.

2.2.2.3. Mudanças nos Pacotes

Estas mudanças afetam a seção %packages:
  • Os argumentos --ignoreDeps e --resolveDeps foram removidos. O Anaconda automaticamente resolve as dependências, mas pulará a instalação dos pacotes que não correspondem às dependências.
  • Se você quer obter exatamente o mesmo conjunto de pacotes pelo Kickstart que você obteria pela instalação padrão GUI, aceitando todos os padrões, adicione o seguinte: 
    %packages --default
%end
  • Você pode também opcionalmente especificar a arquitetura de pacotes que você quer instalar para instalações multi-arch. Por exemplo: 
    %packages
glibc.i686
%end
    Isto adicionaria o pacote glibc x86 ao conjunto, que pode ser útil em um sistema x86-64 que requer que os pacotes x86 para motivos de compatibilidade.
  • Não é possível auditar e migrar todos os pacotes e grupos na seção %packages. Alguns pacotes e grupos foram removidos, alguns adicionados e alguns tiveram seus nomes alterados. Por favor consulte as Notas de Lançamento para mais detalhes.

2.2.2.4. Mudanças de Script

Estas mudanças afetam o uso dos scripts %pre, %post e %traceback.
  • O log dos erros enquanto se executa scripts foi melhorado. O scripts não são removidos após serem executados, então eles podem ser inspecionados. Isto é muito útil em sistemas onde os scripts são dinamicamente gerados, para poder ver o que foi executado. Além disso, os resultados do stderr e o stdout são sempre colocados no log para cada script. Isto tem um importante efeito colateral: se seus scripts usam um programa interativo, você deve passar o --logfile=/dev/tty3 ao cabeçalho de seus scripts. Senão, você não será capaz de interagir com o programa.

2.2.2.5. Mudanças de Sintaxe

Mudanças no núcleo de sintaxe do Kickstart são raros. Entretanto, há duas importantes mudanças de sintaxe para estar atento:
  • A opção %include pode agora aceitar uma URL com um argumento, além do nome de um arquivo.
  • As seções %packages, %post, %pre e %traceback devem ter uma opção %end no final. Préviamente, estas seções não tinha um token final explícito, mas terminavam onde começavam. Iniciando no Red Hat Enterprise Linux 6, usar o %end é requerido. Arquivos sem um token %end terão falha.

2.2.2.6. Resumo das Diferenças

Esta seção lista as diferenças nos comandos e opções do Red Hat Enterprise Linux 6:
Comandos removidos:
  • key
  • langsupport
  • mouse
Comandos obsoletos:
  • monitor
  • xconfig --resolution
Comandos adicionados:
  • fcoe
  • group
  • rescue
  • sshpw
  • updates

2.2.2.7. pykickstart

O pacote pykickstart contém utilitários que podem ser usados para fazer a migração mais facilmente. Tenha certeza de que possui instalado o pacote mais atual. O comando ksverdiff pega o início e fim de sintaxe, e relata as diferenças em comandos e opções para as duas versões dadas. Declarando os comandos e opções novos, obsoletos e removidos. Por exemplo: 
$ ksverdiff --from RHEL5 --to RHEL6

The following commands were removed in RHEL6:
langsupport mouse key

The following commands were deprecated in RHEL6:
monitor

The following commands were added in RHEL6:
sshpw group rescue updates fcoe
 ...
Você pode também checar a validade de seu arquivo de kickstart com o comando ksvalidator. Este comando checa a validade do arquivo com a versão de sintaxe do kickstart que você especificar. Entretanto, não pode lhe informar sobre problemas que aconteceriam somente no momento da instalação, por exemplo se você especifica part --ondisk=sdr e tal dispositivo não existe. Exemplo de uso: 
$ ksvalidator --version RHEL6 my-rhel5-ks.cfg

2.2.3. Networking

Esta seção descreve quais comportamentos foram mudados no instalador gráfico, relacionados à redes.
  • O Anaconda está agora usando o NetworkManager para configuração da interface de rede durante a instalação. A tela de configuração da interface de rede principal no Anaconda foi removida. O usuários são somente requeridos digitar detalhes de configuração de rede se caso for necessário durante a instalação. As configurações usadas durante a instalação são então escritas no sistema para uso posterior.
  • Quando usar o boot.iso para inicializar o instalador, a tela de seleção da fonte aparece mesmo se todos os métodos de instalação padrões são escolhidos.
  • Quando inicializar por PXE e usar um arquivo .iso montado pelo NFS para instalação de mídia, adicione repo=nfs:server:/path/ à linha de comando. Os arquivos install.img e product.img também precisam serem extraídos e/ou colocados no diretório nfs:server:/path/images/. O arquivo product.img contém definições de variantes e várias classes de instalação.
  • Alguns sistemas com múltiplas interfaces de rede podem não atribuir o eth0 à primeira interface de rede conforme reconhecida pela BIOS do sistema. Isto pode causar ao instalador de tentar o uso de uma interface de rede diferente do que era inicialmente usado pelo PXE. Para mudar este comportamento, use o seguinte nos arquivos de configuração pxelinux.cfg/*: 
    IPAPPEND 2 APPEND
      ksdevice=bootif
  • Esta opção de configuração causa ao instalador o uso da mesma interface de rede que a BIOS do sistema e PXE usam. Você pode também usar a seguinte opção, que fará ao instalador usar o primeiro dispositivo de rede que encontrar que está ligado ao switch de rede: 
     
ksdevice=link

2.2.4. Subscrições de Produtos e Atualização de Conteúdo

O Red Hat Enterprise Linux 6 apresenta um serviço atualizado e mais flexível para entrega de conteúdo e gerenciamento de subscrição. Esta seção descreve as mudanças no serviço de conteúdos.
  • O ambiente de host da Red Hat é atualizado usando as subscrições baseadas em canal para subscrições baseadas em produtos e quantidades. O novo RHN baseado em Certificados teve as ferramentas de cliente redesenhadas para gerenciar subscrições e sistemas e trabalha com com a nova Rede de Entrega de Conteúdo e Subscrições (CDN - Content Delivery Network).
    O RHN baseado em canais tradicional ainda está disponível como RHN Classic.
    Estes dois serviços de subscrições estão disponíveis na mesma plataforma, mas apenas com tecnologias paralelas, então todas as subsrições podem ser registradas e gerenciadas em qualquer maneira.
    Ambientes usando o Satellite ou servidor proxy continuarão a usar o sistema de subscrição baseado em canal tradicional e registrarão os sistemas com o RHN Classic.
  • Uma nova opção de servidor de conteúdo, o Red Hat Network Classic, foi adicionada ao assistente do firstboot (primeira inicialização). Ele usa o RHN baseado em canais tradicional em vez do atualizado RHN e CDN. O Red Hat Network padrão usa a nova plataforma de gerenciamento Red Hat Network baseada em certificados.
  • O RHN Baseado em Certificados e o RHN Classic são interoperáveis; se um sistema é registrado usando um serviço, o outro serviço reconhece-o e não emitirá alertas. Entretanto, estes serviços não funcionam simultaneamente. Um sistema deve estar registrado com um e somente um serviço de subscrição; não podendo ser registrado com ambos.
    Não há atualmente caminho de migração direta de um sistema usando o RHN Classic para o novo Red Hat Network baseado em Certificados. Para mover de sistema para o outro, existem duas opções:
    • Atualize o sistema para Red Hat Enterprise Linux 6.1 ou posterior usando um boot ISO em vez do yum.
    • Manualmente remova o sistema do RHN Classic e delete o registro do host, então registre o sistema para o Red Hat Network baseado em Certificados usando o as ferramentas do gerenciador de subscrição da Red Hat.
  • Um novo conjunto de ferramentas do cliente, o Gerenciador de Subscrição Red Hat GUI e CLI são fornecidos com o Red Hat Enterprise Linux 6.1 para gerenciar subscrições através do RHN baseado em Certificados. As ferramentas existentes rhn_* estão ainda disponíveis para lidar com sistemas gerenciados pelo RHN Classic.

2.3. Instalador baseado em texto

A opção de instalação baseada no modo texto no Red Hat Enterprise Linux 6 está significativamente mais simplificada do que era nas versões anteriores. A instalação do modo texto agora omite os passos mais complicados que eram previamente parte do processo, e lhe fornece uma experiência organizada e simples. Esta seção descreve as mudanças no comportamento quando usar o instalador baseado em texto:
  • O Anaconda automaticamente seleciona os pacotes somente dos grupos base e de núcleo. Estes pacotes são suficientes para assegurar que o sistema é operacional no final do processo de instalação, pronto para instalar atualizações e novos pacotes.
  • O Anaconda ainda lhe apresenta com a tela inicial das versões anteriores que lhe permite especificar onde o anaconda deveria instalar o Red Hat Enterprise Linux no seu sistema. Você pode escolher usar o disco inteiro, remover as partições linux existentes ou usar o espaço livre no drive. Entretanto, o anaconda agora define automaticamente a estrutura das partições e não lhe pergunta para adicionar ou deletar partições ou sistemas de arquivos desta estrutura básica. Se você precisar de uma estrutura personalizada no momento da instalação, você deve fazer uma instalação gráfica por uma conexão VNC ou uma instalação Kickstart. Opções mais avançadas, tais como gerenciamento de volume lógico (LVM), sistemas de arquivos criptografados e sistemas de arquivos redimensionáveis estão somente disponíveis no modo gráfico e Kickstart.
  • O Anaconda agora realiza uma configuração automática do bootloader no instalador baseado em texto.
  • Instalações em modo texto usando Kickstart são feitas na mesma maneira que eram feitas nas versões anteriores. Entretanto, por causa da seleção de pacote, o particionamento avançado e configuração do bootloader são agora automatizados no modo texto, o anaconda não pode lhe perguntar por informações que ele precisa durante estes passos. Você deve portanto assegurar que o arquivo de kickstart inclui os pacotes, particionamento e configurações de bootloader. Se qualquer dessas informações estiverem faltando, o anaconda sairá com uma mensagem de erro.

Capítulo 3. Armazenamento e Sistemas de Arquivos

3.1. RAID

Atualizações

Realizar uma atualização de um conjunto dmraid para um conjunto mdraid não é suportado. Um aviso será mostrado quando uma atualização deste tipo for tentada. Atualizações de conjuntos mdraid existentes e criação de novos conjuntos mdraid são possíveis.

O novo superblock padrão pode causar problemas quando atualizar conjuntos. Este novo formato de superbloco (usado em todos os dispositivos exceto quando criar uma partição RAID1 /boot) está agora no início da matriz e qualquer sistema de arquivos ou dados LVM são deslocados para o início da partição. Quando a matriz não estiver rodando, o LVM e os comandos do sistema de arquivos mount podem não detectar o dispositivo com tendo um volume válido ou dados do sistema de arquivo. Isto é intencional e significa que se você quiser montar um disco único em uma matriz RAID1, você precisa iniciar a matriz tendo somente esse disco único nela, então monte a matriz. Você não pode montar um disco não preparado diretamente. Esta mudança foi feita já que montar um disco não preparado diretamente pode corromper silenciosamente a matriz se um resync não é forçado.
Em reinicializações subsequentes, o sistema RAID pode então considerar que o disco que não era incluído na matriz como incompatível e desconectará o dispositivo da matriz. Isto é normal. Quando você estiver pronto para re adicionar o outro disco de volta à matriz, use o comando mdadm para fazer um hot add do disco na matriz, no qual apontar um resync das peças modificadas do disco (se você tiver write-intent bitmaps ) ou no disco todo (se você não tiver bitmaps) para ser realizado e a matriz mais uma vez será sincronizada. Deste ponto, os dispositivos não serão desconectados da matriz, já que a matriz é considerada estar própriamente agregada.
O novo superblock suporta o conceito de matrizes (mdraid). A dependência do método antigo de enumeração de matriz (por exemplo: /dev/md0, então /dev/md1, etc.) para a distinção entre matrizes foi eliminado. Você agora pode escolher um nome arbitrário para a matriz (tal como home, data ou opt). Crie a matriz com o nome escolhido usando a opção --name=opt. Seja qual for o nome dado à matriz, esse nome será criado em /dev/md/ (a menos que um caminho completo seja dado como nome, que no caso esse caminho será criado ou a menos que você especifique um número único, tal como 0 e o mdadm iniciará a matriz usando o esquema antigo /dev/mdx). O instalador do Anaconda não permite atualmente a seleção de nomes de matrizes e em vez disso usa o esquema de número simples como uma maneira de emular como as matrizes eram criadas no passado.
A nova matriz mdraid suporta o uso dos write-intent bitmaps. Ajudando o sistema a identificar partes problemáticas de uma matriz, para que se no evento de um desligamento incomum, somente as partes problemáticas precisam de ser resincronizadas. Matrizes recém criadas terão automaticamente um write-intent bitmap adicionado quando necessário. Por exemplo, matrizes usadas para troca e matrizes muito pequenas (tal como matrizes /boot) não se beneficiam de ter write-intent bitmaps. É possível adicionar um write-intenet bitmap à sua matriz existente anteriormente depois que uma atualização estiver completa pelo comando mdadm --grow no dispositivo, entretanto os write-intent bitmaps incorrem em um desempenho modesto (cerca de 3-5% em um pedaço de bitmap de 65536, mas pode aumentar para 10% ou mais em tamanhos menores de bitmap tal como 8192). Isto significa que se um write-intent bitmap é adicionado à uma matriz, é melhor manter o tamanho do pedaço relativamente grande. O tamanho recomendado é 65536.

3.2. ext4

Migrar de um ext3

É recomendado para aqueles que desejam fazer uso do ext4 iniciar com uma partição recém formatada. Entretanto, você pode instalar o Red Hat Enterprise Linux 6 com a opção de boot ext4migrate se você deseja converter suas partições ext3 em legacia para ext4. É importante notar que fazendo isso você não receberá todos os benefícios que o ext4 oferece, já que os dados atualmente residindo na partição não farão uso dos recursos de extenção e outras mudanças. Novos dados entretando farão uso das extenções. Passando essa opção de boot para migrar para ext4 não é recomendado e é altamente recomendável que se faça um backup dos sistemas de arquivos antes de tentar esta migração.

Mudanças de Comportamento

O Red Hat Enterprise Linux 6 fornece suporte total para ext4 e é o sistema de arquivos padrão para novas instalações. Esta seção explica as principais mudanças no comportamento que este novo sistema de arquivos apresenta.

  • A versão incluída do carregador de boot GRUB oferece suporte total para partições ext4. O instalador também lhe permite colocar o sistema de arquivos /boot em uma partição ext4.
  • A versão incluída do pacote e2fsprogs está totalmente compatível com o ext4.
  • Em alguns casos, os sistemas de arquivos ext4 criados sob o Red Hat Enterprise Linux 5.3 com o pacote e4fsprogs criou um tipo de sistema de arquivos ext4dev. O recurso test-fs sinaliza identificar esses sistemas de arquivos como uma versão de desenvolvimento pode ser removida com o seguinte comando: tune2fs -E ^test_fs. Isto é feito para que esses sistemas de arquivos sejam reconhecidos como sistemas de arquivos ext4 regulares.

3.3. fusecompress

fusecompress

O fusecompress é um sistema de arquivos comprimido montável por usuários sem previlégios. O Red Hat Enterprise Linux 6 inclui um versão atualizada que corrige diversos bugs mas muda formato em disco. Usuários com sistemas de arquivos fusecompress existentes precisarão migrar seus dados para o novo formato. A menos que a descompressão seja realizada antes da atualização, o pacote fusecompress_offline1 é requerido.

3.4. blockdev

blockdev

A opção do comando blockdev --rmpart não é mais suportada. Os comandos partx(8) e delpart(8) agora fornecem esta funcionalidade.

Capítulo 4. Serviços e Redes

4.1. Interfaces e Configurações

NetworkManager

O Red Hat Enterprise Linux 6 usa o NetworkManager por padrão quando configurar interfaces de rede.

Infiniband

O suporte ao Infiniband (especificamente o script de início openib e o arquivo openib.conf) era fornecido pelo pacote openib no Red Hat Enterprise Linux 5. O nome do pacote mudou no Red Hat Enterprise Linux 6 para refletir sua funcionalidade mais precisamente. A funcionalidade Infiniband é agora distribuída no pacote rdma. O serviço é agora chamado rdma e o arquivo de configuração está localizado no /etc/rdma/rdma.conf.

4.2. Inicialização de Serviços

xinetd

O Xinetd é um daemon usado para iniciar serviços de rede em demanda. As mudanças no xinetd são relacionadas aos limites permitidos dos descritores de arquivos abertos:

  • O mecanismo de escuta mudou de select() para poll(). Com esta mudança, o limite de descritores de arquivos abertos usados pelo xinetd foram mudados.
  • O limite do descritor de arquivo pode também ser mudado a cada serviço. Isto pode ser feito no arquivo de configuração para o serviço através da directiva rlimit_files. O valor pode ser um valor inteiro positivo ou ILIMITADO.
Runlevels

No Red Hat Enterprise Linux 6, os runlevels 7, 8 e 9 não são mais suportados e não podem ser usados.

Upstart

No Red Hat Enterprise Linux 6, o init do pacote sysvinit foi substituido com o Upstart, um sistema init baseado em eventos. Este sistema lida com a inicialização de tarefas e serviços durante o boot, parando-os durante o desligamento e supervisionando-os enquanto o sistema estiver em execução. Para mais informações sobre o Upstart, consulte a página man init(8).

Processos são reconhecidos para o Upstart como trabalhos e são definidos pelos arquivos no diretório /etc/init. O Upstart é bem documentado nas páginas man. A visão geral do comando está em init(8) e a sintaxe está descrita em init(5).
O Upstart fornece as seguintes mudanças no comportamento no Red Hat Enterprise Linux 6:
  • O arquivo /etc/inittab está obsoleto, e é agora usado somente para configurar o runlevel pela linha initdefault. Outras configurações são feitas pelos serviços upstart no diretório /etc/init.
  • O número de consoles ativos tty é agora configurado pela variável ACTIVE_CONSOLES no /etc/sysconfig/init, que é lida pela tarefa /etc/init/start-ttys.conf. O valor padrão é ACTIVE_CONSOLES=/dev/tty[1-6], que inicia um getty no tty1 até o tty6.
  • Uma serial do getty continua configurada automaticamente se o console serial é o console do sistema primário. Em lançamentos anteriores, isto era feito pelo kudzu, que editaria o /etc/inittab/ No Red Hat Enterprise Linux 6, a configuração do console serial primário é manuseado pelo /etc/init/serial.conf.
  • Para configurar um getty rodando em um console serial não padrão, você deve agora escrever uma tarefa Upstart em vez de editar o /etc/inittab. Por exemplo, se um getty no ttyS1 é o desejado, o seguinte arquivo de tarefa (/etc/init/serial-ttyS1.conf) funcionaria: 
    # This service maintains a getty on /dev/ttyS1.

start on stopped rc RUNLEVEL=[2345]
stop on starting runlevel [016]

respawn
exec /sbin/agetty /dev/ttyS1 115200 vt100-nav
Como nos lançamentos anteriores, você ainda deve se assegurar que o ttyS1 está no /etc/securetty se você desejar permitir logins root neste getty.
Pelo razão da mudança para o Upstart, usando o /etc/shutdown.allow para definir quem pode desligar a máquina não é mais suportado.

4.3. IPTables/Firewalls

O IPTables inclui um módulo alvo SECMARK. Este é usado para definir o valor de marca de segurança associado com o pacote para uso pelo subsistema de segurança tal como o SELinux. Ele é somente válido na table mangle. Consulte o seguinte para exemplo de uso: 
iptables -t mangle -A INPUT -p tcp --dport 80 -j SECMARK --selctx \ system_u:object_r:httpd_packet_t:s0

4.4. Apache HTTP Server

Abaixo há uma lista de mudanças para o servidor Apache HTTP que vale a pena saber quando migrar para o Red Hat Enterprise 6:
  • Os módulos mod_file_cache, mod_mem_cache, e mod_imagemap não são mais suportados.
  • A opção Charset=UTF-8 foi adicionada à directiva IndexOptions padrão. Se as listagens dos diretórios com caractéres que não sejam UTF-8 são requeridas (tal como aquelas produzidas pelo mod_autoindex), esta opção deve ser mudada.
  • A sessão de cache de distribuição distcache não é mais suportada no mod_ssl.
  • A localização padrão do arquivo de ID do processo (pid) foi mudado de /var/run para /var/run/httpd.
  • O pacote mod_python não é mais incluído já que o desenvolvimento upstream foi encerrado. O Red Hat Enterprise Linux 6 fornece o mod_wsgi como uma alternativa, com suporte para scripts Python pelo interface WSGI.

4.5. PHP

As mudanças no PHP são listadas abaixo:
  • O PHP foi atualizado para a versão 5.3. Problemas de compatibilidade podem requerer a atualização dos scripts. Para mais detalhes, consulte as seguintes URLs:
  • As seguintes mudanças foram feitas na configuração padrão (/etc/php.ini):
    • O error_reporting é agora definido para E_ALL & ~E_DEPRECATED (anteriormente E_ALL)
    • O short_open_tag é definido agora para Off (anteriormente On)
    • O variables_order é definido agora para GPCS (anteriormente EGPCS)
    • O enable_dl é definido agora para Off (anteriormente On)
  • O mime_magic, dbase, e extensões ncurses não são mais distribuídas.

4.6. BIND

Há diversas importantes mudanças na configuração do BIND:
  • A configuração ACL padrão - no Red Hat Enterprise Linux 5, a configuração ACL padrão permitia consultas e oferecia recursão para todos os hosts. Por padrão, no Red Hat Enterprise Linux 6, todos os hosts podem fazer consultas por dados autoritários mas somente hosts da rede local podem fazer consultas recursivas.
  • Nova opção allow-query-cache - a opção allow-recursion se tornou obsoleta com esta opção. Ela é usada para controlar acesso aos caches dos servidores, que incluem todos os dados não autoritários (como consultas recursivas e sugestões de nomes de servidores root).
  • Gerenciamento do ambiente chroot - O script bind-chroot-admin, que era usado para criar symlinks de um ambiente que não é chroot para um ambiente chroot, se tornou obsoleto e não existe mais. Ao invés, a configuração pode ser gerenciada diretamente em um ambiente que não seja chroot e scripts init automaticamente montam os arquivos necessários para o ambiente chroot durante a inicialização named em caso que os arquivos já não estão presentes no chroot.
  • O diretório de permissões /var/named - O diretório /var/named não é mais gravável. Todos os arquivos de zona que precisam ser graváveis (tais como zonas DNS dinâmicas, DDNS) devem ser colocados no novo diretório gravável: /var/named/dynamic.
  • A opção dnssec [yes|no] não existe mais - As opções globais dnssec [yes|no] foram divididas em duas novas opções: dnssec-enable e dnssec-validation. A opção dnssec-enable ativa o suporte DNSSEC. A opção dnssec-validation ativa a validação DNSSEC. Note que definindo a dnssec-enable para "não" em um servidor recursivo significa que ele não pode ser usado como um encaminhador para outro servidor que realiza a validação DNSSEC. Ambas opções são definidas para sim "yes" por padrão.
  • Você não precisa mais especificar a declaração controls no /etc/named.conf se você usar o utilitário de gerenciamento rndc. O serviço named automaticamente permite controlar conexões pelo dispositivo loopback e ambos named e rndc usam a mesma chave secreta gerada durante a instalação (localizada em /etc/rndc.key).
Em uma instalação padrão, o BIND é instalado com a validação DNSSEC ativada e usa o registro ISC DLV. Isto significa que todos os domínios assinados (tais como gov., se., cz.), que possuem suas próprias chaves no registro ISC DLV, são criptograficamente validados no servidor recursivo. Se a validação falhar devido à tentativas de envenenamento do cache, então o usuário final não receberá estes dados falsificados. A implementação DNSSEC é agora um recurso totalmente implementado, é um passo importante para fazer a internet mais segura para os usuários finais e é totalmente suportada no Red Hat Enterprise Linux 6. Como mencionado anteriormente, a validação DNSSEC é controlada com a opção dnssec-validation no /etc/named.conf.

4.7. NTP

O NTP (Network Time Protocol) é usado para sincronizar os relógios dos sistemas de computadores através da rede. No Red Hat Enterprise Linux 6, o arquivo de configuração padrão, /etc/ntp.conf, possui agora as seguintes linhas comentadas: 
#server 127.127.1.0 # local clock
#fudge 127.127.1.0 stratum 10
Esta configuração quer dizer que o ntpd somente distribuirá informações de tempo para clientes de rede se ela é especificamente sincronizada a um servidor NTP ou relógio de referência. Para fazer o ntpd fornecer essas informações mesmo quando não sincronizadas, as duas linhas devem ser comentadas.
Também quando o ntpd é iniciado com a opção -x (em OPTIONS no arquivo /etc/sysconfig/ntpd), ou se existem servidores especificados no /etc/ntp/step-tickers, o serviço não executa mais o comando ntpdate antes de iniciar. Agora há um serviço ntpdate separado que pode ser ativado independentemente do serviço ntpd. Este serviço ntpdate é desativado por padrão, e deve ser usado somente quando outros serviços requerem a hora correta antes de iniciar ou não funcionam propriamente quando modificações ocorrem depois pelo ntpd.
Você pode encontrar problemas rodando este serviço com a configuração padrão do NetworkManager. Pode ser necessário adicionar NETWORKWAIT=1 ao /etc/sysconfig/network, conforme descrito no Guia de Implementação do Red Hat Enterprise Linux (Depoyment Guide).

4.8. Kerberos

No Red Hat Enterprise Linux 6, os clientes Kerberos e servidores (incluindo KDCs) serão padrões para não usar chaves para as codificações des-cbc-crc, des-cbc-md4, des-cbc-md5, des-cbc-raw, des3-cbc-raw, des-hmac-sha1, e arcfour-hmac-exp. Por padrão, os clientes não serão capazes de autenticar em serviços que possuem chaves destes tipos.
A maioria dos serviços podem ter um novo conjunto de chaves (incluindo chaves para o uso com codificações mais fortes) adicionadas aos seus keytabs e não passar por períodos de inatividade, e o ticket que concede chaves de serviços podem da mesma maneira serem atualizados a um conjunto que inclui chaves para uso com codificações mais fortes, usando o comando kadmin cpw-keepol.
Como uma solução temporária, sistemas que precisam continuar a usar codificações mais fracas requerem a opção allow_weak_crypto na seção libdefaults do arquivo /etc/krb5.conf. Esta variável é definida para false por padrão, e a autenticação falhará sem ter esta opção ativada: 
[libdefaults]
allow_weak_crypto = yes
Adicionalmente, o suporte para Kerberos IV, tanto como uma biblioteca compartilhada disponível como um mecânismo de autenticação suportado em aplicações, foi removido. Suporte recém adicionados para políticas de bloqueio requerem uma mudança ao formato de dump do banco de dados. KDCs masters que precisam fazer um dump de banco de dados em um formato que antigos KDCs podem consumir devem executar o comando kdb5_util's dump com a opção -r13.

4.9. Mail

4.9.1. Sendmail

Em alguns lançamentos do Red Hat Enterprise Linux 5, o Mail Transport Agent (MTA) sendmail aceitava conexões de rede de hosts externos por padrão. No Red Hat Enterprise Linux 6, o sendmail por padrão, somente aceita conexões do sistema local (localhost). Para garantir ao sendmail a habilidade de agir como um servidor para hosts remotos, realize um dos seguintes passos:
  • Edite o /etc/mail/sendmail.mc e mude a linha DAEMON_OPTIONS para também escutar em dispositivos de rede.
  • Comente a linha DAEMON_OPTIONS no /etc/mail/sendmail.mc.
Para colocar quaisquer dessas mudanças em efeito, instale o pacote sendmail-cf, então regere o /etc/mail/sendmail.cf. Isto é feito rodando os seguintes comandos: 
su -c 'yum install sendmail-cf'
su -c 'make -C /etc/mail'

4.9.2. Exim

O Exim foi removido do Red Hat Enterprise Linux 6. O postfix é o padrão e o MTA recomendado.

4.9.3. Dovecot

Configuração do Dovecot

A configuração para o Dovecot 2.x foi mudada. O arquivo de configuração master /etc/dovecot.conf foi movido para o /etc/dovecot/dovecot.conf e outras partes da configuração Dovecot foi movida para o /etc/dovecot/conf.d/*.conf. A maioria da configuração é a mesma e é compatível com esta nova versão; entretanto, você pode testar sua configuração e listar quais opções foram renomeadas, removidas ou de outra maneira alteradas nesta nova versão com o seguinte comando: 

doveconf [-n] -c /old/dovecot.conf

4.10. MySQL®

DBD Driver

O MySQL DBD driver foi licenciado duas vezes e os problemas relacionados ao licenciamento foram resolvidos. O pacote resultante apr-util-mysql é agora incluído nos repositórios de software do Red Hat Enterprise Linux 6.

4.11. PostgreSQL

Atualizando Banco de Dados

Se você estiver atualizando a partir de uma instalação do Red Hat Enterprise Linux 5 em que o PostgreSQL 8.4 (pacotes postgresql84-*) estava em uso, os pacotes Red Hat Enterprise 6 PostgreSQL serão operados como uma substituição.

Entretanto, se você estiver atualizando de uma instalação do Red Hat Enterprise Linux 5 na qual o PostgreSQL 8.1 (pacotes postgresql-*) ou anterior estava em uso, e você possui um conteúdo de banco de dados existentes que precisa ser preservado, e você precisará seguir o procedimento de despejo e recarregamento devido às mudanças no formato dos dados: http://www.postgresql.org/docs/8.4/interactive/install-upgrading.html. Assegure-se que você faça o passo de despejo (dump) antes de atualizar para o Red Hat Enterprise Linux 6.
Outras Mudanças

Consulte a seguinte URL para possíveis problemas de compatibilidade de aplicação associadas com a transição do PostgreSQL 8.1 para o 8.4: http://wiki.postgresql.org/wiki/WhatsNew84

4.12. Squid

O Squid foi atualizado para o 3.1, e agora fornece suporte IPv6 nativo. O arquivo de configuração /etc/squid/squid.conf foi significativamente encurtado; as opções de configuração para o Squid 3.1 foram mudadas e não são inteiramente compatíveis com algumas versões anteriores. Para detalhes completos na configuração e outras mudanças, por favor consulte as notas de lançamento do Squid 3.1: http://www.squid-cache.org/Versions/v3/3.1/RELEASENOTES.html.
O Squid fornece a habilidade de autenticar usuários pelos assistentes ncsa_auth e pam_auth. As permissões destes assistentes foram mudadas no Red Hat Enterprise Linux 6. Lançamentos anteriores ativavam o sinalizador setuid para o ncsa_auth e pam_auth, onde previlégios elevados eram necessários para acessar o sistema de arquivos requeridos para autenticação. Agora, no Red Hat Enterprise Linux 6, o Squid não requer a configuração do sinalizador setuid para estes assistentes. Esta mudança foi feita por causa de risco à segurança presentes quando executados sinalizadores setuid. A funcionalidade normal foi mantida sem definir estes sinalizadores.

4.13. Bluetooth

Serviço de Bluetooth por Demanda

Para suportar dispositivos Bluetooth, o serviço de segundo plano do Bluetooth foi iniciado por padrão nas versões anteriores do Red Hat Enterprise Linux. Neste lançamento, o serviço de bluetooth é iniciado por demanda quando necessitado e automaticamente pàra 30 segundos depois que o dispositivo em uso parou. Isto reduz tempo de inicialização geral e consumo de recursos.

4.14. Cron

Vixie cron e Cronie

O Red Hat Enterprise Linux 6 inclui o pacote o cronie como um substituto para o vixie-cron. A diferença principal entre este pacotes é de como as tarefas regulares (diárias, semanais, mensais) são feitas. O Cronie usa o arquivo /etc/anacrontab, que por padrão se parece com o seguinte: 

# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45

# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

# period in days   delay in minutes   job-identifier   			command

1			5		cron.daily	nice run-parts	/etc/cron.daily
7			25		cron.weekly	nice run-parts	/etc/cron.weekly
@monthly		45		cron.monthly	nice run-parts	/etc/cron.monthly
Estas tarefas regulares serão executadas uma vez por dia, no intervalo de tempo das 03:00-22:00, incluindo atrasos casuais. Por exemplo, o cron.daily terá um atrasado forçado de 5 minutos mais um atraso casual de 0-45 minutos. Você pode também rodar as tarefas sem atrasos, entre 4 e 5: 
RANDOM_DELAY=0 # or don't use this option at all

START_HOURS_RANGE=4-5

# period in days   delay in minutes   job-identifier   			command
1			0		cron.daily	nice run-parts	/etc/cron.daily
7			0		cron.weekly	nice run-parts	/etc/cron.weekly
@monthly		0		cron.monthly	nice run-parts	/etc/cron.monthly
Recursos do cronie incluem:
  • Atrasos casuais para o início da tarefa em /etc/anacrontab.
  • O intervalo de tempo de tarefas regulares podem ser definidas no /etc/anacrontab.
  • Cada cron table pode ter sua própria zona de tempo definida com a varável CRON_TZ.
  • Por padrão, o daemon do cron checa por mudanças nas tabelas com o inotify.
Para mais detalhes sobre o cronie e cronie-anacron, por favor consulte o Guia de Implementação do Red Hat Enterprise Linux (Deployment Guide).

4.15. Logging

A opção dateext é agora ativada por padrão no /etc/logrotate.conf. Esta opção arquiva versões antigas dos arquivos de log, adicionando uma extensão representando a data (no formato YYYYMMDD). Previamente, um número era anexado aos arquivos.

Capítulo 5. Ferramentas da Linha de Comando

Esta seção descreve as mudanças comportamentais das ferramentas de linha de comando no Red Hat Enterprise Linux 6.

5.1. Grep

O comportamento do comando grep foi alterado com relação à busca por strings com maiúsculas e minuscúlas. Usando intervalos de busca no formato [a-z] é dependente da variável LC-COLLATE.
Você pode definir LC_COLLATE=C para preservar comportamentos antigos para alcançar resultados apropriados quando realizar intervalos de busca com este método; entretanto, no Red Hat Enterprise Linux 6, a maneira recomendada para intervalos de busca é usar o formato [[:lower:]],[[:upper:]].
Esta mudança pode afetar significativamente o resultado, então scripts e processos podem ser revisados para continuar alcançar os resultados corretos.

5.2. Sed

O comando sed com a opção -i lhe permite deletar os conteúdos de um arquivo de somente leitura e lhe permite deletar outros arquivos protegidos. As permissões de um arquivo definem quais ações podem tomar lugar para tal arquivo, enquanto as permissões para um diretório definem quais ações podem ser tomadas para a lista de arquivos dentro desse diretório. Por esta razão, o sed não permite você usar o -i em um arquivo com escrita permitida dentro de um diretório de somente leitura, e quebrará links hards ou simbólicos quando a opção -i é usada em tal arquivo.

5.3. Pcre

O pacote pcre foi atualizado para 7.8. Isso inclui as seguintes mudanças comportamentais:
  • A verificação UTF-8 agora referência o RFC 3629 em vez do RFC 2279. Isto o faz mais restritivo nas strings que aceita. Por exemplo, o valor do caracter ordinal UTF-8 é agora limitado para 0x0010FFFF: 
    $ echo -ne "\x00\x11\xff\xff" | recode UCS-4-BE..UTF8 | pcregrep --utf-8 '.'
pcregrep: pcre_exec() error -10 while matching this line:
    Por favor consulte o RFC para mais detalhes: http://tools.ietf.org/html/rfc3629#section-12.
  • Os padrões salvos que eram compilados por versões anteriores do PCRE devem ser recompilados. Isto afeta aplicações que serializam expressões PCRE pré compiladas à memória externa (por exemplo, um arquivo) e os carrega depois. Isto é normalmente feito por motivos de desempenho, por exemplo em grandes filtros de spam.

5.4. Shells

A locação dos arquivos binários do shell mudou. Por exemplo, os binários do bash e ksh não estão mais no /usr/bin. Ambos binários são agora encontrados no /bin. Os scripts necessitarão de atualização para apontar à nova localização dos binários.

5.5. Nautilus

O pacote nautilus-open-terminal fornece uma opção de Abrir Terminal com o clique direito para abrir uma nova janela de terminal no diretório atual. Anteriormente, quando esta opção era escolhida a partir do Desktop, a nova janela do terminal abria no diretório home do usuário. Entretanto, no Red Hat Enterprise Linux 6, o comportamento padrão abre o diretório Desktop (exemplo: ~/Desktop/). Para ativar o comportamente antigo, uso o seguinte comando para definir o GConf booleano desktop_opens_home_dir para verdadeiro:
gconftool-2 -s /aps/nautilus-open-terminal/desktop_opens_dir --type=bool true

Capítulo 6. Desktop

  • No Red Hat Enterprise Linux 6, o console GUI foi movido do tty7 para o tty1.
Configuração GDM

Um número de configurações do GDM são agora gerenciadas dentro do GConf.

A saudação (greeter) padrão do DGM é chamada simple Greeter e é configurado pelo GConf. Os valores padrões são armazenados no GConf no arquivo gdm-simple-greeter.schemas. Use o gconftool2 ou gconf-editor para editar esses valores. Existem as seguintes opções para o Greeter:
  • /apps/gdm/simple-greeter/banner_message_enable 
    false (boolean)
    Controla se a mensagem do banner é mostrada.
  • /apps/gdm/simple-greeter/banner_message_text 
    NULL (string)
    Especifica a mensagem de texto do banner para exibir na janela de saudação.
  • /apps/gdm/simple-greeter/logo_icon_name 
    computer (string)
    Define o nome do ícone tema para usar no logo da saudação.
  • /apps/gdm/simple-greeter/disable_restart_buttons 
    false (boolean)
    Controla se mostra os botões de reinicializar na janela de login.
  • /apps/gdm/simple-greeter/wm_use_compiz 
    false (booleans)
    Controla se o compiz é usado como gerenciador de janela em vez do metacity.
Os plugins podem também serem desativados usando o GConf. Por exemplo, se você quiser desativar o plugin de som, então desconfigure a seguinte chave /apps/gdm/simple-greeter/settings-manager-plugins/sound/active.

Capítulo 7. Segurança e Autenticação

Este capítulo cobre mudanças no comportamento de segurança e autenticação, incluindo SELinux, SSSD, LDAP, Checksums, e PAM.

7.1. SELinux

O daemon sshd é agora um serviço confinado.

7.2. SSSD

O SSSD (System Security Services Daemon) oferece acesso à identidade remota e mecanismos de autenticação, referidos como providers (provedores). Isso permite a esses provedores serem plugados como backends SSSD, abstraindo as fontes de autenticação e identidade de rede e local e permitir qualquer provedor de dados de identidade ser plugado. Um domínio é um banco de dados contendo informações dos usuários, que pode servir como fonte de informação de identidade do provedor. Múltiplos provedores de identidade são suportados, permitindo dois ou mais servidores de identidade agir como namespaces de usuários separados. A informação coletada está disponível às aplicações no front-end através de interfaces padrões PAM e NSS.
O SSSD roda como uma suíte de serviços, independente das aplicações que usam ele. Essas aplicações portanto não precisam mais fazer suas próprias conexões à domínios remotos ou mesmo estarem atentas de qual está sendo usada. Cache local robusto de informações de afiliação de grupos permite operações sem importar de onde vem a identidade (exemplo: LDAP, NIS, IPA, DB, Samba, etc.), oferece desempenho melhorado, e permite autenticação ser realizada mesmo quando a operação de autenticação offline e online estiver indisponível. O SSSD também permite o uso de provedores múltiplos do mesmo tipo (exemplo: múltiplos provedores LDAP) e permite pedidos de identidade de domínios qualificados serem resolvidos por esses provedores diferentes. Mais detalhes podem ser encontrados no Guia de Implantação do Red Hat Enterprise Linux 6 (Deployment Guide).

7.3. LDAP

OpenLDAP

A configuração requerida para o serviço OpenLDAP foi mudada no Red Hat Enterprise Linux 6. Na versões anteriores, o slapd era configurado pelo arquivo /etc/openldap/slapd.conf. A configuração slapd no Red Hat Enterprise Linux 6 é agora armazenada em um diretório especial LDAP (/etc/openldap/slapd.d/) com um esquema pré definido e uma Árvore de Informação de Diretório (Directory Information Tree - DIT). Mais detalhes deste esquema de configuração pode ser encontrado em openldap.org. A seção seguinte detalha um exemplo de como converter o arquivo de configuração antigo para funcionar com o novo diretório:

7.3.1. Convertendo a configuração slapd

Este exemplo assume que o arquivo a ser convertido da configuração antiga slapd está localizado no /etc/openldap/slapd.conf e o novo diretório para a configuração OpenLDAP está localizado em /etc/openldap/slapd.d/.
  • Remova os conteúdos do novo diretório /etc/openldap/slapd.d/: 
     # rm -rf /etc/openldap/slapd.d/*
  • Execute slaptest para checar a validade do arquivo de configuração e especifique o novo diretório de configuração: 
     slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
  • Configure as permissões do novo diretório: 
     chown -R ldap:ldap /etc/openldap/slapd.d 
     chmod -R 000 /etc/openldap/slapd.d 
     chmod -R u+rwX /etc/openldap/slapd.d
  • Uma vez que o serviço é confirmado para funcionar com o novo diretório de configuração, remova o arquivo de configuração antigo: 
     rm -rf /etc/openldap/slapd.conf

7.4. Checksums

O Red Hat Enterprise Linux agora usa o algorítimo digest SHA-256 para verificação de dados e autenticação em mais lugares do que antes, atualizando a partir dos algorítimos mais fracos SHA-1 e MD5.

7.5. Modulos de Autenticação Plugáveis (PAM)

Configurações comuns para serviços PAM estão localizadas no arquivo /etc/pam.d/system-auth-ac.
Módulos de autenticação são agora também escritos em arquivos de configuração PAM adicionais: /etc/pam.d/password-auth-ac, etc/pam.d/smartcard-auth-ac e /etc/pam.d/fingerprint-auth-ac.
O módulo PAM para o sshd e outros serviços remotos tais como ftpd agora incluem o arquivo /etc/pam.d/password-auth no Red Hat Enterprise Linux 6 em vez do /etc/pam.d/system-auth.

7.6. Usuários do Sistema

O limite para número UID/GID atribuídos estaticamente (definidos pelo pacote setup no arquivo /usr/share/doc/setup-*/uidgid) foi aumentado de 100 (no Red Hat Enterprise Linux 3, 4, e 5) para 200 no Red Hat Enterprise Linux 6. Esta mudança pode afetar sistemas que possuem UID/GID atribuídos estaticamente ou dinamicamente de 100-200, e causam falha na instalação e execuçao de algumas aplicações.
A alocação de UID/GID dinâmicos agora abrangem de 499 para baixo no Red Hat Enterprise Linux 6. Para criação de usuário de sistema estático sem reservas impostar pelo pacote setup, é recomendado o uso da area de UID/GID de 300 e acima.

Capítulo 8. Kernel

8.1. Kernel

A ferramenta dracut foi substituiu o uso do mkinitrd. Também o arquivo /etc/modprobe.conf não é mais usado como padrão no gerenciamento de módulos do kernel, entretanto ele ainda pode ser usado se criado manualmente. Consulte o seguinte para um exemplo de uso da ferramenta dracut: 
# mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-old.img
# dracut --force /boot/initramfs-$(uname -r).img $(uname -r)

Capítulo 9. Mudanças nos Pacotes e Drivers

A lista de pacotes incluídos e drivers de sistema passam por mudanças regulares em lançamentos do Red Hat Enterprise Linux. Isto é feito por diversas razões: pacotes e drivers são adicionados ou atualizados no sistema operacional para fornecer novas funcionalidades ou os pacotes e drivers podem representar hardware desatualizados e são removidos ou os pacotes especificos de hardware e drivers não são mais suportados pelo fornecedor e são removidos.
Este capítulo lista os pacotes novos e atualizados e drivers do Red Hat Enterprise Linux 6, e também aqueles que estão obsoletos e descontinuados (removidos).

9.1. Mudanças nas Ferramentas da Configuração de Sistemas

system-config-bind

A ferramenta system-config-bind se tornou obsoleta e foi removida sem substituição. Editando a configuração do nome do servidor manualmente pelo arquivo named.conf é recomendado no Red Hat Enterprise Linux 6. A documentação compreensiva do BIND está instalada como parte do pacote bind no /usr/share/doc/bind-x.y.z. Também, configurações modelos podem ser encontradas no diretório /usr/share/doc/bind-x.y.z/sample. A ferramenta system-config-bind das versões anteriores, entretanto gera uma configuração BIND padrão, então dependendo de seu ambiente é possível migrar para a versão do BIND encontrada no Red Hat Enterprise Linux 6 movendo arquivos de configurações antigos para a locação correta e realizar testes suficientes.

system-config-boot

A ferramenta system-config-boot permitia configuração gráfica do bootloader do GRUB. No Red Hat Enterprise Linux 6 ela se tornou obsoleta e removida sem substituição. A configuração padrão do GRUB é suficiente para muitos usuários, entretanto se mudanças manuais são requeridas, a configuração do boot pode ser acessada e alterada no arquivo grub.conf, localizado no diretório /boot/grub. A documentação completa para configurar o GRUB pode ser encontrada na homepage do GRUB: http://www.gnu.org/software/grub/.

system-config-cluster

A ferramenta system-config-cluster se tornou obsoleta e foi removida sem substituição. Usar o ricci e o luci (do projeto Conga) é o recomendado.

system-config-display

A ferramenta system-config-display foi substituida pelas ferramentas de configuração XRandr e encontrada nas áreas de trabalho: GNOME e KDE. Não há arquivo de configuração explícito (xorg.conf) na instalação padrão do X server já que o gerenciamento de exibição é agora feito dinâmicamente por uma das seguintes opções do menu:

GNOME: System (Sistema) → Preferences (Preferências) → Display (Exibição)
KDE: System Settings (Configurações do Sistema) → Computer Administration (Administração do Computador) → Display (Exibição)
Nota: O utilitário de linha de comando (xrandr) também pode ser usado para a configuração de exibição. Veja o comando xrandr --help ou a página de manual através do comando man xrandr para maiores detalhes.
system-config-httpd

A ferramenta system-config-httpd se tornou obsoleta e foi removida sem substituição. Usuários devem configurar os servidores web manualmente. A configuração pode ser feita no diretório /etc/httpd. O arquivo de configuração principal está localizado em /etc/httpd/conf/httpd.conf. Este arquivo está bem documentado com comentários detalhados para a maioria das configurações de servidores; entretanto se requerido, a documentação do servidor web Apache completa é distribuída com o pacote httpd-manual.

system-config-lvm

A ferramenta system-config-lvm se tornou obsoleta. Os usuários devem realizar o gerenciamento de volumes lógicos pelas ferramentas gnome-disk-util ou lvm.

system-config-netboot

A ferramenta system-config-netboot se tornou obsoleta e foi removida sem substituição. Usar o Red Hat Satellite é o recomendado.

system-config-network

A ferramenta system-config-network foi substituida pelo NetworkManager - uma ferramenta de configuração de rede poderosa e moderna. O NetworkManager-applet (nm-applet) é instalado por padrão em ambos ambientes de área de trabalho e pode ser encontrado na barra de ferramentas do sistema. Veja a página do NetworkManager para maiores informações: http://projects.gnome.org/NetworkManager/.

system-config-nfs

A ferramenta system-config-nfsse tornou obsoleta e foi removida sem substituição. O usuários devem definir a configuração do servidor NFS manualmente.

system-config-rootpassword

A ferramenta system-config-rootpassword foi substituida pela ferramenta system-config-users - uma ferramenta de configuração e gerenciamento de usuários poderosa. A senha root pode ser definida na ferramenta system-config-users desmarcando a opção "Esconder grupos e usuários do sistema" (Hide system users and groups) nas Preferências. O usuário root será agora mostrado na listagem principal e a senha pode ser modificada como qualquer outro usuário.

system-config-samba

A ferramenta systema-config-samba se tornou obsoleta e foi removida sem substituição. Os usuários devem definir a configuração do servidor SMB manualmente.

system-config-securitylevel

A ferramenta system-config-securitylevel foi removida. Os usuários devem agora usar a ferramenta system-config-firewall.

system-config-soundcard

A ferramenta system-config-soundcard foi removida. A detecção de placa de som e configuração é feita automaticamente.

system-config-switchmail

A ferramenta system-config-switchmail se tornou obsoleta e foi removida sem substituição. O postfix é o preferido e o MTA padrão (Mail Transfer Agent) no Red Hat Enterprise Linux 6. Se você estiver usando um outro MTA, ele deve ser configurado manualmente de acordo com seus arquivos de configuração e técnicas específicas.

9.2. Bash (Bourne-Again Shell)

O Red Hat Enterprise Linux 6 inclui a versão 4.1 do Bash e seu shell padrão. Esta seção descreve os problemas de compatibilidade que esta versão apresenta em relação as outras versões.
  • O Bash-4.0 e posteriores agora permitem construções de substituição de processos para passar inalterados através da expansão de controle. Então qualquer expansão dos conteúdos terá de ser especificada separadamente e qualquer substituição de processo terá de ser digitada separadamente.
  • O Bash-4.0 e posteriores agora permitem ao SIGCHLD interromper a espera builtin, conforme o Posix determina. Então o trap SIGCHLD não é mais invocado uma vez para cada filho existente se você estiver usando 'wait' para esperar por todos os filhos.
  • Já que agora o Bash-4.0 e posteriores seguem as regras Posix para encontrar os delimitadores de encerramento de uma substituição de comando $(), ele não se comportará como nas versões anteriores, mas captará mais erros de sintaxe e análise antes de reproduzir uma subshell para avaliar a substituição de comando.
  • O código de acabamento programável usa o mesmo conjunto de caractéres delimitadores como readline quando quebrar as linhas de comando em palavras, em vez do conjunto de meta caractéres do shell, então o acabamento programável e readline devem ser mais consistentes.
  • Quando a leitura do builtin expira, ela tenta atribuir qualquer leitura de entrada para varáveis especificas, que também faz as variáveis serem definidas às strings vazias se não há entradas suficientes. Versões anteriores descartavam a leitura de caractéres.
  • No Bash-4.0 e posteriores, quando um dos comandos em um pipeline é terminado por um SIGINT enquanto executar uma lista de comandos, o shell age como se recebesse a interrupção.
  • O Bash-4.0 e versões posteriores mudam o manuseio da opção set -e para que o shell saia se um pipeline falhar (e não somente se o último comando no pipeline com falha é um comando simples). Isto não é como o Posix especifica. Há uma tarefa a caminho para atualizar esta porção do padrão; o comportamento do Bash-4.0 tenta capturar o consensus no momento do lançamento.
  • O Bash-4.0 e posteriores tem o bug Posix corrigido que fazia o builtin .(source) buscar o diretório atual para o seu argumento de nome de arquivo, mesmo se o "." não está no sistema PATH. O Posix diz que o shell não deve olhar na variável PWD neste caso.
  • O Bash-4.1 usa o local atual quando comparar as strings usando operadores do comando [[. Isto pode ser revertido ao comportamento anterior definindo uma das opções compatNN shopt.
Expressões Regulares

Além dos pontos já listados, citar o argumento padrão à expressão regular correspondendo ao operador condicional =~ pode fazer a correspondência regexp parar de funcionar. Isto ocorre em todas as arquiteturas. Nas versões do bash anteriores ao 3.2, o efeito de comentar o argumento de expressão regular ao [[ operador =~ do comando não era especificada. O efeito prático era que comentar duas vezes o argumento padrão requeria "" para comentar caractéres especiais, que interferiam com o processamento da barra inversa realizada pela expansão da palavra duas vezes comentada.

Na versão bash 3.2, o shell foi mudado para citar internamente caractéres em argumentos de string únicos e duplicados ao operador =~, que suprime o significado especial dos caractéres que são importantes às expressões regulares processando (`.', `[', `\', `(', `), `*', `+', `?', `{', `|', `^', and `$') e os força a serem correspondidos literalmente. Isto é consistente em como o operador de correspondência padrão == trata as porções citadas de seu argumento padrão.
Já que o tratamento dos argumentos de strings citados foi mudado, diversos problemas podem acontecer, o principal deles é o problema de espaço em branco em argumentos padrões e a diferença de tratamento de strings citadas entre o bash 3.1 e o bash 3.2. Ambos os problemas podem ser resolvidos usando uma variável shell em todos os operadores do comando [[, ela fornece a habilidade de citar padrões que você desejar quando atribuir a variável, então expanda os valores a uma única string que pode conter espaços em branco. O primeiro problema pode ser resolvido usando "" ou qualquer outro mecanismo de citação para escapar os espaços em branco nos padrões.
O Bash 4.0 apresenta o conceito de um nível de compatibilidade, controlado por diversas opções ao shopt builtin. Se a opção compat31 estiver ativada, o bash reverterá para o comportamento do 3.1 em relação a citar o lado direito do operador =~.

9.3. Outras Mudanças de Pacotes

Pacotes Atualizados

A tabela seguinte lista os pacotes atualizados no Red Hat Enterprise Linux 6 e uma descrição de mudanças que valem a pena saber.

Tabela 9.1. Pacotes Atualizados

Pacote Atualizado Descrição
OProfile O OProfile foi atualizado para 0.9.5. Esta nova versão inclui suporte para processadores Intel Atom e i7, processadores da família AMD 11h, e o recurso Instruction Based Sampling (IBS) na família AMD 10h.
quota, edquota, setquota Agora aceitam um nome de usuário ou ID de usuário como um argumento. Se o argumento parece ser um número, ele será considerado um ID de usuário, caso contrário ele será traduzido para um ID automaticamente. Esteja atento que isto pode causar um problema se o nome do usuário consistir apenas de dígitos. O pacote quota foi atualizado. O argumento -x, que forçava o nome do usuário à tradução de ID em utilitários como quota, edquota e setquota foi removido. Esta funcionalidade é agora fornecida pela opção --always-resolve.
module-init-tools O /etc/modprobe.conf não existe por padrão. Ele pode ainda ser usado se criado manualmente.
Pacotes Descontinuados

A tabela seguinte lista os pacotes descontinuados (removidos) no Red Hat Enterprise Linux 6 e seus substitutos ou alternativas.

Tabela 9.2. Pacotes Descontinuados

Pacote Descontinuado Substituido por
aspell hunspell. O aspell é somente fornecido como uma dependência de construção. Aplicações que usam o spell-checking devem usar o hunspell.
beecrypt NSS/OpenSSL
crash-spu-commands Nenhum. Pacotes específicos Cell não são mais incluídos.
dhcpv6/dhcpv6-client Os binários dhcp/dhclient agora possuem capacidades IPv6 internas.
elfspe2 Nenhum. Pacotes específicos Cell não são mais incluídos.
exim Postfix
gnbd O iSCSI recomendado para uso no lugar.
gnome-vfs gvfs
ipsec-tools Openswan
kmod-gnbd O iSCSI recomendado para uso no lugar.
lam openmpi
libspe2 Nenhum. Pacotes específicos Cell não são mais incluídos.
libspe2-devel Nenhum. Pacotes específicos Cell não são mais incluídos.
linuxwacom xorg-x11-drv-wacom
mod_python O mod_wsgi, que usa a interface WSGI pode ser usada como uma alternativa para scripts Python.
mkinitrd dracut
nss_ldap nss-pam-ldapd, pam_ldap
openmotif-2.2 openmotif-2.3
spu-tools Nenhum. Pacotes específicos Cell não são mais incluídos.
switchdesk O gerenciamento de sessão realizado por ambos gerenciadores de sessão suportados: o GDM e o KDM.
syslog rsyslog
SysVinit upstart
vixie-cron cronie
Pacotes Obsoletos

  • qt3
  • GFS1
  • gcj - Incluído no Red Hat Enterprise Linux 6 para motivos de desempenho entretanto o gcj provavelmente não será incluído em futuros lançamentos.

9.4. Mudanças de Drivers

Esta seção descreve as mudanças de driver no Red Hat Enterprise Linux 6. Por favor observe que todos os drivers são agora carregados no initramfs por padrão.
Drivers Descontinuados

  • aic7xxx_old
  • atp870u
  • cpqarray
  • DAC960
  • dc395x
  • gdth
  • hfs
  • hfsplus
  • megaraid
  • net/tokenring/
  • paride
  • qla1280
  • sound/core/oss
  • sound/drivers/opl3/*
  • sound/pci/nm256

Drivers Obsoletos

  • aacraid
  • aic7xxx
  • i2o
  • ips
  • megaraid_mbox
  • mptlan
  • mptfc
  • sym53c8xx

Componentes do Kernel Descontinuados

  • NBD - Network Block Device substituido pelo iSCSI no Red Hat Enterprise Linux 6.
  • HFS - suporte ao sistema de arquivos Apple descontinuado no Red Hat Enterprise Linux 6.
  • Tux - acelerador de servidor web descontinuado no Red Hat Enterprise Linux 6.
  • Non-PAE x86 kernel - Versões anteriores do Red Hat Enterprise Linux continham múltiplos kernel para a arquitetura i686: um kernel com e um kernel sem PAE. Já fazem muitos anos desde que os hardwares sem PAE eram vendidos em volume. Por isso no Red Hat Enterprise Linux 6, há somente um kernel único, um que inclui o PAE.
  • O agendador de E/S atencipador está obsoleto e não está presente no Red Hat Enterprise Linux 6. Ele foi substituído pelo agendador de E/S CFQ (Completely Fair Queueing), que tem sido o agendador de E/S padrão no kernel do Linux desde 2006. Clientes que usam o agendador de E/S antecipador são encorajados a testar sua carga de trabalho usando o CFQ e bugs em arquivos para quaisquer problemas de desempenho observados. Enquanto o objetivo é fazer o CFQ realizar uma equivalência com o agendador de E/S antecipador em todos os teste de carga de trabalho. A Red Hat não pode garantir que não haverão discrepâncias.

9.5. Mudanças de Bibliotecas

Bibliotecas de 32-bits não são instaladas por padrão no Red Hat Enterprise Linux 6. Você pode mudar este comportamento definindo multilib_policy=all no /etc/yum.conf, que ativará a política multilib como uma política de sistema geral.

Apêndice A. Histórico de Revisão

Histórico de Revisões
Revisão 6.1-39.402Fri Oct 25 2013Rüdiger Landmann
Rebuild with Publican 4.0.0
Revisão 6.1-39.42012-07-18Anthony Towns
Rebuild for Publican 3.0
Revisão 6.1-39Wed May 18 2011Scott Radvan
Revisão para o lançamento 6.1

Nota Legal

Copyright © 2011 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.