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
I really invite you to read previous post about multiple backend if you
didn't do it yet :
http://article.gmane.org/gmane.comp.lib.elektra.devel/23/match=mapping
Regards,
Yannick.
Bárður Árantsson wrote:
>Yannick Lecaillez wrote:
>
>
>>(sorry for the big cut of the discussion, but that beginned a bit hard
>>to snip it correctly ... :-p)
>>
>>Bárður Árantsson wrote:
>>
>>
>>
>>>I hope I'm not misunderstanding you, but the daemon cannot be run as the
>>>user: It will not have the necessary access to system configuration
>>>settings -- unless it happens to use the filesys backend which works by
>>>virtue of the file system ACLs being identical with the Elektra ACLs.
>>>
>>>
>>>
>>>
>>Daemon will be not runned as "the" user, but "as" user : Imagine a
>>specific "elektra" special user (without shell). This user is then like
>>"root" of configuration stuff. Not the system administrator, but the
>>configuration administrator.
>>
>>
>>
>
>Ok, got it now.
>
>
>
>>(but *not* to write settings into "real" users home directories)
>>
>>
>
>I see this as a serious problem. (Because of the backup/multiple
>machines issue.)
>
>
>
>>>The backup issue is interesting though... If the user settings are to be
>>>stored in the user's home directory then the daemon could spawn a
>>>subprocess (which could setuid) for each user that is connected to it,
>>>and direct all requests for user keys to the appropriate sub-process and
>>>handle system keys itself.
>>>
>>>
>>>
>>>
>>That's interesting but that seems a bit complex to implement : Have you
>>got some idea how to implement "main" daemon to user specific daemon
>>communication ? Memory sharing (mutex) ? Pipe (another layer to traverse
>>: user application -> pipe -> main daemon -> pipe -> user specific
>>daemon) ? Create pipe "on the fly" (user application -> main pipe ->
>>main daemon (launching new kdbd process as user.user, creating a new
>>pipe dedicated to this user) then user application -> dedicated pipe ->
>>user specific daemon) ?
>>
>>
>
>I was thinking of the last one (but see below...). Shared memory is
>generally just a bad idea in general because it is too error-prone to
>get the locking right. IIRC pipes are actually zero-copy on Linux, so no
>extra copying overhead is incurred.
>
>Thinking about it some more one could actually get away with using the
>exact same program for both the user-specific daemon and the system daemon:
>
> (Frontend)
> Daemon
> |
> / \
> / \
> / \
> / \
> / \
> "/" (system) "user:"
> daemon daemon
>
>The frontend daemon (the one the user programs would actually
>communicate with) would be a program running as root which could
>spawn the "/" (system) daemon at startup (running as elektra:elektra),
>and it could start "user:" daemons as necessary (running as the
>particular user). Then the main job of the frontend daemon would be
>to interpret the paths in requests and directing the requests to the
>appropriate daemon.
>
>(If one is willing to accept the possible security implications, these
>actually don't really have be be separate processes, but they must not
>be able to block each other's I/O).
>
>
>
>>>I definitely think user settings should be stored in the user's home
>>>directory. If the user wants to share settings across multiple machines
>>>this is pretty much the only option.
>>>
>>>
>>>
>>You mean, as example, somebody who is exporting its home trought NFS to
>>different machine (nis/yellowpage) ?
>>That's a really good point.
>>
>>
>
>Yes, or even just synchronizing through something like unison. If the
>user configuration is stored somewhere other than the user's home
>directory, a user would need a customized way to synchronize just for
>elektra (using "-export"). If the user's configuration is stored in the
>user's home directory, they can just synchronize the files directly
>(Probably only makes sense with "filesys" backend, but I think it is
>something worth considering.)
>
>
>
>>>(There is technically another
>>>option, namely only running a single daemon and letting the user specify
>>> which daemon to use for user: settings. However, I think this
>>>complicates matters even further by requiring the daemon to be
>>>accessible over the network, etc.)
>>>
>>>
>>>
>>>
>>That don't require daemon to be accessible over the network : map user:/
>>to kdbd + a libelektra-mysql backend and let libmysql do the hard work
>>(locking, networking, ...). That let you keep your settings centralized
>>while using these at different place "at the same time" : PDA, Laptop,
>>Home computer, Work computer ... Could be interesting.
>>
>>
>
>... which would force you to run a full-blown RDBMS with all the added
>complications of that. Administrative headaches aside, if your different
>networks are far apart (latency-wise) your programs will slow to a crawl
>with a centralized approach.
>
>The only other system which I can think of right now which handles this
>kind of thing reasonably well is LDAP. That might be *very* interesting
>as a backend since it
>
>a) natively supports replication to multiple sites (thus avoiding the
>latency issue), and
>
>b) is already hierarchical in nature, thus avoiding an awkward mapping
>onto the relational model.
>
>Of course setting up LDAP is a pain, but probably no less of a pain than
>setting up MySQL. (And it would only be necessary in "enterprise"
>scenarios).
>
>It's been a long time since I looked at LDAP but IIRC it may even
>support some fancy means of conflict resolution which is "sensitive" to
>the hierarchical nature of the data.
>
>
>
>>So i think there are good point about sharing settings trought home
>>directory and there are good points too to sharing settings trought
>>elektra ...
>>Don't forget sharing settings trought home directory will always be
>>possible using filesys backend directly without daemon.
>>
>>
>>
>>>>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.
>>>>
>>>>
>>>>
>>>This doesn't really work with setups where users are spread out over
>>>multiple physical volumes. For anything like that is is equivalent to
>>>just storing the user keys in the same place as the system keys.
>>>
>>>
>>>
>>>
>>That's right. But i think in a context of a single-computer "home
>>usage", that still interesting.
>>For users spread out over multiple physical volumes, that's a "real
>>installation" and you could think about using libelektra-mysql or using
>>libelektra-filesys directly.
>>
>>
>
>Sure, it solves the immediate problem without addressing the larger
>problem. The "store user config in $HOME" approach solves the problem
>and also addresses the larger problem (though admittedly not fully).
>
>
>
-------------------------------------------------------------------------
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
