Implementação do Berimbau Infocentros

O Programa Identidade Digital adotou o nome "Berimbau" como identidade para os softwares desenvolvidos nas áreas de tecnologia. Assim, a solução desenvolvida para os Infocentros foi chamada de Berimbau Infocentros. Existem outras iniciativas de desenvolvimento no PID, como o Berimbau Desktop e o Acessa Berimbau. O primeiro é uma solução que ainda está sendo implementada, para que os usuários dos Infocentros possam levar para casa um LiveCD com um sistema que possui um ambiente desktop idêntico ao do Berimbau Infocentros, e o segundo é um sistema Web que integra-se com o Berimbau Infocentros e cuida dos dados e gestão das unidades, usuários, cursos, estatísticas, etc.

O Berimbau Infocentros seguiu um modelo de versionamento em que é possível detectar o estado global da solução, e que define os tipos de atualizações efetivadas. A primeira versão colocada em produção foi a 1.0.1. O primeiro dígito da versão deve permanecer enquanto o Berimbau Infocentros não for drasticamente modificado. Este dígito deve ser alterado somente quando os softwares básicos da solução sofrerem grandes alterações, por exemplo, se outra distribuição GNU/Linux passar a ser utilizada como base do sistema. O segundo dígito refere-se a uma atualização em que será necessário uma reinstalação local, ou seja, deve-se estar presente num infocentro para realizar a atualização do sistema. O terceiro dígito é modificado a cada atualização remota e automatizada, que será vista com detalhes ainda neste capítulo.

Instalação e configurações iniciais da distribuição

O Debian-BR-CDD possui um propósito semelhante ao que é necessário no Berimbau Infocentros. Ambos são concebidos para usuários com pouca habilidade técnica, fornecem uma interface amigável, além de possuírem muitos softwares em comum. Outro fator importante é que o autor deste trabalho é também desenvolvedor do Debian-BR-CDD.

Como visto no capítulo anterior, a base do berimbau Infocentros é a versão 1.0pre5 do Debian-BR-CDD. Uma documentação sobre a instalação do Debian-BR-CDD pode ser encontrada em Doc do Debian-BR-CDD 2005. A solução não demandou a criação de um instalador genérico, visto que o hardware é homogêneo. Portanto foi criado um CD de instalação específico para o hardware homologado, que será visto a seguir.

Foram fechados 49 ticketspara primeira versão oficial do Berimbau Infocentros que englobaram uma série de configurações, personalizações e codificações no sistema base. A Figura 8 exibe a interface de tickets do Trac, onde são listadas algumas das atividades realizadas para o release desta versão do sistema.

Preparação do kernel

O servidor LTSP é responsável pelo processamento e reserva de memória física para cada processo requisitado pelos terminais. Foi preciso então otimizar ao máximo a configuração do kernel linux do servidor, de forma que suportasse somente o hardware necessário, sem desperdiçar recursos com suporte a dispositivos inexistentes. O kernel deve suportar também os dispositivos adicionais que estão presentes nos Infocentros, como uma impressora USB e gerenciamento de energia a partir de um nobreak, utilizando recursos do ACPI.

Foram realizados testes de performance com as versões do kernel linux 2.6.8 e com a versão 2.4.28. Depois da otimização das configurações de ambas as versões, a 2.4.28 mostrou-se compatível com todas os dispositivos necessários e uma leve vantagem na performance de execução dos programas. Não houve um teste de fato confiável nesse sentido, e a vantagem na performance estaria dentro de uma faixa de erro experimental. Porém, antes de se realizar testes exaustivos, foi decidido pela utilização do kernel 2.4.28, devido a um patch disponível para a alteração do seu sistema de escalonamento, que se mostrou de fato um grande benefício na utilização do LTSP.

