kdb(1)

Usage

kdb get [-dlr] key/name

kdb set [-t type] [-d] [-c "A comment about this key"] [-m mode] [-u uid] [-g gid] key/name "the value"

kdb set [-t type] [-m mode] [-c "A comment"] key/name -- "the value"

kdb set [-t type] [-b file] key/name

kdb ls [-lRfvs] [{key/dir | key/name}]

kdb ls [-lRfvx] [{key/dir | key/name}] > keys.xml

kdb edit [-R] [{key/dir | key/name}]

kdb rm key/name

kdb mv key/src key/dest

kdb ln key/src key/dest

kdb export [-f] system/some/tree.root > [file.xml]

kdb import < file.xml

kdb import file.xml

set

ls

ln

mv

rm

edit

Options.PP -R

Environment

KDB_ROOT if defined, prepends it to key names.

KDB_BACKEND defines the name of another backend plugin library to use ExamplesSetting Keys.PP bash$kdb set -c "My first key" user/example/key "Some nice value"

bash$kdb set user:luciana/example/key -- "Some - nice - value with dashes"

bash#KDB_ROOT=user:http/sw/httpd kdb set -u nobody -g http key "Some value"

bash$kdb set -b image.png -t bin user/example/binaryKey

bash$kdb set -b file.txt user/example/regularKey

bash#kdb set -t link system/sw/XFree/current system/sw/XFree/handmade Getting Keys.PP bash$KDB_ROOT=user/example kdb get some/key/name

bash$eval `kdb get -s user/env/env1/PS1`

bash$KDB_BACKEND=gconf kdb get user/sw/gnome-terminal/global/active_encodings Listing.PP bash$kdb ls -laR user:valeria

bash$kdb ls -lR system/sw/xorg/current

bash$KDB_ROOT=system/sw kdb ls -lR xorg

bash$KDB_BACKEND=fstab kdb ls -Rv system/filesystems

bash$eval `kdb ls -Rvs user/env/env2` Miscelaneous.PP bash#kdb ln system/sw/xorg/handmade system/sw/xorg/current

bash#kdb mv system/sw/xorg/current system/sw/xorg/old

bash#kdb rm system/inittab/rc4

bash$KDB_BACKEND=gconf kdb rm user/gconfKey XML Import and Export.PP bash#kdb export user/sw/app | sed -e 's|/app/|/app2/|g' | kdb import

bash#KDB_ROOT=system/sw kdb export myapp > myappconf.xml

bash#kdb import myappconf.xml

bash$KDB_BACKEND=gconf kdb export user/sw

Releases

5 releases since Debian 3.1 (Sarge); the text changed 2 times.

