When troubleshooting TempAuth, the first thing you want to do is confirm that you are running TempAuth:

As illustrated in the preceding code snippet, in the [pipeline:main] section of proxy-server.conf, there will be a tempauth entry in the pipeline if TempAuth is in use. If your deployment is using TempAuth and you are troubleshooting auth problems, you'll want to check the rest of the TempAuth configuration.

In addition to the tempauth entry in the pipeline, there should be the tempauth filter section, similar to the one displayed here:

Lines 3-6 in the preceding output define the various users' setup to work with TempAuth. In the preceding example, the user entries follow this format:

User_<account>_<username> = <password> [.<role>]

When attempting to make calls to Swift via the API, the credentials used should match the values in the [filter:tempauth] section of your configuration file:

curl -v -H 'X-Storage-User: test:tester' -H 'X-Storage-Pass: testing' http://swiftproxyserver:8080/auth/v1.0

As demonstrated in the preceding lines of code, you will pass in <account>:<username> into the X-Storage-User header. In our example, we are using the tester user under the test account. If everything works as expected, the output from this curl call will be similar to the output shown here:

You can test Swift by attempting to run GET on the account. To do this, you need to use X-AUTH-Token that was returned in the preceding call as well as X-Storage-Url. With these two values in hand, you can run a curl command similar to the following one:

curl -v -H 'X-Auth-Token: AUTH_tk8c7ae187154749ccb121397f6779f11e' http://127.0.0.1:8080/v1/AUTH_test

The preceding curl command will return an output similar to the output shown in the following screenshot:

We have executed this command against an empty Swift cluster, but it's worth noting the statistics that are returned from this call. X-Account-Object-Count lists the number of objects in this account. The X-Account-Container-Count list displays the number of containers in the account. The X-Account-Bytes-Used command shows the number of bytes used in this account.

If there is a problem with the credentials, you will see an error similar to the following one when you run curl:

Take a note of the 401 Unauthorized error returned from this call. In addition to this, the body returned includes a message explaining that the user's authorization could not be verified. These errors point to the fact that one of the credentials used in the curl call was incorrect. To resolve this issue, verify the credentials set at /etc/swift/proxy-server.conf against the credentials used in the curl call.

For users who utilize the Swift command-line tool, you will typically use a syntax similar to the following syntax:

swift -U test:tester -K testing -A http://127.0.0.1:8080/auth/v1.0/ auth

When this command is executed successfully, you will see an output similar to the one shown here:

Note that the pattern of the user (-U) attribute is <account>:<username>. Suppose that, when you attempt to use the Swift command-line tool with TempAuth, you come across an error similar to the following one:

There are a few settings that you need to check when you come across a 401 Unauthorized error when using the Swift command-line tool. To troubleshoot this error, you need to check the account, username, password, and auth URL being used.

The account and username

When using the Swift command-line tool, you need to pass in the account and the username for the user you are authenticating. For example, to run the Swift list command with authentication arguments passed in on the command line, you would use the following code:

The tool expects user information to be passed as <Account>:<Username>. For example, for an account named test and a username tester, the value passed to the -U argument of the Swift tool would be test:tester. If you omit the account value, you are likely to see the preceding 401 Unauthorized error.

You can pass the account and username as an argument into the Swift tool or you can set these values in an environment variable named ST_USER, as demonstrated in line 2 of the following screenshot:

These values may be added to a swiftrc file or you can include them in the openrc file along with the environment variables for other OpenStack services. When troubleshooting the Swift tool with TempAuth, be sure to check for the Swift tool environment variables, ST_AUTH, ST_USER, and ST_KEY, and if they are being used, make sure they are correct. It may also be helpful to unset these environment variables while troubleshooting and pass the values explicitly. The values passed into the Swift tool should match those set in the [filter:tempauth] section of the /etc/swift/proxy-server.conf file.

Auth GET failed: http://127.0.0.1:8080/auth2/v1.0 400 Bad Request

If you are having trouble using Swauth, you should confirm that Swauth has been successfully initialized. Swauth is typically initialized using a command similar to the following one:

swauth-prep -A http://127.0.0.1:8080/auth/ -K swauthkey

Note that there is no output when this command is completed successfully. The value for swauthkey in the command should match the value in your /etc/proxy-server.conf file under the [filter:swauth] section. The value for super_admin_key should be listed here.

If you run into unauthorized errors, similar to what we saw in the TempAuth section, you will want to confirm that your accounts and users have been set up in Swauth. You can do this by leveraging the swauth-list command:

swauth-list -A http://127.0.0.1:8080/auth/ -K swauthkey

Again, the value passed into the -K argument should match the entry of super_admin_key in the [Filter:swauth] section of the proxy-server.conf file. Upon successful execution, this command will return an output similar to this:

This command returns a list of the accounts (projects/tenants) loaded into Swauth. Likewise, you can list the users under an account using the following command:

swauth-list -A http://127.0.0.1:8080/auth/ -K swauthkey test

This command looks very similar to the command used earlier to list accounts. The only difference is that we will include the name of the account we want to list users for. In this example, the name of the account is test, and it is the last argument sent to the preceding command. The output of this command is as follows:

In this output, you will see a section titled users, which provides a list of users on the test account. The output displays one user under the test account with a username tester. If, for some reason, these commands do not return the accounts or users you are expecting, then you can add users using a command similar to the following one:

swauth-add-user -A http://104.239.130.27:8080/auth/ -K swauthkey -a test tester testing

There are additional swauth commands that may prove useful when troubleshooting. These commands are given in the following list:

Using the preceding commands, you can troubleshoot and correct most errors with your Swauth data.

Most installations will include a Swift service user that the object storage service will use to interact with Keystone. Make sure that the Swift user exists, and the password for this user has been set accurately in Keystone and in the proxy-server.conf file. You can use the OpenStack client to check whether the Swift user exists:

openstack user list

When you run the preceding user list command, as demonstrated, you will see a list of users recorded in Keystone. Make sure that there is a Swift user present.

If the Swift user has not been created already, you can create this user using the Keystone client:

keystone user-create --name swift --pass swiftpass --tenant service

Likewise, you can create the Swift user using the OpenStack client:

openstack user create swift --password swiftpass --project service

Whether you are using the Keystone client or the OpenStack client, be sure to set a secure password. Once the Swift user has been created, this user will need to be assigned the admin role under the service project/tenant.

Once the Swift user has been created, check whether you have configured the Swift proxy server with the correct credentials. Confirm the credentials at /etc/swift/proxy-server.conf under the [filter:authtoken] section. Take the following screenshot, for example: