José Luis Tallón wrote: >* 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 > > Yeah, the idea of multiple backend mapping is to allow you to map what you want to the backend of your choice. By the way, using kdbd + berkeleydb storing user:/ to their respective user's home directories will impose you to run this kdbd instance as root. But this is why i defend idea of multiple backend mapping since the begining : that brings flexibility and you can do what you want. And that would not be complex as hell to implement.
>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? ; > > Could you give more details please. Don't know if i uderstood you well ... you mean sort of "dynamic mapping" ? Use filesys for low level stuff directy. Then, when daemon is here, use it ? That mean a same configuration could be handled by two different backend depending wherever daemon is launched or not. I'm not really happy with this. Why not simply let mappings exactly like how they have been configured ? >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. > > This is how things are done yet, using SO_PASSCRED. >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 ) > > For me filesys don't have to be used with kdbd. More over, caching stuff under filesystem/ will probably not increase global performance a lot since stuff residing here aren't used oftenly (system/init, system/filesystems). The fact is i would have maximum flexibility and KISS (Keep It Simple, Stupid) as possible. Creating dynamicly pipe, process, agent will simply add complexity without adding (IMHO) enought good value. Adding caching stuff to kdbd is something i'm thinking too. Its "easy" to do for local backends (understand stored localy on filesystem) but not as easy for remote backends : cache system have to be aware about each modification done and these modifications could have be done not by you (your instance of kdbd). Afaik, LDAP allow you to monitor some branch/objectClass for modification. But for SQL that's another story ... So perhaps caching stuff would probably have to be done in the real backends themself rather than into kdbd. Regards, Yannick. ------------------------------------------------------------------------- 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
