INSTALAÇÃO DO SAGE SOB O CentOS 5.1

INSTALAÇÃO DO SAGE SOB O CentOS 5.1



Red Hat Nash Version 5.1.19.16
Daniel Martins (danmart@eln.gov.br)



Data: 27/12/2007
Duração da instalação: aproximadamente 6 horas (incluindo a colocação em serviço da base demo_ems).
Hardware: Xeon Quad com 512 Mbytes RAM, 35 Gbytes de disco, placa de som on-board, duas placas de rede Ethernet 10/100Mbps.
Material: 6 Cds obtidos no site http://www.centos.org


1. INTRODUÇÃO
O CEPEL já distribuiu informalmente um documento descrevendo a instalação do SAGE no CentOS 4.5. Como o fornecedor já distribui a versão 5.1, tomamos como desafio a instalação do SAGE nesta nova versão. As vantagens principais são que nesta nova distribuição o postgresql incluído já vem na versão 8.1 e o sistema operacional, mais atualizado, acreditamos, trás consigo drivers para um número maior periféricos.

2. INSTALAÇÃO DO SISTEMA OPERACIONAL.
Testes dos discos.
Como os Cds já haviam sido testados durante uma instalação bem sucedida num laptop HP/Compaq nx9010 fizemos skip deste primeiro procedimento.

Organização física dos discos.
/boot – 100 Mbytes
swap – 1024 Mbytes
/ - 35 Gbytes
Placas de rede
As duas placas de rede foram instaladas com IP fixo e com o nome da máquina srv1. Isto vai permitir que o sistema já vá se preparando para rodar a base demo_ems.
Instalação dos pacotes.
 Foi selecionado “Personalizar agora”
 Marcadas as opções “Desktop KDE” e “Server”
Personalização dos Pacotes.
 Ambiente da Área de Trabalho => KDE
 Aplicações => Tudo menos “Jogos e Entretenimento”
 Desenvolvimento => Tudo menos Ruby
 Servidores.
 PostgreSQL (sim)
 MySQL. (não)
 Servidor Web (tudo)
 Servidores de email (não)
 Servidores de nome (não)
 Servidores de notícias (não)
 Servidores de rede (não)
 Sistema Básico.
 Virtualização (não)
 Clustering (não)
 Armazenamento de Clustering (não)

3. PÓS-INSTALAÇÃO
 Firewall desabilitado.
 SELinux desabilitado
 Kdump (não)
 Criar usuário (não. Ainda não)
 Som (testado e OK)
 Cds adicionais (não)
4. PRIMEIRO LOGIN COM ROOT
 Acertada a hora do relógio.
 Tela entrou em 800x600 porque o monitor (HP p1230) não foi encontrado. Executamos “Administrador / Configuração de Telas” e utilizamos o HP p1130. Desta vez a tela foi para 1440 x 1280.
RightClick na área de trabalho / Configuração da Área de Trabalho e o trouxemos para a resolução tradicional de 1024 x 768. Tivemos que repetir este procedimento após o primeiro login como sage.
5. APRESENTAÇÃO DO USUÁRIO SAGE
Ainda como root:
# cd /
# mkdir /export
# mkdir /export/home
# mkdir /export/home/sage
# system-config-users
- Adicionar Usuário
 Nome do Usuário: sage
 Nome completo do usuário: SAGE
 senha: sagesage
 janela de login: /bin/tcsh
 Marcamos “criar diretório pessoal” : /export/home/sage
 Desmarcamos “criar grupo privado para usuário” e “inserir manualmente o ID do usuário e fechamos o aplicativo.

6. PRIMEIRO LOGIN COMO SAGE
Fizemos logout da interface KDE e login como sage / sagesage na interface KDE. Novamente tivemos que ajustar a resolução da tela desta vez seguindo simplesmente o procedimento final do ítem 4 (right click sobre a tela e etc.)



7. COLOCAÇÃO EM SERVIÇO DO POSTGRESQL, VERSÃO 8.1
Executamos:
# ps -e | grep ostgres e não obtivemos nenhuma resposta. Postgres está fora.
# su
# /sbin/chkconfig posrgresql on
# /sbin/service postgresql start [OK]

