Teste – Red Hat Enterprise Linux 6 Beta 1 e 2

Eu sei, eu sei. O RHEL6 Beta 1 saiu em Abril, e se não me engano, foi no dia 21 (não googlei pra confirmar). O Beta 2 saiu em junho, com uma atualização em julho. Mas estou trabalhando demais, e somente agora tive tempo para experimentar (e fazer uma análise) daquilo que virá. Testei as duas versões. As imagens ainda são baixáveis no FTP da Red Hat, tanto o primeiro quanto o segundo, e não se sabe até quando (provavelmente até o último estágio dos RCs, mas não é confirmado). O mirror é lento, e por isso o download é demorado. Apesar de tudo, tenho me divertido bastante na distribuição. Não quero ser pego desprevenido quando adquirirmos a versão 6 final e quando o CentOS 6 for entregue. Afinal, muitas coisas aconteceram no mundo Linux desde o lançamento do Red Hat 5 (que foi em 2007) pra cá.

Deixando de lero-lero. Gimme the tech specs!

As especificações são praticamente as mesmas do Fedora 12. Estou testando o RHEL6 como servidor, então, não instalei nenhum pacote oriundo do Fedora ou de repositórios externos. Então, o que obtive foi:

Kernel: 2.6.32-19.
GCC: 4.4-3
GLIBC: 2.11
Gnome: 2.28.2
X: 7.5.6
Yum: 3.2.27-12

BETA1 – Instalação e primeiras impressões do RHEL6

Após o download, criei uma máquina virtual no VMware vSphere 4.1. Setei o tipo da máquina virtual como “Red Hat Enterprise Linux 6 64-bit”, com quatro processadores, 4GB Ram e 20GB em disco. A imagem de instalação estava na mesma LUN do storage. Nesta definição, por padrão, o vSphere setou o driver de disco da máquina pra “VMware Paravirtual” e o driver de rede pra “VMXNET3”, algo que estranhei. Afinal, paguei pra ver se o driver de disco seria detectado na instalação uma vez que o “VMware Paravirtual” só costuma ser detectado após a instalação do vmware-tools, bem como o VMXNET3, cuja ausência me impediria de realizar uma instalação por rede. Instalação por rede, agora, não era o caso, então azar. Mas, chegou a hora da instalação e… Batata! Disco não encontrado – e nem a rede. Então, reconfigurei a controladora da máquina virtual pra “LSI Logical SAS”, reinicializei-a e a instalação aconteceu normalmente. Comecei com o pé esquerdo…

Mesmo assim, após isso, a instalação aconteceu às mil maravilhas. Não pediu serial como nas versões oficiais. Gostei da nova versão (?) do Anaconda, uma vez que ele ficou mais limpo, mais organizado e com um tema mais bonito. Entretanto, o particionamento ficou mais confuso. Não experimentei as opções padrão, e (como sempre), selecionei “personalizar”. Afinal, julgo o particionamento como a etapa mais importante da instalação. Todo o resto você repara depois via sistema, mas se o particionamento for ineficaz, ainda que use LVM, é mais trabalhoso (e arriscado) uma recuperação posterior.

Minha primeira surpresa foi agradável: Pela primeira vez, é possível instalar o RHEL6 oficialmente em XFS. Parece que finalmente a Red Hat escutou os clientes nesse aspecto, apesar de agora já existirem file systems mais modernos que este. Por default o sistema de arquivos recomendado é o EXT4, que foi o que utilizei. Criei uma /boot com 100MB, um Volume Group denominado “system” com 19.8GB e mais dois Logical Volumes: Um denominado “Swap”, de 512MB e outro denominado “root”, com o resto dos quase 19.5GB para montar a /. Não especifiquei /home, /var, /tmp ou /usr, pois nesse caso, pelo servidor ser virtualizado, não haverá sobrecarga de um ou mais discos (todos os volumes estão no storage, com RAID5, compartilhados com outras máquinas virtuais).

Prosseguindo a instalação, também gostei muito da nova organização dos pacotes. Unificou-se aquela burra divisão “Base” / “System” existente no Red Hat 5. Existe uma enorme (enorme!) quantidade de pacotes direto do DVD de instalação, mas isso se dá, provavelmente, pela distribuição ainda estar no Beta 1. No produto final, com certeza haverá a costumeira divisão de pacotes baseada em tipo de instalação (Server, Workstation e Virtualization). O resto foi automático, bastando setar a senha de root, timezone, hostname e etc. O sistema foi instalado perfeitamente e não achei nenhum bug.

Utilização

A primeira coisa que pensei após instalar foi: O sistema dá uma impressão de agilidade maior que o Red Hat 5. No entanto, o Red Hat 6 perdeu o bonito RHGB que o acompanhava na série 5, e disponível no Fedora de 6 a 9. Isso já era esperado, e ele foi substituído pelo Plymouth, que é mais flexível e também é bonitão, mas não carrega mais o X como o RHGB fazia, coisa que era legal pra fazer WinLoser pirar (“meu sistema sobe em modo gráfico e interativo, e o seu?“).

É, não dá mais. (Clica que aumenta!)

O desktop do Beta 1 continua com cara de Fedora, porém mais atual. Também quisera, né! 3 anos…

Instalei o VMware Tools, como de costume, que compilou absolutamente sem problemas. (No Red Hat 5 e CentOS 5, os módulos já não são mais compilados, uma vez que o instalador já carrega os módulos prontos pro kernel utilizado por ambas).

Sobre o BTRFS

Eu queria experimentar o BTRFS já nessa instalação, e não foi possível. Porém, após ler o draft do Migration Guide, verifiquei que existe uma opção à ser informada ao kernel e que disponibiliza o módulo do BTRFS para instalação. O uso é experimental, mas como estou usando pra “brincar”, deixei pra testar no Beta 2. Não iria reinstalar o Beta 1 “só” por isso. Se tiver mais um ou dois curiosos por aí, basta digitar “linux icantbelieveitsnotbtr”(wtf!?) ao selecionar o kernel no início da instalação.

BETA2 – Instalação e segundas impressões

Após dois dias de testes, chegou a hora de baixar o Beta 2 e acompanhar as mudanças que ocorreram nesse meio tempo. Ao chegar no mirror, surpresa: A mídia de instalação já havia sido modificada, e já disponibilizada como Server e Workstation. Baixei ambas, em versão do dia 15 de julho de 2010, mas até o momento, só fiz a instalação da versão Server. A Workstation eu utilizarei em algum desktop que eu achar sobrando por aqui.

As mudanças nessa versão se tornaram mais evidentes que na anterior. A interface gráfica foi alterada e está mais bonita. Passei a opção “icantbelieveitsnotbtr” pra testar o BTRFS, como deixei pendente no Beta 1, mas ao chegar no particionador, ainda não estava disponível. 😦

O Anaconda também ficou mais “a cara” da Red Hat. No instalador ele já solicita o cadastro da Red Hat Network para quem possuir uma conta de avaliação. Eu não tenho, então pulei essa parte. Todo o resto foi sem surpresas e sem alterações. Não reaproveitei nem o anaconda-ks.cfg da instalação anterior pra verificar se alguma feature foi alterada, e com exceção da RHN, não houve nenhuma outra modificação funcional, somente a arte. O nome “BETA” já não está mais tão estampado como no Beta 1, o que passa um ar mais sério ao sistema (apesar do WARNING) no início da instalação.

A mídia Server não está mais tão enxuta quanto o da série 5. Em comparação ao Beta 1, notei falta apenas do OpenOffice (que no Beta 3, se houver, provavelmente será substituído pelo LibreOffice), e cuja ausência é normal numa mídia de instalação Server. O Plymouth, por padrão, veio com um tema bem mais insosso que o do Beta 1, pra não dizer mais feio: apenas um anel girando durante o carregamento do sistema. Samara Morgan mandou dizer que a-do-rou. Eu não.

Alguns pacotes também sofreram atualização desde o Beta 1 (mesmo?). As versões de alguns deles:

Kernel: 2.6.44-1.
GCC: 4.4.4-10
GLIBC: 2.12-1.4
Gnome: 2.28.2
X: 7.7-17
Yum: 3.2.27-12

BETA 2 – Utilização

(Seven days.)

Após a instalação, configurei o yum habilitando os repositórios pro RHEL6 Beta, e instalei mais alguns temas pro Plymouth. Boot feio aqui não! Diferente do Beta 1, as pastinhas do Gnome agora são azuis e tem relevo. Déjà Vu? As ferramentas que ficaram foram as seguintes:

– system-config-authentication
– system-config-lvm
– system-config-date
– system-config-network (mas ela chama a system-config-network-tui)
– system-config-firewall (muitas alterações, eu gostei)
– system-config-kdump
– system-config-printer
– system-config-keyboard
– system-config-printer-applet
– system-config-kickstart
– system-config-services
– system-config-language
– system-config-users

O sistema já tinha um update de kernel disponível, e agora foi atualizado pro 2.6.32-44.2. As configurações do Apache continuam seguindo o (ótimo) padrão da Red Hat, o que vai garantir uma atualização tranquila para aqueles que seguem essa hierarquia. Pelo menos do ponto de vista do servidor web. Também não encontrei o gdm-setup, front-end que configura o gdm, em ambos os Betas, o que dificultou a configuração de login remoto diretamente via X.

Quebrando o gelo – RHEL5 x RHEL6

A primeira diferença que senti no Beta 1 foi ao configurar a interface de rede: CADÊ O SYSTEM-CONFIG-NETWORK? É um mundo cão, mas sim. Eles tiraram. 😦 Rapidamente fui ao system-config-services, encontrei o serviço de rede (network) ativo, corri pro /etc/sysconfig/networking e não encontrei nenhuma configuração de dispositivo. Segundo o draft de migração do RHEL5 para RHEL6, confirmei o que eu não queria ter visto: O system-config-network foi substituído pelo NetworkManager e seu nm-applet. Isso gerou conflito com os usuários, e algumas pessoas reclamaram no bugzilla a ausência do utilitário. Não deu outra, a comunidade venceu e a Red Hat reinseriu o system-config-network novamente na árvore do RHEL6. 😀 Mas, no Beta 1, não teve jeito. Fiquei sem.

De acordo com o mesmo documento (que está desatualizado), outras ferramentas de configuração também foram retiradas. Uma regressão no meu humilde ponto de vista. E isso se aplicou ao:

– system-config-boot
– system-config-network
– system-config-cluster
– system-config-http
– system-config-lvm (apesar que no meu, está instalado e funcionando bem. Sempre foi uma ótima ferramenta)
– system-config-netboot
– system-config-nfs
– system-config-bind (ok, era cheio de bug e eu preferia fazer na mão. Entendo que deve ser um saco parsear configuração do Bind. Mas não seria melhor ter consertado? Era uma ferramenta com muito potencial)
– system-config-samba
– system-config-soundcard (obsoleto por que agora o sistema detecta as placas de som automaticamente? Com o PulseAudio? Garanto, ESSA VAI FAZER FALTA).
– system-config-switchmail (obsoleto por que, segundo o manual, o novo MTA padrão é o Postfix. Comigo isso só se comprovou no Beta 2. No Beta 1 ainda era o Sendmail).

E outras ferramentas que foram reagregadas:

– system-config-securitylevel (melhorou, unificado no system-config-firewall)
– system-config-rootpassword (melhorou, unificado no system-config-users)
– system-config-display (essa melhorou, foi substituído pelo XRandr, que tem se mostrado excelente de um ano pra cá)

Eu entendo algumas das mudanças aí realizadas, mas são poucas. Bem poucas. Concordo que o system-config-http, system-config-nfs, system-config-samba e system-config-boot eram ferramentas extremamente básicas e sua manutenção levava tempo. Mas, se o RHEL já tem uma interface gráfica confortável de usar, não seria mais racional o incremento dessas ferramentas visando uma melhor integração do sistema como um todo? “mimimi eu só uso o modo texto” – Eu sei Flipper (Marcellus®), eu também. Mas ferramentas gráficas fazem MUITA diferença, principalmente pra gerentes, pseudo-administradores e alguns outros cargos administrativos. Os faz pensarem que sabem realizar qualquer tipo de configuração, tira a impressão de “modo texto é coisa do passado” (aham, fala isso pra IBM, CISCO, Oracle, Sun e etc) e dá um peso uma feature a mais pro sistema.

Das configurações que realizei, gostei do syslog ter sido substituído pelo rsyslog e já ter o plugin de integração com o PostgreSQL direto da instalação, é um dos meus principais recursos de monitoramento. Há vários plugins do Yum também disponibilizados direto dessa mídia. Outra alteração já prevista foi a adoção do upstart, existente no Fedora desde a versão 9, e agora trazida por padrão no Red Hat 6. Eu não gosto, mas humildemente entendo que é um caminho sem volta. Assim como em outras distribuições, as configurações do upstart ficam no /etc/init e disponíveis no man 8 init, man 5 init, e no caso dos Red Hats, /etc/sysconfig/init.

Testes que ainda vou realizar

Das coisas que realmente quero experimentar no RHEL6 são os novos recursos de virtualização, com a criticada e elogiada substituição do Xen pelo KVM. Eu realmente estou ansioso para testar o RHEL6 como hypervisor, pois desde o princípio, “fui mais com a cara” do KVM do que do Xen. Os motivos que tenho para isso são completamente pessoais, nem adianta vir com mimimi se você prefere o Xen. Eu sei usar bem a ambos, mas prefiro o KVM pela excelente integração com o kernel Linux em si, coisa que não acontece com o Xen. Isso não pode ser feito numa máquina virtual, então não posso testar por agora, mas vou aproveitar algum IBM x3400 que tenho sobrando aqui no trabalho desde que foram substituídos e brincar com a virtualização.

Considerações finais

Nenhuma. Tudo o que foi descrito foram conclusões minhas. Ainda tenho muita coisa pra testar, provavelmente escreverei outras coisas relacionadas a essa distribuição. Se você ficou com vontade de experimentar, aproveite a disponibilidade e faça os testes que julgar necessário. 🙂

Stay safe,
Lucas Timm.