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

manifests/issuesserver.pp

 node 'issues1' {
 
   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':
+  trac::instance {'issues':
     config => 'trac/trac.ini.erb',
     description => 'Adblock Plus Issue Tracker',
-    environment => 'environment',
     location => '/',
-    logo => 'adblockplus_logo.png',
+    logo => 'puppet:///modules/trac/adblockplus_logo.png',
     database => 'trac',
     permissions => "puppet:///modules/trac/permissions.csv",
   }
 
   trac::instance {'orders':
     config => 'trac/orders.ini.erb',
     description => 'Eyeo Order System',
-    environment => 'environment-orders',
     location => '/orders',
-    logo => 'eyeo_logo.png',
+    logo => 'puppet:///modules/trac/eyeo_logo.png',
     database => 'trac_orders',
     permissions => "puppet:///modules/trac/order-permissions.csv",
   }
 
   # Transforming the auth_cookie table of the "new" Trac project into an
   # insertable view 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_view':
     command => "mysql -utrac -p'${private::trac::database_password}' trac_orders --execute '
-      CREATE VIEW auth_cookie_view AS SELECT * FROM trac.auth_cookie;
-      RENAME TABLE auth_cookie TO auth_cookie_original, auth_cookie_view TO auth_cookie;'",

[Wladimir Palant, 2014/07/31 09:46:53]

Why the renaming? We don't want that empty table. So the following should do:

DROP TABLE IF EXISTS auth_cookie;
CREATE VIEW auth_cookie AS SELECT * FROM trac.auth_cookie;

[mathias, 2014/08/01 13:59:46]

Well, I still prefer my version: Beside having an implicit (thus cheap) backup,
it's also atomic. Therefore, it fails early enough no matter what could go
wrong. And the *_original does not hurt anyone - but may provide important
structure information for debugging after a future update or something like
that. Thus, although I understand that it might be overkill in this particular
situation, I do not see any reason to drop this practice - or that table.

[Wladimir Palant, 2014/08/01 14:11:13]

Backup of an empty table that isn't used anywhere? Also, why should we care here
whether the operation is atomic?
I'm generally unhappy about crap left behind just because it might become useful
at some point - that's what version control systems are for. I'd rather not
waste time in a year or two trying to figure out what this table is good for.

[mathias, 2014/08/01 16:25:03]

Since you prefer it without, I'll adjust it.

But, if you're interested,.. as I see it, it's not crap. It's documentation: As
long as we do not mirror every external resource (including e.g. trac and APT
packages for example), the original structure may change at any time and may
cause strange effects in development after future releases. Every debugging
developer would be happy if we left the original there. I've been there. A lot.
Also; the atomic nature allows that thingy to fail if we do anything wrong (e.g.
in the future) before every session is destroyed. 
I understand that this might be considered overkill in this particular
situation. But I'm not used to dropping good practices just because they are not
considered an requirement. It feels like an appendix operation without having a
problem with the blind gut at all..

+      DROP TABLE IF EXISTS auth_cookie;
+      CREATE VIEW auth_cookie AS SELECT * FROM trac.auth_cookie;'",
     unless => "mysql -utrac -p'${private::trac::database_password}' trac_orders --execute '
-      SHOW CREATE TABLE auth_cookie' | grep VIEW",

[Wladimir Palant, 2014/07/31 09:46:53]

How about:

unless => "mysql -utrac -p'${private::trac::database_password}' trac_orders
--execute 'SHOW CREATE VIEW auth_cookie'"

No need to grep, the exit code of the mysql command seems to be sufficient.

[mathias, 2014/08/01 13:59:46]

Agreed, done.

+      SHOW CREATE VIEW auth_cookie'",
     path => "/usr/bin:/usr/sbin:/bin:/usr/local/bin",
     require => [
-      Exec["deploy_trac"],
+      Exec["deploy_issues"],
       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.
   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_view'],
   }
 
+  # This directive is required due to legacy issues, where only one trac
+  # project was configured. Now we want to have more verbose names, e.g.
+  # tracd_issues and tracd_orders, but the spawn-fcgi module doesn't remove
+  # unmentioned former setups. So, in order to avoid conflicts or manual
+  # intervention during rollout, we must keep this statement here and never
+  # re-use the name again. Ugly, but neccessary.
+  spawn-fcgi::pool {"tracd":
+    ensure => absent,
+    require => Exec['tracd_kludge'],
+  }
+
+  # Unfortunately, the spawn-fcgi module is not capable of stopping the
+  # processes of pools that are changed to absent - simply because it removes
+  # the configuration file and the subsequent reload or restart does not
+  # recognize the pool any more. Thus, we have to ensure that the service is
+  # stopped before:
+  exec { 'tracd_kludge':
+    command => 'service spawn-fcgi stop',
+    onlyif => 'service spawn-fcgi status',
+    path => '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
+    notify => Service['spawn-fcgi'],
+  }
+
+  # Pretty similar to the "tracd" pool issue above: The trac-admin initenv
+  # command would fail for environment-issues after creation of the directory
+  # structure, when it comes to the database setup (which already exists),
+  # if we do not handle the existing resources manually..
+  exec { 'trac_env_issues_kludge':
+    command => 'ln -s environment /home/trac/environment-issues',
+    before => Exec['trac_env_issues'],
+    path => "/usr/bin:/bin",
+    user => trac,
+    onlyif => 'test -d /home/trac/environment && \
+      test ! -e /home/trac/environment-issues',
+    require => User['trac'],
+  }
+
   class {'nagios::client':
     server_address => 'monitoring.adblockplus.org'
   }
 }