Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
VRaducan
Partner - Contributor III
Partner - Contributor III

Qlik Catalog Podman catalog-licenses container

Hi everyone,

we are proceeding with a catalog installation to a customer but we came to a halt.

The O.S. is RHEL8.6 ...

I've installed the pgsql, tomcat and podman, (the service does not instantiate automatically even thought I've run the post isntall .sh script, but this is a minor problem) The problem now is that when I access the Catalog http:/catalogmachine:8080/qdc we got a licenses service error.

I am trying to investigate a bit, before we have the next call with the customer...

From what I can see, watching the licenses container logs in podman we got this error: 

0)","timestamp":"2022-07-15T12:50:09.514513488Z"}
{"caller":"builder.go:439","corrId":"8a78abba-21a3-4e84-aa90-770f8a35721f","error":"dial tcp: lookup \u003cpostgres-server-ip-address\u003e: no such host","level":"error","message":"failed to initiate persistence, retrying in 5 seconds (1)","timestamp":"2022-07-15T12:50:14.514877412Z"}
{"caller":"builder.go:439","corrId":"8a78abba-21a3-4e84-aa90-770f8a35721f","error":"dial tcp: lookup \u003cpostgres-server-ip-address\u003e: no such host","level":"error","message":"failed to initiate persistence, retrying in 5 seconds (2)","timestamp":"2022-07-15T12:50:19.515142913Z"}
{"caller":"builder.go:439","corrId":"8a78abba-21a3-4e84-aa90-770f8a35721f","error":"dial tcp: lookup \u003cpostgres-server-ip-address\u003e: no such host","level":"error","message":"failed to initiate persistence, retrying in 5 seconds (3)","timestamp":"2022-07-15T12:50:24.515371157Z"}
{"caller":"builder.go:439","corrId":"8a78abba-21a3-4e84-aa90-770f8a35721f","error":"dial tcp: lookup \u003cpostgres-server-ip-address\u003e: no such host","level":"error","message":"failed to initiate persistence, retrying in 5 seconds (4)","timestamp":"2022-07-15T12:50:29.515682667Z"}
{"caller":"builder.go:439","corrId":"8a78abba-21a3-4e84-aa90-770f8a35721f","error":"dial tcp: lookup \u003cpostgres-server-ip-address\u003e: no such host","level":"error","message":"failed to initiate persistence, retrying in 5 seconds (5)","timestamp":"2022-07-15T12:50:34.515935538Z"}

Beware that the customer's machine is "locked" and has no access to internet apart from these sites: 

redhat.com
*.qlik.com 
github.com
archive.apache.org

rpm.nodesource.com

registry.npmjs.org

 

It does looks to me that the service is not able to access a postgres server IP.

I am going now through the postgresql configuration and check that...like the pg_hba.conf file in /var/lib/pgsql .... ecc...

And I'll have a look there...meanwhile...I've noticed something else: 

If I launch the container manually from /usr/local/qdc/qlikcore/

(qdc) ./launch_qlikContainers.sh

is not working and goes in timeout because it tries to pull the containers from qliktech-docker-release.jfrong.io/engine:12.722.0... 

