stable_api_nonsense e distribuições enterprise-ready

Hoje tive a prova de que realmente não há sentido drivers de dispositivos serem mantidos externamente à árvore oficial do kernel. Se eles são mantidos fora, em minha opinião, só existem duas explicações :

  • O código não é limpo/correto o suficiente para ser aceito na árvore oficial

Já havia passado por muita raiva anteriormente utilizando módulos de kernel mantidos externamente, mas a política de atualizações de segurança do Debian sempre me ajudou muito nisso, porque mesmo com uma mudança de ABI em novos pacotes de kernel, regerar módulos de kernel empacotados no Debian é trivial e eu tinha a garantia de que a mudança na ABI foi necessária para corrigir uma falha de segurança real e não para acrescentar backports de funcionalidades novas suspeitas mascaradas como atualizações de segurança.

Mas hoje tive de lidar com outra distribuição que não segue essa política e me convenci que não ter o código para dar suporte a qualquer tipo de hardware que seja incluso na árvore oficial do kernel só gera dor de cabeça. O cenário : dois servidores, cada qual com 8 processadores e 8GB de memória, acessando um IBM TotalStorage DS4300 via fibra. O módulo que usamos para ter suporte um pouco melhor a failover das fibras é código mantido fora da árvore oficial do kernel (são dois, na verdade, mas isso é outra história).

Atualizações de segurança do kernel “oficiais” (ou seja, pacotes lançados pelo distribuidor oficial) instaladas, código do módulo externo recompilado, initrds regerados, servidores reiniciados e tudo aparentemente funcional. Percebeu o “aparentemente” ? O diabo está nos detalhes : o failover das fibras simplesmente parou de funcionar, congelando os servidores quando qualquer uma das fibras era removida e reinserida.

Depois de muita dor de cabeça para entender qual era o problema descobrimos que uma nova versão do código que implementa o módulo de kernel para controle de failover foi lançada. A nova versão corrigiu o problema, que foi “introduzido” pela nova versão do kernel.

Regras para se ter em mente quando lidando com distribuições enterprise-ready e código que deveria estar no kernel mas por algum motivo inexplicável não está :

  • Seja relaxado em relação a segurança e fique vulnerável por algum tempo, esperando os desenvolvedores de seu módulo externo atualizarem o código em questão antes de aplicar as atualizações de kernel que são marcadas como críticas pelo distribuidor do seu sistema operacional.
  • Distribuições “enterprise”, corretamente licenciadas, hardware e software homologados de nada adiantam quando a política de atualizações de “segurança” dessas distribuições introduzem código novo (e não somente correções de segurança) no meio de uma atualização de segurança.

Ah ! E porque raios as pessoas atualizam o código de seus drivers com base em versões de kernel de uma distribuição enterprise específica e não com base no kernel oficial ? Essas “parcerias” entre distribuidores de versões “enterprise” e grandes empresas de hardware/software me deixam furioso.

Por essas e outras que sempre bato a cabeça na parede quando ouço : “Tanto faz a distribuição, Linux é tudo a mesma coisa”. Hoje em dia isso é pura mentira. Todo o discurso de previsibilidade, de uma agenda e de uma grande empresa por trás vai por água abaixo quando vemos coisas como essas no dia-a-dia.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s