Notas de Lançamento do Red Hat Enterprise Linux AS 4

A versão do glibc provida no Red Hat Enterprise Linux 4 efetua verificações internas de sanidade adicionais para evitar e detectar a corrupção de dados o quanto antes. Por padrão, se a corrupção for detectada, será apresentada uma mensagem similar à seguinte no erro padrão (ou autenticado via syslog se o stderr não for aberto):

*** glibc detected *** double free or corruption: 0x0937d008 ***

Por padrão, o programa que gerou este bug também será finalizado. No entanto, isto (e o fato de uma mensagem de bug ser gerada ou não) pode ser controlado pela variável de ambiente MALLOC_CHECK_. As configurações seguintes são suportadas:

Caso você tenha um programa de um ISV de terceiros que dispare estas verificações de corrupção e apresente uma mensagem, você deve submeter um relatório de defeito ao fabricante da aplicação, já que isso indica um bug sério.

O Red Hat Enterprise Linux 4 inclui um kernel conhecido como kernel hugemem. Este kernel suporta um espaço de usuário de 4GB por processo (contra 3GB de outros kernels) e um espaço do kernel direto de 4GB. Usar este kernel permite que o Red Hat Enterprise Linux rode em sistemas com memória principal de até 64GB. O kernel hugemen é necessário para poder usar toda a memória das configurações do sistema, contendo mais de 16GB. O kernel hugemen também pode beneficiar configurações rodando com menos memória (se rodar uma aplicação que pode ser beneficiada de maior espaço de usuário por processo, por exemplo).

Para instalar o kernel hugemen, digite o seguinte comando autenticado como root:

rpm -ivh <kernel-rpm>

            

(Onde <kernel-rpm> é o nome do arquivo RPM do kernel hugemem — kernel-hugemem-2.6.9-1.648_EL.i686.rpm, por exemplo).

Após completar a instalação, reinicialize seu sistema e certifique-se de selecionar o kernel hugemen recém-instalado. Após testar seu sistema para a operação correta, enquanto rodar o kernel hugemen, você deve modificar o arquivo /boot/grub/grub.conf para que o kernel hugemen seja inicializado por padrão.

Apesar do Red Hat Enterprise Linux 4 incluir suporte para o rawio, agora esta é uma interface não recomendada. Se a sua aplicação acessa o dispositivo usando esta interface, a Red Hat recomenda que você modifique sua aplicação para abrir o dispositivo em bloco com a sinalização O_DIRECT. A interface do rawio permanecerá durante o ciclo de vida do Red Hat Enterprise Linux 4, mas é candidata à remoção em versões futuras.

As operações I/O assíncronas (AIO) em sistemas de arquivo, são atualmente suportadas em O_DIRECT ou no modo sem buffer (non-buffered). Note também que a interface de detecção assíncrona não está mais presente e AIO em pipes não é mais suportada.

O subsistema de som agora é baseado na ALSA; os módulos OSS não estão mais disponíveis.

Os ambientes de sistema que utilizam a funcionalidade "hugepage" do kernel devem estar cientes que o nome da entrada /proc/ controlando esta funcionalidade foi alterado entre o Red Hat Enterprise Linux 3 e Red Hat Enterprise Linux 4:

O kernel distribuído com o Red Hat Enterprise Linux 4 agora inclui suporte para a detecção doDispositivo de Disco Aprimorado (EDD), que questiona as informações do dispositivo de disco inicializável no BIOS do controlador do disco e as armazena numa entrada do sistema de arquivo /sys.

Também foram adicionados duas opções importantes de comandos de linha relacionadas à EDD:

Esta versão incial do Red Hat Enterprise Linux 4 não suporta os drives de disco USB. No entanto, outros dispositivos de armazenamento USB, como mídia flash, CD-ROM e dispositivos de DVD-ROM são atualmente suportados.

O kernel distribuído no Red Hat Enterprise Linux 4 inclui o novo driver megaraid_mbox da LSI Logic, que substitui o driver megaraid. O driver megaraid_mbox tem melhor design, é compatível com o kernel 2.6 e inclui suporte para o hardware mais recente. Entretanto, o megaraid_mbox não suporta alguns hardware antigos, antes suportados pelo driver megaraid.

Os adaptadores com os seguintes pares de ID do fabricante e do dispositivo não são suportados pelo driver megaraid_mbox:

vendor, device

0x101E, 0x9010
0x101E, 0x9060
0x8086, 0x1960

O comando lspci -n pode ser usado para exibir os IDs dos adaptadores instalados numa determinada máquina. Os produtos com estes IDs são conhecidos pelos (mas não limitados aos) seguintes nomes de modelos:

