This section describes the ways to start, stop, and reload the Keystone services.
Keystone can serve a number of REST APIs and extensions on different TCP/IP ports.
The core Keystone API is primarily a read-only API (the only write operation being POST /tokens which authenticates a client, and returns a generated token). This API is sufficient to use OpenStack if all users, roles, endpoints already exist. This is often the case if Keystone is using an enterprise backend and the backend is managed through other entperrise tools and business processes. This core API is called the Service API and can be started separately from the more complete Admin API. By default, Keystone runs this API on port 5000. This is not an IANA assigned port and should not be relied upon (instead, use the Admin API on port 35357 to look for this endpoint - more on this later)
The Service API is started using this command in the /bin directory:
$ ./keystone-auth
Inn order for Keystone to be a fully functional service out of the box, API extensions that provide full CRUD operations is included with Keystone. This full set of API calls includes the OS-KSCATALOG, OS-KSADM, and OS-KSEC2 extensions. These extensions provide a full set of create, read, update, delete (CRUD) operations that can be used to manage Keystone objects through REST calls. By default Keystone runs this full REST API on TCP/IP port 35357 (assigned by IANA to Keystone).
The Admin API is started using this command in the /bin directory:
$ ./keystone-admin
Both APIs can be loaded simultaneously (on different ports) using this command:
$ ./keystone
There are two ways to start a Keystone service (either the Service API server or the Admin API server):
We recommend using the second way in production and the first for development and debugging.
The first is by directly calling the server program, passing in command-line options and a single argument for a paste.deploy configuration file to use when configuring the server application.
Note
Keystone ships with an etc/ directory that contains a sample paste.deploy configuration files that you can copy to a standard configuration directory and adapt for your own uses.
If you do not specify a configuration file on the command line, Keystone will do its best to locate a configuration file in one of the following directories, stopping at the first config file it finds:
The filename that is searched for is keystone.conf by default.
If no configuration file is found, you will see an error, like:
$ keystone
ERROR: Unable to locate any configuration file. Cannot load application keystone
Here is an example showing how you can manually start the keystone-auth server and keystone-registry in a shell:
$ ./keystone -d
keystone-legacy-auth: INFO **************************************************
keystone-legacy-auth: INFO Configuration options gathered from config file:
keystone-legacy-auth: INFO /Users/ziadsawalha/Documents/Code/keystone/etc/keystone.conf
keystone-legacy-auth: INFO ================================================
keystone-legacy-auth: INFO admin_host 0.0.0.0
keystone-legacy-auth: INFO admin_port 35357
keystone-legacy-auth: INFO admin_ssl False
keystone-legacy-auth: INFO backends keystone.backends.sqlalchemy
keystone-legacy-auth: INFO ca_certs /etc/keystone/ssl/certs/ca.pem
keystone-legacy-auth: INFO cert_required True
keystone-legacy-auth: INFO certfile /etc/keystone/ssl/certs/keystone.pem
keystone-legacy-auth: INFO debug True
keystone-legacy-auth: INFO default_store sqlite
keystone-legacy-auth: INFO extensions osksadm,oskscatalog,hpidm
keystone-legacy-auth: INFO hash-password True
keystone-legacy-auth: INFO keyfile /etc/keystone/ssl/private/keystonekey.pem
keystone-legacy-auth: INFO keystone-admin-role Admin
keystone-legacy-auth: INFO keystone-service-admin-role KeystoneServiceAdmin
keystone-legacy-auth: INFO log_dir .
keystone-legacy-auth: INFO log_file keystone.log
keystone-legacy-auth: INFO service-header-mappings {
'nova' : 'X-Server-Management-Url',
'swift' : 'X-Storage-Url',
'cdn' : 'X-CDN-Management-Url'}
keystone-legacy-auth: INFO service_host 0.0.0.0
keystone-legacy-auth: INFO service_port 5000
keystone-legacy-auth: INFO service_ssl False
keystone-legacy-auth: INFO verbose False
keystone-legacy-auth: INFO **************************************************
passlib.registry: INFO registered crypt handler 'sha512_crypt': <class 'passlib.handlers.sha2_crypt.sha512_crypt'>
Starting the RAX-KEY extension
Starting the Legacy Authentication component
admin : INFO **************************************************
admin : INFO Configuration options gathered from config file:
admin : INFO /Users/ziadsawalha/Documents/Code/keystone/etc/keystone.conf
admin : INFO ================================================
admin : INFO admin_host 0.0.0.0
admin : INFO admin_port 35357
admin : INFO admin_ssl False
admin : INFO backends keystone.backends.sqlalchemy
admin : INFO ca_certs /etc/keystone/ssl/certs/ca.pem
admin : INFO cert_required True
admin : INFO certfile /etc/keystone/ssl/certs/keystone.pem
admin : INFO debug True
admin : INFO default_store sqlite
admin : INFO extensions osksadm,oskscatalog,hpidm
admin : INFO hash-password True
admin : INFO keyfile /etc/keystone/ssl/private/keystonekey.pem
admin : INFO keystone-admin-role Admin
admin : INFO keystone-service-admin-role KeystoneServiceAdmin
admin : INFO log_dir .
admin : INFO log_file keystone.log
admin : INFO service-header-mappings {
'nova' : 'X-Server-Management-Url',
'swift' : 'X-Storage-Url',
'cdn' : 'X-CDN-Management-Url'}
admin : INFO service_host 0.0.0.0
admin : INFO service_port 5000
admin : INFO service_ssl False
admin : INFO verbose False
admin : INFO **************************************************
Using config file: /Users/ziadsawalha/Documents/Code/keystone/etc/keystone.conf
Service API (ssl=False) listening on 0.0.0.0:5000
Admin API (ssl=False) listening on 0.0.0.0:35357
eventlet.wsgi.server: DEBUG (77128) wsgi starting up on http://0.0.0.0:5000/
eventlet.wsgi.server: DEBUG (77128) wsgi starting up on http://0.0.0.0:35357/
$ sudo keystone-registry keystone-registry.conf &
jsuh@mc-ats1:~$ 2011-04-13 14:51:16 INFO [sqlalchemy.engine.base.Engine.0x...feac] PRAGMA table_info("images")
2011-04-13 14:51:16 INFO [sqlalchemy.engine.base.Engine.0x...feac] ()
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Col ('cid', 'name', 'type', 'notnull', 'dflt_value', 'pk')
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (0, u'created_at', u'DATETIME', 1, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (1, u'updated_at', u'DATETIME', 0, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (2, u'deleted_at', u'DATETIME', 0, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (3, u'deleted', u'BOOLEAN', 1, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (4, u'id', u'INTEGER', 1, None, 1)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (5, u'name', u'VARCHAR(255)', 0, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (6, u'disk_format', u'VARCHAR(20)', 0, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (7, u'container_format', u'VARCHAR(20)', 0, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (8, u'size', u'INTEGER', 0, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (9, u'status', u'VARCHAR(30)', 1, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (10, u'is_public', u'BOOLEAN', 1, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (11, u'location', u'TEXT', 0, None, 0)
2011-04-13 14:51:16 INFO [sqlalchemy.engine.base.Engine.0x...feac] PRAGMA table_info("image_properties")
2011-04-13 14:51:16 INFO [sqlalchemy.engine.base.Engine.0x...feac] ()
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Col ('cid', 'name', 'type', 'notnull', 'dflt_value', 'pk')
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (0, u'created_at', u'DATETIME', 1, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (1, u'updated_at', u'DATETIME', 0, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (2, u'deleted_at', u'DATETIME', 0, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (3, u'deleted', u'BOOLEAN', 1, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (4, u'id', u'INTEGER', 1, None, 1)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (5, u'image_id', u'INTEGER', 1, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (6, u'key', u'VARCHAR(255)', 1, None, 0)
2011-04-13 14:51:16 DEBUG [sqlalchemy.engine.base.Engine.0x...feac] Row (7, u'value', u'TEXT', 0, None, 0)
$ ps aux | grep keystone
myuser 77148 0.0 0.0 2434892 472 s012 U+ 11:50AM 0:00.01 grep keystone
myuser 77128 0.0 0.6 2459356 25360 s011 S+ 11:48AM 0:00.82 python ./keystone -d
Simply supply the configuration file as the first argument and then any common options you want to use (-d was used above to show some of the debugging output that the server shows when starting up. Call the server program with --help to see all available options you can specify on the command line.)
Using --trace-calls is useful for showing a trace of calls (errors in red) for debugging.
For more information on configuring the server via the paste.deploy configuration files, see the section entitled Configuring Keystone
Note that the server daemonizes itself by using the standard shell backgrounding indicator, &, in the previous example. For most use cases, we recommend using the keystone-control server daemon wrapper for daemonizing. See below for more details on daemonization with keystone-control.
The second way to start up a Keystone server is to use the keystone-control program. keystone-control is a wrapper script that allows the user to start, stop, restart, and reload the other Keystone server programs in a fashion that is more conducive to automation and scripting.
Servers started via the keystone-control program are always daemonized, meaning that the server program process runs in the background.
To start a Keystone server with keystone-control, simply call keystone-control with a server and the word “start”, followed by any command-line options you wish to provide. Start the server with keystone-control in the following way:
$ sudo keystone-control <SERVER> start [CONFPATH]
Note
You must use the sudo program to run keystone-control currently, as the pid files for the server programs are written to /var/run/keystone/
Start the keystone-admin server using keystone-control:
$ sudo keystone-control admin start
Starting keystone-admin with /etc/keystone.conf
The same paste.deploy configuration files are used by keystone-control to start the Keystone server programs, and you can specify (as the example above shows) a configuration file when starting the server.
If you started a Keystone server manually and did not use the & backgrounding function, simply send a terminate signal to the server process by typing Ctrl-C
If you started the Keystone server using keystone-control, you can use the keystone-control program to stop it:
$ sudo keystone-control <SERVER> stop
For example:
$ sudo keystone-control auth stop
Stopping keystone-auth pid: 77401 signal: 15
Restart the Keystone server using keystone-control:
$ sudo keystone-control admin restart /etc/keystone.conf
Stopping keystone-admin pid: 77401 signal: 15
Starting keystone-admin with /etc/keystone.conf