Example 1.1: Set user token to myt0k3n==
- $ kamaki set token myt0k3n==
+ $ kamaki config set token myt0k3n==
Shell vs one-command
--------------------
Options:
- - - -
- astakos: Astakos API commands
- config : Configuration commands
- flavor : Compute/Cyclades API flavor commands
- history: Command history
- image : Plankton (and Compute) Image API commands
- network: Compute/Cyclades API network commands
- server : Compute/Cyclades API server commands
- store : Pithos+ storage commands
+ user: Astakos API commands
+ config: Configuration commands
+ flavor: Compute/Cyclades API flavor commands
+ history: Command history
+ image: Plankton (and Compute) Image API commands
+ network: Compute/Cyclades API network commands
+ server: Compute/Cyclades API server commands
+ file: Pithos+ storage commands
.. code-block:: console
:emphasize-lines: 1
Example 3.4.1: Print username for token us3rt0k3n== using grep
- $ kamaki astakos authenticate -o token=us3rt0k3n== | grep userame
+ $ kamaki user authenticate -o token=us3rt0k3n== | grep userame
userame : user@synnefo.org
The -o argument can be used to temporarily override various (set or unset) options. In one command, all -o option sets are forgotten just after the command has been completed, and the previous settings are restored (a.k.a. the configuration file is not modified).
-The astakos-authenticate command in example 3.4.1 runs with an explicitly provided token, which temporarily overrides the token provided in the configuration file.
+The user-authenticate command in example 3.4.1 runs with an explicitly provided token, which temporarily overrides the token provided in the configuration file.
Interactive shell
-----------------
Command Contexts
^^^^^^^^^^^^^^^^
-The kamaki interactive shell implements the notion of command contexts. Each command group is also a context where the users can **enter** by typing the group name. If the context switch is successful, the kamaki shell prompt changes to present the new context ("store" in example 4.1.1).
+The kamaki interactive shell implements the notion of command contexts. Each command group is also a context where the users can **enter** by typing the group name. If the context switch is successful, the kamaki shell prompt changes to present the new context ("file" in example 4.1.1).
.. code-block:: console
:emphasize-lines: 1
- Example 4.1.1: Enter store commands context / group
+ Example 4.1.1: Enter file commands context / group
$ kamaki
- [kamaki]: store
- [store]:
+ [kamaki]: file
+ [file]:
Type **exit** (alternatively **ctrl-D** in (X)nix systems or **ctrl-Z** in Windows) to exit a context and return to the context of origin. If already at the top context (kamaki), an exit is equivalent to exiting the program.
.. code-block:: console
:emphasize-lines: 1
- Example 4.1.2: Exit store context and then exit kamaki
+ Example 4.1.2: Exit file context and then exit kamaki
- [store]: exit
+ [file]: exit
[kamaki]: exit
$
[config]: list
... (configuration options listing) ...
[config]: exit
- [kamaki]: store
- [store]: list
+ [kamaki]: file
+ [file]: list
... (storage containers listing) ...
- [store]: exit
+ [file]: exit
[kamaki]: server
[server]: list
... (VMs listing) ...
[kamaki]: config list
... (configuration options listing) ...
- [kamaki]: store list
+ [kamaki]: file list
... (storage container listing) ...
[kamaki]: server list
... (VMs listing) ...
kamaki commands:
================
- astakos config flavor history image network server store
+ user config flavor history image network server file
interactive shell commands:
===========================
[config]: set --help
[kamaki]: config set -h
[kamaki]: config set --help
- [store]: /config set -h
+ [file]: /config set -h
[server]: /config set --help
.. _accessing-top-level-commands-ref:
[server]: create 'my debian' 43 6aa6eafd-dccb-67fe2bdde87e
...
-An other example (4.3.2) showcases how to acquire and modify configuration settings from a different context. In this scenario, the user token expires at server side while the user is working. When that happens, the system responds with an *(401) UNAUTHORIZED* message. The user can acquire a new token (valid for the astakos identity manager of preference) which has to be set to kamaki.
+An other example (4.3.2) showcases how to acquire and modify configuration settings from a different context. In this scenario, the user token expires at server side while the user is working. When that happens, the system responds with an *(401) UNAUTHORIZED* message. The user can acquire a new token (valid for the Astakos identity manager of preference) which has to be set to kamaki.
.. code-block:: console
:emphasize-lines: 1
- Example 4.3.2: Set a new token from store context
+ Example 4.3.2: Set a new token from file context
- [store]: list
+ [file]: list
(401) UNAUTHORIZED Access denied
- [store]: /astakos authenticate
+ [file]: /user authenticate
(401) UNAUTHORIZED Invalid X-Auth-Token
- [store]: /config get token
+ [file]: /config get token
my3xp1r3dt0k3n==
- [store]: /config set token myfr35ht0k3n==
+ [file]: /config set token myfr35ht0k3n==
- [store]: /config get token
+ [file]: /config get token
myfr35ht0k3n==
- [store]: list
+ [file]: list
1. pithos (10MB, 2 objects)
2. trash (0B, 0 objects)
.. note:: The error messages on this example where shortened for clarity. Actual kamaki error messages are more helpful and descriptive.
-The following example compares some equivalent calls that run *astakos-authenticate* after a *store-list* 401 failure.
+The following example compares some equivalent calls that run *user-authenticate* after a *file-list* 401 failure.
.. code-block:: console
:emphasize-lines: 1,3,10,17,26
- Example 4.3.3: Equivalent astakos-authenticate calls after a store-list 401 failure
+ Example 4.3.3: Equivalent user-authenticate calls after a file-list 401 failure
* without kamaki interactive shell *
- $ kamaki store list
+ $ kamaki file list
(401) UNAUTHORIZED Access denied
- $ kamaki astakos authenticate
+ $ kamaki user authenticate
...
$
* from top-level context *
- [kamaki]: store list
+ [kamaki]: file list
(401) UNAUTHORIZED Access denied
- [kamaki]: astakos authenticate
+ [kamaki]: user authenticate
...
[kamaki]
* maximum typing *
- [store]: list
+ [file]: list
(401) UNAUTHORIZED Access denied
- [store]: exit
- [kamaki]: astakos
- [astakos]: authenticate
+ [file]: exit
+ [kamaki]: user
+ [user]: authenticate
...
- [astakos]:
+ [user]:
* minimum typing *
- [store]: list
+ [file]: list
(401) UNAUTHORIZED Access denied
- [store]: /astakos authenticate
+ [file]: /user authenticate
...
- [store]:
+ [file]:
.. hint:: To exit kamaki shell while in a context, try */exit*
All setting changes affect the physical kamaki config file. The config file is created automatically at callers' home firectory the first time a config option is set, and lives there as *.kamakirc* . It can be edited with any text editor or managed with kamaki config commands.
-In example 4.4.1 the user is going to work with only one storage container. The store commands use the container:path syntax, but if the user sets a container name as default, the container name can be omitted. This is possible by setting a *store.container* setting.
+In example 4.4.1 the user is going to work with only one storage container. The file commands use the container:path syntax, but if the user sets a container name as default, the container name can be omitted. This is possible by setting a *file.container* setting.
.. code-block:: console
:emphasize-lines: 1
Example 4.4.1: Set default storage container
- [store]: list
+ [file]: list
1. mycontainer (32MB, 2 objects)
2. pithos (0B, 0 objects)
3. trash (2MB, 1 objects)
- [store]: list mycontainer
+ [file]: list mycontainer
1. D mydir/
2. 20M mydir/rndm_local.file
- [store]: /config set store.container mycontainer
+ [file]: /config set file.container mycontainer
- [store]: list
+ [file]: list
1. D mydir/
2. 20M mydir/rndm_local.file
-After a while, the user needs to work with multiple containers, therefore a default container is no longer needed. The *store.container* setting can be deleted, as shown in example 4.4.2 .
+After a while, the user needs to work with multiple containers, therefore a default container is no longer needed. The *file.container* setting can be deleted, as shown in example 4.4.2 .
.. code-block:: console
:emphasize-lines: 1
Example 4.4.2: Delete a setting option
- [store]: /config delete store.container
+ [file]: /config delete file.container
- [store]: list
+ [file]: list
1. mycontainer (32MB, 2 objects)
2. pithos (0B, 0 objects)
3. trash (2MB, 1 objects)
:emphasize-lines: 1,12,19,32
* Download mycontainer1:myfile and upload it to mycontainer2:myfile
- [kamaki]: store
- [store]: copy mycontainer1:somefile mycontainer1:myfile
- [store]: download mycontainer1:myfile mylocalfile
+ [kamaki]: file
+ [file]: copy mycontainer1:somefile mycontainer1:myfile
+ [file]: download mycontainer1:myfile mylocalfile
Download completed
- [store]: upload mylocalfile mycontainer2:myfile
+ [file]: upload mylocalfile mycontainer2:myfile
Upload completed
* undo the process *
- [store]: !rm mylocalfile
- [store]: delete mycontainer1:myfile
- [store]: delete mycontainer2:myfile
+ [file]: !rm mylocalfile
+ [file]: delete mycontainer1:myfile
+ [file]: delete mycontainer2:myfile
* check history entries *
- [store]: exit
+ [file]: exit
[kamaki]: history
[history]: show
- 1. store
- 2. store copy mycontainer1:somefile mycontainer1:myfile
- 3. store download mycontainer1:myfile mylocalfile
- 4. store upload mylocalfile mycontainer2:myfile
- 5. store delete mycontainer1:myfile
- 6. store delete mycontainer2:myfile
+ 1. file
+ 2. file copy mycontainer1:somefile mycontainer1:myfile
+ 3. file download mycontainer1:myfile mylocalfile
+ 4. file upload mylocalfile mycontainer2:myfile
+ 5. file delete mycontainer1:myfile
+ 6. file delete mycontainer2:myfile
7. history
8. history show
*repeat the process *
[history]: run 2-4
- <store copy mycontainer1:somefile mycontainer1:myfile>
- <store download mycontainer1:myfile mylocalfile>
+ <file copy mycontainer1:somefile mycontainer1:myfile>
+ <file download mycontainer1:myfile mylocalfile>
Download completed
- <store upload mylocalfile mycontainer2:myfile>
+ <file upload mylocalfile mycontainer2:myfile>
Upload completed
For powerfull scripting, users are advised to take advantage of their os shell scripting capabilities and combine them with kamaki one-command. Still, the history-run functionality might prove handy in many occasions.
projects / kamaki / blobdiff