Arch Linux User Repository

Eu adotei o pacote e o atualizei para incluir as alterações feitas pelo @esauvisky e outros usuários uma vez que elas corrigiram as falhas para mim.

No entanto eu recomendo VEEMENTEMENTE que vocês utilizem o pacote warsaw-bin ao invés deste aqui, pois o processo de instalação, configuração e atualização são muito menos complexos e muito mais estáveis.

Oi pessoal,

Eu segui os passos comentados pelo @esauvisky e não funcionou. Eu acabei de instalar o Arch do zero porque comprei um SSD novo. Alguém tem uma luz?? Vlw

Os erros:

[rodrigo@arch warsaw]$ cd /usr/lib/warsaw [rodrigo@arch warsaw]$ rm ld-linux-x86-64.so.2 && ln -s /usr/lib/ld-linux-x86-64.so.2 . rm: cannot remove 'ld-linux-x86-64.so.2': Permission denied [rodrigo@arch warsaw]$ rm libc.so.6 && ln -s /usr/lib/libc.so.6 . rm: cannot remove 'libc.so.6': Permission denied [rodrigo@arch warsaw]$ rm libpthread.so.0 && ln -s /usr/lib/libpthread.so.0 . rm: remove write-protected regular file 'libpthread.so.0'? ln: failed to create symbolic link './libpthread.so.0': File exists [rodrigo@arch warsaw]$ rm libdl.so.2 && ln -s /usr/lib/libdl.so.2 . rm: cannot remove 'libdl.so.2': Permission denied

● warsaw.service - Warsaw Technology (core) Loaded: loaded (/usr/lib/systemd/system/warsaw.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Sat 2018-04-21 12:26:56 -03; 13min ago Process: 4150 ExecStart=/usr/bin/warsaw/core (code=exited, status=127) Process: 4145 ExecStartPre=/usr/bin/warsaw/wscertmgr (code=exited, status=0/SUCCESS) Main PID: 4150 (code=exited, status=127)

abr 21 12:26:56 arch systemd[1]: Starting Warsaw Technology (core)... abr 21 12:26:56 arch wscertmgr[4145]: Verifying... abr 21 12:26:56 arch wscertmgr[4145]: Ok! abr 21 12:26:56 arch core[4150]: /usr/bin/warsaw/core: relocation error: /usr/local/lib/warsaw/libpthread.so.0: symbol __libc_dl_error_tsd, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference abr 21 12:26:56 arch systemd[1]: warsaw.service: Main process exited, code=exited, status=127/n/a abr 21 12:26:56 arch systemd[1]: warsaw.service: Failed with result 'exit-code'. abr 21 12:26:56 arch systemd[1]: Failed to start Warsaw Technology (core).

Segui os passos do esauvisky, e funciona lindamente! Que alívio poder usar o netbanking no Arch, sem precisar usar VM...

Só um detalhe: o wsatspi só começa a rodar, pra mim, depois que eu vou até o site da Diebold e faço a finalização da instalação do guardião. Até este momento final não tem nenhum processo wsatspi rodando.

Mas enfim, o importante é que funciona :-)

Enorme abraço ao esauvisky e demais pessoas que descobriram os hacks pra fazer isso funcionar, faz mais de ano que tento fazer mas sem sucesso.

[EDIT 1] Por algum motivo que ainda não entendi, mesmo tendo iniciado o serviço warsaw no systemd eu precisei reiniciar a máquina pra que ele funcionasse corretamente. Talvez ele seja bem "crica" no que diz respeito a primeiro iniciar o processo como root, depois com o usuário logado. Daí o aplicativo no site da Diebold conseguiu identificar que estava instalado.

++++ Passo-a-Passo Atualizado ++++

(15 de abril de 2018, por @esauvisky)

Siga as instruções abaixo antes de postar algum problema que estiver tendo com este pacote! ;)

1: Instale este PKGBUILD

2: Execute o workaround do @ArchHero para utilizar bibliotecas nativas:

$ cd /usr/lib/warsaw
# rm ld-linux-x86-64.so.2 && ln -s /usr/lib/ld-linux-x86-64.so.2 .
# rm libc.so.6 && ln -s /usr/lib/libc.so.6 .
# rm libpthread.so.0 && ln -s /usr/lib/libpthread.so.0 .
# rm libdl.so.2 && ln -s /usr/lib/libdl.so.2 .

3: Defina o atributo do diretório /usr/lib/warsaw como append-only:

# chattr +a /usr/lib/warsaw/

4: Ative e inicie o serviço do warsaw e execute core como usuário:

# systemctl enable warsaw
# systemctl start warsaw
$ /usr/bin/warsaw/core

• Alternativamente você pode só dar enable no serviço e reiniciar o computador.

5: Verifique que os processos relacionados ao warsaw estão rodando corretamente:

$ ps aux | grep warsaw

• Você deve observar no mínimo 1 [...]/warsaw/core rodando como root e pelo menos um [...]/warsaw/wsatspi rodando como usuário.

• Pode haver um core rodando como usuário também ou múltiplas instâncias de algum dos binários.

6: Certifique-se que seu navegador está configurado corretamente:

• No caso do Chrome, é necessário ativar a flag: chrome://flags/#allow-insecure-localhost

• No caso do Firefox, pode ser necessário clicar no ícone ao lado do cadeado e permitir a execução de applets flash.

7: Abra a página do seu banco e veja se está funcionando.

