Bug 205330 - Dovecot logs uses only UTC time
Dovecot logs uses only UTC time
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: dovecot (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Michal Hlavinka
Depends On:
  Show dependency treegraph
Reported: 2006-09-05 22:46 EDT by Matthew Sage
Modified: 2010-10-22 01:56 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-05 09:37:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matthew Sage 2006-09-05 22:46:39 EDT
Description of problem:
Dovecot uses UTC time to log login details if 'login_chroot' is turned on.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Set logins to work in a chroot gaol - in /etc/dovecot.conf:
login_chroot = yes

Actual results:
Dovecot logging will use UTC time, ignoring /etc/localtime

Expected results:
Dovecot logging should respect /etc/localtime

Additional info:
This is caused because /etc/localtime is not accessible from the chroot gaol.

Previous workaround is to disable the login_chroot feature.

The following patch to the init.d script overcomes the problem:

*** /etc/init.d/dovecot.logfix 2006-09-06 12:14:34.000000000 +1000
--- /etc/init.d/dovecot  2006-02-08 10:57:35.000000000 +1100
*** 21,36 ****
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/dovecot
-       # Check to see if login is chrooted
-       CHROOT_VAL=`grep ^login_chroot /etc/dovecot.conf | cut -f2 -d= | sed -e
's/^ *//'`
-       if [ "$CHROOT_VAL" != "no" ]; then
-               CHROOT_DIR=`grep ^login_dir /etc/dovecot.conf | cut -f2 -d= |
sed -e 's/^ *//'`
-               if [ -z "$CHROOT_DIR" ]; then
-                       # dovecot default
-                       CHROOT_DIR="/var/run/dovecot/login"
-               fi
-               mkdir $CHROOT_DIR/etc
-               cp /etc/localtime /$CHROOT_DIR/etc/
-       fi
--- 21,24 ----
Comment 1 Dan Horák 2008-06-10 11:56:59 EDT
I don't think the initscript is the right place to prepare chrooted environment.
Better should be to add a standalone script (e.g. prepare-chroot.sh) into
/usr/share/doc/dovecot-*/ that the user configuring chrooted login can call.
Comment 2 Matthew Sage 2008-06-10 17:14:18 EDT
Although I agree in principle, the problem is that an admin wants to be able to
configure Dovecot and be able to start the service using '/sbin/service dovecot
start' (i.e. the useability of Dovecot should be the primary concern, not
ideological correctness).

This cannot happen the way you suggest because the description of the login_dir
variable states (from /etc/dovecot.conf),

# Directory where authentication process places authentication UNIX sockets
# which login needs to be able to connect to. The sockets are created when
# running as root, so you don't have to worry about permissions. Note that
# everything in this directory is deleted when Dovecot is started.

The localtime file is deleted each time Dovecot starts, so the only possible
place to set this up in the chroot environment is in the initscript, after the
daemon has been started.

Ugly, but...
Comment 3 Dan Horák 2008-06-11 06:32:36 EDT
Hmm, after looking at the issue more seriously, the update to the init script
looks like the right way.
Comment 4 RHEL Product and Program Management 2008-10-31 12:41:39 EDT
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 5 Michal Hlavinka 2010-03-05 09:37:58 EST
I'm sorry for not addressing the issue in RHEL-4. As dovecot
is not scheduled for update in RHEL-4.9, I'm closing that bugzilla WONTFIX. If
you are still experiencing the issue with RHEL-5, feel free to reopen it
against RHEL-5.

Note You need to log in before you can comment on or make changes to this bug.