atualizações sobre o problema de infra-estrutura no projeto fedora

Aparentemente, parece mesmo que foi um problema de segurança (estou especulando, ainda). Por ter sido divulgada uma nova chave SSH no final do email do Paul Frields, imagino que tenha sido algo relacionado a isso. Na íntegra:

Our team has been hard at work for several days now, restoring services
in the Fedora infrastructure. We started with what we identified as
Fedora’s “critical path,” those systems required to restore minimum
daily operation. That work to be completely finished by the end of the
day. We then move on to our other value services to complete them as
soon as possible.

Please give the infrastructure team the time they need to do this
demanding work. They have been doing a spectacular job and deserve the
absolute highest credit.

The systems that are now back online and usable include the following:
* Puppet, Xen and FAS hosts
* app1, app3, and app4
* database and proxy servers
* the majority of the Xen guest machines
* serverbeach5, serverbeach4
* Fedora Hosted**

The systems that should be available very soon:
* asterisk1 and collab1
* cvs1
* builders, x86 and ppc
* Fedora People

We know the community is awaiting more detail on the past week’s
activities and their causes. We’re preparing a timeline and details and
will make them available in the near future. We appreciate the
community’s patience, and will continue to post updates to the
fedora-announce-list as soon as possible.

= = =
** New SSH fingerprint for Fedora Hosted:
e6:b3:68:51:98:2d:4c:dc:63:27:46:65:51:d5:f0:7a


Paul W. Frields, Fedora Project Leader
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://paul.frields.org/ – – http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

Espero que tenhamos mais notícias em breve, e que o anúncio seja tão claro como foi o do Debian anos atrás, lembram? 🙂

Migração de Debian para Fedora

Fedora

A história

A partir de domingo, 10/08/2008 estou usando Fedora. Sim, Fedora. Sempre fui um apoiador de software livre, e durante esses vários anos utilizei as distribuições principais da seguinte maneira:

  • 1996: Yggdrasil, primeiro contato com Linux, através da Interdata, onde foi praticamente meu primeiro emprego.
  • 1997 ~ 2000: Slackware, onde realmente aprendi o que era usar Linux e demais ferramentas GNU. Nesse intervalo de tempo, também testei diversas outras distribuições, como SuSE, RedHat. FreeBSD, OpenBSD também foram testados. IRC, efnet, security geek. Madrugadas e madrugadas aprendendo. Tempo bom!
  • 2000 ~ 2002: Debian, achei que o Slackware andava meio parado, e meu tempo também já não era como antes (faculdade, etc). O Debian é uma ótima distribuição que se encaixou nas minhas necessidades na época.
  • 2002 ~ 2003: Gentoo, pois queria ter o controle total dos pacotes, ~x86 na época era demais com um AthlonXP (que tenho até hoje!), ver todas aquelas linhas de compilação! Ficava feliz com a fato do OpenOffice compilar depois de várias horas.
  • 2003 ~ 2005: Debian, o tempo novamente. Como não sobrava muito, digamos que retornei ao meu “Porto Seguro”.
  • 2005 ~ 2007: Ubuntu, nesse momento, eu achava que precisava contribuir com o software livre, já que o utilizava bastante e não ajudava com muita coisa. Já tinha dado treinamentos, participado de InstallFests, etc, mas precisava ser algo maior. Comecei então a trabalhar no projeto Ubuntu Brasil, com os meus amigos Rodrigo Belém, Mario Meyer e Lício Fonseca. Estávamos progredindo, mas novamente o tempo (neste caso por família, filho, esposa!) , me impediu de trabalhar mais ativamente, e infelizmente outras pessoas que eu mesmo apoiei no início resolveram “queimar meu filme” (nenhum dos que citei anteriormente). Então, o empenho de contribuição desapareceu.
  • 2007 ~ 10/08/2008: Debian/Ubuntu, sempre usando os dois, Debian no MacBook e Ubuntu no Desktops (trabalho e casa).

Os motivos

  • Surpresa: no mês de julho, eu e alguns amigos resolvemos atualizar nosso servidor dedicado, e eis que então surge a possibilidade de usar o CentOS. Até então, eu já tinha ouvido falar de tal distribuição baseada no RHEL, mas nunca tinha tido vontade de experimentar. Depois de alguns dias administrando o servidor, gostei muito da ferramenta yum (que me lembrou bem do apt), feita em python e C, e também da estabilidade do servidor.
  • Segurança: o Fedora possui um grande comprometimento ao quesito segurança. Firewall habilitado por padrão, PIE, SSP, SELinux, … Tudo bem, alguns podem dizer que não são as melhores proteções… mas, lembrem-se que “o ótimo é inimigo do bom” (como diria o Jaime!), e esses esforços não podem ser desconsiderados.
  • Aparência: ninguém pode negar que o conjunto de artes do Fedora é bem elaborado. O sítio é bem organizado e chamativo. O boot loader também tem um cuidado especial, o que é um atrativo para novos usuários. Pensei até em usar o LinuxMint, mas não sei qual o será o tempo de vida da distribuição.
  • “Corporatividade”: as distribuições mais usadas em empresas hoje são RHEL e SuSE. Ambas, usam RPM. Ambas, tem uma distribuição “comunitária”, Fedora e openSUSE. Ou seja, algumas das ferramentas disponíveis nestas últimas, acabam sendo migradas para as distribuições corporativas. E isso não deve ser desconsiderado.
  • Novidade: é sempre bom experimentar algo novo. O sistema init é diferente (event), pm-utils, selinux, e por aí vai. Junto com a mudança sempre vem um empenho e vontade de aprender.

