diff options
| -rw-r--r-- | index.md | 2 | ||||
| -rw-r--r-- | puppet.md | 216 | ||||
| -rw-r--r-- | puppet/master.md | 74 | ||||
| -rw-r--r-- | rescue.md | 17 | ||||
| -rw-r--r-- | vservers.md | 81 |
5 files changed, 10 insertions, 380 deletions
@@ -24,8 +24,6 @@ A antiga documentação do Padrão Fluxo ainda [está disponível](trac/). * [Swap](swap). * [Firewire](firewire). * [Firewall](firewall). -* [VServers](vservers). -* [Puppet](puppet). * [Backup](backup). * [Chaves](keys). * [Certificados](certs). diff --git a/puppet.md b/puppet.md deleted file mode 100644 index 67a672d..0000000 --- a/puppet.md +++ /dev/null @@ -1,216 +0,0 @@ -[[!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. - -Hoje em dia o Padrão Saravá utiliza o gitolite, porém o bootstrap inicial utilizou o gitosis. Fica aos leitores/as o exercício de utilizar o gitolite. - -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`. - -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). - -Adicionando mais masters -======================== - -[Como adicionar mais puppetmasters](master). diff --git a/puppet/master.md b/puppet/master.md deleted file mode 100644 index 1a44775..0000000 --- a/puppet/master.md +++ /dev/null @@ -1,74 +0,0 @@ -Configurando um master -====================== - -Procedimento para configurar um novo master e eventualmente assumi-lo como o -master principal da rede. - -Deploy do nodo --------------- - -* Assumiremos `$old` como o hostname do master antigo. -* Nós usaremos o master `$old` para configurar o master `$node`. -* Assim, siga as [instruções para adicionar um nodo](/nodo), levando em conta: - * Inicialmente, a configuração do nodo com `nodo::role::master::main: false`. - * Se o nodo for assumir o papel de um master principal, use `nodo::role::master::main: true` - após a aplicação do primeiro catálogo. - -Mudança de porta ----------------- - -Em alguns casos -- dependendo de onde o novo master for hospedado --, pode ser necessário -usar uma porta fora do padrão para o `puppetmaster`. - -No caso de mudança de portas do puppetmaster, comunicar essa mudança aos nodos -via `puppet::daemon::port` e aguardar aplicação de catálogo de todos os nodos. - -Mudança do DNS --------------- - -Esta etapa consiste em fazer a atualização do DNS, para que os nodos acessando `puppet.$domain` -caiam direto no novo master. Use a seguinte configuração na interface de atualização de DNS, -substituindo `$node.$domain` pelo domÃnio do novo master (o ponto final é importante): - - admin 3600 IN CNAME $node.$domain. - munin 3600 IN CNAME $node.$domain. - nagios 3600 IN CNAME $node.$domain. - puppet 3600 IN CNAME $node.$domain. - -As próximas etapas podem ser executadas enquanto o DNS é propagado. - -Importação da chave de backups ------------------------------- - -Para importar a chave privada do nodo `$old` no nodo `$node`, use - - admin@box$ HOST=$old hydra $hydra import-key $node - -Restore dos backups -------------------- - -Assumindo que o backup criptografado já esteja disponÃvel em `$node:/var/backups/remote/$old.$domain`: - - root@master$ hydractl backup-restore-master $old - -Após o restore, o nodo deverá estar pronto para assumir o papel de master. - -Atualize seu ~/.ssh/config --------------------------- - -Exemplo de configuração pessoal, substituindo as variáveis de acordo: - - Host admin.$domain - HostName $node.$domain - Port $porta - -Assim, independentemente qual seja o nodo master atual, ele sempre estará acessÃvel pelo alias `admin.$domain`, -evitando mudanças desnecessárias e tediosas em referências de inúmeros repositórios. - -PossÃveis problemas -------------------- - -As seguintes mensagens de erro podem aparecer no novo master depois de sua ativação: - -* "You cannot collect without storeconfigs being set": o problema tende a desaparecer conforme os exported resources forem sendo definidos. -* [Collected resources with a puppet master fail on Ruby 1.9.x](http://projects.puppetlabs.com/issues/10963): basta aplicar o patch manualmente. @@ -8,7 +8,7 @@ Um sistema de resgate pode ser útil para a [instalação](/install) de um siste Baixando o sistema ------------------ -Utilizamos imagens `iso-hybrid` do [Debian Live](http://live.debian.net) como base para o sistema de resgate. +Utilizamos imagens `iso-hybrid` do [Debian Live](https://www.debian.org/CD/live/) como base para o sistema de resgate. Gravando o sistema ------------------ @@ -20,14 +20,14 @@ Criando uma imagem de resgate Imagens de resgate podem ser criadas usando o [debirf](http://cmrg.fifthhorseman.net/wiki/debirf): - apt-get install debirf + apt install debirf tar xzf /usr/share/doc/debirf/example-profiles/rescue.tgz debirf make rescue debirf makeiso rescue Alternativamente, podemos criá-las usando o [live-build](http://live.debian.net/devel/live-build/): - apt-get install live-build + apt install live-build mkdir live-default && cd live-default lb config sudo lb build @@ -37,7 +37,7 @@ Mais informações [aqui](http://live.debian.net/manual/git/html/live-manual.en. Habilitando acesso remoto ------------------------- - apt-get install openssh-server + apt install openssh-server ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub Configuração mÃnima @@ -49,13 +49,16 @@ Configuração mÃnima Instalando ferramentas básicas ------------------------------ - apt-get update - apt-get install screen pciutils usbutils git locales + apt update + apt install screen pciutils usbutils git locales Usando remotamente ------------------ -A grande vantagem do sistema de resgate é a sua possibilidade de utilização remota. Com o servidor `SSH` instalado, é possÃvel se conectar a ele do conforto do seu desktop ou laptop! Antes de fazer isso, não deixe de verificar a impressão digital do serviço `SSH` do sistema de resgate. +A grande vantagem do sistema de resgate é a sua possibilidade de utilização +remota. Com o servidor `SSH` instalado, é possÃvel se conectar a ele do +conforto do seu desktop ou laptop! Antes de fazer isso, não deixe de verificar +a impressão digital do serviço `SSH` do sistema de resgate. A partir do seu computador: diff --git a/vservers.md b/vservers.md deleted file mode 100644 index 6a77259..0000000 --- a/vservers.md +++ /dev/null @@ -1,81 +0,0 @@ -[[!toc levels=4]] - -Linux-VServers num Servidor Debian -================================== - -Considerando um sistema Debian [instalado de acordo com o padrão](../install), esta seção trata da configuração do ambiente para [Linux-VServers](http://www.linux-vserver.org/). - -Criação do volume ------------------ - -Para preparar o volume do `/var/vservers`, primeiramente verifique o espaço disponível: - - vgdisplay vg - -Como examplo, consideremos uma saída que contenha um `Free PE` equivalente a `232811`, correspondente aos +/-900GB remanescentes no disco. Assim, crie o `/dev/vg/vservers` e comece com a escrita de sujeira no dispositivo: - - lvcreate -l 232811 -n vservers vg - dd if=/dev/urandom of=/dev/vg/vservers - -Esse procedimento vai demorar umas boas horas (talvez até alguns dias), então basta deixar a máquina ligada até que ele seja concluído e que então seja possível criar o volume criptografado e o sistema de arquivos em `/dev/vg/vservers`. - -Criptografia e pontos de montagem ---------------------------------- - -Após encher o disco com dados aleatórios, proceda com a criptografia do volume: - - cryptsetup -h sha256 -c aes-cbc-essiv:sha256 -s 256 luksFormat /dev/vg/vservers - cryptsetup luksOpen /dev/vg/vservers vservers - mkfs.ext4 /dev/mapper/vservers - -O `/etc/crypttab` deve ganhar uma linha adicional para que o sistema tente descriptografar a partição no boot: - - vservers /dev/mapper/vg-vservers none luks,cipher=aes-cbc-essiv:sha256 - -O `/etc/fstab` também deve ganhar uma linha: - - /dev/mapper/vservers /var/vservers ext4 defaults,errors=remount-ro 0 0 - -Agora basta montar a nova partição: - - mkdir -p /var/vservers && mount /var/vservers - -Configurando o ambiente ------------------------ - -Preparamos o diretório base dos vservers da seguinte forma: - - rm -f /etc/vservers/.defaults/vdirbase - ln -s /var/vservers /etc/vservers/.defaults/vdirbase - setattr --barrier /var/vservers - -Criando um VServer ------------------- - -Escolha a configuração: - - export vserver="nome-do-vserver" - export project="projeto.org" - export context="numero-do-contexto" # exemplo: 2 - export network="configuracao-de-rede" # exemplo: eth0:192.168.0.2/24 - export version="lenny" # versao do debian - -Crie o vserver: - - vserver $vserver build -n $vserver --context $context --hostname $vserver.$project \ - --interface $network -m debootstrap -- -d $version - -Agora basta iniciá-lo: - - vserver $vserver start - -E instalar os aplicativos básicos: - - vserver $vserver exec apt-get update - vserver $vserver exec apt-get upgrade - vserver $vserver exec apt-get install lsb-release cron sudo openssh-server locales openssl - -Para inicialização automática do vserver durante a inicialização do servidor: - - echo default > /etc/vservers/$vserver/apps/init/mark - |