Bug 106572 - bind-chroot doesn't install chroot's /etc/localtime, nor update it on tzdata updates
bind-chroot doesn't install chroot's /etc/localtime, nor update it on tzdata ...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
2
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
:
: 132385 (view as bug list)
Depends On: 107507
Blocks: FC3Target
  Show dependency treegraph
 
Reported: 2003-10-08 10:50 EDT by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: bind-9.2.4rc8-14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-20 12:30:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2003-10-08 10:50:16 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031003

Description of problem:
/var/log/messages entries issued by a chrooted bind are in UTC, not in the local
timezone, but they don't say so.  This can be very confusing.

Version-Release number of selected component (if applicable):
bind-chroot-9.2.2.P3-4

How reproducible:
Always

Steps to Reproduce:
1.Start bind in the chroot
2.Look at /var/log/messages

Actual Results:  Messages will not be in the local timezone, without any
indication of being in UTC.

Expected Results:  They should be in the local timezone.

Additional info:

Copying /etc/localtime to the chroot should be enough to fix this.
Comment 1 Daniel Walsh 2003-10-08 11:06:15 EDT
 Fixed in bind-9_2_2_P3-6

Dan
Comment 2 Alexandre Oliva 2003-10-09 02:10:50 EDT
I don't see any change in behavior.  /etc/localtime is not present in the
chroot, and messages are still logged with the wrong timezone.
Comment 3 Alexandre Oliva 2003-10-18 16:28:39 EDT
Still present in -9
Comment 4 Daniel Walsh 2003-10-19 00:20:44 EDT
This works on my machine.  Please make sure you uninstall bind-chroot and
reinstall it.  Since there is now a check to make sure files only get moved the
first time bind-chroot gets installed.  

Dan
Comment 5 Alexandre Oliva 2003-10-19 13:49:46 EDT
Aha, the uninstall&reinstall bit was what I was missing.  This fixes the
problem, indeed.

Ideally, there should be some trigger on tzdata updates to copy the file again,
should it change. tzdata should itself update /etc/localtime on postinstall, but
currently it doesn't.
Comment 6 Daniel Walsh 2003-10-22 09:28:20 EDT
So this bug is closed correct?

Dan
Comment 7 Alexandre Oliva 2003-10-22 14:08:46 EDT
Hmm...  Maybe I should have closed this bug and opened a new one about the
tzdata trigger, instead of changing the summary?
Comment 8 Jakub Jelinek 2003-11-13 15:58:02 EST
tzdata cannot depend on shell etc. as it is a dependency loop.
So I think the trigger needs to go into some other packages.
What about redhat-config-date? That is a package which normally
modifies /etc/localtime...
Comment 9 Alexandre Oliva 2003-11-13 16:03:07 EST
This bug should remain open against bind, since bind should eventually
be changed when tzdata is adjusted, at which point bug 107507, that
this bug depends on, will remind us.
Comment 10 Alexandre Oliva 2004-05-24 10:47:53 EDT
/var/named/chroot/etc/localtime is not there after an everything FC2
install from scratch.
Comment 11 SEKINE Tatsuo 2004-08-04 11:44:20 EDT
Hi, why don't you know how to debug?

  # rpm -ivvh bind-chroot-9.2.3-13.i386.rpm 
  D: ============== bind-chroot-9.2.3-13.i386.rpm
  (snip)
  D:   install: %post(bind-chroot-9.2.3-13)       execv(/bin/sh) pid  2501
  + test -r /etc/sysconfig/named
  + grep -q '^ROOTDIR=' /etc/sysconfig/named
  + echo ROOTDIR=/var/named/chroot
  + '[' '!' -d /var/tmp ']'
  (snip)

It was easy to find out the reason of this BUG.
The patch which fixes this BUG is below.
 
--- bind.spec   2004/08/04 15:31:39     1.1
+++ bind.spec   2004/08/04 15:32:11
@@ -101,7 +101,7 @@
 then :
 else 
 echo ROOTDIR="%{prefix}" >>/etc/sysconfig/named
-if [ ! -d "${prefix}/var/tmp" ]; then
+if [ ! -d "%{prefix}/var/tmp" ]; then
        mkdir -m770 -p "%{prefix}/var/tmp"
        rm -f "%{prefix}/dev/null"
        mknod "%{prefix}/dev/null" c 1 3

Comment 12 Jason Vas Dias 2004-08-04 19:26:34 EDT
This was fixed in bind-9.2.4rc6-3 .
Next version (bind-9.2.4rc6-4) will make the chroot /etc/localtime
a hard link to /etc/localtime instead of copying. Will ensure tzdata
updates /etc/localtime.
Comment 13 Alexandre Oliva 2004-09-05 02:12:33 EDT
It does copy /etc/localtime to /var/named/chroot/etc at install time,
indeed, but AFAICT it still fails to update the copy of /etc/localtime
in the chroot after a tzdata update (or anything else) that updates
it.  How was it supposed to update /etc/localtime in the chroot after,
say, a tzdata update that modifies /etc/localtime?
Comment 14 Alexandre Oliva 2004-09-11 22:08:28 EDT
And it gets worse: apparently, at the time we run the bind-chroot
%post script at install time (anaconda), /etc/localtime in
/mnt/sysimage is America/New_York, regardless of the timezone selected
in the installer.  Only at the end of the install is /etc/localtime
set up  according to the user selection, so
/var/named/chroot/etc/localtime is always wrong unless you happen to
be in America/New_York timezone.
Comment 15 Alexandre Oliva 2004-09-11 22:17:12 EDT
Filed the above as bug 132385.
Comment 16 Jason Vas Dias 2004-09-13 11:13:15 EDT
 I'll fix by checking if /etc/localtime has changed in the named
 initscript and copying it again if so; this will handle timezone
 updates as well as initial install - this should be fixed in:
 bind-9.2.4rc7-14
Comment 17 Alexandre Oliva 2004-09-13 17:00:09 EDT
*** Bug 132385 has been marked as a duplicate of this bug. ***
Comment 18 Jason Vas Dias 2004-09-20 12:30:42 EDT
 This is now fixed in bind-9.2.4rc8-14 (fc3-head).

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