O patch utilizado foi o fairsched, que significa "escalonamento justo". A situação em que diversos terminais processam seus programas num único servidor pode causar transtornos frequentes para seus usuários. Um exemplo clássico é quando um dos terminais está ocupando grande parte do poder de processamento do servidor, num momento em que outros terminais necessitam realizar tarefas simples. Estes últimos sofrem um atraso consequente da política de escalonamento do kernel.

O patch fairsched implementa um escalonamento justo hierárquico de CPU para o Linux. Resumidamente este escalonamento aloca tempo de CPU para os processos a partir de "pesos" pré-determinados, onde somente uma parcela da unidade de processamento é reservada para cada usuário. Os testes executados com o fairsched foram bastante satisfatórios, essencialmente o teste simples em que um usuário executa um loop infinito de criação de processos através da syscall fork() enquanto outros utilizam terminais do mesmo servidor LTSP. Nos testes com o kernel sem o patch, o sistema travava imediatamente, interrompendo as atividades de todos os usuários nos terminais. Com o fairsched, somente o ambiente do usuário que executou o loop travava, mostrando que de fato apenas uma parcela da CPU estava reservada para este usuário, uma característica bastante adequada para o cenário dos Infocentros.

O kernel foi compilado utilizando o sistema para administração de kernel do Debian, que facilitou bastante a administração posteriores atualizações.

Espelhamento de discos

O hardware do computador homologado para trabalhar como servidor LTSP no projeto possui dois discos rígidos, cada um com 80GB. O propósito da utilização de dois discos foi a implementação de uma rotina de backup, onde tivemos o Berimbau Infocentros inicialmente instalado nos dois discos cumprindo de forma satisfatória o requisito de redundância de dados a baixo custo.

O disco 1 (hda) é utilizado por padrão nos Infocentros. Diariamente o monitor do Infocentro realiza uma rotina de espelhamento dos dados do disco 1 para o disco 2 (hdb). No caso de uma falha no disco 1, basta modificar o SETUP da BIOS da máquina para que o sistema do disco 2 inicialize. Este é um procedimento de caráter provisório, e deve funcionar enquanto a equipe técnica do PID é acionada para tomar as providências necessárias em relação ao disco 1 com o sistema de arquivos danificado.

Foi desenvolvido um programa em bash, utilizando recursos do rsync e do zenity afim de oferecer uma interface simples para o monitor do Infocentro realizar as tarefas diárias de espelhamento. Os programas desenvolvidos especialmente para administrar o Berimbau Infocentros foram inseridos na entrada de menu do GNOME, obedecendo a mesma hierarquia utilizada pelos outros softwares de gerenciamento do sistema. As figuras 4.2.3, 4.2.3, 4.2.3 e 4.2.3 ilustram o passo a passo para a tarefa de espelhamento dos discos no sistema.

Figura 9: Menu para atividade diária de espelhamento de discos

Figura 10: Tela inicial do procedimento de de espelhamento

Figura 11: Confirmação para início do espelhamento

Figura 12: Efetivação do espelhamento

Um espelhamento diário dos discos leva em média 10 minutos para ser concluído e sugere-se que seja realizado minutos antes de se fechar o Infocentro. Este curto tempo de espelhamento deve-se à caracaterística do rsync realizar somente a transferência dos arquivos que foram alterados desde o último espelhamento.

Alguns cuidados foram tomados para a implementação deste procedimento, como por exemplo as entradas no /etc/fstab e /boot/grub/menu.lts, que são específicas para cada disco. O programa também só realiza o backup se nenhum usuário estiver logado em qualquer terminal LTSP, evitando que o procedimento seja realizado enquanto alterações são efetivadas em arquivos no sistema.

Criação e instalação de outros pacotes específicos

Um dos maiores benefícios da utilização do Debian para o Berimbau Infocentros foi seu sistema de gerenciamento de pacotes, o APT. Com ele foi possível desenvolver pacotes de personalização do sistema com consistência e principalmente com um processo de atualização remota bastante eficaz.

