[Dovecot] Attribute Cache flush errors on FreeBSD 8.2
I'm running dovecot 2.0.16 on FreeBSD 8.2 with the mail spool and
indexes on an NFS server.
Lines like the following keep appearing in syslog for access to each
mailbox:
Error: nfs_flush_attr_cache_fd_locked: fchown(/home/philk/Mail/Deleted)
failed: Bad file descriptor
This is coming from nfs-workarounds.c line 210, which tracing back seems
to be coming from the call to mbox_lock on
lib-storage/index/mbox/mbox-lock.c line 774.
I have /home mounted with options
acregmin=0,acregmax=0,acdirmin=0,acdirmax=0 (as FreeBSD doesn't have a
noac option), but it throws the same error either way.
The output of dovecot -n is below.
Phil.
# 2.0.16: /usr/local/etc/dovecot/dovecot.conf
# OS: FreeBSD 8.2-RELEASE-p3 i386
auth_mechanisms = plain login
auth_username_format = %Lu
disable_plaintext_auth = no
first_valid_gid = 1000
first_valid_uid = 1000
listen = *, [::]
mail_fsync = always
mail_location = mbox:~/Mail/:INBOX=/var/mail/%u
mail_nfs_index = yes
mail_nfs_storage = yes
mail_privileged_group = mail
mmap_disable = yes
passdb {
args = session=yes dovecot
driver = pam
}
protocols = imap pop3
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
user = root
}
ssl_cert = /etc/ssl/certs/dovecot.pem
ssl_key = /etc/ssl/private/dovecot.pem
userdb {
args = blocking=yes
driver = passwd
}
verbose_proctitle = yes
protocol imap {
imap_client_workarounds = delay-newmail tb-extra-mailbox-sep
}
protocol pop3 {
pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
pop3_uidl_format = %08Xu%08Xv
}
protocol lda {
postmaster_address = postmas...@example.com
sendmail_path = /usr/sbin/sendmail
}
[Dovecot] Providing shared folders with multiple backend servers
Hi *, I am currently in the planning stage for a new and improved mail system at my university. Right now, everything is on one big backend server but this is causing me increasing amounts of pain, beginning with the time a full backup takes. So naturally, I want to split this big server into smaller ones. To keep things simple, I want to pin a user to a server so I can avoid things like NFS or cluster aware filesystems. The mapping for each account is then inserted into the LDAP object for each user and the frontend proxy (perdition at the moment) then uses this information to route each access to the correct backend storage server running dovecot. So far this has been working nice with my test setup. But: I also have to provide shared folders for users. Thankfully users don't have the right to share their own folders, which makes things easier (I hope). Right now, the setup works like this, using Courier: - complete virtual mail setup - global shared folders configured in /etc/courier/shared/index - inside /home/shared-folder-name/Maildir/courierimapacl specific user get access to a folder - each folder a user has access is mapped to the namespace #shared like #shared.shared-folder-name Now, if I split my backend storage server into multiple ones and user-A is on server-1 and user-B is on server-2, but both need to access the same shared folder, I have a problem. I could of course move all users needing access to a shared folder to the same server, but in the end, this will be a nightmare for me, because I forsee having to move users around on a daily basis. Right now, I am pondering with using an additional server with just the shared folders on it and using NFS (or a cluster FS) to mount the shared folder filesystem to each backend storage server, so each user has potential access to a shared folders data. Ideas? Suggestions? Nudges in the right direction? Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: [Dovecot] Providing shared folders with multiple backend servers
On 1/7/2012 4:20 PM, Sven Hartge wrote: Hi *, I am currently in the planning stage for a new and improved mail system at my university. Right now, everything is on one big backend server but this is causing me increasing amounts of pain, beginning with the time a full backup takes. You failed to mention your analysis and diagnosis identifying the source of the slow backup, and other issues your eluded to but didn't mention specifically. You also didn't mention how you're doing this full backup (tar, IMAP; D2D or tape), where the backup bottleneck is, what mailbox storage format you're using, total mailbox count and filesystem space occupied. What is your disk storage configuration? Direct attach? Hardware or software RAID? What RAID level? How many disks? SAS or SATA? It's highly likely your problems can be solved without the drastic architecture change, and new problems it will introduce, that you describe below. So naturally, I want to split this big server into smaller ones. Naturally? Many OPs spend significant x/y/z resources trying to avoid the shared nothing storage backend setup below. To keep things simple, I want to pin a user to a server so I can avoid things like NFS or cluster aware filesystems. The mapping for each account is then inserted into the LDAP object for each user and the frontend proxy (perdition at the moment) then uses this information to route each access to the correct backend storage server running dovecot. Splitting the IMAP workload like this isn't keeping things simple, but increases complexity, on many levels. And there's nothing wrong with NFS and cluster filesystems if they are used correctly. So far this has been working nice with my test setup. But: I also have to provide shared folders for users. Thankfully users don't have the right to share their own folders, which makes things easier (I hope). Right now, the setup works like this, using Courier: - complete virtual mail setup - global shared folders configured in /etc/courier/shared/index - inside /home/shared-folder-name/Maildir/courierimapacl specific user get access to a folder - each folder a user has access is mapped to the namespace #shared like #shared.shared-folder-name Now, if I split my backend storage server into multiple ones and user-A is on server-1 and user-B is on server-2, but both need to access the same shared folder, I have a problem. Yes, you do. I could of course move all users needing access to a shared folder to the same server, but in the end, this will be a nightmare for me, because I forsee having to move users around on a daily basis. See my comments above. Right now, I am pondering with using an additional server with just the shared folders on it and using NFS (or a cluster FS) to mount the shared folder filesystem to each backend storage server, so each user has potential access to a shared folders data. So you're going to implement a special case of what you're desperately trying to avoid? This makes no sense. Ideas? Suggestions? Nudges in the right direction? Yes. We need more real information. Please provide: 1. Mailbox count, total maildir file count and size 2. Average/peak concurrent user connections 3. CPU type/speed/total core count, total RAM, free RAM (incl buffers) 4. Storage configuration--total spindles, RAID level, hard or soft RAID 5. Filesystem type 6. Backup software/method 7. Operating system Instead of telling us what you think the solution to your unidentified bottleneck is and then asking yeah or nay, tell us what the problem is and allow us to recommend solutions. This way you'll get some education and multiple solutions that may very well be a better fit, will perform better, and possibly cost less in capital outlay and administration time/effort. -- Stan
Re: [Dovecot] Providing shared folders with multiple backend servers
Stan Hoeppner s...@hardwarefreak.com wrote: It's highly likely your problems can be solved without the drastic architecture change, and new problems it will introduce, that you describe below. The main reason is I need to replace the hardware as its service contract ends this year and I am not able to extend it further. The box so far is fine, there are normally no problems during normal operations with speed or responsiveness towards the end-user. Sometimes, higher peak loads tend to strain the system a bit and this is starting to occur more often. First thought was to move this setup into our VMware cluster (yeah, I know, spare me the screams), since the hardware used there is way more powerfull than the hardware used now and I wouldn't have to buy new servers for my mail system (which is kind of painful to do in an universitary environment, especially in Germany, if you want to invest an amount of money above a certain amount). But then I thought about the problems with VMs this size and got to the idea with the distributed setup, splitting the one server into 4 or 6 backend servers. As I said: idea. Other ideas making my life easier are more than welcome. Ideas? Suggestions? Nudges in the right direction? Yes. We need more real information. Please provide: 1. Mailbox count, total maildir file count and size about 10,000 Maildir++ boxes 900GB for 1300GB used, df -i says 11 million inodes used I know, this is very _tiny_ compared to the systems ISPs are using. 2. Average/peak concurrent user connections IMAP: Average 800 concurrent user connections, peaking at about 1400. POP3: Average 300 concurrent user connections, peaking at about 600. 3. CPU type/speed/total core count, total RAM, free RAM (incl buffers) Currently dual-core AMD Opteron 2210, 1.8GHz. Right now, in the middle of the night (2:30 AM here) on a Sunday, thus a low point in the usage pattern: total used free sharedbuffers cached Mem: 1233582097202522615568 0 53112 680424 -/+ buffers/cache:89867163349104 Swap: 5855676 109165844760 System reaches its 7 year this summer which is the end of its service contract. 4. Storage configuration--total spindles, RAID level, hard or soft RAID RAID 6 with 12 SATA1.5 disks, external 4Gbit FC Back in 2005, a SAS enclosure was way to expensive for us to afford. 5. Filesystem type XFS in a LVM to allow snapshots for backup I of course aligned the partions on the RAID correctly and of course created a filesystem with the correct parameters wrt. spindels, chunk size, etc. 6. Backup software/method Full backup with Bacula, taking about 24 hours right now. Because of this, I switched to virtual full backups, only ever doing incremental and differental backups off of the real system and creating synthetic full backups inside Bacula. Works fine though, incremental taking 2 hours, differential about 4 hours. The main problem of the backup time is Maildir++. During a test, I copied the mail storage to a spare box, converted it to mdbox (50MB file size) and the backup was lightning fast compared to the Maildir++ format. Additonally compressing the mails inside the mdbox and not having Bacula compress them for me reduce the backup time further (and speeding up the access through IMAP and POP3). So this is the way to go, I think, regardless of which way I implement the backend mail server. 7. Operating system Debian Linux Lenny, currently with kernel 2.6.39 Instead of telling us what you think the solution to your unidentified bottleneck is and then asking yeah or nay, tell us what the problem is and allow us to recommend solutions. I am not asking for yay or nay, I just pointed out my idea, but I am open to other suggestions. If the general idea is to buy a new big single storage system, I am more than happy to do just this, because this will prevent any problems I might have with a distributed one before they even can occur. Maybe two HP DL180s (one for production and one as test/standby-system) with an SAS attached enclosure for storage? Keeping in mind the new system has to work for some time (again 5 to 7 years) I have to be able to extend the storage space without to much hassle. Grüße, S° -- Sigmentation fault. Core dumped.
Re: [Dovecot] Strange error: DIGEST-MD5 mechanism can't be supported with given passdbs
Hi Timo,
Did you review the patches in previous email? I tested two patches against
my configuration(pasted in this thread too), they both work well. I prefer
the first patch, but I'm not sure whether it breaks something else.
Regards,
Yubao Liu
On 01/07/2012 11:36 AM, Yubao Liu wrote:
On 01/07/2012 01:51 AM, Timo Sirainen wrote:
On 6.1.2012, at 19.45, Yubao Liu wrote:
On 01/07/2012 12:44 AM, Timo Sirainen wrote:
On Sat, 2012-01-07 at 00:15 +0800, Yubao Liu wrote:
I don't know why this function doesn't check auth-masterdbs, if I
insert these lines after line 128, that error goes away, and
dovecot's
imap-login process happily does DIGEST-MD5 authentication [1].
In my configuration, masterdbs contains passdb passwd-file,
passdbs contains passdb pam.
So .. you want DIGEST-MD5 authentication for the master users, but not
for anyone else? I hadn't really thought anyone would want that..
Is there any special reason that master passdb isn't taken into
account in src/auth/auth.c:auth_passdb_list_have_lookup_credentials() ?
I feel master passdb is also a kind of passdb.
I guess it could be changed. It wasn't done intentionally that way.
I guess this change broke old way:
http://hg.dovecot.org/dovecot-2.0/rev/b05793c609ac
In old version, auth-passdbs contains all passdbs, this revision
changes auth-passdbs to only contain non-master passdbs.
I'm not sure which fix is better or even my proposal is correct or fully:
a) in src/auth/auth.c:auth_passdb_preinit(), insert master passdb to
auth-passdbs too, and remove duplicate code for masterdbs
in auth_init() and auth_deinit().
b) add similar code for masterdbs in
auth_passdb_list_have_verify_plain(),
auth_passdb_list_have_lookup_credentials(),
auth_passdb_list_have_set_credentials().
This is exactly my use case, I use Kerberos for system users,
I'm curious why master passdb isn't used to check
have_lookup_credentials ability
http://wiki2.dovecot.org/Authentication/MultipleDatabases
Currently the fallback works only with the PLAIN authentication
mechanism.
I hope this limitation can be relaxed.
It might already be .. I don't remember. In any case you have only
PAM passdb, so it shouldn't matter. GSSAPI isn't a passdb.
If the fix above is added, then I can use CRAM-MD5 with master
passwd-file passdb
and normal pam passdb, else imap-login process can't startup due to
check in
auth_mech_list_verify_passdb().
Attached two patches against dovecot-2.0 branch for the two schemes,
the first is cleaner but may affect other logics in other source files.
Another related question is pass option in master passdb, if I set
it to yes,
the authentication fails:
Jan 7 11:26:00 gold dovecot: auth: Debug: client in:
AUTH#0111#011CRAM-MD5#011service=imap#011secured#011lip=127.0.1.1#011rip=127.0.0.1#011lport=143#011rport=51771
Jan 7 11:26:00 gold dovecot: auth: Debug: client out:
CONT#0111#011PDk4NjcwMDY1MTU3NzI3MjguMTMyNTkwNjc2MEBnb2xkPg==
Jan 7 11:26:00 gold dovecot: auth: Debug: client in:
CONT#0111#011ZGlla2VuKndlYm1haWwgYmNkMzFiMWE1YjQ1OWQ0OGRkZWQ4ZmIzZDhmMjVhZTc=
Jan 7 11:26:00 gold dovecot: auth: Debug:
auth(webmail,127.0.0.1,master): Master user lookup for login: dieken
Jan 7 11:26:00 gold dovecot: auth: Debug:
passwd-file(webmail,127.0.0.1,master): lookup: user=webmail
file=/etc/dovecot/master-users
Jan 7 11:26:00 gold dovecot: auth: passdb(webmail,127.0.0.1,master):
Master user logging in as dieken
Jan 7 11:26:00 gold dovecot: auth: Error: passdb(dieken,127.0.0.1):
No passdbs support skipping password verification - pass=yes can't be
used in master passdb
Jan 7 11:26:00 gold dovecot: auth: Debug: password(dieken,127.0.0.1):
passdb doesn't support credential lookups
My normal passdb is a PAM passdb, it doesn't support credential
lookups, that's
reasonable, but I feel the comment for pass option is confusing:
$ less /etc/dovecot/conf.d/auth-master.conf.ext
# Example master user passdb using passwd-file. You can use any passdb
though.
passdb {
driver = passwd-file
master = yes
args = /etc/dovecot/master-users
# Unless you're using PAM, you probably still want the destination
user to
# be looked up from passdb that it really exists. pass=yes does that.
pass = yes
}
According the comment, it's to check whether the real user exists, why
not
to check userdb but another passdb? Even it must check against passdb,
in this case, it's obvious not necessary to lookup credentials, it's
enough to
to lookup user name only.
Regards,
Yubao Liu
