[[!toc levels=4]] Bootstrap da configuração do puppet =================================== Pré-requisitos -------------- ### DNS Certifique-se de que existe uma entrada do tipo `puppet.projeto.org` apontando para o host que hospeda (ou hospedará) o puppetmaster. Caso contrário, será preciso adicionar o nome do host no `/etc/puppet/puppet.conf` de cada cliente logo após sua instalação: [puppetd] server = puppet.projeto.org E então reiniciar o serviço: /etc/init.d/puppet restart ### Firewall É importante que o vserver hospedeiro do puppet tenha acesso SSH externo. Assim, certifique-se que seu Debian/Firewall possua uma linha do seguinte tipo no arquivo `/etc/shorewall/rules`: DNAT net vm:192.168.0.2:22 tcp 2202 No caso, `192.168.0.2` é o IP do vserver, `22` a porta de destino nesse IP e `2202` a porta aberta para a conexão externa. Para tal configuração ser efetiva, o `ListenAddress` do `/etc/ssh/sshd_config` do servidor SSH da **máquina hospedeira** deve estar restrito ao IP real da máquina. Gitosis ------- O gitosis é um gerenciador de repositórios git que utiliza chaves públicas ssh para controle de acesso. A ferramenta é simples, poderosa, está nos repositórios do debian estável, e sua configuração é feita através de um repositório git, o que sugere um bom ponto de partida para o bootstrap. gitosis via puppetmasterd ------------------------- O primeiro passo é criar o arquivo de manifesto `/etc/puppet/manifests/classes/gitosis.pp` com o seguinte conteúdo: class gitosis { # directory for gitosis user and repositories file { "/var/git": ensure => directory, mode => 0755, owner => gitosis, group => gitosis; } # the needed packages package { gitosis: ensure => installed; } package { sudo: ensure => installed; } package { git: ensure => installed; } # alters the user's home dir user { gitosis: allowdupe => false, comment => "git repository hosting,,,", ensure => present, home => "/var/git", shell => "/bin/sh"; } # tries to get rid of ugly directory structure file { "/srv/gitosis": ensure => absent, force => true; } file { "/srv": ensure => absent; } } O arquivo acima, além de garantir que o git, sudo e gitosis estejam instalados, altera o home do usuário gitosis para `/var/git`, dentro do qual será criado um diretório chamado `repositories` onde serão armazendos nossos repositórios git. Para aplicar as configurações ao nó, adicionanos o seguinte conteúdo ao arquivo de manifesto `/etc/puppet/manifests/site.pp`: import "classes/gitosis.pp" node 'admin.projeto.org' { include gitosis } Para dar acesso ao primeiro usuário do gitosis, basta executar o seguinte comando: sudo -H -u gitosis gitosis-init < FILENAME.pub # (ou simplesmente copie e cole a chave pública aqui) Um comentário importante sobre a opção `-H`: .. warning:: For now, ``gitosis`` uses the ``HOME`` environment variable to locate where to write its files. If you use ``sudo -u`` without ``-H``, ``sudo`` will leave the old value of ``HOME`` in place, and this will cause trouble. There will be a workaround for that later on, but for now, always remember to use ``-H`` if you're sudoing to the account. Agora podemos clonar o repositório administrativo do gitosis remotamente: git clone ssh://gitosis@servidor.projeto.org:porta/gitosis-admin A configuração não deve ser feita diretamente no repositório do gitosis no servidor, como indicam os autores: You should always edit the configuration file via ``git``. The file symlinked to ``~/.gitosis.conf`` on the server will be overwritten when pushing changes to the ``gitosis-admin.git`` repository. puppetmasterd via gitosis ------------------------- Agora que podemos alterar a configuração do gitosis remotamente, vamos criar a permissão de acesso ao novo repositório de configurações do puppet, alterando `gitosis-admin/gitosis.conf`: [gitosis] [group gitosis-admin] writable = gitosis-admin members = usuario@maquina [group puppet] writable = puppet members = usuario@maquina E atualizamos as configurações no servidor através do git local: git commit -a git push origin master Agora, de volta ao servidor, inicializamos um repositório git em `/etc/puppet` e clonamos para o diretório do gitosis: cd /etc/puppet git init git add * git commit git clone --bare /etc/puppet/ /var/git/repositories/puppet.git chown -R gitosis:gitosis /var/git/repositories/puppet.git Agora já podemos clonar o repositório puppet remotamente: git clone ssh://gitosis@servidor.projeto.org:porta/puppet.git Agora adicionamos um manifesto para o puppetmasterd em `puppet/manifests/classes/puppetmasterd.pp`: class puppetmasterd { package { puppetmaster: ensure => installed } # updates the puppet configuration dir with git repositories # every 5 minutes. cron { puppet-conf: command => "git --git-dir=/etc/puppet/.git/ pull /var/git/repositories/puppet.git master && \ git --git-dir=/etc/puppet/.git/ --work-tree=/etc/puppet/ checkout -f", user => root, hour => '*', minute => '*/5', ensure => present; } # runs the service service { puppetmasterd: ensure => running; } } E atualizamos `puppet-conf/manifests/site.pp`: import "classes/gitosis.pp" import "classes/puppetmasterd.pp" node 'admin.projeto.org' { include gitosis include puppetmasterd } Enviamos as novas configurações para o servidor: git add classes/puppetmasterd.pp git add site.pp git commit git push origin master Finalmente, no servidor, fazemos a última atualização do repositório de configurações do puppet na mão: git --git-dir=/etc/puppet/.git/ pull /var/git/repositories/puppet.git && \ git --git-dir=/etc/puppet/.git/ --work-tree=/etc/puppet/ checkout -f Agora a nova regra do cron garantirá que o repositório em `/etc/puppet` estará sempre atualizado com o repositório em `/var/git/puppet-conf`. Para adicionar um novo usuário ao gitosis, basta adicionar as chaves públicas ssh ao diretório `gitosis-admin/keydir/` com um nome de arquivo do tipo `usuario@maquina.pub`. Adicionando um nodo ------------------- Instale os pacotes necessários: apt-get install puppet openssh-server lsb-release Habilite o `puppetd` editando o arquivo `/etc/default/puppet`, inicie o puppet. No caso de utilização do [mongrel e nginx](http://projects.reductivelabs.com/projects/puppet/wiki/Using_Mongrel_Nginx) para o `puppetmaster`, lembre-se de iniciar o `puppetd` pela primeira vez através de um comando do tipo puppet agent --server puppet.projeto.org --waitforcert 60 --test --ca_port 8141 Caso contrário, simplesmente inicie-o com /etc/init.d/puppet start Em seguida, verifique se os fingerprints dos certificados (master e nodo) coincidem. No master (use `/var/lib/puppet` caso esta seja a pasta utilizada pelo master): puppet cert --fingerprint camada.projeto.org puppet cert --fingerprint ca openssl x509 -text -noout -fingerprint -in /var/lib/puppetmaster/ssl/certs/ca.pem No nodo: openssl x509 -text -noout -fingerprint -in /var/lib/puppet/ssl/certs/camada.projeto.org.pem openssl x509 -text -noout -fingerprint -in /var/lib/puppet/ssl/certs/ca.pem Caso os fingerprints batam, basta liberar o novo nodo a partir do host em que roda o master como o comando puppet cert -s nome-do-nodo.projeto.org Mais detalhes [aqui](http://reductivelabs.com/trac/puppet/wiki/CertificatesAndSecurity) sobre certificados e segurança. Stored Configs -------------- Para utilizar [storeconfigs](http://reductivelabs.com/trac/puppet/wiki/UsingStoredConfiguration) via mysql, proceda com os seguintes comandos: apt-get install mysql-server mysqladmin -u root -p create puppet mysql -u root -p Comandos para o mysql: GRANT ALL PRIVILEGES ON puppet.* TO puppet@"%" IDENTIFIED BY 'senha'; flush privileges; Linhas adicionadas no puppet.conf do nodo master, na seção `[puppetmasterd]`: storeconfigs = true dbadapter = mysql dbserver = localhost dbuser = puppet dbpassword = senha Referências ----------- * [Puppet no Riseup](https://we.riseup.net/riseup+tech/puppet).