Re: First time setting up Director Woes
Working again. Explains a lot actually. Inital box I was experimenting
on PAM was already setup and had worked. That error I got caught up in
was with SSSD and PAM wasn't working. Fixing the error shot myself in
the foot in other ways. Thank you!
-Jesse C. Smillie
On 3/13/17 4:38 PM, Aki Tuomi wrote:
On March 13, 2017 at 10:21 PM "Jesse C. Smillie"
wrote:
I'm trying to setup our first director server. Trying to keep the
initial config simple really as just maybe a proof of concept and its
got me pulling my hair out today. Initially I just tried to convert one
of my already running IMAP servers to be a director just to see if I
could do it. I modified the configs as it appeared they needed based on:
https://wiki2.dovecot.org/Director
http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/Proxy
But it didn't work. Kept serving files locally instead of proxing off
to the servers listed.
Remove this:
passdb {
driver = pam
}
Aki
<>
First time setting up Director Woes
I'm trying to setup our first director server. Trying to keep the
initial config simple really as just maybe a proof of concept and its
got me pulling my hair out today. Initially I just tried to convert one
of my already running IMAP servers to be a director just to see if I
could do it. I modified the configs as it appeared they needed based on:
https://wiki2.dovecot.org/Director
http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/Proxy
But it didn't work. Kept serving files locally instead of proxing off
to the servers listed.
---
Mar 13 15:58:27 fugitoid dovecot: imap-login: Login: user=,
method=PLAIN, rip=10.0.15.114, lip=10.1.12.221, mpid=3022, TLS,
session=
Mar 13 15:58:27 fugitoid dovecot: imap(makaveli): Error: User
initialization failed: Namespace '': mkdir(/home/makaveli/Maildir)
failed: Permission denied (euid=2605(makaveli) egid=1100()
missing +w perm: /home, dir owned by 0:0 mode=0755)
Mar 13 15:58:27 fugitoid dovecot: imap: Error: Invalid user settings.
Refer to server log for more information.
Thinking it was just something with that box (still running Dovecot
2.2.10 as well) I moved on to setup a new Centos7 server and go through
the setup again and initially it was working for a few hours.
---
Mar 13 12:19:03 fugitoid dovecot: imap-login: proxy(makaveli): started
proxying to 10.1.12.228:993: user=, method=PLAIN,
rip=10.0.15.114, lip=10.1.12.221, TLS, session=
Then at some point I got side tracked by a pam error message and when I
came back from working that out Dovecot was trying to authenticate users
locally again. I really feel like I'm missing something here, but for
the life of me I can't figure it out. Any ideas would be welcome. Thanks.
# 2.2.28 (bed8434): /etc/dovecot/dovecot.conf
# OS: Linux 3.10.0-514.10.2.el7.x86_64 x86_64 CentOS Linux release
7.3.1611 (Core)
auth_mechanisms = plain login
default_client_limit = 1024
director_mail_servers = 10.1.12.229 10.1.12.228 10.1.12.225
director_servers = 10.1.12.221:9090
mail_fsync = always
mail_nfs_storage = yes
mbox_write_locks = fcntl
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
driver = pam
}
passdb {
args = proxy=y nopassword=y ssl=any-cert
driver = static
}
protocols = imap
service director {
fifo_listener login/proxy-notify {
mode = 0666
}
inet_listener {
port = 9090
}
unix_listener director-userdb {
mode = 0600
}
unix_listener login/director {
mode = 0666
}
}
service imap-login {
executable = imap-login director
inet_listener imaps {
port = 993
ssl = yes
}
}
ssl = required
ssl_ca = ssl_cipher_list =
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
ssl_dh_parameters_length = 2048
ssl_key = # hidden, use -P to show it
ssl_protocols = TLSv1 TLSv1.1 TLSv1.2
userdb {
driver = passwd
}
<>
Re: [Dovecot] Users can't delete an email (Totally Random effect)
Will definitely look into the usermin connection. Not to be totally stupid, but I clicked the link you listed. Does that mean next 1.0 release there will a fix to at least work out the whole can't delete thing? -Jesse C. Smillie "Insert inspirational or witty comment here" Timo Sirainen wrote: On Tue, 2008-07-01 at 15:07 -0400, Jesse C. Smillie wrote: Hello all... Found a weird one here. I tried to search the web but I'm not having luck so I thought I'd hit the mailing list. We have noticed off and on all school year that every so often a user gets an email that they just can't delete using Thunderbird or Outlook over IMAP (we do not support Pop3 anymore.) Essentially the user clicks the email and takes it to the trash. When they empty the trash the email appears again in their inbox as if it was new! Up until this point I would just tell people to login to Usermin which is still set to access the email natively through the maildir format and delete it that way. What we have found out is that emails which have their info fields repeated twice are emails which can't be deleted. So for example: [EMAIL PROTECTED]:/home/somedude# find ./ -iname '*,*,*' ./Maildir/cur/1208807796.29873_0.gator:2,Sb:2,S http://hg.dovecot.org/dovecot-1.0/rev/39bb56f31185 fixes this. Unfortunately I don't know how or why these emails are created. Maybe Usermin creates them? begin:vcard fn:Jesse C. Smillie n:Smillie;Jesse C. org:Gateway School District;Technology Department adr:;;;Monroeville;PA;15146;USA email;internet:[EMAIL PROTECTED] title:Mac Tech / Linux Administrator / Mac Administrator tel;work:412-858-0453 tel;cell:412-861-3423 x-mozilla-html:TRUE version:2.1 end:vcard
[Dovecot] Users can't delete an email (Totally Random effect)
Hello all... Found a weird one here. I tried to search the web but I'm not having luck so I thought I'd hit the mailing list. We have noticed off and on all school year that every so often a user gets an email that they just can't delete using Thunderbird or Outlook over IMAP (we do not support Pop3 anymore.) Essentially the user clicks the email and takes it to the trash. When they empty the trash the email appears again in their inbox as if it was new! Up until this point I would just tell people to login to Usermin which is still set to access the email natively through the maildir format and delete it that way. What we have found out is that emails which have their info fields repeated twice are emails which can't be deleted. So for example: [EMAIL PROTECTED]:/home/somedude# find ./ -iname '*,*,*' ./Maildir/cur/1208807796.29873_0.gator:2,Sb:2,S ./Maildir/cur/1205162628.14926_0.gator:2,Sb:2,S ./Maildir/cur/1206557108.6542_0.gator:2,Sb:2,STb ./Maildir/cur/1204054624.5835_0.gator:2,Sa:2,S ./Maildir/cur/1208957483.28799_0.gator:2,RSb:2,RSTb ./Maildir/cur/1208803572.18922_0.gator:2,Sb:2,S ./Maildir/cur/1209482166.31816_0.gator:2,Sb:2,S ./Maildir/cur/1212778554.27192_0.gator:2,Sa:2,S ./Maildir/cur/1210613916.23757_0.gator:2,Sb:2,S ./Maildir/cur/1210277191.15311_0.gator:2,Sa:2,S ./Maildir/cur/1204813078.31520_0.gator:2,Sa:2,S ./Maildir/cur/1207318169.27142_0.gator:2,Sb:2,STb ./Maildir/cur/1206732320.12478_0.gator:2,RSb:2,RSTb ./Maildir/cur/1210788980.15319_0.gator:2,RSb:2,S ./Maildir/cur/1205432415.9316_0.gator:2,RSb:2,S ./Maildir/cur/1204135464.22085_0.gator:2,Sb:2,S ./Maildir/cur/1207161276.31798_0.gator:2,Sb:2,S ./Maildir/cur/1203969436.24684_0.gator:2,Sa:2,S ./Maildir/cur/1207753826.6079_0.gator:2,Sa:2,RSa ./Maildir/cur/1207832151.6749_0.gator:2,Sb:2,S ./Maildir/cur/1212082057.25882_0.gator:2,Sa:2,S ./Maildir/cur/1205856514.5523_0.gator:2,Sb:2,S ./Maildir/cur/1207072150.20246_0.gator:2,RSab:2,S ./Maildir/cur/1208800746.30992_0.gator:2,Sb:2,S ./Maildir/cur/1205353851.26747_0.gator:2,Sb:2,S All of these emails will not be deletable by the imap client. They will do the thing I described above. If I remove one of the info fields they can be deleted. We also found if we create a fake email and name it "test:2,ae:2,Sae" it too will have the nondelete problem. Unfortunately I don't know how or why these emails are created. As far as the vitals go: We are running Dovecot 1.0.14 now, but I have been able to observe this problem through a few of the last versions. The server runs Slamd 64 10.2 (Opteron 64 CPUs) and all of the home directories are on a ReiserFS formatted Volume Anything else I can tell you please let me know and of course any info anybody can tell me about how to make this weirdness go away would be greatly appreciated. Thanks. -- -Jesse C. Smillie "Insert inspirational or witty comment here" begin:vcard fn:Jesse C. Smillie n:Smillie;Jesse C. org:Gateway School District;Technology Department adr:;;;Monroeville;PA;15146;USA email;internet:[EMAIL PROTECTED] title:Mac Tech / Linux Administrator / Mac Administrator tel;work:412-858-0453 tel;cell:412-861-3423 x-mozilla-html:TRUE version:2.1 end:vcard
Re: [Dovecot] A little OT but hopefully still related enough... Maildir Delivered mail naming problems.
Well I don't know what it was, but something you said encouraged me to give up on my current version of Procmail and move to the current version of procmail. It turns out that its the package of procmail that came with Slamd 10.2 which was version 3.15.2 causing all of this mess. I DLed the latest slackbuild scripts (procmail version 3.22.5) and so forth from Slamd_Current, made the package, upgraded the package and now the new emails names are being saved properly. I also ended up just hacking together a script to rename the currently bad named emails from their existing weird form to something more compatible using the naming scheme that the mb2md.pl script uses as a template. This worked out really easy to fix all the email under ~/Maildir/new I still have to come up with something to rename the emails which have already made their way from ~/Maildir/new to ~/Maildir/cur though... I want to save the info which is currently in place after the ":" but I'll figure it out. Thanks again!:> -Jesse Smillie Timo Sirainen wrote: On Tue, 2007-07-17 at 15:00 -0400, Jesse C. Smillie wrote: I have migrated from mbox format to Maildir format in the last week. I used the utility mb2md.pl to convert all of our existing emails from one system to the next. I then modified my /etc/procmailrc file by putting this at the top: MAILDIR=$HOME/Maildir DEFAULT=$MAILDIR/ Looks OK. So now to my problem. We also use Usermin for our users to access their email when they don't have a supported client available to them. When I've no idea about Usermin. However, all the email that is delivered after the fact is different. They all look like this: _oTH.XqwlGB.gator:2,RS _p2F.qjVlGB.gator:2,RS It's not in a standard maildir format. Maybe Procmail has changed it recently? Maybe it's configurable? Maybe you should just get rid of Procmail? :) For the most part I'm being told that the reason why Usermin's sort is all screwed up (order wise) in IMAP mode is that messages are displayed in the order that the IMAP server reports them. Like wise in Maildir mode the order which they are read. I can understand why this naming stuff throws everything off at this point. When Dovecot sees new messages in maildir it sorts the new messages by their filename and assigns UIDs in that order. Existing messages aren't ever reordered however. So if Dovecot sees these kind of new messages one at a time, there's no problem. But if it sees two of them, then those two might be in wrong order.
[Dovecot] A little OT but hopefully still related enough... Maildir Delivered mail naming problems.
Normally I wouldn't post off topic to a mailing list, but I have posted every where else I can think of and haven't had any success yet working this out. I know there has to be a few people here with extensive knowledge of how mail works and maybe just a tip in the right direction would help me out at this point. I have migrated from mbox format to Maildir format in the last week. I used the utility mb2md.pl to convert all of our existing emails from one system to the next. I then modified my /etc/procmailrc file by putting this at the top: MAILDIR=$HOME/Maildir DEFAULT=$MAILDIR/ This way procmail is forced to deliver to the new format as well. For the most part all of this is working perfectly. Procmail is delivering emails to their new proper folder and even extended rules in users own ~/.procmailrc are working well once the folder path was changed from $MAILDIR/whatever to $MAILDIR/.whatever/. Works great. I am using Dovecot 1.0.1 to deliver our email through the IMAP protocol and with the clients we support (Thunderbird and Outlook) things are working very well for us. So now to my problem. We also use Usermin for our users to access their email when they don't have a supported client available to them. When users look at their email with Usermin their emails are out of order regardless of weather I have Usermin's "Read Mail" module using IMAP to get mail or have it read the users Maildir directly. Sorts are just all jacked up. Sometimes if users then click the "Date" button to sort by date it snaps to; sometimes it don't. I currently have multiple posts on the Webmin/Usermin mailing list about this problem and it really seems to point back to the naming scheme of our emails now. All emails which were converted have the classic maildir format. UnixTime.PID.Server... 1183737827.002379.mbox:2,RS 1183737827.002388.mbox:2,RS 1183737827.002392.mbox:2,RSa 1183737827.002394.mbox:2,RS However, all the email that is delivered after the fact is different. They all look like this: _oTH.XqwlGB.gator:2,RS _p2F.qjVlGB.gator:2,RS _qQF.2mpjGB.gator:2,Sa _sK.8mTlGB.gator:2,RSa _uOG.gCtjGB.gator:2,RS _uxG.a6lkGB.gator:2,RS _vnF.n-2lGB.gator:2, _x9H.llckGB.gator:2, _z3G.k8klGB.gator:2,S _z5G.kAilGB.gator:2,RS I have been searching the net for a few hours and reading various documentation here and there and I haven't been able to find anything that tells me why my mail is being named this way or how to fix it. I can say that my test box which also runs 10.2 slamd also delivers this exact same way For the most part I'm being told that the reason why Usermin's sort is all screwed up (order wise) in IMAP mode is that messages are displayed in the order that the IMAP server reports them. Like wise in Maildir mode the order which they are read. I can understand why this naming stuff throws everything off at this point. What I don't understand is why its doing this. I mean I'm pretty sure there is nothing here out of the ordinary as far as my config. I have searched all over the net the last few days and haven't been able to find anything useful. So in wrap up sorry for being a little OT and thanks a head of time for any info or light anyone can share here. -Jesse Smillie
Re: [Dovecot] mbox vs maildir
Wow this is weird because I'm about to make this same jump next week! From what I'm reading so far the big draw back with mbox is the single file with all the emails in it. When you delete a message from that file the whole file has to be rewritten without that email in it. If the box is big enough that can be a serious drag on the server. We have been using Dovecot here all school year for Imap & Pop3 with the Mbox format and when two or more people delete at the same time the utilization on my 3ware card shoots up. We bought the BBU unit for the 3ware so I could enable WRITE cache and that has helped tremendously. I thought this study in regards to speed was quite interesting: http://www.courier-mta.org/mbox-vs-maildir/ <http://www.courier-mta.org/mbox-vs-maildir/> So far my testing conversion process has gone really well. I am surprised how easy it was to tell procmail to do MailDir instead and even the conversion process was super easy. For converting the old inbox and folders I am using the tool mb2md.pl from http://batleth.sapienti-sat.org/projects/mb2md/ I was having a really hard time figuring all of this out until I ran into this webpage: http://adam.rosi-kessel.org/weblog/2007/04/18/adams-super-simple-guide-to-mbox-maildir-conversion/ I know through namespaces you can do inbox in one type and other boxes in another type. I was initially thinking about doing all new stuff in maildir and still support the old ~/mail format. The setup seemed easy enough, but I figured in the long run I am shutting down the server for a few hours to do this so I mis well go all the way. The only thing I'm not sure of is what the best file system to keep this on. I have been keeping my home directories on ReiserFS for quite a while, but one of our tech thinks XFS would be good. All data I have right now tells me to stay ReiserFS though. Even Dovecot's own page says XFS may not be a wise choice. Hope some of this stuff helps you. My server BTW is: Slackware Slamd64 11 (Added Kerberos, Dovecot, etc after the fact) Dual AMD Opteron 242s 4 Gigs RAM 800 Gig RAID 5 3G SATA array ReiserFS on /home /var/spool/mail -Jesse C. Smillie "Insert inspirational or witty comment here" Don Russell wrote: I'm using Dovecot 1.0.1-12 on Linux/Fedora 7 along with sendmail and procmail all running on the same box mail is stored in mbox format It's a small system with a half dozen or so e-mail "accounts". Each with 40-60MB of messages in various folders. I keep seeing messages about how mbox is antiquated and anybody with more than 100 messages etc should not use mbox, but use maildir instead. I'm not entirely convinced there seem to be pros and cons for each. Is there a discussion somewhere that really highlights why one format is so much better than the other? The last time I tried to convert from mbox to maildir, things got pretty botched up, no data loss, but it wasn't pretty. :-) Can Dovecot handle mbox for some users and maildir for others? I'd like to try a conversion for one user... I'll probably create a new user, then have procmail copy (via ! action code) all mail for one user to that new user. Thank you - This mail was scanned by BitDefender For more informations please visit http://www.bitdefender.com - begin:vcard fn:Jesse C. Smillie n:Smillie;Jesse C. org:Gateway School District;Technology Department adr:;;;Monroeville;PA;15146;USA email;internet:[EMAIL PROTECTED] title:Mac Tech / Linux Administrator / Mac Administrator tel;work:412-858-0453 tel;cell:412-861-3423 x-mozilla-html:TRUE version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
