BUG do Behaviors impediu o GLPi de abrir chamdos em 2022

Neste post fazemos uma análise de baixo nível e relatamos o problema que atingiu um grande volume de usuários do nosso querido sistema de gestão de serviços GLPi. Ensinamos como contornar o erro que faz com que o GLPi não abra mais chamados após a virada de ano para 2022. Mas, a explicação será com um viés um pouco mais técnico.

Introdução

Para você que está aqui lendo este post, tenha um ótimo ano novo. Que 2022 venha repleto de oportunidades e que os desafios nos tornem cada vez melhores!

E foi exatamente assim que o ano começou para alguns amigos da comunidade. Desafios maiores.

Paciente ZERO

Já no dia 1º de Janeiro de 2022, um usuário no grupo do Telegram (https://t.me/glpibr – conecte-se conosco, somos mais de 2.600 pessoas) apresentou os primeiros sintomas do BUG de falha ao registrar novo ticket, foco deste post.

Como parecia ser um incidente isolado e estávamos realizando uma migração de novos Clientes para nossa infraestrutura, não tivemos como ajudar a solucionar o problema em questão, fazendo uma análise minuciosa da causa raiz.

Mas, já no dia 2 de janeiro, um de nossos clientes Verdanadesk contatou a Central de Serviços querendo agendar um suporte para segunda-feira (03/01/2022) cedo, alegando sintomas parecidos.

Então, foi constatado que o problema de nosso Cliente era (já sanado, claro) o mesmo que o amigo da comunidade.

Em pesquisas e conversas no grupo do telegram, foi visto que o impacto disso é relativamente grande, com vários relatos sobre o acontecido.

Foco na solução, depois no marketing

Incidentes devem ser solucionados o mais rápido possível…

ITIL®4 e ABNT NBR ISO/IEC20000-1:2020

Como não teríamos tempo de concluir este post ainda no dia 03 de janeiro devido a rotina de trabalho e sabendo que várias pessoas da comunidade continuariam sendo impactadas pelo problema, decidimos enviar um e-mail para todos que assinam nossa Caixa de Notícias, de forma que os mesmos possam retornar a disponibilidade de seus ambientes o mais rápido possível.

Este post então, é apenas um complementar do assunto para ajudar administradores do sistema GLPi a entender o que houve exatamente de errado, como contornar o problema e refletir sobre se terá ou não alguma forma viável de implantarem no projeto uma correção definitiva.

Sintomas

Os sintomas deste bug são relativamente simples e fáceis de se identificar.

Primeiro sintoma

O sintoma mais óbvio é que seu sistema GLPi para de abrir chamados após às 23h59min de Dezembro 2021.

Simplesmente assim. Não existem mais chamados abertos na base após a virada do ano. Seja por e-mail, seja por interface web, seja por API ou qualquer outro método.

Este erro nos remete ao velho e tão conhecido “Bug do Milênio”. E, de certa forma, existe muita similaridade entre eles.

Segundo sintoma

Este também fica fácil de identificar. Ao usar o plugin formcreator para registro do chamado, é exibida a seguinte mensagem na tela do usuário final:

Terceiro Sintoma

Outro sintoma também experimentado é que os chamados abertos por e-mail param de funcionar devido a incapacidade do sistema de lhes atribuir novos números de registros.

Quarto sintoma

Este é mais chato. Ele é o típico erro que tira o sono de qualquer administrador de sistema. Ele ocorre na abertura do chamado usando a interface padrão. A tela é processada e recarregada sem qualquer informação. E o chamado simplesmente não é criado. Ou seja, você fica sem entender nada.

É um sintoma “perigoso”. Dizemos isso pois, outros erros no sistema podem apresentar comportamentos idêntico a este.

Solução de contorno ao erro

Caso você esteja passando por este problema, a solução é relativamente simples:

Passo 1 – Desativar o uso do modelo de numeração para chamado

Acesse o seu GLPi e então desative o mascaramento de ID de tickets do plugin Behaviors:

Menu principal > Configurar > Geral
Acesse a opção “Formato do número do chamado” e marque a opção NULL (———-)

A fazer isso, eliminaremos a característica imposta pelo plugin que está gerando o BUG. Porém, é necessário ainda a execução do segundo passo para que possamos reiniciar o contador de ID da tabela.

Passo 2 – Reinicializa o contador da tabela glpi_tickets

Abra o terminal de comando do seu servidor, se autentique no MySQL, selecione a base de dados e execute o seguinte comando:

ALTER TABLE glpi_tickets AUTO_INCREMENT = 2113000000;

Feito isso, o contador da tabela será reiniciado para o valor “2113000000” e como o mascaramento imposto pelo plugin foi desabilitado, então ele tornará a ter o comportamento nativo que é funcionar de forma incremental.

Ou seja, os chamados registrados agora terão os seguintes identificadores 2113000000, 2113000001, 2113000002,2113000003 e assim suscetivamente.

Com esta solução de contorno, é garantido que você ainda tenha como gerar mais de 34 milhões de chamados até que o sistema apresente novamente um erro por limitações do banco de dados.

Causa Raiz do erro

Ao que conseguimos identificar, o erro ocorre devido a uma limitação de campos do tipo INT(11) usado no MySQL (não validamos em outros SGBDs). Este tipo de campo é justamente o utilizado nas tabelas do GLPi para as chaves primárias de cada registro e isso inclui os tickets.

Cada chamado aberto no GLPi recebe o mesmo identificador que sua chave primária do banco de dados. Isso implica que, se o ID de um determinado chamado no banco de dados for igual a 1 então, seu número de registro será também igual a 1. E assim sucessivamente e de forma auto incremental, ou seja, o próprio Banco de Dados checa qual o último ID existente e cria o próximo chamado com ID sendo igual ao último registro mais 1.

Quando usamos o plugin Behaviors, uma das características que adotamos (e que acreditamos ser de muito bom gosto) é alterar o formato dos identificadores dos chamados. Usamos isso para dar um ar mais profissional nas bases que estão iniciando, principalmente.

Então, ao invés de usarmos formatos como 1, 2, 3, 4, 5, 6… para registro dos chamados, usamos algumas técnicas de mascaramento disponíveis por meio do próprio Plugin Behaviors onde, amarramos o ID do ticket a data em que o registro foi realizado.

Exemplos:

Hoje são 3 de janeiro de 2022. Se estivermos iniciando uma base nova hoje, ao invés de iniciar a contagem dos tickets por meio de registros meramente incrementais (1, 2, 3 … N), podemos dar um ar mais sofisticado a estes usando uma mistura de formatos que usam a data do registro como referência:

2022010301 – chamado 1 do ano de 2022, mês de janeiro, dia 3

Isso dá um ar bem profissional. Porém, a contra gosto, descobrimos sua limitação após anos de uso.

O plugin Behaviors nos dá os seguinte modelos a serem adotados:

• Y000001
• Ym0001
• Ymd01
• ymd0001

Abaixo, colocamos um print contendo o resultado dessas formatações executadas na mesma ordem num terminal GNU/Linux:

Erro referente a este post ocorre apenas na utilização do último modelo “ymd0001”.

Se analisar com atenção, perceberá que este modelo possui a mesma quantidade de caracteres que os demais. Porém, com a virada do ano para 2022, os primeiros dígitos que eram 21 se tornasse 22.

Embora isso não pareça nada demais do ponto de vista lógico, fez com que fosse ultrapassada a capacidade de valor a ser armazenada em campos do tipo INT(11) que vai de 0 à “2.147.483.647” em um serviço MySQL.

Ou seja, o plugin Behaviors está tentando salvar valores maiores que 2201010000 nos registros dos chamados e com isso, o Banco de Dados retorna claramente o erro dizendo que o valor que está tentando salva excede sua capacidade.

Comandos utilizados para os testes apresentados no vídeo

Criação de base de dados SQL:

# Entrar no MySQL
mysql

Criar Base de Dados glpi_bug para testes:

create database glpi_bug character set utf8;

Selecionar Base de Dados glpi_bug para uso:

use glpi_bug;

Criar tabela verdanadesk_teste:

CREATE TABLE `verdanadesk_teste` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`id`)
  );

Inserir registros na tabela verdanadesk_teste de forma incremental:

insert into verdanadesk_teste values();

Inserir registros na tabela verdanadesk_teste de forma não incremental:

insert into verdanadesk_teste (id) values(255);

Listar conteúdo da tabela verdanadesk_teste:

select * from verdanadesk_teste;

Deletar registros da tabela verdanadesk_tmp:

delete from verdanadesk_teste where id = 2147483647;

Reiniciar o contador da tabela verdanadesk_tmp:

ALTER TABLE glpi_tickets AUTO_INCREMENT = 2113000000;

Conclusão

O pessoal que mantém o plugin Behaviors e a Teclib andam conversando sobre o problema e tentando entender uma forma de resolvê-lo em definitivo. Mas, até o momento, o martelo não foi batido.

Normal que isso aconteça! como vimos, não é uma mudança assim tão simples de acontecer.

Vamos acompanhando o desenrolar deste carretel e, assim que possível, atualizaremos este post, como de praxe.

Esperamos que o post tenha ajudado a esclarecer o problema. Grande abraço e fiquem com Deus!