Yannick Lecaillez wrote:
> In fact i think we're discuss about a problem which couldn't exist :-p
> multiple backend and mapping fix all problems in a easier way to
> implement and could fit to every usage :
>
> * usage 0 : map everything to filesys
> - Pros : reliable, no daemon, no spof
> - Cons : Slow, inode consuming, waste disk space, fill system FS
> with "useless" things.
>
> * usage 1 : map everything to elektra.elektra kdbd + berkeleydb stored
> into a fixed place.
> - Pros : No root daemon, fast. Centralized
> - Cons : Users can't backup their settings easily, can't be used
> for SysVinit
>
> * usage 2 : map system/ to filesys directly, system/sw + user:/ to
> elektra.elektra kdbd + berkeleydb stored into a fixed place.
> - Pros : No root daemon
> - Cons : Can't backup easily, can't share trought user's home
> directory
>
> * usage 3 : map user:/ and system/ to filesys directly, system/sw/ to
> elektra.elektra kdbd + berkeleydb stored in a fixed place
> - Pros : No root daemon, user settings are stored into user's
> home directory (backup easily, share easily)
> - Cons : user:/ is using slow and inode consuming filesys
>
> * usage 4 : map user:/ and system/ to filesys directly, system/sw/ to
> elektra.elektra kdbd + mysql (or ldap, or whatever)
> - Pros : No root daemon, system settings are centralized for
> several computer. settings into user's home directory (backup easily,
> share easily)
> - Cons : user:/ is using slow and inode consuming filesys, can't
> share users settings trought different location at same time
>
> * usage 5 : map system/ to filesys directly, system/sw + user:/ to
> elektra.elektra kdbd + mysql (or ldap, or whatever)
> - Pros : No root daemon, settings are centralized. user can use
> its settings at different location at same time
> - Cons : Could be slow depend of rdbms server speed, network
> speed & latency, etc ...
>
> * usage n : add your favorite here
>
My suggestion (basically what I said before, but adding LDAP/MySQL)
* map system/ to filesys directly
* map system/sw to /var/lib/elektra/system-sw.db (640 elektra.elektra)
- or LDAP
- or MySQL
* map user to either $HOME/.kdb/user.db
- or LDAP
- or MySQL
And the approach:
* filesys (direct) for init-like programs
* As soon as the daemon is running (libelektra checks if
/var/run/kdbd.sock is there), use the controller/slaves model which
Bárður has described before (a refinement of my original proposal). This
is the model used by many *high performance and secure* servers, such as
Apache and Postfix. Why not trust them for this? ;)
Regarding security, the UNIX-domain connection method allows
libelektra.so the credentials of the calling process through the socket,
so that the user's permissions can be checked when accessing the
*shared* Berkeley-DB-backed configuration store.
One additional plus: the daemon (kdbd) can even *cache* the
filesys-backed configuration (which would be stored under
/etc/elektra/system/* ) into a BDB (or even memory!) a single inotify
handle would allow the daemon to invalidate/rebuild its cache upon
modification of filesys-backed config by the administrator (as opossed
to using kdb / kdbedit )
J.L.
P.S.: I can write this a bit more detailed into a design document and
even put it into the Wiki (if given access, that is)
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Registry-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/registry-list
