[Dovecot] automounting home dirs
Hi, I'm running dovecot-1.0.10 on a Solaris 10 server with home dirs automounted over NFS. I have set the mail_location configuration option so that nothing should be written to a user's home dir over NFS but, as far as I can tell, dovecot still by default tries to chdir to a user's home dir when reading mail, although this is not required. This creates additional unnecessary load on a heavily-loaded fileserver and generally slows everything down and creates an unnecessary dependency. Is there a way to prevent dovecot from causing the home dirs to be mounted? I found this thread: http://markmail.org/message/umywuppl3vvzfe4p#query:dovecot%20mount%20home%20directory+page:3+mid:fgr4g6pup5y6qbcr+state:results which discusses the same problem, but it's quite old and there doesn't seem to be a definitive answer other than hacking the passwd file or the code. Is there a more elegant solution? TIA. _ Get a bird’s eye view of the world with Multimap http://clk.atdmt.com/GBL/go/115454059/direct/01/
Re: [Dovecot] automounting home dirs
Roger Hale wrote: I'm running dovecot-1.0.10 on a Solaris 10 server with home dirs automounted over NFS. I have set the mail_location configuration option so that nothing should be written to a user's home dir over NFS but, as far as I can tell, dovecot still by default tries to chdir to a user's home dir when reading mail, although this is not required. This creates additional unnecessary load on a heavily-loaded fileserver and generally slows everything down and creates an unnecessary dependency. Is there a way to prevent dovecot from causing the home dirs to be mounted? You can override the home dir returned by your userdb with a variable-expanded, static value by adding home to args[1]. You need to be careful and make sure that Dovecot doesn't use anything in the users' home dirs. You may need to set mail_location and/or mail and create a virtual home-dir tree local to the Dovecot server. Posting `dovecot -n` output would help. 1: http://wiki.dovecot.org/UserDatabase
Re: [Dovecot] automounting home dirs
I'm running dovecot-1.0.10 on a Solaris 10 server with home dirs
automounted over NFS. I have set the mail_location configuration
option so that nothing should be written to a user's home dir over
NFS but, as far as I can tell, dovecot still by default tries to
chdir to a user's home dir when reading mail, although this is not
required. This creates additional unnecessary load on a
heavily-loaded fileserver and generally slows everything down and
creates an unnecessary dependency.
Is there a way to prevent dovecot from causing the home dirs to be
mounted?
You can override the home dir returned by your userdb with a
variable-expanded, static value by adding home to args[1]. You need
to be careful and make sure that Dovecot doesn't use anything in the
users' home dirs. You may need to set mail_location and/or mail and
create a virtual home-dir tree local to the Dovecot server.
Thanks. Are you suggesting I add something like the following?
userdb static {
args = home=/some/random/dir
}
Incidentally, what I really wanted was for the user's home dir only to be
mounted for imap connections (when it could be usefully used), not POP3. I
thought by moving the indexes dir this would just happen.
Posting `dovecot -n` output would help.
# 1.0.10: /usr/local/etc/dovecot.conf
protocols: imap imaps pop3s
disable_plaintext_auth: no
login_dir: /usr/local/var/run/dovecot/login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(pop3): /usr/local/libexec/dovecot/pop3-login
mail_extra_groups: mail
mail_location:
mbox:/var/mail/.mboxes/%u:INBOX=/var/mail/%u:INDEX=/var/mail/.indexes/%u
mail_debug: yes
mmap_disable: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(pop3): /usr/local/libexec/dovecot/pop3
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
pop3_reuse_xuidl(default): no
pop3_reuse_xuidl(imap): no
pop3_reuse_xuidl(pop3): yes
pop3_uidl_format(default):
pop3_uidl_format(imap):
pop3_uidl_format(pop3): %08Xv%08Xu
auth default:
mechanisms: plain login
passdb:
driver: pam
userdb:
driver: passwd
_
Get a bird’s eye view of the world with Multimap
http://clk.atdmt.com/GBL/go/115454059/direct/01/
Re: [Dovecot] automounting home dirs
Roger Hale wrote:
Is there a way to prevent dovecot from causing the home dirs to be
mounted?
You can override the home dir returned by your userdb with a
variable-expanded, static value by adding home to args[1]. You need
to be careful and make sure that Dovecot doesn't use anything in the
users' home dirs. You may need to set mail_location and/or mail and
create a virtual home-dir tree local to the Dovecot server.
Thanks. Are you suggesting I add something like the following?
userdb static {
args = home=/some/random/dir
}
passwd instead of static in your case, but yes. Overriding home is only
supported in v1.1 or later when the userdb is passwd. You'll need to
either update Dovecot or change your userdb driver. If your users only
access their mailboxes through POP3/IMAP, you could switch to a
single-UID/GID setup with the static driver (which does support setting
home in v1.0).
Incidentally, what I really wanted was for the user's home dir only
to be mounted for imap connections (when it could be usefully used),
not POP3. I thought by moving the indexes dir this would just happen.
Dovecot runs the imap/pop3 sessions as the logged-in user, so it chdir's
regardless of the mailbox location.
Re: [Dovecot] Password field limitations
mouss wrote:
Charles Marcus a écrit :
On 12/23/2008 12:25 PM, Luigi Rosa wrote:
If I'm not mistaken, dovecot doesn't care - this will be a limitation of
your Filesystem and/or password storage tool... in this case, MySQL...
I Use MySQL and I don't have such kind of limitations.
I would blame Tom's MySQL interface or implementation, but not MySQL itself.
I certainly didn't intend to mean it was a Mysql limitation in general -
I'm using it too for my user/password backend, and have all of these
characters available in passwords:
`...@#$%^*()_-+={}|[]:;?,.
More than likely it is a system library or charset issue, or something
like that...
that would be really surprising. I am most inclined to think that the
password change is done via a (buggy) web interface or a buggy script.
or maybe it is a PEBCAK?
I did some tests and it appears the limitations presented by the
customer in regards to invalid characters, are indeed not reproducible.
I'll see if I can find a reproducible case with the 8 char length
password, because I have indeed seen this before myself, but it might be
related to the hashing algorithm used (The guy who originally made the
interface decided it was smart to hash all passwords using
OLD_PASSWORD() in MySQL, so I'm stuck with that for now).
Sorry for the noise.
PS. My interface is fine though, thank you.
--
Tom
