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.
- 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.
- 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=