Usando Cobbler para gerenciar e automatizar a instalação de sistemas

Cobbler torna mais fácil a configuração e administração de um ambiente de instalação via rede

Cobbler é uma ferramenta que procura centralizar as diferentes tarefas envolvidas na configuração e administração de um servidor de instalação de maneira a facilitar o provisionamento de sistemas.

Paulo de Rezende Pinatti, Staff Software Engineer, IBM

Paulo de Rezende PinattiPaulo de Rezende Pinatti

Engenheiro de software na IBM com 10 anos de experiência em computação, atualmente trabalha no desenvolvimento de ferramentas para sistemas de virtualização (Openstack, oVirt). Formado em Ciência da Computação, já trabalhou no desenvolvimento de toolkits de instalação e configuração de Linux em máquinas IBM POWER, boot loaders, desenvolvimento para web, administração de sistemas, e outros.
Perfil My DeveloperWorks



25/Jun/2013

Introdução

O processo de configurar um ambiente de rede para instalação de máquinas pode envolver vários passos diferentes até que tudo esteja pronto para realizar o boot de uma máquina via rede e iniciar uma instalação. Serviços como dhcp, tftp, dns, http, ftp, nfs precisam ser configurados, entradas individuais de cada máquina cliente precisam ser inseridas nos arquivos de configuração de dhcp e tftp, arquivos de provisionamento automatizado do sistema operacional (tais como kickstart, autoinst, etc.) precisam ser criados, mídias de instalação precisam ser extraídas para repositórios http/ftp/nfs, dentre outras tarefas. Não é um processo direto e por vezes é cansativo manualmente registrar cada máquina cliente que precisa ser provisionada. Qualquer mudança de parâmetro, como um sistema operacional diferente a ser usado, demanda intervenção manual na configuração e possivelmente em arquivos de provisionamento (kickstart por exemplo). Quando o número de máquinas começa a crescer, certos pontos como o diretório tftp podem se tornar confusos quando não há forte atenção à organização da estrutura de arquivos.

Nesse cenário, Cobbler busca ser uma solução para endereçar os problemas citados através da criação de um ponto central de gerenciamento de todos os aspectos relacionados ao provisionamento de uma máquina: ele reconfigura serviços, cria repositórios, extrai mídias de sistemas operacionais, atua ou se integra com um sistema de gerenciamento de configuração (CMS), controla sistemas de gerenciamento de energia, e outros. Cobbler cria uma camada de abstração na qual você pode rodar comandos como "adicione novo repositório" ou "mude o sistema operacional de uma máquina cliente" e ele se encarrega de tudo: criação/atualização de arquivos de configuração, reiniciar serviços, extrair mídias para repositórios recém criados. A intenção é esconder todas as questões relativas ao sistema de forma a permitir ao usuário focar na tarefa a ser feita em si.

Esse artigo cobrirá como a ferramenta Cobbler é estruturada, as funcionalidades principais disponíveis e exemplos de como usá-las para realizar o provisionamento de uma máquina de maneira fácil e rápida. Na seção a seguir, começaremos discutindo as funcionalidades disponíveis na ferramenta.


O que a ferramenta oferece

A principal função do Cobbler é automatizar a instalação e configuração de máquinas, sem a necessidade de intervenções manuais. Ele permite isso configurando um ambiente de boot PXE (ele também suporta PowerPC usando yaboot) e controlando todos os aspectos relacionados à instalação tais como serviços de boot via rede (dhcp e tftp) e espelhamento de repositórios.

Quando você deseja instalar uma nova máquina, o que o Cobbler basicamente faz é:

  • usa um template previamente definido para configurar o serviço dhcp (caso o gerenciamento de dhcp esteja habilitado);
  • espelha um repositório (yum ou rsync) ou extrai uma mídia para registrar um novo sistema operacional;
  • cria uma entrada no arquivo de configuração do dhcp para a máquina a ser instalada usando os parâmetros especificados pelo usuário (endereços IP e MAC);
  • cria os arquivos PXE apropriados sob o diretório do serviço tftp;
  • reinicia o serviço dhcp para refletir as mudanças;
  • reinicia a máquina para iniciar a instalação, caso o gerenciamento de energia esteja habilitado.

A ferramenta tem um bom alcance de distribuições Linux suportadas: Red Hat, Fedora, CentOS, Debian, Ubuntu e SuSE. Ao adicionar um novo sistema operacional (geralmente através de uma imagem ISO) ela sabe como extrair os arquivos apropriados e ajustar os serviços de rede para corretamente realizar o boot das máquinas.

Cobbler suporta templates de arquivos de provisionamento do tipo kickstart. Arquivos kickstart são usados por sistemas baseados em Red Hat e Fedora para automatizar o processo de instalação. Através do uso desta função, você pode ter templates kickstart base e definir como as variáveis são substituídas neles de acordo com a configuração de um perfil ou máquina. Por exemplo, um template pode conter duas variáveis $domain e $machine_name. Na configuração do Cobbler, um determinado perfil especifica domain=mydomain.com e cada máquina que usa esse perfil especifica seu nome na variável machine_name. Todas as máquinas desse perfil serão instaladas usando o mesmo kickstart configurado para domain=mydomain.com e cada uma terá o seu próprio nome de máquina, enquanto o template kickstart ainda pode ser usado para instalar outras máquinas com diferentes domains e nomes de máquina.

Para auxiliar no gerenciamento de sistemas, o Cobbler pode se conectar a uma variedade de ambientes de gerenciamento de energia utilizando fence scripts. Ele suporta apc_snmp, bladecenter, bullpap, drac, ether_wake, ilo, integrity, ipmilan, ipmitool, lpar, rsa, virsh, e wti. Em qualquer momento que você desejar reinstalar uma máquina, você pode apenas rodar um comando "reinicie o sistema meusistema" e o Cobbler se encarrega de rodar para você o fence script apropriado usando as informações (como número da baia) e credenciais necessárias.

Além das funcionalidades acima, Cobbler também provê funcionalidades de um sistema de gerenciamento de configuração (CMS). Há duas opções: um sistema interno próprio ou integração com um CMS externo existente, tal como Chef ou Puppet. Utilizando o sistema interno é possível especificar templates de arquivo que serão processados baseados em parâmetros de configuração (da mesma maneira que os templates kickstart) e copiados para o local onde você determinar. Isso é muito útil quando há a necessidade de instalar arquivos de configuração para máquinas específicas de maneira automatizada.

Cobbler pode também trabalhar em conjunto com um cliente chamado koan para realizar o provisionamento de máquinas virtuais e reinstalação de sistemas a partir do lado cliente.

Por estar fora do foco deste artigo, as funcionalidades de gerenciamento de configuração e koan não serão abordadas. Ainda assim, são funcionalidades bastante úteis que valem a pena ser exploradas pelo leitor.


Como o Cobbler é estruturado

A estrutura de configuração do Cobbler é baseada em um conjunto de objetos registrados no qual cada um representa uma entidade associada a uma outra (aponta para ou é apontada por outra). Quando um objeto aponta para outro, ele herda os dados do objeto apontado e pode sobrescrever ou adicionar informações mais específicas. Os seguintes tipos de objetos são definidos:

  • Distribution (distribuição): representa um sistema operacional, carrega informações a respeito do kernel e initrd bem como outros dados como parâmetros de kernel.
  • Profile (perfil): aponta para uma distribuição, um arquivo kickstart e possivelmente repositórios, além de outros dados como parâmetros de kernel mais específicos.
  • System (sistema): representa uma máquina a ser provisionada, aponta para um perfil ou uma imagem e possui informações sobre endereços IP e MAC, gerenciamento de energia (endereço, credenciais, tipo) e dados mais específicos.
  • Repository (repositório): carrega informação de espelhamento de um repositório yum ou rsync.
  • Image (imagem): pode ser utilizado no lugar de um objeto de distribuição para arquivos que não se encaixam nessa categoria (por exemplo não podem ser divididos em kernel e initrd).

Baseado nos objetos registrados e na associação entre eles, o Cobbler sabe como mudar o sistema de arquivos para refletir essa configuração. Isso é muito útil pois abstrai os detalhes de configuração do sistema e permite ao usuário focar no que ele quer que seja feito.

Figura 1. Relacionamento entre objetos
Relacionamento entre objetos

Usando o Cobbler

Agora que você conhece e entende suas funcionalidades, é chegada a hora de aprender como utilizar o Cobbler. Existem algumas opções disponíveis para configurar e utilizar a ferramenta: linha de comando, API, XML-RPC e interface gráfica web. Vamos focar primariamente na opção de linha de comando.

Cobbler possui pacotes disponíveis para as distribuições Fedora, RHEL, CentOS (os dois últimos através do repositório EPEL 1), Ubuntu e OpenSuse. Nesse artigo as instruções serão baseadas em um sistema Fedora e são facilmente ajustáveis para outro sistema conforme necessário.

Vamos começar instalando a ferramenta e o pacote fence-agents, que é usado pelo Cobbler para realizar atividades de gerenciamento de energia. Como usuário root, entre o seguinte comando de instalação do gerenciador de pacotes da distribuição:

yum -y install cobbler fence-agents

Uma vez instalado, inicie os serviços necessários:

service cobblerd start

service httpd start

Você pode testar se o Cobbler está rodando corretamente digitando cobbler check. Esse comando é usado para reportar alguns pontos de configuração que podem precisar ser ajustados. Não se preocupe com eles; é apenas um guia para ajudar os usuários e nós vamos configurar os aspectos relevantes ao longo dessa seção (apenas fique atento os avisos relativos a ajustes de SELinux, nesse caso siga as instruções do Cobbler). Se você por acaso receber alguma mensagem de erro de conexão, verifique se os serviços foram iniciados corretamente e também os logs de SELinux, caso ele esteja ativo. Você pode precisar definir o booleano SELinux httpd_can_network_connect_cobbler como true (setsebool -P httpd_can_network_connect_cobbler 1). Se esse for o caso, lembre-se de reiniciar os serviços depois disso.

Dependendo da necessidade, o Cobbler pode ser configurado para gerenciar apenas certos serviços. Por exemplo, você pode administrar um servidor de arquivo mas o dhcp é servido por outra máquina na rede a qual você não tem acesso. Nesse caso o administrador do dhcp pode definir a opção filename com o objetivo de solicitar um arquivo de boot (pxelinux.0 para x86 ou yaboot para PowerPC) e a opção next_server para apontar para o endereço IP do seu servidor de arquivo, fazendo com que as máquinas na rede durante o processo de boot solicitem o arquivo do seu servidor. Você então configura o Cobbler para gerenciar o serviço tftp e registra as máquinas para que ele sirva os arquivos apropriados para elas.

____________________________
1 EPEL significa Extra Packages for Enterprise Linux. Trata-se de um conjunto de pacotes mantidos pela comunidade Fedora que não estão incluídos nas distribuições Linux Enterprise Red Hat Enterprise Linux (RHEL), CentOS e Scientific Linux (SL). Maiores informações podem ser encontradas em http://fedoraproject.org/wiki/EPEL.

Neste artigo vamos configurar o Cobbler para gerenciar todos os serviços, o que é um cenário comum e nos permite entender como configurá-los. O arquivo de configuração principal do Cobbler é /etc/cobbler/settings, abra-o com o seu editor de texto e defina as seguintes opções:

  • manage_dhcp: 1
  • manage_dns: 1
  • manage_tftpd: 1
  • restart_dhcp: 1
  • restart_dns: 1
  • pxe_just_once: 1
  • next_server: <endereço IP do servidor>
  • server: <endereço IP do servidor>

As opções manage_* e restart_* são auto-explicativas, a opção next_server é usada no arquivo de configuração dhcp para dizer às máquinas qual é o endereço do servidor para o qual elas devem solicitar o arquivo de boot, e a opção server é usada durante a instalação das máquinas para indicar o endereço do servidor Cobbler. Finalmente, a opção pxe_just_once é usada para prevenir loops de instalação em máquinas configuradas para sempre realizar o boot pela rede. Quando essa opção é ativada existe um mecanismo no qual a máquina avisa ao Cobbler que a instalação terminou e este muda o indicador netboot do objeto sistema correspondente para false, forçando a máquina a realizar o boot pelo disco local. Faremos uso disso mais adiante no exemplo prático.

