Lastly, look at the running network interface state, which should indicate that
br1
has an IP address,
enp8s0f1
does not, and both are up. At this point, the tenant VM should be able to reach the external network.
Working with kinit
When a user logs into a system running in the secure service mode, the login procedure uses kinit and the user's
keytab to assign a Kerberos ticket granting ticket to the user. If the user stays logged into the system for too long,
this ticket may expire and the user may lose access to HDFS and other services. To see the status of the ticket
granting ticket, including when it was granted and when it will expire, the user may use the following command:
$
klist
Ticket cache: FILE:/tmp/krb5cc_10003
Default principal: crayusr@local
Valid starting Expires Service principal
10/23/2017 07:55:16 10/30/2017 07:55:16 krbtgt/local@local
renew until 11/22/2017 06:55:16
To obtain a new ticket granting ticket the user may log out and log back in, or issue the following command:
$
kinit -A -k -t /security/secrets/username.keytab
For users logged into tenant VMs, there is no ticket granting ticket generated for the tenant VM login session. A
ticket granting ticket is generated each time a command is run on a physical node through the tenant proxy
mechanism.
Logs
●
Urika-GX Tenant Management Logs -
utp-server
logs are located in the
/var/log/utp/utp.log
file.
These logs are only accessible to the administrator and have a default log level of
DEBUG
●
Urika-GX Security Manager Logs - The default log file for the
usm-sync-users
and
usm-recreate-
secret
commands is located at
/var/log/usm/urika-secret-manager.log
. These logs have a
default log level of
INFO
. The default log level and format can also be optionally reconfigured by
modifying
/opt/cray/urika-secret-manager/default/logconf.d/usm-logging-dict.json
8.4.1
Save and Restore Tenant Information
Prerequisites
This procedure requires root privileges on the SMW.
About this task
When making changes to Urika-GX that result in swapping, re-deploying or wiping out the contents of tenant VM
host nodes or the node on which HDFS name nodes reside (NID 0), critical tenant data can be destroyed,
resulting in loss of the tenant VM environment or users' HDFS data.
The procedure described here provides a means for backing up this tenant data and reconstructing the affected
tenants so that HDFS data and the tenant VM environment are preserved.
Troubleshooting
S3016
254
