[06:42:15] im using the file cache at the moment. changes to UI elements such as the side bar do not invalidate the cache of articles/pages, which will contain these elements. is there a favorite solution besides manually deleting everything in the cache, or fudging some variable in the LocalSettings.php and redeploying the wiki? [07:01:38] cornduck : you can just `touch LocalSettings.php`, see https://www.mediawiki.org/wiki/Manual:$wgCacheEpoch [07:03:13] legoktm[m]: that's neat but it's about the same [07:03:37] i guess it is better [07:04:16] There's no automatic way to invalidate the cache if the sidebar changes AFAIK [07:06:37] thanks legoktm[m] [12:16:25] y0 and thanks for the awesome MediaWiki. 2 months ago I ran into troubles on 2 servers where the only thing I did change was tried to enable the VisualEditor and at first it seemed to work fine, but then started running into 404 errors (without a thing being changed by me between when it worked and when it started to run into the 404s). After trying a few restores from old /var/www/site and the mysqldump the wiki was always broken so that if I [12:16:27] make an edit it is fine, but on the next edit the wikis had run into an inconsistent state [12:17:18] For full disclosure: I think the mysql username and password may have been in the knowledge of some foreign party _and_ lack of careful firewalling the servers [12:19:07] I have the old VPS powered down and I'd like to destroy and recycle them, but I thought I'd ask for opinions here if I / we should pursue diagnosing what went wrong, of if we're happy that the production isn't broken any more [12:20:04] For full disclosure: Foreign party may have been in the possession of write rights to files owned by www-data [12:21:12] that's about it, thanks for hearing me out [12:29:53] Iamthehuman1: If you think someone is changing files underneath you, then reinstalling is probably your best bet. What did you have installed besides MediaWiki? [12:36:15] hexmode: Wordpress [12:37:15] I solved the situation by spinning up new production servers from a 4 days old snapshot. Now the old ones are in the broken state and powered down [12:39:48] If I can say what the brokenness appears to me: it would appear to me that the first edit I did with the (now disabled) VisualEditor pop into existence in the wrong place in the database, even after clean mysql import of the old backupped database [12:40:39] Would there be some other place than the MySQL/MariaDB where revisions are stored if using VisualEditor? If no, I'm going to delete the servers, if yes, then that was prlly exploited [12:41:26] I really doubt it is VE that is the problem. Some WP plugin seems more likely. [12:41:59] I'm not sure what you mean by "pop into existence in the wrong place in the database" [12:42:53] revisions are stored in the database [12:42:54] yeah, I know some attackers got into a Wordpress on one of the servers exhibiting this wiki problem, but I do not think they may have gained access on the other server, coz the wordpressen have very random and long passwords [12:43:57] They don't necessarily need passwords. a plugin could have a bug in it that lets them in. [12:44:34] hexmode: a client was using very bad passwords, Jetpack confirmed that the Wordpress-account was hacked [12:45:09] they even pointed out a malicious plugin was inserted, but I don't know how malicious nor how to find out [12:45:19] But you said the problem was on the long-password site, right? [12:45:30] it was on both servers [12:46:16] at first the VisualEditor appeared to work and then sometime later, just 404, 404, 404 [12:46:21] my point is that they don't need passwords to corrupt the server [12:46:39] and 404s in VE sounds like they had access to the server [12:51:05] My theory is that they used the malicious plugin they had installed to gain write access to files owned by www-data... if this be this dangerous then why I didn't find any good hits when searching for how to run each site as separate users in PHP-FPM [12:52:26] maybe I should into that containers-stuff.. VPS was hot shit .. in the 00's [12:52:58] because that isn't something most people want to do? I use php-fpm to run different MW installs on different PHP versions. [12:53:46] Isn't the Wordpress paradigm of code with ability to modify itself inherently dangerous? [12:54:39] running the sites under different users using php-fpm would mitigate the problem in a similar way to containers, but, yes, using containers is probabaly more easily google-able [12:55:23] yes, self-modifying code is opening yourself up to problems. [13:01:25] Perhaps I should just buy hosting service for the Wordpressen from some provider that uses elecricity from renewable sources and just accept it is more expensive than DIY [13:02:30] more automation by others, more price tag, but at least shit like this wouldn't happen this badly [13:05:04] I appreciate your insight hexmode, thank you [13:05:46] np [13:13:46] I dunno how the browsers SSL/TLS stuff handles having two different certs in two different places for domain.tld, coz its gonna run to that if I host the wikis myself and the Wordpres elsewhere [13:14:40] I mean I dunno if the "more than one cert for one single domain" is allowed or is just too risky to allow from the security perspective [13:15:51] you could load both places with the same cert [13:16:52] I have a DIY system for installing and renewing when needed with two cronjobs and the hosting people are going to have their own automatic system to get a LetsEncrypt or similar [13:17:53] often they'll let you provide your own, though [13:18:08] one cronjob renews the certs when needed, another restarts apache2/nginx 15 minutes after that [13:19:40] but I bet they will not provide proper level of automation for the people using "external" certs, so looks like another case of "choose your suppliers wisely" [13:23:11] oh hold on.. a thought is appearing.. you have scp or sftp access to the hosted instances, I can push prlly push the certs with a script ... that is if the solution given allows this [18:41:07] Guest22: move your LocalSettings.php out of the way until you have MW set up [18:45:49] Thanks for your reply hexmode. I assume there's no way around that then, like forcing MW to ignore it? [18:46:21] its all scriptable, so what does it matter? [18:47:53] You mean docker or MW or both? [18:48:22] both... have you looked at the official docker builds? [18:48:48] Do you mean this: https://hub.docker.com/_/mediawiki ? [18:49:09] yes, but also the developer ones [18:49:35] look at addshore's work for an example [18:52:09] Thanks, I'll check that out [18:54:07] I was trying to keep my docker-compose file constant, but you also gave me an idea of how I may do what I'm looking to do, which involves only using docker compose to launch the wiki when it's already configured, and before that just use standard docker with the command line options I need