Good morning everybody. Has anyone witnessed such a situation?
Thanks.
The customer created a Subnet and implemented a proxy server.
Changed IP of Qlik Sense Central and Rim Node servers.
The first change took place in the single-Node DEV environment.
After the migration, after a few days, the HUB can no longer authenticate the users.
We applied a proxy configuration on the server and other actions were performed by the client's Infra team.
I suggested bypassing the proxy to Qlik's licensing addresses.
Obs. The customer did not present what actions it performed.
We edited the file %Program Files% \ Qlik \ Sense \ ServiceDispatcher \ services.conf
I suggested proxy configuration in this file and provided the necessary documents for the procedure.
Example: -proxy-uri = http: //myproxy.example.com: 8888
The Infra team took charge of this issue and did not report to us what actions were taken.
The DEV environment returned to work and performed the migration of the Prod environment to a new Subnet.
The day after the change we were called with another behavior presented in the PROD environment.
After a few hours the Hub user receives a notification that they do not have an pass license.
This behavior occurs on average 3x a day, we found that 80% of the time it is enough to restart the dispatcher service in Rim Node for the environment to work again.
There is no firewall enabled on servers for Domain environment.
Tests on the central Node and proxy configuration were performed in the same way as they were done in the DEV environment.
The addresses lef1.qliktech.com, lef2.qliktech.com, lef3.qliktech.com, lef4.qliktech.com and license.qlikcloud.com were tested on the servers as follows
No proxy settings in browsers status: No Access.
Telnet on port 443 working.
So far we have not been able to identify the reason for what, the problem only occurs after a few hours and not persistently.
The only attempt to change the proxy configuration environment mentioned above.
We have not observed any IP calls and we have not found any errors in the DNS hosts' IPs.
O cliente criou uma Subnet e implementou um servidor de proxy.
Alterou o IP dos servidores de Qlik Sense Central e Rim Node.
A primeira mudança ocorreu no ambiente de DEV com somente um Nó.
Após a migração, passados alguns dias, o HUB não pode mais autenticar os usuários e fomos acionados.
Realizamos a configuração de proxy no servidor e outras ações foram realizadas pela equipe de Infra do cliente.
Sugeri que fosse feito um bypass no proxy para os endereços de licenciamento da Qlik.
Obs. O cliente não apresentou as ações realizadas.
Editamos o arquivo %Program Files%\Qlik\Sense\ServiceDispatcher\services.conf
Sugeri a configuração de proxy neste arquivo e forneci a documentação necessária para o procedimento.
Exemplo: -proxy-uri=http://myproxy.example.com:8888
A equipe de Infra tomou a frente desta questão e não nos reportou quais ações foram realizadas.
O ambiente de DEV voltou a funcionar e realizaram a migração do ambiente de Prod para a nova Subnet.
No dia posterior a mudança fomos acionados com um outro comportamento apresentado no ambiente de PROD.
Após algumas horas o usuário do Hub recebe a notificação de que não tem uma licença de acesso.
Esse comportamento ocorre em média 3x ao dia, descobrimos que em 80% das vezes basta reiniciar o serviço de dispatcher no Rim Node para o ambiente voltar a funcionar.
Não existe firewall habilitado nos servidores para ambiente de Domínio.
Testes no nó central e configuração de proxy foram realizados da mesma forma que foram feitos no ambiente de DEV.
Os endereços lef1.qliktech.com, lef2.qliktech.com, lef3.qliktech.com, lef4.qliktech.com e license.qlikcloud.com foram testados nos servidores da seguinte forma
Nenhuma configuração de proxy nos browsers status: Sem Acesso.
Telnet na porta 443 funcionando.
Não conseguimos até momento identificar o motivo do por quê o problema ocorre somente após algumas horas e não de forma persistente.
A única tentativa de alteração no ambiente foi a configuração do proxy citada acima.
Não observamos nenhuma chamada por IP e não constatamos erros nos IPs dos hosts no DNS.