elektra(7) A framework to store configuration atoms hierarchically Library Linkage Architecture.PP The Elektra library (libelektra.so) has 2 layers: public methods and backend access, according to the following architecture (these pictures were taken from the Elektra presentation[1]): When using local backends such as the filesys backend, all key access happens in the actual process space as bellow: A remote daemon backend is also possible as noted bellow: True Facts About Elektra Elektra Is Not Namespaces and Key Names.PP All keys are organized in a hierarchical tree with 2 Namespaces (subtrees) as showed by the picture: system user User Domains.PP Different from the system namespace, the user namespace is dynamic. For example, the key user/env/PATH may have completely different values for users luciana and valeria. In this example, if valeria wants to access this key at luciana's space, it should refer to user:luciana/env/PATH. Access permissions apply. User domains were implemented also to address situations when different user names ($USER) have same UID. So a user key is stored in his home directory based on the user name, not the UID. Inactive Keys.PP A great thing about text configuration files is that some configuration items can be there as an example, but inactive or commented. Elektra provides a very simple way to simulate this behavior: if the key name begins with a dot (.), it is considered inactive or commented. In real world applications, the Elektra API will ignore these keys by default, but the keys are still accessible if the developer wants to. These are some keys that have inactive subtrees: See bellow more examples of inactive keys. Key Examples.PP Here are some valid key names, and their values: The Elektra keys of the combined /etc/passwd and /etc/shadow entry for user 'nobody' would look like: The environment variables I want set, when I log in, with their full key name: The entry in /etc/inittab that is responsible for starting X11 would look: The users database files and /etc/inittab were Elektrified to key-value pairs using the users-convert and inittab-convert scripts included with the distribution. An example of an elektrified /etc/X11/xorg.conf or /etc/X11/XF86Config: Pay attention that the keys bellow system/sw/XFree/current/Monitor/.Monitor1 are inactive because we have .Monitor1 as their parent. So unless special options are used when calling the API, these keys will not be retrieved from the database. Throughout this text you will see other examples of key names. Key Data Types.PP There are only two types of data that can be stored: Text Binary There are very good reasons why types like Integer, Time, Font, List, etc were not implemented: Elektra was designed to be useful for any type of program, so having more specific data types implicates in the definition of value limits, separators in the storage format, etc, that may be good for some application and bad for other. So the semantics of the data is handled by the application. A program or framework may define its own special data handling methods using these essential basic types. See the keyGetType() and keySetType() methods documentation in the kdb(3) man page to understand how to set keys with your own data types. There are more two types of keys: Directory Link Key Meta Data.PP Besides the key name and the value, each key has other attributes: Owner's User and Group Access Permissions Modification, Access and Stat Times Key Comment Fine Grained Security Example.PP To show this metadata in action, this screen shows the kdb command listing keys and their attributes related to user nobody. We ran the kdb command without super-user credentials, asking for long (-l), recursive (-R) listing, and to show each key value (-v). But (since we are) regular user, we don't have permission to see the values of the system/users/nobody/passwd* fields. The users database files were elektrified to key-value pairs using the users-convert script included with the distribution. ExamplesSetting Keys.PP bash$kdb set -c "My first key" user/example/key "Some nice value" bash$kdb set user:luciana/example/key -- "Some - nice - value with dashes" bash#KDB_ROOT=user:http/sw/httpd kdb set -u nobody -g http key "Some value" bash$kdb set -b image.png -t bin user/example/binaryKey bash$kdb set -b file.txt user/example/regularKey bash#kdb set -t link system/sw/XFree/current system/sw/XFree/handmade Getting Keys.PP bash$KDB_ROOT=user/example kdb get some/key/name bash$eval `kdb get -s user/env/env1/PS1` bash$KDB_BACKEND=gconf kdb get user/sw/gnome-terminal/global/active_encodings Listing.PP bash$kdb ls -laR user:valeria bash$kdb ls -lR system/sw/xorg/current bash$KDB_ROOT=system/sw kdb ls -lR xorg bash$KDB_BACKEND=fstab kdb ls -Rv system/filesystems bash$eval `kdb ls -Rvs user/env/env2` Miscelaneous.PP bash#kdb ln system/sw/xorg/handmade system/sw/xorg/current bash#kdb mv system/sw/xorg/current system/sw/xorg/old bash#kdb rm system/inittab/rc4 bash$KDB_BACKEND=gconf kdb rm user/gconfKey XML Import and Export.PP bash#kdb export user/sw/app | sed -e 's|/app/|/app2/|g' | kdb import bash#KDB_ROOT=system/sw kdb export myapp > myappconf.xml bash#kdb import myappconf.xml bash$KDB_BACKEND=gconf kdb export user/sw elektra(5) A framework to store configuration atoms hierarchically Elektra Key Storage Strategy.PP Elektra implements a very simple way to store the key-value pairs. The value (and some metainfo) for each key is stored in a single file. The key name (and some of its context) is sufficient to find the file name that stores the value. The system/* keys are stored under /etc/kdb/, and the user/* keys can be found under each user's $HOME/.kdb/. Here are some examples of key names, and where Elektra goes to look for them in the disk. system/sw/XFree86/screen0/driver user/env/PATH user:luciana/env/PATH system/mime.types/some.mime Some may think that one file per key will consume many filesystem i-nodes. Actually, when not using Reiser4 filesystem, it may consume some more disk space, and it may also be not so efficient than reading one single text file, as KConfig does. But Elektra's nature lets applications load their keys on demand; so it is possible to avoid the read-all-use-some approach. Writing updated keys back to disk is also more robust, because unchanged keys won't be touched, different from a single file approach, that must be entirelly rewritten. Besides that, big applications (like Mozilla, Konqueror, KDE, Gnome) key gathering time is a very small part of what they have to do to start up. And the benefits of an homogeneous key database to the entire system are much bigger then these issues. Think about a common integration between everything, flexibility, security granularity and openness. XML, Storage Backends and Elektra.PP This document you are just reading was written in DocBook XML. XML is a wonderfull technology, but brings no value to this software. Two main goals of the Elektra Project are to be lightweight, and to be accessible by early boot stage programs like /sbin/init and the /etc/rc.d scripts. XML parsing libraries are memory eaters, not so fast as we can expect, and they are usually located under /usr/lib, which may be unavailable to these early boot stage needs. Some discussions asked for a sort of plugin architecture to let user decide the format to store keys content. Well, the info that goes into the key file is not big deal as you'll see, and sometimes, too many options is bad business, and not the path for the Elektra Project. So no XML, no plugin architecture, no sophistication. Lets keep it simple and generic. A very straight forward text based file format was defined to store a single key value. Key Files Format.PP Inside Elektra key database, each key is a file, and every file is a key. So most of the key's metainformation are actually its file attributes, as you can see in a regular ls(1) command output. So what needs to be stored inside the key file is the data type (binary or text), key comment and the actual data. The format of each key file is: So if we set the key system/hw/eth0/driver as type String and value "3com", and comment "The driver for my network interface", we'll find the file /etc/kdb/system/hw/eth0/driver containing: Other example: setting user/tmp/proprietary as Binary, and value "A groovy data I want to hide", and comment "Stay away from here", you'll get in ~$USER/.kdb/user/tmp/proprietary the following: The current data types are: Between 20 and 39 40 up to 254 Types between 0 and 19 are used only internaly in the API, and will never appear into a key file. They are used to define meta keys as directory, link, etc.

Mentioned on this page

ls(1) list directory contents rm(1) remove files or directories UTF-8(7) chmod(1) change file mode bits

Referred to by

elektra(5) A framework to store configuration atoms hierarchically Elektra Key Storage Strategy.PP Elektra implements a very simple way to store the key-value pairs. The value (and some metainfo) for each key is stored in a single file. The key name (and some of its context) is sufficient to find the file name that stores the value. The system/* keys are stored under /etc/kdb/, and the user/* keys can be found under each user's $HOME/.kdb/. Here are some examples of key names, and where Elektra goes to look for them in the disk. system/sw/XFree86/screen0/driver user/env/PATH user:luciana/env/PATH system/mime.types/some.mime Some may think that one file per key will consume many filesystem i-nodes. Actually, when not using Reiser4 filesystem, it may consume some more disk space, and it may also be not so efficient than reading one single text file, as KConfig does. But Elektra's nature lets applications load their keys on demand; so it is possible to avoid the read-all-use-some approach. Writing updated keys back to disk is also more robust, because unchanged keys won't be touched, different from a single file approach, that must be entirelly rewritten. Besides that, big applications (like Mozilla, Konqueror, KDE, Gnome) key gathering time is a very small part of what they have to do to start up. And the benefits of an homogeneous key database to the entire system are much bigger then these issues. Think about a common integration between everything, flexibility, security granularity and openness. XML, Storage Backends and Elektra.PP This document you are just reading was written in DocBook XML. XML is a wonderfull technology, but brings no value to this software. Two main goals of the Elektra Project are to be lightweight, and to be accessible by early boot stage programs like /sbin/init and the /etc/rc.d scripts. XML parsing libraries are memory eaters, not so fast as we can expect, and they are usually located under /usr/lib, which may be unavailable to these early boot stage needs. Some discussions asked for a sort of plugin architecture to let user decide the format to store keys content. Well, the info that goes into the key file is not big deal as you'll see, and sometimes, too many options is bad business, and not the path for the Elektra Project. So no XML, no plugin architecture, no sophistication. Lets keep it simple and generic. A very straight forward text based file format was defined to store a single key value. Key Files Format.PP Inside Elektra key database, each key is a file, and every file is a key. So most of the key's metainformation are actually its file attributes, as you can see in a regular ls(1) command output. So what needs to be stored inside the key file is the data type (binary or text), key comment and the actual data. The format of each key file is: So if we set the key system/hw/eth0/driver as type String and value "3com", and comment "The driver for my network interface", we'll find the file /etc/kdb/system/hw/eth0/driver containing: Other example: setting user/tmp/proprietary as Binary, and value "A groovy data I want to hide", and comment "Stay away from here", you'll get in ~$USER/.kdb/user/tmp/proprietary the following: The current data types are: Between 20 and 39 40 up to 254 Types between 0 and 19 are used only internaly in the API, and will never appear into a key file. They are used to define meta keys as directory, link, etc. elektra(7) A framework to store configuration atoms hierarchically Library Linkage Architecture.PP The Elektra library (libelektra.so) has 2 layers: public methods and backend access, according to the following architecture (these pictures were taken from the Elektra presentation[1]): When using local backends such as the filesys backend, all key access happens in the actual process space as bellow: A remote daemon backend is also possible as noted bellow: True Facts About Elektra Elektra Is Not Namespaces and Key Names.PP All keys are organized in a hierarchical tree with 2 Namespaces (subtrees) as showed by the picture: system user User Domains.PP Different from the system namespace, the user namespace is dynamic. For example, the key user/env/PATH may have completely different values for users luciana and valeria. In this example, if valeria wants to access this key at luciana's space, it should refer to user:luciana/env/PATH. Access permissions apply. User domains were implemented also to address situations when different user names ($USER) have same UID. So a user key is stored in his home directory based on the user name, not the UID. Inactive Keys.PP A great thing about text configuration files is that some configuration items can be there as an example, but inactive or commented. Elektra provides a very simple way to simulate this behavior: if the key name begins with a dot (.), it is considered inactive or commented. In real world applications, the Elektra API will ignore these keys by default, but the keys are still accessible if the developer wants to. These are some keys that have inactive subtrees: See bellow more examples of inactive keys. Key Examples.PP Here are some valid key names, and their values: The Elektra keys of the combined /etc/passwd and /etc/shadow entry for user 'nobody' would look like: The environment variables I want set, when I log in, with their full key name: The entry in /etc/inittab that is responsible for starting X11 would look: The users database files and /etc/inittab were Elektrified to key-value pairs using the users-convert and inittab-convert scripts included with the distribution. An example of an elektrified /etc/X11/xorg.conf or /etc/X11/XF86Config: Pay attention that the keys bellow system/sw/XFree/current/Monitor/.Monitor1 are inactive because we have .Monitor1 as their parent. So unless special options are used when calling the API, these keys will not be retrieved from the database. Throughout this text you will see other examples of key names. Key Data Types.PP There are only two types of data that can be stored: Text Binary There are very good reasons why types like Integer, Time, Font, List, etc were not implemented: Elektra was designed to be useful for any type of program, so having more specific data types implicates in the definition of value limits, separators in the storage format, etc, that may be good for some application and bad for other. So the semantics of the data is handled by the application. A program or framework may define its own special data handling methods using these essential basic types. See the keyGetType() and keySetType() methods documentation in the kdb(3) man page to understand how to set keys with your own data types. There are more two types of keys: Directory Link Key Meta Data.PP Besides the key name and the value, each key has other attributes: Owner's User and Group Access Permissions Modification, Access and Stat Times Key Comment Fine Grained Security Example.PP To show this metadata in action, this screen shows the kdb command listing keys and their attributes related to user nobody. We ran the kdb command without super-user credentials, asking for long (-l), recursive (-R) listing, and to show each key value (-v). But (since we are) regular user, we don't have permission to see the values of the system/users/nobody/passwd* fields. The users database files were elektrified to key-value pairs using the users-convert script included with the distribution. ExamplesSetting Keys.PP bash$kdb set -c "My first key" user/example/key "Some nice value" bash$kdb set user:luciana/example/key -- "Some - nice - value with dashes" bash#KDB_ROOT=user:http/sw/httpd kdb set -u nobody -g http key "Some value" bash$kdb set -b image.png -t bin user/example/binaryKey bash$kdb set -b file.txt user/example/regularKey bash#kdb set -t link system/sw/XFree/current system/sw/XFree/handmade Getting Keys.PP bash$KDB_ROOT=user/example kdb get some/key/name bash$eval `kdb get -s user/env/env1/PS1` bash$KDB_BACKEND=gconf kdb get user/sw/gnome-terminal/global/active_encodings Listing.PP bash$kdb ls -laR user:valeria bash$kdb ls -lR system/sw/xorg/current bash$KDB_ROOT=system/sw kdb ls -lR xorg bash$KDB_BACKEND=fstab kdb ls -Rv system/filesystems bash$eval `kdb ls -Rvs user/env/env2` Miscelaneous.PP bash#kdb ln system/sw/xorg/handmade system/sw/xorg/current bash#kdb mv system/sw/xorg/current system/sw/xorg/old bash#kdb rm system/inittab/rc4 bash$KDB_BACKEND=gconf kdb rm user/gconfKey XML Import and Export.PP bash#kdb export user/sw/app | sed -e 's|/app/|/app2/|g' | kdb import bash#KDB_ROOT=system/sw kdb export myapp > myappconf.xml bash#kdb import myappconf.xml bash$KDB_BACKEND=gconf kdb export user/sw

Usage

Environment

Releases

See also

Mentioned on this page

Referred to by