1ELEKTRA(5) ELEKTRA(5)
2
6 elektra - A framework to store configuration atoms hierarchically
7 Note
9 This section is provided for the sake of the openness of Elektra. You
10 should not access the Elektra's key files directly. You should use the
11 API or the kdb(1) command for that. Elektra Key Storage Strategy.PP
12 Elektra implements a very simple way to store the key-value pairs. The
13 value (and some metainfo) for each key is stored in a single file. The
14 key name (and some of its context) is sufficient to find the file name
15 that stores the value.
16 The system/* keys are stored under /etc/kdb/, and the user/* keys can
18 be found under each user's $HOME/.kdb/.
19 Here are some examples of key names, and where Elektra goes to look for
21 them in the disk.
22 system/sw/XFree86/screen0/driver
24 Maps to: /etc/kdb/system/sw/XFree86/screen0/driver
25 user/env/PATH
27 Maps to: ~$USER/.kdb/user/env/PATH
28 user:luciana/env/PATH
30 Maps to: ~luciana/.kdb/user/env/PATH
31 system/mime.types/some.mime
33 Maps to: /etc/kdb/system/mime.types/some.mime
34 Some may think that one file per key will consume many filesystem
36 i-nodes. Actually, when not using Reiser4 filesystem, it may consume
37 some more disk space, and it may also be not so efficient than reading
38 one single text file, as KConfig does. But Elektra's nature lets
39 applications load their keys on demand; so it is possible to avoid the
40 read-all-use-some approach. Writing updated keys back to disk is also
41 more robust, because unchanged keys won't be touched, different from a
42 single file approach, that must be entirelly rewritten.
43 Besides that, big applications (like Mozilla, Konqueror, KDE, Gnome)
45 key gathering time is a very small part of what they have to do to
46 start up. And the benefits of an homogeneous key database to the entire
47 system are much bigger then these issues. Think about a common
48 integration between everything, flexibility, security granularity and
49 openness. XML, Storage Backends and Elektra.PP This document you are
50 just reading was written in DocBook XML. XML is a wonderfull
51 technology, but brings no value to this software. Two main goals of the
52 Elektra Project are to be lightweight, and to be accessible by early
53 boot stage programs like /sbin/init and the /etc/rc.d scripts.
54 XML parsing libraries are memory eaters, not so fast as we can expect,
56 and they are usualy located under /usr/lib, which may be unavailable to
57 these early boot stage needs.
58 Some discussions asked for a sort of plugin architecture to let user
60 decide the format to store keys content. Well, the info that goes into
61 the key file is not big deal as you'll see, and sometimes, too many
62 options is bad business, and not the path for the Elektra Project.
63 So no XML, no plugin architecture, no sophistication. Lets keep it
65 simple and generic. A very straight forward text based file format was
66 defined to store a single key value. Key Files Format.PP Inside
67 Elektra key database, each key is a file, and every file is a key. So
68 most of the key's metainformation are actually its file attributes, as
69 you can see in a regular ls(1) command output.
70 So what needs to be stored inside the key file is the data type (binary
72 or text), key comment and the actual data. The format of each key file
73 is:
74 File Format Version
76 Data Type
77 As many lines of
78 comments as we want (UTF-8 encoded)
79 <DATA>
80 The data encoded as text
81 So if we set the key system/hw/eth0/driver as type String and value
84 "3com", and comment "The driver for my network interface", we'll find
85 the file /etc/kdb/system/hw/eth0/driver containing:
86 RG002
88 40
89 The driver for my network interface
90 <DATA>
91 3com
92 Other example: setting user/tmp/proprietary as Binary, and value "A
95 groovy data I want to hide", and comment "Stay away from here", you'll
96 get in ~$USER/.kdb/user/tmp/proprietary the following:
97 RG002
99 20
100 Stay away from here
101 <DATA>
102 41206772 6f6f7679 20646174 61204920 77616e74 20746f20 68696465
103 The current data types are:
106 Between 20 and 39
108 Binary value. The data will be encoded into a text format. Today
109 only type 20 is used, and means a raw stream of bytes with no
110 special semantics to Elektra. The other values are reserved for
111 future use; being treated still as binary values but possibly
112 with some semantics to Elektra or a higher level application.
113 40 up to 254
115 Text, UTF-8 encoded. Values higher then 40 are reserved for
116 future or application specific implementations of more abstract
117 data types, like time/date, color, font, etc. But always
118 represented as pure text that can be edited in any text editor
119 like vi(1).
120 Types between 0 and 19 are used only internaly in the API, and will
122 never appear into a key file. They are used to define meta keys as
123 directory, link, etc.
124
126 kdb(1), elektra(7)
127
129 Avi Alkalay <avi at unix.sh>.
130Elektra Initiative March 2004 ELEKTRA(5)