[Dovecot] Mongo backend for userdb and passdb
Hi,
I was wondering if any work had been made (out of tree) or has been planned for a mongo driver? If not is it something that would be of any interest for being included?
Regards, Damien
On 28.2.2013, at 12.28, Damien Churchill damoxc@gmail.com wrote:
I was wondering if any work had been made (out of tree) or has been planned for a mongo driver? If not is it something that would be of any interest for being included?
Have you noticed the memcached and redis backends for lib-dict, and the passdb/userdb dict? So you'd only need to implement dict-mongodb.c for Dovecot v2.2. Feel free to start developing. :) v2.2 also has its own lib-http if that's needed.
On 28 February 2013 14:01, Timo Sirainen tss@iki.fi wrote:
On 28.2.2013, at 12.28, Damien Churchill damoxc@gmail.com wrote:
I was wondering if any work had been made (out of tree) or has been planned for a mongo driver? If not is it something that would be of any interest for being included?
Have you noticed the memcached and redis backends for lib-dict, and the passdb/userdb dict? So you'd only need to implement dict-mongodb.c for Dovecot v2.2. Feel free to start developing. :) v2.2 also has its own lib-http if that's needed.
I hadn't no! That makes things far easier :) Do you have any preference on which driver to use? I was thinking of selecting libmongo-client[0] as its made its way into repositories unlike the official mongo C driver.
On 28.2.2013, at 15.13, Damien Churchill damoxc@gmail.com wrote:
On 28 February 2013 14:01, Timo Sirainen tss@iki.fi wrote:
On 28.2.2013, at 12.28, Damien Churchill damoxc@gmail.com wrote:
I was wondering if any work had been made (out of tree) or has been planned for a mongo driver? If not is it something that would be of any interest for being included?
Have you noticed the memcached and redis backends for lib-dict, and the passdb/userdb dict? So you'd only need to implement dict-mongodb.c for Dovecot v2.2. Feel free to start developing. :) v2.2 also has its own lib-http if that's needed.
I hadn't no! That makes things far easier :) Do you have any preference on which driver to use? I was thinking of selecting libmongo-client[0] as its made its way into repositories unlike the official mongo C driver.
Any external library actually makes things more difficult, because they can easily only be loaded by the dict server, which means every lookup have to be proxied through it (similar problem with dict-sql). Although in v2.2 there's some new code for how to load SSL library dynamically only when needed, and the same could be done for your dict-mongodb at least in theory..
On 28 February 2013 14:40, Timo Sirainen tss@iki.fi wrote:
On 28.2.2013, at 15.13, Damien Churchill damoxc@gmail.com wrote:
On 28 February 2013 14:01, Timo Sirainen tss@iki.fi wrote:
On 28.2.2013, at 12.28, Damien Churchill damoxc@gmail.com wrote:
I was wondering if any work had been made (out of tree) or has been planned for a mongo driver? If not is it something that would be of any interest for being included?
Have you noticed the memcached and redis backends for lib-dict, and the passdb/userdb dict? So you'd only need to implement dict-mongodb.c for Dovecot v2.2. Feel free to start developing. :) v2.2 also has its own lib-http if that's needed.
I hadn't no! That makes things far easier :) Do you have any preference on which driver to use? I was thinking of selecting libmongo-client[0] as its made its way into repositories unlike the official mongo C driver.
Any external library actually makes things more difficult, because they can easily only be loaded by the dict server, which means every lookup have to be proxied through it (similar problem with dict-sql). Although in v2.2 there's some new code for how to load SSL library dynamically only when needed, and the same could be done for your dict-mongodb at least in theory..
Okay I'll have a look at doing it that way. Is the ssl code in lib-ssl-iostream or somewhere else?
On 28 February 2013 14:47, Damien Churchill damoxc@gmail.com wrote:
On 28 February 2013 14:40, Timo Sirainen tss@iki.fi wrote:
On 28.2.2013, at 15.13, Damien Churchill damoxc@gmail.com wrote:
On 28 February 2013 14:01, Timo Sirainen tss@iki.fi wrote:
On 28.2.2013, at 12.28, Damien Churchill damoxc@gmail.com wrote:
I was wondering if any work had been made (out of tree) or has been planned for a mongo driver? If not is it something that would be of any interest for being included?
Have you noticed the memcached and redis backends for lib-dict, and the passdb/userdb dict? So you'd only need to implement dict-mongodb.c for Dovecot v2.2. Feel free to start developing. :) v2.2 also has its own lib-http if that's needed.
I hadn't no! That makes things far easier :) Do you have any preference on which driver to use? I was thinking of selecting libmongo-client[0] as its made its way into repositories unlike the official mongo C driver.
Any external library actually makes things more difficult, because they can easily only be loaded by the dict server, which means every lookup have to be proxied through it (similar problem with dict-sql). Although in v2.2 there's some new code for how to load SSL library dynamically only when needed, and the same could be done for your dict-mongodb at least in theory..
Okay I'll have a look at doing it that way. Is the ssl code in lib-ssl-iostream or somewhere else?
Hi,
I've been messing about with this and I think a similar configuration format to the sql dict driver would be handy, although I imagine the same could also be achieved with just lots of uri arguments. Mongo isn't really a key/value store so you'd want to be able to specify fields within the document to query upon/fetch.
I'm still getting to grips with the architecture of things so not entirely sure what the best course of action would be here. If using the map style config would be desirable then creating some shared parser that sql and mongodb can use would be good.
On Wed, 2013-03-20 at 10:29 +0000, Damien Churchill wrote:
I've been messing about with this and I think a similar configuration format to the sql dict driver would be handy, although I imagine the same could also be achieved with just lots of uri arguments. Mongo isn't really a key/value store so you'd want to be able to specify fields within the document to query upon/fetch.
I'm still getting to grips with the architecture of things so not entirely sure what the best course of action would be here. If using the map style config would be desirable then creating some shared parser that sql and mongodb can use would be good.
I've been planning on having one generic dict sql-like configuration for all dict backends, so you could map different dict paths to different backends. So the idea is good, but probably quite a lot of work.
On 20 March 2013 10:39, Timo Sirainen tss@iki.fi wrote:
On Wed, 2013-03-20 at 10:29 +0000, Damien Churchill wrote:
I've been messing about with this and I think a similar configuration format to the sql dict driver would be handy, although I imagine the same could also be achieved with just lots of uri arguments. Mongo isn't really a key/value store so you'd want to be able to specify fields within the document to query upon/fetch.
I'm still getting to grips with the architecture of things so not entirely sure what the best course of action would be here. If using the map style config would be desirable then creating some shared parser that sql and mongodb can use would be good.
I've been planning on having one generic dict sql-like configuration for all dict backends, so you could map different dict paths to different backends. So the idea is good, but probably quite a lot of work.
Would it not be just some bastardised version of dict-sql-settings?
On Wed, 2013-03-20 at 10:40 +0000, Damien Churchill wrote:
On 20 March 2013 10:39, Timo Sirainen tss@iki.fi wrote:
On Wed, 2013-03-20 at 10:29 +0000, Damien Churchill wrote:
I've been messing about with this and I think a similar configuration format to the sql dict driver would be handy, although I imagine the same could also be achieved with just lots of uri arguments. Mongo isn't really a key/value store so you'd want to be able to specify fields within the document to query upon/fetch.
I'm still getting to grips with the architecture of things so not entirely sure what the best course of action would be here. If using the map style config would be desirable then creating some shared parser that sql and mongodb can use would be good.
I've been planning on having one generic dict sql-like configuration for all dict backends, so you could map different dict paths to different backends. So the idea is good, but probably quite a lot of work.
Would it not be just some bastardised version of dict-sql-settings?
I guess you could do that for now. The grand plans of how to put everything nicely together can wait. :)
On 20 March 2013 10:54, Timo Sirainen tss@iki.fi wrote:
On Wed, 2013-03-20 at 10:40 +0000, Damien Churchill wrote:
On 20 March 2013 10:39, Timo Sirainen tss@iki.fi wrote:
On Wed, 2013-03-20 at 10:29 +0000, Damien Churchill wrote:
I've been messing about with this and I think a similar configuration format to the sql dict driver would be handy, although I imagine the same could also be achieved with just lots of uri arguments. Mongo isn't really a key/value store so you'd want to be able to specify fields within the document to query upon/fetch.
I'm still getting to grips with the architecture of things so not entirely sure what the best course of action would be here. If using the map style config would be desirable then creating some shared parser that sql and mongodb can use would be good.
I've been planning on having one generic dict sql-like configuration for all dict backends, so you could map different dict paths to different backends. So the idea is good, but probably quite a lot of work.
Would it not be just some bastardised version of dict-sql-settings?
I guess you could do that for now. The grand plans of how to put everything nicely together can wait. :)
For now I think I can get away with just tacking on uri arguments. Seems silly duplicating effort, although if you'd like me to give it a shot I'm happy to do so!
On 20 March 2013 10:59, Damien Churchill damoxc@gmail.com wrote:
On 20 March 2013 10:54, Timo Sirainen tss@iki.fi wrote:
On Wed, 2013-03-20 at 10:40 +0000, Damien Churchill wrote:
On 20 March 2013 10:39, Timo Sirainen tss@iki.fi wrote:
On Wed, 2013-03-20 at 10:29 +0000, Damien Churchill wrote:
I've been messing about with this and I think a similar configuration format to the sql dict driver would be handy, although I imagine the same could also be achieved with just lots of uri arguments. Mongo isn't really a key/value store so you'd want to be able to specify fields within the document to query upon/fetch.
I'm still getting to grips with the architecture of things so not entirely sure what the best course of action would be here. If using the map style config would be desirable then creating some shared parser that sql and mongodb can use would be good.
I've been planning on having one generic dict sql-like configuration for all dict backends, so you could map different dict paths to different backends. So the idea is good, but probably quite a lot of work.
Would it not be just some bastardised version of dict-sql-settings?
I guess you could do that for now. The grand plans of how to put everything nicely together can wait. :)
For now I think I can get away with just tacking on uri arguments. Seems silly duplicating effort, although if you'd like me to give it a shot I'm happy to do so!
Hi,
I've pushed an initial copy of what I've got so far to bitbucket[0]. I'm in two minds currently about how to correctly handle returning the json object that the userdb/passdb backend expects. Currently the config file is copying mostly what dict-sql does:
connect = host=localhost:port=27017:db=mail
map { pattern = shared/passdb/$user collection = users username_field = email value_field = password
fields {
email = $user
}}
map { pattern = shared/userdb/$user collection = users username_field = email value_field = password
fields {
email = $user
}
values {
home = /home/vmail
uid = 5000
gid = 5000
}}
value_field isn't currently used at all, and the values map just provides some default values that will be replaced if they exist in the returned document.
The part I'm wondering is how to allow the object you end returning as flexible as what is currently possible with the sql passdb/userdb queries. May have to ultimately bite the bullet and accept that it won't be. Primarily it would be good to be able to concat strings with fields returned for building the quota rule or something similar. Just wondered what your thoughts were on this?
[0] https://bitbucket.org/damoxc/dovecot-2.2-mongodb/commits/0dee37209ff9f4b2f84...
participants (2)
-
Damien Churchill
-
Timo Sirainen