Automatizando o gerenciamento de infraestrutura com Cfengine, Parte 1: Instalando servidores e clientes

Cfengine é uma solução popular para automação de datacenter usada por organizações em todo o mundo. Ele é escalável para dezenas de milhares de máquinas, de laptops, desktops e dispositivos integrados a mainframes. Aprenda como usar essa tecnologia versátil e flexível para resolver problemas de datacenter.

Joanne Icken, Advisory Software Engineer, IBM

Joanne Icken é engenheira de software da IBM, com experiência em gerenciamento de sistemas, ambientes distribuídos e exploração de tecnologias da nuvem em apoio a aplicativos corporativos.



Todd Palmer, Advisory Software Engineer, IBM

Todd Palmer é engenheiro de software da equipe IBM Innovation System onde ele implementa software de gerenciamento de configuração e automação. Anteriormente, ele trabalhou na equipe de Engenharia de Cliente de Sistemas de Informação da IBM Watson Research.



26/Mai/2011

Introdução

Hoje, os datacenters de TI devem fornecer e manter serviços estáveis, seguros e escaláveis executados em vários tipos de hardware de servidor e sistemas operacionais, entre várias versões de sistema operacional. A eficiência é importante, e os administradores querem minimizar o suporte a esses serviços e torná-los uma operação totalmente automatizada. Nesta série de duas partes Automatizando o gerenciamento de infraestrutura com Cfengine ", examinaremos o Cfengine, uma estrutura de automação para administração de sistema e gerenciamento de TI.

A parte 1 desta série fornecerá uma visão geral do Cfengine V3 Community Edition e informações sobre como desenvolver e configurar um servidor e cliente de política/distribuição no Cfengine. A Parte 2 continuará com exemplos de uso do Cfengine para executar muitas das tarefas diárias envolvidas em serviços de apoio.

Este artigo supõe que já foi instalado o sistema operacional UNIX® ou Linux® base e que você está familiarizado com os comandos de pacote Cygwin e Linux.


Gerenciamento de configuração e o Cfengine

O bom gerenciamento de configuração estabelece e mantém a consistência com base nos atributos de desempenho, funcionais e físicos de plataformas e produtos de TI, e seus ambientes. Também é usado para determinar recursos de segurança adequados e garantir que sejam devidamente aplicados. Trata-se de um trabalho complexo, e existem muitas ferramentas de gerenciamento de configuração disponíveis.

Algumas ferramentas, como Arusha Project (ARK), podem ser usadas com o Cfengine. Outras usam conceitos semelhantes de gerenciamento de sistema, mas são escritas em linguagens de programação diferentes, como Puppet, escrita em Ruby e que usa chamadas REST, SyncTool, escrita em Python, e SmartFrog, baseada em tecnologia Java™ . Outras, como opsi (Open PC Server Integration), são escritas apenas para Windows®. O IBM® Systems Director e o IBM BigFix, adquirido recentemente, também fornecem gerenciamento de configuração.

O Cfengine é uma estrutura de gerenciamento de configuração de software livre GNU para automação de sistemas de computadores. A estrutura é leve e pode ser desenvolvida em quase qualquer plataforma. Ela é executada de forma nativa em todas as plataformas comuns, incluindo AIX, Linux, UNIX, Apple e Windows.

A IT Infrastructure Library, a abordagem mais adotada para gerenciamento de serviços de TI no mundo todo, define gerenciamento de conhecimento como um processo-chave para fornecer serviços. O gerenciamento de conhecimento garante que uma pessoa, com o conhecimento correto, entregue e ofereça suporte aos serviços exigidos pela empresa. A premissa é que os serviços sejam oferecidos de forma eficiente com um claro entendimento do valor fornecido pelos serviços com as informações relevantes disponíveis conforme necessário O Cfengine V3 se concentra no gerenciamento de conhecimento em cada fase do ciclo de vida do gerenciamento. Usando uma configuração definida, o Cfengine pode garantir que os pacotes, arquivos de configuração, permissões de arquivos e processos corretos estejam sendo executados em seu ambiente.

O Cfengine tem duas edições: uma edição da comunidade de longa data e uma edição corporativa comercial. No caso da edição comercial, há várias ofertas: Nova, Constellation e Galaxy (consulte Recursos).