Ambas empresas, Dell e LSI Logic, indicaram que não suportam mais estes modelos no kernel 2.6. Como resultado, estes adaptadores não são suportados no Red Hat Enterprise Linux 4.

A versão inicial do Red Hat Enterprise Linux 4 não inclui suporte ao alvo ou ao iniciador de software iSCSI. O suporte ao iSCSI está sendo avaliado para a adição numa atualização futura do Red Hat Enterprise Linux 4.

O driver Emulex LightPulse Fibre Channel (lpfc) está sob revisão pública para uma possível inclusão no kernel 2.6 do Linux. Está incluso no Red Hat Enterprise Linux 4 para fins de teste, e há previsão de alterações no driver. Se houver problemas com o driver ou, se por algum motivo, sua inclusão no kernel 2.6 do Linux não for indicável, o driver pode ser removido da versão final do Red Hat Enterprise Linux.

O driver lpfc atualmente, possui os seguintes problemas conhecidos:

No passado, o processo de atualização do kernel não alterava o kernel padrão na configuração do gestor de início do sistema.

O Red Hat Enterprise Linux 4 traz uma alteração neste comportamento para tornar kernels recém-instalados como padrão. Este comportamento se aplica a todos os métodos de instalação (inclusive rpm -i).

Este comportamento é controlado por duas linhas do arquivo /etc/sysconfig/kernel:

Para eliminar a redundância inerente ao suprimento de um pacote separado para o código fonte do kernel quando este código já existe no arquivo .src.rpm do kernel, o Red Hat Enterprise Linux 4 não inclui mais o pacote kernel-source. Os usuários que precisarem de acesso às fontes do kernel podem encontrá-las no arquivo kernel .src.rpm. Para criar uma árvore fonte expandida a partir deste arquivo, siga os passos seguintes (note que <versão> refere à especificação da versão do seu kernel corrente):

Então, você pode proceder normalmente.

obj-m    := foo.o

KDIR    := /lib/modules/$(shell uname -r)/build
PWD    := $(shell pwd)

default:
    $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

              

O Red Hat Enterprise Linux 4 inclui uma versão cliente de e-mail gráfico, Evolution. Esta versão adiciona diversas funcionalidades novas, inclusive:

O pacote gimp-perl foi removido do Red Hat Enterprise Linux 4 porque o GIMP foi atualizado para a versão 2.0 e os vínculos do Perl não estavam preparados nem faziam parte do pacote principal.

Usuários de scripts Perl no GIMP devem instalar o módulo Gimp Perl no site http://www.gimp.org/downloads/.

ja_JP.eucJP torna-se ja_JP.UTF-8

ko_KR.eucKR torna-se ko_KR.UTF-8

zh_CN.GB18030 torna-se zh_CN.UTF-8

zh_TW.Big5 torna-se zh_TW.UTF-8

Idiomas Indianos — iiimf-le-unit

Japonês — iiimf-le-canna

Coreano — iiimf-le-hangul

Chinês Simplificado — iiimf-le-chinput

Chinês Tradicional — iiimf-le-xcin

ami faz com que o iiimf-le-hangul seja instalado

kinput2 faz com que o iiimf-le-canna seja instalado

miniChinput faz com que o iiimf-le-chinput seja instalado

xcin faz com que o iiimf-le-xcin seja instalado

Por padrão, o agente de transporte de correio (MTA) do Sendmail não aceita conexões de rede de nenhuma máquina além do computador local. Se você quer configurar o Sendmail como um servidor para outros clientes, você deve editar o comando /etc/mail/sendmail.mc e alterar a linha DAEMON_OPTIONS para escutar dispositivos de rede também (ou desabilite completamente esta opção utilizando o delimitador de comentário dnl). Então você deve gerar novamente /etc/mail/sendmail.cf rodando o seguinte comando (como root):

criar -C /etc/mail

Note que você deve ter o pacote sendmail-cf instalado para que isto funcione.

Sob a configuração padrão de segurança do SELinux, o httpd é coberto pela norma direcionada. Isto aumenta a segurança e estabilidade do servidor Web ao permitir ou negar o acesso do httpd especificamente a objetos do sistema. Entretanto, como isto pode prejudicar configurações previamente operantes (como aquelas que usam PHP), você deve entender como o SELinux funciona para garantir que sua configuração seja funcional e segura.

Por exemplo: um booleano pode ser configurado para atribuir permissão específica para o httpd acessar objetos em ~/public_html/ desde que recebam o contexto de segurança httpd_sys_content_t. O daemon do Apache não pode acessar objetos (arquivos, aplicações, dispositivos e outros processos) que tenham um contexto de segurança com acesso não atribuído especificamente pelo SELinux para o httpd.

