[Dovecot] Developer docs?
Hi, I'm looking to modify Dovecot slightly to add support for a custom feature. I've spent some time reading the code, and I've been wondering if there are any contributor/developer documents I've missed that would make getting up to speed easier. I've read much of the code, and most of the wiki, including the Design/* and /*Process pages. They give a good summary of some of the design decisions, but I don't see much other than that. The docs included in the tarball are just dumps of the wiki pages. I've browsed some of the list archives as well, without finding much to help me. Are there other resources I've missed? What I'm trying to do requires passing some additional information/state from the imap-login process (presumably through the master) to the imap mail process. Any pointers much appreciated! Thanks, C. -- ------- C. Mills ---
Re: [Dovecot] Developer docs?
Timo Sirainen wrote: > On 25.8.2013, at 21.09, C. Mills wrote: > > > > Are there other resources I've missed? > > Nope. Maybe the docs will increase some day when there's more time and > developers. It's a real chicken-and-egg problem, that's for sure. > See how imap-login/client-authenticate.c imap_client_auth_begin() sends the > command tag to imap process. Or if it's something all login processes need > you could modify struct master_auth_request directly. Okay, thanks for the pointer. /me continues digging C. -- ------- C. Mills ---
Re: [Dovecot] Developer docs?
Timo Sirainen wrote: > On 25.8.2013, at 21.09, C. Mills wrote: > > > What I'm trying to do requires passing some additional information/state > > from the imap-login process (presumably through the master) to the imap > > mail process. Any pointers much appreciated! > > See how imap-login/client-authenticate.c imap_client_auth_begin() sends the > command tag to imap process. Or if it's something all login processes need > you could modify struct master_auth_request directly. I do see how it's put into the imap_client->common.master_data_prefix there, but it's not clear to me how to get it back *out* in the imap mail client. The only place I see that data actually used is in /login-common/sasl-server.c. For a concrete example, I'd like to pass an additional string/char * of state information from the imap-login code to imap mail client code. I think, based on the above, that you suggest putting it into the imap_client->common struct, which I've done, so that struct is then passed to client_auth_begin(), and presumably goes to the master process. But where does that information/data get passed to the imap mail client? For example, if I wanted to access it in /imap/cmd-fetch.c : cmd_fetch(), cmd->client appears to be a different structure? Thanks, C. C. -- --- C. Mills ---
[Dovecot] Solved: startup failures "net_listen_unix(...) failed: Invalid argument"
I ran into this and had a bit of trouble tracking a diagnosis down, so here it is for the archives in case anyone else runs into this. A new installation of dovecot was failing to start, with these messages: $ ./sbin/dovecot Error: service(imap-urlauth): net_listen_unix(.../var/run/dovecot/token-login/imap-urlauth) failed: Invalid argument Error: service(auth): net_listen_unix(.../var/run/dovecot/token-login/tokenlogin) failed: Invalid argument Fatal: Failed to start listeners Some of the other processes seemed to be starting up fine, and they created sockets in the expected dir, but the above two wouldn't. stracing the processes didn't show a lot, but eventually I checked the length of the installation path, and found the above two socket paths were exceeding the maximum path length limit for Unix sockets -- 108 chars on my Linux boxen. I haven't checked SuS or Posix to see what the standards say the actual minimum required size for the maximum path length is -- it might be shorter yet on other systems. Moving the installation to a less deeply nested hierarchy fixed the problem. I hope this saves someone else a headache someday. C. C. -- ------- C. Mills ---