Gerenciamento do ciclo de vida

O Cfengine segue o modelo Build-Deploy-Manage-Audit (BDMA) de gerenciamento de ciclo de vida do sistema. O BDMA compreende quatro fases do ciclo de vida do sistema: desenvolver, implementar, gerenciar e auditar. Na fase de desenvolvimento, são planejadas mudanças de políticas, formuladas promessas do estado desejado e é desenvolvido um modelo de proposta de promessas, de modo que, se todas as máquinas fizerem e mantiverem essas promessas, o sistema funcionará perfeitamente.

Na fase de implementação, sua política é publicada para todos os clientes autônomos, e cada cliente executa um agente capaz de implementar as políticas e mantê-las ao longo do tempo, sem assistência.

Na fase de gerenciamento, o agente autônomo gerencia o sistema, de modo que é preciso lidar apenas com eventos raros que não possam ser tratados automaticamente.

Finalmente, na fase de auditoria, as alterações são auditadas e mantidas localmente. Os resultados de decisões são assegurados pelo design no Cfengine e mantidos automaticamente.

O Cfengine não deve ser encarado como um sistema de lançamento, onde se tenta forçar a saída de alterações absolutas e revertê-las em caso de erro. Com o Cfengine, é possível publicar sequências de revisões de políticas, sempre seguindo em frente. As mudanças de estado são administradas localmente por cada cliente e continuamente reparadas para o cumprimento da política.

Dependências

O Cfengine exige OpenSSL e BerkeleyDB V3.2 ou posterior. Opcionalmente, é possível desenvolver suporte para a biblioteca PCRE (Perl Compatible Regular Expression), OpenLDAP e PostgreSQL ou MySQL. Alguns recursos de banco de dados estão disponíveis apenas nas edições comerciais. No Windows, o Cfengine exige um ambiente Cygwin. Além disso, um software de controle de versão, como o Subversion (SVN), pode ser usado para controlar mudanças nos arquivos de configuração.

Termos

  • Promessas — Ações ou regras definidas para serem seguidas por um sistema.
  • Pacotes configuráveis— Grupos de promessas.
  • Políticas — Pacotes configuráveis que definem o conhecimento tangível que podemos gerenciar.
  • Classes— Atributos/variáveis definidos como "on" ou não definidos como "off".
  • As políticas consistem em pacotes configuráveis de promessas.
  • Chaves— Podem ser públicas ou privadas, utilizadas como autenticação para acesso do cliente ao servidor, geradas em cada cliente usando o a chave cf e, em seguida, copiadas para o keystore do servidor. Na IBM apenas o uso de chaves de servidor já forneceu segurança suficiente.

Introdução

O Cfengine pode ser executado em qualquer servidor UNIX, bem como, em Windows com a ajuda do ambiente Cygwin. Em um servidor UNIX, comece instalando o OpenSSL, BerkeleyDB e qualquer pacote adicional mencionado acima. O Cfengine geralmente é instalado a partir de um pacote de distribuição (como rpm ou deb), ou a fonte pode ser baixada e compilada (consulte Recursos).

Se planeja desenvolver o Cfengine a partir do código de origem, também será preciso instalar ferramentas adicionais, como gcc, flex e bison, em seu servidor UNIX/Linux. Em servidor Windows, comece instalando o Cygwin, depois instale as ferramentas gcc, flex e bison para compilar e instalar o código.

Os arquivos base do Cfengine são instalados em subdiretórios do diretório de trabalho dele, /var/cfengine. Esse diretório de trabalho é utilizado pelo Cfengine para seus próprios fins e é definido no momento da compilação. Esse caminho também é considerado um sistema de arquivos local seguro. À medida que os arquivos de configuração são codificados, são colocados em um ponto de distribuição de configuração (/var/cfmasterfiles, por exemplo) em todos os servidores Cfengine. Em geral é esse caminho que é colocado sob o controle de versão.

Desenvolvendo o Cfengine a partir do código de origem

Faça o download do código de origem a partir do repositório do Cfengine. Efetue login no sistema como usuário não raiz e execute os seguintes comandos.

