Debugging and Troubleshooting
Click here to see this page in full context


Debugging and Troubleshooting

Why do I see this error while executing docker-compose up command?
"yaml: line 6: did not find expected key"Why do I see this error while executing docker-compose up command?
"yaml: line 6: did not find expected key"

Cause: Issue with syntax of the docker-compose.yml file.

Solution: Correct the docker-compose.yml file. The easiest way would be to copy and paste the yml content from Jira connector Github as is. Alternatively, use the syntax validators yamllint on your linux machine or the online yaml syntax validator to correct the yaml syntax.

Why do I see this error when I execute docker-compose up command with valid YAML file?
 “Error response from daemon: manifest for <image-name:tag> not found: manifest unknown: manifest unknown"Why do I see this error when I execute docker-compose up command with valid YAML file?
 “Error response from daemon: manifest for <image-name:tag> not found: manifest unknown: manifest unknown"

Cause: Image mentioned in the docker-compose.yml file is not present on docker hub.

Solution: Verify if the image names used in your local docker-compose.yml file and Jira connector's Github docker-compose.yml file have same image names.
If both of them are correct, check if your host needs proxy to connect with docker hub which could be blocking docker pull operation.

Why do I see the error while fetching custom fields?
"An exception occurred while trying to resolve custom field Id for module VMDR and fields [Custom Field Name]". ERROR- "Cannot proceed further until conflict is resolved."Why do I see the error while fetching custom fields?
"An exception occurred while trying to resolve custom field Id for module VMDR and fields [Custom Field Name]". ERROR- "Cannot proceed further until conflict is resolved."

The presence of two Custom fields with the same name and different field type in your Jira instance leads to this error scenario.
In such a case, you need to configure the Custom Field ID in Ticketing Scheme template for the custom field which has correct field type.


Configure Custom field Id for that custom Field in Ticketing Scheme Template as per below Example.
                "Impact": {
                        "value":"${vuln.impact}",
                        "customFieldId": "customfield_10009"
                    }

You can read more about this in depth at Configurations.

Jira Client logs error as “Field cannot be set. It is not on the appropriate screen, or unknown”Jira Client logs error as “Field cannot be set. It is not on the appropriate screen, or unknown”

Cause: 

  1. The error in Jira connector's Jira client service refers to the default screen scheme.
  2. If any of the custom fields or default fields (eg. description) are not part of this 'Default screen scheme' then, while creating a ticket, the Jira API used to create issue can not find this field and throws the error mentioned above.

Solution

Check the fields for which error is being thrown in the logs.

The Jira Connector throws an error response from the Jira API which contains only field custom field ID.

To identify the corresponding field name, use the following curl call.

Curl call to fetch all the fields in Jira instance

curl --request GET --url '<jira-instance-url>/rest/api/latest/field' --user 'email@email.com:<API-token>' --header 'Accept: application/json' > output.json
  1. output.json created in above curl call contains all the fields in your Jira instance
  2. You can search using custom field ids on this JSON file to find out the field which is in error.

    Now, that you have list of your fields ready with you, Go to jira instance (needs admin login here) 

  3. Navigate to Project setting > Screens.
  4. On this screen click on 'Edit' option infront of 'Default Screen Scheme'. refer below imagedefault screen scheme
  5. On 'Configure Screen Scheme — Default Screen Scheme', click Default Screen.configure screen
  6. Configure Screen' page appears.configure screen page

    The page lists all the field on this screen. We need to add the fields for errors being thrown to this list. To do so, move down to bottom of the page, you can find an option to add field.option screen

  7. Type the field name in it, it should populate the respective field, select the same. refer below image.

Once, all the fields are added to this list. from this point onwords, Jira client should not face the screen related error.

 

After uploading config.json, I observed ‘config.json (Permission denied)’ error in Qualys client Service LogsAfter uploading config.json, I observed ‘config.json (Permission denied)’ error in Qualys client Service Logs

Cause: 

As of Jira connector v1.0.1, passwords provided in config.json are encrypted by Qualys client service. After encryption, the service replaces actual passwords in config.json with a static string saying, "Password has been encrypted".

