Autor:Carlos E. Morimoto
Fonte:http://www.guiadohardware.net/tutoriais/centos/
O CentOS é uma versão gratuita do Red Hat Enterprise, gerado a partir do código fonte disponibilizado pela Red Hat e mantido de forma bastante competente por um grupo de desenvolvedores, que combina representantes de diversas empresas que utilizam o sistema (sobretudo empresas de hospedagem) e voluntários.
Ele é, basicamente, uma versão gratuita do RHEL, que possui um excelente histórico de segurança e conta com uma boa estrutura de suporte comunitário e atualizações pontuais de segurança, qualidades que o tornam uma das distribuições Linux mais populares em servidores, sobretudo em servidores web.
Se você está interessado na estabilidade do Red Hat Enterprise, ou precisa rodar softwares como o Oracle, que são suportados apenas nele, mas não tem como pagar caro pelo sistema, o CentOS é a sua melhor opção.
Red Hat x RHEL x CentOS x Fedora: Para quem está chegando agora, o Red Hat Linux foi uma das primeiras distribuições Linux a conquistar um grande público. A primeira versão foi lançado em 1994 e o sistema conseguiu ganhar espaço tanto entre os desktops (devido à relativa facilidade de uso) quanto entre os servidores, devido à boa estabilidade do sistema. O Red Hat Linux foi descontinuado em 2004, dando lugar ao Fedora, que é desenvolvido de forma colaborativa e às diferentes versões do Red Hat Enterprise (também chamado de RHEL), a versão comercial do sistema, destinada a grandes empresas.
O Red Hat Enterprise possui um ciclo de desenvolvimento mais lento (que prioriza a estabilidade) e tem suas versões suportadas por um período de nada menos do que 7 anos após o lançamento. Para quem está acostumado com o rápido ritmo de desenvolvimento das distribuições Linux domésticas, um sistema que é suportado por 7 anos pode soar estranho, mas dentro do ramo corporativo este é um diferencial importante, já que atualizar os desktops e os servidores é sempre um processo arriscado e caro (devido à mão de obra necessária, necessidade de treinar os funcionários, etc.), de forma que ciclos de desenvolvimento mais lentos e previsíveis são preferidos. Veja o caso do Windows, por exemplo, muitas empresas ainda usam servidores com o 2000 Server, ou mesmo com o NT 4.
O RHEL é fornecido apenas em conjunto com um plano de suporte e não pode ser redistribuído em seu formato binário. Entretanto, todo o código fonte está disponível, de forma que alguém que pacientemente compile cada um dos pacotes disponibilizados pela Red Hat, acaba obtendo uma cópia completa do sistema, que pode ser usada para todos os fins.
O CentOS nada mais é do que um Red Hat Enterprise compilado a partir do código fonte disponibilizado pela Red Hat, com os logotipos as marcas registradas removidas. Isso garante que os dois sistemas sejam binariamente compatíveis (ou seja, um software compilado para rodar no Red Hat Enterprise roda também na versão correspondente do CentOS sem precisar de modificações) e todos os passos de instalação e configuração dos dois sistemas são idênticos, o que faz com que toda a documentação do Red Hat Enterprise se aplique também ao CentOS.
Ao aprender a trabalhar com o CentOS, você automaticamente aprende a trabalhar com o Red Hat Enterprise e vice-versa. A grosso modo, podemos dizer que o Fedora é uma versão comunitária de desenvolvimento do Red Hat Enterprise, enquanto o CentOS é uma cópia praticamente exata do sistema.
Com relação às versões, o Red Hat Enterprise 4 foi baseado no Fedora Core 3, enquanto o Red Hat Enterprise 5 foi baseado no Fedora Core 6 e o Red Hat Enterprise 6 será baseado no Fedora 9. As versões do CentOS seguem as versões do Red Hat Enterprise, de forma que o CentOS 5 corresponde ao Red Hat Enterprise 5 e assim por diante:
Fedora Core 3 > Red Hat Enterprise Linux 4 > CentOS 4
Fedora Core 6 > Red Hat Enterprise Linux 5 > CentOS 5
Fedora 9 > Red Hat Enterprise Linux 6 > CentOS 6
Novas versões do Red Hat Enterprise são disponibilizadas a cada 18 ou 24 meses, mas recebem um grande volume de atualizações e correções de segurança durante este período. Isso leva ao lançamento de sub-versões com as atualizações pré-instaladas, como o Red Hat Enterprise 4.6 e o Red Hat Enterprise 5.1, que são sempre seguidas pelas versões correspondentes do CentOS.
Assim como o sistema principal, as atualizações e correções de segurança são disponibilizados pela equipe do CentOS, novamente através de pacotes compilados a partir dos códigos fontes disponibilizados pela Red Hat. As atualizações do CentOS são tipicamente disponibilizadas entre 24 e 72 horas depois das do Red Hat Enterprise (o que é impressionante considerando que se trata de um projeto voluntário), mas muitas atualizações críticas são disponibilizadas muito mais rápido, em poucas horas. Assim como o Red Hat Enterprise, todos os releases do sistema são suportados recebem atualizações de segurança por um período de 7 anos. Com isso, o CentOS 4 será suportado até 2012 e o CentOS 5 será suportado até pelo menos 2013.
A grande diferença entre o CentOS e o Red Hat Enterprise é a questão do suporte, já que, embora caro, o suporte oferecido pela Red Hat é bastante personalizado e os profissionais passam por um exame de certificação exigente (o RHCE) que mistura testes teóricos e práticos. Em servidores de missão crítica, usar o Red Hat Enterprise e pagar pelo suporte é geralmente uma boa opção, já que além de ajuda na implementação, você tem uma equipe pronta para agir em caso de problemas inesperados. Para os demais casos, você pode perfeitamente utilizar o CentOS contando com o suporte comunitário oferecido através dos fóruns do projeto.
O CentOS é também bastante similar ao Fedora, mas nesse caso as diferenças são mais evidentes, já que versões recentes do Fedora são baseadas em pacotes mais atuais, o que invariavelmente leva a mudanças no sistema. De qualquer forma, os passos básicos de instalação e a configuração geral dos dois sistemas são praticamente iguais, de forma que as dicas desse tópico se aplicam também ao Fedora.
Comparar o CentOS e o Fedora para uso em servidores desperta argumentos similares aos de uma comparação entre o Ubuntu e o Debian. O CentOS segue as versões do Red Hat Enterprise, que possui um ciclo de desenvolvimento muito mais longo, onde a principal preocupação é a estabilidade do sistema. O Fedora, por sua vez, é desenvolvido em torno de ciclos muito mais curtos, com uma nova versão sendo disponibilizada a cada 6 meses.
Por um lado isso é bom, já que você tem acesso a versões mais atuais dos pacotes, mas por outro lado é ruim, pois o lançamento mais freqüente de novas versões aumenta sua carga de trabalho como administrador, já que o sistema precisa ser atualizado mais freqüentemente.
Além de serem mais espaçadas, as versões do CentOS recebem atualizações de segurança por um período muito mais longo, que torna a vida útil das instalações muito maior. Um servidor rodando a versão mais atual do CentOS poderia ser mantido em serviço por até 7 anos, recebendo apenas as atualizações de segurança, o que não seria possível no Fedora, onde o suporte às versões antigas é encerrado muito mais rapidamente.
Em resumo, se você não se importa de utilizar softwares ligeiramente antigos e quer um servidor que ofereça um baixo custo de manutenção e possa ser usado durante um longo período sem riscos, o CentOS é mais recomendável. Se, por outro lado, você precisa de versões recentes do Apache, Samba ou outros serviços, ou se tem alguma preferência pessoal em relação ao Fedora, também pode utilizá-lo sem medo.
Embora o Fedora seja em teoria menos estável que o CentOS, ambas as distribuições podem ser considerados bastante estáveis. Poderíamos dizer que o CentOS é "99% estável" enquanto o Fedora é "98% estável". Ou seja, existe diferença, mas ela é relativamente pequena.
Instalando
Voltando à instalação, você pode baixar as imagens do sistema no http://www.centos.org/
Na versão 5.1, o sistema é distribuída tem nada menos do que 6 CDs de instalação (7 CDs na versão de 64 bits), mas, assim como no caso do Debian, é possível fazer uma instalação minimalista usando apenas o primeiro CD. Se baixar 4 GB não for um problema, você pode ganhar tempo baixando a versão em DVD.
Está disponível também o NetInstall, uma imagem de boot com apenas 7 MB para instalação via rede, onde o instalador baixa os pacotes necessários via HTTP, FTP ou NFS durante a instalação. É perfeitamente possível usar o NetInstall para fazer uma instalação via web, baixando apenas os pacotes que serão realmente usados (em vez de baixar o DVD inteiro), mas a menos que você tenha uma conexão muito rápida, ou esteja fazendo uma instalação minimalista, isso não é muito recomendável.
O mais comum é que o NetInstall seja usado para instalar vários servidores (imagine o caso de uma empresa de hospedagem, por exemplo) a partir de um mirror local. Para configurar um, você precisa apenas copiar todos os arquivos do DVD de instalação para uma pasta e compartilhar o conteúdo usando um servidor web ou FTP, informando o endereço IP do servidor e o diretório onde estão os arquivos ao instalar o sistema nas demais máquinas.
É possível ainda automatizar a instalação através do kickstart, um recurso disponível também no Fedora, onde você gera um arquivo de configuração, contendo instruções para o instalador e indica a localização do arquivo usando um parâmetro de boot, como em:
linux ks=http://192.168.1.254/ks.cfg
Este exemplo faz com que o instalador configure a rede via DHCP e tente acessar o arquivo através de um servidor web interno. É possível carregar o arquivo via NFS, FTP, usando um disquete ou mesmo gerar um CD de instalação personalizado, incluindo o arquivo. Ele é uma boa opção para ambientes onde você precisa realizar um grande número de instalações em pouco tempo. Você pode ver mais detalhes sobre ele aqui:
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/pt-BR/Installation_Guide/ch-redhat-config-kickstart.html
O CentOS utiliza o Anaconda, que é o mesmo instalador gráfico usado no Fedora. Para usar o instalador gráfico é necessário ter 512 MB de memória, mas é possível instalar o sistema em máquinas antigas usando o instalador em modo texto, que pode ser acessado usando a opção "linux text" na tela de boot:
Assim como em outras distribuições, você pode incluir opções para o Kernel na linha de boot, de forma a solucionar problemas de compatibilidade, como a "acpi-off", "noapic", "all-generic-ide", "irqpoll" e "outras", como em:
linux noapic irqpoll
O instalador começa se oferecendo para realizar um teste da mídia de instalação e em seguida pergunta sobre a linguagem do sistema (o português do Brasil está disponível desde as primeiras versões do sistema) e o layout do teclado.
Durante a instalação, você pode ver o log de mensagens geradas pelo instalador pressionando Ctrl+Alt+F3 e ter acesso a um terminal que pode ser usado para solucionar problemas pressionando Ctrl+Alt+F2.
Em seguida temos o particionamento dos HDs, que começa com a clássica pergunta sobre utilizar o layout padrão, ou criar um layout personalizado:
O CentOS utiliza o LVM por padrão, criando um único volume lógico, englobando todo o espaço disponível do HD e criando partições dentro dele. É usada também uma partição /boot separada, que fica fora do volume LVM, já que o grub não é capaz de inicializar o sistema se o diretório /boot estiver dentro de um volume lógico:
O LVM (Logical Volume Manager) é um recurso incluído no Kernel Linux a partir da versão 2.4 que cria uma camada de abstração entre o sistema operacional e os HDs (ou outras unidades de armazenamento utilizadas). Ele adiciona alguns complicadores adicionais na configuração, mas, em compensação oferece um conjunto de vantagens bastante interessantes.
Imagine que no LVM o sistema não vê HDs e partições, mas sim um ou mais volumes lógicos. Cada volume se comporta como se fosse uma partição, que é formatada e montada da forma usual (um volume pode ser usado inclusive como partição swap). Estes volumes são agrupados em um grupo de volumes lógicos (logical volume group) que se comporta de forma similar a um HD.
O pulo do gato é que o grupo de volumes lógicos pode combinar o espaço de vários HDs e ser modificado conforme necessário, incorporando mais HDs. Os volumes lógicos dentro dele também podem ser redimensionados livremente conforme for necessário.
Se você precisa de mais espaço dentro do volume referente à pasta home, por exemplo, você poderia reduzir o tamanho de um dos outros volumes do sistema (que estivesse com espaço vago) e aumentar o tamanho do volume referente ao home, tudo isso com o servidor operante.
Outra possibilidade é ir adicionando novos HDs ao servidor conforme precisar de mais espaço. Ao instalar um novo HD, você começaria criando um volume físico, englobando todo o espaço do HD. Uma vez que o volume físico é criado, você pode expandir o grupo de volumes lógicos, de forma que ele incorpore o espaço referente ao novo HD. A partir daí, você pode expandir os volumes lógicos, usando o espaço livre.
Caso seja utilizada uma controladora SCSI ou SAS com suporte a hot-swaping, é possível até mesmo adicionar, remover ou substituir HDs, fazendo as alterações necessárias nos volumes lógicos, tudo sem interrupções.
É importante enfatizar que o LVM é apenas uma mudança na forma como o sistema acessa os discos, ele não é um substituto para o RAID. No LVM você pode agrupar vários HDs em um único grupo de volumes lógicos, mas se um dos HDs apresentar defeito, o servidor ficará inoperante e você perderá os dados armazenados no disco afetado, diferente do RAID, onde você pode sacrificar parte do espaço para ter uma camada de redundância.
O grupo de volumes lógicos criado pelo instalador é visto pelo sistema como "/dev/VolGroup00" e os volumes lógicos dentro dele são vistos como "/dev/VolGroup00/LogVol00", "/dev/VolGroup00/LogVol01", etc. Estes nomes usados por default não são muito descritivos, mas é possível alterá-los usando o próprio particionador. Naturalmente, é possível também deixar de usar o LVM, voltando ao sistema normal de particionamento. Nesse caso você só precisa deletar os volumes e o grupo de volumes lógicos e criar a partições desejadas usando o espaço disponível.
Para o particionamento do HD, valem as regras que vimos no meu tutorial anterior sobre instalação de servidores Linux, ou seja, usar volumes separados para os diretórios "/tmp", "/var" e "/home", de acordo com a aplicação do servidor.
Em seguida temos a tela de configuração do gerenciador de boot. Diferente de um desktop, onde muitas vezes precisamos configurar o gerenciador para inicializar vários sistemas operacionais, em um servidor utilizamos sempre um único sistema, o que simplifica as coisas. Você pode rodar outros sistemas operacionais simultaneamente usando VMware Server ou o Xen, utilizando máquinas virtuais.
A opção "Utilizar uma senha no gerenciador de inicialização" define uma senha de boot, que é solicitada pelo grub no início do boot. Esta senha é raramente usada em servidores, pois impede que o servidor seja reiniciado sem que alguém esteja presente no local para digitar a senha no boot seguinte. Ela também não é eficiente como uma proteção contra acesso local do servidor, pois é facilmente burlável.
Em seguida temos a configuração da rede. Tanto ao configurar um servidor para a Internet quanto ao configurar um servidor de rede local, é muito provável que você configure também um domínio. Na Internet a função do domínio é obvia, já que é através dele que os visitantes acessarão os sites hospedados, mas um domínio pode ser útil também em uma rede local, facilitando o acesso às máquinas e viabilizando o uso de diversos serviços adicionais. Mesmo o Active Directory (utilizado em redes Microsoft) é fortemente baseado no uso de domínios.
Gerenciar nomes de domínio é tarefa para o Bind. Por enquanto, você pode se limitar a configurar o "fully qualified domain name" do servidor, ou seja, seu nome completo, incluindo o nome da máquina e o domínio que será utilizado, como em "centos.gdhn.com.br":
Depois de ajustar o fuso-horário e definir as senhas do sistema, chegamos à seleção dos pacotes que serão instalados. Todas as categorias disponíveis são opcionais, de forma que se você simplesmente desmarcar todas, fará uma instalação minimalista do sistema, em modo texto.
As categorias importantes no nosso caso são a "Server" (a seleção padrão de pacotes, incluindo o Samba, Apache, FTP, etc.) e, opcionalmente, a "Server-GUI", que instala o ambiente gráfico e as ferramentas gráficas de administração. É interessante ativar também o "Packages from CentOS Extras", que torna disponível um conjunto de pacotes adicionais, disponibilizados pela equipe do CentOS.
Marcando a opção "Personalizar agora" você tem acesso ao menu de seleção de pacotes. Se você marcou a categoria "Server-GUI" ou uma das categorias desktop, você notará que os pacotes referentes ao X, além do Gnome ou KDE e um conjunto de aplicativos gráficos estarão marcados.
Assim como o Fedora, o CentOS inclui um conjunto de aplicativos gráficos para configuração do sistema que podem ser úteis em muitas situações, de forma que muitos administradores preferem manter o ambiente gráfico instalado, mesmo em servidores que serão apenas acessados remotamente. Você pode perfeitamente manter os pacotes relacionados ao ambiente gráfico instalados, mas manter o ambiente gráfico inativo enquanto não o estiver usando (de forma a não consumir recursos do servidor).
Nas primeiras instalações, recomendo que desmarque os pacotes dentro da categoria "Servidores" e instale cada serviço manualmente, assim você pode estudar melhor o processo de configuração de cada um:
Diferentemente do Red Hat Enterprise, que possui versões distintas para servidores (Red Hat Enterprise Linux), servidores de missão crítica (Red Hat Enterprise Linux Advanced Platform) e para estações de trabalho (Red Hat Enterprise Linux Desktop), cada uma contendo uma coleção de pacotes específicos para as tarefas a que são destinadas, o CentOS é uma distribuição unificada, que simplesmente inclui todos os pacotes disponíveis nos repositórios.
Isso significa que, além de ser usado como servidor, que é o que estudaremos aqui, o CentOS também pode ser usado como sistema desktop, já que inclui o Gnome, KDE e um conjunto bastante completo de aplicativos que podem ser marcados durante a instalação.
Depois de concluída a cópia dos arquivos, é aberto um agente de configuração (que no RHEL é chamado de Red Hat Setup Agent), que conclui a configuração do sistema. Duas opções importantes são a configuração do firewall e do SELinux.
O configurador do firewall é na verdade um wizard, que permite que você selecione as portas referentes aos serviços que ficarão ativos no servidor (as portas selecionadas são abertas e todas as demais fechadas) e, a partir das respostas, gera as regras correspondentes para o IPtables, que é o firewall propriamente dito. Além das portas dos serviços padrão, você pode adicionar manualmente qualquer porta que precisar manter aberta. No exemplo estou abrindo a porta 901, usada pelo swat:
Você pode ajustar a configuração do firewall após a instalação através do utilitário "system-config-securitylevel" (disponível no Sistema > Administração > Nível de Segurança e Firewall). Existe também uma versão em modo texto do aplicativo, o "system-config-securitylevel-tui", que pode ser acessada via terminal (e inclusive remotamente, via SSH).
É possível também desativar a configuração do firewall e configurar as regras do IPtables manualmente, como veremos a seguir. Escrever um script de firewall é mais simples do que pode parecer à primeira vista.
Enquanto estiver estudando, recomendo que faça justamente isso; desativando o firewall na configuração e configurando o IPtables manualmente. Isso evita que você se depare com problemas inesperados introduzidos por portas fechadas no firewall. Depois que você entender a configuração manual do IPtables, pode voltar a configurar o firewall através do wizard caso prefira.
Continuando, temos o SELinux (Secure Linux), um sistema que visa reforçar a segurança do sistema, aplicando um conjunto de diretivas rígidas de segurança. O grande problema é que o SELinux interfere no funcionamento de um grande volume de serviços e de softwares adicionais, o que torna necessário criar exceções para cada caso.
Isso faz com que o modo "Enforcing" (Forçando) do SELinux seja aconselhável apenas em situações onde a segurança realmente seja um fator crítico e onde o administrador possua profundos conhecimentos do sistema, de forma a diagnosticar problemas causados pelas políticas de segurança e criar as exceções necessárias. Um meio termo é o nível "Permissive" (permissivo), onde o SELinux é aplicado apenas a alguns serviços específicos (o Apache e o Bind, por exemplo) e age apenas em relação a eles.
Mesmo sem o SELinux, o CentOS é uma distribuição bastante segura. Enquanto você estiver estudando sobre o sistema e utilizando-o em servidores de rede local, é interessante desativar o sistema. Com isso, você evita situações onde determinados serviços não estão funcionando (apesar da configuração estar correta) por causa das restrições do SELinux.
Para desativá-lo depois da instalação, edite o arquivo "/etc/selinux/config" e substitua a linha "SELINUX=enforcing" ou "SELINUX=permissive" por:
SELINUX=disabled
É necessário reiniciar o micro para que a alteração entre em vigor. O reboot demora alguns minutos, pois o sistema precisa realizar um conjunto de modificações nos arquivos.
A menos que você tenha manualmente desmarcado o pacotes "openssh-server" durante a instalação, o servidor SSH será instalado e ficará ativo por padrão, o que permite que você faça o restante da configuração do servidor remotamente:
$ ssh root@servidor
O arquivo de configuração do SSH no CentOS é o "/etc/ssh/sshd_config", o mesmo usado no Debian e no Ubuntu. O nome do pacote também é o mesmo, "openssh-server". A única diferença é que o script usado para controlar o serviço é o "/etc/init.d/sshd" e não "/etc/init.d/ssh".
Usando o yum
O yum (Yellow dog Update, Modified) é o gerenciador de pacotes usado por padrão no CentOS, no Fedora e no Red Hat Enterprise. O yum foi originalmente desenvolvido pela equipe do Yellow Dog (uma distribuição baseada no Red Hat, destinada a computadores com chip PowerPC) e foi sistematicamente aperfeiçoado pela equipe da Red Hat, até finalmente assumir o posto atual.
O yum trabalha de forma bem similar ao apt-get, baixando os pacotes a partir dos repositórios especificados nos arquivos de configuração, junto com as dependências necessárias. Assim como o apt-get, ele é capaz de solucionar conflitos automaticamente e pode ser também usado para atualizar o sistema. Essencialmente, o yum e o apt-get solucionaram o antigo problema das dependências (um pacote precisa de outro, que por sua vez precisa de um terceiro) que atormentava os usuários de distribuições mais antigas.
Existem muitas diferenças entre o CentOS e o Debian, uma delas é o formato dos pacotes utilizados: o CentOS utiliza pacotes .rpm, enquanto o debian utiliza pacotes .deb. Ambos também utilizam repositórios separados, com pacotes construídos especificamente para cada uma das duas distribuições, de forma que existem algumas diferenças nos nomes dos pacotes e arquivos de configuração usados.
Diferente do apt-get, onde você precisa rodar o "apt-get update" antes de cada instalação para atualizar a lista de pacotes, o yum faz a atualização automaticamente cada vez que uma instalação é solicitada, checando os repositórios, baixando os headers do pacotes e calculando as dependências antes de confirmar a instalação, como nesse exemplo:
Isso faz com que a instalação de pacotes usando o yum seja um pouco mais demorada que usando o apt-get. Ou seja, ganha-se de um lado mas perde-se do outro. :)
Para instalar um pacote, use o comando "yum install", como em:
# yum install mysql-server
Para removê-lo posteriormente, use:
# yum remove mysql-server
O yum possui também um recurso de busca, que é bastante útil quando você está procurando por um pacote, mas não sabe o nome exato, ou em casos de pacotes que possuem nomes diferentes em relação a outras distribuições. Use o comando "yum search", seguido por alguma palavra ou expressão, que faça parte do nome do pacote ou descrição, como em:
# yum search samba
Ele retorna um relatório contendo todos os pacotes relacionados, incluindo o texto de descrição de cada um. Isso resulta geralmente em uma lista relativamente longa. Para fazer uma busca mais restrita, procurando apenas nos nomes dos pacotes, use o parâmetro "list", como em:
# yum list httpd
Ele é bem menos falador, retornando apenas os pacotes que possuem "httpd" no nome, sem pesquisar nas descrições.
Uma terceira opção é a "provides" que mostra pacotes que incluem um determinado arquivo, pesquisando não no nome ou na descrição, mas sim no conteúdo dos pacotes. Ele é bastante útil em casos em que você precisa de alguma ferramenta ou biblioteca que faz parte de outro pacote maior, como em:
# yum provides mcedit
Em caso de dúvida, você pode verificar se um determinado pacote está instalado e qual é a versão usando o comando "rpm -q", como em:
# rpm -q samba
samba-3.0.25b-0.el5.4
Para atualizar um pacote já instalado, use o comando "yum update", como em:
# yum update samba
O comando "yum install" também pode ser usado para atualizar pacotes. A diferença entre o "install" e o "update" é que o "update" se limita a atualizar pacotes já instalados. Ao perceber que o pacote solicitado não está instalado, ele exibe um aviso e aborta a instalação, como no exemplo abaixo. Isso reduz a possibilidade de você acabar instalando um novo serviço por engano:
# yum update mysql-server
Loading "installonlyn" plugin
Setting up Update Process
Setting up repositories
Reading repository metadata in from local files
Could not find update match for mysql-server
Outra observação é que, depois de atualizar um serviço, é necessário recarregar o serviço (como em "service smb restart") para que a nova versão passe a ser usada. Esta é mais uma pequena diferença com relação às distribuições derivadas do Debian, onde os serviços são reiniciados de forma automática depois de atualizados.
Para atualizar todo o sistema, comece usando o parâmetro "check-update", que lista as atualizações disponíveis:
# yum check-update
Se usado sem especificar um pacote, o "update" vai atualizar de uma vez só todos os pacotes do sistema, de forma similar ao "apt-get upgrade" do Debian:
# yum update
Existe ainda o comando "yum upgrade", que é um pouco mais incisivo, incluindo também pacotes marcados como obsoletos (que não existem mais na versão atual). Ele é útil em casos em que é necessário atualizar uma versão antiga do sistema:
# yum upgrade
É possível também fazer com que o yum atualize o sistema automaticamente todas as madrugadas. Para isso, basta ativar o serviço "yum" e configurá-lo para ser ativado durante o boot:
# chkconfig yum on
# service yum start
Isso faz com que a atualização seja agendada através do cron e seja (por padrão) executada todos os dias às 4:02 da manhã, como especificado no arquivo "/etc/crontab".
Repositórios adicionais
A lista de repositórios usados pelo yum é dividida em diversos arquivos, organizados na pasta "/etc/yum.repos.d/". No CentOS, a parta inclui por padrão apenas dois arquivos: "CentOS-Base.repo" e "CentOS-Media.repo". O primeiro inclui os repositórios oficiais da distribuição, enquanto o segundo permite que você instale pacotes contidos nos CDs (ou no DVD) de instalação.
O arquivo "CentOS-Base.repo" contém diversas entradas como a abaixo, uma para cada repositório:
#released updates
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
Ao adicionar repositórios adicionais, você criaria novos arquivos dentro da pasta "/etc/yum.repos.d/", um para cada repositório adicional.O yum verifica os arquivos dentro da pasta cada vez que é executado, fazendo com que o novo repositório passe a ser usado automaticamente.
Normalmente, os responsáveis pelos repositórios disponibilizam arquivos de configuração prontos, que precisam ser apenas copiados para dentro da pasta "/etc/yum.repos.d". Para adicionar o repositório kbs-centos-extras, por exemplo, você baixaria o arquivo "kbsing-CentOS-Extras.repo", disponível no http://centos.karan.org/.
Assim como o apt-get, o yum utiliza chaves GPG para checar a autenticidade dos pacotes antes de fazer a instalação. Cada pacote é assinado digitalmente pelo desenvolvedor, o que atesta que o pacote foi realmente gerado por ele. Mesmo que alguém tentasse adulterar o pacote (incluindo um rootkit ou um script malicioso, por exemplo), não teria como falsificar também a assinatura, o que levaria o yum a reportar o problema e abortar a instalação.
Ao adicionar um novo repositório, é necessário adicionar também a chave pública do desenvolvedor, usando o comando "rpm --import", como em:
# rpm --import http://centos.karan.org/RPM-GPG-KEY-karan.org.txt
Normalmente, a URL com a chave pública GPG fica em destaque dentro da página com instruções de como adicionar o repositório.
Da mesma forma, para remover um repositório posteriormente, você removeria o arquivo da pasta, de forma que o yum deixe de usá-lo. É interessante também limpar o cache do yum, usando os comandos:
# yum clean headers
# yum clean packages
Plugins
O yum oferece também suporte a plugins, que permitem expandir as funcionalidades do gerenciador. Dois plugins bastante populares são o fastestmirror e o protectbase.
O fastestmirror faz com que o yum cheque a velocidade dos mirrors a cada instalação e baixe sempre os pacotes a partir do mirror mais rápido (evitando os problemas de lentidão que atingem muitos usuários), enquanto o protectbase faz com que o yum dê prioridade para os pacotes dos repositórios oficiais, evitando que eles sejam substituídos por pacotes de outros repositórios adicionados manualmente.
Para ativar o fastestmirror, basta instalar o pacote "yum-fastestmirror", como em:
# yum install yum-fastestmirror
Isso faz com que ele passe a ser usado automaticamente. Você notará que o yum passará a exibir duas mensagens adicionais durante cada operação:
Loading "fastestmirror" plugin
Loading mirror speeds from cached hostfile
Naturalmente, para que o fastestmirror possa escolher o repositório mais rápido a utilizar, é necessário que seja especificada uma lista de mirrors dentro da configuração de cada repositório na pasta "/etc/yum.repos.d". Você notará que as entradas referentes aos mirrors oficiais incluem uma linha "mirrorlist", que indica a localização de um arquivo com a lista dos mirrors disponíveis, como em:
[extras]
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
Ao adicionar novos repositórios manualmente, não se esqueça de pesquisar sobre a localização do arquivo com a lista dos mirrors, de forma a especificá-lo na configuração.
Para ativar o protectbase, instale o pacote yum-protectbase:
# yum install yum-protectbase
Para que ele se usado, é necessário adicionar a linha "protect=1" ou "protect=0" na configuração de cada um dos repositórios incluídos na pasta "/etc/yum.repos.d". Os repositórios com o "protect=1" serão protegidos pelo protectbase, evitando que os pacotes sejam substituídos por pacotes de versões mais recentes incluídos nos repositórios adicionais. Com isso, os repositórios adicionais passam a realmente ser usados apenas para instalar pacotes que não fazem parte dos repositórios principais, reduzindo bastante a possibilidade de problemas ao usar repositórios não-oficiais.
É importante proteger pelo menos os repositórios "base" e "updates", dentro do arquivo "/etc/yum.repos.d/CentOS-Base.repo", como em:
[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
protect=1
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
protect=1
As demais entradas devem receber a opção "protect=0", como em:
[rpmforge]
name = Red Hat Enterprise $releasever - RPMforge.net - dag
#baseurl = http://apt.sw.be/redhat/el5/en/$basearch/dag
mirrorlist = http://apt.sw.be/redhat/el5/en/mirrors-rpmforge
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1
protect = 0
