Category: TRIM

It worked before but...
Using TRIM with make commands does not work anymore here:

{CODE()}
[root@vm5163 trim]# make instance
PHP Parse error: syntax error, unexpected '.', expecting ',' or ';' in /var/local/trim/src/libs/audit/Checksum.php on line 64

Parse error: syntax error, unexpected '.', expecting ',' or ';' in /var/local/trim/src/libs/audit/Checksum.php on line 64
make: *** [instance] Error 255
[root@vm5163 trim]# php -v
PHP 5.5.38 (cli) (built: Jul 21 2016 12:51:12)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies
{CODE}

__Use case 1- mirror a site__
Be able to provide on same server (different URL) or different server a fresh identical copy of Tiki with all data, including files that are not in DB.

a) Could be to offer a backup site on a different server in case main server is down. This backup site could be in the customer's office, so avoid any cloud lock-in: "You have a fully working instance with all data (less than x hours old) and all the FLOSS code on a computer you physically control" And this sticker can go on the box :-)
https://www.stickermule.com/marketplace/3442-there-is-no-cloud

b) Could be part of a dev/staging/prod routine. Ex. push data from prod to staging and/or dev to 'reset' and now we start developing again.
http://12factor.net/dev-prod-parity

c) Could conceivably be used to have several copies of a site and load balance via DNS but there would likely be better ways to achieve this... (ex. MariaDB Galera Cluster)

d) demos (OpenSourceCMS type demo to test/develop and show off profiles)

Perhaps:
make clone : a one-time copy
make mirror: setup automated recurring copy

This script should have access to ((doc:system configuration)) and to run a ((doc:profile)). An example is $site_closed eq 'y' and $site_closed_msg="This is a copy of XYZ..."

__ Use case 2- pre-dogfood (test upgrade)__
Like:
* https://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/doc/devtools/update.dogfoodserver.sh
* https://tiki.org/Pre-Dogfood+Server

That script works but it's a manual configuration every time. TRIM can backup, deploy and upgrade so why not combine? :-)

a) Check at any time how an upgrade would impact.
Could be to the tip of same branch or to the tip of a future branch or trunk.

b) Could be part of a dev/staging/prod routine

And adding a conflict alert with this would be really nifty:
https://dev.tiki.org/Check+if+the+update+would+cause+conflicts

Especially combined to the automated updates:
https://doc.tiki.org/TRIM#To_setup_automated_updates

Perhaps:
make cloneandupdate (test minor update)
make cloneandupgrade (test minor upgrade)

This script should have access to ((doc:system configuration)) and to run a ((doc:profile)). An example is $site_closed eq 'y' and $site_closed_msg="This is a copy of XYZ..."

PECL's ssh2 extension is poorly maintained, hard to install and unreliable even when it has been successfully installed. Testament to just how difficult to install are all the comments located on the third website that comes up when you do a search for "php ssh" on Google (without the double quotes):

http://kevin.vanzonneveld.net/techblog/article/make_ssh_connections_with_php/

Testament to it's unreliability even after it has been successfully installed is this:


http://www.frostjedi.com/phpbb/viewtopic.php?f=46&t=13223

In light of this, I think TRIM ought to use phpseclib (http://phpseclib.sourceforge.net/). It would save everyone a lot of heartache, from the end users, who wouldn't need to ask for support, to the developers, who wouldn't have to spend as much time providing support for the deficiencies in PECL's ssh2 extension.

TRIM: allow editing instance information. BEfore that, allow a way to view the contents of an instance, since we may have duplicates, or several accesses to the same server, or a site migrated to a new server, etc. and it's difficult to know what to delete (if any), or edit, if possible, to keep the backups consistant and everything tidy.

Doing this manually is error-prone and time consuming.

make compare should compare two sites and report at least:

* Differences in PHP version
** Seeing a diff of tiki-check.php output would be fantastic as well to see anything risky if the two Tikis are on different servers.
* Differences in the data
** in database (presumably text diff of mysqldump)
** files on disk outside web area)
* Differences in the code base

So one could iteratively manually cherry-pick merge stuff from dev/staging to production, and re-run diff until there is nothing else one cares to keep. And then, use the "copy prod to dev" script.

This is useful for ((Configuration Management for Tiki Projects))

See also: ((Divergent Preferences in Staging Development Production))

-+make instance+- command on CentOS fails with the follwoing fatal error:
{CODE()}
...
Working directory [/tmp/trim_temp] :
Backup owner [root] : luci
Backup group [root] : luci
Backup file permissions [750] :
PHP Fatal error: Exceptions must be valid objects derived from the Exception base class in /var/local/trim/src/libs/trim/Discovery.php on line 172

Fatal error: Exceptions must be valid objects derived from the Exception base class in /var/local/trim/src/libs/trim/Discovery.php on line 172
make: *** [instance] Error 255
{CODE}

On the svn updating step when -+make update+- is ran there is an error reported:
{CODE()}
...
Updating svn...
svn --non-interactive merge --accept theirs-full --allow-mixed-revisions --dry-run --revision BASE:HEAD '/var/www/demo.luciash.eu/web/trimtesttiki18' 2>&1 [1]
svn: invalid option: --allow-mixed-revisions
Type 'svn help' for usage.
...
{CODE}

But it seems the script continues without fatal error then...

-+svn help+- reports -+Subversion command-line client, version 1.6.11.+-