Causos

A senha perdida

O ano era algum entre 1995 e 1998. Mais próximo do primeiro, eu suponho. Estava trabalhando na Humana, como Analista de Sistemas. Feliz, recém formado em Ciência da Computação, de posse do meu primeiro fusquinha, e absolutamente entusiasmado com um curso de "desenvolvedor de aplicações Oracle" que eu havia feito em Recife.

Ali aprendi, entre outras coisas, que o Oracle faz tudo o que, na academia, se dizia que os Bancos de Dados deveriam fazer.

Ato imediato, comecei a usar todas instalações Oracle a que eu tinha acesso como cobaias de experiências um tanto "macabras". Uma das cobaias, por infelicidade, acabaria sendo a instalação Oracle que mantinha no ar o sistema hospitalar de um dos maiores hospitais da Paraíba, e naquela época o principal hospital de crianças de Campina Grande: CLIPSI.

As experiências eram variadas: desde a implementação de procedimentos recursivos usando a linguagem PL/SQL até a reorganização forçada dos dados por reindexação dos clusters, passando por processos paralelos que forçavam um estado de deadlock, que era para ver se o "bichinho" escapava mesmo das armadilhas.

Importante reiterar: o Oracle passou com louvor em todos os testes.

Um deles, porém, não acabou muito bem. Pelo menos para mim.

No Hospital, onde eu havia ido providenciar alguma atualização do sistema, eu fiquei "de castigo" esperando o chefe, para que ele verificasse e atestasse a corretude do que eu havia feito.

Isso não me assustava. Sabia que estava tudo em ordem. Mas ocorreu que, com o tempo de sobra e a "cobaia" Oracle ao lado, a hora me pareceu bem propícia para experiências.

Percebi que a senha do usuário de administrador do sistema não havia sido alterada. No Oracle, que segue o padrão SQL ANSI, o usuário administrador se chama "system" e a senha, por default é "manager".

Não é um esmero de criatividade, deve-se reconhecer.

Conectei como "system" e, para verificar se tinha mesmo os "poderes do administrador", criei um usuário chamado "degas".

Ainda testando se os poderes de "system" eram mesmo equivalentes aos divinos naquele ambiente, digitei "grant DBA to degas". Em tese havia concedido permissão de administrador, as mesmas permissões divinas de "system", para o usuário "degas".

Mas ainda havia a hipótese de que nada daquilo estivesse implementado de fato. Como testar?

Conectei como "degas" e, para verificar se aquele usuário realmente tinha a permissão de administrador, executei um comando para alterar a senha do usuário "system".

Que foi executado à perfeição. Pronto. Tese comprovada.

Saí do usuário "degas" e fechei o aplicativo.

E aí ocorreu-me uma pequena dúvida: qual havia sido a nova senha do usuário "system"?

Mais assustadora, uma segunda pergunta me ocorreu: qual havia mesmo sido a senha do usuário "degas"?

Sentindo o sangue fugir-me do corpo percebi, em uma fração de segundo, o tamanho da obra que eu tinha feito: sem a senha de "system", e sem a senha de "degas", os dois únicos usuários com permissão de administrar o Banco de Dados, aquilo lá se tornava um dragão indomado e sem controle. O Banco de Dados havia se tornado uma caixa inacessível. Dentro dela todos os dados e grande parte das aplicações do hospital inteiro.

Pela primeira vez na vida eu tive certeza de que perderia o emprego.

Não aconteceu, felizmente.

O Núcleo

Esta história também aconteceu enquanto eu trabalhava na Humana. Naqueles tempos, uma parte da receita da empresa vinha da prestação de serviços de processamento de dados a alguns hospitais.

Explico: a facilidade de se possuir computadores, redes, bancos de dados e aplicações corporativas nos anos 90 não eram particularmente atrativas. Uma alternativa que muitas empresas buscavam (e ainda hoje buscam) era contratar uma empresa para prover tais serviços. Em Campina Grande muitos hospitais usavam a Humana Assessoria e Sistemas para isso.

Havia uma instalação Oracle em rede SCO-Unix que era usada para dar suporte aos hospitais. Eram vários. A humana mantinha um time de digitadores que entravam com dados de AIH (Autorização de Internação Hospitalar) e gerava os relatórios que os hospitais enviavam ao SUS e aos planos de saúde, a fim de efetuar seus faturamentos.

Algumas vezes acontecia de o disco estar cheio, ou quase cheio. O Oracle implementa um algoritmo de alocação progressiva de arquivos de extensão para os tablespaces, de forma que as áreas para alocação de dados estejam previamente disponíveis. Quando o sistema conclui que não haverá disco disponível para a ampliação do espaço, ele interrompe a geração de novas transações. O Banco de Dados, então, pára. Num estado consistente, mas pára.

Aconteceu naquele dia. Era uma sexta-feira. De tarde.

Eu e mais dois colegas, Alvinho e Stênio, estávamos na Humana. Coube a mim a tarefa de arrumar espaço em disco para que o SGBD pudesse continuar operando. Era um pouco urgente, já que os hospitais dependiam daquilo para enviar seus relatórios no prazo.

O servidor do SCO-Unix dispunha de uma interface em que se chaveava entre vários terminais (o ambiente não era gráfico naqueles tempos) e eu fui abrindo diferentes terminais para procurar, em diferentes pontos do sistema de arquivos, algo que pudesse ser removido. Em um dos terminais, para acessar a raiz do disco, eu me conectei como root.

Aí as coisas começaram a dar errado.

Correndo contra o relógio, chaveando entre os terminais, já nem mais sabendo que usuário estava logado em cada um, encontrei um arquivo enorme (para os padrões da época) de 5Mb. Seu nome? unix.

Sem pensar em nada exceto no tempo, que estava cada vez mais curto, digitei: rm unix. O arquivo foi removido. O Oracle, com toda certeza, poderia operar neste espaço de 5Mb.

Mas as coisas sempre podem ser melhoradas. Assim, em seguida, vendo que havia um outro arquivo do mesmo tamanho, chamado unix.old, achei por bem removê-lo também.

Pronto. Agora, com 10Mb livres no sistema de arquivos, o Oracle continuou operando, os hospitais receberam seus relatórios e todos fomos felizes para o merecido descanso de final de semana.

Até que na segunda, ao chegar no trabalho, comecei a perceber que algo estava errado. Ao pisar na empresa, relataram-me que o servidor Unix simplesmente não entrava mais no ar. Conseguíamos dar boot com disquete. Mas não era possível montar o sistema de arquivos, e iniciar o sistema.

Aí eu lembrei, enquanto perdia o fôlego, do arquivo que havia removido.

Era simplesmente o núcleo, ou kernel, do Sistema Operacional.

Corri até a UFCG em busca de socorro e dialoguei com o professor Walfredo Cirne.

"Cara, apaguei um arquivo chamado unix no SCO. E agora?"

"Degas! Aquilo é o núcleo do Sistema Operacional!" respondeu Walfredo, uma informação que eu, desesperadamente, já tinha. E em seguida completou: "Mas fique tranquilo. Ele tem um backup. Mova o arquivo unix.old para unix que o sistema volta para o ar".

Incrédulo, lembrei-me que unix.old era o segundo arquivo que eu removera.

Naquele momento eu tive, pela segunda vez em minha vida, a certeza de que estava no olho da rua.

E, pela segunda vez, isso não aconteceu. Felizmente.