Install and configure Keystone in Installation Guide

[Steve Tyler]

-----------------------------------
Release: 0.1 on 2016-07-22 12:23
SHA: 3cc858472d59ea978f4d2a141104b6aa5cef5c59
Source: http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/install-guide/source/keystone-install.rst
URL: http://docs.openstack.org/mitaka/install-guide-ubuntu/keystone-install.html

The following section is invalid:
Initialize Fernet keys:

# keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone

'fernet_setup' is an invalid argument

[maoshuai (maoshuai)]

Hi Tyler,Do you manually install the Mitaka release?I don't think 'fernet_setup' is an invalid argument.It's nessesary to initialize your key repository(/etc/keystone/fernet-keys/) for Fernet tokens.

[Steve Tyler (instantrice)]

I realize it's necessary, but the argument is simply not there. Man page confirms as well as the error message indicating available options that fernet_setup doesn't exist as an argument. Everything has been installed following the documentation here :

docs.openstack.org/mitaka/install-guide-ubuntu

[Steve Tyler (instantrice)]

Full error message:

keystone-manage: error: argument command: invalid choice: 'fernet_setup' (choose from 'db_sync', 'db_version', 'pki_setup', 'ssl_setup', 'token_flush')

[Darren McGrandle (dmcgrandle)]

Same error for me, installing on debian jessie:

# keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone
usage: keystone-manage [db_sync|db_version|pki_setup|ssl_setup|token_flush]
keystone-manage: error: argument command: invalid choice: 'fernet_setup' (choose from 'db_sync', 'db_version', 'pki_setup', 'ssl_setup', 'token_flush')
# keystone --version
0.10.1
#keystone-manage --version
2014.1.3

# apt-cache show keystone
Package: keystone
Version: 2:9.0.0-2~bpo8+1
Installed-Size: 366
Maintainer: PKG OpenStack <email address hidden>
Architecture: all
Depends: adduser, dbconfig-common, init-system-helpers (>= 1.18~), python-keystone (= 2:9.0.0-2~bpo8+1), q-text-as-data, sqlite3, ssl-cert (>= 1.0.12), debconf (>= 0.5) | debconf-2.0, lsb-base (>= 3.0-6), python
Suggests: apparmor
Description-en: OpenStack identity service
 This is the identity service used by OpenStack for authentication (authN)
 and high-level authorization (authZ). It currently supports token-based
 authN with user/service authZ, and is scalable to support OAuth, SAML,
 and OpenID in future versions. Out of the box, Keystone uses SQLite for
 its identity store database, with the option to connect to external LDAP.
 .
 This package contains the daemons.
Description-md5: 1b67519deaaf4579dcc19e2b1805131b
Homepage: http://keystone.openstack.org/
Section: python
Priority: extra
Filename: pool/main/k/keystone/keystone_9.0.0-2~bpo8+1_all.deb
Size: 91106
MD5sum: ae410e7463ed00aa3731a26d24a366ee
SHA1: 4b6196add12ccb9a9f20fe3fa58c27f82f25f4a3
SHA256: 7625f0b502b9b08d8a293822143c7b955d4edb73cccd20488d5ea558e02a624e

Package: keystone
Version: 2014.1.3-6
Installed-Size: 495
Maintainer: PKG OpenStack <email address hidden>
Architecture: all
Depends: adduser, dbconfig-common, init-system-helpers (>= 1.18~), python-configobj, python-keystone (= 2014.1.3-6), sqlite3, ssl-cert (>= 1.0.12), debconf (>= 0.5) | debconf-2.0, lsb-base (>= 3.0-6), python:any
Pre-Depends: dpkg (>= 1.15.6~)
Description-en: OpenStack identity service
 This is the identity service used by OpenStack for authentication (authN)
 and high-level authorization (authZ). It currently supports token-based
 authN with user/service authZ, and is scalable to support OAuth, SAML,
 and OpenID in future versions. Out of the box, Keystone uses SQLite for
 its identity store database, with the option to connect to external LDAP.

[Alexandra Settle (alexandra-settle)]

Darren - are you also following the Mitaka guide?

[Lana (loquacity)]

OK, so what do we need to do here? Is it a different command, or do we just remove the step?

[Lana (loquacity)]

In the Newton (latest) version, we give this command:
# keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone

Is this incorrect also?

[Lance Bragstad (lbragstad)]

From a keystone perspective - we added the `keystone-manage fernet_setup` and `keystone-manage fernet_rotate` commands in the Kilo release when we introduced the fernet token format.

I would think those commands are required by the install guide since they bootstrap a keystone node with the keys required to issue and validate tokens. Granted, this can be done by third party tooling and using `keystone-manage` to do this isn't explicitly required, just the presence of the keys is. The keystone team opted to include that tooling in `keystone-manage` to provide a way to bootstrap keys out of the box from Kilo on.

[Lance Bragstad (lbragstad)]

I did a little more digging into this. Looking back at the Mitaka codebase I see that we provided entry points for the commands through setup.cfg [0]. This should make `keystone-manage fernet_setup` [1] and `keystone-manage fernet_rotate` [2] accessible. From an upstream perspective, keystone provides these things in the Mitaka branch.

Steve and Darren, can you confirm that the packages you're using built/provided these entry points for the Mitaka release?

I was able to install stable/mitaka using virtual environments and use the fernet commands [3]

[0] https://github.com/openstack/keystone/blob/stable/mitaka/setup.cfg#L72
[1] https://github.com/openstack/keystone/blob/stable/mitaka/keystone/cmd/cli.py#L517
[2] https://github.com/openstack/keystone/blob/stable/mitaka/keystone/cmd/cli.py#L539
[3] http://cdn.pasteraw.com/o9laezlcgjjb1oinfh8g2kq7jntudh3

[Darren McGrandle (dmcgrandle)]

Thanks for the work Lance. Since debian was buggy I went with CentOS instead. I have Openstack up and running now and don't have the system available any more to re-install and test.
Regards,
:D