aboutsummaryrefslogtreecommitdiff
path: root/puppet.mdwn
blob: 0f3385187ab5f981e6ebed3c66669720c8ac5967 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
[[!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

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

    puppetd --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):

    openssl x509 -text -noout -fingerprint -in /var/lib/puppetmaster/ssl/ca/requests/camada.projeto.org.pem
    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).