Diversos pacotes Debian foram criados para esta solução, no entanto foram criados somente quando estritamente necessário. O projeto foi concebido para se utilizar o máximo possível de programas disponíveis, considerando o simples fato de que quanto mais "jovem" é um código, maior é a possibilidade de se encontrar falhas. Tentamos então ao máximo utilizar os pacotes oferecidos diretamente pelos repositórios oficiais do Debian , desenvolvendo somente aquilo que de fato deve ser específico para o Berimbau Infocentros.

Gerência e monitoramento remoto

Num grande parque de computadores há maior probabilidade de problemas acontecerem paralelamente, prejudicando os serviços que devem ser oferecidos. Falhas podem surgir na disponibilização de link pelo provedor do Infocentro ou em algum componente físico local. Problemas de software podem ocorrer, porém, muitos deles podem ser detectados e tratados remotamente, e até mesmo automaticamente.

Diante do cenário em que se tem aproximadamente uma centena de Infocentros espalhados pelo estado sob a responsabilidade de uma entidade, é prudente que haja um sistema que atue diante de uma falha nos sentidos de (1) detectar a falha, (2) isolar a falha e (3) eliminar a falha de forma automatizada, se possível. O Nagios é o software que realiza esse trabalho. Além de notificar os administradores em caso de falhas, ele fornece uma interface Webcom uma visão macro dos Infocentros, possibilitando a geração de relatórios, estatísticas, visualização de mapas em 2D, 3D, entre outros recursos interessantes para o projeto.

O Nagios possui um componente extra, o Nagios Remote Plugin Executor. O NRPE permite que um serviço remoto do Nagios colete informações internas de um sistema, como por exemplo a quantidade de disco rígido utilizado em cada partição do sistema. Ele possui uma arquitetura cliente-servidor. O cliente é executado pelo processo do Nagios, enquanto o servidor NRPE espera por conexões, e ao receber uma requisição, executa localmente um plugin do Nagios e retorna a informação de estado para o cliente, que armazena a informação na base de dados do Nagios, onde será realizada uma ação de acordo com o estado recebido.

No nosso caso foi preciso desenvolver alguns plugins específicos para o Nagios, assim criamos um pacote para o NRPE para os Infocentros em conjunto com os plugins nativos do Nagios e outros desenvolvidos no projeto. A criação do pacote possibilitou também a configuração específica para o servidor NRPE, onde somente o servidor com o endereço IP determinado pelo PID tem permissão para requisitar informações dos Infocentros.

A figura 13 exibe sua tela de serviços monitorados em cada Infocentro, enquanto a figura 14 mostra o gráfico que informa a situação referente à quantidade de processos zumbis em um Infocentro ao longo do tempo.

Figura 13: Nagios - estado dos serviços nos Infocentros

Figura 14: Nagios - gráfico do estado de um Infocentro ao longo do tempo

Além do Nagios, utilizamos um software para monitoramento remoto de recursos, com a intenção de termos uma outra visão da utilização dos recursos dos Infocentros. Este software é o Cacti. O Cacti gera gráficos na linha do tempo em relação à utilização de recursos remotos. Instalamos no Berimbau Infocentros um servidor SNMP com as configurações necessárias para que o Cacti, instalado num dos servidores do PID, pudesse realizar requisições e gerar os gráficos necessários.

O Cacti coleta informações referente ao tráfego de bits entrando e saindo em cada interface de rede do servidor LTSP nos Infocentros. Todo servidor LTSP nos Infocentros possui as interfaces eth0 e eth1. A primeira é uma interface gigabit que conecta-se aos 10 terminais LTSP, a segunda é a interface que conecta-se à Internet através de um link fornecido pelo provedor do Infocentro.

As informações exibidas pelo Cacti foram de grande utilidade para o projeto, essencialmente pelo fato de podermos ter uma visão pro-ativa referente à utilização dos recursos de rede em cada Infocentro. Pela análise dos gráficos gerados na interface eth0 podemos detectar visualmente se a demanda de link está compatível com a disponibilidade. Com isso o PID consegue sugerir ao Infocentro que se realize um upgrade do link em caso da demanda estar crescendo ao ponto de alcançar a disponibilidade de link oferecida.