• Se não funcionar, abra a página (http://www.dieboldnixdorf.com.br/warsaw) no seu navegador, selecione seu banco e aguarde a atualização.

8: Se a página acima não conseguir identificar o warsaw, informando que não está instalado, continue o passo-a-passo abaixo. Caso tenha funcionado, pule para o passo nº 10 para arrumar um bug no autostart do XDG.

9: Uma das coisas que pode estar fazendo com que o warsaw não funcione é SYN flooding nas portas que o warsaw usa (30800 e 30900). Para detectar, tente abrir a página do banco ou do site acima e verifique o log da kernel:

$ dmesg

• Se você estiver vendo várias instâncias da mensagem a seguir, significa que isto pode ser o problema:

  TCP: request_sock_TCP: Possible SYN flooding on port 30900. Sending cookies.  Check SNMP counters.
  

• Para resolver temporariamente, execute os seguintes códigos, e veja se o problema persiste:

  # sysctl net.ipv4.tcp_syncookies=1
  # sysctl net.ipv4.tcp_synack_retries=5
  # sysctl net.ipv4.tcp_max_syn_backlog=65536
  

• Para resolver permanentemente, crie um drop-in no diretório /etc/sysctl.d/, conforme as novas regras de configuração de parâmetros da kernel:

  # nano /etc/sysctl.d/60-warsaw.conf
  

  • Adicione o conteúdo abaixo no arquivo acima:

    net.ipv4.tcp_syncookies=1
    net.ipv4.tcp_synack_retries=5
    net.ipv4.tcp_max_syn_backlog=65536
    

10: Arrume um bug no .desktop do autostart do XDG, que pode fazer com que múltiplas instâncias dos processos core e wsatspi fiquem dando respawn:

# nano /etc/xdg/autostart/warsaw.desktop

• Substitua, no arquivo acima, a linha:

  X-GNOME-AutoRestart=true
  

• Por:

  X-GNOME-AutoRestart=false
  

• Reinicie o computador.

Pessoal, fiz exatamente o que o esauvisky sugeriu e funcionou perfeitamente. Instalem o pacote pelo AUR, substituam as bibliotecas do warsaw pelas do sistema, façam as bibliotecas como append-only e habilitem o serviço.

Pessoal, referente ao meu comentário de 2018-03-30 11:33, informo que o warsaw passou a funcionar aqui. A única coisa que fiz seguir a dica do @esauvisky abaixo (2018-04-01 13:45), mas não posso afirmar se foi isso que resolveu pois só havia uma instância do core rodando.

Finalmente não preciso mais da vm do Mint para acessar o Itaú.

EDIT: Lembrei-me que fiz uma atualização completa do sistema antes de acessar o banco. Foram mais de 150 atualizações. Pode ter a ver.

Estava tendo um minor-issue onde o login nem sempre funcionava, me obrigando a reiniciar o serviço (systemctl restart warsaw) para que funcionasse de novo.

Descobri que quando isto acontecia, haviam múltiplas instâncias (tipo mais que 3) de core e wsatspi rodando simultaneamente, portanto o bug origina-se em /etc/xdg/autostart/warsaw.desktop que tem uma flag para permitir auto-reinicialização no Gnome.

Quem tiver o mesmo problema, é possível solucionar o bug editando o arquivo e trocando: X-GNOME-AutoRestart=true por X-GNOME-AutoRestart=false.

Segui os passos descritos aqui e consegui subir o warsaw, as portas 30800 e 30900 estão abertas... porém, tanto o Itaú como a página de diagnóstico do warsaw continuam dizendo que ele não está instalado. Alguma ideia? Tive que instalar o Mint numa vm para poder usar o Itaú.

@gerson Uma alternativa para não setar o diretório inteiro como append-only, é copiar as bibliotecas (em vez de criar links simbólicos) e tornar estas cópias como imutáveis chattr +i, mas por sua vez isto traz um outro inconveniente, que é que atualizações das bibliotecas no sistema não serão repassadas para o warsaw. Eu só optei pelo primeiro caminho porque me parece mais KISS e um pouco mais robusto.

Todas estas modificações e alternativas podem ser facilmente embutidas em um PKGBUILD, especificamente no pre_install e post_install, no entanto, é praticamente impossível fazer o pacote cumprir com as diretrizes de empacotamento do Arch Linux usando estes workarounds que estamos usando.

A única forma que eu consigo ver seria extrair os arquivos do instalador um-a-um, instalar eles manualmente em /usr/lib, criar links para todas as bibliotecas (e não somente as 4 ou 5 que fazem o warsaw dar coredump), criar as unidades do systemd e autostart do zero, e assim por diante. Olha, é trabalho! E mesmo assim estaríamos quebrando uma ou outra regrinha por causa da porcaria que é este software per se.

Troquei de Desktop e acabei de fazer uma nova instalação do Arch. Confirmo que tive que seguir o passo-a-passo do @esauvisky para funcionar. Fazendo isso, está redondo. Não poderíamos colocar este passo-a-passo no PKGBUILD?

Dúvida: num possível update futuro, o atributo de append-only (chattr +a) não poderia causar algum bug? Talvez no PKGBUILD tenhamos que fazer um chattr -a antes, deixar atualizar os arquivos, e depois refazer o passo-a-passo do @esauvisky.

Comprei um SSD, instalei o Arch do zero. Eventualmente, chegara a hora de instalar esta porcaria.

Resultado: segui meu passo-a-passo nos comentários daqui, em 3 minutos consegui abrir com sucesso a página do banco, sem sequer precisar reiniciar o sistema. Então posso confirmar que ainda está funcionando :)