Agora que o Cobbler sabe quais serviços gerenciar, precisamos dizer quais programas serão usados para eles. As opções são:

  • DHCP: ISC dhcpd ou dnsmasq
  • DNS: BIND ou dnsmasq
  • TFTP: in.tftpd ou tftp interno do Cobbler

Vamos utilizar dnsmasq para dhcp e dns pela sua facilidade de configuração e in.tftpd por ser o padrão do sistema. Edite o arquivo /etc/cobbler/modules.conf com os seguintes parâmetros:

[dns]
module = manage_dnsmasq

[dhcp]
module = manage_dnsmasq

[tftpd]
module = manage_in_tftpd

Cobbler usa um template para criar arquivos de configuração para os serviços. É necessário editar o template do dnsmasq em /etc/cobbler/dnsmasq.template para ajustar as informações de rede tais como a faixa de endereços IP a ser usada e o endereço do gateway. Assumindo que o servidor rodando Cobbler é também o gateway e nossa faixa IP é 192.168.122.5-192.168.122.254, insira 'dhcp-range=192.168.122.5,192.168.122.254,255.255.255.0' no arquivo. Geralmente é desejável bloquear o boot de clientes não registrados pelo servidor. Você pode fazer isso adicionando o parâmetro 'dhcp-ignore=tag:!known'2. O conteúdo do arquivo deve ser semelhante ao abaixo:

# Cobbler generated configuration file for dnsmasq
# $date
#

# resolve.conf .. ?
#no-poll
#enable-dbus

read-ethers
addn-hosts = /var/lib/cobbler/cobbler_hosts

dhcp-range=192.168.122.5,192.168.122.254,255.255.255.0
dhcp-ignore=tag:!known
dhcp-option=3,$next_server
dhcp-lease-max=1000
dhcp-authoritative
dhcp-boot=pxelinux.0
dhcp-boot=net:normalarch,pxelinux.0
dhcp-boot=net:ia64,$elilo

$insert_cobbler_system_definitions

Cobbler está quase pronto para uso. É preciso reiniciar o serviço e sincronizar as mudanças com o sistema de arquivos para elas tenham efeito. Lembre-se de reiniciar o serviço xinetd para que o tftp esteja disponível. Execute os comandos:

service cobblerd restart

cobbler sync

service xinetd restart

Nesse ponto você pode começar a adicionar distribuições, repositórios, criar perfis e registrar sistemas. Certifique-se de verificar a configuração do firewall para permitir tráfego nas portas utilizadas pelos serviços de rede tftp, dhcp e http/https.

Vamos preparar o Cobbler para instalar sistemas Fedora 17 com duas opções disponíveis: desktop xfce ou gnome. Iniciamos adicionando uma árvore de instalação Fedora por meio da extração do conteúdo de uma mídia ISO previamente baixada (você pode apontar o Cobbler diretamente para repositórios de rede também). Execute os seguintes comandos: 3

mount -o loop /Fedora-17-x86_64-DVD.iso /mnt/iso

cobbler import --arch=x86_64 --path=/mnt/iso --name=Fedora17

A operação pode levar algum tempo para terminar pois o Cobbler copia o conteúdo da mídia para o sistema de arquivos. O comando cobbler import é muito útil pois ele automaticamente cria um objeto distribuição e um objeto perfil para você. O resultado deve ser semelhante ao abaixo:

____________________________
2 Em versões mais antigas a sintaxe pode ser diferente: 'dhcp-ignore=#known'. Na dúvida você pode inserir as duas juntas.
3 Existe um problema conhecido no qual o Cobbler não consegue visualizar o conteúdo do diretório montado e falha ao importar a mídia. Se isso acontecer com você a solução é reiniciar o serviço do Cobbler depois de rodar o comando mount.

