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?

Subject	To be solved	To be ignored	To be closed	Comment	Done?
show server doesn't have latest stable versions (ex.: 11.1). item4848			y	show.tiki.org has up to version 18 while show2.tiki.org has all other latest versions	-
Make 26.x work on show2.tiki.org. item8544	-	y	-	this will be fixed on show3.tiki.org. item8491	-
show.tiki.org "Change password enforced" should not happen when I click "Reset password to 12345". item4859			y	the bug relates to Tiki 14x which is unsupported for a while	-
Show.t.o requires php 7.1+ (was: Tracker Field Location no longer fetching coordinates from tracker field address). item6907			y	there is no show.t.o instance making it hard to reproduce the issue. Additionally, the issue might is based on older Tiki versions currently unsupported	-
Remove tiki file-tree from show2.t.o instance when item is closed. item7548	y	-	-	-	-
Bug Tracker / Wishlist broken - no Category saving and show instances fail on installing. item4829	-	-	y	the issue relates to an old Tiki version; 12x, currently unsupported	-
"SVN update" button doesn't work anymore on existing show instances. item6796	y	-	-	use "GIT update" instead	-
show.tiki.org upgrade any trunk checkout to latest HEAD item4645	y	-	-	-	-
show.tiki.org: clone and upgrade. item4788	y	-	-	relates to item4645	-
Show1 and Show2: Remove cache on text files like http://bsfez-11581-7922.show2.tikiwiki.org/info.txt. item8031	y	-	-	should be further tested on current show*.t.o instances	-
http://dev.tiki.org/tiki-tracker_rss.php?trackerId=5 has show related content. item5303	y	-	-	-	-
Show.tiki.org: spinner doesn't last long enough. item4825	y	-	-	-	-
Enable .htaccess or its nginx equivalent on show instances for SEFURLs demonstrations. item6128	y	-	-	-	-
Allow to create show.t.o AND show2.t.o for the same bug report. item7117	y	-	-	-	-
svn update on show2.t.o instance from dev.t.o does apparently nothing. item7799	-	-	y	Duplicate of item6796	-
Add show.tiki.org as a mirror domain to show.tikiwiki.org. item4648	y	-	-	-	-
show.tiki.org : should be a way to use activate .htaccess. item4864	y	-	-	-	-
Show2 instance server doesn't easily support Tiki26. item8491	-	y	-	will be fixed with the introduction of show3.t.o. Relates to item8544	-
show.tiki.org : SVN update should also do a db update and run Composer. item4909	y	-	-	relates to item6796	-