and that site it's closed because of the Server's proxy.  (we've already asked them to open for us *.jfrog.io)

Whilst if I go in the root directory:

cd /

and the

cd /tmp/podium/bin/qlikSenseIntegration/ 

(this is the folder where i've downloaded the installer) 

and then launch the

(qdc) ./launchContainers.sh

it works and

(qdc) sudo podman ps

gives me the list of the containers.

.........any thoughts?

It has to pull the container from jfrog before the start? Is that's why is blocked ? 

But then, why when making it start from the download zone where also other files are present the .launch Containers.sh script instantiates the containers, whilst from the installation path it does not? 

Thank You

Vlad 

 

 

Labels (1)
1 Solution

Accepted Solutions
VRaducan
Partner - Contributor III
Partner - Contributor III
Author

Hi Everyone just FIY,

the customer had a proxy as stated earlier.

The problem was the podman containers service which did not get all the proxy configuration from the system (as per stated in the podman official documentation...we've also tried to force the configuration under /usr/share/containers.config but no use)

Solved modifying the pod_qlikContianers.yml file which resides usually in /usr/local/qdc/qlikcore 

Modifying the file and inserting the proxy parameters under LICENSES_CONNECTION_STRING

- name: PROXY URI 

value: http://proxyOfTheCustomer.local:portOfTheProxy/

- name: LICENSES_CONNECTION_STRING
value: host=xx.xx.xxx.xxx port=5432 user=licenses password=xxxxx dbname=licenses sslmode=disable
- name: PROXY_URI
value: http://xxxxxxxxxx.xxxxxxxxx.local:portnumber/

 Thank you everyone.

BR 

V

View solution in original post

10 Replies
Gerald_U
Support
Support

Hello Vlad,

 

Does the server has an internal and external IP address?

If so, you would have to navigate to pod_qlikcontainers.yml and switch the IP address under licenses to the internal IP.

Let me know if that makes a difference.

Thanks,

Gerald 

VRaducan
Partner - Contributor III
Partner - Contributor III
Author

Hi Gerald. the server has got only an internal IP, we are accessing it through VPN and SSH console. 

So we are working from the customer's intranet. 

If this is what you meant. I'll try to vim the qlikcontainer.yml and have a look in there. 

Another question: 

The customer needs to ingest some .xlsx documents from the File System and then output the results on a Qlik Sense Installation. 

They are creating a sharefile on Linux on port 22 (SFTP). No QVD ingestions have to be made from the catalog, so it is not necessari the SMB port right? 

Do the Catalog has some issue in browsing the SFTP fileShare?

If the files are being put on the  SFTP from another user, can the qdc root user which runs the catalog have access to these .xlsx? 

Thanks 

Vlad 

 

VRaducan
Partner - Contributor III
Partner - Contributor III
Author

Another question: 

on the single node installation guide it states: 

Create QVD file share:
o On your C: drive, create a new folder called qvd_repository.
o Right-click your new folder qvd_repository and select Properties.
o Open the Sharing tab and click Share.
o Enter qvd_scanner and click Add.
o Click Share and then Done.
o Open the folder qvd_repository

the customer is Creating an S: drive for QVD ingestion (looks like it is needed), is it possible to use the folder qvd_scanner on another Drive? 

Thanks

Gerald_U
Support
Support

Hello Vlad,

Yes, you should be able to to use the folder qvd_scanner on another Drive.

I don't think that should be an issue.

Gerald

VRaducan
Partner - Contributor III
Partner - Contributor III
Author

OK thank You Gerald.

What about the fileshare on RHEL8? (source folder)

Thanks 

VRaducan
Partner - Contributor III
Partner - Contributor III
Author

Podman Started correctly, 

.jfrog.io unlocked by proxy same error on UI: 

VRaducan_0-1658408241845.png

Checked the pod_qlikcontainers.yml, these are the info:

VRaducan_1-1658408276869.png

The broadcast is different from inet

pod_qlikcontinaers.yml lists the inet address 

VRaducan_2-1658408319558.png

Any help appreciated 

Thank You it is pretty urgent

 

Pg_hba.conf 

VRaducan_3-1658408643450.png

postgresql.conf

VRaducan_4-1658408704172.png

Restarted Podman Service with systemctl and still getting this error:

VRaducan_5-1658408972259.png

dial tcp http://3.219.96.142/....is that another thing to open on proxy? 

 

Gerald_U
Support
Support

The fileshare on RHEL should be fine  as long as the qdc root user which runs the catalog have access to these .xlsx

This is basic Linux Permissions, it would depend entirely on the permissions configured on the Linux directory.

 

As for the main issue, Please open a case so we can help you troubleshoot the issue live.

 

Thank you,

Gerald

Gerald_U
Support
Support

As for this , Please open a case so we can help you troubleshoot the issue live.

 

Thank you,

Gerald

VRaducan
Partner - Contributor III
Partner - Contributor III
Author

Hi Gerald, ok I'll open a ticket, Btw now the licenses service goes into this error, I think the dial to tcp has been resolved. Still there is something 

{"caller":"sync.go:139","corrId":"6c6a1eb1225e3316:6c6a1eb1225e3316:0000000000000000:1","count":0,"level":"debug","message":"found license(s) for sync","timestamp":"2022-07-22T09:30:14.735637644Z"}
{"caller":"middleware.go:48","corrId":"4d1083b962985441:4d1083b962985441:0000000000000000:1","level":"debug","name":"V1ParametersPost","req.method":"POST","req.url":"/v1/licenses/parameters","timestamp":"2022-07-22T09:30:15.778098709Z"}
{"caller":"handler.go:43","corrId":"4d1083b962985441:4d1083b962985441:0000000000000000:1","errorMessage":"invalid license error, no license found, tenant not found","errorType":"LICENSES-ForbiddenRequest","level":"info","statusCode":403,"timestamp":"2022-07-22T09:30:15.778447177Z"}
{"audience":"","caller":"middleware.go:61","corrId":"4d1083b962985441:4d1083b962985441:0000000000000000:1","level":"info","message":"http request","name":"V1ParametersPost","req.method":"POST","req.url":"/v1/licenses/parameters","res.statusCode":"403","subType":"","tenant":"","timestamp":"2022-07-22T09:30:15.780505754Z","userAgent":"okhttp/3.11.0"}
{"caller":"middleware.go:48","corrId":"41f6f135272b5c82:41f6f135272b5c82:0000000000000000:1","level":"debug","name":"V1LicensesDefinitionPut","req.method":"PUT","req.url":"/v1/licenses/definition","timestamp":"2022-07-22T09:30:15.792158888Z"}
{"caller":"sync.go:139","corrId":"2258d15ce4f66aa5:2258d15ce4f66aa5:0000000000000000:1","count":0,"level":"debug","message":"found license(s) for sync","timestamp":"2022-07-22T09:30:24.736124293Z"}
{"caller":"sync.go:139","corrId":"147b8862cf3ee4ea:147b8862cf3ee4ea:0000000000000000:1","count":0,"level":"debug","message":"found license(s) for sync","timestamp":"2022-07-22T09:30:34.736601995Z"}