tar –zxf cfengine-x.x.x.tar.gz
cd cfengine-x.x.x
./configure --prefix=/var/cfengine 
   --sbindir=/var/cfengine/bin --localstatedir=/var/cfengine
   --with-workdir=/var/cfengine --with-openssl=/usr make

Agora, mude para o usuário raiz e execute os seguintes comandos (os arquivos binários são colocados em /var/cfengine/bin).

make install 
make installcheck

Instalando o Cfengine no servidor de política/distribuição

Efetue login no sistema como usuário raiz e execute os seguintes comandos:

mkdir –p /var/cfengine/masterfiles
cp cfengine-x.x.x/inputs/update.cf to /var/cfengine/masterfiles
cp cfengine-x.x.x/inputs/promises.cf to /var/cfengine/masterfiles

Atualize a opção "mailto" no arquivo promises.cf usando o e-mail adequado. Acrescente as redes das quais seu servidor deve aceitar conexões na seção "body server control" de promise.cf:

allowconnects => { "192.", "10.", "127.0.0.1" , "::1" };
allowallconnects => { "192.", "10.", "127.0.0.1" , "::1" };
trustkeysfrom => { "192.", "10.", "127.0.0.1" , "::1" };

Atualize o servidor de política em todos os arquivos de configuração para o novo ambiente de servidor:

cp cfengine-x.x.x/inputs/failsafe.cf to /var/cfengine/masterfiles
cp cfengine-x.x.x/inputs/cfengine_stdlib.cf to /var/cfengine/masterfiles

Componentes do Cfengine

Esta é uma lista de componentes importantes da instalação Cfengine. (Observação: Se o Cfengine foi instalado a partir de um pacote binário ou foi feita customização durante uma instalação compilada, esses diretórios base podem ser diferentes.)

Diretórios

  • /var/cfengine/bin — Diretório com binários do Cfengine
  • /var/cfengine/inputs — Diretório com arquivos de configuração do Cfengine
  • /var/cfengine/outputs — Diretório com relatórios de execução do Cfengine
  • /var/cfengine/ppkeys — Diretório com chaves de autenticação
  • /var/cfmasterfiles — Diretório com arquivos principais no servidor de política
  • /var/cfengine/repository — Diretório que contém backup de arquivos Cfengine importantes para a recuperação (nome/local configuráveis)

Arquivos binários

  • /var/cfengine/bin/cf-promises — Comando que verifica a sintaxe de promessa
  • /var/cfengine/bin/cf-agent — Comando que mantém as promessas feitas em comum e os pacotes configuráveis de agentes sobre o estado do sistema
  • /var/cfengine/bin/cf-serverd — O servidor (daemon) usado para distribuir arquivos de política ou de dados para clientes e responder as solicitações de cf-runagent
  • /var/cfengine/bin/cf-execd — Programação do daemon responsável para execução de cf-agent
  • /var/cfengine/bin/cf-runagent — Comando que executa o cf-agent em uma máquina remota
  • /var/cfengine/bin/cf-monitord — Daemon responsável para coletar informações sobre o status do seu sistema
  • /var/cfengine/bin/cf-report — Comando que gera resumos e outros relatórios a partir de bancos de dados integrados do Cfengine
  • /var/cfengine/bin/cf-know — Comando que gera um mapa de tópico padrão ISO a partir de várias promessas (o agente de modelagem de conhecimento)
  • /var/cfengine/bin/cf-key — Ferramenta de geração de chave executada uma vez em cada host para criar pares de chaves públicas/privadas para comunicação segura

Arquivos de configuração

  • /var/cfengine/inputs/promises.cf — Arquivo de configuração principal usado pelo cf-agent
  • /var/cfengine/inputs/library.cf — Biblioteca da comunidade que contém uma coleção de código reutilizável, para os releases V3.1.x, é melhor usar a biblioteca da comunidade

Inicie o servidor de política do Cfengine pela primeira vez

Execute os seguintes comandos no servidor:

