See show.tiki.org Overview first. Here is a great intro: https://tiki.org/Presentation-Fosdem-2014-show.tiki.org (see PDF)

Questions

• Do we need to run different versions of Tiki with different versions of PHP? trunk now needs 5.5, how do older Tikis work with that?

Architecture

• Own set of scripts
  • We have a very defined set of things to do. Adding something like puppet as a layer over calling these very defined scripts doesn't add anything else than overhead.
• All on one server
  • If in future we need to have multiple servers we can simply have multiple machines behind proxy (we will only need this if we are too successful)
• Create apache virtual hosts for john1.show.tiki.org etc...
• A global htpasswd protection
• Have local mirrors of various Tiki SVN tag versions (part of release procedure, or potentially when we are tired of adding them write a cron job to check for new tags - pretty trivial)
• On show.tiki.org, there is ssh access via key which can be accessed from dev.tiki.org.
• Connection to show.tiki.org can be through http://www.php.net/manual/en/function.ssh2-exec.php.
  • If we end you using another tool, e.g. Puppet/Chef, there might be PHP libs provided that can do the connection as well
  • executable on show.tiki.org provides response with info e.g. the domain back to server
  • In the case of failure on scripts on show.tiki.org, best effort to put up a warning HTML on the domain as much as possible, and also send out email to admin and (different email) user about error.
• Would need a secure execution environment on show.tw.org that has no access to system shell, but only to allowed script services.
• Need some security precautions to avoid server compromise from instance.

Scripts needed

Whether or not we use a tool like Puppet/Chef, there will need to be scripts - whether it is a shell script, or puppet script, etc...

Instance creation

1. Virtual host creation
2. Instance creation from tag
   1. clone tag instance to target directory (use subdirectory if provided by user)
   2. svn switch(checkout?) to specific revision if specified by user.
   3. Import tiki.sql
   4. Modify tiki.sql
      1. Create random password and let the user know?
      2. Turn on action log and turn on everything
      3. Admin email set to user's email
      4. Name of site dynamically set based on username with an algorithm which guarantees that we can trace all sites of a given user, and still have nice legible names for the simplest cases (not a high priority).
         • If the username has anything other than letters and numbers without spaces, dev.tw.o just use "user<tikiuserId>" to be safe. Name of site is e.g. john-1-v10-1.show.tiki.org or john-1-r38987.show.tiki.org
   5. Run setup.sh
   6. Run htaccess.sh (this is an option on setup and can be triggered afterwards), set RewriteBase if in subdirectory (and message that we did it)
3. Send email after instance creation (from show)

Snapshot creation

1. On demand from dev.tw.o, show.tiki.org will create a snapshot, store it on a folder john-1.show.tiki.org/snapshots/......tgz? A snapshot is a tarball for source and a tarball for database.
2. The snapshots on show.tiki.org are matched to corresponding items in a snapshots tracker on dev.tiki.org (visible through items list field on the bug tracker).
3. On deletion of the snapshot item on the snapshots tracker, a request for deleting of the snapshot is done on show.tiki.org. Probably only admins will delete snapshots (no harm in keeping more).
4. Once the bug tracker item is closed, the links to the snapshots will no longer be visible in case they have been deleted.

Instance upgrading

1. Make exact clone from existing (code + db);
2. svn -rxxxx or switch
3. doctools/sqlupgrade.sh
4. run setup.sh for composer.
5. Need to be able to detect error, same handling as for new instance, email admin and user.
6. Perhaps the script can be tried twice before considered fail.
7. We could also write in the email "please try again later tomorrow" or something like that

Instance destruction

1. 30 days after tracker item is closed on dev, the instance is removed, triggered from dev.
2. Delayed destruction of snapshots.
3. Provide a way for admin of dev to trigger an immediate destruction and clearing of this.
4. When users are deleted from tiki.org, the instance needs to be destroyed as well, this should happen through lib/setup/events.php.
5. When tracker item is deleted, it should also remove the show instance similarly.
6. Add a popup warning for an admin deleting a tracker item that a show instance will be deleted.
7. 48h before destruction, there is an email sent with instructions to postpone destruction, if necessary.

Implementation

There is ssh://ctrl@show.tiki.org which has tim-ssh as its login shell and can create, destroy and snapshot instances. You can call it like

# ssh ctrl@show.tiki.org create -t <SVN-Tag> -u <user> -i <Instabce-ID>
# ssh ctrl@show.tiki.org destroy -t <SVN-Tag> -u <user> -i <Instance-ID>
# ssh ctrl@show.tiki.org snapshot -t <SVN-Tag> -u <user> -i <Instance-ID>

The main script is /usr/local/sbin/tim and /usr/local/sbin/tim-ssh is a wrapper around it that is being used as the login shell.

The created sites can only be accessed via their show.tiki.org subdomain. So http://amette-42-10-0.show.tiki.org works, but http://amette-42-10-0.show.tiki.org doesn't. This is due to the registrar that we have tiki.org registered with, doesn't allow for wildcard domains.

To get access to this demo please contact mailto:jyhem@tiki.org.

Wishes

1. Broken feedback for "SVN update" button

We solve, close, or ignore?