Em caso da observação de pouca utilização, o PID pode entrar em contato com o Infocentro e para verificar se há algum problema referente ao fornecimento do link, ou mesmo detectar se o Infocentro está sendo utilizado em dias ou horários inadequados. Um exemplo pode ser a utilização de Infocentros durante o período noturno, em regiões com alto índice de violência.

A análise da interface eth1 pode detectar se a infraestrutura de rede do Infocentro está em condições adequadas. A conectividade entre o servidor e as estações devem estar em perfeitas condições para o bom funcionamento dos serviços oferecidos pelo LTSP. Caso algum servidor LTSP esteja gerando um tráfego abaixo da média na interface eth1, a equipe do PID deve entrar em contato, pois isso pode indicar por exemplo que alguns terminais não estão funcionando, ou que a infraestrutura de rede local não está fornecendo a infraestrutura de rede necessária para o bom funcionamento do LTSP.

A figura 4.2.5 indica os tráfegos de entrada e saída na interface eth0 e eth1 de um Infocentro implantado na cidade de Vitória da Conquista.

Figura 15: Cacti

Gerenciamento de usuários locais

Para cumprir com o requisito de se disponibilizar um espaço no disco rígido para cada usuário nos Infocentros foi preciso criar um mecanismo que possibilitasse o gerenciamento de usuários no sistema. Isso significa cadastro, modificação e remoção de usuários no Berimbau Infocentros. Lembrando que estes não são os usuários cadastrados na base de dados central, são somente usuários Unix, que possuem um login e uma senha no sistema para poderem usufruir do seu espaço individual no disco rígido.

Há diversas ferramentas disponíveis para manipular contas de usuários no GNU/Linux, no entanto foi preciso utilizar uma que oferece uma interface simples e possibilidade de personalização. A primeira tentativa foi a utilização do manipulador de usuários nativo do GNOME. Este software não atendeu às necessidades, pelo fato de listar obrigatoriamente todos os usuários do sistema, que em alguns casos passavam dos milhares, tornando o processo exaustivo e consequentemente, muito lento.

A opção utilizada foi o Webmin. Além de oferecer uma interface Web para manipulação de contas, o Webmin foi personalizado seguindo a estética gráfica da solução, além de ter sofrido uma série de configurações de grande importância para a segurança do sistema, como por exemplo a possibilidade do usuário monitor [*] ter o poder de manipular as contas com restrições básicas. O benefício imediato foi a não disponibilização de permissões de super usuário do sistema para os monitores, que não podem, por exemplo, manipular usuários e grupos nativos do sistema. Outro benefício que o Webmin proporcionou foi a possibilidade de extensão através de módulos que podem oferecer algumas informações adicionais aos monitores, como utilização de recursos locais (disco, memória, etc).

A figura 16 mostra a tela do Webmin personalizado para o projeto. Um menu foi criado para este sistema de gerenciamento de usuários, oferendo uma interface intuitiva para os monitores, que muitas vezes ainda não possuem habilidade com a solução.

Figura 16: Webmin personalizado para gerenciamento de usuários no Berimbau Infocentros

[*] monitor é o usuário do sistema que pertence ao monitor do Infocentro, ele possui algumas permissões adicionais por padrão.

CD de replicação rápida

Após a preparação da primeira versão do Berimbau Infocentros foi preciso realizar a instalação nos 100 servidores, que posteriormente seriam transferidos para as unidades espalhadas no estado. O propósito era que o sistema pudesse ser instalado e testado num único dia, por pessoas sem habilidade técnica para realizar as tarefas básicas de uma instalação GNU/Linux. Assim deu-se a necessidade da criação de um método que possibilitasse a instalação do sistema rapidamente nos servidores, sem qualquer necessidade de interação humana referente às configurações de software.

