Eu também não detectei nenhuma diferença entre os três métodos de instalação.
A propósito, os três métodos de instalação atualmente são estes:
1) Instalar o instalador
HDA_BB, que por sua vez instalará o módulo de segurança Warsaw pra você.
2) Instalar o módulo de segurança Warsaw diretamente, usando o pacote
DEB (o link ao lado é para a versão de 64 bits).
3) Instalar o módulo de segurança Warsaw diretamente, usando o shell script
RUN (o link ao lado é para a versão de 64 bits).
O programa DPKG instala manualmente um pacote DEB, porém não analisa se esse pacote possui dependências, ou seja, não analisa se, para funcionar, esse pacote precisa ser instalado junto com outros pacotes DEB dos quais ele depende. Para instalar qualquer pacote DEB na linha de comandos (terminal do shell do Linux)
resolvendo as dependências desse pacote DEB, você precisa usar o programa
GDEBI, ao invés de usar o DPKG. Caso não tenha o GDEBI, instale-o com este comando:
sudo apt-get install gdebi -yApós isso, para instalar um pacote DEB no terminal do shell basta executar o comando
sudo gdebi /caminho/para/o/pacote.deb, portanto se você salvou um arquivo como p.ex.
hda-bb_0.1_all.deb em um local como p.ex.
/home/fulano/Downloads/, o comando de instalação desse pacote DEB será:
sudo gdebi /home/fulano/Downloads/hda-bb_0.1_all.debO mesmo vale para o caso de você decidir instalar manualmente o pacote DEB do módulo de segurança Warsaw. Portanto, se por exemplo você pegar o arquivo
warsaw_setup64.deb e salvá-lo em
/home/fulano/Downloads/, este será o comando para instalar manualmente esse pacote DEB no terminal do shell do Linux, já resolvendo as dependências do pacote:
sudo gdebi /home/fulano/Downloads/warsaw_setup64.debJá no caso do arquivo de script RUN, para instalá-lo você precisa primeiro torná-lo executável, o que se consegue executando-se o comando
sudo chmod +x /caminho/para/o/arquivo.run, portanto se o arquivo tiver um nome como por exemplo
warsaw_64_installer.run e você o salvar em
/home/fulano/Downloads/, o comando para torná-lo executável e então instalá-lo será este:
sudo chmod +x /home/fulano/Downloads/warsaw_64_installer.run && sudo /home/fulano/Downloads/warsaw_64_installer.runDurante a instalação do módulo Warsaw por qualquer um desses métodos, é necessário
deixar todos os navegadores fechados.
=> Desinstalar o HDA_BB é fácil. Basta executar este comando, no terminal do shell:
sudo apt-get purge hda-bbDesinstalar o Warsaw instalado via pacote DEB também é fácil. Basta executar este comando, no terminal do shell:
sudo apt-get purge warsawJá para desinstalar o Warsaw instalado via script RUN, é necessário executar o desinstalador dele. O comando é este:
sudo /usr/bin/warsaw_uninstallApós cada instalação ou desinstalação, é recomendável reiniciar o sistema.
O que eu já fiz, até agora...
Eu já instalei o módulo de segurança Warsaw por intermédio de cada um dos três métodos acima citados. Nenhum funcionou para o meu caso: a página
https://seg.bb.com.br/home.html continua me informando que não possuo o módulo de segurança Warsaw, ao acessar a página
http://www.dieboldnixdorf.com.br/warsaw (da empresa que comprou a GAS Tecnologia, desenvolvedora do Warsaw) e informar que meu banco é o Banco do Brasil, também recebo a informação de que meu sistema não possui o módulo Warsaw. Mas eu sei que o Warsaw está instalado, pois o
daemon (o "serviço", o processo residente na memória do sistema) do Warsaw é o arquivo binário executável
core, que se encontra em
/usr/local/bin/warsaw/ (caminho completo:
/usr/local/bin/warsaw/core), e esse
daemon está em execução (ou seja: uma cópia do arquivo
core encontra-se presente na memória RAM que está sendo usada pelo sistema operacional Linux). Eu inclusive executei o comando abaixo, para interromper o
daemon do Warsaw:
sudo service warsaw stopDaí executei este outro comando, para iniciar novamente o
daemon / serviço Warsaw:
sudo service warsaw start...e então executei o comando:
ps -ef |grep -i warsaw |grep -v grep...que me mostrou que de fato existe um
daemon / serviço
warsaw executando o arquivo binário executável
core a partir de
/usr/local/bin/warsaw (o arquivo binário
core está residente na memória do computador), portanto o Warsaw está em execução. Consequentemente, se aqueles dois websites estão informando que o Warsaw não está instalado é porque
esses websites não estão conseguindo se comunicar com o daemon que se encontra em execução no meu sistema, e isso sinaliza um problema (ou dificuldade) ou no daemon ou em algum componente do daemon: pode ser uma biblioteca faltando; uma configuração errada dentro desse
daemon; alguma biblioteca funcionando diferentemente do que devia e, por isto, impedindo que, por exemplo, uma conexão websocket seja estabelecida entre o
daemon e o servidor do banco;
daemon sendo bloqueado por outro processo etc.
Quando executo o programa HDA_BB, ele me informa que o módulo está de fato instalado e em execução, porém dá aquele erro de websocket / soquete que tantos outros usuários estão vivenciando (eu, inclusive). Meu sistema é o XUbuntu versão 16.04 de 64 bits e estou usando o kernel estável 4.7.10 (número completo da versão: 4.7.10-040710-generic). Como o
daemon do warsaw está em execução mas mesmo assim estou tendo esse problema, pensei na possibilidade de isso estar relacionado a alguma incompatibilidade do kernel (ou do
iptables que executa o componente
netfilter do kernel) com essa versão do Warsaw, por isto instalei o kernel versão 4.4, que é nativo desse XUbuntu que estou usando. Infelizmente, não fez diferença nenhuma.
Também experimentei instalar versões anteriores (antigas) do Warsaw, mas nenhuma funcionou.
Como mudar de kernel não fez diferença, experimentei mexer no
iptables (o firewall interno do Linux): percebi que quando o script
/usr/local/bin/HDA_BB/HDA_BB é executado, ele testa a conectividade do websocket executando o comando
telnet na porta
30900 do endereço IP
127.0.0.1 (codinome
localhost). Então executei este comando, no terminal do shell:
telnet 127.0.0.1 30900...e o resultado foi "connection refused" (conexão recusada). Daí pensei: "Mmmm... É por isso que o programa HDA_BB informa que o websocket não está conectado: é porque a porta 30900 está fechada. Como o módulo Warsaw (o arquivo binário
core) tenta usar essa porta 30900, mas não consegue, o HDA_BB informa esse problema".
Como dentro do arquivo
/usr/local/bin/HDA_BB/HDA_BB há uma linha com o comando
echo open 127.0.0.1 30800, resolvi executar este comando que usa o telnet para testar a conectividade da porta TCP nº 30800 no endereço IP 127.0.0.1:
telnet 127.0.0.1 30800...e, para minha surpresa, o telnet confirmou que a porta 30800 está aberta (antes de você instalar o Warsaw, essa porta fica fechada, mas com a instalação do Warsaw essa porta passa a ficar aberta). Então tive a ideia de usar o
iptables para redirecionar para a porta 30800 todos os pedidos que chegarem à porta 30900. Você faz isso executando este comando, no terminal do shell:
sudo iptables -t nat -A OUTPUT -p tcp -d 127.0.0.0/8 --dport 30900 -j REDIRECT --to-port 30800Executei novamente o programa HDA_BB e... tadá! O programa mostrou o "sinal verde" para o item "Socket" (conectividade do websocket "ok").
...mas alegria de pobre dura pouco, rs.
Apesar de esse meu artifício ter funcionado para "enganar" o programa HDA_BB, pelo visto a porta 30900 não é a única usada pelo Warsaw para estabelecer uma conexão websocket (o que inclusive reforça ainda mais o meu receio em usar esse módulo, diga-se de passagem... Detesto programas "obscuros", que não tenho como saber como funcionam porque são programas compilados, proprietários, a cujo código-fonte eu não tenho acesso...
).
Bom, enfim: dei essa volta toda e,
por enquanto, ainda não consegui fazer esse módulo de segurança funcionar.
Por ora, o que está me salvando é que instalei o
VirtualBox para Linux, em seguida criei uma máquina virtual Linux genérica, baixei o
ISO do Android 4.4, usei esse ISO para instalar o Android 4.4 na máquina virtual, daí dei boot nesse "Android virtualizado", instalei o
aplicativo do BB nesse Android,
e-pronto (eu sacaneando a propaganda do Banco do Brasil...
): estou usando o notebook com XUbuntu Linux para acessar o Banco do Brasil via aplicativo instalado no Android virtualizado. Claro que isso está longe de ser uma solução, mas é um paliativo recomendado a quem por ora está como estou: sem acesso via navegador.
Como
por enquanto o módulo de segurança Java do Banco do Brasil continua funcionando (continua ativo no website do Banco do Brasil), usar um navegador que dê suporte ao
plugin NPAPI do JRE (popularmente conhecido como "
plugin Java") possibilita que, por ora, o usuário possa continuar acessando sua conta corrente via módulo de segurança Java. Como a partir da versão 52 o Firefox deixou de dar suporte a plugins de arquitetura NPAPI, não dá pra usar essa versão do navegador. Porém, pode-se obter o
Firefox versão 51, de 64 bits para acessar sua conta corrente via Internet, já que essa foi a última versão do Firefox a dar suporte ao plugin NPAPI do JRE. Após baixar o arquivo comprimido
firefox-51.0.tar.bz2, use o terminal do shell para acessar a pasta em que você salvou esse arquivo e então execute este comando de descompactação:
sudo tar -xvf firefox-51.0.tar.bz2Nessa mesma pasta surgirá uma subpasta
firefox. Use o terminal mesmo para entrar nela. Porém,
antes de executar o Firefox 51 pela primeira vez, execute seu Firefox atual, para poder desativar a atualização automática, daí acesse o endereço
about:preferences#advanced, clique na opção
Atualizações, marque a caixa
Nunca verificar (não recomendado: risco de segurança) e, por fim,
feche o Firefox.
Após fazer isso (para evitar que o Firefox versão 51 - que funciona com o plugin NPAPI do JRE - automaticamente se atualize para a versão mais recente - que não suporta plugins NPAPI), retorne ao terminal do shell, que deverá estar conectado à pasta do Firefox 51, e então execute este comando (ele inicializará o Firefox versão 51):
./firefoxO uso do
./ é importante para informar que você quer executar especificamente o arquivo binário
firefox que se encontra dentro da pasta que você acessou via terminal (a pasta do Firefox 51).
Se você executar o Firefox 51 com a "atualização automática" desabilitada, você conseguirá usar o Firefox 51 para acessar o website do Banco do Brasil, daí o website do banco fornecerá o
applet Java para o Firefox 51 e o Firefox 51 conseguirá executar esse
applet, já que o Firefox 51 é capaz de executar o plugin Java.
Enquanto o applet (módulo de segurança) Java continuar hospedado no website do Banco do Brasil, você continuará podendo usar o Firefox 51 para acessar sua conta pelo método "antigo" / tradicional, ou seja: via Java (sem precisar do Warsaw).
Espero que alguém descubra como resolver esse problema (já que relatei esse problema para o Banco do Brasil, mas o "maravilhoso" suporte técnico está há mais de 1 semana sem se manifestar, tampouco sem resolver o problema). Se eu conseguir resolver isso, publico aqui.
