1. HOME
  2. MCP Q4`18 Release Notes
  3. Maintenance updates
  4. 2019.2.9
  5. Addressed issues
  6. DriveTrain
  7. Issues resolutions requiring manual application

Issues resolutions requiring manual application

Issues resolutions requiring manual application

Note

Before proceeding with the manual steps below, verify that you have performed the steps described in Apply maintenance updates.

[34894] Apache service failure to start on proxy nodes after reboot

Fixed the issue with the apache2 service failing to start after rebooting of any proxy node. The issue occurred due to Apache requiring the certificates placed on the GlusterFS volume, which might not have been mounted before the apache2 service start. To apply the issue resolution, set the dependency between the GlusterFS volume mount and the apache2 service explicitly as described below.

To apply the issue resolution:

  1. Log in to the Salt Master node.

  2. In classes/cluster/<cluster_name>/openstack/proxy.yml, add the following pillar:

    parameters:
  ...
  apache:
    server:
      wait_for_service:
        - srv-salt-pki.mount
  ...

  3. Apply the changes to Apache on the proxy nodes:

    salt 'prx*' saltutil.refresh_pillar
salt 'prx*' state.apply apache.server

[34406] Sphinx UI accessibility without authorization

Fixed the issue with the Sphinx providing Reclass variables without authorization. The issue occurred due to NGINX being configured without a basic authorization for reclass_doc.

To apply the issue resolution:

  1. Log in to the Salt Master node.

  2. Generate a Sphinx UI password and add it to classes/cluster/<cluster_name>/infra/secrets.yml using the following parameter as described in MCP Operations Guide: Manage secrets in the Reclass model.

    parameters:
  _param:
    ...
    sphinx_proxy_password_generated: <generated_password>
    ...

  3. Apply the changes to NGINX and Sphinx:

    salt -C 'I@sphinx:server and I@nginx:server' saltutil.refresh_pillar
salt -C 'I@sphinx:server and I@nginx:server' state.apply nginx

[28442] Wrong default value for umask causing an exception

Fixed the issue with a wrong default value set for umask, which caused the Cannot access storage file: Permission denied exception when running the salt.control state if umask was set to 027.

To apply the issue resolution:

  1. Log in to the Salt Master node.

  2. Apply the following state:

    salt -C "I@salt:control" state.apply salt.control
updated: 2021-04-17 10:13