O Mundo Arcano de CEFALA Admin

Interface cgit para os repositórios do CEFALA

2025-08-20T06:47:00-03:00

Faz tempo que eu desejava instalar uma interface web para os repositórios Git do CEFALA, que se encontram na VM git.cefala.org. Dentre as inúmeras interfaces disponíveis, acabei optando pelo cgit, que reúne as vantagens de ser leve (escrito em C), eficaz (sem PHP nem JavaScript) e de fácil configuração, além de fornecer (quase) tudo que se espera de uma interface web para o Git.

No caso do CEFALA, apenas a VM www.cefala.org é accessível via HTTP e HTTPS. Neste caso, é necessário utilizar o mecanismo de proxy do Apache2 para poder acessar o servidor cgit na VM git.cefala.org. O servidor HTTP/HTTPS virtual está definido na configuração do Apache da VM www.cefala.org e é acessível pela URL https://cgit.cefala.org.

Por hora, os seguintes repositórios são visíveis na interface cgit:

cefala-cgit: Configuração do servidor cgit (vide abaixo)
apt-debian-pinning: configuração do APT pinning para as diversas distribuições da Debian, descrita num artigo deste blog
git-scripts: Scripts de ajuda para uso do Git na VM git.cefala.org, descritos num artigo deste Blog
notmyidea-pt: Tradução do tema notmyidea do Pelican em português. Este tema é usado neste Blog.

O servidor cgit está configurado para aceitar um arquivo de descrição README.md na raiz de cada repositório (exemplo) e também para colorir sintaticamente os arquivos mostrados (exemplo).

É possível também clonar os repositórios via HTTP:

$ git clone http://cgit.cefala.org/cgit/cefala-cgit

A configuração deve ser feita tanto na VM www.cefala.org (servidor Apache) quanto na VM git.cefala.org (servidor cgit). Ambas configurações são feitas através do projeto cefala-cgit.

Na VM www.cefala.org:

$ git clone cefala-admin@git.cefala.org:cefala-cgit.git
$ cd cefala-cgit
$ sudo make apache-install

Na VM git.cefala.org:

$ git clone /var/git/cefala-cgit
$ cd cefala-cgit
$ sudo make cgit-install

Modificações permanentes nos arquivos de configuração devem ser registradas (commit) e subidas (push) no repositório centralizado:

$ git add apache cgitrc cgitrepos
$ git commit -m 'Modificação na configuração para [isto] ou [aquilo]'
$ git push

P.S.: Eu nunca sei como traduzir commit e push em português. Algumas pessoas já tentaram fazer isto, ali e acolá.

Certbot is our friend

2022-07-16T20:42:00-03:00

Há cinco anos e meio, Leandro Leão escreveu um ótimo artigo sobre a utilização do Let's Encrypt para habilitar o acesso com criptografia (HTTPS) dos servidores web do CEFALA. Naquela época, o Let's Encrypt era incipiente e não havia uma maneira totalmente automatizada de instalar os certificados.

Neste meio tempo, as coisas evoluíram e existe agora um programa para tanto, o certbot.

No exemplo abaixo, descrevo o processo de criação de um novo site foo.cefala.org, que responderá em HTTPS. Suponhamos que, no servidor www.cefala.org tenhamos um arquivo de configuração /etc/apache2/sites-available/foo.conf com o seguinte conteúdo:

<VirtualHost *:80>
    ServerName foo.cefala.org
    DocumentRoot /var/www/foo
</VirtualHost>

Suponhamos também que, no diretório root deste novo site, haja um arquivo /var/www/foo/index.html com o seguinte conteúdo:

<html><body>FOO</body></html>

Este site pode então ser ativado no servidor Apache:

$ sudo a2ensite foo
$ sudo systemctl reload apache2

O novo site se tornará assim acessível através da URL http://foo.cefala.org/.

Para que ele seja também acessível via HTTPS, basta fazer o seguinte:

$ sudo certbot --apache -d foo.cefala.org

Um novo certificado Let's Encrypt será gerado para o site foo.cefala.org e os arquivos correspondentes serão colocados no diretório /etc/letsencrypt/live/foo.cefala.org.

Como a opção --apache do comando certbot foi usada, o arquivo /etc/apache2/sites-available/foo.conf é modificado automaticamente e terá este conteúdo:

<VirtualHost *:80>
    ServerName foo.cefala.org
    DocumentRoot /var/www/foo
    RewriteEngine on
    RewriteCond %{SERVER_NAME} =foo.cefala.org
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

Além disto, um novo arquivo /etc/apache2/sites-available/foo-le-ssl.conf será criado, com este conteúdo:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName foo.cefala.org
    DocumentRoot /var/www/foo
    SSLCertificateFile /etc/letsencrypt/live/foo.cefala.org/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/foo.cefala.org/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

O novo site em HTTPS será automaticamente habilitado para o Apache. Basta então lançar:

$ sudo systemctl reload apache2

e o site https://foo.cefala.org/, com criptografia SSL, estará acessível.

Religando as VMs

2022-07-12T18:15:00-03:00

O compositor de teclado internacional

2021-11-09T08:40:00-03:00

Quando um usuário de computador utiliza o seu teclado para escrever em línguas diferentes ele se confronta sempre com o problema de introduzir caracteres especiais no seu texto. Isto vai além dos caracteres acentuados (quem nunca precisou digitar o nome daquele famoso vulcão Eyjafjallajökull, que fica em Suðurland, na Islândia?) e também diz respeito à caracteres usuais como moedas internacionais (€, £, ¥, etc), o alfabeto grego (α, β, γ, etc), ou mesmo caracteres de pontuação que não se encontram normalmente em teclados (–, «, “, etc).

Usuários de X11 em Linux (isto é, qualquer usuário de ambiente de trabalhos como KDE, Gnome, ou outros) dispõem de um mecanismo para digitar facilmente estes caracteres especiais, conhecido em inglês como “Compose key”, traduzido em português como tecla de composição.

A ideia é muito simples. Para obter, por exemplo, o caractere ä (a com trema), basta teclar Compose seguido de a e ".

Você dirá : “Beleza, mas como eu teclo Compose?” Quando a ideia de composição foi implementada, nos anos 1980, alguns teclados foram produzidos com a tecla Compose, como as teclas Alt, Ctrl e Shift, que existem em praticamente em qualquer atual.

Em Linux, é possível configurar uma das teclas do teclado como sendo a tecla Compose. Eu restringirei este artigo ao ambiente de trabalho Gnome.

Há duas maneiras de definir a tecla Compose no sistema Gnome. Se você gosta de usar o mouse, abra o painel de configurações e selecione a aba “Teclado”. Na seção “Entrada de caracteres especiais”, escolha a “Tecla de composição” que você desejar. No meu laptop, como eu uso muito pouco a tecla Windows (aquela que, no meu teclado, fica ao lado da tecla Alt da esquerda), eu a escolhi como a minha tecla Compose. No painel de configurações do sistema Gnome, esta tecla é identificada como “Super da esquerda”.

A segunda maneira de definir a tecla Compose á através do comando gsettings, por exemplo :

$ gsettings set org.gnome.desktop.input-sources xkb-options "['compose:lwin']"

No exemplo acima, lwin corresponde à tecla Windows da esquerda. Com esta técnica, é possível fazer uma configuração automática, que pode ser propagada de uma conta para outra, ou de um sistema para outro.

Agora que a tecla Compose foi definida, basta consultar o arquivo /usr/share/X11/locale/en_US.UTF-8/Compose para saber quais sequências de composição são definidas. Neste arquivo, você verá linhas como esta abaixo, que corresponde ao exemplo que eu dei acima (a com trema):

<Multi_key> <a> <quotedbl> : "ä" adiaeresis # LATIN SMALL LETTER A WITH DIAERESIS

Em sistemas onde a localização é definida como sendo pt_BR, algumas sequências suplementares são definidas no arquivo /usr/share/X11/locale/pt_BR.UTF-8/Compose.

De qualquer maneira, não é necessário decorar todas as sequências de composição, pois elas são, em geral, graficamente mnemônicas. Por exemplo, para obter o caractere polonês Ł, basta teclar Compose+L+/ ou Compose+/+L, para obter o símbolo da moeda japonesa ¥ (yen), basta teclar Compose+y+= ou Compose+Y+= ou Compose+=+y ou Compose+=+Y (note que y maiúsculo ou minúsculo funciona neste caso), para obter o símbolo de copyright ©, basta teclar Compose e qualquer combinação de c e o maiúsculos ou minúsculos.

Por fim, é possível também definir as suas combinações próprias de sequências de composição, no arquivo ~/.XCompose, com a mesma sintaxe dos arquivos /usr/share/X11/locale/*/Compose. Por exemplo, esta a minha maneira de definir a sequência para a letra grega α (alfa):

<Multi_key> <a> <space> : "α" U03B1 # GREEK SMALL LETTER ALPHA

Atualizando este Blog

2021-04-06T08:47:00-03:00

Fazem anos que este Blog não foi atualizado. Neste meio tempo, o Pelican, o motor que move este Blog, passou da versão 3 para a versão 4.6. Eu atualizei o sistema da VM git.cefala.org para refletir a atualização do Pelican.

Entre as novidades, está o esquema moderno de plugins do Pelican. O presente Blog usa apenas os plugins linkclass e avatar, que são instalados na VM git.cefala.org via pip.

As modificações que foram feitas para atualizar o Blog podem ser visualizadas com este comando:

$ git diff 9301493..

Quase nada mudou do ponto de vista dos usuários (isto é, autores de artigos) deste blog. A única mudança importante é o fato de que a categoria do artigo é agora determinada pelo nome do sub-diretório onde o arquivo fonte *.md se encontra. Antigamente, era necessário colocar o campo Category: no cabeçalho do artigo.

Eu também aproveitei para participar do movimento anti-racista do software livre, renomeando o ramo principal do repositório Git de master para main. Quem já tem um repositório clonado localmente, terá que fazer isto aqui:

$ git branch -m master main
$ git fetch origin
$ git branch -u origin/main main

Configuração Apache sob Git

2017-09-15T20:45:00-03:00

A configuração do servidor HTTP Apache da VM www.cefala.org está agora sob controle Git. Para obter os arquivos, rode o seguinte neste servidor:

$ git clone cefala-admin@git.cefala.org:cefala-apache-config
$ cd cefala-apache-config
$ ls -p
Makefile  www/

O diretório www corresponde ao valor retornado pelo comando hostname. Este projeto poderá ser usado para configurar o Apache de outros servidores do CEFALA mas, pelo momento, somente a VM www responde ao protocolo HTTP. Este design também assegura que os arquivos não seram instalados por erro em outras VMs.

Pelo momento, somente o diretório sites-available está no repositório, mas isto pode mudar no futuro:

$ ls -lR www
www:
total 4
drwxr-xr-x 2 rlaboiss rlaboiss 4096 Sep 15 20:50 sites-available

www/sites-available:
total 52
-rw-r--r-- 1 rlaboiss rlaboiss 1444 Sep 15 20:50 000-default.conf
-rw-r--r-- 1 rlaboiss rlaboiss  315 Sep 15 20:50 admin-blog.conf
-rw-r--r-- 1 rlaboiss rlaboiss  205 Sep 15 20:50 audio.conf
-rw-r--r-- 1 rlaboiss rlaboiss  166 Sep 15 20:50 blog.conf
-rw-r--r-- 1 rlaboiss rlaboiss  163 Sep 15 20:50 cefalaorg.conf
-rw-r--r-- 1 rlaboiss rlaboiss  102 Sep 15 20:50 cefalaorgRedirect.conf
-rw-r--r-- 1 rlaboiss rlaboiss  339 Sep 15 20:50 cefalaorg-tls.conf
-rw-r--r-- 1 rlaboiss rlaboiss  159 Sep 15 20:50 fonologia.conf
-rw-r--r-- 1 rlaboiss rlaboiss  155 Sep 15 20:50 issp2006.conf
-rw-r--r-- 1 rlaboiss rlaboiss  159 Sep 15 20:50 morphala.conf
-rw-r--r-- 1 rlaboiss rlaboiss  304 Sep 15 20:50 netscan.conf
-rw-r--r-- 1 rlaboiss rlaboiss  175 Sep 15 20:50 praat.conf
-rw-r--r-- 1 rlaboiss rlaboiss  282 Sep 15 20:50 sii.conf

Eu considerei todos os sites que estão atualmente (2017-09-15) ativados através dos links existentes em /etc/apache2/sites-enabled. Para adicionar um novo site, basta adicionar um novo arquivo .conf e rodar:

$ sudo make install

Em seguida, não se esqueça de adicionar o arquivo ao repositório e fazer o git push.

Existe também um comando para verificar, a cores e em 2D, as diferenças entre os arquivos que estão no diretório de trabalho e aqueles que estão no diretório de configuração do Apache:

$ make diff

Isto permitirá de detetar arquivos que foram introduzidos manualmente na configuração sem passar pelo Git.

Update (2022-07-20):

A estrutura de diretórios do projeto Git foi modificada e corresponde agora à estrutura no diretório /etc:

$ ls -lR www
www:
total 8
drwxr-xr-x 3 rlaboiss rlaboiss 4096 Jul 19 03:28 apache2
drwxr-xr-x 2 rlaboiss rlaboiss 4096 Jul 19 03:22 letsencrypt

www/apache2:
total 4
drwxr-xr-x 2 rlaboiss rlaboiss 4096 Jul 19 12:02 sites-available

www/apache2/sites-available:
total 56
-rw-r--r-- 1 rlaboiss rlaboiss 1444 Sep 15  2017 000-default.conf
-rw-r--r-- 1 rlaboiss rlaboiss  461 Jul 19 12:02 admin-blog.conf
-rw-r--r-- 1 rlaboiss rlaboiss  555 Jul 19 03:21 admin-blog-le-ssl.conf
-rw-r--r-- 1 rlaboiss rlaboiss  205 Sep 15  2017 audio.conf
-rw-r--r-- 1 rlaboiss rlaboiss  166 Sep 15  2017 blog.conf
-rw-r--r-- 1 rlaboiss rlaboiss  174 Oct 16  2017 cefalaorg.conf
-rw-r--r-- 1 rlaboiss rlaboiss  102 Sep 15  2017 cefalaorgRedirect.conf
-rw-r--r-- 1 rlaboiss rlaboiss  425 Oct 16  2017 cefalaorg-tls.conf
-rw-r--r-- 1 rlaboiss rlaboiss  159 Sep 15  2017 fonologia.conf
-rw-r--r-- 1 rlaboiss rlaboiss  155 Sep 15  2017 issp2006.conf
-rw-r--r-- 1 rlaboiss rlaboiss  159 Sep 15  2017 morphala.conf
-rw-r--r-- 1 rlaboiss rlaboiss  304 Sep 15  2017 netscan.conf
-rw-r--r-- 1 rlaboiss rlaboiss  175 Sep 15  2017 praat.conf
-rw-r--r-- 1 rlaboiss rlaboiss  282 Sep 15  2017 sii.conf

www/letsencrypt:
total 4
-rw-r--r-- 1 rlaboiss rlaboiss 953 Jul 19 03:22 options-ssl-apache.conf

Note também, que o arquivo www/letsencrypt/options-ssl-apache.conf foi adicionado ao projeto. Este arquivo é automaticamente gerado pelo certbot (veja o artigo deste Blog sobre isto). Neste arquivo, a opção SSLSessionTickets off foi comentada, o que não é caso do arquivo original.

Os módulos Apache necessários são também ativados via make enable-modules.

A mensagem mostrada pelo comando make diff também foi modificada. Na versão atual, os arquivos que estão no sistema (em /etc/apache2/sites-available) e que não estão sob controle Git são listados separadamente. Além disto as diferenças entre as listas de módulos Apache listados em Makefile e aqueles que estão habilitados no sistema (isto é, os arquivos em /etc/apache2/sites-enabled/*.conf) também é mostrada.

Reinicializando o servidor via SMASH CLP

2017-07-24T14:44:00-03:00

O servidor do CEFALA desligou abruptamente no dia 23 de julho de 2017 às 16h30. Hani avisou hoje:

“Para fins de registro, agora pela manhã, ao não conseguir contato com o servidor do cefala 150.164.32.8, que é uma máquina virtual, nem com 150.164.32.49, que é o host que hospeda o servidor virtual, verifiquei que era possível contactar a 150.164.32.39 que, creio eu, seja a placa de rede inteligente do servidor físico.

Acessei então a placa:

$ ssh root@150.164.32.39

e entrei no sistema SMASH CLP por meio do qual foi possível reiniciar o servidor com os comandos:

->cd system1
COMMAND COMPLETED :
cd system1
ufip=/system1
->start
COMMAND COMPLETED :
start
ufip=/system1
Start: Target started successfully

Encontrei os comandos básicos do SMASH CLP nesta página.”

Don't go /home-less!

2016-11-12T18:15:00-02:00

Recentemente, o servidor kvm teve de ser reinicializado de maneira brutal e as VMs que são nele abrigadas não foram enviadas em hibernação, como deveriam ter sido. Uuando kvm retorna à vida, algumas das VMs que estão em seu bojo não são inicializadas corretamente. Isto acontece porque a partição /home, disponibilizada pela VM nfs ainda não está disponível via NFS quando as outras VMs git, a dev e a sci tentam montá-la.

Este problema poderia ser corrigido com um script de hook no servidor kvm colocado em /etc/libvirt/hooks/qemu. Este script é chamado várias vezes durante a inicialização de cada VM. Por exemplo, ele é chamado quando libvirt terminou de fazer o labeling de todos os recursos mas ainda não inicializou a VM hospedada, desta forma:

/etc/libvirt/hooks/qemu guest_name start begin -

Neste caso, bastaria colocar no script de hook o seguinte código:

#!/bin/sh
if [ "$2" = start -a "$1" != CEFALA-NFS ] ; then
    sleep 60
fi

Entretanto, como o Arlindo bem lembrou, existem dezenas de opções para Ligar e Desligar as VMs e seria um tanto crítico intervir com hooks em algo tão simples, que pode afetar o desligamento correto das VMs (caso esse sleep seja executa muitas vezes durante a hibernação a VM corre o risco de ultrapassar o timeout e ser encerrada abruptamente).

Resolvemos, então, adotar um outro método, baseado no script cron /etc/cron.hourly/mount-home contendo o seguinte código:

#!/bin/sh
grep -q '172.16.10.1:/home' /etc/mtab || mount -a

Este script foi integrado no repositório Git cefala-vm-conf (descrito em um outro artigo deste blog). Para instalá-lo em cada VM, basta fazer:

$ git clone cefala-admin@git.cefala.org:cefala-vm-conf.git
$ cd cefala-vm-conf
$ sudo make cron

P.S.: O título deste post não tem nada a ver com os Shoulders e a sua canção!

Nobreak novo, saudades do antigo

2016-10-09T23:10:00-03:00

Hani avisou na nossa lista de difusão cefala-admin:

“Para os que não estão informados, há algumas semanas, o nobreak APC Back UPS RS 1500 estava apitando (emitindo sons de alarme) e, depois de algumas horas, decidimos substituí-lo pelo nobreak APC Back UPS BR1200, mais novo, que estava na minha sala.

A interface do nobreak antigo era por meio de um conector RJ45, enquanto que a do novo é por meio de uma porta USB. Ontem, Arlindo alterou a configuração do sistema de monitoramento de carga do nobreak para ler os dados na nova interface.

Ao fazer isto, foi necessário desligar o servidor uma vez desligando as máquinas virtuais ao invés de hiberná-las. Desculpem se isto tiver causado a interrupção de algum processo em execução :-(

Durante o processo, descobrimos que o nobreak antigo tinha uma autonomia de aproximadamente 40 minutos, a qual é algo em torno do dobro da autonomia do nobreak atual, que é de aproximadamente 20 minutos. (Vejam a curva abaixo. Nosso servidor consome em torno de 200 watts.)

Entretanto, fiquei sem entender o por quê de uma diferença tão grande. O nobreak antigo possui duas baterias de 12 V e 9 Ah, enquanto que o novo possui duas baterias de 12 V e 7 Ah.

As baterias de 12 V e 7 Ah em série (i.e. 24 V) deveriam ser capazes de fornecer uma potência de 200 watts por 50 min (7/(200/24)×60) com uma eficiência de 100%. Se o nobreak está aguentando apenas algo em torno de 20 minutos, a eficiência seria de apenas 40%. (Não estou considerando uma possível condição ruim das baterias, pois o valor foi calculado com base na curva do fabricante em anexo e não nos testes que eu e Arlindo fizemos ontem.)

No caso do nobreak antigo, as baterias de 12 V e 9 Ah em série (i.e. 24 V) deveriam ser capazes de fornecer uma potência de 200 watts por 65 min (9/(200/24)×60) com uma eficiência de 100%. Se o nobreak estava aguentando apenas algo em torno de 40 minutos, a eficiência era de 62%, o que não é alto, mas é bem melhor que o obtido com o nobreak novo.”

Arlindo completou:

“Eu utilizei uma calculadora para estimar o consumo de energia em função dos componentes do nosso servidor. Cheguei ao seguinte resultado:”

            Motherboard: Server
                 Socket: Socket LGA 1366 CPU: 1 x Intel Xeon E5620
              CPU Speed: 2400 MHz CPU Vcore: 1.2 V CPU Utilization: 50%

                 Memory: 6 x 8GB DDR3 Module

       Video Card Set 1: 1 x NVIDIA GeForce GTX 560
             Core Clock: 810 MHz
           Memory Clock: 1000 MHz

                Storage: 5 x SATA 7.2K RPM

          Optical Drive: 1 x DVD-RW/DVD+RW Drive

               Keyboard: 1 x Standard Keyboard
                  Mouse: 1 x Standard Mouse

                    Fan: 1 x 120mm

   Computer Utilization: Always On (24/7)

           Load Wattage: 396 W               -------------------------
 Recommended UPS rating: 750 VA              | +3.3V |   +5V |  +12V |
Recommended PSU Wattage: 446 W               --------+-------+--------
                                             | 9.4A  | 18.1A | 27.0A |
                                             --------+-------+--------
                                             |     122W      |  325W |
                                             -------------------------

Informações Estatísticas CEFALA KVM

2016-06-16T12:40:00-03:00

Após utilizar o MRTG na criação de um gráfico estatístico para monitorar a tensão de entrada do nobreak, visto que este estava chaveando ininterruptamente em alguns momentos, o trabalho realizado para um gráfico foi aproveitado para criar diversos outros relacionados ao Servidor CEFALA KVM. Estes gráficos são úteis para acompanhar dados de CPU, Memória, Discos, Ocupação, Processos, Rede de Comunicação, entre outros como exemplificado abaixo:

Os demais gráficos, atualizados a cada cinco minutos, podem ser acessados através do endereço: http://150.164.32.49/mrtg.

Do the fscking thing

2016-05-28T10:12:00-03:00

No dia 22 de maio de 2016, a energia elétrica foi desligada na parte da manhã na Engenharia da UFMG para que a subestação fotovoltaica instalada seja ligada. O sistema do servidor kvm.cefala.org foi desligado graciosamente, de acordo com o arquivo syslog:

May 22 08:35:39 CEFALA apcupsd[1168]: Initiating system shutdown!
May 22 08:35:39 CEFALA apcupsd[1168]: User logins prohibited
May 22 08:35:39 CEFALA systemd[24851]: Stopping Default.
May 22 08:35:39 CEFALA systemd[24851]: Stopped target Default.
May 22 08:35:39 CEFALA systemd[24851]: Stopping Basic System.
May 22 08:35:39 CEFALA systemd[24851]: Stopped target Basic System.
May 22 08:35:39 CEFALA systemd[24851]: Stopping Paths.
May 22 08:35:39 CEFALA systemd[24851]: Stopped target Paths.
May 22 08:35:39 CEFALA systemd[24851]: Stopping Timers.
May 22 08:35:39 CEFALA systemd[24851]: Stopped target Timers.
May 22 08:35:39 CEFALA systemd[24851]: Stopping Sockets.
May 22 08:35:39 CEFALA systemd[24851]: Stopped target Sockets.
May 22 08:35:39 CEFALA systemd[24851]: Starting Shutdown.
May 22 08:35:39 CEFALA systemd[24851]: Reached target Shutdown.
May 22 08:35:39 CEFALA systemd[24851]: Starting Exit the Session...
May 22 08:35:39 CEFALA systemd[24851]: Received SIGRTMIN+24 from PID 27192 (kill).
May 22 08:35:39 CEFALA smartd[1127]: smartd received signal 15: Terminated
May 22 08:35:39 CEFALA rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="1197" x-info="http://www.rsyslog.com"] exiting on signal 15.

O nobreak do servidor aguentou 40 minutos e o sistema de detecção de baixa autonomia das baterias funcionou a contento:

May 22 07:55:56 CEFALA apcupsd[1168]: Running on UPS batteries.
[…]
May 22 08:35:39 CEFALA apcupsd[1168]: Battery charge below low limit.

Entretanto, quando a energia elétrica foi restabelecida, o servidor não voltou ao ar. O processo de boot foi interrompido, devido a problemas no sistema de arquivos que já existiam antes do nobreak entrar em ação:

May 22 08:35:37 CEFALA kernel: [2818552.456483] EXT4-fs error (device md3): ext4_read_dirblock:902: inode #103025245: block 32: com\ m find:Directory hole found

Para evitar que o servidor fique fora do ar em situações como esta no futuro, eu fiz as modificações abaixo, de modo a forçar a verificação do sistema de arquivos, via fsck, no momento do boot (inspiradas em uma questão do StackExchange):

Criação do arquivo vazio /forcefsck, na raiz do sistema de arquivos. A presença deste arquivo é detectada pelo script de inicialização do sistema /etc/init.d/checkfs.sh. Entretanto, em sua execução, este script apaga o arquivo /forcefsck.
Para a coisa ficar perene, o arquivo /etc/default/grub deve ser modificado com a adição de "forcefsck" na variável GRUB_CMDLINE_LINUX. O script /etc/init.d/checkfs.sh detecta a presença da opção forcefsck em /proc/cmdline. Existe também a opção do kernel fsck.mode=force, mas eu não encontrei documentação sobre ela para sistemas Debian.
Enfim, para que o fsck seja executado sem intervenção humana, adicionei a linha FSCKFIX=yes no arquivo /etc/default/rcS.

Como não é possível, e nem desejável, fazer o teste desta nova configuração, teremos que esperar pelo próximo apagão e que ele ocorra num momento em que o sistema de arquivos contenha erros.

Update: A natureza nos deu uma mão e fez com que o teste acima pudesse ser realizado. No dia 21 de junho de 2016, houve falta de energia elétrica no CEFALA. O nobreak aguentou em torno de 40 minutos e o shutdown e o reboot foram realizados como esperado. Além disto, a partição /dev/md3 continha erros, que foram corrigidos convenientemente pelo fsck. Estas são as linhas relevantes do arquivo syslog:

Jun 21 09:32:03 CEFALA apcupsd[1133]: Battery charge below low limit.
Jun 21 09:32:03 CEFALA apcupsd[1133]: Initiating system shutdown!
Jun 21 09:32:03 CEFALA apcupsd[1133]: User logins prohibited
Jun 21 09:32:03 CEFALA smartd[1112]: smartd received signal 15: Terminated
Jun 21 09:32:03 CEFALA rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="1406" x-info="http://www.rsyslog.com"] exiting on signal 15.
Jun 21 10:21:00 CEFALA rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="1399" x-info="http://www.rsyslog.com"] start
Jun 21 10:21:00 CEFALA hdparm[282]: Setting parameters of disc: (none).
Jun 21 10:21:00 CEFALA keyboard-setup[283]: Setting preliminary keymap...done.
Jun 21 10:21:00 CEFALA kernel: [    0.000000] Initializing cgroup subsys cpuset
Jun 21 10:21:00 CEFALA mdadm-raid[280]: Generating udev events for MD arrays...done.
Jun 21 10:21:00 CEFALA kernel: [    0.000000] Initializing cgroup subsys cpu
Jun 21 10:21:00 CEFALA kernel: [    0.000000] Initializing cgroup subsys cpuacct
Jun 21 10:21:00 CEFALA kernel: [    0.000000] Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)
Jun 21 10:21:00 CEFALA kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=2cfbd920-4a21-4bcd-9e07-4b7337f6ea74 ro quiet
Jun 21 10:21:00 CEFALA kernel: [    0.000000] e820: BIOS-provided physical RAM map:
Jun 21 10:21:00 CEFALA systemd-fsck[487]: /dev/md3: recovering journal
Jun 21 10:21:00 CEFALA kernel: [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009a3ff] usable
Jun 21 10:21:00 CEFALA kernel: [    0.000000] BIOS-e820: [mem 0x000000000009a400-0x000000000009ffff] reserved
Jun 21 10:21:00 CEFALA kernel: [    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
Jun 21 10:21:00 CEFALA kernel: [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000008c11afff] usable
Jun 21 10:21:00 CEFALA kernel: [    0.000000] BIOS-e820: [mem 0x000000008c11b000-0x000000008c1fafff] ACPI NVS
Jun 21 10:21:00 CEFALA kernel: [    0.000000] BIOS-e820: [mem 0x000000008c1fb000-0x000000008c4e7fff] ACPI data

O MRTG implementado pelo Arlindo e explicado num outro artigo, mostra como a carga da bateria evoluiu durante o apagão:

[N.B.: Segundo Arlindo, a existência das faixas brancas de menor espessura ao longo do gráfico não é algo que está relacionado à saúde do nobreak, mas ao script de coleta de dados via USB.]

As VMs não morrem, só hibernam

2016-03-23T07:55:00-03:00

Arlindo manda avisar que as VMs do CEFALA são resilientes aos apagões brasileiros:

From: Arlindo F. Neto
Subject: Estado do Nobreak do CEFALA
Date: Tue, 22 Mar 2016 14:42:22 -0300
To: cefala-admin

Pessoal,

Compartilhando uma informação interessante. Notei uma diferença considerável de uptime entre as VMs (67 dias para a SCI) e o Servidor do CEFALA (12 dias). A diferença é sinal de que a metodologia de hibernar as VMs está funcionando, bem como a detecção de falta de eletricidade e shutdown do hospedeiro, como pode ser visto no log abaixo:

2016-03-10 08:15:29 -0300 Power failure.
2016-03-10 08:15:35 -0300 Running on UPS batteries.
2016-03-10 08:58:08 -0300 Battery charge below low limit.
2016-03-10 08:58:08 -0300 Initiating system shutdown!
2016-03-10 08:58:08 -0300 User logins prohibited
2016-03-10 08:58:08 -0300 apcupsd exiting, signal 15
2016-03-10 08:58:08 -0300 apcupsd shutdown succeeded

Automatizemos a renovação de certificados Let's Encrypt para acalmar o meu TOC

2016-02-26T18:00:00-03:00

Vocês já devem ter percebido que eu tenho um TOC e que este TOC é relacionado com a reprodutibilidade das configurações. Sempre que eu configuro algo no sistema, eu penso: "E se eu precisar de fazer isto de novo amanhã, será que eu vou me lembrar de todos os passos?". Pelo visto, não é só TOC não, tem também um pouco de Mal de Alzheimer precoce por aí. Ah, e eu já contei para vocês que eu tenho um TOC?

Bom, vamos ao que interessa. Há alguns meses, o Leandro Leão instalou o certificado da Let's Encrypt na VM www.cefala.org, tudo muito bem explicado em outro artigo deste blog. Como este certificado expira de três em três meses, o Leandro criou um script de renovação automática e adicionou uma linha na crontab do usuário root. Aí, me bateu aquele TOC e eu decidi automatizar o processo usando Git, make e systemd.

Antes de mais nada, deixe-me justificar a mudança do crontab para o systemd. Apesar de não ter ainda aprovação unânime na comunidade de software livre, o systemd já se tornou o substituto por default do sysvinit nas principais distribuições GNU/Linux (Debian, Fedora, Arch, CoreOS, etc.). Mais especificamente com relação ao assunto do presente artigo, o systemd permite um controle mais fino de tarefas periódicas do que o crontab, além de integrar automaticamente o log das tarefas. Tem gente por aí que já explicou direitinho como migrar do crontab ao systemd.

Pois bem, eu criei assim um repositório Git para esta configuração específica do Let's Encrypt na VM www.cefala.org. Basta então fazer:

$ git clone cefala-admin@git.cefala.org:/var/git/cefala-admin/letsencrypt-www
$ cd letsencrypt-www
$ sudo make

Com estes comandos, o script .sh de renovação automática é instalado em /usr/local/sbin e os arquivos .service e .timer são instalados e inicializados para o systemd. O script de renovação escrito pelo Leandro usa o comando renew do programa letsencrypt. Um novo certificado TLS só é obtido se o certificado corrente for vencer em menos de 30 dias. Graças ao timer do systemd, este script rodará todos os dias de madrugada na VM www.cefala.org.

Uma das coisas legais no systemd é que não é preciso se preocupar com o arquivo de log, pois fica tudo registrado automaticamente no /var/log/syslog, o que pode ser consultado com journalctl ou com o seguinte comando:

$ sudo systemctl status letsencrypt-renew-tls-certs.service

Ufa, consegui acalmar o meu TOC!

Update: No fim das contas, me toquei que o sisteminha que escrevi é genérico o suficiente para ser útil a outras pessoas. Coloquei-o então no GitHub. Você pode cloná-lo desta maneira:

$ git clone https://github.com/rlaboiss/letsencrypt-systemd.git

Usando o Let's Encrypt

2015-12-10T09:16:00-02:00

Sobre o Let's Encrypt

O projeto Let's Encrypt entrou na fase beta pública na semana passada, começando a oferecer certificados TLS/SSL válidos a qualquer site interessado.

O objetivo do projeto é oferecer, gratuitamente, uma maneira simples e automatizada para administradores ativarem e manterem o protocolo TLS (antigamente SSL) em seus websites.

Ele é de código aberto e pode ser encontrado no github: https://github.com/letsencrypt/letsencrypt.

Instalação do certificado

Antes de qualquer coisa, é necessário baixar os scripts:

$ git clone https://github.com/letsencrypt/letsencrypt
$ cd letsencrypt

A documentação está disponível em: http://letsencrypt.readthedocs.org/en/latest/index.html

A maneira mais simples de obter e configurar os certificados é com o script letsencrypt-auto rodado como root. Se você não gosta da ideia de executar esse script como root, há um projeto paralelo (não oficial) que talvez lhe interese: https://github.com/diafygi/letsencrypt-nosudo.

Executando o letsencrypt-auto:

$ sudo ./letsencrypt-auto

Ele irá procurar as dependências necessárias e, caso não encontre, automaticamente usará o apt-get para instalá-las.

O let's encrypt mostrará uma lista com os sites encontrados no servidor:

O script enviará uma requisição ao Let's Enrypt solicitando um certificado. Após verificar que o servidor realmente é proprietário da entrada DNS correspondente, o certificado será enviado. Esse processo é automático e não demora mais que alguns segundos. Os certificados são colocados em: /etc/letsencrypt/live

Em seguida você deve escolher se quer habilitar o redirecionamento http -> https, ou prefere manter o site também acessível sem criptografia:

Assim, as modificações serão feitas automaticamente nos arquivos correspondentes em /etc/apache2/sites available. Em seguida, as configurações serão aplicadas ao apache.

Caso queira reverter essas configurações, execute:

$ sudo ./letsencrypt-auto --rollback

O certificado tem validade de 3 meses. Portanto, o certificado deve ser renovado antes disso. Para tal, é só executar novamente o mesmo script e seguir os passos. Em determinado ponto, você verá a seguinte tela:

É só aceitar e o certificado será renovado por mais 3 meses.

É possível automatizar essa renovação utilizando um arquivo de configuração do let's encrypt e o crontab, porém, a intenção do projeto é de oferecer uma ferramenta oficial que faça isso, portanto, por enquanto, é mais interessante esperar pra ver o que eles oferecerão.

Aqui você pode conferir o teste de segurança no domínio cefala.org: https://www.ssllabs.com/ssltest/analyze.html?d=www.cefala.org

Post-scriptum

(por Rafael Laboissière, em 2022-07-16)

A técnica descrita acima é obsoleta e devemos usar agora o certbot.

Homepage default para *.cefala.org

2015-11-22T17:13:00-02:00

O servidor Apache instalado na VM www.cefala.org abriga vários sites web virtuais (“VirtualHost”, na terminologia do Apache). Para que isto funcione corretamente, o servidor DNS instalado em ppgeemaster.cpdee.ufmg.br traduz qualquer nome *.cefala.org para o número IP 150.164.32.8, que é o da VM www.cefala.org.

O problema com esta configuração é que qualquer site *.cefala.org, para o qual não existe VirtualHost definido, exibe a homepage default do Apache, aquela famosa página frugal com o conteúdo seguinte:

It works!
This is the default web page for this server.
The web server software is running but no content has been added, yet.

Isto dá a falsa impressão de que o site existe e o seu conteúdo será um dia criado. Para evitar este constrangimento, eu fiz modificações no arquivo /var/www/index.html da VM www.cefala.org. Resultou nisto aqui: http://nao.existe.e.nunca.existiu.cefala.org/.

P.S.: Para não perder o hábito, e também para perpetuar esta nova configuração, a instalação da homepage default está sob controle Git:

$ git clone cefala-admin@git.cefala.org:/var/git/cefala-admin/default-website

Agrupando a gente

2015-09-12T15:25:00-03:00

Recentemente, eu apresentei as novas regras para a gestão de grupos POSIX no CEFALA. Como eu já mencionei em outras ocasiões, grupos POSIX existem única e exclusivamente para facilitar compartilhamento de arquivos em sistemas UNIX-like.

Entretanto, o grande obstáculo para o compartilhamento de arquivos é o fato de que os nossos diretórios de login têm direitos de acesso muito restritos (drwx------). Isto também causa problemas de acesso do diretório ~/public_html pelo servidor Apache.

Para contornar este problema, foram criados diretórios para cada usuário em /home/shared/, com direitos de acesso drwxr-xr-x. Os diretórios ~/public_html foram também transferidos para /home/shared/* e substituídos por links simbólicos apropriados. O script cefala-add-user também foi modificado de acordo com o que acabei de expor. Eis um exemplo de criação de usuário do CEFALA com a versão mais recente do script:

# cefala-add-user foo
[snip]
# ls -ld /home/foo /home/shared/foo
drwx------ 2 foo foo 4096 Sep 12 04:37 /home/foo
drwxr-xr-x 3 foo foo 4096 Sep 12 04:37 /home/shared/foo
# ls -l /home/foo /home/shared/foo
/home/foo:
total 0
lrwxrwxrwx 1 root root 28 Sep 12 04:37 public_html -> /home/shared/foo/public_html

/home/shared/foo:
total 4
drwxr-xr-x 2 foo foo 4096 Sep 12 04:37 public_html

A configuração do Apache teve de ser modificada, ficando o arquivo /etc/apache2/mods-enabled/userdir.conf desta maneira:

<IfModule mod_userdir.c>
    UserDir /home/shared/*/public_html
    UserDir disabled root

    <Directory /home/shared/*/public_html>
        AllowOverride FileInfo AuthConfig Limit Indexes
        Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
        <Limit GET POST OPTIONS>
            Require all granted
        </Limit>
        <LimitExcept GET POST OPTIONS>
            Require all denied
        </LimitExcept>
    </Directory>
</IfModule>

Para terminar este artigo, aqui vai uma dica sobre o uso de diretórios compartilhados onde os direitos de acesso ao grupo se propagam automaticamente. Como exemplo, eu usarei o meu nome de login (rlaboiss) e um dos grupos ao qual pertenço (issp2006):

$ getent group issp2006
issp2006:*:503:hani,rlaboiss

Imaginem que eu crie um diretório a ser compartilhado pelo outro membro deste grupo:

$ cd /home/shared/rlaboiss
$ mkdir test-bad
$ chgrp issp2006 test-bad
$ chmod o-rx,g=u test-bad
$ ls -ld test-bad
drwxrwx--- 2 rlaboiss issp2006 4096 Sep 12 09:39 test-bad

Agora, imaginem que eu crie um arquivo e um sub-diretório dentro do diretório recém-criado:

$ cd test-bad
$ mkdir foo
$ touch bar
$ ls -l
total 4
-rw-r--r-- 1 rlaboiss rlaboiss    0 Sep 12 09:41 bar
drwxr-xr-x 2 rlaboiss rlaboiss 4096 Sep 12 09:41 foo

Se eu quiser também compartilhar os arquivos foo e bar com membros do grupo issp2006, então eu terei que rodar os comandos chgrp e chmod com os argumentos adequados.

É possível automatizar o processo graças ao uso dos comandos newgrp e umask, além do flag s (“set group ID on execution”) do comando chmod. A coisa seria assim:

$ newgrp issp2006
$ umask 2
$ cd /home/shared/rlaboiss
$ mkdir test-good
$ chmod o-rx,g+s test-good
$ cd test-good/
$ mkdir foo
$ touch bar

e o resultado seria este:

$ ls -ld ../test-good
drwxrws--- 3 rlaboiss issp2006 4096 Sep 12 09:49 ../test-good
$ ls -l
total 4
-rw-rw-r-- 1 rlaboiss issp2006    0 Sep 12 09:49 bar
drwxrwsr-x 2 rlaboiss issp2006 4096 Sep 12 09:49 foo

Notem que não foi preciso usar os comandos chgrp e chmod para ajustar os direitos de acesso do diretório foo e do arquivo bar. O comando newgrp abre um novo shell, de tal maneira que o umask, que normalmente deve ser 22, não se propagará ao shell superior. Não se esqueça de rodar o commando exit ou teclar Ctrl-D para voltar à seção shell original, uma vez terminadas as ações relacionadas com o compartilhamento de arquivos.

Simplificando a criação de usuários na base LDAP

2015-09-09T08:06:00-03:00

Eu até que gosto de interfaces web, como a phpLDAPadmin, mas eu pertenço àqueles tempos passados da informática pré-histórica, onde eu me comunicava com computadores via VT100. Além disto, às vezes, eu tenho ataques de claustrofobia quando fico preso dentro de um browser. Por estas razões, eu resolvi experimentar o script ldapadduser, do pacote Debian ldapscripts, destinado à criação de usuários na base LDAP.

Descobri logo de cara que phpLDAPadmin e ldapscripts não são bom amigos, pois eles adotam esquemas de base LDAP e gabaritos de objetos (“templates” en inglês) incompatíveis entre si. O primeiro passo para a reconciliação dos dois foi a reestruturação da nossa base LDAP. Os objetos do tipo “user account” e “POSIX group” estão agora dentro dos subníveis ou=Groups e ou=People, respectivamente. O atributo ou do LDAP significa “Organizational Unit”. Na interface phpLDAPadmin, vocês verão atualmente algo do gênero:

─> dc=cefala,dc=org (3)
 └────> cn=admin
 └[+]─> ou=Groups (32)
 └[+]─> ou=People (27)

Esta mudança não foi suficiente, pois o gabarito de usuário usado pelo comando ldapadduser é incompatível com aquele usado pelo phpLDAPadmin. Após arrancar os poucos cabelos que restam na minha cabeça ao tentar forçar um gabarito específico no ldapadduser, eu acabei desistindo e escrevi o meu próprio script, cefala-add-user, que está agora no Git:

$ git clone cefala-admin@git.cefala.org:/var/git/cefala-admin/cefala-ldap

Eis um exemplo de criação de usuário utilizando o script:

$ sudo cefala-add-user foo
cefala-add-user:I: Creating user foo.
Last name: Bar
First name: Foo
Email address: foo.bar@example.org
Login shell (default /bin/bash):

    Last name: Bar
    First name: Foo
    Email address: foo.bar@example.org
    Login shell: /bin/bash
Is the above information correct [y/n]: y
New password:
Re-enter new password:
Successfully added group foo to LDAP
adding new entry "cn=Foo Bar,ou=People,dc=cefala,dc=org"

cefala-add-user:I: Created user foo (UID: 1027, GID: 532)

Dois commentários importantes:

Vocês devem ter notado que o script cria um grupo específico para o usuário, cujo nome é idêntico ao nome de login. Esta é a norma na distribuição Debian. Anteriormente, os usuários do CEFALA ficavam todos no mesmo grupo cefala-users. Como os grupos POSIX servem apenas para o compartilhamento de arquivos, não fazia sentido colocar todo mundo dentro do mesmo grupo. Para que tudo fique coerente, eu criei grupos para os usuários existentes e modifiquei os GIDs dos arquivos na partição /home.
Vocês também devem ter notado que o script cria o diretório de login na partição /home. Esta é uma razão a mais para a utilização do script cefala-users ao invés da criação de usuários via phpLDAPadmin. No caso acima, o diretório ficou assim:
```
$ ls -ld /home/foo
drwx------ 40 foo foo 4096 Sep  9 13:12 /home/foo
```

Snapshots no KVM/QEMU

2015-09-04T12:00:00-03:00

Após a atualização do Virt-Manager surgiu um ícone muito curioso na interface de administração da aplicação. Como o ícone estava desativado não foi dado muita atenção para o mesmo. Eis que em uma visita aos amigos do DCC (Projeto FUZA), o referido ícone estava habilitado e funcionando na implementação KVM/QEMU de lá. Ao retornar para o CEFALA o motivo de estar desativado foi encontrado: é utilizado a imagem RAW ao invés de QCOW2. Foi convertido uma das VMs para QCOW2 (recomendado por sinal) e lá estava o ícone ativo.

A própria descrição do ícone explica muito bem o que este faz! Uma vez ativo, é possível criar snapshots das VMs em pleno funcionamento, como demonstrado pela figura abaixo.

Uma vez criado um snapshot ele pode ser manipulado através dos botões, a saber: i) criar novo snapshot; ii) executar VM com a versão do snapshot; iii) restaurar VM na versão do snapshot, e; iv) excluir snapshot.

Toda a manipulação feita no Virt-Manager também pode ser realizada por linha de comando, no Hospedeiro das VMs.

Aparentemente os snapshots são guardados dentro do arquivo QCOW2 da respectiva VM. O snapshot é uma técnica interessante principalmente para manter a integridade da VM. Aos poucos as VMs do CEFALA serão alteradas para o formato QCOW2 possibilitando assim a criação de snapshots.

Impressoras na Rede do CEFALA

2015-09-01T12:38:00-03:00

No intuito de manter a nossa boa e velha - mais velha do que boa - HP LaserJet 1200 funcionando, mapeei sua porta USB para dentro da VM NFS e a configurei para liberar que usuários da rede 10.0.5.0/24 (rede interna do CEFALA) possam utilizá-la sem restrições.

A configuração foi demasiadamente simples e por isto não entrarei em detalhes a respeito da mesma, basicamente um apt-get install cups resolveu todo o problema.

Os passos posteriores foram utilizar a ferramenta web (acessível via http://10.0.5.253:631) para instalar, configurar e compartilhar a impressora.

Configurações para Utilização de Impressoras

HP LaserJet 1200 - para utilizar esta impressora (a única presente no CEFALA) o link de acesso é http://10.0.5.253:631/printers/HP_LaserJet_1200; este endereço deve ser utilizado para configuração seja em Linux, Windows ou MAC. Trata-se de uma impressora de rede que só aceitará serviços caso o solicitante esteja dentro da rede 10.0.5.0/24.

Instalando LDAP + NFS em Estações de Trabalho

2015-08-31T21:11:00-03:00

Há pouco foi feito a instalação de uma Estação de Trabalho física no CEFALA, que utiliza os recursos de autenticação e compartilhamento de arquivos da VM nfs.cefala.org. A máquina roda Ubuntu 14.04, no entanto o procedimento a ser descrito funciona perfeitamente em Debian e acredita-se funcionar em qualquer outra distribuição Debian Like.

O primeiro passo para a configuração é a instalação dos pacotes necessários:

apt-get install libnss-ldap libpam-ldap ldap-utils

Durante a instalação dos pacotes o dpkg fará a configuração passo-a-passo do libnss-ldap, as imagens a seguir mostram como uma Estação de Trabalho deve ser configurada na rede CEFALA.

Ao final da configuração interativa do libnss-pam é necessário ainda a configuração manual de alguns arquivos, a saber:

/etc/nsswitch.conf - é necessário inserir ldap à frente de compat nas linhas passwd, group e shadow, como no exemplo abaixo:

passwd:     compat ldap
group:      compat ldap
shadow:     compat ldap

/etc/pam.d/common-password - para que a alteração de senha via passwd funcione, é necessário remover a opção use_authtok da respectiva linha, que deverá ser alterada para:

password     [success=1 user_unknown=ignore default=die]     pam_ldap.so try_first_pass

/etc/pam.d/common-session - é possível, com auxílio do módulo pam_mkhomedir.so, criar automaticamente o diretório /home/user para os usuários que ainda não o têm. Entretanto, recomenda-se que o administrador que criou o usuário faça manualmente a criação do diretório com permissão 700, visto que a criação automática do diretório não está presente em todos os servidores/estações que o usuário pode logar. Para que o módulo seja ativado, a linha baixo deve ser inserida no final do arquivo de configuração.

session optional        pam_mkhomedir.so skel=/etc/skel umask=077

Ao final da configuração LDAP, deve-se garantir que o serviço libnss-pam tenha sido selecionado para ser iniciado com o sistema:

# sysv-rc-conf libnss-ldap on

A configuração do NFS é mais simples, sendo necessário a instalação do pacote nfs-common:

# apt-get install nfs-common

A linha de configuração que montará a partição /home deverá ser incluída no arquivo /etc/fstab:

10.0.5.253:/home   /home    nfs          rw,async,nfsvers=3,rsize=65536,wsize=65536,timeo=5,retrans=4           0    0

Após a montagem, o /home atual será substituído pelo /home remoto exportado via NFS. É interessante, antes desta montagem, mudar o /home para /home_local (lembrando de alterar em /etc/passwd o /home para /home_local dos usuários locais, caso houver).

(crédito)

Desempenho dos Tipos de Dispositivos de Rede

2015-08-31T20:11:00-03:00

Há pouco tempo atrás descobri um terrível gargalo que estava prejudicando o compartilhamento de arquivos com o NFS (Network File System). Trata-se da seleção do Modelo de Dispositivo de Rede a ser utilizado como Placa de Rede em uma VM. No KVM são apenas três opções possíveis: e1000, rtl8139 e virtio; sendo que a primeira opção, Hypervisor padrão, no caso do CEFALA é o virtio. Por não saber do problema, todas as VMs do CEFALA estavam utilizando o rtl8139 por ser um driver mais conhecido. Após perceber que esta configuração acarretava em uma perda em performance, decidi testar os demais modelos para verificar o desempenho de cada um deles.

Os testes utilizaram o iperf combinando os modelos de dispositivos de rede existentes em um enlace virtual: e1000 <-> e1000, rtl8131 <-> rtl8139 e virtio <-> virtio. O iperf foi executado por três vezes consecutivas e o melhor resultado para 10 segundos de transferência é apresentado abaixo:

e1000 <-> e1000

[ ID] Interval       Transfer     Bandwidth
[ 3]  0.0-10.0 sec  1.48 GBytes  1.27 Gbits/sec

rtl8131 <-> rtl8139

[ ID] Interval       Transfer     Bandwidth
[ 3]  0.0-10.0 sec   179 MBytes   150 Mbits/sec

virtio <-> virtio

[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  20.9 GBytes  18.0 Gbits/sec

Os testes deixam claro o desempenho do virtio em comparação com os demais. Obviamente todas as VMs passaram a utilizá-lo em substituição ao rtl8139. Como este post não tem o intuito de investigar o motivo da diferença, mas sim de expor a mesma, vou parando por aqui...

Acesso seguro (e prático) às VMs

2015-08-09T11:31:00-03:00

Como já foi divulgado por aqui, o controle do acesso às Vms do CEFALA está centralizado no servidor LDAP, que se encontra instalado na VM nfs. A senha de login de cada usuário é única para todas as VMs e está armazenada na base LDAP.

Existem duas maneiras de modificar a senha:

Faça um login em nfs.cefala.org e use o comando passwd. Note que é possível rodar o comando passwd nas outras VMs, mas a modificação não é propagada à base LDAP e, na verdade, não serve para nada.
Visite a interface phpLDAPadmin da VM nfs na URL https://nfs.cefala.org/phpldapadmin/. Clique en login na barra da esquerda e preencha o campo Login DN com cn=Rafael Laboissière,dc=cefala,dc=org (usando o seu nome ao invés do meu) e o campo Password com a sua senha LDAP.

Obviamente, estes dois métodos só funcionam se você já possuir uma senha válida na base LDAP e se você se lembrar dela. Caso contrário, você terá que pedir ajuda a um dos administradores da base LDAP (Arlindo e este seu humilde servidor, no momento).

O login por SSH às VMs utiliza, por default, a autenticação Unix clássica usando a senha LDAP. Entretanto, a maneira mais prática e mais segura de se autentificar nas VMs do CEFALA é através de pares de chave SSH. Ela é segura porque evita o envio de senhas através da Internet. Ok, ok, eu sei que as conexões via SSH são encriptadas, mas deixem-me cultivar a minha paranoia de segurança. Além disto, a conexão por par de chaves SSH introduz um obstáculo a mais aos piratas da Net pois, além da senha, elas terão que se apoderar também da chave privada que, normalmente, nunca sai do seu notebook ou computador pessoal.

Quando ao aspecto da praticidade, o uso de pares de chave SSH permite conexões transparentes sem a necessidade de fornecimento da senha a cada transação (scp, git pull/push, etc.).

A coisa funciona da seguinte maneira. Inicialmente, crie um par de chaves no seu sistema pessoal, usando o comando ssh-keygen. Este comando proporá a criação da chave privada em ~/.ssh/id_rsa. Você poderá mudar este nome, o que te permite criar tantos pares de chaves quanto você quiser. Eis um exemplo de criação de pares de chave:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/rafael/.ssh/id_rsa): /home/rafael/.ssh/id_rsa.cefala
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/rafael/.ssh/id_rsa.cefala.
Your public key has been saved in /home/rafael/.ssh/id_rsa.cefala.pub.
The key fingerprint is:
b4:37:bd:e8:e8:64:f2:4c:0a:1b:59:09:d0:ef:af:04 rafael@edge
The key's randomart image is:
+---[RSA 2048]----+
|  ..             |
|   ..            |
|    ..  .        |
|     ..o . .     |
|    E.o S o .    |
|     +.  . o .   |
|    + o.+ . .    |
|     = O.o       |
|    . oo= .      |
+-----------------+

Note que, no exemplo acima, eu criei chaves com nomes ~/.ssh/id_rsa.cefala (a chave privada) e ~/.ssh/id_rsa.cefala.pub (a chave pública). A primeira é preciosa e não deve nunca sair do seu sistema pessoal. A segunda é feita para ser divulgada a Zeus e o mundo. Note, também, que é possível criar a chave sem senha. Entretanto, se você fizer isto, eu desço aí em Belo Horizonte para bater em você com vara de marmelo.

O próximo passo consiste na transferência da chave pública ao CEFALA, o que é feito da seguinte forma:

ssh-copy-id -i ~/.ssh/id_rsa.cefala.pub rlaboiss@xxx.cefala.org

substituindo rlaboiss pelo seu nome de login e xxx pelo nome de qualquer uma das VMs do CEFALA (dev, git, nfs, sci ou www). Este comando simplesmente adiciona a sua chave pública como uma linha do arquivo remoto ~/.ssh/authorized_keys. Como a partição /home/ é compartilhada por todas as VMs, basta rodar uma só vez o comando ssh-copy-id acima.

Em seguida, para simplificar as coisas e evitar o uso da opção -i a cada comando ssh, coloque o seguinte no arquivo .ssh/config do seu computador pessoal:

Host *.cefala.org
  User rlaboiss
  IdentityFile ~/.ssh/id_rsa.cefala

Lembre-se de usar o seu nome de login no lugar de rlaboiss.

Se você estiver usando um desktop moderno, como o GNOME3, por exemplo, que roda sob ssh-agent, você só precisará fornecer uma única vez a senha do seu par de chaves SSH, aquele que você usou no comando ssh-keygen (e espero que você tenha realmente usado uma senha, para o bem do seu lombo!). A partir daí, todas as conexões SSH ou Git nas VMs do CEFALA serão feitas sem necessidade de fornecimento da senha.

Update: No parágrafo acima, eu dou a entender que o ssh-agent só pode ser usado em sessões de desktop como o GNOME, por exemplo. Entretanto, existe uma maneira muito simples de rodá-lo dentro de uma sessão de shell. Neste caso basta fazer isto aqui:

$ eval $(ssh-agent)
$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/rlaboiss/.ssh/id_rsa:
Identity added: /home/rlaboiss/.ssh/id_rsa (/home/rlaboiss/.ssh/id_rsa)

Você pode usar qualquer chave SSH como argumento do comando ssh-add, sendo o valor por default ~/.ssh/id_rsa. Após a execução destes comandos, as conexões via sss/scp não pedirão senha, contanto que a chave pública (no exemplo acima .ssh/id_rsa.pub) esteja estocada no arquivo .ssh/authorized_keys do servidor acessado. Vide explicação mais acima neste post.

Criando e configurando novas VMs do CEFALA

2015-06-15T13:13:00-03:00

Neste artigo, as etapas para a criação e a configuração de máquinas virtuais (VMs) do CEFALA sào descritas. O processo não é complicado, mas exige a realização de uma sequência de ações manuais, dificilmente automatizáveis. Como vocês verão abaixo, eu tentei automatizar ao máximo a configuração dos clientes NSS, LDAP e NFS. Vamos então ao que interessa.

Preliminares

Antes de se criar uma nova VM, é necessário que um IP seja reservado para ela no servidor DNS do CEFALA. Digamos que a VM a ser criada é a xyz. Assim que seu IP estiver atribuído, podemos conhecê-lo através do seguinte comando:

$ host xyz.cefala.org

O arquivo de configuração KVM da VM deverá também ser criada. Não entrarei em detalhes deste processo no presente artigo. Normalmente, após a sua criação, o arquivo de configuração aparecerá como /etc/libvirt/qemu/CEFALA-XYZ.xml ou algo do gênero.

Algo importante para o bom funcionamento da VM é a criação da interface de rede br3. Se ela ainda não existir, é possível fazê-lo no virt-manager. Para tanto, clique no ícone “Show virtual hardware details” e em seguida no botão “Add Hardware”. Crie uma interface de rede com esta configuração:

Network source: Specify shared device name
Bridge name: br3
Device model: rtl8139

Instalação do sistema operacional

Antes de iniciar a instalação do sistema operacional, é necessário indicar o arquivo ISO contendo o netinst da Debian. Se isto não tiver ainda sido feito, lance o virt-manager e configure o “IDE CDROM 1”, apontando o seu “Source path” para o arquivo ISO /var/lib/libvirt/images/debian-testing-amd64-netinst.iso ou aquele que for apropriado. É também importante colocar “IDE CDROM 1” no topo da lista “Boot Options”. Em seguida, basta ligar a VM e o instalador da Debian será lançado.

Dizem por aí que até uma galinha é capaz de instalar um sistema Debian, pois basta ficar bicando na tecla “Enter”. No nosso caso, teremos que ter um cérebro ligeiramente superior ao de uma galinha, pois teclas diferentes da “Enter” terão que ser usadas. Em particular, a etapa “Configuring the network with DHCP” não funcionará (pois não existe servidor DHCP para as VMs) e teremos que escolher a opção “Configure network manually” e fornecer os dados abaixo, manualmente:

address: 150.164.32.XX
netmask: 255.255.255.0
gateway: 150.164.32.254
nameserver: 150.164.32.32

O XX do address IP é aquele que o DNS do CEFALA nos fornece. Na sequência da configuração rede, escolhemos o nome da máquina adequado (xyz no nosso exemplo) e usamos o “domain name” cefala.org.

O programa de instalação da Debian exige a criação de um usuário além do root. Escolha um nome de login qualquer para ele. Este usuário deverá ser suprimido mais tarde, pois as contas dos usuário serão compartilhadas via LDAP.

Configuração da VM

Como descrito por Arlindo em um outro artigo, as VMs do CEFALA compartilham o diretório /home através do NFS, cujo servidor é a VM nfs.cefala.org. O protocolo NFS passa pela bridge br3, definida no hospedeiro kvm.cefala.org. Deste modo, será necessário criar na nova VM uma nova interface de rede (a eth1) com o IP apropriado.

Além disto, a administração das contas dos usuários é centralizada na VM nfs.cefala.org, via LDAP. É necessário, assim, instalar e configurar os pacotes Debian com os clientes NSS e LDAP.

No intuito de automatizar ao máximo as ações descritas acima, eu criei um Makefile e alguns arquivos de configuração que estão atualmente sob w controle Git. Aqueles que têm acesso aos repositórios cefala-admin (via par de chaves SSH) poderão obter os arquivos desta maneira:

$ git clone cefala-admin@git.cefala.org:cefala-vm-conf.git

O comando acima não funcionará na VM que acabou de ser criada, pois a partição /home ainda não está disponível. Ora, é para isto mesmo que precisamos dos arquivos! Podemos contornar este problema do ovo e da galinha com os seguintes comandos (utilize a console do virt-manager, fazendo o login como root):

# scp -r rlaboiss@git.cefala.org:/var/git/cefala-admin/cefala-vm-conf.git .
# aptitude install git
# git clone cefala-vm-conf.git
# aptitude remove git

Obviamente, você terá que substituir o rlaboiss acima pelo seu nome de login na base LDAP. Em seguida, instale os pacotes libnss-ldapd e nfs-common:

# aptitude install libnss-ldapd nfs-common

Aceite todos os valores propostos como default no debconf. Eles serão modificados no passo seguinte, que é este abaixo:

# cd cefala-vm-conf
# aptitude install make
# make IP=85 HOSTNAME=xyz
# aptitude remove make

A especificação das variáveis IP e HOSTNAME é obrigatória. A variável IP corresponde ao último número do IP na bridge br3. Atualmente, nós temos as seguintes definições:

172.16.10.1 nfs.cefala.org
172.16.10.2 git.cefala.org
172.16.10.3 www.cefala.org
172.16.10.4 dev.cefala.org
172.16.10.5 sci.cefala.org

Et voilà! A nova VM está pronta para utilização. Para ter certeza que tudo está funcionando, faça um teste de conexão à partir de uma outra máquina, com o comando:

$ ssh xyz.cefala.org

Nota: os comandos para remover os pacotes git e make não são obrigatórios, mas garantem que as VMs permaneçam limpas.

Update: Desde o commit 528e67f, não é mais necessário especificar as variáveis IP e HOSTNAME no lançamento do commando make.

Migração dos repositórios Git

2015-06-06T12:32:00-03:00

Os repositórios Git que se encontravam na VM www foram todos transferidos para a VM git. Este mudança é praticamente transparente para os usuários, mas as URLs indicando os repositórios centralizados devem ser atualizadas. Para tanto, vá até o seu repositório Git e edite a linha contendo url = do arquivo .git/config, trocando o cefala.org por git.cefala.org. Por exemplo, no repositório Git deste blog, a tal linha deve ficar assim:

url = cefala-admin@git.cefala.org:blog

Por sinal, a migração do repositório Git deste blog deu um pouco de trabalho, ligado à construção automática do site web a cada git push. Anteriormente, como o servidor HTTP e o repositório estavam na mesma VM, a www, tudo era simples. Na situação atual, o web site continua sendo construído pelo Pelican a cada git push. Entretanto, isto ocorre na VM git. É necessário, assim, transferir os arquivos produzidos para a VM www.

Uma solução que foi pensada inicialmente por Hani e por mim, seria o compartilhamento de um diretório entre as duas VMs. Esta solução é realmente simples de se implementar no contexto atual, onde as duas VMs, www e git, rodam no mesmo hospedeiro KVM. Na eventualidade de migração das VMs para máquinas diferentes, esta solução teria que ser adaptada, o que resultaria em mais trabalho no futuro.

A solução mais robusta que encontrei pelo momento foi o uso de um proxy no servidor HTTP da VM www. Para que isto funcione, a VM git tem também que rodar um servidor HTTP, fornecendo as páginas produzidas pelo Pelican ao compilar este blog. Isto é feito através de um script de init (/etc/init.d/admin-blog) que roda um SimpleHTTPServer a partir do diretório do site web do blog. Como o seu nome bem diz, o SimpleHTTPServer é servidor HTTP minimalista que é, na verdade, um módulo do Python. Isto evita a instalação e a configuração de um servidor HTTP completo, como o Apache, na VM git. Para matar um passarinho, basta um estilingue, não precisamos de um caça F-16. (Vixe, com essa eu cacei briga com a Sociedade Protetora dos Animais e com o IBAMA!)

Este servidor HTTP na VM git serve apenas as páginas do blog e fica na escuta de uma porta TCP específica, cujo número eu escolhi aleatoriamente. Assim, é possível acessar o blog nesta URL: http://git.cefala.org:8367/.

O próximo passo é a configuração do proxy na VM www. Isto foi feito graças ao arquivo /etc/apache/sites-available/admin-blog.conf, que contém as linhas:

<VirtualHost *:80>
    ServerName admin.cefala.org
    <Location /blog/ >
        ProxyPass http://git.cefala.org:8367/
        ProxyPassReverse http://git.cefala.org:8367/
    </Location>
</VirtualHost>

O servidor admin.cefala.org foi recentemente adicionado ao servidor DNS e aponta para www.cefala.org. Após instalação do arquivo acima na VM www, basta rodar an2ensite. A URL pública para acessar o blog é, assim, http://admin.cefala.org/blog/.

Para não perder o vício, eu coloquei tudo sobre controle GIt, tanto o scritp init da VM git quanto a configuração Apache da VM www, além de criar um Makefile para automatizar as tarefas. Isto tudo está no diretório webserver do repositório Git deste blog.

Aﬁnando o teste do VirtFS

2015-06-01T20:25:00-03:00

Arlindo escreveu um ótimo artigo sobre os testes comparativos de desempenho do NFS e do VirtFS. Isto gerou uma longa discussão na lista de difusão cefala-admin na semana passada. No frigir dos ovos, a escolha recaiu sobre o NFS, principalmente porque o desempenho do rsync com arquivo destino numa partição VirtFS foi catastrófico, por razões que desconhecemos. No presente artigo, estou documentando os aspectos metodológicos que levantei durante a tal discussão, caso a questão volte à pauta no futuro.

Performance/reliability/concurrency: Pick two

Nos testes feitos por Arlindo, a partição VirtFS foi montada com as opções por default. Entretanto, eu descobri que a opção de cache pode ter uma influência enorme no desempenho. Este é o resultado com a opção cache por default:

rlaboiss@NFS:~$ sudo umount /mnt/virtfs
rlaboiss@NFS:~$ sudo mount -t 9p /virtfs /mnt/virtfs -otrans=virtio,version=9p2000.L
rlaboiss@git:~$ dd if=/dev/zero of=/mnt/virtfs/test count=1000 bs=32k
1000+0 records in
1000+0 records out
32768000 bytes (33 MB) copied, 0.653058 s, 50.2 MB/s

Abaixo está o resultado do mesmo teste com a opção cache=loose, para o qual desempenho é multiplicado por 6.6:

rlaboiss@git:~$ sudo umount /mnt/virtfs/
rlaboiss@git:~$ sudo mount -t 9p /virtfs /mnt/virtfs -otrans=virtio,version=9p2000.L,cache=loose
rlaboiss@git:~$ dd if=/dev/zero of=/mnt/virtfs/test count=1000 bs=32k
1000+0 records in
1000+0 records out
32768000 bytes (33 MB) copied, 0.0980486 s, 334 MB/s

A ideia de testar variações do parâmetro de cache veio da documentação do v9fs do kernel Linux. O que é descrito neste documento me lembra o velho dilema dos estudantes, que almejam sempre ter:

boas notas
vida social
oito horas de sono por dia

Apenas dois destes objetivos podem ser alcançados simultaneamente. É como no VirtFS, em que você tem que escolher dois dentre os três objetivos:

desempenho
confiabilidade
concorrência

Com a opção “no cache” por default, perde-se o desempenho. Com cache=loose, perde-se a confiabilidade. Com cache=fscache, perde-se a concorrência. (Nota: o termo “concorrência” significa gestão de acesso simultâneo a um mesmo arquivo por dois processos diferentes.)

Em se tratando de `dd`, tamanho de bloco é documento

Vocês talvez tenham notado que eu utilizei a opção bs do comando dd nos meus testes acima. O desempenho do dd depende de maneira crítica do tamanho do bloco (512 bytes, por default). Além disso, existe, aparentemente, um tamanho ideal de bloco que depende do hardware do HD.

Eis aqui o teste realizado com o arquivo de destino na partição VirtFS, no qual pode-se observar a existência de um tamanho ótimo de bloco:

rlaboiss@git:~$ sudo umount /mnt/virtfs/
rlaboiss@git:~$ sudo mount -t 9p /virtfs /mnt/virtfs -otrans=virtio,version=9p2000.L,cache=loose
rlaboiss@NFS:~$ for bs in 1k 2k 4k 8k 16k 32k 64k 128k 256k 512k 1M 2M 4M 8M 16M; do
    speed=$(dd if=/dev/zero of=/mnt/virtfs/test count=10 bs=$bs 2>&1 | grep copied | cut -f3 -d, );
    printf "%5s %8s" $bs $speed;
    echo "";
done
   1k      6.0 MB/s
   2k     16.2 MB/s
   4k     53.7 MB/s
   8k     84.7 MB/s
  16k      178 MB/s
  32k      323 MB/s
  64k      540 MB/s
 128k      583 MB/s
 256k      936 MB/s
 512k      1.3 GB/s
   1M      1.6 GB/s
   2M      1.5 GB/s
   4M      2.2 GB/s
   8M      2.0 GB/s
  16M      590 MB/s

Como Arlindo comentou, é sempre interessante comparar os resultados obtidos no VirtFS com os resultados obtidos quando o arquivo destino está na própria imagem da VM. Ei-los:

rlaboiss@NFS:~$ for bs in 1k 2k 4k 8k 16k 32k 64k 128k 256k 512k 1M 2M 4M 8M 16M; do
    speed=$(dd if=/dev/zero of=/var/tmp/test count=10 bs=$bs 2>&1 | grep copied | cut -f3 -d, );
    printf "%5s %8s" $bs $speed;
    echo "";
done
   1k      116 MB/s
   2k     99.6 MB/s
   4k      161 MB/s
   8k      288 MB/s
  16k      457 MB/s
  32k      663 MB/s
  64k      832 MB/s
 128k      1.0 GB/s
 256k      1.1 GB/s
 512k      1.1 GB/s
   1M      927 MB/s
   2M      587 MB/s
   4M      401 MB/s
   8M      430 MB/s
  16M      340 MB/s

É interessante observar que o pico de desempenho do VirtFS acontece mais tarde (bs=4M) do que aquele do arquivo na imagem da VM (bs=256k). Entretanto, a velocidade de escritura máxima no VirtFS é o dobro daquela do disco da imagem VM (2.2 GB/s contra 1.1 GB/s, respectivamente)

Para terminar o registro, aqui vão os resultados com o arquivo de destino numa partição compartilhada via NFS:

rlaboiss@NFS:~$ for bs in 1k 2k 4k 8k 16k 32k 64k 128k 256k 512k 1M 2M 4M 8M 16M; do
    speed=$(dd if=/dev/zero of=/home/rlaboiss/test count=10 bs=$bs 2>&1 | grep copied | cut -f3 -d, );
    printf "%5s %8s" $bs $speed;
    echo "";
done
   1k      197 kB/s
   2k      533 kB/s
   4k      1.1 MB/s
   8k      1.3 MB/s
  16k      3.4 MB/s
  32k      4.7 MB/s
  64k      6.6 MB/s
 128k      8.4 MB/s
 256k      9.5 MB/s
 512k      9.5 MB/s
   1M     11.7 MB/s
   2M     13.8 MB/s
   4M     14.2 MB/s
   8M     16.2 MB/s
  16M     15.8 MB/s

Detalhes metodológicos

Os testes do Arlindo foram feitos na VM nfs. Os testes acima, foram feitos na git.cefala.org. Para isto, eu adicionei um hardware nesta VM, que aparece assim no arquivo /etc/libvirt/qemu/CEFALA-Git.xml:

<filesystem type='mount' accessmode='mapped'>
  <driver type='path'/>
  <source dir='/var/tmp/virtfs'/>
  <target dir='/virtfs'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</filesystem>

O diretório /var/tmp/virtfs aparece assim na kvm:

rlaboiss@CEFALA:~$ ls -ld /var/tmp/virtfs/
drwxrwxrwx 3 libvirt-qemu libvirt-qemu 4096 Jun  1 13:39 /var/tmp/virtfs/

Alﬁnetando o APT

2015-06-01T18:10:00-03:00

Debian é um sistema maneiro (se fosse usar gíria do meu tempo, eu diria “supimpa”). Entretanto, a distribuição stable é sempre velha de dois anos, mesmo quando ela acaba de nascer. Este conservadorismo, aliado à coerência entre zilhões de pacotes disponíveis, é que faz o sucesso da Debian. Por outro lado, é difícil ficar na crista da onda em termos de aplicativos.

É por isto que eu mantenho o APT da Debian do meu notebook sempre apontando para a distribuição testing. Obviamente, não é aconselhável seguir esta prática em servidores compartilhados, como as VMs do CEFALA. Felizmente, já encontraram uma maneira de contornar o problema: basta alfinetar o APT (APT pinning, em inglês).

Imagine que você esteja rodando a Debian amd64 stable atual (a.k.a. jessie), que tem o kernel Linux no pacote linux-image-3.16.0-4-amd64. Digamos que você deseja testar um kernel mais moderno, por exemplo a versão 4.0 do Linux. Uma solução seria fazer a atualização completa do sistema para a Debian unstable, no que só de pensar já dá preguiça. Outra solução seria espetar o APT com um alfinete, da seguinte forma:

Primeiro, informe o seu sistema da existência da Debian unstable, por exemplo, criando o arquivo /etc/apt/sources.list.d/debian-unstable.list com o seguinte conteúdo:

deb http://ftp.br.debian.org/debian/ unstable main contrib non-free
deb-src http://ftp.br.debian.org/debian/ unstable main contrib non-free

Em seguida, informe o APT quais são as suas preferências, por exemplo, criando o arquivo /etc/apt/preferences.d/debian-releases com o seguinte conteúdo:

Package: *
Pin: release a=stable
Pin-Priority: 650

Package: *
Pin: release a=unstable
Pin-Priority: 600

Os números que aparecem nas linhas Pin-Priority não têm relevância particular, mas o essencial é saber que o maior deles indica a distribuição preferida.

Em seguida, basta rodar:

$ sudo aptitude update
$ sudo aptitude install linux-image-4.0.0-1-amd64/unstable

e você terá o kernel Linux 4.0 rodando na sua máquina após o próximo reboot.

Como eu sou um cara supimpa (ou maneiro, se você preferir) eu criei um projetinho para automatizar os passos acima. Para variar, e por vício meu, ele está no Git do cefala-admin. Para aqueles que têm acesso via par de chaves SSH (veja as instruções que eu postei num outro artigo), basta fazer:

$ git clone cefala-admin@www.cefala.org:apt-debian-pinning

Em seguida, basta rodar sudo make para alfinetar o APT. O “programa” fará algumas perguntas, como no exemplo abaixo, mas basta teclar “Enter” para aceitar as opções por default. Leia a documentação no arquivo README.md, para maiores detalhes.

$ sudo make
Debian mirror [ftp.us.debian.org]: ftp.fr.debian.org
Priority order [stable testing unstable experimental]: testing unstable experimental
Installing preferences file...
Installing source files...
aptitude update
[...]

NFS ou 9p Virtio..., eis a questão

2015-05-25T10:25:00-03:00

Amigos, como solicitado em nossos inúmeros e-mails, crio agora este post acerca de minha saga com a utilização de 9p Virtio ou NFS (Network File System) para compartilhamento de pastas entre Hospedeiro (Host) e Hospedado (Guest). Este tipo de compartilhamento é muito útil e largamente utilizado (por mim) no VirtualBox, devido a sua praticidade. Entretanto, confesso nunca ter analisado afinco sua performance. Nas últimas semanas a necessidade de utilização de compartilhamento de pastas com alto desempenho surgiu, e junto esta necessidade os problemas.

Em todos os testes que se seguem, o Hospedeiro foi o servidor do CEFALA. A pasta a ser compartilhada do Hospedeiro para uma VM foi a /home/backup_users. O Sistema Operacional de ambos é o Debian 8. O comando utilizado para obter a performance de gravação foi dd if=/dev/zero of=test count=100000 && rm test, variações de configuração neste comando alteram a performance observada, no entanto o percentual entre o desempenho do Hospedeiro e da pasta montada no Hospedado segue o mesmo. Para a coleta de resultados o comando será executado por cinco vezes e o último resultado será considerado (vale lembrar que a diferença entre os cinco é mínima).

Para a configuração do 9p Virtio a referência oficial do KVM/QEMU foi seguida, sendo realizada a configuração via Virt-Manager. Os parâmetros para compartilhamento foram Driver: Default e Modo: Mapped. O modo Mapped foi escolhido por preservar as permissões dos arquivos na pasta compartilhada. Entretanto, no Hospedeiro, a pasta compartilhada deverá ter como do o usuário dono o mesmo usuário que executa a VM que a montará, no caso libvirt-qemu. A pasta compartilhada no Hospedeiro está sob uma partição RAID 5, que tem a performance abaixo:

root@CEFALA:/home# dd if=/dev/zero of=test count=100000 && rm test
100000+0 records in
100000+0 records out
51200000 bytes (51 MB) copied, 0.196585 s, 260 MB/s

Na VM CEFALA-NFS, utilizada para os testes, a performance de acesso da em seu próprio sistema de arquivos (root) foi a seguinte:

root@NFS:/# dd if=/dev/zero of=test count=100000 && rm test
100000+0 registros de entrada
100000+0 registros de saída
51200000 bytes (51 MB) copiados, 0,190469 s, 269 MB/s

pode-se dizer que é igual a performance do sistema de arquivos onde encontra-se o arquivo imagem desta VM. Entretanto, ao montar na VM a pasta /home/backup_users compartilhada do Hospedeiro, a performance do 9p Virtio não segue o desempenho observado nos testes anteriores:

root@NFS:/mnt/backup_users# dd if=/dev/zero of=test count=100000 && rm test
100000+0 registros de entrada
100000+0 registros de saída
51200000 bytes (51 MB) copiados, 8,01939 s, 6,4 MB/s

Foram utilizadas diversas formas de montagem da pasta compartilhada, como por exemplo mount -t 9p -o trans=virtio,version=9p2000.L, que é uma orientação do manual oficial KVM/QEMU. Em todos os testes a performance se manteve a mesma.

Um teste comparativo foi realizado com o VirtualBox, neste a máquina utilizada foi um Laptop (laptop pessoal). O sistema de arquivos onde a imagem da VM Ubuntu está alocada tem o seguinte desempenho:

lopan@lopan:~# dd if=/dev/zero of=test count=100000 && rm test
100000+0 registros de entrada
100000+0 registros de saída
51200000 bytes (51 MB) copiados, 0,155031 s, 330 MB/s

na VM que foi executada pelo VirtualBox, seu sistema de arquivos tem um desempenho inferior ao observado no Hospedeiro, comportamento que não ocorre no KVM/QEMU:

root@lopan:/# dd if=/dev/zero of=test count=100000 && rm test
100000+0 registros de entrada
100000+0 registros de saída
51200000 bytes (51 MB) copiados, 0,379748 s, 135 MB/s

ainda que inferior em relação ao desempenho do Hospedeiro, trata-se de um desempenho razoável. No entanto, ao utilizar o mecanismo de compartilhamento de pasta do VirtualBox o desempenho do compartilhamento de pasta é parecido com o do KVM/QEMU, ridiculamente baixo:

root@lopan:/media/sf_tmp# dd if=/dev/zero of=test count=100000 && rm test
100000+0 registros de entrada
100000+0 registros de saída
51200000 bytes (51 MB) copiados, 9,26114 s, 5,5 MB/s

Diferentemente daquilo que foi visto em VirtFS - A virtualization aware File System pass-through, o desempenho observado com o NFS é muito maior que o 9p Virtio. No teste com o NFS a configuração do servidor obedeceu o indicado pelo Debian NFS Server Setup, e a montagem da partição foi configurada da seguinte forma (em /etc/fstab): 172.16.10.254:/mnt/backup/PPGEEMaster /mnt/backup nfs rw,async,nfsvers=3,rsize=65536,wsize=65536,timeo=5,retrans=4 0 0, sendo observado o seguinte desempenho:

root@ppgeemaster:/mnt/backup# dd if=/dev/zero of=test count=100000 && rm test
100000+0 registros de entrada
100000+0 registros de saída
51200000 bytes (51 MB) copiados, 0,263266 s, 194 MB/s

Meus amigos do CEFALA, os testes que foram executados podem e devem conter falhas! Do contrário não seria possível uma afirmação como a do artigo VirtFS - A virtualization aware File System pass-through. Apesar do desempenho do VirtualBox e KVM/QEMU serem parecidos, não creio que o KVM/QEMU deveria ficar tão abaixo do NFS (Network File System), visto as afirmações do artigo. Este post deve ser complementado à medida em que: (i) encontrarmos o problema e nivelarmos o desempenho em conformidade com o exposto no artigo; (ii) confirmar a baixa performance através de testes conclusivos, contradizendo assim o artigo.

Todas as configurações iniciais utilizadas foram sob orientações de manuais oficiais do Debian, KVM, entre outros. Pesquisas em fóruns foram realizadas e testes com diversas configurações e linhas de execução do comando mount foram utilizadas, em nada alterou o desempenho em relação ao percentual comparado entre os sistemas de arquivo de Hospedeiro e Hospedado.

Update (por Rafael): Excelente artigo, Arlindo. Eu escrevi alguns comentários sobre os testes acima em um outro artigo.

Servidor NFS (National Foundation for Security)

2015-05-21T19:15:00-03:00

Em uma das reuniões de um projeto no qual eu e Hani participamos, um coreano visitante mencionou que é preciso uma catástrofe para que algo possa ser reconstruído da forma correta. Confesso que a declaração do coreano me marcou muito, e a cada dia eu vejo que isso é verdade. Tudo bem que ele fez menção à guerras, insinuando talvez que o Brasil só “tomará jeito” quando algo do tipo acontecer. Enfim, parece que isso se aplica também a tecnologia, pois nos últimos meses o PPGEE e CEFALA foram assombrados por problemas envolvendo RAID e ambos estão sendo reerguidos de forma estável e estruturados para crescer.

Esta contribuição tem o intuito de documentar parte do que está sendo feito no servidor do CEFALA, mais especificamente ao novo servidor de compartilhamento de arquivos e autenticação. Atualmente, o servidor físico do CEFALA (KVM ou Hospedeiro, chamem como quiser) tem SSH e Libvirt instalados. O acesso à este servidor ficará restrito aos administradores do Libvirt, demais usuários do CEFALA terão acesso apenas aos serviços providos através de Máquinas Virtuais. Neste momento irei focar no servidor CEFALA-NFS (National Foundation for Security) o qual será responsável por compartilhar o /home e a base de dados para autenticação via LDAP (Lightweight Directory Access Protocol).

No hospedeiro, que deve ser entendido como o servidor físico do CEFALA, foi configurado um volume em RAID 1 que totaliza 1.8TB e que será de uso exclusivo para o /home. O volume foi adicionado à VM CEFALA-NFS de forma transparente, ou seja, a VM consegue acesso direto ao /dev/md3 do hospedeiro. Isso foi possível com a seguinte inserção no arquivo /etc/libvirt/qemu/CEFALA-NFS.xml:

<disk type='block' device='disk'>
  <driver name='qemu' type='raw'/>
  <source dev='/dev/md3'/>
  <target dev='hdc' bus='virtio'/>
</disk>

Ainda é cedo para afirmar a performance e estabilidade da forma de acesso utilizada. No entanto, caso a VM apresente alguma instabilidade, uma alternativa seria exportar o NFS diretamente do hospedeiro ou compartilhar o diretório do hospedeiro no qual o RAID 1 está montado. Se leu até aqui, faça agora um minuto de oração para que tudo funcione adequadamente!

Seguindo adiante, após a implementação do RAID 1 dentro da VM, que foi montado como /home e teve todos os dados do antigo servidor copiados via rsync, o próximo passo é compartilhá-lo com outras VMs. Deu-se início então ao processo de instalação do LDAP, necessário para que as permissões do /home e a autenticação dos usuários sejam possíveis. O processo de instalação do LDAP seguiu à risca os manuais do próprio Debian, tanto para instalação do Servidor quando para o Uso do LDAP. Não é necessário entrar em detalhes sobre a configuração do LDAP, visto que com o uso da documentação citada não houve imprevistos, o LDAP foi posto em funcionamento em poucos minutos tanto no Servidor quando no Cliente.

Para facilitar a administração da base LDAP, a aplicação phpLDAPadmin foi instalada. A interface pode ser acessada através do endereço http://nfs.cefala.org/phpldapadmin, que funcionará unicamente com HTTPS. O usuário administrador da base é cn=admin,dc=cefala,dc=org e a senha será compartilhada posteriormente com os administradores. Será neste ambiente que novos usuários deverão ser criados, farei isso com todos os usuários que existiam no servidor antigo e após isso o acesso ao hospedeiro será cancelado, permanecendo apenas os usuários hani, rlaboiss e lopan, com contas Unix, para administração do KVM/QEMU.

Com o LDAP funcionando, agora é a vez do NFS-Server (Network File System) para exportará o /home para outras VMs. A instalação do NFS-Server seguiu as orientações do Debian, disponível na página NFS Server Setup. Exportação da pasta /home foi configurada no /etc/exports:

/home        172.16.10.*(rw,no_root_squash,subtree_check)

Mais uma vez não houve imprevistos com a documentação do Debian, o NFS-Server foi tranquilamente instalado e testado, em outra VM, com o comando mount 172.16.10.1:/home /mnt/home. O único problema diagnosticado nesta etapa, mas que não é falha da documentação utilizada, foi a respeito de portas abertas para o mundo, ouvindo no endereço 0.0.0.0. Para resolver este problema de forma definitiva, optei pela implementação de um Firewall simples, a ser carregado no /etc/rc.local, que tem o intuito de preservar acesso externo apenas para ICMP, SSH, HTTP e HTTPS:

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -P INPUT DROP

Se a paciência (ou curiosidade) foi tamanha para chegar até aqui, provavelmente estará se perguntando: que rede é essa no NFS-Server (172.16.10.*)? A resposta tem ligação com o Firewall anterior. Seria ingenuidade colocar um NFS-Server com acesso via porta WAN ou LAN, e em nosso caso é até desnecessário! Em um ambiente como o nosso é possível criar uma Rede Virtualizada. Cria-se uma Bridge no Hospedeiro que interconectará todas as Interfaces Virtuais das VMs que a utilizarem. Ficou confuso? Então vamos a uma explicação mais detalhada...

A rede 172.16.10.0/24 foi reservada para comunicação exclusivamente entre VMs, não sendo possível acesso via WAN ou LAN. Neste sentido foi criado a bridge br3 no hospedeiro, sem adição de endereço IP pois nem este terá acesso à rede 172.16.10.0/24. As VMs que desejarem acesso aos serviços LDAP, NFS, ou simplesmente uma conexão fora da rede pública (WAN ou LAN), devem inserir uma Interface de Rede na br3, que irá se comportar analogamente como um switche. A VM CEFALA-NFS, objetivo deste post, está configurada com o Endereço IP 172.16.10.1 na br3. Outras VMs deverão ser configuradas como 172.16.10.{2, 3, 4, ..., 254}.

Como o hospedeiro conta com um RAID 5, além do RAID 1 utilizado exclusivamente para o /home, este será utilizado para backup. A VM CEFALA-NFS será agendada para diariamente (semanalmente ou mensalmente, a definir) fazer o backup do /home no RAID 5 do hospedeiro. Os usuários dos serviços providos pelo CEFALA-NFS terão acesso ao /home somente através deste servidor, ficando o /home backup acessível apenas pelos administradores.

Chega ao fim a implementação do Servidor NFS (National Foundation for Security), sendo necessário em seus clientes (VMs) apenas três passos:

Configuração de uma Interface Virtual na br3 com IP na rede 172.16.10.0/24;
Instalação do LDAP cliente;
Configuração do NFS no /etc/fstab para montagem automática do /home.

Update: (por Rafael Laboissière) Este é o comando, a ser rodado na VM kvm.cefala.org, para restaurar um diretório /home/$user a partir do backup diário:

rsync -av /mnt/sdc1/backup_users/$user nfs.cefala.org:/home/$user

Porque prefiro o sudo

2015-05-15T11:41:00-03:00

Os servidores *.cefala.org são administrados por várias pessoas. Todas elas devem ter, em princípio, acesso à conta root nos diferentes sistemas. A maneira mais simples de se lidar com esta situação é de divulgar a senha do root a todos os colaboradores. Ou prefiro usar o sudo, pelas razões que exponho abaixo.

Primeiramente, senha não é coisa que se compartilhe, apesar do fato de que formamos uma confraria de paz e amor.

(crédito)

Quando mais de duas pessoas compartilham um segredo, é provável que, mais cedo ou mais tarde, ele seja publicado no Estado de Minas.

Em segundo lugar, utilizar sudo é uma boa porque fica sempre registrado no arquivo /var/log/auth.log quem fez o quê e quando.

Vida fácil com git-scripts

2015-05-14T12:34:00-03:00

Git é legal, é bacana, mas impõe também uma certa dose de trabalho ao administrador dos repositórios centralizados. Bom, antes de continuar com o assunto deste artigo, deixe-me somente esclarecer que o conceito de “repositório centralizado” não existe em Git, per se. Todo e qualquer repositório, seja ele “bare” ou “working” (veja os detalhes neste post), é apenas um repositório a mais na rede de repositórios associados a um projeto. Somos nós, seres humanos, que impomos as regras e declaramos: “Este aqui é o repositório central. O resto é firula!”

Pois bem, voltando ao assunto, o administrador do sistema onde os repositórios ditos centralizados serão instalados deve executar uma certa quantidade de tarefas, de maneira a manter a ordem mundial. No setup que foi escolhido para a atual VM webserver (e para a futura VM git.cefala.org), um dado repositório será acessado pelos diversos contribuidores através da conta de um único usuário não-humano do sistema. Não confunda não-humano com desumano. Este tal usuário te tratará muito bem, contanto que o administrador do sistema faça a sua parte.

E o assunto carga de trabalho do coitado do administrador volta à tona. Primeiro, ele tem que criar a conta daquele usuário não-humano, levando-se em conta tudo o que a sua não-humanidade exige, como proibir login, apagar eventuais senhas, etc. Em seguida, o nosso pobre administrador tem que criar os repositórios nos lugares certos e com as boas permissões. como exige a boa etiqueta do mundo Unix. Enfim, deve-se também garantir que este usuário não-humano se comunicará polidamente com os usuários mais humanos que compartilharão os repositórios.

Está confuso? .ique tranquilo, eu também fiquei, no início. Após matutar bastante, a maneira mais simples que encontrei para o compartilhamento de repositórios centrais foi através de autentificação por pares de chave SSH. Neste caso as chaves públicas RSA dos contribuidores deverão ser instaladas na conta do usuário não-humano que detém o repositório centralizado. Veja um exemplo de uso em um outro artigo que escrevi.

De modo a simplificar a vida do administrador do servidor git, eu criei uma série de scripts, que coloquei, obviamente, sob controle Git:

$ git clone cefala-admin@git.cefala.org:git-scripts

(N.B.: Você não precisa rodar o comando acima para poder usar os scripts da maneira descrita abaixo na VM git.cefala.org. Rode o git clone acima somente se você estiver curioso para saber como eu escrevi os scripts, ou se você encontrou algum bug e deseja corrigi-lo.)

No momento, existem quatro scripts disponíveis. O primeiro deles permite a criação do tal usuário não-humano:

# add-git-user usuario

Note que este comando deve ser rodado como root ou através do sudo. A conta do usuário será criada, com diretório home /var/git/usuario/, com login shell /usr/bin/git-shell, com senha desabilitada e com números UID et GID maiores que 2000. Esta última medida é necessária para evitar os conflitos futuros, quando as informações das contas dos usuários dos servidores CEFALA serão centralizadas, usando NSS+LDAP ou o que quer que seja.

Em seguida, existe um script para criar o repositório centralizado:

# add-git-repo usuario repositorio.git

O repositório será criado em /var/git/usuario/repositorio.git/. Um outro script permite a instalação das chaves RSA autorizadas:

# add-authorized-keys usuario id_rsa.pub

O arquivo id_rsa.pub é aquele obtido através do comando ssh-keygen e enviado pelo contribuidor. Enfim, o script git_multimail.py também foi incluído no projeto. Este script pode ser utilizado no hook post-receive do repositório centralizado para o envio de notificações automáticas de git push.

Para instalar os scripts no $PATH do sistema, basta rodar make de dentro do repositório clonado git-scripts. Como diria maravilhosamente o Dadá, a vida do administrador agora virou mamão com açúcar.

Update: O script add-authorized-keys aceita agora a opção -r, que força o acesso read-only para a chave sendo adicionada. Neste caso, a pessoa que é proprietária da chave SSH só pode executar os comandos git clone, git pull e git fetch, sendo o git push interditado.

Libere o seu avatar

2015-05-11T05:57:00-03:00

Gostou do meu avatar aí ao lado? .ocê também pode ter o seu avatar estampado neste blog, como todo narcisista que se preze. Para isto, basta fazer três coisas:

se inscrever no Libravatar, deixando lá a sua foto 3×4 (ou melhor, 80×80 px),
redigir um artigo para este blog, e
preencher o campo Email: no cabeçalho do dito artigo com o endereço mail que você usou para criar a conta no Libravatar.

Se você tem conta no Gravatar, vai funcionar também, contanto que você utilize o endereço mail adequado. Se você não tiver conta nem no Libravatar e nem no Gravatar, azar seu. A sua cara ficará deste jeito.

Algum engraçadinho vai perguntar: “Se o treco funciona com Gravatar e se a maioria das pessoas já têm conta lá, porque você me vem com esta estória de Libravatar? Mas vocês gostam de complicar uma coisa simples, hein?”

Eu respondo com uma pergunta: Qual é a diferença entre os dois? E já dou a resposta: um termina com .org e o outro com .com. Precisa dizer mais?

Libere o revolucionário que mora no fundo do seu ser!

Reescrevendo a história

2015-05-09T19:42:00-03:00

Git é uma excelente ferramenta para o trabalho cooperativo. Ele pode fazer muitas coisas, mas é incapaz de resolver conflitos entre as pessoas. Afinal de contas, o Git é apenas um programa de computador e, enquanto não chega o dia da Strong AI, teremos que resolver os conflitos apenas entre nós, reles seres humanos.

A que tipo de conflito estou me referindo? .ão estou falando de nada muito sério, como o que aconteceu aqui na Europa há 70 anos, mas apenas de situações que ocorrem quando dois colaboradores estão trabalhando concomitantemente em um projeto sob controle Git. Cada um faz modificações e commits do seu lado, partindo do mesmo ponto da história. Um deles é mais esperto e faz o git push primeiro. Quando o outro chega para fazer o seu push, o repositório remoto reclama, dizendo que há novidades e o obriga a fazer um pull, seguido de um merge. Aí, o outro fica com uma história assim:

2015-05-09 06:22 Hani Camille Yehia M─┐ Merge branch 'master' of www.cefala.org:blog
2015-05-09 11:16 Rafael Laboissiere │ o Use the correct name for the git-multimail command
2015-05-09 06:20 Hani Camille Yehia o │ Include command to define 'ci' as an alias to 'commit' in article 'o-git-me-manda-noticias'
2015-05-09 06:10 Hani Camille Yehia o─┘ Add Hani's email address to the push notification mailing list

(Abrindo parêntese rapidinho, o que está mostrado acima é uma cópia das linhas do Tig. Trata-se de uma interface totalmente textual para visualizar a história do Git, sem aqueles frufrus todos das interfaces tipo Click-O-Rama. Fecha parêntese.)

Bom, a história ficou feia de com força, por causa daquele commit “Merge branch etc.”. Felizmente, o Git, como nos bons tempos do Stalinismo e do KGB, é capaz de reescrever a história e evitar que você passe constrangimento ao fazer o git push. Normalmente, o fluxo de trabalho com Git deve ser o seguinte:

$ git pull
$ editor some-file
$ git pull
$ git add some-file
$ git commit -m "Changed some file"
$ git push
Great, thanks for your contribution!

Note que eu coloquei duas vezes git pull acima. O primeiro, você faz antes de introduzir as suas modificações. Entretanto, estas modificações podem durar horas ou dias. É por isto que recomendo o segundo git pull. De qualquer maneira, a sequência pull/add/commit/push deve ser feita rapidamente.

Agora, problemas acontecem quando você deixa de fazer o git pull na hora certa. Aí, pode dar nisto:

$ editor some-file
$ git add some-file
$ git commit -m "Changed some file"
$ git push
You, moron, do a git pull first!
$ git pull
Ha!  I will force you to do an ugly merge!
$ git push

Quando isto ocorrer, chame o super git rebase e ele virá ao seu socorro. Santa rebaseada, Batman! Logo após o git pull, lance os comandos seguintes e a história voltará a ser linear, como se nada tivesse acontecido, não é mesmo, Vladimir?

$ git rebase remotes/origin/master master
$ git push

Uma outra maneira de evitar todo e qualquer problema é o uso sistemático da opção --rebase do command git pull.

P.S.: Por falar em reescrever a história, a Rússia festejou hoje o armistício da Segunda Guerra Mundial, com toda pompa militar de uma ex-URSS. Eles gostam de ser diferentes do resto do mundo, que festejou o armistício ontem, no dia 8 de maio. Muito se falou por aqui na Europa, nestes últimos dias, da tomada do Reichstag em Berlim pelo Exército Vermelho. Aí eu me lembrei daquela famosa foto do hasteamento da bandeira soviética. Notem que a foto, que foi toda preparada pela propaganda soviética, teve que ser retocada antes da publicação, pois aparecia nela um soldado com relógios nos dois pulsos, prova da pilhagem constrangedora de guerra. No bom estilo Git (o retoque, é claro, não a pilhagem!).

Ô Git, me manda notícias!

2015-05-08T23:26:00-03:00

O repositório Git centralizado, onde o controle de versão deste blog é feito, foi recentemente modificado para permitir a notificação automática de push, utilizando o script git_multimail.py. A lista de endereços mails para os quais os avisos são enviados fica no arquivo config do repositório centralizado.

“Bacana”, você vai me dizer, “mas como eu faço para incluir o meu endereço mail nesta lista? .ou ter que me logar na VM webserver e fazê-lo manualmente?” Sim, esta seria uma opção, mas como nós já estamos usando o Git para administrar o blog, eu fiz o necessário para automatizar o processo… via Git! .amos lá, então, para a receita de bolo do dia.

Se você ainda não tiver clonado o repositório, faça-o seguindo as instruções no meu artigo precedente. Se você já havia clonado há mais tempo, é sempre bom dar uma pullada (isto evita fusões desnecessárias e arborecências de commit tortuosas):

$ git pull

Em seguida, edite o arquivo que define a lista de difusão, comite-o e pushe a modificação:

$ editor git-hooks/mailing-list
$ git add git-hooks/mailing-list
$ git commit -m "Add my email address to the push notification mailing list"
$ git push

Se o código que eu escrevi funcionar corretamente, então você deverá receber doravante os mails de notificação, a começar pelo seu push acima. Nestes mails, as modificações feitas nos arquivos fonte deste blog aparecerão de forma detalhada.

Blogar é viver

2015-05-08T11:43:00-03:00

Como dizia o outro, recordar é viver. Este blog foi criado para manter a memória de que tem sido feito em termos de administração dos servidores do CEFALA. O motor que o move é o Pelican. A escolha do sistema obedeceu aos seguintes critérios (impostos por mim, é claro!):

geração de website estático,
escrito em Python,
moderno e bem mantido,
artigos escritos em MarkDown e
fácil integração com Git.

A utilização é maldita de tão simples (“damn simple”):

$ git clone cefala-admin@www.cefala.org:blog
$ cd blog/website
$ editor content/meu-artigo-fantastico.md
$ git add content/meu-artigo-fantastico.md
$ git commit -m "Add my fantastic article"
$ git push

Após o git push final, o site é inteiramente reconstruído no servidor www. Como visto acima, A criação dos artigos pode ser feita inteiramente em um terminal, sem cliques de mouse, sem abrir navegadores web e, o supra sumo da perfeição, sem rodar PHP no servidor!

Bom, para ser sincero, a utilização não é tão simples assim (mas também não é tão maldita assim). Para começo de conversa, o comando git clone acima só funcionará se a sua chave pública SSH RSA estiver instalada na conta do "usuário" cefala-admin. A conta deste “usuário” não-humano no servidor www.cefala.org não permite login e está limitada a aceitar apenas os comandos do Git.

Este setup foi escolhido por várias razões. Em primeiro lugar, ele evita a criação de contas de usuários na www que terão acesso ao repositório Git centralizado. A manutenção deste repositório também fica mais simples, sem a necessidade de criação de um grupo Unix para controlar o acesso. Em segundo lugar, o acesso via chave SSH, além de ser mais seguro, é mais prático para os usuários. Cada usuário poderá ter quantas chaves quiser, uma para cada sistema do qual ele (ou ela) acessa o servidor www. Além disto, se ela (ou ele) estiver usando o ssh-agent, então, após a primeira conexão, não se precisará mais de entrar a senha da chave RSA para operações futuras (dentro de uma mesma sessão do ssh-agent, evidentemente).

Bom, para aqueles que se esqueceram, gerar uma chave RSA pública é mais fácil do que torcer pelo próprio time:

$ ssh-keygen

Em seguida, envie-me o arquivo ~/.ssh/id_rsa.pub, para que eu (ou a pessoa que esteja administrando este blog) o adicione ao arquivo /var/git/cefala-admin/.ssh/authorized_keys do usuário cefala-admin da VM git.cefala.org. No futuro, seria interessante elaborar uma maneira de automatizar esta tarefa mas, por enquanto, vai na mão mesmo.

Nas instruções que coloquei acima, a pessoa contribuindo neste blog tem apenas que criar um novo artigo escrito em Markdown no diretório content/, comitá-lo no Git e fazer o git push. Obviamente, é interessante verificar localmente como ficará o site, antes de exportá-lo. Para tanto, comece por instalar o pacote necessário no seu sistema:

$ sudo aptitude install python-pelican

Em seguida, após editar e salvar o seu novo artigo, vá para o diretório website (de onde você vê um outro arquivo Makefile e o diretório content/) e rode os comandos seguintes:

$ make html
$ make serve

Aí, basta apontar o seu navegador para http://localhost:8000 e verificar se o trabalho ficou bem feito. Se você achar que o mundo merece ler o que você escreveu, então prossiga com o git commit e o git push.

Update: Você pode pedir para o repositório centralizado te avisar quando um push ocorrer nele. Para tanto, basta seguir as instruções.

Update: Na Debian, o pacote python-markdwon é uma dependência do pacote python-pelican. Em outras distribuições, como a Gentoo, você terá que instalar o módulo Markdown do Python manualmente. Isto ainda não é tudo para poder construir localmente o website. O nosso blog precisa de alguns plugins extras do Pelican, que são instalados como sub-módulos Git. Para simplificar a tarefa, eu criei um arquivo Makefile, que fica no diretório raiz do projeto. Logo após fazer o clone, faça isto aqui:

$ cd blog
$ make

Na verdade, ao invés do git pull, será sempre melhor lançar o comando make como acima.

Trazendo a VM webserver de volta à vida

2015-05-07T23:00:00-03:00

Ao fim do mês de abril de 2015, o volume RAID do servidor cefala2 começou a falhar e, de maneira esporádica e imprevisível, o sistema se tornava “read-only”. Nesta mesma época, eu decidi, de maneira impensada obviamente, fazer a atualização do sistema Debian da wheezy para a jessie, apesar das nuvens negras que apareciam naquele não tão belo horizonte.

Não deu outra. Durante a atualização do sistema via aptitude dist-upgrade, o volume RAID falhou de novo e o sistema ficou num estado de morte cerebral. Como bem diz o Hani, o ponto nevrálgico do sistema foi atingido, pois a atualização do GRUB ficou pelo meio do caminho.

Em 1º de maio, dia em que tive muito trabalho com o sistema, desci às profundezas do inferno (i.e. mount em loop device), dominei o Cérbero (i.e. chroot), negociei com o Hades (i.e. GRUB) e trouxe de volta ao mundo dos vivos o servidor webserver. Segue abaixo o relato passo à passo da minha Odisseia, durante a qual vesti o manto de root no arcano mundo do cefala2.

A imagem da VM será montada como um dispositivo loop e ficará disponível como um disco do sistema. Para tanto, devemos obter o primeiro dispositivo loop do sistema que esteja livre:

# LOOPDEV=$(sudo losetup -f | sed s:/dev/::)

No meu caso, foi:

# echo $LOOPDEV
loop0

Em seguida, associei a imagem da VM a este dispositivo loop (ATENÇÃO: a VM tem que estar completamente desligada neste momento, ou seja, shutoff):

# losetup /dev/$LOOPDEV /home/images_kvm/WinImages/CEFALA_VMs/CEFALAServer.img

Usei o kpartx para criar os dispositivos neste disco virtual:

# kpartx -av /dev/$LOOPDEV
add map loop0p1 (253:0): 0 58591232 linear /dev/loop0 2048
add map loop0p2 (253:1): 0 15624192 linear /dev/loop0 58593280
add map loop0p3 (253:2): 0 97656832 linear /dev/loop0 74217472
add map loop0p4 (253:3): 0 876699648 linear /dev/loop0 171874304

Verifiquei que as partições foram criadas corretamente:

# ls -alF /dev/mapper
total 0
drwxr-xr-x  2 root root     140 Mai  1 03:36 ./
drwxr-xr-x 16 root root    3880 Mai  1 03:36 ../
crw------T  1 root root 10, 236 Abr 30 10:34 control
lrwxrwxrwx  1 root root       7 Mai  1 03:36 loop0p1 -> ../dm-0
lrwxrwxrwx  1 root root       7 Mai  1 03:36 loop0p2 -> ../dm-1
lrwxrwxrwx  1 root root       7 Mai  1 03:36 loop0p3 -> ../dm-2
lrwxrwxrwx  1 root root       7 Mai  1 03:36 loop0p4 -> ../dm-3

Em seguida, criei um ponto de montagem no sistema:

# mkdir -p /mnt/vm

Aí, já pude montar as partições (na verdade, eu tive que fazer uns testes antes para descobrir onde estavam as partições /, /home e /var, além da partição de swap):

# mount /dev/mapper/${LOOPDEV}p1 /mnt/vm
# mount /dev/mapper/${LOOPDEV}p3 /mnt/vm/home
# mount /dev/mapper/${LOOPDEV}p4 /mnt/vm/var

Para que o chroot funcione corretamente mais tarde, é preciso também montar os sistemas de arquivos udev, proc e sysfs do kernel no futuro ponto raiz de chroot:

# mount --bind /proc /mnt/vm/proc
# mount --bind /sys /mnt/vm/sys
# mount --bind /dev /mnt/vm/dev

Neste ponto, estamos prontos para lançar o chroot e entrar, virtualmente, na máquina VM webserver:

# chroot /mnt/vm

À partir daí, usei o dpkg --configure -a e o aptitude para consertar o sistema. O problema de boot da webserver vinha do pacote GRUB, cuja atualização tinha sido interrompida brutalmente pelo apagão em Terra Brasilis. O problema foi corrigido ao reinstalar o MBR (master boot record) na imagem da VM, o que foi feito desta maneira:

# echo "(hd0) /dev/loop0" > /boot/grub/device.map
# grub-install /dev/loop0
# update-grub
# rm -f /boot/grub/device.map
# exit

Depois disto, de volta ao cefala2, desfiz as montagens das partições e liberei o dispositivo loop:

# umount /mnt/vm/dev
# umount /mnt/vm/sys
# umount /mnt/vm/proc
# umount /mnt/vm/var
# umount /mnt/vm/home
# umount /mnt/vm
# kpartx -d /dev/$LOOPDEV
# losetup -d /dev/$LOOPDEV

A partir daí, basta ressuscitar a VM moribunda, apertando no botão “Run” do virt-manager ou através de virsh start CEFALAServer.

Update [2025-08-19]: No texto acima não está indicado em qual sistema se encontram as imagens da VM. Atualmente, elas se encontram no servidor kvm.cefala.org e estão presentes no diretório /var/lib/libvirt/images/ (e não /home/images_kvm/WinImages/, como escrito acima).