Skip to main content

Miscellaneous

Symptom: Removed the account permissions that are required for restoring permissions.​

Accounts with the Administrators role can by default perform permission management. As a consequence, Administrator users may remove from themselves those permissions that allow permission management.

  • In a situation where all the standard Key Manager accounts have lost the permissions necessary for permission management, it is possible to restore them using a superuser account.

    To restore permission management rights to Key Manager accounts that have a certain role:

    1. Use a superuser account to log into the system via the administrative interface.

    2. In the administrative interface, navigate to the Accounts→Roles page. Click on an existing role to manage its associated permissions.

    3. Check the permission labeled Administer the users, groups and permissions. Click Save to apply the changes for the role. Any account with this role can now be used for permission management.

Symptom: Forgot the superuser password (lost access to the Key Manager system)​

  • It is possible to reset the superuser password using the Key Manager Controller utility.

    1. Gain terminal access to a Key Manager back end

    2. On the Key Manager Server, run the following command (replace username and password with the user name and password you want to set for the superuser account):

      # /opt/sshmgr/bin/ssh-mgr-controller --admin-account=username \
      --admin-account-password=password --admin-account-superuser=yes

      The command creates a new superuser with the specified user name and password. If an account with the specified user name already exists, that account becomes a superuser account, and the account password is set to the specified password.

Symptom: Management job fails due to broadcast message​

  • When running management jobs, Key Manager uses terminal output to determine the outcome of individual actions. Broadcast messages occurring during job execution may cause the job to fail. As with all jobs, the reason of failure can be determined by reviewing the job log. The job-log entry caused by a broadcast message may look something like the following:

    2014-11-15 15:51:52.429860+00:00: Job 1627556 Failed: invalid literal for int()
    with base 10: '\x07\x07\x07Broadcast Message from root (pts/2) on server01 
    Sat Nov 15 16:51:52...\nTHE  SYSTEM server01 IS BEING SHUT DOWN NOW ! ! !\r\n
    Log off now or risk your files being damaged\r\n\r\n2\n'

    You can review the job log to determine the actions that were performed before the job failed, and if desired, you can rerun the job later.

Symptom: Actions on Rocky Linux server or host fail due to account being locked​

  • On Rocky Linux, any newly created accounts have no passwords, and are locked. To unlock newly created accounts, you must assign them a password.
  • Ensure that the Key Manager system time and the IdP time are synchronized.

Symptom: Scrollbars are not visible when using Key Manager​

  • Modern browser scrollbars tend to be hidden, and minimized. To make the scroll bars more visible, you will need to edit the settings of the browser you are using.

    Here is an example how to make the scroll bar more visible on Firefox:

    • To make the scrollbar always visible:

      • Click on the Firefox hamburger menu, and click Settings.

      • Search for the setting Always show scrollbars.

      • Toggle the Always show scrollbars setting on.

      The scrollbar should now be always visible.

    • To make the scrollbar appear larger:

      • In Firefox address bar, write about:config, and press enter.

      • Click Accept the Risk and Continue.

      • Search for widget.non-native-theme.scrollbar.style

      • Click on the associated number, and change the value to something bigger, for example 4.

      Firefox scroll bar should now appear larger.

Symptom: Oracle database error ORA-01804 or ORA-01805:​

  • Ensure the Oracle client Time Zone matches the database.

    To check which timezone file is being used, enter the following command in your oracle database:

    SQL> select *
    from v$timezone_file;
    FILENAME  VERSION     CON_ID

    timezlrg_32.dat       32   0

    To switch the Key Manager timezone file to the same one used by the Oracle database, do the following on each Key Manager server:

    1. Stop the Key Manager processes:

      # supervisorctl stop all

    2. Copy the timezone file from the Oracle database server at ORACLE_HOME\oracore\zoneinfo to Key Manager server directory /opt/sshmgr/.runtime/lib/oracore/zoneinfo

      note

      The oracore directory, and directories and files under it need to be owned and readable by user sshmgr:tectia. Key Manager will use the timezone file with the largest number in the filename from this directory.

    3. Run the upgrade script to update the settings:

      # /opt/sshmgr/sbin/upgrade

    4. Restart the Key Manager processes:

      # supervisorctl restart all

    Make sure all processes run normally - Key Manager should be able to connect to the database normally.