Yannick Lecaillez wrote:
> José Luis Tallón wrote:
>
> [snip]
> I think too. But there is, at least, one disadvantage with that : its
> usual for Linux users to have a "system" partition and a home partition.
> This way, you could change/upgrade your distribution while keeping your
> home partition intact (containing your datas and your settings). That
> mean user have to backup himself its user's specifc settings using kdb
> -export otherwise these could simply be lost during
> reinstallaion/upgrading ...
>
Reinstallation will not overwrite any of the user's preferences, of course.
It is precisely the same idea as having all of KDE's config under ~/.kde
You can simply upgrade KDE and your config will still be there... and be
used!
> But the still good advantage is that permit to run daemon as user
> everytime. So, i think that need discution
>
Indeed, having an unprivileged daemon is good.
Another possibility (even though a bit more complex):
* init: use "filesys" directly -> convenient, safe, "bomb-proof"
* system apps: use BDB (or even SQL) backend, through a daemon able to
do some caching
(this is all transparent to applications, since they only need to
link libelektra.so)
* user apps: run a *user* "config agent" under the user's UID (maybe
forked from some central config daemon to have better performance and
for stability reasons [more later]], serving the user's *private* config
stored under his/her $HOME
>> Good try, wrong location.
>>
>> It should be stored under /var/lib/elektra:
>> /var/lib/elektra/system.db <= system/ namespace
>> /var/lib/elektra/user:yl.db <= user:yl/ namespace
>> /var/lib/elektra/user:foo.db <= user:foo/ namespace
>>
>> and docs can still be read from /usr/share/doc/elektra/
>>
> That's an idea, but configuration are used to be in /etc.
For text files, maybe.
We are not talking about text files necessarily anymore. If this is to
be modified by kdbedit preferably and going to be some sort of database,
it *needs* to reside under /var/lib/elektra (as per LFHS)
> But i think
> its a detail and the database location should be configurable and let
> everyone (i mean users/packagers) to decide what is better for themself
> (see "multiple-backend" post).
>
Yes, but up to a certain degree. Otherwise, this would start looking
like Windoze -- everything spread all around :-|
> [snip]
>
>> Anyway, even though I prefer an unprivileged daemon too, an "isolated
>> enough" daemon running as root in order to be able to read user's
>> preferences from their home directories might be a good idea, too.
>>
>>
>>
> Exactly, that need discution. Btw, i'll be happy to add : "* doesn't
> require something to be run as root" to the "True facts about elektra" :-)
>
> Hmm ... just got an idea .... Why not store system settings into
> /etc/<somewhere> (or /var/lib/<somewhere>) and user's specific into
> /home/elektra ? This way users keep their settings if they
> change/upgrade their distros and we don't have to run kdbd as root.
>
The solution I propose above goes like this:
* For the system/ namespace:
- system-wide config within /var/lib/elektra (plus backend config under
/etc/elektra, of course)
- system-wide daemon running as elektra:elektra, potentially chrooted
if needed, and listening on a UNIX-domain socket under /var/run
NOTE: the daemon is *not* needed for the first part of
initialization. That is: init-like programs can pass a flag to
libelektra.so instructing it to run in "singleuser mode", that is: load
the corresponding backend in-core.
Once init and a few more processes have run, the daemon can be
launched (immediately after mounting /var in this case) and all programs
using elektra afterwards will communicate with the daemon.
either a
* "user config daemon" (a)
or
* user config agent (b)
As in:
a) daemon running as nobody:elektra, using POSIX's SAVED_UIDS where possible
(where unavailable use "root" or "local service"[win32])
It will fork when needed, use its SAVED_UID to regain privileges and
then immediately setuid() to that of the user, hence becoming
unprivileged. Only then will it open the user's configuration files. It
would create a listening socket under /tmp/.elektra-UNIX for
libelektra.so to connect to.
After a configurable amount of time not receiving queries (and only
after all clients have disconnected), it can terminate.
This will be spawned after a certain kind of request has been
received (first request for user-related config)
b) Same idea, without daemon, nor additional program running potentially
(even though this would have performance implications):
libelektra.so could simply load the appropriate backend "driver"
libelektra-<backend>.so within the process and use it directly.
Drawback: config can't be locked.
Alternative which *does* work: spawn a config agent which behaves as
the "user component" described above: run upon first request for user/
namespace, stay for a while after last client has disconnected, then
terminate (just like ssh-agent, for example)
I think this pretty much covers all your needs... libelektra.so becomes
a sort of "intelligent multiplexer" which services requests with the
best method available, and provides a uniform interface / source
compatibility (and binary also, most of the time)
As usual, any suggestions / comments / etc are welcome (but please
redirect flames to /dev/null ;) )
J.L.
-------------------------------------------------------------------------
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
