import rt 3.8.8

3 files changed, 95 insertions, 19 deletions

diff --git a/rt/docs/Security b/rt/docs/Security
index c9787ac52..51ddfabdb 100644
--- a/rt/docs/Security
+++ b/rt/docs/Security
@@ -1,25 +1,12 @@
-RT2 runs setgid to some group (it defaults to 'rt').
+Security tips for running RT3
 
-rt's configuration file, 'config.pm', is not world readable because it 
-contains rt's database password. If  a user gets access to this file, he
-can arbitrarily manipulate the RT database. This is bad. You don't want
-this to happen.  config.pm is mode 550. No users should be members of 
-the 'rt' group unless you want them to be able to obtain your rt password.
+0   Protect your RT installation by making it only accessible via SSL
 
-If you're running the web interface, you'll need to make sure your webserver
-has access to config.pm.  You could do this by letting your webserver's user
-be a member of the 'rt' group. This has the disadvantage of letting 
-any mod_perl code on your web server have access to your RT password.
+1   Be sure to change the password for the root user of RT.  The default password is "password".  This can be changed via the RT web interface at: Preferences > About me
 
-Alternatively, you can run RT2 on its own apache instance bound to a high
-port on 127.0.0.1
-which runs as a non-priviledged user which is a member of the group 'rt'.  
+2   Be sure to protect your RT_SiteConfig.pm file if it contains database credentials or other sensitive information.  This file only needs to be readable by RT and your web server.  One way to accomplish this is to make the file readable only by root and the group that RT runs as, and then make sure your web server is a member of that group.  Advanced configuration may be required if other users have the ability to run CGIs or access the server where RT is running.  Otherwise, those users may have access to become RT superusers.
 
-Configure your webserver to proxy requests to RT's 
-virtual directory to the apache instance you just set up.
-
-TODO: doc the apache configs needed to do this.
-
-The same technique can be used to run multiple RT2 instances on the same host.
+3   Be sure to protect your database.  If it does not need to talk to the world, then don't allow it to listen for remote connections.  With MySQL this can be accomplished via "skip-networking".  If you use your database for other things and must allow remote connections, be sure to use a strong, hard to guess  password for RT.
 
+4   Apache, lighttpd, and most other web servers support name based virtual hosts.  When possible, configure RT as a name based virtual host to raise the bar against DNS rebinding attacks.  Note:  If when you visit http://your.servers.ipaddress.here you see RT, it means you are not likely getting this additional protection.
 
diff --git a/rt/docs/templates.pod b/rt/docs/templates.pod
index 76856d456..d6a9a9937 100644
--- a/rt/docs/templates.pod
+++ b/rt/docs/templates.pod
@@ -3,6 +3,11 @@
 Each template is split into two sections. A block of headers and a body. These
 sections are separated by a blank line.
 
+Templates are processed by the L<Text::Template> module. This module
+allows you to embed arbitrary Perl code into your templates. Text wrapped
+in curly braces, C<{...}> is interpreted as Perl. See L<Text::Template>
+for more information.
+
 =head2 Headers
 
 Your template may specify arbitrary email headers. Each header is a name, a
diff --git a/rt/docs/timezones_in_charts.pod b/rt/docs/timezones_in_charts.pod
new file mode 100644
index 000000000..003322238
--- /dev/null
+++ b/rt/docs/timezones_in_charts.pod
@@ -0,0 +1,84 @@
+=head1 INTRO
+
+Every date in RT's DB is stored in UTC format. This affects charts
+groupped by time periods (Annually, Monthly, etc.). To produce
+charts that are in a specific timezone we have to use DB's specific
+functions to convert time. Each DB has very different requirements.
+
+=head1 CONFIGURATION
+
+This code is experimental and you can turn it on and off using
+boolean option $ChartsTimezonesInDB in the RT config.
+
+=head1 DATABASE SPECIFIC NOTES
+
+=head2 mysql
+
+Time can not just be converted using numeric time shift as this
+shift value depends on day saving time properties of the time zone.
+
+mysql since 4.1.3 supports named timezones, but you have to fill
+special tables with up to date data. On modern systems it's Usually
+very easy:
+
+    mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql
+
+mysql's doc recommends to restart server. Read more about timezones
+in mysql in the following document
+http://dev.mysql.com/doc/refman/5.0/en/time-zone-support.html .
+
+=head2 Postgres
+
+Postgres database uses system's functions to deal with timezones.
+You shouldn't do anything particular except making sure that
+data in F</usr/share/zoneinfo> is up to date. On some systems
+this means upgrading a system package.
+
+=head3 Note for users of Pg 7.2 and older or users upgraded from those
+
+You should be sure that timestamps in RT DB have no TZ set. TIMESTAMP
+column type in Postgres prior to Pg 7.3 has timezone info by default.
+In newer versions it's not the case anymore. If you have such system
+then you should alter columns.
+
+=head2 Other databases
+
+There is no implementation for other DBs, yet.
+
+=head1 FOR DEVELOPERS
+
+=head2 Postgres
+
+We use timestamp type for all datetime fields. It either has timezone
+info or not, by default since Pg 7.3 it has no timezone. Conversion is
+kinda tricky:
+
+    timezone('Europe/Moscow', timezone('UTC', column_without_tz_info))
+    timezone('to_tz', timezone('from_tz', column_without_tz_info))
+    http://www.postgresql.org/docs/7.4/static/functions-datetime.html#FUNCTIONS-DATETIME-ZONECONVERT
+
+This function flips HAS_TZ flag on the argument. First call makes
+no conversion, but flips HAS_TZ flag. So next call flips it back
+and does actual conversion.
+
+http://www.postgresql.org/docs/7.4/static/datatype-datetime.html#DATATYPE-TIMEZONES
+
+=head2 mysql
+
+Once there is a timezone info loaded in tables on the server
+we have all the same set of named timezones like in system
+and DateTime (DateTime project has copy of the TZ data in a module).
+
+CONVERT_TZ(TS, from, to) exists since mysql 4.1.3. Note that it
+takes timestamp, so supports limitted range (usuall 1970-2038).
+
+=head2 Oracle
+
+Look at FROM_TZ function.
+
+=head2 SQLite
+
+As far as I can see has no support.
+
+=cut
+