Ron Stone 4b29310c6f Support DS rel-linking from STX
Change-Id: I5278866605ffd9b29ae2abe7d6e99606f6052423
Signed-off-by: Ron Stone <ronald.stone@windriver.com>
2024-03-12 11:45:42 +00:00

7.5 KiB

Use Local CLIs

administration and other tasks can be carried out from the command-line interface ().

Warning

For security reasons, only administrative users should have privileges.

You can access via container-backed Local from the active controller node's local console or by -ing to the Floating IP Address.

This procedure shows how to obtain the credentials to access Local , depending on your account type, and provides guidance on how to customize -specific resources and switch between and contexts.

In order for you to perform this procedure, you will need an account that is either:

  • the Sysadmin Local Linux Account; or
  • a Local LDAP Linux User Account.

The Sysadmin Local Linux Account is the account that, by default, has access to the credentials of the Keystone user admin that comes pre-created with .

A Local LDAP Linux User Account, on the other hand, is an account with SSH privileges that is typically configured with only access to the credentials of a Keystone user who has the same username as the account. To create such a composite Local and Keystone user account, see Manage Composite Local LDAP Accounts at Scale <manage-local-ldap-39fe3a85a528>.

Important

The Local Linux User Account must be a member of the group openstack to have access to the configuration files. This group is automatically created and made available after is applied on the platform.

You can add an account to the group openstack by running:

sudo ldapaddusertogroup <USER> openstack

See Local LDAP Linux User Accounts <local-ldap-linux-user-accounts> for more details.

If this is your first access to the system, you can use the Sysadmin Local Linux Account for Local CLI access.

  1. Log in to the active controller via console or to the Floating IP Address.
    • If accessing with Sysadmin Local Linux Account, use the username sysadmin with your <sysadmin-password>.
    • If accessing with a Local LDAP Linux Account, use the username and password for that account.
  2. Acquire the Keystone credentials for .
    • If accessing with Sysadmin Local Linux Account:

      $ source /var/opt/openstack/admin-openrc
      ~(keystone_admin)$
    • If accessing with a Local LDAP Linux Account:

      $ source /var/opt/openstack/local_openstackrc
      Enter password for Keystone user `ldap-user`:
      Created file `/home/ldap-user/ldap-user-openrc-openstack`.
      ~(keystone_ldap-user)$

      The Local Linux User Account should always source /var/opt/openstack/local_openstackrc to load Keystone credentials. This command prompts the user for the Keystone password, stores it in the local file <USER>-openrc-openstack and loads it. Subsequent calls of source /var/opt/openstack/local_openstackrc will just load the created local openrc file.

OpenStack commands for the Cloud Application are now available via the openstack command.

For example:

~(keystone_admin)$ openstack flavor list
+-----------------+------------------+------+------+-----+-------+-----------+
| ID              | Name             |  RAM | Disk | Eph.| VCPUs | Is Public |
+-----------------+------------------+------+------+-----+-------+-----------+
| 054531c5-e74e.. | squid            | 2000 |   20 |  0  |   2   | True      |
| 2fa29257-8842.. | medium.2c.1G.2G  | 1024 |    2 |  0  |   2   | True      |
| 4151fb10-f5a6.. | large.4c.2G.4G   | 2048 |    4 |  0  |   4   | True      |
| 78b75c6d-93ca.. | small.1c.500M.1G |  512 |    1 |  0  |   1   | True      |
| 8b9971df-6d83.. | vanilla          |    1 |    1 |  0  |   1   | True      |
| e94c8123-2602.. | xlarge.8c.4G.8G  | 4096 |    8 |  0  |   8   | True      |
+-----------------+------------------+------+------+-----+-------+-----------+

~(keystone_admin)$ openstack image list
+----------------+----------------------------------------+--------+
| ID             | Name                                   | Status |
+----------------+----------------------------------------+--------+
| 92300917-49ab..| Fedora-Cloud-Base-30-1.2.x86_64.qcow2  | active |
| 15aaf0de-b369..| opensquidbox.amd64.1.06a.iso           | active |
| eeda4642-db83..| xenial-server-cloudimg-amd64-disk1.img | active |
+----------------+----------------------------------------+--------+

If you need to run a command that references a local file, then that file must be copied to or created in the shared directory between the host and the clients container. On the host side, the directory is located at /var/opt/openstack.

Note

You can use a different directory for this purpose after specifying an alternate path in the Helm overrides and reapplying the application:

~(keystone_admin)$ system helm-override-update <app_name> clients openstack \
    --reuse-values --set workingDirectoryPath=/var/opt/another-directory
~(keystone_admin)$ system application-apply <app_name>

If you are logged in as sysadmin, you just have to move your file to /var/opt/openstack and reference it by its filename:

~(keystone_admin)$ mv ubuntu.qcow2 /var/opt/openstack/ubuntu.qcow2
~(keystone_admin)$ openstack image create --public --disk-format qcow2 \
    --container-format bare --file ubuntu.qcow2 ubuntu_image

Similarly, if you are logged in as an user, you just have to move your file to /var/opt/openstack/<USER> and reference it by its filename:

~(keystone_ldap-user)$ mv ubuntu.qcow2 /var/opt/openstack/ldap-user/ubuntu.qcow2
~(keystone_ldap-user)$ openstack image create --public --disk-format qcow2 \
    --container-format bare --file ubuntu.qcow2 ubuntu_image

Note

The subdirectory /var/opt/openstack/<USER> is created automatically after the first execution of a command by an user. If it does not exist, you can create it by running:

~(keystone_ldap-user)$ mkdir -p /var/opt/openstack/${USER}

Note

After running source /var/opt/openstack/admin-openrc, all OpenStack are aliased to the containerized OpenStack .

This means that, after sourcing admin-openrc or local_openstackrc, the openstack command no longer references the Platform OpenStack . Instead, it references the OpenStack of the containerized OpenStack application.

You can verify this by running:

~(keystone_admin)$ source /var/opt/openstack/admin-openrc
~(keystone_admin)$ type openstack
openstack is aliased to `/var/opt/openstack/clients-wrapper.sh openstack'

If you want to go back to using the OpenStack Platform , you can do so by clearing the aliases:

~(keystone_admin)$ source /var/opt/openstack/clear-aliases.sh