Backlinks

Structures

2018-11-25: The "Tiki Remote Instance Manager (TRIM)" will go into maintenance mode, and the code will be forked and revamped to become its replacement, now known as the "Tiki Manager".

The info below is kept for posterity.

For the foreseeable future, we'll continue working on TRIM. We did take a good look at the alternatives. Of course, they have some nice things, but they are also missing things TRIM does well. TRIM's lack of Windows support was a problem but exploring different scenarios. Ex.: TRIM on Cygwin. And Cygwin offers many other benefits as developers who are familiar with GNU/Linux can more easily work on a Windows Server.

Be future-proof to a change in Tiki's Source Control Management. Nothing is planned but one or more of the following could happen:

SourceForge could shut down (Like CodePlex, Google Code, etc.)

SourceForge could change the URLs like they did in 2012

Tiki could decide to self-host with Allura, Gitlab, Phabricator, improve and use the Version Control Bridge or something else

Tiki could decide to move to Git, Mercurial or Fossil.

Web GUI

It is understood that there will be some operations that take longer, and that some processes will need to happen or be restarted in the background. We can use some of the strategies of Tiki Scheduler

Proposed Bootstrap mockup GUI (by Benoit)

Screenshot:

Nice! Just a little thing: I think the "List Backups" option is missing in the Backups section of the menu. Also should there be "Install/Update/Uninstall Theme" option somewhere?
luciash d' being
10 Apr 17 12:52 GMT-0000

I dont think TRIM can manage themes right now. As for the menu, I just listed all possible TRIM commands as of now. A lot of things will change and List Backups will probably be there eventually.Benoit Roy 10 Apr 17 20:54 GMT-0000

Salt Stack is a strong candidate for this (A proof of concept was successful). So perhaps Salt Stack provisions the VM, installs and configures ClearOS and the domain name and launches TRIM to set up Tiki.

To be able to run automated testing on TRIM instances via Browser Automation or an external tool

New commands (not sure where to put this, you can move it somewhere else)Benoit Roy 10 Apr 17 21:09 GMT-0000

Blank instance, something like 'make blank' just to be easier/faster to make blank instances instead of 'make instance' and choosing blank instance. They are used for backup/restore/clone.

REST API

It would be nice to have common Trim commands available as REST API endpoints. Let's suppose we wire Github, Sourceforge or even inotify to Trim. Whenever use change something in their source code, Trim could be informed via REST and take the proper actions, like cd project && svn up .

Hooks

We could wire two Trim instances. Imagine we have 2 environments (Prod/Dev). In production I can configure Trim whenever a DB backup happens, tell it to other Trim in development environment, so that Dev Trim can download and load a fresh database.

Nice to have

FTP support: Normally, TRIM is used to managed many Tikis. You really want SSH and SVN for this. Without shell access, it's going to be a management nightmare anyway. But TRIM is useful if you have even a few Tikis. Perhaps a compromise would be for TRIM to be able to work locally on Windows. If everything is in PHP and the server has SVN for Windows, it should work OK. Could be used for backup, restore and clone. And folks can use Syncthing to get backups safely to another server.

It definitely needs to be more verbose: I think the biggest need for the command line version of the server is to make it more verbose. Some commands doesn't output anything so we don't know if it was a success or not . Same thing if there are errors except when its an error generated by PHP or the OS. Commands where i wrote 'all good' means that it 'seems' to work correctly to my best of my sysadmin knowledge :O)Benoit Roy 10 Apr 17 20:54 GMT-0000

That also can enable the console app to show what commands are available based on the dependencies of the system

Replace usage of 'command line utilities' inline with the code with either PHP equivalents, or create PHP classes with a interface that allow TRIM to abstract form implementation and maybe in the future replace with a PHP based implementation, example: rjsmelo 14 Apr 17 06:45 GMT-0000

df + awk with a directory iterator to get a directory size recursively

zcat with any option PHP or gzip in the command line that allow you to uncompress the file

rm --force with recursive unlink

Replace usage of ssh-copy-id with just a ssh / scp wrapper

Pack TRIM as a Phar - that would allow to easily download trim and "start a project" using the current folder. rjsmelo 14 Apr 17 06:45 GMT-0000

Data import from existing TRIM: This should not be hard (data is in a simple sqlite db) but if it's a problem, we can live with it. We need to think of next 10 years, and as long as TRIM Revamp (Whatever the name ends up being) is able to "adopt" an existing site, we are good. It's a 1-time transition.

TRIM was enhanced to also be able to deploy WordPress. While Tiki is the main goal, if the successor to TRIM can easily handle other PHP apps, it could be considered as the tool/base for installing PHP apps on ClearOS.

Appears it is only available for Zend Framework 2.x so far? Or just the docs?
luciash d' being
10 Apr 17 12:52 GMT-0000

Would it support MultiTiki installs?
luciash d' being
10 Apr 17 12:52 GMT-0000

Good question. TRIM and MultiTiki are somewhat alternatives to each other. With some extra work, we could make it work. make backup would be useful, but not so much make update. Can you elaborate on use case? Marc Laporte 03 Jul 17 03:36 GMT-0000

Other

Some related Tiki work

setup.sh revamp

Move some (all?) of setup.sh to php

Relationships between various Tiki instances

In item5937 and item5930 it seems we need a new concept in TRIM to have relationships between the instances. "mirror of", "upgrade of", etc. Not sure how this should all be done. Maybe some sort of new list of 'operations' done between instance X and Y. Maybe each Tiki should "know" (ex. in db/local.php) what it is (prod / dev) and what other Tikis are related? We also want this related concept for the Federation.

System Configuration ( tiki.ini file) is our friend to hard-code settings that make sense to the use case.
ex: dev and staging sites don't send out notification emails
So we need a standard way of setting this file where it's not overwritten in an operation.

c) Opportunity for the future (but not applicable to 12.x and older) -> Theme-related stuff (tpl, css, js, fonts, etc) can now all live in a common root directory:
https://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/themes/fivealive/So this could be automatically synced (rsync, Syncthing, TRIM, etc) or versioned with a different system than the Tiki (Git or Fossil). Use case: I have a production server that I can't give someone SSH access to (VPN or legal issues). But a theme integrator improves CSS on a dev server. I need to copy stuff over periodically. Syncthing could keep things in sync while keeping version history. This could be nice for tpl and css files that can both be edited via the GUI by the end users or by us as a file edit. lang/fr/custom.php is another example.

d) Recent work on Composer could also be useful. Ex.: To use Composer to deploy custom themes as Packages.

Attached files

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.