A conclusão

Até agora tenho gostado do Fedora. Já não uso mais o FC9 estável, e sim o testing. Ainda não tive oportunidade, mas vou acabar migrando para a variação de desenvolvimento, Rawhide, mantendo a similaridade que tinha com o Debian sid.

Vale a pena? Não consido afirmar ainda, mas não me arrependi. Pouco a pouco vou conhecendo mais detalhes do Fedora, e em último caso posso formatar tudo e reinstalar a distribuição que quiser (nada como um /home separado!).

Problemas no FC9? Encontrei alguns, sempre existem. Tais como os da imagem abaixo. Entrei em contato com o desenvolvedor do PackageKit, Richard, e soluções para eles já foram providenciadas.

Mas então Fedora é melhor que o Debian? Não, claro que não. É mais uma questão de gosto e de funcionalidades que cada um procura e precisa.

SystemTap no Ubuntu 7.04

Um dos utilitários mais interessantes que conheci recentemente, enquanto estava lendo um Redbook da IBM sobre Perfomance Tuning de Linux em ambientes System p, é o SystemTap.

Do sítio principal, o SystemTap pode ser descrito como: “Uma ferramenta que fornece uma infra-estrutura baseada em software livre (GPL) para simplificar a obtenção de informações sobre um sistema Linux em execução” (tradução literal).

Graças aos desenvolvedores (Debian/Ubuntu), o pacote está disponível na seção universe/devel e pode ser instalado com um simples apt-get:

$ sudo apt-get install systemtap
Lendo Lista de Pacotes... Pronto
Construindo Árvore de Dependências
Lendo informação de estado... Pronto
Os pacotes extra a seguir serão instalados:
  libelf1 libpfm3-3.2
Os NOVOS pacotes a seguir serão instalados:
  libelf1 libpfm3-3.2 systemtap
0 pacotes atualizados, 3 pacotes novos instalados, 0 a serem removidos e 22 não atualizados.
É preciso fazer o download de 739kB de arquivos.
Depois de desempacotamento, 2683kB adicionais de espaço em disco serão usados.
Quer continuar [S/n] ? S
[...]
Instalando systemtap (0.0.20070113-1) ...
$

Aqui no meu sistema, foi necessário instalar outros dois pacotes, libelf1 e libpfm3, que são para manipular arquivos ELF, e bibliotecas para suporte a PMU (Performance Monitor Unit), respectivamente.

Após a instalação, é interessante verificar o diretório de documentação do software (em /usr/share/doc/NOMEDOPACOTE), pois geralmente traz exemplos bem interessantes. No caso do SystemTap, eu realizei o seguinte:

$ cd /usr/share/doc/systemtap/examples
$ sudo ./top.stp
semantic error: libdwfl failure (dwfl_linux_kernel_report_offline): No such file or directory while
resolving probe point kernel.function("sys_*")
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.

Humm, estranho. Usando o nosso amigo Google, descobri que existe o Bug #106957, que faz sentido pois o SystemTap precisa de informações de depuração para prover as informações do ambiente, que estão presentes nos pacotes linux-image-debug-VERSAO-DO-KERNEL. Além disso, é necessário criar um link simbólico para o nome de arquivo que o SystemTap tenta acessar:

$ sudo apt-get install linux-image-debug-$(uname -r)
Password:
Lendo Lista de Pacotes... Pronto
Construindo Árvore de Dependências
Lendo informação de estado... Pronto
Os NOVOS pacotes a seguir serão instalados:
  linux-image-debug-2.6.20-16-generic
0 pacotes atualizados, 1 pacotes novos instalados, 0 a serem removidos e 22 não atualizados.
É preciso fazer o download de 0B/24,2MB de arquivos.
Depois de desempacotamento, 59,9MB adicionais de espaço em disco serão usados.
Selecionando pacote previamente não selecionado linux-image-debug-2.6.20-16-generic.
(Lendo banco de dados ... 138496 arquivos e diretórios atualmente instalados.)
Descompactando linux-image-debug-2.6.20-16-generic (de .../linux-image-debug-2.6.20-16-generic_2.6
.20-16.29_i386.deb) ...
Instalando linux-image-debug-2.6.20-16-generic (2.6.20-16.29) ...
$ sudo ln -sf /boot/vmlinux-dbg-$(uname -r) /boot/vmlinux-$(uname -r)
$ sudo ./top.stp
SYSCALL                         COUNT
sys_gettimeofday                65187
sys_ioctl                       54202
sys_poll                        11467
sys_read                         3790
sys_gettid                       2471
sys_write                        1110
sys_kill                          803
sys_time                          673
sys_select                        597
sys_futex                         442
sys_clock_gettime                 248
sys_fcntl64                       207
sys_setitimer                     196
sys_socketcall                    183
sys_rt_sigprocmask                176
sys_writev                        150
sys_close                         103
sys_sigreturn                      99
sys_recvfrom                       97
sys_recv                           91
--------------------------------------

No exemplo acima, o SystemTap lista as 20 chamadas de sistema que estão sendo mais utilizadas. O aplicativo não se resume apenas a isso, o propósito principal dele é ajudar a identificar possíveis gargalos no sistema, seja de CPU, I/O, memória ou rede. Vale a pena!