Category: Monitoring

{syntax type="tiki" editor="plain"}
I think it would be good to have the option to have Automatic quarantine of forum posts that contain an external link. There would be an alert informing users that posts containing an external link will display after being approved by a moderator.

This would effectively end the kind of (likely AI or other automatic) spamming for link placement that we've seen in the tiki.org forums, I think.

This could be generalized to enable site admins to quarantine posts containing other content as well, such as hate speech. Maybe the admin preference would include a checkbox for "external link" and a text field for other content.

About the implementation, on the edit-forum page (such as tiki-admin_forums.php?forumId=14&cookietab=2#content_admin_forums1-2) there is an "Approval type" admin pref with options "All posted", "Queue anonymous posts", and "Queue all posts". To me the wording is a little unclear but maybe "Queue posts with external links" could be added here.

(I think "Require approval for" would be clearer than "Queue" in the wording of the options.)

It might also be good to extend this to also apply to comments, or to be ready to, if spam starts showing up there.

We have: ((tw:Testing Tiki installations on major Shared Hosting companies))

Now, let's add monitoring on this.

Set-up monitoring for all our pre-dogfood servers for all the checks we have, but especially last successful re-index. If last successful re-index is more than x (ex.:3) days old, an email alert should be sent out.

Here is a real-world example of why having checks on all pre-dogfood servers would have made everything smoother. An unidentified commit in trunk is causing indexing to crash:
https://dev.tiki.org/item4609

If we had been warned by a pre-dogfood sever, we could have found the commit and fixed the problem a few days after it appearing.

Note that this type of crash can also happen with some data not yet supported by the indexer, and thus, it can happen at any time, not just on code changes. And with a broken index, a Tiki site can be in big trouble because it doesn't just skip over the problem, it just dies. We are fortunate to have tons of data on all the pre-dogfood servers.

Because of issue 4609, we are stuck with respect to testing Unified Search with MySQL in trunk. Once this is solved, maybe something else will be discovered, so we to know ASAP so it's stable enough for Tiki12. This is crucial as per ((Search Dilemma))

1) Document the state of testing going on tiki.org sites, collect historical information, and produce monthly report on pass/fail on various checks. (some of these checks might fail a lot of the time with no problem, but collecting the historical info is useful to tune the tests for future, notification can be disabled for most of these checks).

2) If possible, provide easy access to the monitoring dashboard for tiki.org sites.

^
Let's coordinate here: ((Monitoring revamp))
^

At tiki-check.php on several Tiki25 and Tiki26 I can see the following Error remarksbox.
Also visible on Tiki websites : https://dev.tiki.org/tiki-check.php

{img type="src" src="https://ibb.co/brc9Jzz" thumb="box"}
{img type="src" src="https://ibb.co/4sZnChP" thumb="box"}
{img type="src" src="https://ibb.co/DYgdcQK" thumb="box"}

https://ibb.co/brc9Jzz
https://ibb.co/4sZnChP
https://ibb.co/DYgdcQK

Monitoring tools giving a wrong assessment is bad.

---

~~#F00:Update 2024-02-12:~~ Seems it has been fixed for Tiki26 but not for Tiki25.

{img fileId="2148" thumb="box"}

Use case 1:
* Customer has his own hosting (ex: dedicated or shared hosting)
* There is not just Tiki on that hosting
* Tiki consultant doesn't really control the hosting. They may change config to suit another app or in an upgrade.
* Tiki consultant sets up everything just nice thanks to Tiki Check
* Several months go by, all is well. Tiki Consultant is a hero.
* Hosting company (or someone else working on another app on the same server) proceeds to an upgrade/change without telling anyone
* Several months go by, problems appear, there is dissatisfaction
* Customer considers this as within the warranty and expects the Consultant to fix without extra charge
* Tiki consultant feels: "hey, it worked when I left it"
* Tiki consultant doesn't remember / have data on the previous config so can't explain the cause of the issues.
* Customer thinks Tiki was perhaps not such a good idea, as it's not supporting data load and there are all kinds of quirks
* Customer gets told, "why didn't you use system XYZ instead?"

In an alternate reality, Tiki Consultant sets up a Nagios/Icinga/Shinken instance to track all Tiki sites he has been associated with. Data is logged quietly in the background.

When an issue is reported, he can look at historical data and see what changed and have a clue. As a bonus, he can indicate to the customer that hosting company made changes to the server without advising anyone. Tiki Consultant is a hero (and can bill that time), and hosting company is not. If Nagios/Icinga/Shinken could alert the Tiki Consultant of changes, it would permit Tiki Consultant to review changes and to evaluate if there are any risks of issues.

Use case 2: run on all *.tiki.org sites to help reliability.

Use case 3: run on pre-dogfood servers and if we notice something went awry (ex: requires more RAM), we have a clear indication of which day the commit came in.
We have 50+ beautiful checks in tiki-check.php Surely it can't be hard to make them accessible to an outside monitoring system?