This message may be followed by the login attempt being closed. This means the user is configured with
restricted user access in the user authorization list. The user is not currently permitted to log on to physical nodes.
The user may be authorized for a tenant VM, but not a physical node.
If the user is supposed to have access to physical nodes, then the user must be granted relaxed user access, as
follows:
smw#
ux-tenant-relax username
Kerberos Issues
When a user logs on to a physical node or tries to run commands through the Urika tenant proxy from a tenant
VM, the user may see the following message:
kinit failed: operations requiring kerberos will not work during this session --
please contact your system administrator
In all probability, the login or
utp-launch
attempt itself will succeed, but commands requiring access to HDFS or
to the user's Kerberos keytab file will fail.
To diagnose this, the administrator needs to look in
/var/log/secure
and look for messages coming from the
pam_cray_keytab
PAM module. These will have the string
pam_cray_keytab:
preceding the text of the log
message. Most likely, this may be caused by Kerberos recognizing or finding a keytab file. The log messages will
be similar to the following:
Oct 16 13:34:30 nid00030 sshd[143134]: pam_cray_keytab: user = '<username>', kinit reported: \
'kinit: Client '<username>@local' not found in Kerberos database while getting initial credentials'
Oct 16 13:34:30 nid00030 sshd[143134]: pam_cray_keytab: kinit failed for user '<username>', see previous logs
There may be other errors reported by
kinit
as well. If the logs contain such information, first check whether
there is a keytab currently set up for the user. This can be done by looking for a file named
username
.keytab
in
the
/security/secrets
directory. If that file does not exist, the problem is most likely that the
usm-sync-
users
command has not been re-run to create the user's secrets since the time that user was either added to the
authorized users list or added as a Linux user. Re-run
usm-sync-users
to troubleshoot the problem:
smw#
usm-sync-users
If the file does exist, most likely the user's keytab file has gotten out of sync with what Kerberos assumes as the
user's keytab. In this case, regenerate the user's keytab (and Mesos secrets) by running:
smw#
usm-recreate-secret username
This will generate a new set of secrets for the user and install them.
Note that while the above actions alone will probably fix the Kerberos issue, it will still be needed to restart Urika-
GX services by executing
urika-stop
and then executing
urika-start
to sync up the created Mesos secrets
and give the user access to Mesos for job launch. Since stopping and starting Urika-GX services can cause
running jobs to be killed, schedule that action carefully.
Tenant Management Issues
When the Urika-GX tenant management package is updated, the update procedure attempts to identify
configuration that is out of date without damaging the configuration. If configuration settings are removed in a new
Troubleshooting
S3016
251