8. CONFIGURAÇÃO DO ACESSO A INTERNET/INTRANET
Instalação do java versão mais nova:
 Executamos o Mozilla
 Editamos “Preferências / Configurar / Conexão / Configuração manual do proxy em 10.0.0.49:80 para todos os protocolos.
 Selecionamos página inicial para http://www.google.com
 Apontamos Mozilla para http://www.sun.com
 Selecionamos Java for games, apps and a whole more
 Selecionamos “free java download”
 Selecionamos “Linux self-extraction” e baixamos jre-6u3-linux-i386.bin para o Desktop do usuário sage.
 Fizemos login como root (su) e executamos:
# cd /usr/local
# chmod a+x /export/home/sage/Desktop/jre-6u3-linux-i386.bin
# /export/home/sage/Desktop/jre-6u3-linux-i386.bin
Foi então criado o diretório /usr/local/jre1.6.0_03. Executamos então:
# ln -sf /usr/local/jre1.6.0_03/bin/java /usr/bin/java
# ln -sf //usr/local/jre1.6.0_03/bin/java /bin/java (Senão o VisorBase não roda)
 Executamos finalmente, segundo o manual do CEPEL:
# /sbin/chkconfig sendmail off
# cd /usr/lib
# ln -s libtk8.4.so libtk8.3.so
# ln -s libtcl8.4.so libtcl8.3.so
# chmod 755 /usr/bin/ssh-agent

9. OBTENÇÃO DOS ARQUIVOS DO SAGE
- Fizemos login como sage e executamos:
# su
# passwd sage e trocamos a senha de sagesage para sage.
- Editamos /etc/hosts e colocamos definimos ips para as máquinas srv1, srv2, ihm1, ihm2, ihm3, ihm4, trp1, trp2, ctr06-p e ctr06-r.
- Agora, de volta como sage (exit do su) executamos em $HOME:
# mkdir sage
# cd sage
Baixamos do CEPEL os seguintes arquivos: sageexe_linux_x86_ems.tar.Z, instala_sage e sagecnf_demo_ems.tar.Z. Este último do diretórios updates do sage. Todos estes arquivos foram colocados no diretório $SAGE.
Baixamos ainda do CEPEL todos os updates de 1 a 18a e os colocamos todos no diretório $SAGE.

10. LIBERAÇÃO DOS SERVIÇOS telnet e ftp.
Clicando em “Menu K” do KDE (botão equivalente ao botão Iniciar no XP) selecionamos “Administração / Configurações / Configurações do Servidor / Serviços”.
- Habilitamos vsftp e fizemos start do serviço.
- Habilitamos rsh.
- Habilitamos telnet. Não esquecer de clicar em “salvar” para que ainda valha para o próximo boot.

11. INSTALAÇÃO DO SAGE
Executamos como usuário sage no diretório $SAGE para instalação da árvore de diretórios e a base demo_ems original:
# chmod +x instala_sage
# ./instala_sage demo_ems

12. INSTALAÇÃO DOS UPDATES

Para instalação dos updates começaram a aparecer alguns problemas.

1º Problema: No comentário do update 18 o CEPEL sinaliza que talvez seja necessário instalar as bibliotecas zlib-1.1.4-8-1.rpm e zli-devel-1.1.4-8.rpm (que se encontra no site do Cepel). Contudo, executando “rpm -qa | grep zlib” encontramos já presente na versão 5.1 do CentOS as biliotecas zlib-1.2.3-3 e zlib-devel-1.2.3-3 e assim achamos desnecessário usar esta sugestão.

2° Problema: O comando “tail” no linux sofreu uma alteração recente. Após exaustivas discussões entre os especialistas internacionais se decidiu que tail a moda antiga trazia algumas ambiguidades, dentre elas o parâmetro +N. Este parâmetro, utilizado nos updates do Cepel informa para tail que ele deve listar todas as linhas do arquivo a partir da linha N. Isto trazia uma ambiguidade com o parâmetro -n, já um parâmetro tradicional. Assim, se resolveu eliminar o uso do parâmetro +N simplesmente e colocá-lo após o -n. Contudo, isto deve ter provocado um furor nos saudosistas que alegaram que muitos serviçõs (inclusive o instala_update do Cepel) ficariam prejudicados. O pior é que não é possível corrigir os arquivos updNNN_Linux_x86_ems.csh porque o check-sum não vai mais funcionar. Entretanto, após dura batalha se resolveu, para atender aos saudosistas e tradicionalistas que, para usar o comando tail a moda antiga basta setar a variável ambiente _POSIX2_VERSION para qualquer valor antes de executar o comando tail.
A solução encontrada então para este problema foi incluir no arquivo $HOME/.cshtc a seguinte linha setenv “_POSIX2_VERSION “ 1. Não devemos esquecer de relogar como sage para que isto tenha efeito posterior. Tentamos colocar esta linha no arquivo .cssagerc em $SAGE mas este arquivo é alterado durante alguns updates e a linha é então perdida.

