Hi.
I am an operator of a small wiki. The log of the wiki is not preserved currently.
The wiki is running on a container which is on a Hashicorp Nomad node. You can assume it as just a docker container.
For a monetary reason, I want to use a free plan of a logging stack cloud service, for example Grafana Loki or OpenObserve.
I set up the mediawiki used monolog so that logs flowed to stdout, and let Vector[1] agent on a machine collected it and sent to the OpenObserve cloud. I wanted logs are not stored in the storage, because I did not want logrotate.d.
But for some reason, storage became closely full, I've disabled the whole logging system. I've not inspected it.
Before re-enable the logging system or inspect it, I hope to know how people deploy the log system. If you have some experience, please reply to this or review my approach.
Regards.
1: https://vector.dev/
Hello,
For many years, some classes in MediaWiki implemented the IDBAccessObject
interface (which only provides several public constants) and then would
call them indirectly (e.g. self::READ_NORMAL). Since these constants were
public, other parts of MediaWiki started to call them through the
implementing class as well (e.g. calling User::READ_LATEST).
This is inconsistent with the access pattern of other constants in
MediaWiki. it's also confusing (e.g. it's unclear to a newcomer why
UserFactory is implementing IDBAccessObject) and it's prone to clashes
(e.g. BagOStuff class has a clashing constant).
Since it's not possible to trigger a deprecation warning in such cases, It
can't follow the usual stable interface policy path [1] and here is the
email to wikitech-l as required by the policy.
In three weeks we will remove indirect access to these constants by
removing IDBAccessObject from implementation. This will take effect from
1.42 release.
Classes that won't have those constants anymore are including but not
limited to:
* User
* WikiPage (and its subclasses)
* File (and its subclasses)
* Title
* ActorStore
* RevisionStore
* UserOptionsManager
* And more.
To find such cases in extensions you maintain, you can search for
"(?<!IDBAccessObject)::READ_" (regex) and check if the constant being used
is an indirect call to IDBAccessObject. Be careful that there might be some
false positives such as custom defined constants, constants referring to
BagOStuff ones and similar cases like that.
We have already removed all cases in core and extensions deployed to
Wikimedia production.
You can follow the work and see examples of how the migration is done in
extensions (for example gerrit:993112
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/993112>) in
T354194 <https://phabricator.wikimedia.org/T354194>.
[1] From the policy
<https://www.mediawiki.org/wiki/Stable_interface_policy#Hard_deprecation>:
"If it is not reasonably possible for the deprecated code to emit
deprecation warnings, hard deprecation can be applied by announcing the
removal on wikitech-l in a timely manner."
Thank you and sorry for the inconvenience,
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello everyone!
I need some advice... I am currently stuck on MediaWiki 1.39.2 and can't
upgrade to newer versions within this LTS release.
I am using PluggableAuth and SimpleSAMLphp to authenticate users to our
wikis. Starting with MW 1.39.3, these extensions were updated to newer
versions (7.0.0) that don't work any more, at least with PostgreSQL as
database (see https://phabricator.wikimedia.org/T348543). I am still
using MW 1.39.2 with versions 6.2 of PluggableAuth and 5.0.1 of
SimpleSAMLphp.
I would like to combine MW 1.39.6 with the older versions of the
extensions, but here
https://extdist.wmflabs.org/dist/extensions/
only the newer ones are available.
I have tried to use composer (with which I have zero knowledge and IMHO
the documentation is ... challenging), and I was able to install
MediaWiki itself and PluggableAuth via composer, but not SimpleSAMLphp.
This extensions seems to be completely unknown to composer.
Switching from PostgreSQL to MySQL is a last resort. The migration does
not seem to be straight forward at all, and it is even unclear if it
would solve my problem in the first place.
Any ideas how to move forward are welcome!
Maybe what I really would like to ask for is: Don't make major updates
to (essential) extensions within an LTS release of MediaWiki, please
coordinate them with major updates of MediaWiki core.
Cheers,
Joern
--
Jörn Clausen
https://www.uni-bielefeld.de/bits