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