#753 - set up an order system to let eyeo employees file order requests

manifests/issuesserver.pp

 node 'issues1' {
-  include base
+
+  include base, private::trac
 
   class {'trac':
     domain => 'issues.adblockplus.org',
     certificate => 'issues.adblockplus.org_sslcert.pem',
     private_key => 'issues.adblockplus.org_sslcert.key',
     is_default => true,
   }
 
+  trac::instance {'trac':
+    config => 'trac/trac.ini.erb',
+    description => 'Adblock Plus Issue Tracker',
+    environment => 'environment',
+    location => '/',
+    logo => 'adblockplus_logo.png',
+    database => 'trac',
+  }
+
+  trac::instance {'orders':
+    config => 'trac/orders.ini.erb',
+    description => 'Eyeo Order System',
+    environment => 'environment-orders',
+    location => '/orders/',
+    logo => 'eyeo_logo.png',
+    database => 'trac_orders',
+  }
+
+  # Transforming the auth_cookie table of the "new" Trac project into a
+  # federated uplink for the "old" project's table of the same name avoids
+  # the need to convert the entire auth to htpasswd-file handling, which
+  # would be the official way to go for achieving a shared authentication.
+  exec { 'trac_auth_cookie_federated':
+    command => "mysql -utrac -p'${private::trac::database_password}' trac --execute 'SHOW CREATE TABLE auth_cookie' -N \
+      | cut -d' ' -f2 \
+      | sed -e 's/auth_cookie/auth_cookie_federated/' -e 's/\\\\n//g' \
+            -e 's/ENGINE=[A-Za-z]\\+/ENGINE=FEDERATED/' \
+            -e 's/$/ CONNECTION=\"mysql:\\/\\/trac:${private::trac::database_password}@localhost\\/trac\\/auth_cookie\";/' \
+            -e 's/$/ RENAME TABLE auth_cookie TO auth_cookie_original, auth_cookie_federated TO auth_cookie;/' \
+      | mysql -utrac -p'${private::trac::database_password}' trac_orders
+    ",
+    unless => "mysql -utrac -p'${private::trac::database_password}' trac_orders --execute 'SHOW CREATE TABLE auth_cookie' | grep FEDERATED",

[Wladimir Palant, 2014/07/22 13:52:24]

This is quite complex, and there are lots of warning referring to federated
MySQL tables (performance, security). Since both instances run on the same
server, what about:

    CREATE VIEW trac_orders.auth_cookie AS SELECT * FROM trac.auth_cookie;

This view should be updatable, won't it work as well?

[mathias, 2014/07/24 16:36:49]

Sure, it does. Yet it does not allow to move to a distinct server some day
(which was intended before). However, since that's not an issue any more, I'll
update it accordingly.

+    path => "/usr/bin:/usr/sbin:/bin:/usr/local/bin",
+    require => [
+      Exec["deploy_trac"],
+      Exec["deploy_orders"],
+    ],
+  }
+
+  # Synchronizing e-mail and password information between the project
+  # allows for logging in from any entry point - whilst maintaining a
+  # registration form (and process) in one project only.

[Wladimir Palant, 2014/07/22 13:52:24]

Why do we want this table to be synced (rather infrequently) rather than shared?

[mathias, 2014/07/24 16:36:49]

Because the Trac software also stores other information in this fashion (see the
NAME IN() clause, which restricts to those pieces we need). One example is
search criteria, which may include ticket types and the like - those are not
equal in the Trac instances.

+  cron {'trac_session_attribute_sync':
+    ensure => present,
+    user => trac,
+    minute => '*/30',
+    command => "mysql -utrac -p'${private::trac::database_password}' trac_orders --execute ' \
+      INSERT INTO session_attribute (sid, authenticated, name, value) SELECT sid, authenticated, name, value \
+      FROM trac.session_attribute WHERE authenticated = 1 AND name IN (\"email\", \"password\") \
+      ON DUPLICATE KEY UPDATE value=VALUES(value) ' >/dev/null
+    ",
+    require => Exec['trac_auth_cookie_federated'],
+  }
+
   class {'nagios::client':
     server_address => 'monitoring.adblockplus.org'
   }
 }