Out of the box

UPDATE 2009.09.06: Parallels Tools is fully working on Ubuntu 9.04 since 2009.09.01, according to this article.

Today I wrote some RTTI (Run-Time Type Information) tests. After compiling it with Apple’s gcc on Mac, I decided to check how this would go with GNU’s gcc on Linux.
I ran my virtual machine, Ubuntu 9.04 (Jaunty), installed on Parallels Desktop 4.0 (for Mac), and tried to copy’n'paste my source code. I noticed it didn’t work, then I figured out Parallels Tools was missing. At this point, I tried to install it, without success. Checking the generated log at /var/log/parallels-tools-install.log, I found the following messages:

Installation of kernel modules was finished successfully
Start installation of user space modules
X Server: xorg, v1.5.0
Install X modules from directory: .1.6
System X modules are placed in /usr/lib/xorg/modules
Error: there is no X modules for this version of X server
Error: failed to install user space applications and drivers

In short, it says the Parallels Tools couldn’t find the necessary modules for Xorg 1.6.0. So I went to the Parallels website and searched for it. Without success again.
What I found instead, was a forum thread relating this exact problem, started in Apr 17, 2009. I read all the pages quickly, and got surprised it isn’t fixed until now. Let’s count… Aug 22 (today) – Apr 17 = ~4 months.
In addition, there’s a KB article about Parallels Desktop 4 and Ubuntu 9.04 support, showing the last review date as Jul, 22 2009.
But when it’s going to be fixed? No timeline, and no progress updates. Concluding, no idea!
Those customers are very frustrated/disappointed, and many are migrating to VMware Fusion or VirtualBox, declaring it isn’t the first time this kind of problem happens.

A temporary fix would be downgrading Xorg to a prior version, but it is totally unacceptable for me.

UPDATE 2010.10.01: Updated the frameworks to the latest versions.
UPDATE 2010.06.20: Created a personal repository to keep track of new changes.
UPDATE 2009.08.20: Completed the redirection support for ipfw, but I’m not having enough free time lately, so I shared my work. The patch was accepted, but it requires some work to complete the support.

I packaged two parts of MiniUPnP into distinct frameworks, so developers can embed in their .app’s. MiniUPnPc is a client implementation of the Internet Gateway Device Protocol. libnatpmp is a client implementation of the NAT Port Mapping Protocol (part of the Bonjour Protocol).

You can download them here. Both frameworks are universal (PPC, x86, x86-64).

Additionally, ipfw isn’t supported by MiniUPnPd, the server implementation, so I’ll work on it during my spare time. Please, let me know if you are interested on it too.

Recentemente decidi publicar alguns documentos, artigos, códigos, etc, que eu havia feito há muito tempo. Não se assustem com o conteúdo e versões, pois estão “um pouco” desatualizados, mas o conceito permanece.

Escrevi o artigo abaixo em 25 de março de 2006. Naquela data, o LKST estava na versão 1.01.

Linux Kernel State Tracer (LKST)

1. Propósito

Ambientes computacionais de grande porte necessitam alguns tópicos indiscutíveis, levando-se em conta a viabilidade, alguns deles são:
a) Segurança
b) Alta disponibilidade
c) Hardware redundante
d) Resposta imediata à incidentes

Devido à grande evolução do hardware, e do próprio kernel, muitos deixam de analisar a viabilidade de utilizar Linux adequadamente em seus sistemas. Para eles não é fácil fazer isto devido a grande evolução do hardware, tão bem acompanhada pelo kernel.
O LKST foi desenvolvido não só para prover informações confiáveis aos programadores que precisam uma forma eficaz e rápida de depurar problemas no sistema, mas também para disponibilizar informações de depuração quando o sistema operacional travar. Isto melhorará a qualidade do sistema fazendo com que as correções do kernel estejam disponíveis mais rapidamente, acompanhando a velocidade da evolução do hardware. Um programador de kernel que deseja descobrir as causas fundamentais dos problemas no sistema, precisa de um log de estados de transição do kernel. Logo, recorrendo a este log, poderá localizar o que aconteceu antes da paralização do sistema. Um log de eventos bem como interrupções de hardware, ajudará a solucionar o problema causado pelo hardware ou pelo software. E tais logs tornarão isso possível para engenheiros de sistemas que conhecem pouco ou quase nada do kernel do Linux. Porém, as únicas operações disponíveis quando o sistema trava, são simples dumps* de memória, que deveriam ser pequenos. Além disso, essas informações deveriam ser coletadas pelo próprio sistema quando uma falha ocorresse enquanto o sistema estivesse rodando em algum cliente. Estes logs, sendo pequenos, seriam aceitáveis para os sistemas de clientes, e o trabalho poderia ser feito pelo kernel do Linux.

2. Conceito de design

a) Obtendo informações detalhadas sobre falhas do kernel:

O LKST grava não somente stack-traces* e valores dos registradores do processador, mas também as transições de estado mais importantes do kernel, modificações de variáveis importantes, e eventos de hardware.
E além de registrar esses eventos, registra informações relacionadas a eles.

b) Recuperar logs de apoio até mesmo quando o sistema operacional entra em loop infinito:

Os logs que o LKST grava deveriam ser pequenos o bastante para que eles possam ser simplesmente recobrados por um dump* de memória. O LKST também deveria prover meios de exportar logs, incluindo porta serial.

c) Minimizar o log, mesmo em sistemas multi-processados:

Já que o LKST será utilizado em sistemas de clientes, deveria requerer poucos recursos e também evitar locks em sistemas multi-processados.

d) Suportar triggers extensíveis ao usuário para permitir coletar erros e monitoramento:

As Informações coletadas podem diferir de sistema para sistema. Os usuários podem precisar de dados que o LKST padrão não coleta, assim eles poderiam personalizar as chamadas de funções do LKST quando determinados eventos ocorrerem.

e) Conformidade com o padrão:

As informações do LKST deveriam ter conformidade com o POSIX Draft Standard (1003.25). E o mesmo deveria ser controlado por APIs conforme este padrão.

3. Projetos relacionados

Os projetos a seguir podem ser de valor aos interessados no LKST:

a) LTT – Linux Trace Toolkit
b) LKCD – Linux Kernel Crash Dump
c) Linux Event Logging for Enterprise-Class Systems
d) Kernel Tracer in IKD – Integrated Kernel Debugging Facilities

4. Referências

a) Linux Kernel State Tracer (LKST)
b) lkst-spec-1.01.pdf
c) TechnicalConference