Ao permitir que o Apache acesse somente o que precisa para sua função, o sistema fica protegido de daemons httpd comprometidos ou mal-configurados.

Devido a necessidade de diretórios no padrão Linux, permissões de arquivos e etiquetas de contexto de arquivo no SELinux, os administradores e usuários terão que saber como reetiquetar arquivos. Exemplos de reetiquetagem incluem os seguintes comandos (um para reetiquetar o conteúdo de um diretório repetidamente e outro para reetiquetar um único arquivo):

chcon -R -h -t httpd_sys_content_t public_html
chcon -t httpd_sys_content_t public_html/index.html

            

Um arquivo ou diretório que não esteja etiquetado com um contexto da lista de tipos permitidos do Apache gerará um erro 403 Forbidden.

Você pode configurar valores Booleanos ou desativar seletivamente a cobertura da norma direcionada somente para o Apache (ou qualquer um dos daemons cobertos) usando system-config-securitylevel. Sob a aba SELinux, dentro da área Modificar Norma do SELinux, você pode modificar os valores Booleanos para o Apache. Se desejar, pode selecionar Desativar proteção do SELinux para o daemon httpd, que desativa a transição do unconfined_t (o tipo padrão que age transparentemente como a segurança padrão do Linux sem o SELinux) para o tipo específico do daemon; ex.: httpd_t. Desativar esta transição, efetivamente desliga a cobertura do SELinux para aquele daemon, retornando-o somente para a segurança padrão do Linux.

Para mais informações sobre a política do Apache e do SELinux, consulte o Guia da Política do Red Hat SELinux no site http://www.redhat.com/docs.

Por padrão, o daemon httpd agora é iniciado usando o locale C ao invés de usar o locale configurado do sistema. Este comportamento pode ser alterado modificando a variável HTTPD_LANG no arquivo /etc/sysconfig/httpd.

O arquivo de configuração /etc/php.ini padrão foi alterado para usar os padrões de "produção" ao invés dos padrões de "desenvolvimento". As diferenças notáveis são:

Agora o pacote usa o SAPI "apache2handler" para a integração com o httpd 2.0 do Apache ao invés do SAPI "apache2filter". Se você for atualizar versões anteriores, as diretivas SetOutputFilter devem ser removidas do arquivo /etc/httpd/conf.d/php.conf.

As seguintes alterações foram feitas no empacotamento dos módulos de extensão do PHP:

O Red Hat Enterprise Linux 4 inclui o novo pacote xorg-x11-deprecated-libs. Este pacote contém bibliotecas relacionadas ao X11 que não são recomendadas e que podem ser removidas de versões futuras do Red Hat Enterprise Linux. Ao empacotar bibliotecas não-recomendadas desta maneira, a compatibilidade binária com aplicações existentes é mantida enquanto oferece, aos fabricantes de software de terceiros, tempo para retirarem suas aplicações destas bibliotecas.

Atualmente, este pacote contém a biblioteca Xprint (libXp). Esta biblioteca não deve ser usada no desenvolvimento de novas aplicações. As aplicações que atualmente usam esta biblioteca devem começar a migrar para as APIs de impressão libgnomeprint/libgnomeprintui suportadas.

Houve um pouco de confusão em relação às questões de fonte sob o Sistema X Window nas versões recentes do Red Hat Enterprise Linux (e nas versões do Red Hat Linux anteriores). No momento, há dois subsistemas de fontes; cada um com características diferentes:

- O sub-sistema original (mais de 15 anos de idade) é referido como o "sub-sistema central de fonte X". As fontes administradas por este sub-sistema são arredondadas, administradas pelo servidor X e têm nomes como:

-misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1

O subsistema de fonte moderno é conhecido como "fontconfig" e permite às aplicações acesso direto aos arquivos de fonte. Fontconfig é comumente usado com a biblioteca "Xft", que permite às aplicações administrarem fontes fontconfig na tela com "antialiasing". Fontconfig usa nomes mais amigáveis como:

Luxi Sans-10

Com o passar do tempo, fontconfig/Xft irá substituir o sub-sistema central de fonte X. No momento, aplicações utilizando kits de ferramentas Qt 3 ou GTK 2 (inclusive aplicações do KDE e do GNOME) usam o sub-sistema de fonte fontconfig e Xft. Quase todas as outras usam as fontes centrais X.

Futuramente, o Red Hat Enterprise Linux talvez suporte somente fontconfig/Xft no lugar do servidor de fontes XFS como método padrão de acesso a fontes locais.

