Modify

Ticket #957 (closed task: fixed)

Opened 12 years ago

Last modified 12 years ago

Please document the time_zone config option.

Reported by: m4z <[email protected]…> Owned by: desai
Priority: minor Milestone: Bcfg2 1.2.0 Release
Component: bcfg2-doc Version: 1.0
Keywords: timezone time zone log timestamp Cc:

Description

On bcfg2-server 1.1.0, when I use -o, I get:

foo:/var/lib/bcfg2 # date
Tue Oct 26 10:34:19 CEST 2010

foo:/var/lib/bcfg2 # python -c "import time; print time.asctime()"
Tue Oct 26 10:34:21 2010

foo:/var/lib/bcfg2 # tail -1 /var/log/bcfg2-server.log | sed "s/: .*//"
2010-10-26 03:30:15,887 bcfg2-server[9023]

(The log entry is 4 minutes old.)

I tried to set

[statistics]
time_zone = Europe/Berlin

in /etc/bcfg2.conf, and it works:

foo:/var/lib/bcfg2 # tail -1 /var/log/bcfg2-server.log | sed "s/: .*//"
2010-10-26 10:39:05,130 bcfg2-server[30095]
foo:/var/lib/bcfg2 #   

However, the time_zone option is not documented (neither in the old nor new docs, nor the bcfg2.conf manpage).

#600, where I got the idea to try this, only talks about reports, not server logging; and r5743 links to the django website to explain the timezone stuff, which I don't use if I don't use reports, so it kind of suggests to a newbie like me that the above attempt won't work anyway.

So please document it. If I find the time, I might begin to do so myself, but i certainly lack the knowledge. (;

Attachments

Change History

comment:1 Changed 12 years ago by solj

This does not make sense as the time_zone option is only read for either the reporting system or hostbase:

$ grep -ir time_zone src/
src/lib/Server/Hostbase/test/test_environ_settings.py:    os.environ['bcfg_time_zone'] = 'CHI'
src/lib/Server/Hostbase/test/test_environ_settings.py:    os.environ['bcfg_time_zone'] = 'CHI'
src/lib/Server/Hostbase/test/test_environ_settings.py:    assert s.TIME_ZONE == 'CHI'
src/lib/Server/Hostbase/settings.py:TIME_ZONE = 'America/Chicago'
src/lib/Server/Reports/settings.py:    TIME_ZONE = c.get('statistics', 'time_zone')
src/lib/Server/Reports/settings.py:    TIME_ZONE = 'America/Chicago'

This setting is never read elsewhere. Are you sure that nothing else was changed before it started working?

comment:2 Changed 12 years ago by m4z <[email protected]…>

Ok, it makes sense now, let me clarify. It seems I misunderstood the Reports stuff.

First of all, yes, I am sure I changed nothing else. Once I comment out the time_zone line in bcfg2.conf and restart the server, the time is off by 7 hours again:

2010-10-26 12:44:05,361 bcfg2-server[26004]: serve_forever() [stop]
2010-10-26 12:44:05,362 bcfg2-server[26004]: server_close()
2010-10-26 05:44:13,070 bcfg2-server[28047]: Searching for new models to add to the statistics database

I am, however, using Reports. When I disable the DBStats plugin, the time is correct without setting time_zone. I had no idea this changes the time for the whole of bcfg - I am certainly lacking knowledge of the code (and maybe of python, too...). And I didn't expect there is a hardcoded default instead of reading the timezone from the system (if this is possible with python).

Complete server config (in the form that produced the error, so with DBStats enabled):

[server]
repository = /var/lib/bcfg2
# Base:         stuff that many hosts should get (not really used by us)
# Bundler:      associate/put things together in a bundle
# Cfg:          for managing config and other files
# Metadata:     managing clients and groups
# Packages:     for handling software packages (alternative to Pkgmgr)
# Rules:        for service daemons
# SSHBase:      manage ssh server keys
#
# default plugins are
#plugins = Base,Bundler,Cfg,Metadata,Pkgmgr,Rules,SSHbase
plugins = Base,Bundler,Cfg,DBStats,Git,Metadata,Packages,Probes,Rules,SSHbase

[statistics]
sendmailpath = /usr/lib/sendmail
database_engine = sqlite3
# 'postgresql', 'mysql', 'mysql_old', 'sqlite3' or 'ado_mssql'.
database_name =
# Or path to database file if using sqlite3.
#<repository>/etc/brpt.sqlite is default path if left empty
database_user =
# Not used with sqlite3.
database_password =
# Not used with sqlite3.
database_host =
# Not used with sqlite3.
database_port =
# Set to empty string for default. Not used with sqlite3.
web_debug = True
#time_zone = Europe/Berlin

[communication]
protocol = xmlrpc/ssl
password = XXX
certificate = /etc/bcfg2.crt
key = /etc/bcfg2.key
ca = /etc/bcfg2.crt

[components]
bcfg2 = https://foo.example.org:6789
encoding = UTF-8

[mdata]
paranoid = true

[client]
max_copies = 50
path = /var/cache/bcfg2

So, to rephrase:

  • Please document the time_zone option (including default behavior and that it affects all time in bcfg).
  • Please change the default timezone to be read from the system, if possible.

Thanks!

comment:3 Changed 12 years ago by solj

I'm thinking that maybe our fallback setting is just a bad choice. Please try out http://bcfg2.pastebin.com/5hskHZJ0 and see if that fixes the issue for you.

comment:4 Changed 12 years ago by m4z <[email protected]…>

The Reports patch works like a charm, thank you!

I haven't tested Hostbase, since I don't use it.

comment:5 Changed 12 years ago by solj

comment:6 Changed 12 years ago by solj

  • Status changed from new to closed
  • Resolution set to fixed

WARNING! You need to establish a session before you can create or edit tickets. Otherwise the ticket will get treated as spam.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.