Oh, the HSTS had broken since it was enabled in fr.dicoado.org but not in dicoado.org. I've reenabled it again but it's like the other things, it needs being properly set up.

Sorry for your loss Valerio. I'm sure your rabbit has loved the time it lived with you <3

Please note that the screenshoot is outdated :-)
Technically, this isn't even needed. The DNS zone can still be hosted in infomaniak.

In T345415#9167203, @ValerioBoz-WMCH wrote:

The .htaccess is quite short now. Can you please double-check?

It seems lot of things are unnecessary now, since we have separated virtualhosts with separated redirects. But maybe I'm wrong (?)

You can drop GTAG and googleAnalytics.

I can try but this shouldn't do anything I think, since MediaWiki calls
the binary "on the spot" and does not require reloading the server AFAIK.

Installed librsvg-bin, set it up properly, and it works like a charm. Thanks!

Thanks for that certificate, indeed certbot is amazing.

Can confirm 😄

So I saw you've done it, thanks. It works but the quality is unfortunately poor. MediaWiki seems to recomomend using librsvg, which we can install if there is no concern bout it.

Yes we were using rsvg and not imagemagick. Will change it when I can.

Other remarks I would like to make :-)

• The server is a bit of a mess for the moment :/ There are different occurences of a MediaWiki installations, configuration files are stored in really heterogenous places, and there are some test files that lies around. This makes maintenance difficult, and we could gain from cleaning a little^^
• I've moved the debug configurations you added in LocalSettings.php to their proper place (sooner in the file). This has made me go crazy for a moment because I was setting wgDebugLogFile where I was used to do so without realizing I was being overriden by the config at the end of the file :'-). I've put the configurations behind a barrier to avoid leaks and also disabled default logging: this is far too verbose, only a few days of being on and the output file was 1.7 GB. Also, it stores a lot of private informations. This option is better enabled only when trouble shooting a specific bug in my opinion, I therefore disabled it and removed the fat debug file.
• I think we could gain in simplicity by using wildcard for certificates but also for virtualhosts and domain (have a configuration for *dicoado.org instead of fr and www.fr). However I understand that it is harder to put in place!
• We could take more advantage of having now our own server (with root access). For example you've made a TODO for moving .htaccess configuration into the real apache configuration. We can also strengthen the filesystem permission settings in order to reduce attack surface (I've done this for the private folder but this can be done everywhere). Still about reducing attack surface, the apache config could be simplified and the enabled options reduced. This is something I can also help to do.

Thanks for the work so far Valerian!
However, for this one, emphasis mine:

I've issued let's encrypt certificates for dicoado.org and www.dicoado.org (probably still missing fr.dicoado.org - we are still using the original ones that I imported previously)

It would have been better to renew all the certificates (perhaps using wildcard?) :D.

Yes this is in fact on us, we must make the MX record point to your server.

Yes, that's how I managed to make the maintenance script run: using MW_DB
as intended, putting the database name we work on in it through the --wiki
argument. The script checks it and parses it.

either putting the wiki offline

As for now I've done this, I've removed the read permission to everyone so that the general public and crawlers don't get the nasty spammy links.

Also, it may need to - somehow - receive the current domain, in order to guess the current database name.

The issue comes from here. The "Unexpected request" comes from the LocalSettings.php, which fails to exploit MW_DB in order to get some constants (WIKIMINI_PROJECT_UID and WIKIMINI_DOMAIN if I recall correctly) right, and thus reports an error. I've started to adapt the script but I don't see how transmit the domain (and also, the domain should not change the database, or is it?). I can run my maintenance script for now but we need to rewrite the LocalSettings file.

This task has been closed but with no explanation, and no proof that the bug was removed. The last comment explains that it succeeds when the extension is disabled...
This bug is almost certainly linked to T284416. It is still happening in 1.35 when the mentionned setting is enabled.

The documentation does not explain that the setting broke things. Also, the change hasn't be backported in 1.35.
It is probably the reason for T50700 (which was closed while the bug was still being reproduced by seomeone and with no explanation). In the 1.35 version (still supported), the setting is still available and breaks the system upon PDF upload, so people like me that enabled the setting and have no clue why it does not work cannot easily guess it is this setting that breaks.

Usually wikis use both probably because Titleblacklists permits an
easier management in the sense of forbidden title and is probably much
efficient (it does not add a full language, it's a simpler parser, and
it warns the user before even attempting the edits).

did you put some .htaccess or rule in httpd.conf to forbid any access to
it ?

LiquidThread is currently unmaintained and has some awful bugs. Didn't
find any security issue yet but don't know what the bugs are about so it
might be linked. However I do not know what will happen to the current
threads when the extension is removed. If it's like StructuredDiscussion
then we're screwed.

