]> gitweb.fluxo.info Git - padrao.git/commitdiff
Adicionando procedimento de puppet
authorSilvio Rhatto <rhatto@riseup.net>
Wed, 3 Feb 2010 00:02:14 +0000 (22:02 -0200)
committerSilvio Rhatto <rhatto@riseup.net>
Wed, 3 Feb 2010 00:02:14 +0000 (22:02 -0200)
firewall.mdwn
puppet.mdwn

index bb3687a9a9c8a09f360c6f1003e9cdae109b7efd..52ca30e173e378e92abb11d1e6b88cd61e32ad28 100644 (file)
@@ -73,4 +73,4 @@ Finalmente podemos ligar o shorewall:
 Shorewall e Puppet 
 ==================
 
-Uma vez que um nodo puppetmaster estiver rodando, o módulo [puppet-shorewall](http://git.sarava.org/?p=puppet-shorewall.git;a=summary) poderá ser utilizado para gerenciar o firewall. No entanto, se você for substituir o presente procedimento pela sua versão via puppet, certifique-se de apagar os arquivos `/etc/shorewall/{masq,policy,zones,rules,interfaces}`. 
+Uma vez que um nodo [puppetmaster](../puppet) estiver rodando, o módulo [puppet-shorewall](http://git.sarava.org/?p=puppet-shorewall.git;a=summary) poderá ser utilizado para gerenciar o firewall. No entanto, se você for substituir o presente procedimento pela sua versão via puppet, certifique-se de apagar os arquivos `/etc/shorewall/{masq,policy,zones,rules,interfaces}`. 
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..28e9b8691b01383555203abccda25de713710d33 100644 (file)
@@ -0,0 +1,228 @@
+Bootstrap da configuração do puppet 
+===================================
+
+Pré-requisitos
+--------------
+
+É 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-conf.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-conf.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 
+-------------------
+
+Primeiro, adicione o repositório [backports](http://backports.org):
+
+    echo deb http://www.backports.org/debian lenny-backports main contrib non-free >> /etc/apt/sources.list
+    apt-get update ; apt-get install debian-backports-keyring ; apt-get update
+
+Então instale os pacotes necessários:
+
+    apt-get -t lenny-backports install puppet
+
+Adicione a seguinte seção no `/etc/puppet/puppet.conf`:
+
+    [puppetd]
+    server = puppet.projeto.org
+
+Reinicie o serviço:
+
+    /etc/init.d/puppet restart
+
+Em seguida, verifique se os fingerprints dos certificados (master e nodo) coincidem. No master:
+
+    openssl x509 -text -noout -fingerprint -in /var/lib/puppet/ssl/ca/requests/camada.projeto.org.pem
+
+No nodo:
+
+    openssl x509 -text -noout -fingerprint -in /var/lib/puppet/ssl/certs/camada.projeto.org.pem
+
+Caso os fingerprints batam, basta liberar o novo nodo a partir do host em que roda o master como o comando
+
+    puppetca -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).