Default owner of the config.json file is 'app' (Jira connector App user - 555) with permissions rw-r--r-- (644). When the file is uploaded to the docker-volume-path/_date/config/, its owner changes from 'app' (Jira connector App user - 555) to root.

Hence, when Qualys client service tries to replace the 'password' in config.json with static string post encrypting your password, it runs into Insufficient permissions to write into config.json file

Solution:

Provide required permissions to the config.json file at 'docker-volume-path/_date/config/'
dir
Minimum set of permissions required are 706, which you can provide from the Linux terminal
by using the command 'chmod 706 config.json'
On winscp, your permissions matrix for file should look like as follows
config json properties

Qualys Client Error | java.io.IOException: No space left on deviceQualys Client Error | java.io.IOException: No space left on device

Cause:
The host running JIra Connector has insufficient disk space.

Solution:

Use the command df -h to check for availalbe disk space. We recommend a minimum 30GB free space to run the Jira Connector application smoothly. To clear space, delete old log files from the 'logs' directory at regular intervals.

KnowledgeBaseService getFirstQid(). Caused by : Could not get a resource from the pool redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the poolKnowledgeBaseService getFirstQid(). Caused by : Could not get a resource from the pool redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool

Cause: 
The redis host information is not correctly configured in docker-compose.yml.
The 'SPRING_REDIS_HOST' field under 'environment' should be configured with the host IP where redis is running (the host on which Jira connector containers are spinning).

Solution: 

Correct the redis host configuration in docker-compose.yml as highlighted in below sample.

Sample - docker-compose.yml

version: "3.7"
services:
    qualys-client-service:
        image: qualys/qualys-client-for-jira-integration:1.1.0
        networks:
            - qualys-jira-connector
        volumes:
            - qualys-jira-volume:/opt/qualys/common/jiraconnector/  
        environment:
            - SPRING_REDIS_HOST=10.10.10.10
            - SPRING_REDIS_PORT=6379
            - SPRING_REDIS_USER=default
            - SPRING_REDIS_PASSWORD=JiraConnectorRedisDB
     
    redis-client-service:
        image: qualys/redis-test:1.1.0
        networks:
            - qualys-jira-connector
        ports:
          - 6379:6379
        volumes:
          - qualys-jira-volume:/opt/qualys/common/jiraconnector/db        
   
    jira-client-service:
        image: qualys/jira-client-for-jira-integration:1.1.0
        networks:
            - qualys-jira-connector
        volumes:
            - qualys-jira-volume:/opt/qualys/common/jiraconnector/
        depends_on:
            - qualys-client-service
networks:
    qualys-jira-connector:
       
volumes:
  qualys-jira-volume:

Qualys Client Error | starting userland proxy: listen tcp 0.0.0.0:6379: bind: address already in useQualys Client Error | starting userland proxy: listen tcp 0.0.0.0:6379: bind: address already in use

Cause:

The application and port configured in docker-compose.yml for redis service is already in use.

Solution:

In your docker-compose.yml, change the port mapping configuration in docker-compose.yml file.

Refer the highlighted part in following sample.

Sample

version: "3.7"
services:
    qualys-client-service:
        image: qualys/qualys-client-for-jira-integration:1.1.0
        networks:
            - qualys-jira-connector
        volumes:
            - qualys-jira-volume:/opt/qualys/common/jiraconnector/  
       environment:
            - SPRING_REDIS_HOST=10.10.10.10
            - SPRING_REDIS_PORT=6379
            - SPRING_REDIS_USER=default
            - SPRING_REDIS_PASSWORD=JiraConnectorRedisDB    
    redis-client-service:
        image: qualys/redis-test:.1.1.0
        networks:
            - qualys-jira-connector
        ports:
          - 6379:6379
        volumes:
          - qualys-jira-volume:/opt/qualys/common/jiraconnector/db          
    jira-client-service:
        image: qualys/jira-client-for-jira-integration:1.1.0
        networks:
            - qualys-jira-connector
        volumes:
            - qualys-jira-volume:/opt/qualys/common/jiraconnector/
        depends_on:
            - qualys-client-service
networks:
    qualys-jira-connector:       
volumes:
  qualys-jira-volume: