[Dovecot] What causes dovecot to rebuild dovecot-uidlist?
Hello, In what situations will Dovecot 1.2.11 rebuild its uidlist? I am using the maildir storage format, and I am also modifying the uidlist manually (so it's possible I could jack* things up). I have found some related code in maildir-uidlist.c: maildir_uidlist_next. 1) Blank filename or UID 0 2) Any UID not being greater than the proceeding UID 3) Any UID being greater than ~4 billion. 4) Any UID being greater than the suggested next uid. 6) If a filename contains a / 7) General header line sanity checking. Are there any other sections of the code that do sanity checks on dovecot-uidlist (for Maildir type storage)? And optionally do you agree that maildir_uidlist_set_corrupted is the best place to watch to see if I have mangled the uidlist? Thanks in advance, Pat * I insert into dovecot-uidlist manually when I deliver new messages, or discover a message that is not in uidlist for some reason. For compatability reasons I maintain a completely separate cache. If there is a better way to keep the uidlist up to date when the user isn't necessarily accessing the account via dovecot imap, I'm open to suggestions. However my situation is fairly unique I think.
Re: [Dovecot] Expire plugin
Actually, this is where the problem is coming in. We'd switched the server from using IMAPS to IMAP, and I'd neglected to change the folder location. So, now using the mail/Trash folder, I'm again seeing the permission denied. We'd determined that the dict-server socket that was being used was a stale one. So, we removed it, and are now getting a "No such file or directory" error. How is this socket created? I'd have thought it would be created upon Dovecot starting up, but it is not doing so. Is it something in the plugin settings that causes this to be created? Thanks! * * Tom Goerger - Email/Unix System Administrator * * * * University of Minnesota Email: t...@umn.edu * * Operations, Infrastructure and Architecture Phone: 4-5804 * * Internet ServicesOffice: 626J WBOB* * * * On Fri, 23 Apr 2010, Thomas M Goerger wrote: > I do now see on the console: > > Apr 22 16:56:14 mars.tc.umn.edu imap(testg019): : > net_connect_unix(/var/opt/dovecot/run/dovecot/dict-server) failed: Connection > refused > > I owned this file to mysql:mysql now, and the error has gone away on > subsequent logins, but I still don't see anything in the db. > > Thanks! > > * > * Tom Goerger - Email/Unix System Administrator * > * * > * University of MinnesotaEmail: t...@umn.edu * > * Operations, Infrastructure and Architecture Phone: 4-5804 * > * Internet Services Office: 626J WBOB* > * * > * > > On Fri, 23 Apr 2010, Thomas M Goerger wrote: > > > Yes, the plugin is loading. The libraries associated are being touched > > upon user login, so it looks like expire is running. Just that nothing is > > being added to the database upon a user putting something into the Trash. > > We do have our mail not in root of a user folder, but in mail/. So, I > > added mail/Trash to the plugin settings thinking that that was the > > problem, but there was no difference. I checked to make sure that the > > user that I'd set up in the db had the correct permissions to be able to > > talk to the right db and tables. Does it need to have any global > > permissions set? > > > > Most importantly though, is there any logging being done anywhere? > > Anything I can check to see what interaction might be happening between > > dovecot and the db? > > > > Thanks! > > > > * > > * Tom Goerger - Email/Unix System Administrator * > > * * > > * University of Minnesota Email: t...@umn.edu * > > * Operations, Infrastructure and Architecture Phone: 4-5804 > > * > > * Internet ServicesOffice: 626J WBOB* > > * * > > * > > > > On Fri, 23 Apr 2010, Steffen Kaiser wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > On Thu, 22 Apr 2010, Thomas M Goerger wrote: > > > > > > > expires table when I look. Is there anywhere that expire can log to so > > > > I > > > > can see what might be happening? It doesn't look like it logs to the > > > > > > Did you checked that the plugin is loaded at all? > > > > > > Regards, > > > > > > - -- > > > Steffen Kaiser > > > -BEGIN PGP SIGNATURE- > > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > > > iQEVAwUBS9FRQr+Vh58GPL/cAQIBVgf6AnYmZqePcumF1g1tmz+TxMlInf3T44Rk > > > anYKFYRY0SfF/pDyyJLAYzQHDK1/57qT6H1CND4MdYlPHW2uGXAdwd+7HH4XuA/v > > > bCSqWX+MreDFkxb6TXutMJ+4ymyJNK+y1Hs8vyPS1Pq76Lg1V2TkpuebKp6NfUim > > > 7d1yVFT2LmFh6MIkRUQygCD9wZcSGoeQbeheumrLO2r3p0yhnCRi/WhiPY40G31v > > > OCbHj6VXq10NRU8dr0z8Wpdq9JrIT3WEe/XoMHXz5CPKow9Kbj737zK5AT/5b/Gq > > > IlvyJb3j6YQ2QwF3G4KZvFkkC3GcdCB/QtpiciYMiEY92kSX9p/ggw== > > > =9l2w > > > -END PGP SIGNATURE- > > > > > >
Re: [Dovecot] Anyone successfully using expire plugin?
Thomas M Goerger writes:
> Anyone out there using expire? At this point, I'm not sure that it's even
> running. It was touching the plugin libraries yesterday, but doesn't
> appear to be doing so today. The plugin directory wasn't explictly set,
> so I've done so now, but it's still not touching these. Anyone have a cf
> file I could take a look at, or any ideas as to what might be happening?
I haven't followed the thread very attentively, but I am using it
(together w/ 1.2.11). At least on Linux (and possibly on Solaris) you
can use the pmap-command to determine if the plugin is actually loaded
(should be loaded by the 'mail processor' processes, 'pop3' or
'imap'). For a pop3-process I just looked at, this looks like this:
19612: pop3
Address Kbytes Mode Offset DeviceMapping
08048000 672 r-x-- 008:6 pop3
080f 8 rw--- 000a7000 008:6 pop3
080f2000 472 rw--- 000:0 [ anon ]
b7f37000 32 r--s- 008:8 dovecot.index.cache
b7f3f000 32 r--s- 008:8 dovecot.index.log
b7f47000 4 rw--- 000:0 [ anon ]
b7f48000 60 r-x-- 008:6 libpthread-2.3.6.so
b7f57000 4 rw--- e000 008:6 libpthread-2.3.6.so
b7f58000 8 rw--- 000:0 [ anon ]
b7f5a0001172 r-x-- 008:6 libc-2.3.6.so
b807f000 28 rw--- 00125000 008:6 libc-2.3.6.so
b8086000 16 rw--- 000:0 [ anon ]
b808a000 28 r-x-- 008:6 librt-2.3.6.so
b8091000 4 rw--- 6000 008:6 librt-2.3.6.so
b8092000 8 r-x-- 008:6 libdl-2.3.6.so
b8094000 4 rw--- 1000 008:6 libdl-2.3.6.so
b8097000 12 r-x-- 008:6 lib20_expire_plugin.so
b809a000 4 rw--- 2000 008:6 lib20_expire_plugin.so
b809b000 12 rw--- 000:0 [ anon ]
b809e000 84 r-x-- 008:6 ld-2.3.6.so
b80b3000 4 rw--- 00014000 008:6 ld-2.3.6.so
bfbf1000 84 rw--- 000:0 [ stack ]
e000 4 r-x-- 000:0 [ anon ]
mapped: 2756Kwriteable/private: 652Kshared: 64K
I am using a PostgreSQL table created according to the instructions in
the Wiki and my configuration is (excerpt):
- dovecot.conf ---
protocol pop3 {
pop3_uidl_format = %08Xu%08Xv
pop3_save_uidl = yes
mail_max_userip_connections = 3
mail_plugins = expire
}
[...]
dict {
expire = multi-pgsql:/etc/dovecot-pmg-cfg/dovecot-expire.conf
}
plugin {
expire = * 7
expire_dict = proxy::expire
}
--
--- dovecot-expire.conf --
connect = dbname=a user=b password=c
map {
pattern = shared/expire/$user/$mailbox
table = expires
value_field = expire_stamp
fields {
username = $user
mailbox = $mailbox
}
}
--
which is just an adjusted copy of the example configuration
(multi-pgsql is a custom PostgreSQL driver used by this application).
[Dovecot] Anyone successfully using expire plugin?
Anyone out there using expire? At this point, I'm not sure that it's even running. It was touching the plugin libraries yesterday, but doesn't appear to be doing so today. The plugin directory wasn't explictly set, so I've done so now, but it's still not touching these. Anyone have a cf file I could take a look at, or any ideas as to what might be happening? Thanks! * * Tom Goerger - Email/Unix System Administrator * * * * University of Minnesota Email: t...@umn.edu * * Operations, Infrastructure and Architecture Phone: 4-5804 * * Internet ServicesOffice: 626J WBOB* * * *
[Dovecot] How can I make dovecot aware of user's email aliases?
Sieve will not reply to mail it doesn't think was sent directly to a user. I use an SQL auth backend, and a user might login as us...@domain.com. What method can I use to inform dovecot that us...@domain.com is a forward to us...@domain.com, such that the vacation auto response will fire when us...@domain.com is emailed (therefore, the mail ends up in us...@domain.com's mailbox). -- Blog: http://pookey.co.uk/blog Follow me on twitter: http://twitter.com/ipchristian
Re: [Dovecot] Expire plugin
I do now see on the console: Apr 22 16:56:14 mars.tc.umn.edu imap(testg019): : net_connect_unix(/var/opt/dovecot/run/dovecot/dict-server) failed: Connection refused I owned this file to mysql:mysql now, and the error has gone away on subsequent logins, but I still don't see anything in the db. Thanks! * * Tom Goerger - Email/Unix System Administrator * * * * University of Minnesota Email: t...@umn.edu * * Operations, Infrastructure and Architecture Phone: 4-5804 * * Internet ServicesOffice: 626J WBOB* * * * On Fri, 23 Apr 2010, Thomas M Goerger wrote: > Yes, the plugin is loading. The libraries associated are being touched > upon user login, so it looks like expire is running. Just that nothing is > being added to the database upon a user putting something into the Trash. > We do have our mail not in root of a user folder, but in mail/. So, I > added mail/Trash to the plugin settings thinking that that was the > problem, but there was no difference. I checked to make sure that the > user that I'd set up in the db had the correct permissions to be able to > talk to the right db and tables. Does it need to have any global > permissions set? > > Most importantly though, is there any logging being done anywhere? > Anything I can check to see what interaction might be happening between > dovecot and the db? > > Thanks! > > * > * Tom Goerger - Email/Unix System Administrator * > * * > * University of MinnesotaEmail: t...@umn.edu * > * Operations, Infrastructure and Architecture Phone: 4-5804 * > * Internet Services Office: 626J WBOB* > * * > * > > On Fri, 23 Apr 2010, Steffen Kaiser wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Thu, 22 Apr 2010, Thomas M Goerger wrote: > > > > > expires table when I look. Is there anywhere that expire can log to so I > > > can see what might be happening? It doesn't look like it logs to the > > > > Did you checked that the plugin is loaded at all? > > > > Regards, > > > > - -- > > Steffen Kaiser > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > iQEVAwUBS9FRQr+Vh58GPL/cAQIBVgf6AnYmZqePcumF1g1tmz+TxMlInf3T44Rk > > anYKFYRY0SfF/pDyyJLAYzQHDK1/57qT6H1CND4MdYlPHW2uGXAdwd+7HH4XuA/v > > bCSqWX+MreDFkxb6TXutMJ+4ymyJNK+y1Hs8vyPS1Pq76Lg1V2TkpuebKp6NfUim > > 7d1yVFT2LmFh6MIkRUQygCD9wZcSGoeQbeheumrLO2r3p0yhnCRi/WhiPY40G31v > > OCbHj6VXq10NRU8dr0z8Wpdq9JrIT3WEe/XoMHXz5CPKow9Kbj737zK5AT/5b/Gq > > IlvyJb3j6YQ2QwF3G4KZvFkkC3GcdCB/QtpiciYMiEY92kSX9p/ggw== > > =9l2w > > -END PGP SIGNATURE- > > >
Re: [Dovecot] best choice of user database file to work with postfix
On Fri, 23 Apr 2010 16:07:20 +0100 Ed articulated: > Err to be fair, I was about to reply and say that it's IS achievable, > but on the flip side I would concede that it does require a bit of > thought to make this stuff work correctly. I think you are being a > bit harsh to suggest it's *that* simple to make an automated push > work reliably? Sorry, I did not mean that it was trivial, although it is not exactly rocket science either. I was simply countering the statement that the whole MySQL daemon process would have to be shut down to achieve a reliable backup/export was incorrect. > So in summary, it IS possible, but yes it does need a bit of thought, > fair enough. Again, I did not mean to offend anyone. Sorry! -- Jerry dovecot.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ The chief enemy of creativity is "good" sense. Picasso signature.asc Description: PGP signature
Re: [Dovecot] best choice of user database file to work with postfix
On 23/04/2010 15:51, Jerry wrote: There are numerous ways to export/backup a live MySQL database. I have employed several of them myself. You might want to check out this URL for starters: http://www.noupe.com/how-tos/10-ways-to-automatically-manually-backup-mysql-database.html Your statement that the only safe way to backup/export an SQL database is to stop it, etc is totally incorrect. No offense, but I question your knowledge of SQL, and MySQL in particular. Err to be fair, I was about to reply and say that it's IS achievable, but on the flip side I would concede that it does require a bit of thought to make this stuff work correctly. I think you are being a bit harsh to suggest it's *that* simple to make an automated push work reliably? So in summary, it IS possible, but yes it does need a bit of thought, fair enough. I am somewhat perplex by you insinuation that the end users of this database system you are designing are total novices. Depending on the table:type you choose, you may very well have to invoke 'postmap' and perhaps 'postaliase' on them to make them usable by Postfix. If your intended audience is so incompetent that they cannot handle a simple SQL database, how do you expect them to handle the intricacies of getting this database you are designing serviceable? It is my own opinion; however, I think you are basing your decision on a fear of SQL more than on simplifying the final database decision. A simple SQL would greatly simplify maintenance and security. Then again, you are going to be the one who takes the heat if this blows up in your face. The OP has noted (offlist) some extra facts. Basically he has an upstream setup which will generate all the files - these will then be pushed down to the remote sites in an automated fashion, therefore there will be no editing of the local files. The situation is simply a case of finding the most efficient way to push the static data down to the remote sites From that point of view I still think a DB is a useful option, but the text/BDB options are also much more sensible Cheers Ed W
Re: [Dovecot] best choice of user database file to work with postfix
On Fri, 23 Apr 2010 09:03:02 -0400 Phil articulated: > You rsync the files an SQL database (like MySQL) works from, and don't > expect corruption? That's only safe if the database is synced and > shut down. I don't want to be doing that. If I did run a database > engine, it would have to import everything ... as a single massive > transaction (or maybe a live table switch scenario between two > tables). To back it up I'd either export the entire table to a file > (and send that off to the archive), or just back up the file I used > to import with. There are numerous ways to export/backup a live MySQL database. I have employed several of them myself. You might want to check out this URL for starters: http://www.noupe.com/how-tos/10-ways-to-automatically-manually-backup-mysql-database.html Your statement that the only safe way to backup/export an SQL database is to stop it, etc is totally incorrect. No offense, but I question your knowledge of SQL, and MySQL in particular. If you need help with SQL, I know plenty of individuals, including myself, who would be willing to help you design a usable one for your needs. I am somewhat perplex by you insinuation that the end users of this database system you are designing are total novices. Depending on the table:type you choose, you may very well have to invoke 'postmap' and perhaps 'postaliase' on them to make them usable by Postfix. If your intended audience is so incompetent that they cannot handle a simple SQL database, how do you expect them to handle the intricacies of getting this database you are designing serviceable? It is my own opinion; however, I think you are basing your decision on a fear of SQL more than on simplifying the final database decision. A simple SQL would greatly simplify maintenance and security. Then again, you are going to be the one who takes the heat if this blows up in your face. -- Jerry dovecot.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Entropy requires no maintenance. Markoff Chaney signature.asc Description: PGP signature
Re: [Dovecot] Expire plugin
Yes, the plugin is loading. The libraries associated are being touched upon user login, so it looks like expire is running. Just that nothing is being added to the database upon a user putting something into the Trash. We do have our mail not in root of a user folder, but in mail/. So, I added mail/Trash to the plugin settings thinking that that was the problem, but there was no difference. I checked to make sure that the user that I'd set up in the db had the correct permissions to be able to talk to the right db and tables. Does it need to have any global permissions set? Most importantly though, is there any logging being done anywhere? Anything I can check to see what interaction might be happening between dovecot and the db? Thanks! * * Tom Goerger - Email/Unix System Administrator * * * * University of Minnesota Email: t...@umn.edu * * Operations, Infrastructure and Architecture Phone: 4-5804 * * Internet ServicesOffice: 626J WBOB* * * * On Fri, 23 Apr 2010, Steffen Kaiser wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thu, 22 Apr 2010, Thomas M Goerger wrote: > > > expires table when I look. Is there anywhere that expire can log to so I > > can see what might be happening? It doesn't look like it logs to the > > Did you checked that the plugin is loaded at all? > > Regards, > > - -- > Steffen Kaiser > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iQEVAwUBS9FRQr+Vh58GPL/cAQIBVgf6AnYmZqePcumF1g1tmz+TxMlInf3T44Rk > anYKFYRY0SfF/pDyyJLAYzQHDK1/57qT6H1CND4MdYlPHW2uGXAdwd+7HH4XuA/v > bCSqWX+MreDFkxb6TXutMJ+4ymyJNK+y1Hs8vyPS1Pq76Lg1V2TkpuebKp6NfUim > 7d1yVFT2LmFh6MIkRUQygCD9wZcSGoeQbeheumrLO2r3p0yhnCRi/WhiPY40G31v > OCbHj6VXq10NRU8dr0z8Wpdq9JrIT3WEe/XoMHXz5CPKow9Kbj737zK5AT/5b/Gq > IlvyJb3j6YQ2QwF3G4KZvFkkC3GcdCB/QtpiciYMiEY92kSX9p/ggw== > =9l2w > -END PGP SIGNATURE- >
[Dovecot] have I been added to the mailing list
Hi, have I been added to the mailing list? Thank you.
[Dovecot] order of variable modifiers
I'd like to have a variable substitute take the domain name part, lower case it, MD5 it, and take a 2-character substring of that. Would that be like %2MLd ? The documentation on the H hash modifier described reversing with R, but expresses it at %3RHu which seems to me like it would be reversing the hash result rather than the user string. I'm undecided about MD5 vs. hash, and could go either way. But I was thinking: mail_location = /data/mail/%2MLd/%Ld/%2MLn/%Ln
Re: [Dovecot] best choice of user database file to work with postfix
On Fri, Apr 23, 2010 at 5:23 AM, Ed W wrote:
> P.S. The "idiot" who kept breaking the plain text format file in my
> original setup was da da ... me ... So given I think of myself as
> reasonably technical, I would claim that text format "databases" are way
> more fragile than you might expect (good luck getting a non technical
> user not to break the text format file from time to time...)
>
But this is more an issue of exposing the system to human failure than it is
a choice of using a flat file. If the flat file is generated by some other
system, and maybe merged with other data, and never handled by a human
except in extraordinary situations, it should be fine. This is used as a
justification for XML being a text format (that a human can read it and even
edit it, in non-routine situations).
FYI, I have done hand editing of /etc/{group,passwd,shadow} to add users.
So far I've never killed root. I still have to at times. Most recently I
did so with Ubuntu because the user management tool couldn't get it right (I
needed a specific UID/GID arrangement for compatibility with other systems,
and the GUI tool refused ... it would let me do one or the other, but not
both at the same time).
Re: [Dovecot] best choice of user database file to work with postfix
On Fri, Apr 23, 2010 at 3:45 AM, Ed W wrote: You need to look at where you are going with this One way or another you > need a database - call it a banana if you prefer, but it's still a database > whether it's a flat file or a BDB file or whatever > One must be careful with the term "database". I agree with you that it could be anything. But there are lots of people out there that assume some server daemon or engine when you say "database". And most of them assume "SQL" is in there, too. So I avoid that term. > Your requirements appear to be badly phrased. What you *appear* to want is > a black box system which is as simple to maintain as possible. However, you > have stated a bunch of hard to meet criteria such as not allowing any long > running code to support your needs (a daemon). I really don't see that you > should exclude additional daemons, simply evaluate the complete system with > and without and choose the one which is "easiest" to maintain > Yes, a black box system would have suited. But it needs to be open source (that's not a contradiction ... I just have't seen one that I can use). It also needs to be able to integrate with what I will have, which is an exported file, which I have reason to suspect will be in a spreadsheet form. 1) Yes you CAN setup something which uses a plain text database, I tried it > for a while but at 50 users I decided it was too complicated and switched to > a DB. > What complications? Were you hand editing this file? 2) You are optimistic if you don't think some user will accidently add a > halfway through the text file, completely breaking it and have the > skills to realise what they did. Or they will add a "," in the middle of a > password and change the meaning of all your fields. Or they will miss a > field save the file and then never realise their mistake. Better yet are > errors which cause some external (grep,sed,awk) function to choke on the > input and cause some really wierd effects downstream... > Ah, yes, hand editing. But that won't be happening in my case. 3) Why should an sql database need any monitoring and maintenance over the > next X years? Yes you can corrupt the files, but I would hope for very > decent uptimes and after all they aren't going to repair a corrupted boot > sector so you need some kind of maintenance plan in place, simply work in a > full OS backup into the plan and this saves your DB at the same time? > (Offlist we can discuss, but a simple rsync to some separate partition > should do it) > You rsync the files an SQL database (like MySQL) works from, and don't expect corruption? That's only safe if the database is synced and shut down. I don't want to be doing that. If I did run a database engine, it would have to import everything ... as a single massive transaction (or maybe a live table switch scenario between two tables). To back it up I'd either export the entire table to a file (and send that off to the archive), or just back up the file I used to import with. 4) If you really, really don't want a daemon based database then you will > have to look at bdb (if dovecot supports it?) or sqlite which I think > postfix+dovecot both support. You can then add convenience command line > functions to examine and alter the data. Those convenience functions can > error check the input also. > CDB would work, since I would be importing everything all at once every time a change takes place (once every few days perhaps). Berkeley DB would work, too (nearly as fast). A flat file cached in RAM by the OS would be about as fast for these few number of users (that's a "database", too, in its own way). Good luck > It looks like the way I will be doing this is to let Dovecot handle Postfix's SASL needs and generate a little users table for Postfix to make the accept/reject decision on incoming email and spam. So my task now is to decide what form I will give the data to Dovecot.
Re: [Dovecot] best choice of user database file to work with postfix?
On Fri, Apr 23, 2010 at 2:49 AM, Rainer Frey wrote: > On Thursday 22 April 2010 18:15:18 Phil Howard wrote: > [ ... all standard stuff that is well documented ... ] > > > 5. Passwords stored encrypted, such as MD5. And it should be a scheme > > that both Postfix and Dovecot can use so I don't have keep two different > > encryption schemes. > > Postfix doesn't need any password directly. It only authenticates a user > with > a password in one case: SMTP SASL authentication of submission users, and > it > uses the dovecot auth service for that and does not read the password > database > itself. > OK, so all that is in whatever SASL configuration, and so I'll be doing that in Dovecot. It is not about supporting a certain database library. There is simply a > difference in what Dovecot and Postfix need from a user/recipient database. > Dovecot needs information like path to mailbox, uid/gid with which to put > files into the mailboxes, extra configuration fields ... Therefore it uses > a > structured multi-value format like the passwd-file. CDB or similar don't > work > like this, so dovecot can't easily support using the same CDB files as > postfix. > Why not have all those fields combined into the value string you get from CDB? If it can do it from a line out of /etc/passwd then it can do it from CDB (the value could simply be that same line ... or defined to be something else more convenient). Postfix only supports name:value tables, either to use the value > (table-style > lookup) or to check whether there is an entry for a name (list-style > lookup). > Therefore it only uses file databases with such a mapping. In the case of > valid recipients which will be handed off to dovecot for delivery, it is > such > a simple list lookup. > The value can be a tuple (see above). We're lucky that what Postfix needs is "does this exist". So it can just completely ignore the value and not need any code to parse it. > (If it interests you: the postfix virtual delivery agent needs very similar > information to dovecot, but it uses several key:value maps for the > different > information, all with the recipient as key.) > I've run into that before. I think it was the source of some difficulty. In programming I've done, I've stored structured data in Berkeley DB and never needed but one table/file per class of index.
Re: [Dovecot] best choice of user database file to work with postfix?
On 23/04/2010 10:30, Gábor Lénárt wrote: On Wed, Apr 21, 2010 at 01:45:35PM -0400, Phil Howard wrote: Then I think MySQL will do the job. Both postfix and dovecot support MySQL, and you can use SASL to authenticate SMTP with Dovecot, so Dovecot would do all the auth work. Finally, you could use Postfix's VDA patch if you want to use Maildir++. Hope this helps. I don't want to use any other server engine of any kind with this. I'm trying to keep it small and lean, and minimize what the people that have to monitor and fix it need to know. So at the present time, I am excluding all databases like any SQL or LDAP or anything else that needs to run as a daemon/engine/service. Aham, yes, but as soon as you need some management interface, like a web based one, it will be more and more complicated to deal with this decision, you must edit/generate those files with that interface, care about locking because of the possibility of multiple admin access at the same time, you must parse them when you want to show the user list and so on. Sure, if you are very sure that it's not a need and it won't be either, then maybe you're right about "keeping minimal" solution, but based on my experience at an ISP, it's always the situation that sooner or later somebody want to extend the usage of a system which sooner or later needs to use some kind of database to avoid the complexity with dealing local "databases" as flat files or other solution (or keeping them as "system users"). Yeah, I PROMISE that someone will eventually corrupt the flat file text "database" by accident. So now you need to add a backup system (git? rsync?), plus some editing sanity checks? (a la visudo?) In the end I personally went for a mysql + small rails frontend (using activescaffold which allows you to generate an admin interface in a couple of lines of code) We don't know the exact requirements of the OP, but based on what we read here, *I* personally would evaluate either: - sqlite based database with command line shell scripts to edit/examine - mysql based system with remote control editing from some centralised location (ie you admin it for them) - Some black box office distro where you just push the button and out it rolls. I didn't look, but there must be some Centos/Ubuntu derivative thing which comes with a web interface, webmail, etc? With mysql use innodb databases and all the logging options set to sync writes. It should be near impossible to kill even if you keep ripping the power out. Good luck Ed W
Re: [Dovecot] best choice of user database file to work with postfix?
On Wed, Apr 21, 2010 at 01:45:35PM -0400, Phil Howard wrote: > > Then I think MySQL will do the job. Both postfix and dovecot support MySQL, > > and you can use SASL to authenticate SMTP with Dovecot, so Dovecot would do > > all the auth work. Finally, you could use Postfix's VDA patch if you want to > > use Maildir++. > > > > Hope this helps. > > > > I don't want to use any other server engine of any kind with this. I'm > trying to keep it small and lean, and minimize what the people that have to > monitor and fix it need to know. So at the present time, I am excluding all > databases like any SQL or LDAP or anything else that needs to run as a > daemon/engine/service. Aham, yes, but as soon as you need some management interface, like a web based one, it will be more and more complicated to deal with this decision, you must edit/generate those files with that interface, care about locking because of the possibility of multiple admin access at the same time, you must parse them when you want to show the user list and so on. Sure, if you are very sure that it's not a need and it won't be either, then maybe you're right about "keeping minimal" solution, but based on my experience at an ISP, it's always the situation that sooner or later somebody want to extend the usage of a system which sooner or later needs to use some kind of database to avoid the complexity with dealing local "databases" as flat files or other solution (or keeping them as "system users").
Re: [Dovecot] best choice of user database file to work with postfix
P.S. The "idiot" who kept breaking the plain text format file in my original setup was da da ... me ... So given I think of myself as reasonably technical, I would claim that text format "databases" are way more fragile than you might expect (good luck getting a non technical user not to break the text format file from time to time...)
Re: [Dovecot] Expire plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 22 Apr 2010, Thomas M Goerger wrote: expires table when I look. Is there anywhere that expire can log to so I can see what might be happening? It doesn't look like it logs to the Did you checked that the plugin is loaded at all? Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS9FRQr+Vh58GPL/cAQIBVgf6AnYmZqePcumF1g1tmz+TxMlInf3T44Rk anYKFYRY0SfF/pDyyJLAYzQHDK1/57qT6H1CND4MdYlPHW2uGXAdwd+7HH4XuA/v bCSqWX+MreDFkxb6TXutMJ+4ymyJNK+y1Hs8vyPS1Pq76Lg1V2TkpuebKp6NfUim 7d1yVFT2LmFh6MIkRUQygCD9wZcSGoeQbeheumrLO2r3p0yhnCRi/WhiPY40G31v OCbHj6VXq10NRU8dr0z8Wpdq9JrIT3WEe/XoMHXz5CPKow9Kbj737zK5AT/5b/Gq IlvyJb3j6YQ2QwF3G4KZvFkkC3GcdCB/QtpiciYMiEY92kSX9p/ggw== =9l2w -END PGP SIGNATURE-
Re: [Dovecot] best choice of user database file to work with postfix
On 22/04/2010 17:18, Phil Howard wrote: I have not been following this thread as closely as I probably should have; however, I was wondering what the OP's problem was with using MySQL? It would greatly simplify the job of constructing and maintaining databases. It is even possible to create tables that both Postfix and Dovecot can use jointly if desired. I use MySQL for several projects, and would never go back to using 'flat files" unless there was no other way to achieve my goal. The administration is going to be handed off to less technical people, and my goal is to mimize the number of elements in this. It's not about MySQL itself ... it's about not running yet another server/daemon. You need to look at where you are going with this One way or another you need a database - call it a banana if you prefer, but it's still a database whether it's a flat file or a BDB file or whatever Your requirements appear to be badly phrased. What you *appear* to want is a black box system which is as simple to maintain as possible. However, you have stated a bunch of hard to meet criteria such as not allowing any long running code to support your needs (a daemon). I really don't see that you should exclude additional daemons, simply evaluate the complete system with and without and choose the one which is "easiest" to maintain 1) Yes you CAN setup something which uses a plain text database, I tried it for a while but at 50 users I decided it was too complicated and switched to a DB. 2) You are optimistic if you don't think some user will accidently add a halfway through the text file, completely breaking it and have the skills to realise what they did. Or they will add a "," in the middle of a password and change the meaning of all your fields. Or they will miss a field save the file and then never realise their mistake. Better yet are errors which cause some external (grep,sed,awk) function to choke on the input and cause some really wierd effects downstream... 3) Why should an sql database need any monitoring and maintenance over the next X years? Yes you can corrupt the files, but I would hope for very decent uptimes and after all they aren't going to repair a corrupted boot sector so you need some kind of maintenance plan in place, simply work in a full OS backup into the plan and this saves your DB at the same time? (Offlist we can discuss, but a simple rsync to some separate partition should do it) 4) If you really, really don't want a daemon based database then you will have to look at bdb (if dovecot supports it?) or sqlite which I think postfix+dovecot both support. You can then add convenience command line functions to examine and alter the data. Those convenience functions can error check the input also. Good luck Ed W
