<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org" />
<title>Cyrus IMAP Server FAQ</title>
<!-- $Id: faq.html,v 1.22 2002/12/02 21:44:50 rjs3 Exp $ -->
</head>
<body>
<h1>Cyrus IMAP Server FAQ</h1>
<ul>
<li><b>Using PAM</b> Under Linux when using PAM and shadow
passwords, /etc/shadow needs to be readable by the Cyrus user.</li>
<li><b>POP-Before-SMTP</b> It is not included in the default distribution
because there is already a standard way of doing this with SMTP AUTH.
Any good MTA and/or MUA should support SMTP AUTH, so we shouldn't have
to create a hack in an unrelated service. However, if you would like
to install it anyway, we recommend using
<a href="http://mail.cc.umanitoba.ca/drac/">DRAC</a>,
along with the patch available in <tt>contrib/drac_auth.patch</tt>.</li>
<li><b>Using NFS</b> We don't recommend it. If you want to do it,
it may possibly work but you may also lose your email or have
corrupted <tt>cyrus.*</tt> files. You can look at the mailing list
archives for more information.</li>
<li><b>Using AFS/Coda</b> We don't recommend it. It's even less likely
to work than NFS. If you want to do it, it may possibly work but you
may also lose your email or have corrupted <tt>cyrus.*</tt> files. CMU's previous e-mail system, AMS, leveraged AFS extensively for
storage (and transit) purposes. For various reasons it didn't scale
particularly well and led to CMU's interest in IMAP.
<p>
Cyrus was designed to use a local filesystem with Unix semantics and a
working mmap()/write() combination. AFS doesn't provide these
semantics so won't work correctly.</p>
</li>
<li><b>Virtual hosting</b> - This will be supported starting in Cyrus 2.2.</li>
<li><b>dots in userids</b> - you can have a '.' in your username
IF, AND ONLY IF, you use the <a
href="altnamespace.html#unixhiersep">UNIX hierarchy
convention</a>.</li>
<li><b>renaming users</b> - nope, not supported.</li>
<li><b>plus addressing</b></li>
<li><b>Performance/Capacity/Scaling</b> - See <a
href="install-perf.html">the performance guide</a>.</li>
</ul>
<h2>Troubleshooting</h2>
<dl compact="compact">
<dt><b>Q:</b> I'm getting syslog'd messages from the master process
saying processes are "signaled to death by 10". What's up?</dt>
<dd>
<p><b>A:</b> If you're using Berkeley DB 3.0.55, try installing
some <a
href="http://www.sleepycat.com/update/3.0.55/patch.3.0.55.html">patches
to Berkeley DB</a> available from <a
href="http://www.sleepycat.com/update/3.0.55/patch.3.0.55.html">http://www.sleepycat.com/update/3.0.55/patch.3.0.55.html</a>.</p>
</dd>
<dt><b>Q:</b> I've used <tt>saslpasswd2</tt> to create CRAM-MD5
secrets, but imapd doesn't say <tt>AUTH=CRAM-MD5</tt>. Why?</dt>
<dd>
<p><b>A:</b> Make sure <tt>/etc/sasldb2</tt> is readable by the
Cyrus user.</p>
</dd>
<dt><b>Q:</b> I'm using "<tt>sasl_pwcheck_method: saslauthd</tt>", but
authentication isn't working.</dt>
<dd>
<p><b>A:</b> Make sure that the <tt>saslauthd</tt> daemon is running
(you'll want to start it when the system boots). <tt>imapd</tt> is
unable to connect to <tt>saslauthd</tt> if the following message
appears in the logs:</p>
<pre>
Dec 6 12:58:57 mail3.andrew.cmu.edu imapd[1297]: cannot connect to saslauthd server
</pre>
<p>Make sure that <tt>saslauthd</tt> is running and that the cyrus
user can access the unix domain socket (defaults to <tt>/var/run/mux</tt>).
</dd>
<dt><b>Q:</b> I'm getting messages about "duplicate_prune". What's
wrong?</dt>
<dd><p><b>A:</b> These messages look like </p>
<pre>
Jan 14 13:46:24 grant ctl_deliver[9060]: duplicate_prune: opening
/var/imap/deliverdb/deliver-x.db: No such file or directory
Jan 14 13:46:24 grant ctl_deliver[9060]: duplicate_prune: opening
/var/imap/deliverdb/deliver-y.db: No such file or directory
Jan 14 13:46:24 grant ctl_deliver[9060]: duplicate_prune: opening
/var/imap/deliverdb/deliver-z.db: No such file or directory
</pre>
<p>These messages are normal; one file is maintained for each user
beginning with "x", "y", "z", etc. If you're first starting or you
have no users beginning with these letters, these messages are
completely normal and can be ignored.</p>
</dd>
<dt><b>Q:</b> I'm getting a message about "<tt>imapd: could not
getenv(CYRUS_SERVICE); exiting</tt>" in my <tt>imapd.log</tt>.
What's wrong?</dt>
<dd>
<p><b>A:</b> Remove all <tt>imap</tt>, <tt>pop</tt>, <tt>lmtp</tt>
and <tt>sieve</tt> lines from <tt>[x]inetd.conf</tt> and restart
<tt>[x]inetd</tt>.</p>
</dd>
<dt><b>Q:</b> How do I use different SSL/TLS certificates for imap
and pop?</dt>
<dd>
<p><b>A:</b> Specify the different certs using the appropriate
options in <tt>imapd.conf</tt>. Read <tt>imapd.conf(5)</tt> for
details.</p>
</dd>
<dt><b>Q:</b> My KPOP client is complaining about TLS keys. What
should I do?</dt>
<dd>
<p><b>A:</b> Disable TLS for the kpop service. Either set
<tt>tls_pop3_cert_file</tt> to <b>disabled</b> in
<tt>imapd.conf</tt> (which will also disable SSL/TLS for pop3), or
use a separate config file for kpop. For example, change the kpop
service in <tt>cyrus.conf</tt> to something like:</p>
<pre>
kpop cmd="pop3d -k -C /etc/kpopd.conf" listen="kpop"
</pre>
<p>then copy <tt>/etc/imapd.conf</tt> to <tt>/etc/kpopd.conf</tt> and
remove the <tt>tls_*</tt> options.</p>
</dd>
<dt><b>Q:</b> Eudora 5.x can't connect using STARTTLS ("SSL
Neogotiation Failed"). What should I do?</dt>
<dd>
<p><b>A:</b> First, complain to QUALCOMM because their STARTTLS
implementation is broken. Eudora doesn't support TLSv1 (per
RFC2246) and Cyrus requires it. If you really need this before it
is fixed in Eudora, remove or comment out the following lines in
tls.c:</p>
<pre>
if (tlsonly) {
off |= SSL_OP_NO_SSLv2;
off |= SSL_OP_NO_SSLv3;
}
</pre>
</dd>
<dt><b>Q:</b> I'm getting messages in <tt>imapd.log</tt> like:
<pre>
Sep 11 17:23:55 ogg lmtpd[773]: DBERROR db3: 16 lockers
Sep 11 17:23:55 ogg lmtpd[1409]: DBERROR db3: 17 lockers
Sep 11 17:23:56 ogg lmtpd[1508]: DBERROR db3: 9 lockers
Sep 11 17:23:56 ogg lmtpd[776]: DBERROR db3: 9 lockers
</pre>
What's wrong?
</dt>
<dd>
<p><b>A:</b> Nothing is wrong. These messages are logged whenever
Berkeley db encounters lock contention, but isn't necessarily a
problem by themselves. This is especially likely when you have an
empty or small duplicate delivery database and are receiving a large
volume of e-mail.</p>
<p>Berkeley db 4.0 has a bug where the number of lockers isn't
decremented properly, causing this number to be unreliable.</p>
</dd>
</dl>
<hr />
last modified: $Date: 2002/12/02 21:44:50 $ <br />
<a href="index.html">Return</a> to the Cyrus IMAP Server Home Page
</body>
</html>
