Sempre que for necessário acessar o ALFA de uma máquina nova, é preciso executar esse procedimento para que o ALFA reconheça e aceite a conexão que está recebendo.
Esse procedimento está dividido em duas partes. A criação de uma nova chave para o putty e a configuração do putty. Se você já tiver uma chave que foi criada em outra máquina, pode pular para a etapa de configuração do putty.
Antes de iniciar o procedimento, verifique se o usuário para o qual a conexão será criada está listado na linha AllowUsers do arquivo de configuração sshd_config (/etc/ssh/sshd_config)
LINUX:
WINDOWS:
O aplicativo Sybase PowerDesigner é utilizado para a criação do modelo gráfico do banco.
Antes de utilizar o aplicativo, execute o script dump_powerdesigner.lua (/usr/local/bin):
| -n | (opcional) [pg_dump] Dump apenas do esquema especificado. |
| -N | (opcional) [pg_dump] Não inclui no dump o esquema especificado. |
Faz um dump do banco e nele faz as alterações necessárias para ser utilizado no Sybase PowerDesigner.
Ao final, gera um arquivo no formato 'MODELO#[DBNAME]#[DBUSER]#[ESQUEMA(S)]#dump2pwrdesigner.sql' contendo as estruturas das tabelas e views do respectivo usuário/esquemas escolhido(s).
Ao fazer uma alteração na estrutura ou nos metadados das tabelas de um usuário do banco no ALFA, esta deverá ser feita também no PROD. Para verificar se todas as alterações feitas no ALFA também foram feitas no PROD, ou seja, se há diferenças na estrutura e/ou nos metadados dos dois bancos, existe o seguinte script:
Varre as estruturas das tabelas do usuário do banco escolhido (e seus respectivos esquemas) no PROD e do mesmo banco no ALFA.
Não faz as alterações necessárias, apenas compara os dois bancos.
Ao final, lista as diferenças nas estruturas das tabelas do usuário entre as duas máquinas.
Caso não haja diferença nas estruturas, varre os metadados das tabelas do mesmo usuário escolhido (e seus respectivos esquemas) no PROD e essas mesmas tabelas no ALFA.
Não faz as alterações necessárias, apenas compara os dois bancos.
Ao final, lista as diferenças nos metadados das tabelas do usuário entre as duas máquinas.
| -q | Não imprimir procedimentos na tela. |
| -f | Sempre mostrar diferença dos metadados, mesmo se houver diferença na estrutura. |
| -s | Mostrar comandos SQL a serem executados na máquina de destino (sincronização). |
| -n SCHEMA | Realiza diff em um esquema específico do banco de dados. |
| -t TABLE | Realiza diff em uma tabela específica do banco de dados. |
| -U USER | Realiza diff em um usuário específico do banco de dados. |
| -pa | Comparar 'prod' no alfa e na produção. |
| -ap | Idem a opção -pa. |
| -ta | Comparar 'prod' no alfa e 'teste' na produção. |
| -at | Idem a opção -ta. |
| -h | Help.. |
Em nossos sistemas, possuimos algumas tabelas "especiais" que, ao invés de armazenarem dados fornecidos por usuários, armazenam metadados que são utilizados no funcionamento dos scripts. Essas tabelas precisam estar com os dados corretos para que tudo funcione normalmente. Para podermos identificar esse tipo de tabela e comparar os dados das mesmas entre o ALFA e o PROD (usando o script diff_banco.lua), vamos utilizar o recurso de comentários oferecido pelo Postgres.
No PostgreSQL temos um recurso muito bacana que é o comentário em objetos. A idéia é bem simples. É ser um comentário (descrição) do objeto. Um comentário pode ser adicionado em colunas de tabelas, tabelas, seqüências, esquemas, tablespaces, rules, funções, gatilhos (triggers) dentre outros. No nosso caso, utilizaremos os comentários em tabelas.
Em nosso script de diferenciação de bancos, para que uma tabela seja identificada como tabela de metadados, deveremos inserir na mesma o comentário: metadados.
Como utilizar? Ao acessar o banco com o usuário desejado, o qual deverá ser dono das tabelas a serem comentadas, execute o comando detalhado a seguir.
Para listar todas as tabelas de um determinado banco e seus respectivos comentários, utilizamos o seguinte comando:
Esse último comando nos permite conferir se os comentários foram criados corretamente.
Como explicado anteriormente, a especificação das tabelas de metadados é extremamente importante para o funcionamente do script diff_banco.lua. Veja detalhes do script em [Diferença do banco entre as máquinas (ALFA|PROD)].
Os erros que acontecem na máquina de produção normalmente são enviados por e-mail para a conta da equipe, o que não é muito conveniente quando estamos testando algo na produção. Para evitar isso, há uma lista de IPs para os quais a mensagem de erro aparece normalmente, do mesmo jeito que na máquina de testes, sem o envio de e-mail. Essa lista está logo no início no arquivo /home/ccpa-auto/luarocks/share/lua/5.1/sintra-conf/cgilua/error_message.lua.
A publicação de versões novas de sistemas na máquina de produção deve respeitar os seguintes passos:
| [dir. do sistema] cvs tag <novo tag> | Cria um tag para a nova versão do sistema |
| [outro dir.] cvs export -r <novo tag> <sistema> | Obtém uma cópia da versão nova sem os diretórios CVS |
| [outro dir.] tar czf <arquivo>.tar.gz <sistema> | Gera um arquivo de distribuição |
| [outro dir.] scp <arquivo>.tar.gz www2: | Copia o arquivo para a máquina de produção |
| [outro dir.] ssh www2 | "Loga" na máquina de produção |
| [www2] tar xzf <arquivo>.tar.gz | Descompacta o arquivo |
| [www2] diff -r <sistema> /home/<sistema> | Identifica as diferenças entre as versões |
É possível fazer um diff entre um arquivo no alfa e na produção através do seguinte comando:
ssh {remote_host} cat {remote_file} | diff {local_file} -
Então, por exemplo, para ver a diferença entre o script lista.lua do alfa e o lista.lua da produção, basta fazer:
ssh prod cat /home/sapolio/scripts/lista.lua | diff lista.lua -
É possível fazer um diff entre um diretório (e subdiretórios) no alfa e na produção rodando o diff_dif.sh, script do sintra.
O primeiro parâmetro é o diretório a ser comparado. O segundo parâmetro é o diretório a ser excluído da comparação (opcional).
./diff_dir.sh [DIRETÓRIO] [DIRETÓRIO A SER EXCLUÍDO]
O problema é que, para o idioma Português do Brasil no Ubuntu (6.06 LTS, 7.04), a codificação de caractere definida como padrão foi a UTF-8, quando o padrão mais comum no país é o ISO-8859-1. O resultado prático dessa divergência é que alguns caracteres acentuados -- lidos de arquivos gravados em ISO-8859-1, mas indevidamente interpretados como UTF-8 -- não são exibidos corretamente, muitas vezes aparecendo como uma interrogação ou outros símbolos estranhos.
Para corrigir o problema, basta definir a codificação de caractere padrão como ISO-8859-1 no locale para Português do Brasil (pt_BR).
Reproduza os passos a seguir:
Certifique-se que os seguintes pacotes estejam instalados: language-pack-pt e language-pack-pt-base
Para instalar, você pode usar o Gerenciador de Pacotes Synaptic (gráfico), ou executar esta linha de comando (requer sudo / permissão de root):
$ sudo apt-get install language-pack-pt language-pack-pt-base
Edite o arquivo /var/lib/locales/supported.d/local e adicione a seguinte linha no início do arquivo (requer sudo / permissão de root):
pt_BR.ISO-8859-1 ISO-8859-1
Edite o arquivo /etc/locale.alias e adicione a seguinte linha (requer sudo / permissão de root):
pt_BR pt_BR.ISO-8859-1
Edite o arquivo /etc/environment e altere o parâmetro LANG da seguinte forma (requer sudo / permissão de root):
LANG="pt_BR"
Atualize os locales, com o comando (requer sudo / permissão de root):
$ sudo dpkg-reconfigure locales
Para ativar imediatamente as novas configurações no ambiente gráfico, reinicie o seu X, com a seguinte combinação de teclas:
[Ctrl] + [Alt] + [Backspace]
Abra o arquivo ~.bashrc (no seu home) e adicione a seguinte linha no final do arquivo [NOTA: para mim, este passo não foi necessário]:
source /etc/environment