3º Problema: O comando update (ou outro subcomando utilizado por este) utiliza o velho utilitário unix “compress” cujo antonimo é “uncompress”. Entretanto não pudemos mais encontrar estes comando no CentOS 5.1. Submetemos esta questão para o grupo de usuários (“Cadê o compress e uncompress”) e até agora não obtivemos nenhuma resposta. O utilitário compress e uncompress pode perfeitamente ser substituido convenientemente por zcat ou gzip ou gunzip. O problema é que compress e uncompress tem uma chave, ausente naqueles outros, “-” que informa para ele que a leitura do arquivo deve ser feita em stdin. Desta forma, tivemos dificuldade de estabelecer um “alias” simples para os velhos comandos. Acredito, entretanto, que, com algum esforço, possamos desenvolver um script que os substitua. Como natural a preguiça de fim de ano nos impede, simpesmente copiamos de um tradicional SAGE sob RedHat SE3 os comandos “compress” e “uncompress” e os colocamos no diretório /usr/bin.

Os updates foram então instalados, um a um, através do comando “instala_update N”. O comando instala_update aceita um intervalo de updates. Por exemplo “instala_update 3 8”. Contudo, como alguns updates esperam o arquivo .csh em $SAGE e alguns esperam-no em $SAGE/updates. Tivemos alguns problemas e optamos pela instalação de um de cada vez.

13. CONFIGURANDO O AMBIENTE POSTGRESQL.
Uma vantagem do uso do CentOS 5.1 é que ele já trás a bordo a versão 8.1 do postgresql, conforme comentamos anteriormente. Então, para prepará-lo para ser utilizado para geração da base de dados com AtualizaBD ou STI_cargbfj executamos os seguintes comandos:

# su
# service postgresql stop
# rm -vfR /var/lib/pgsql/data
# exit (volta ao usuário sage)
# habilita_postgres

Fornecemos a senha do root e respondemos “s” para as duas últimas questões. Após isto pudemos executar, com sucesso, o comando “AtualizaBD fria fonte” e geramos a base demo_ems.

14. INSTALAÇÃO DAS LICENÇAS DO CEPEL.
Para executar plenamente a base demo_ems somos obrigados a instalar as seguintes licenças: scd, bdh-report, sageiccp e estmon. Finalmente, executamos os últimos comandos listados abaixo para lançar a base demo_ems:

# AtualizaBD fria fonte
# habilita_gbh
# habilita_base
# cd calculos
# instala_calculos
# cd ../drivers
# su
# ./instala_mms
# exit
Por garantia, relogamos na interface gráfica como usuário sage, Executamos o comando var para examinar as variáveis ambiente e, ufa!:
# ativa gcd

A base demo_ems rodou. Executamos “sim-tr sim_sage srv1” no diretório $IHM/../simul e vimos as variáveis serem animadas no VisorTelas.

15. PROBLEMAS FINAIS
1º Problema: o programa VisorAlarme não entrou. Busca daqui, busca dali e descobrimos, sem entendermos bem o motivo, que o arquivo /tmp/sage estava com o proprietário postgres. Executamos então, sob root, um “chown -R sage:users /tmp/sage” e, após um “desativa gcd” e “ativa_gcd” o VisorAlarmes funcionou.
2º Problema: STI_cargbh soltou o seguinte erro na console de slog:
“ - ScreateM: Versão de MCD da aplicação diferente do GMCD”
“ - *ERRO* - Abertura de MCD SAR_ClasConfig SSC_Erro: -236”
“ - Execução interrompida: erro interno: -1”

Lembramos então que a base de dados histórica não é distribuida junto com os updates. Vamos então nos munir da versão mais recente dos executáveis da base histórica disponível no nosso Centro de Operação, stihist_postgres8_Linux_x86_9.9h.tar.gz, e ver o bicho que vai dar.