Foi criado então um CD de replicação, utilizando basicamente o isolinux e uma versão modificada do partimage estaticamente linkada. A versão utilizada do partimage sofreu uma pequena alteração no código, para permitir que o processo fosse 100% não interativo, pois mesmo fornecendo a opção de não interatividade era preciso realizar uma confirmação para cada partição replicada. Veremos que cada servidor necessita de 4 partições, o que proporcionaria aproximadamente 400 interações desnecessárias.

O CD de replicação utiliza os componentes básicos de uma distribuição GNU/Linux. Um kernel realiza o boot, carrega uma imagem initrd e chama o processo init. O init executa então um script que se responsabiliza por criar as tabelas de partições no disco e chamar o partimage, que realiza a cópia das imagens das partições. Algumas configurações específicas pra cada disco são realizadas (grub e fstab) e o processo é finalizado com a gravação do MBR de cada disco rígido utilizando o LILO.

Este processo dura aproximadamente 5 minutos por máquina, possibilitando a instalação do sistema em 100 servidores em curto espaço de tempo. Além desse benefício alcançado, o CD de replicação pode ser utilizado para reinstalar um servidor posteriormente por alguém que não possua habilidades técnicas. Ele é também de fácil atualização, podendo abrigar imagens de versões mais atuais somente pela substituição do arquivo de imagem antigo.

Sistema de atualização

Não pudemos deixar de lado a premissa ideal de manter todos os Infocentros idênticos. Como visto anteriormente, essa característica evita o tratamente de exceções e consequentemente demanda menor trabalho de manutenção: resolver um problema de software em um Infocentro deve significar resolver este problema em todos os Infocentros. As atualizações devem então ser realizadas remotamente e sem intervenção manual em cada Infocentro implantado. Remotamente quer dizer que não é necessário a presença física de um técnico para realizá-la. A não intervenção manual quer dizer que não é necessário logar remotamente em cada Infocentro para efetivar a atualização. Ou seja, o processo deve ser totalmente automatizado, dependendo apenas se o PID disponibiliza ou não uma atualização. Diante desses princípios, os Infocentros devem possuir uma tarefa agendada que verifique diariamente se há alguma atualização disponível. Se houver, devem efetivá-la.

Esta tarefa foi implementada utilizando os recursos do cron e do APT. O código abaixo ilustra uma entrada no arquivo de agendamento do usuário root do Berimbau Infocentros, onde verifica-se diariamente, às 10 horas e 30 minutos se há uma atualização disponível no repositório Debian localizado na sede do Programa Identidade Digital. O apt-get encarrega-se de checar se a versão do pacote de atualização denominadoberimbau-update disponível no servidor é mais atual que a versão instalada no Infocentro. Se for, é realizado o download e a instalação não-interativa do pacote mais novo.

30 10 * * *    apt-get update && apt-get install -y berimbau-update

A criação de um pacote de atualização pode ser consequência da necessidade de resolver uma falha presente nos Infocentros, pode também se dar pela demanda de instalação ou atualização de algum software específico nos Infocentros, ou pode apenas conter um novo papel de parede na área de trabalho, como por exemplo acontece em ocasiões especiais, como as comemorações Juninas, Natal, Ano novo, etc.

O pacote de atualização chama-se berimbau-update e é na verdade um meta-pacote Debian, que contém como dependência uma série de pacotes que devem ser pacotes desenvolvidos pelo PID, com propósitos de correções de falhas, instalação de pacotes oficiais do Debian ou personalizações do sistema. Abaixo são listadas as características do pacote berimbau-update:

Define a versão global da solução

O versionamento do berimbau-update define a versão do sistema. Além de possuir a versão diretamente no seu nome (ex. berimbau-update-1.0.4) ele escreve a sua versão nos arquivos /etc/issue e /etc/issue.net, que devem conter o nome e versão da distribuição em sistemas GNU/Linux.

Possui dependências acumulativas