secure-include, as I said, is disabled (as was already AWC's forum
extension since around June 2022), by this I mean that LocalSettings do
not call it anymore.

Disabled the extension, now need to fix image of the day system.

Uuuh, private issue higher than us

As I see in the code it seems that noesc feature is enabled which is not
a good news :/

…which probably explain why the site is currently down :D

Probably the best way will be to jump to the latest 1.35 (until 1.35.5
included there is the security bug if I remember well), then 1.39. If
really needed, then we might also make a step to 1.31.

Yes you're right, this troll in particular will be resolved later. It's
however still active here and moreover the extension does not inspire me
trust at all^^

For info I was able to access another project (Le Dico des Ados) too.
So, it's really our server who decided that the revolution was starting :-)

the parsoid url that was used by VEForAll and that showed up in the log was, if I recall correctly, something like https://wmch.fr.dicoado.org/wiki/rest.php/wmch.fr.dicoado.org/v3/transform/wikitext/to/html/uppercut

Good news: "$ is not defined" is now fixed
In fact, the problem already occured on legacy dicoado and was fixed, I just transferred the fix.
The wmch version is on an old version of the "legacy" dicoado. For example wmch.fr.dicoado.org is on MW 1.35.2 while fr.dicoado.org is on 1.35.5. Also we updated a few things in our config on legacy, so we will need to also import thoses changes in the wmch server.

Just to precise that I fixed and tested your scripts and they work perfectly :-)

Hi, don't know why exactly your script didn't work (perhaps issue with quoting, or password wrongly typed, or idk), but I've put a .my.cnf file with the credentials and now invoking mysql directly works (no need to write the credentials in the arguments).

$ is not defined is provoked by a little script added by the company Dokit when they made some change to the Foreground skin. It attempts to call masonry (a library for organizing elements AFAIK) but fails, I don't know if it is the reason why VE4all does not load.

Can confirm it now works. However, the transcoding must be manually reinitialized on failed files.

Since the changes were merged into the master branch, may Wikimedia Commons profit from it now, or does it have to wait until the commit comes with a new release?

Perhaps it would be easier to export the good pages, throw away the whole wiki, and reimport the pages in a clean one.

There are https://es.wikimini.org/wiki/Especial:Estad%C3%ADsticas 739 227 "Content pages" (ARTICLES) on es while fr has 198 904 PAGES (all included). The 27 GB is simply spam, if you make the calculation it makes 38kio per page so it does make sense. Perhaps DeletePagesForGood could be useful. This extension is archived but in all cases we're on an old version of MediaWiki soooo… perhaps we could simply take the code in order to run it on all the pages. It will take long.

Awesome! Now needs to remove GA completely.
DSwissK perhaps has some question about some difference between stats of Matomo and stats of GA, feel free to ask @DSwissK.

What is the current state of it all @valerio.bozzolan?

By the way, I did not take note of the password to access Dicoado's Matomo… Could you reset it for me please? :3 I have 2FA, I can give you an access code if needed.

Thank you for the follow-up!

RIP! No problem we'll continue tomorrow. Thanks for your time!

The title seems strange, should it rather be “Should not require an NDA privilege to see in Phabricator the “Other assignee” field”?

This has been used and recommended during all these years, and apparently it was never an issue. So why having this deprecated? And what is the plan proposed by aaron?

Well, as my "Hello World" edit, I've fixed it^^ Sysops can now edit NS_CATEGORY

Perfect. @DSwissK, you'll need to create an OAuth access on Google Analytics using the link mentionned above :-)
We can do this together if you want!

It worked, I could update my password, so I think it is resolved @valerio.bozzolan?

No, we need to be superuser on Matomo apparently, we need to see system's parameters :/ . And @DSwissK will need to follow the tutorial in order to create an OAuth application in Google Analytics :-)

Still not working for me, when trying to use the "forgot password" feature. SMTP Error, bad data. Potential reason : your host can have disabled the mail() function.
We will probably have to create a SMTP server on dicoado in the future.

This look like it can only be done using Matomo's side. We don't "export data from Google" and then give them to Matomo, Matomo fetches it itself. The first step is to install the relevant plugin.

Sorry for the little delay. The domains now point to the given IP, tried it.

Done !

Why not include it in the existing page pointed by Mediawiki:Privacypage ?

You can now use your key to connect to nxxs_wmch@nxxs.ftp.infomaniak.com :-)

the matomo extension is easier to configure I guess (for non cookie usage or things like this)

Hello, why aren't we using the Matomo extension directly ?