NOTA: Uma das exceções no uso do subsistema de fonte descrito acima é o OpenOffice.org (que usa sua própria tecnologia de administração de fontes).

Se você deseja adicionar novas fontes ao seu sistema Red Hat Enterprise Linux 4, deve estar ciente que os passos necessários dependem de qual é o subsistema usado nas novas fontes. Para o sub-sistema central de fonte X, você deve:

1. Criar o diretório /usr/share/fonts/local/ (se já não existe):

mkdir /usr/share/fonts/local/

2. Copiar o arquivo da nova fonte em /usr/share/fonts/local/

3. Atualizar as informações de fonte submetendo os seguintes comandos (note que, devido à restrições de formatação, os seguintes comandos podem aparecer em mais de uma linha; em seu uso, cada comando deve ser inserido numa única linha):

ttmkfdir -d /usr/share/fonts/local/ -o /usr/share/fonts/local/fonts.scale

mkfontdir /usr/share/fonts/local/

4. Se for necessário criar /usr/share/fonts/local/, você deve então adicioná-lo à localidade do servidor de fontes X (xfs):

chkfontpath --add /usr/share/fonts/local/

Adicionar fontes ao subsistema de fonte fontconfig é mais simples; o arquivo da nova fonte somente precisa ser copiado no diretório /usr/share/fonts/ (usuários individuais podem modificar sua configuração pessoal copiando o arquivo da fonte no diretório ~/.fonts/).

Após copiar a nova fonte, use fc-cache para atualizar o cache das informações de fonte:

fc-cache <diretório>

(Onde <diretório> será o diretório /usr/share/fonts/ ou ~/.fonts/).

Usuários individuais também podem instalar fontes graficamente, navegando em fonts:/// no Nautilus, e depois arrastando os arquivos das novas fontes para lá.

NOTA: Se o nome do arquivo da fonte termina com ".gz", este foi comprimido com gzip e deve ser descomprimido (com o comando gunzip) antes que o subsistema de fonte fontconfig possa usar a fonte.

Devido à transição para o novo sistema de fonte baseado no fontconfig/Xft, aplicações GTK+ 1.2 não são afetadas por quaisquer mudanças feitas através da caixa de diálogo Preferências de Fonte. Para estas aplicações, a fonte pode ser configurada adicionando as seguintes linhas ao arquivo ~/.gtkrc.mine:

style "user-font" {

fontset = "<especificação-da-fonte>"

}

widget_class "*" style "user-font"

(Onde <especificação-da-fonte> representa a especificação da fonte no estilo usado pelas aplicações tradicionais do X, tais como "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*".)

O conjunto completo de comandos do LVM2 agora é instalado em /usr/sbin/. Em ambientes de inicialização, onde /usr/ não está disponível, é necessário inserir /sbin/lvm.static antes de cada comando (/sbin/lvm.static vgchange -ay por exemplo).

Nos ambientes onde /usr/ está disponível, não é mais necessário incluir o prefixo lvm antes de cada comando (ex.: /usr/sbin/lvm vgchange -ay torna-se /usr/sbin/vgchange -ay).

Os novos comandos LVM2 (como /usr/sbin/vgchange -ay e /sbin/lvm.static vgchange -ay) detectam se você está rodando um kernel 2.4 e invocam transparentemente os comandos LVM1 antigos, se for apropriado. Os comandos LVM1 foram renomeados para finalizar com ".lvm1" (ex.: /sbin/vgchange.lvm1 -ay).

O daemon do cache do serviço de nomes nscd agora pode manter um cache persistente ao longo das reinicializações do sistema. Cada banco de dados (do usuário, grupo e máquina, respectivamente) pode ser selecionado para ser persistente, configurando a linha apropriada no arquivo /etc/nscd.conf como "yes". As entradas não são removidas do cache até que seja provado que estas não interessam mais. Todas as entradas cujo tempo de vida expiraram, mas são interessantes, são automaticamente recarregadas, beneficiando situações nas quais os serviços de diretórios e nomes tornam-se temporariamente indisponíveis.

Sob a configuração padrão de segurança do SELinux, este daemon é coberto pela norma direcionada. Isto aumenta a segurança ao permitir ou negar acesso especificamente aos objetos do sistema que o daemon usa normalmente. No entanto, como isto tem o potencial de prejudicar configurações previamente operantes, você deve entender como o SELinux funciona para garantir que sua configuração seja segura e funcional.

Para mais informações sobre a política do SELinux, consulte o Red Hat SELinux Guia de Política em http://www.redhat.com/docs.