É sabido que as unidades de Infocentros são implantadas sequencialmente. Assim, pode ocorrer a situação em que um Infocentro esteja em funcionamento durante meses enquanto outro acaba de ser implantado. É possível então que o Infocentro mais antigo X esteja rodando o Berimbau Infocentros 1.0.5, enquanto o que acabou de ser implantando, Y, possui a versão inicial 1.0.1. Percebe-se nessa situação que a versão mais atual do pacote berimbau-infocentros disponível no servidor do PID é a 1.0.5 e que o Infocentro Y realizará a verificação automática e efetivará a atualização. O berimbau-update 1.0.5 deve então prover as atualizações 1.0.2, 1.0.3 e 1.0.4 por dois motivos básicos. O primeiro é óbvio, considerando que todos os Infocentros devem possuir a mesma versão e a mais atual disponível. A segunda é que uma atualização pode manipular algo que só esteja disponível na sua exata versão anterior. Assim, os procedimentos realizados na versão 1.0.5 só devem ser realizados após a instalação completa e sequencial de todas as anteriores.

Mantém um histórico de todas as versões - changelog

A fim de reduzir o custo de suporte e manutenção pela equipe do PID, foi preciso registrar todo o histórico de atualizações. Uma ocorrência bastante comum é a abertura de um chamado para a equipe de suporte referente a um determinado problema. Com o registro das correções para cada versão do sistema é possível saber se o problema em questão ainda persiste pelo fato do Infocentro não possuir a atualização que o corrige, mas que já está disponível. Num caso como este basta pedir para que o monitor do Infocentro aguarde até o próximo dia, quando uma verificação automática de atualização será realizada.

Existem três níveis de registros de modificações para o pacote berimbau-updade: um está escrito no idioma português, numa linguagem mais acessível dentro do ambiente Trac. Cada milestone fechado neste ambiente deve possuir as informações mais relevantes de modificação. A Figura 4.2.8 mostra as descrições contidas para o milestone Berimbau Infocentros 1.0.5. Nota-se também nesta figura o tratamento que o Trac dá aos tickets que já foram fechados. Os tickets podem ser fechados diretamente pelo sistema de tickets do Tracou através de uma mensagem de commit do Subversion, utilizando a sintaxe closes: <ticket-number>.

Figura 17: Trac - modificações no milestone 1.0.5 (versão 1.0.5 do sistema)

O outro nível de registros está no próprio changelog do pacote, onde são descritos no idioma inglês os detalhes do pacote, oferecendo aos desenvolvedores e colaboradores as informações necessárias para o acompanhamento do projeto. O código abaixo ilustra os registros no arquivo changelog do pacote berimbau-update, referente às atualizações 1.0.4 e 1.0.5:

berimbau-update (1.0.5) unstable; urgency=low

   * Depends on sagui package that:
      
      - fix cups problem with inactive printer
      - update Berimbau to 1.0.5

 -- Tiago Bortoletto Vaz <tiago@debian-ba.org>  Mon, 05 Jul 2005 08:05:00 -0300

berimbau-update (1.0.4) unstable; urgency=low

   * Depends on avestruz package that:
      
      - install xine-ui and mozilla-plugin-vlc packages
      - install /usr/local/bin/video.sh to call xine 
      - install a new system menu item for show videos
      - update Berimbau to 1.0.4

 -- Tiago Bortoletto Vaz <tiago@debian-ba.org>  Mon, 09 Jun 2005 09:06:09 -0300

O terceiro e mais detalhado nível refere-se diretamente aos changesets registrados pelos commits efetuados no repositório Subversion. Como visto anteriormente, o Trac provê uma interface clara de verificação desses changesets, o que mostra com detalhes toda a evolução do projeto, listando as revisões de cada arquivos, modifificações, mensagens de commits, etc. Este nível de detalhes pode auxiliar um processo de depuração em caso de falhas na codificação do pacote. A Figura 4.2.8 ilustra como o Trac exibe essas informações.