cobbler distro report
Name                           : Fedora17-x86_64
Architecture                   : x86_64
TFTP Boot Files                : {}
Breed                          : redhat
Comment                        :
Fetchable Files                : {}
Initrd                         : /var/www/cobbler/ks_mirror/Fedora17-
x86_64/images/pxeboot/initrd.img
Kernel                         : /var/www/cobbler/ks_mirror/Fedora17-
x86_64/images/pxeboot/vmlinuz
Kernel Options                 : {}
Kernel Options (Post Install)  : {}
Kickstart Metadata             : {'tree': 'http://@@http_server@@/cblr/links/Fedora17-
x86_64'}
Management Classes             : []
OS Version                     : generic26
Owners                         : ['admin']
Red Hat Management Key         : <<inherit>>
Red Hat Management Server      : <<inherit>>
Template Files                 : {}

cobbler profile report

Name                           : Fedora17-x86_64
TFTP Boot Files                : {}
Comment                        :
DHCP Tag                       : default
Distribution                   : Fedora17-x86_64
Enable gPXE?                   : 0
Enable PXE Menu?               : 1
Fetchable Files                : {}
Kernel Options                 : {}
Kernel Options (Post Install)  : {}
Kickstart                      :
Kickstart Metadata             : {}
Management Classes             : []
Management Parameters          : <<inherit>>
Name Servers                   : []
Name Servers Search Path       : []
Owners                         : ['admin']
Parent Profile                 :
Proxy                          :
Red Hat Management Key         : <<inherit>>
Red Hat Management Server      : <<inherit>>
Repos                          : []
Server Override                : <<inherit>>
Template Files                 : {}
Virt Auto Boot                 : 1
Virt Bridge                    : xenbr0
Virt CPUs                      : 1
Virt Disk Driver Type          : raw
Virt File Size(GB)             : 5
Virt Path                      :
Virt RAM (MB)                  : 512
Virt Type                      : qemu

Esse perfil será o pai de outros dois que iremos criar para cada desktop que queremos instalar. Antes disso, vamos considerar que temos um repositório yum com pacotes adicionais que gostaríamos de usar em nossas instalações. Para fazer isso, nós criamos um objeto repositório:

cobbler repo add --arch=x86_64 --name=Flash-plugin  
--mirror=http://linuxdownload.adobe.com/linux/x86_64/

cobbler reposync

cobbler repo report

Para a URL do repositório yum, Cobbler suporta http://, ftp://, rsync://, caminhos do sistema de arquivos e locais ssh (usando autenticação por chave privada). A operação reposync é muito importante pois ela realiza a cópia em si dos arquivos do repositório remoto. Se você criar o objeto repositório mas não executar o reposync você acabará com um repositório vazio e sua instalação vai provavelmente falhar.
Para completar a ativação do repositório ele precisa ser associado a um perfil. Associamos ao perfil do Fedora com o comando:

cobbler profile edit --name=Fedora17-x86_64 --repos=Flash-plugin

É hora de criar os perfis. Para tornar a instalação automática precisamos especificar um arquivo kickstart a ser usado. É aqui que a funcionalidade de template kickstart entra em cena. Vamos criar um simples kickstart baseado nos disponíveis em /var/lib/cobbler/kickstarts e definir na seção %packages uma variável $desktop_pkg_group, a qual será posteriormente substituída para determinar quais pacotes desktop serão instalados. O kickstart terá o seguinte conteúdo:

# System bootloader configuration
bootloader --location=mbr
# Partition clearing information
clearpart --all --initlabel
# Run the Setup Agent on first boot
firstboot --disable
# Activate X
xconfig --startxonboot
# Use network installation
url --url=$tree
# additional repostories get added here
$yum_repo_stanza
# Reboot after installation
reboot
# System keyboard
keyboard us
# System language
lang en_US
# System timezone
timezone  America/New_York
# Root password
rootpw --iscrypted $default_password_crypted
# Install OS instead of upgrade
install
# Clear the Master Boot Record
zerombr
# Allow anaconda to partition the system as needed
autopart

%packages
@base
@base-x
firefox
flash-plugin
$desktop_pkg_group
%end

%post
# create a default user to log in X
useradd desktop-user
passwd -d desktop-user

# adds the yum repositories to the installed system
$yum_config_stanza
# cobbler final steps
$SNIPPET('kickstart_done')
%end

As variáveis que começam com $ são substituídas pelo programa Cheetah4 que o Cobbler usa para processar seus templates. Se você está familiarizado com o uso de templates Cheetah, as regras são as mesmas. Você pode aprender mais a respeito das variáveis internas do Cobbler como $yum_config_stanza olhando os kickstarts disponíveis em /var/lib/cobbler/kickstarts.
Depois de criar o arquivo, copie-o para /var/lib/cobbler/kickstarts, caso contrário o Cobbler pode falhar ao tentar usá-lo. Com o arquivo kickstart pronto, você pode perguntar: como o Cobbler vai saber qual é o valor de $desktop_pkg_group? Nós definimos isso quando criamos os perfis usando a opção --ksmeta. Ela permite que você determine o valor a ser utilizado na substituição da variável no template kickstart. Esses são os comandos para criar os perfis para xfce e gnome:

cobbler profile add --name=Fedora17-xfce \
--ksmeta='desktop_pkg_group=@xfce-desktop' \
--kickstart=/var/lib/cobbler/kickstarts/example.ks \
--parent=Fedora17-x86_64
cobbler profile add --name=Fedora17-gnome \
--ksmeta='desktop_pkg_group=@gnome-desktop' \
--kickstart=/var/lib/cobbler/kickstarts/example.ks \
--parent=Fedora17-x86_64
cobbler profile report

Note que o parâmetro --parent diz para esses perfis herdarem do perfil Fedora, o que significa que eles utilizarão a distribuição Fedora e o repositório adicional Flash-plugin. Você pode verificar como será o conteúdo do kickstart depois do processamento para ter certeza que tudo está correto. O resultado deve ser semelhante ao abaixo:

cobbler profile getks --name=Fedora17-xfce

# System bootloader configuration
bootloader --location=mbr
# Partition clearing information
clearpart --all --initlabel
# Run the Setup Agent on first boot
firstboot --disable
# Activate X
xconfig --startxonboot
# Use network installation
url --url=http://192.168.122.1/cblr/links/Fedora17-x86_64
# additional repostories get added here
repo --name=Flash-plugin --baseurl=http://192.168.122.1/cobbler/repo_mirror/Flash-plugin
repo --name=source-1 --baseurl=http://192.168.122.1/cobbler/ks_mirror/Fedora17-x86_64

# Reboot after installation
reboot
# System keyboard
keyboard us
# System language
lang en_US
# System timezone
timezone  America/New_York
# Root password
rootpw --iscrypted $1$mF86/UHC$WvcIcX2t6crBz2onWxyac.
# Install OS instead of upgrade
install
# Clear the Master Boot Record
zerombr
# Allow anaconda to partition the system as needed
autopart

%packages
@base
@base-x
firefox
flash-plugin
@xfce-desktop
%end

%post
# create a user we can use to log on X
useradd desktop-user
passwd -d desktop-user

# adds the yum repositories to the installed system
wget "http://192.168.122.1/cblr/svc/op/yum/profile/Fedora17-xfce" \
--output-document=/etc/yum.repos.d/cobbler-config.repo

# cobbler final steps






wget "http://192.168.122.1/cblr/svc/op/ks/profile/Fedora17-xfce" -O /root/cobbler.ks
wget "http://192.168.122.1/cblr/svc/op/trig/mode/post/profile/Fedora17-xfce" -O /dev/null
%end

____________________________
4 Cheetah é um processador de template baseado em python. Você pode encontrar mais informações sobre seu funcionamento em http://www.cheetahtemplate.org/

Repare que a variável $desktop_pkg_group foi corretamente substituída por @xfce-desktop, o que instrui o Anaconda a instalar o grupo de pacotes do desktop xfce.

Estamos quase prontos para iniciar uma instalação. O último passo é associar as máquinas (uma para cada desktop) com os perfis que queremos instalá-las. Os comandos são:

cobbler system add --name=desktop-xfce-1 \
--profile=Fedora17-xfce \
--mac=52:54:00:b8:5e:8f \
--ip-address=192.168.122.10
cobbler system add --name=desktop-gnome-1 \
--profile=Fedora17-gnome \
--mac=52:54:00:88:f3:44 \
--ip-address=192.168.122.11
cobbler system report

Você pode fazer uso da funcionalidade de gerenciamento de energia e deixar o Cobbler ligar/desligar/reiniciar as máquinas para você. Essa funcionalidade também é útil quando você tem muitas máquinas e precisa organizar informações de gerenciamento de energia tais como usuário e senhas para cada, pois o Cobbler terá essas informações registradas em sua base. Suponha que a máquina desktop-xfce-1 esteja localizada em um IBM Bladecenter na baia 2, e que desktop-gnome-1 é uma máquina gerenciada por uma placa rsa. Você pode fazer:

cobbler system edit --name=desktop-xfce-1 \
--power-type=bladecenter \
--power-id=2 \
--power-user=admin_user \
--power-pass=admin_password \
--power-address=192.168.122.2
cobbler system edit --name=desktop-gnome-1 \
--power-type=rsa \
--power-user=rsa_user \
--power-pass=rsa_password \
--power-address=192.168.122.3

Não se esqueça de aplicar todas as mudanças no sistema de arquivos:

cobbler sync

Você está pronto para realizar o boot das máquinas e instalá-las. Lembre-se de que elas precisam estar configuradas para boot via rede, caso contrário elas podem realizar o boot a partir do disco rígido e nunca iniciar a instalação. Se você ativou o gerenciamento de energia, o Cobbler pode realizar o reboot da máquina para você de maneira que a instalação pode ser iniciada com um simples comando:

cobbler system reboot --name=desktop-xfce-1

Isso fará com que o Cobbler conecte-se ao Bladecenter com as credenciais que você especificou e execute um comando de reboot para a blade 2. A blade vai realizar o boot pela rede, receber os arquivos de boot do Cobbler e a instalação vai ocorrer automaticamente. O processo termina quando a tela de login do Fedora é exibida.


Cobbler ainda mais fácil: a interface web

Você pode querer visualizar os objetos Cobbler e reusar valores de objetos para tarefas repetitivas de frequência diária. Cobbler oferece uma interface web bastante útil que permite a você fazer isso. Para usá-la, comece instalando seu pacote:

yum -y install cobbler-web

Uma vez instalado, é necessário configurar o sistema de autenticação e autorização do Cobbler para que você seja capaz de realizar login. A configuração do sistema está disponível no arquivo /etc/cobbler/modules.conf, e se parece com o abaixo:

# authentication:
# what users can log into the WebUI and Read-Write XMLRPC?
# choices:
#    authn_denyall    -- no one (default)
#    authn_configfile -- use /etc/cobbler/users.digest (for basic setups)
#    authn_passthru   -- ask Apache to handle it (used for kerberos)
#    authn_ldap       -- authenticate against LDAP
#    authn_spacewalk  -- ask Spacewalk/Satellite (experimental)
#    authn_pam        -- use PAM facilities
#    authn_testing    -- username/password is always testing/testing (debug)
#    (user supplied)  -- you may write your own module
# WARNING: this is a security setting, do not choose an option blindly.
# for more information:
# https://github.com/cobbler/cobbler/wiki/Cobbler-web-interface
# https://github.com/cobbler/cobbler/wiki/Security-overview
# https://github.com/cobbler/cobbler/wiki/Kerberos
# https://github.com/cobbler/cobbler/wiki/Ldap

[authentication]

module = authn_denyall

# authorization:
# once a user has been cleared by the WebUI/XMLRPC, what can they do?
# choices:
#    authz_allowall   -- full access for all authneticated users (default)
#    authz_ownership  -- use users.conf, but add object ownership semantics
#    (user supplied)  -- you may write your own module
# WARNING: this is a security setting, do not choose an option blindly.
# If you want to further restrict cobbler with ACLs for various groups,
# pick authz_ownership.  authz_allowall does not support ACLs.  configfile
# does but does not support object ownership which is useful as an additional
# layer of control.

# for more information:
# https://github.com/cobbler/cobbler/wiki/Cobbler-web-interface
# https://github.com/cobbler/cobbler/wiki/Security-overview
# https://github.com/cobbler/cobbler/wiki/Web-authorization

[authorization]

module = authz_allowall

Como podemos observar nos comentários de ajuda acima, existem algumas opções de autenticação como LDAP, PAM e arquivo de configuração. Vamos usar PAM para autenticação que é bastante comum. Na seção authorization, precisamos definir quais usuários terão acesso de uso à ferramenta. Configure a opção module para authz_ownership para que possamos especificar no arquivo users.conf quem terá acesso. A configuração deve ficar:

[authentication]

module = authn_pam

[authorization]
module = authz_ownership

Salve o arquivo. Assumindo que você tenha um usuário no sistema chamado myuser (se não tiver, crie um com useradd myuser && passwd myuser), abra o arquivo /etc/cobbler/users.conf e adicione myuser ao grupo admins (esse grupo tem acesso completo aos objetos), como abaixo:

# Cobbler WebUI / Web Services authorization config file
#
# NOTICE:
# this file is only used when /etc/cobbler/modules.conf
# specifies an authorization mode of either:
#
#   (A) authz_configfile
#   (B) authz_ownership
#
# For (A), any user in this file, in any group, are allowed
# full access to any object in cobbler configuration.
#
# For (B), users in the "admins" group are allowed full access
# to any object, otherwise users can only edit an object if
# their username/group is listed as an owner of that object. If a
# user is not listed in this file they will have no access.
#
#     cobbler command line example:
#
#     cobbler system edit --name=server1 --owner=dbas,mac,pete,jack
#
# NOTE:  yes, you do need the equal sign after the names.
# don't remove that part.  It's reserved for future use.

[admins]

myuser = ""

A configuração está pronta. Agora reinicie os serviços do Cobbler e Apache para aplicar as mudanças:

service cobblerd restart

service httpd restart

A interface web é bastante direta: existe um menu do lado esquerdo onde você tem as classes de configuração (repositórios, sistemas, distribuições, perfis, etc.), resources (para gerenciamento de configuração), e ações (import, sync). Ao clicar em uma classe de configuração a interface lista todos os objetos correspondentes no lado direito da tela. É possível aplicar filtros para listagem e realizar diferentes ações através de botões ao lado de cada item.

Figura 2. Interface web do Cobbler
Interface web do Cobbler

Conclusão

Este artigo apresentou o Cobbler, uma ferramenta para automatizar e facilitar a instalação de sistemas. Foi explicado como ele usa o boot via rede para controlar e iniciar as instalações e descritas as funcionalidades disponíveis como espelhamento de repositório, criação de templates kickstart e conectividade com sistemas de gerenciamento de energia.

Uma descrição dos objetos de configuração da ferramenta e como eles se relacionam entre si permitiu ao leitor entender a estrutura interna do Cobbler. A estrutura baseada em objetos associados e herança entre eles provê boa abstração e reuso, o que facilita o trabalho do usuário de configurar um ambiente de instalação de sistemas.

O leitor aprendeu também como instalar e configurar o Cobbler, além de como usar seus comandos para criar uma configuração adequada para automaticamente instalar máquinas. Finalmente, foi explicado como instalar e configurar a interface web para aqueles que necessitam de uma alternativa prática para realizar atividades diárias.

Cobbler é uma ferramenta útil que pode tornar a vida de administradores de sistemas mais fácil. Existem outras funcionalidades não exploradas nesse artigo como a API XML-RPC, a funcionalidade de gerenciamento de configuração, e o cliente koan que tornam o Cobbler ainda mais poderoso. Para aqueles procurando automatizar seus ambientes de instalação, Cobbler é definitivamente uma excelente opção.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux
ArticleID=934697
ArticleTitle=Usando Cobbler para gerenciar e automatizar a instalação de sistemas
publish-date=06252013