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
- Virtual host creation
- Instance creation from tag
- clone tag instance to target directory (use subdirectory if provided by user)
- svn switch(checkout?) to specific revision if specified by user.
- Import tiki.sql
- Modify tiki.sql
- Create random password and let the user know?
- Turn on action log and turn on everything
- Admin email set to user's email
- 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
- Run setup.sh
- 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)
- Send email after instance creation (from show)
Snapshot creation
- 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.
- 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).
- 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).
- 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
- Make exact clone from existing (code + db);
- svn -rxxxx or switch
- doctools/sqlupgrade.sh
- run setup.sh for composer.
- Need to be able to detect error, same handling as for new instance, email admin and user.
- Perhaps the script can be tried twice before considered fail.
- We could also write in the email "please try again later tomorrow" or something like that
Instance destruction
- 30 days after tracker item is closed on dev, the instance is removed, triggered from dev.
- Delayed destruction of snapshots.
- Provide a way for admin of dev to trigger an immediate destruction and clearing of this.
- When users are deleted from tiki.org, the instance needs to be destroyed as well, this should happen through lib/setup/events.php.
- When tracker item is deleted, it should also remove the show instance similarly.
- Add a popup warning for an admin deleting a tracker item that a show instance will be deleted.
- 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
We solve, close, or ignore?
Subject | To be solved | To be ignored | To be closed | Comment | |
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 |