Figura 18: Trac - exibição de modificações entre diferentes revisões

A utilização desse esquema de atualização forneceu as funcionalidades necessárias para que os Infocentros pudessem sofrer atualizações sem necessidade da presença física de técnicos, num processo automatizado e consistente. Os registros de modificações de versões da solução podem ser consultadas a qualquer momento, seja para a equipe de suporte conhecer suas características, ou para um desenvolvedor realizar uma depuração.

Alguns problemas neste processo foram também detectados. O mais comum foi a eventual sobrecarga no link disponível para o servidor do PID que disponibiliza as atualizações, considerando que o agendamento para a atualização dos Infocentros era num mesmo horário. Outro problema contou com a não atualização de alguns Infocentros por conta do relógio do sistema estar com a marcação de hora incorreta. Esses problemas foram facilmente contornados com novas atualizações e aumento do link do Programa Identidade Digital.

Contabilização de acessos

O Programa Identidade Digitalpossui uma base de dados com os registros referentes aos Infocentros implantados. Nesta base de dados deve constar, entre diversos outras informações, a quantidade real de acessos em cada Infocentro. É possível coletar manualmente essas informações, porém seria um processo custoso, pois além de coletar os dados seria preciso inserí-los na base de dados central, para cada Infocentro.

Foi criado então um método para coletar automaticamente esses registros de acessos e enviá-los ao banco de dados, utilizando ferramentas simples e os logs providos pelo syslog do sistema. O programa desenvolvido coleta os dados diários de acesso, rotaciona os logs, carrega as informações do arquivo de meta informações faz o envio utilizando SSL, para o servidor do PID, que autentica a requisição e insere os dados no banco de dados.

CD de restauração do sistema

Diante de uma falha no sistema de arquivos do Berimbau Infocentros deve haver um método de restauração sem a necessidade da presença de técnicos do PID no local. Assim foi desenvolvido um CD de restauração, com o objetivo de restaurar um sistema que foi corrompido por uma falha no seu sistema de arquivos. Este CD foi desenvolvido utilizando os componentes do CD de replicação. A diferença é que ele apenas instala a imagem referente à partição que contém os dados do Berimbau Infocentros, sem refazer a partição de dados dos usuários. Este CD basicamente refaz toda a partição do sistema no disco 1, sincroniza os arquivos de configurações específicas a partir do disco 2 e restaura os dados dos usuários também a partir do espelho disponível no disco 2.

Arquivo de meta-informações

É sabido que os Infocentros inicialmente foram replicados a partir da mesma fonte, assim possuem os mesmos softwares, a mesma configuração, etc. Porém surgiu a necessidade dos Infocentros carregarem algumas informações específicas. A primeira demanda nasceu da necessidade de se enviar informações sobre a quantidade de acessos em cada unidade implantada. O Infocentro necessitava então enviar uma informação para uma base central dizendo o seguinte: "Eu sou o Infocentro X e hoje houve Y acessos aqui". Há duas maneiras de se pensar em implementar essa funcionalidade. A primeira é configurar especificamente o programa que realizaria essa atividade diária. A segunda é criar um registro local, que deve conter informações específicas do Infocentro, e ser acessada pelo programa que enviará as Informações para a base de dados do PID. Em ambos os casos é preciso uma intervenção remota, porém no segundo caso o registro pode servir para programas futuros, o que aconteceu no projeto.

O registro contendo as informações específicas em cada Infocentro é o arquivo /etc/berimbau-metainfo, que a princípio guardava informações referentes ao número de identificação do Infocentro na base de dados do PID e o seu nome, como mostra o trecho abaixo:

# this file store some settings about this server
# for PID management

# Nome do Infocentro
nomeInf=

# ID do Infocentro no Acessa Berimbau
idInf=

# Usuário para contabilizacao de logins
userAcessa=

# Senha para contabilizacao de logins
passAcessa=

# Endereco do contador de logins
urlCounter=

