I was recently asked to upgrade some neolithic aged software (UW-IMAP,
sendmail 8.12.x, apache 1.3, amongst other horrors).
The box is physically remote, so an aggressive "new flush" wasn't
an option.
I've been able to upgrade the compiler to gcc-3.4, openssl to 1.0.2k, glibc,
php to something in the 5.4-branch, etc.
I have CLucene working, even.
I know should take a shotgun to the box and retire it. It's a NORTHWOOD P4,
no
less, with only 1.5GB RAM and 74GB of SCSI-160 storage.
*BUT* that isn't my call to make, as much as I'd like to do the right
thing.
When Life(tm) hands you incredibly sour and bitter oranges, the best you can
do aside from making a Palmetto Punch, is perhaps traditional Cochinita pibil
the way they do in the Yucatan.
I ran across two main problems, the first of which struck during the build.
Amazingly enough, I was able to update pcre, gettext, openssl, textcat, and
other libraries to modern versions without too much pain and suffering.
1) In src/lib/compat.h there is a definition for p(read|write) that conflicts
with the one in /usr/include/unistd.h
On this box, there is a macro appended to the definition (to control whether
or not THROW is defined in C++ "mode"). This is regulated by using
the macro
__THROW. I assume this is anachronistic.
2) There was an odd overflow bug in the quota module. (Yes, would you believe
that user quotas are used + enforced on this Frankenbox?) I assume it's a
rarely seen issue because few Dovecot users compile the software in caves on
computers powered by horse-pulled generator wheels. I suspect Timo's seen
more Abominable Snowcreatures in Espoo than systems like these.
Simply adding an explicit 64 bit (unsigned) type to the constant multipliers
seemed to address this. Of these two patches, this is probably the most
"safe"
and thus likely to be accepted into the main branch of code.
Thanks for the great software, as always, Timo. It's a testimony to your
design and implementation acumen that software you've written in 2017 still
runs on machines that went obsolete in 480 B.C.E.
I am trying to track down one possible issue that could be locking-related,
which causes some mailbox open operations to see to take longer than they
should. Log entries like:
> Warning: Transaction log file
/home/luser/mail/.imap/INBOX/dovecot.index.log
> was locked for 95 seconds (rotating while syncing)
> Warning: Transaction log file
/home/luser/mail/.imap/INBOX/dovecot.index.log
> was locked for 92 seconds (rotating while syncing)
I am using sendmail 8.15.2 (HASFLOCK not defined) and procmail 3.22 (Locking
strategies: dotlocking, fcntl(), lockf(), flock())
I also see odd errors while using SeaMonkey clients:
imap(luser): Error: fchown(/home/luser/mail/.subscriptions.lock,
group=501(coregroup)) failed: Operation not permitted (egid=200(users), group
based on /home/luser/mail - see http://wiki2.dovecot.org/Errors/ChgrpNoPerm)
imap(luser): Error: file_dotlock_open() failed with subscription file
/home/luser/mail/.subscriptions: Operation not permitted
.subscriptions doesn't exist either as a file or a directory in the named
directories.
Is there a "filter" against dot-files being opened within the bowels
of dovecot?
Onto the "meat" of this "bug" report:
Dovecot: dovecot-2.2.30.2
Slackware 9 (with most of the core libs upgraded to the latest possible)
Kernel: 2.4.35-ow2
Configure command: CC=gcc-3.4 CXX=g++-3.4 \
CFLAGS='-O2 -march=pentium4 -mtune=pentium4 -fPIC -fPIE \
-fomit-frame-pointer -fstack-protector-all -D_FORTIFY_SOURCE=2' \
CFLAGS='-O2 -march=pentium4 -mtune=pentium4 -fPIC -fPIE \
-fomit-frame-pointer -fstack-protector-all -D_FORTIFY_SOURCE=2' \
CPPFLAGS=-I/dev/shm/libstemmer_c/include \
LDFLAGS='-L/dev/shm/libstemmer_c -z relro -z now' \
./configure --prefix=/usr --with-ssldir=/etc/ssl --localstatedir=/var \
--sysconfdir=/etc/dovecot --with-bzlib --with-libcap --with-lz4 \
--with-textcat --with-stemmer --with-sql=yes --with-cdb \
--with-shadow --with-libwrap --with-moduledir=/usr/lib/dovecot \
--with-icu --with-lucene --with-sqlite --with-sql=yes
Build fix patch (mismatching prototype): https://pastebin.com/GS3a2DPX
Quota Overflow Fix Patch: https://pastebin.com/gsSXmkz9
Dovecot configuration: https://pastebin.com/JX43feFw
Without the patch:
# doveadm quota get -u luser
Quota name Type Value Limit %
User quota STORAGE 3365836 1305696 257
Group quota STORAGE 0 - 0
(All attempts to add mail to any folder fail with a quota error.)
With the patch:
# doveadm quota get -u luser
Quota name Type Value Limit %
User quota STORAGE 3364608 5500000 61
Group quota STORAGE 0 - 0
Thanks,
=M=