/var/cfengine/bin/cf-key
mkdir /var/cfmasterfiles/ppkeys
cp /var/cfengine/ppkey/localhost.pub /var/cfmasterfiles/ppkeys/root-<servername or ip>.pub
cp /var/cfengine/ppkey/localhost.priv \
/var/cfmasterfiles/ppkeys/root-<servername or ip>.priv
cp /var/cfmasterfiles/inputs/update.cf /var/cfengine/inputs/
cp /var/cfmasterfiles/inputs/failsafe.cf /var/cfengine/inputs/
/var/cfengine/bin/cf-agent –bootstrap

Agora o servidor de política do Cfengine está configurado. Para preparar o Cfengine para servir a clientes remotos, execute o seguinte comando: start cf-server.

Na maioria dos ambientes, é possível executar o cf-serverd por meio das configurações. Outras vezes, é bom ter um arquivo de configuração independente para suas configurações de servidor. Isso fornece um local para que processos externos abram novamente o cf-serverd se o processo for interrompido inesperadamente. Também é possível ter um script de segurança para abrir novamente o cf-serverd. Para executá-lo a partir da linha de comando, execute:

/var/cfengine/bin/cf-serverd
/var/Cfengine/bin/cf-serverd –f
/var/cfmasterfiles/prod/server/server.cf

Configuração inicial de um cliente

  1. /var/cfengine/inputs/failsafe.cf
  2. /var/cfengine/inputs/update.cf
  3. /var/cfengine/ppkeys/root-<server>.pub

Inicie o cliente Cfengine pela primeira vez executando os seguintes comandos:

/var/cfengine/bin/cf-key
/var/cfengine/bin/cf-agent –K –bootstrap

Criar um pacote binário para o seu ambiente

Nesse ponto, talvez seja interessante criar pacotes APT ou RPM para serem usados na configuração dos seus clientes. Um pacote contém os binários do Cfengine e outro, os arquivos de configuração mínimos do Cfengine e as chaves públicas do servidor para a autoinicialização do Cfengine, juntamente com os comandos cf-key e cf-agent listados acima. Com os dois pacotes desenvolvidos, é simples configurar um cliente com o Cfengine instalando os pacotes.

Demonstraremos a criação de pacotes binários para o ambiente Red Hat. (Para criar um pacote Debian, consulte UbuntuForums.org). Diferentes distribuições talvez tenham requisitos diferentes para a criação de um pacote binário. Consulte a documentação do seu ambiente para ver como preparar adequadamente essas informações.

Preparando um RPM

RPMs começam com um arquivo de especificações que contém as informações sobre o pacote. A Listagem 1 mostra um exemplo de arquivo de especificações de RPM no Red Hat.

Lista 1. Arquivo de especificações de RPM no Cfengine V3 Red Hat
%define debug_package %{nil}
%define bin_path \
"/bin:/usr/bin:/usr/sbin:/usr/bin/X11:/sbin:\
/opt/cfengine/bin:/
opt/cfengine/bin:/opt/freeware/bin/:/usr/gnu/bin"
Name : cfengine
Summary : A tool to maintain complicated networks
Version : 3.1.4
Release : 1
URL : http://www.cfengine.org
Vendor : %{__spec_vendor}
License : GPL
Group : System Environment/Client Management
Packager : <your name> <your email address >
Distribution : %{__spec_distribution}
Source : %{name}-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
%ifos linux
Requires : db4 openssl coreutils pcre
#libacl zlib libattr e2fsprogs-libs keyutils-libs
BuildRequires : db4 db4-devel openssl openssl-devel pcre-devel
#libacl libacl-devel openssl openssl-devel pcre-devel zlib zlib-devel
                libattr libattr-devel e2fsprogs-libs keyutils-libs libselinux libsepol