Sistema de gestão dos Infocentros

Foi desenvolvido um sistema WEB para que os monitores dos Infocentros realize tarefas relativas ao cadastro, consulta e atualização dos dados dos usuários, agendamento de cursos, e organização das suas respectivas turmas. Este sistema também fornece relatórios e gráficos sobre quantidade de usuários, acessos, localidades, etc.

Entre as suas principais características estão a flexibilidade e possibilidade de adaptação a novos cenários, como a inserção de novos equipamentos ou a retirada de computadores do Infocentro. Através de senhas que hierarquizam o acesso, o sistema chamado Acessa Berimbau define quais funções podem ser exercidas por instrutores, monitores e administradores do sistema.

O sistema foi codificado de maneira a permitir essa extensibilidade e escalabilidade, isto é, possibilitar a adição de novas funcionalidades ou modificação de procedimentos atuais. O Acessa Berimbau foi desenvolvido utilizando linguagem PHP, tendo o Apache 2 como servidor Web e o PostgreSql? como SGBD.

O desenvolvimento seguiu os paradigmas da orientação a objetos, utilizando alguns padrões de projeto, como o Dao e Bo, que oferecem uma camada de abstração para o acesso a métodos, e o padrão MVC para separar a camada de negócios das camadas de acesso ao banco de dados e apresentação.

Foi utilizado também o software Smarty que é um gerador de templates, e com isso separaramos todo o código php do código html, facilitando a preparação do leiaute por outra equipe especializada. Para prover uma camada de abstração de banco de dados, utilizamos a biblioteca Pear::BD, e para gerar os gráficos dos relatórios, foi utilizado a biblioteca Php-Gd, que provê os métodos necessários para gerar imagens em formato Jpeg e Png.

Foi implantado também um mecanismo de autenticação utilizando a biblioteca Pear::Auth, totalmente integrada com as outras bibliotecas utilizadas no desenvolvimento do sistema. Para o acesso aos relatórios foi utilizado o padrão de projeto Facade que permitiu que fosse criado uma única classe que acessa todas as outras necessárias para gerar os relatórios.

As Figuras 4.2.12, 4.2.12, 4.2.12, 4.2.12, 4.2.12 e 4.2.12 exibem algumas telas de funcionalidades importantes do Acessa Berimbau. [*]

Figura 19: Acessa Berimbau - tela principal com quadro de avisos para os monitores

Figura 20: Acessa Berimbau - tela de agendamento para utilização do Infocentro

Figura 21: Acessa Berimbau - opção de relatório

Figura 22: Acessa Berimbau - gráfico em barra

Figura 23: Acessa Berimbau - gráfico pizza

Figura 24: Acessa Berimbau - tela sobre o programa

Controle de utilização dos Infocentros

Cada Infocentro chega a possuir milhares de usuários cadastrados. Isso gera uma demanda muito grande de utilização, sendo necessário limitar o tempo de acesso para que mais pessoas possam ser beneficiadas, entretanto, este limite não deve ser único para todos os Infocentros, deve ser flexível para casos específicos e deve ser controlado pelo monitor do Infocentro.

Um problema surge quando um usuário não respeita o limite de tempo ou desobedece teimosamente alguma norma do Infocentro e o monitor é obrigado a intervir. Afim de amenizar esta situação, foi desenvolvido um software para encerrar sessões de usuários nos terminais do Infocentro. O programa foi escrito em C e GTK, tornando transparente para o usuário a intervenção do monitor, que realiza o procedimento de encerrar a sessão do usuário a partir do servidor.

A figura 4.2.13 exibe uma tela capturada do sistema de encerramento de uma sessão remota no Infocentro. Este software foi integrado ao Menu do GNOME, no ítem Sistema, onde todos os outros programas para manipulação do Berimbau Infocentros está localizado, sendo assim, mais um programa de fácil e intuitivo acesso por parte do monitor.

Figura 25: Tela do programa que encerra sessões de usuários nos Infocentros