ExclusiveArch : i386 x86_64 ppc ppc64
%endif
%descriptionCfengine is the standalone, open-source datacenter 
management platform run by leading enterprises since 1993. 
Customize your IT systems, align to network, business and 
regulatory needs, monitor problems, automatically repair 
and maintain systems more effectively than with proprietary 
software. Cope with new and legacy systems and adopt on a 
phased basis. Cfengine yields reduced costs, improved 
efficiency and higher return on investment for the lowest 
cost of adoption in the industry!
Authors:
--------
Mark Burgess
%prep
[ -d %{buildroot} -a "%{buildroot}" != "" ] && rm -rf %{buildroot}
mkdir -p %{buildroot}
%setup -q
%build
export CFLAGS="-g -O2 -D_FORTIFY_SOURCE=0"
%configure \
--prefix=/var/cfengine \
--sbindir=/var/cfengine/bin \
--localstatedir=/var/cfengine \
--with-workdir=/var/cfengine \
--libdir=%{_libdir} \
--with-berkeleydb=%{_libdir} \
--with-openssl=/usr \
--with-pcre
make
make DESTDIR=${RPM_BUILD_ROOT} install
%files
%defattr(-,root,root)
%{_mandir}/man?/*
/var/cfengine/*
%{_libdir}/libpromises.la
%{_libdir}/libpromises.so*
%pre
export PATH=$PATH:%bin_path
%post
export PATH=$PATH:%bin_path

Processo de desenvolvimento de RPM

  1. Faça o download do código de origem para a pasta /usr/src/redhat/SOURCES/.
  2. Coloque o arquivo de especificações na pasta /usr/src/redhat/SPECS/.
  3. Execute o comando rpmbuild –ba /usr/src/redhat/SPECS/cfengine.spec para criar o binário e os RPMs de origem.
  4. Instale e teste seu novo RPM executando rpm –ivh <RPM name>. Teste a remoção do RPM executando rpm –e <RPM name>.

Primeiros passos com o Cfengine

Na inicialização, o cf-agent faz a identificação automática de muitos atributos do host. A partir desses atributos, são definidas "classes rígidas". À medida que o processo é executado, outras classes a serem definidas são conhecidas como "classes flexíveis". A execução inicial começa com uma chamada de cf-execd –F a partir de cron ou da linha de comando. cf-execd lê o arquivo cf-promise, que faz a verificação da sintaxe. Se forem encontrados erros, o cf-agent aborta a configuração atual e procura executar a configuração /var/cfengine/inputs/failsafe.cf.

A Figura 1 explica em um diagrama o processo do Cfengine.

Figura 1. Processo do Cfengine
Diagram shows the flow from promise.cf with no issues and the fallback to failsafe.cf if errors are detected

Configuração de amostra

Para se familiarizar com o Cfengine, as listagens 2-6 mostram arquivos de configuração de amostra a serem colocados em /var/cfengine/inputs. Para verificar se a sintaxe está correta, execute cf-promises –f ./test.cf. Para executar com essa configuração, execute cf-agent –Kiv -f ./test .cf.

Lista 2. failsafe.cf de amostra
########################################################
# failsafe.cf
########################################################
body common control
{
 bundlesequence => { "update" };
 inputs => { "update.cf" };
 version => "1.2.3";
}
bundle agent failsafe
{
 classes:
  "failsafe" not => "bootstrap_mode";
}
Lista 3. promises.cf de amostra
#######################################################
# Copyright (C) Cfengine AS
# This file is part of Cfengine 3 - written and maintained by Cfengine AS.
#######################################################
# promises.cf
#######################################################
body common control
{
 bundlesequence => { 
   "update",
   "garbage_collection",
   "main"
};
inputs => {
 "update.cf",
 "site.cf"
};
}
#######################################################
body agent control
{
 ifelapsed => "15";
}
#######################################################
body executor control
{
 splaytime => "1";
 mailto => "username@localhost.localdomain";
 smtpserver => "localhost";
 mailmaxlines => "30";
 # Instead of a separate update script, now do this
 exec_command => "$(sys.workdir)/bin/cf-agent -f failsafe.cf && 
         $(sys.workdir)/bin/cf-agent";
}
#######################################################
body reporter control
{
 reports => { "performance", "last_seen", "monitor_history" };
 build_directory => "$(sys.workdir)/reports";
 report_output => "html
}
#######################################################
body server control 
{
 allowconnects => { "192.", "10.", "127.0.0.1" , "::1" };
 allowallconnects => { "192.", "10.", "127.0.0.1" , "::1" };
 trustkeysfrom => { "192.", "10.", "127.0.0.1" , "::1" };
 # Makes updates and runs happen in one
 cfruncommand => "$(sys.workdir)/bin/cf-agent -f failsafe.cf && 
         $(sys.workdir)/bin/cf-agent";
 allowusers => { "root" };
}
#######################################################
# Server configuration
#######################################################
bundle server access_rules()
{
 access:
  "/var/cfmasterfiles"
  admit => { "192.", "10.", "127.0.0.1" , "::1" };
 roles:
  ".*" authorize => { "root" };
}
body action local_immediate
{
 ifelapsed => "0";
 action_policy => "fix";
}
#######################################################
## To avoid namespace conflict and reduce file footprint
#######################################################
body depth_search local_recurse(d)
{
 depth => "$(d)";
 xdev => "true";
}
body delete local_tidy
{
 dirlinks => "delete";
 rmdirs => "true";
}
body file_select local_days_old(days)
{
 mtime => irange(0,ago(0,0,"$(days)",0,0,0));
 file_result => "mtime";
}
body classes local_define(class,alert)
{
 promise_repaired => { "$(class)" };
 repair_failed => { "$(alert)" };
}
Lista 4. update.cf de amostra
#######################################################
### update.cf – config file used by the base delivery system
#######################################################
bundle agent update
{
vars:
 "master_inputs" string => "/var/cfmasterfiles/inputs";
 "master_scripts" string => "/var/cfmasterfiles/scripts";
 "master_ppkeys" string => "/var/cfmasterfiles/ppkeys";
 "master_server" slist => { "localhost" };
 redhat|centos::
 "update_crontab" string => "/var/spool/cron/root";
 SuSE::
 "update_crontab" string => "/var/spool/cron/tabs/root";
 #define others as needed (darwin, macOSX should support below)
 (!SuSE).(!redhat)::
 "update_crontab" string => "/var/spool/cron/crontabs/root";
classes:
 "exec_fix" not => regline(".*cf-execd.*","$(update_crontab)");
files:
 "/var/cfengine/inputs" 
 handle => "update_inputs",
 comment => "Update the base inputs directory for client",
 perms => u_p("600"),
 copy_from => update_scp("$(master_inputs)","$(master_server)"),
 depth_search => recurse_svn("inf"),
 file_select => cf3_config,
 action => update_immediate;
 "/var/cfengine/scripts" 
 handle => "update_scripts",
 comment => "Update the base scripts directory for client",
 perms => u_p("750"),
 copy_from => update_scp("$(master_scripts)","$(master_server)"),
 depth_search => recurse_svn("inf"),
 file_select => cf3_scripts,
 action => update_immediate; "/var/cfengine/ppkeys" 
 handle => "update_ppkeys",
 comment => "Update the base ppkeys directory for client",
 perms => u_p("600"),
copy_from => update_scppubs("$(master_ppkeys)","$(master_server)"),
 depth_search => recurse_svn("inf"),
 file_select => cf3_pub,
action => update_immediate;
 exec_fix::
 "$(update_crontab)"
 handle => "update_cron",
 comment => "Ensure that cron entry exists",
 create => "true",
 action => update_immediate,
 edit_line => update_add2cron,
 classes => update_repaired("updated_cron");
commands:
 bootstrap_mode::
 "/bin/echo"
 args => "Running Bootstrap, version: $(sys.cf_version) Workdir is: $(sys.workdir) ",
 handle => "callback_bootstrap",
 comment => "Callback Bootstrap happened",
 action => update_immediate;
 failsafe::
 "/bin/echo"
 args => "Running Failsafe, version: $(sys.cf_version) Workdir is: $(sys.workdir) ",
 handle => "callback_failsafe",
 comment => "Callback Failsafe happened",
 action => update_immediate;
 !bootstap.!failsafe::
 "/bin/echo"
 args => "Running Normal, version: $(sys.cf_version) Workdir is: $(sys.workdir)",
 handle => "callback_normalrun",
 comment => "Callback Normal Run Happened",
 contain => update_root,
 action => update_immediate;
}
############################################
body perms u_p(p)
{
 mode => "$(p)";
}
body depth_search recurse_svn(d) 
{ 
 depth => "$(d)"; 
 exclude_dirs => { "\.svn" }; 
}
############################################
 add_cron::
 "Added a 15 minute schedule to crontab";
}
body file_select cf3_config
{
 leaf_name => { "^.svn", ".*\.cf" , ".*\.sh" };
 file_result => "leaf_name";
}
body file_select cf3_scripts
{
 leaf_name => { ".*\.sh", ".*.py" };
 file_result => "leaf_name";
}
body file_select cf3_pub
{
 leaf_name => { "^localhost*", ".*\.pub" };
 file_result => "leaf_name";
}
#########################################################
body copy_from update_scp(from,server)
{
 source => "$(from)";
 servers => { "$(server)" };
 compare => "digest";
 verify => "true";
 purge => "true";
 trustkey => "true";
}
body copy_from update_scppubs(from,server)
{
 source => "$(from)";
 servers => { "$(server)" };
 compare => "digest";
 verify => "true";
 purge => "false";
 trustkey => "true";
} body action update_immediate
{
 ifelapsed => "0";
}
body classes update_repaired(class)
{
 promise_repaired => { "$(class)" };
}
body action update_background
{
 ifelapsed => "0";
 action_policy => "fix";
}
body contain update_root
{
 exec_owner => "root";
 useshell => "true";
}
#########################################################
# bundle for bodies
#########################################################
bundle edit_line update_add2cron {
 classes: 
 "add_cron" not => regline("^#*[CF3 normal run]","$(edit.filename)");
 insert_lines:
 add_cron::
 "5,15,30,45 * * * * /var/cfengine/bin/cf-execd -F #CF3 normal run";
 reports:
add_cron::
 "Added a 15 minute schedule to crontab";
}
Lista 5. site.cf de amostra
#######################################################
# Copyright (C) Cfengine AS
# This file is part of Cfengine 3 # site.cf - Site specific promises
#######################################################
bundle common g
{
vars:
 !failsafe||!bootstrap::
 "message" string => "All Looks good";
 bootstrap::
 "message" string => "Running bootstrap";
 failsafe::
 "message" string => "Running Failsafe";
}
#######################################################
# General site issues can be in bundles like this one
#######################################################
bundle agent main
{
### This would be a place to add something new!
commands:
 cfengine_3_1_4::
 "/bin/echo"
 args => "Example Command with message param: '$(g.message)'",
 handle => "echo_command",
 comment => "Example of the echo command",
 action => local_immediate,
 classes => local_define("cmd_1","life");
}
#######################################################
# Garbage collection issues
#######################################################
bundle agent garbage_collection
{
files:
 "$(sys.workdir)/outputs" 
 delete => local_tidy,
 file_select => local_days_old("5"),
 depth_search => local_recurse("inf");
}
Lista 6. Execução de teste de amostra
############################################################
#
# Simple test execution – test.cf
#
###########################################################
body common control 
{ 
bundlesequence => { "testbundle" }; 
} 
###########################################################
bundle agent testbundle 
{ 
vars: 
 "size" int => "46k"; 
 "rand" int => randomint("33","$(size)");
commands: 
 "/bin/echo" 
 args => "Hello world - $(size)/$(rand)", 
 contain => standard, 
 classes => cdefine("followup","alert");
 followup:: 
 "/bin/ls"
 contain => standard;
reports:
 alert::
 "What happened?";
}
###########################################################
body contain standard
{
 exec_owner => "mark";
 useshell => "true";
}
###########################################################
body classes cdefine(class,alert)
{
 promise_repaired => { "$(class)" };
 repair_failed => { "$(alert)" };
}

Resumo

Neste artigo, aprendemos a inicializar um servidor de política/distribuição do Cfengine V3 e um cliente do Cfengine V3. É possível instalar pacotes binários ou compilados a partir do código de origem. Vimos também como desenvolver pacotes binários para seu ambiente a partir do código baixado por download. E vimos arquivos de configuração de amostra para executar o Cfengine, como verificá-los quanto à precisão e como aplicá-los ao seu ambiente de execução.

O exemplo, embora muito simples, permite testar seu ambiente. A parte 2 desta série "Automatizando o gerenciamento de infraestrutura com Cfengine " incluirá mais exemplos de tarefas de administração de sistema.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

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=Software livre, Linux
ArticleID=661047
ArticleTitle=Automatizando o gerenciamento de infraestrutura com Cfengine, Parte 1: Instalando servidores e clientes
publish-date=05262011