[00:57:59] [1/2] ohh I think I finally figured out how to complete my ImportDump automation work! Actually, doing some DPL3 work on phpunit tests gave me the idea to complete it... [00:57:59] [2/2] @reception123 [00:59:25] I can probably complete it this weekend or next week [01:11:56] :CatGasp: [01:12:13] a:cutecatgirldance: [06:09:53] Wow, that sounds great! [06:12:16] The only concern I have is how well the jobrunner will handle imports, but it does handle dump backups so I think it will be fine. I'll probably add a limit config for how many can simultaneously be started or something though maybe. [11:24:45] @bluemoon0332 I can talk for England about CA [11:29:02] I said this yesterday to CA over DM [11:29:13] but I believe we should fork CentralAuth [11:30:53] The problems with global accounts being attached to lots of wikis is unique to Miraheze, and Wikimedia has in no uncertain terms said that CA is meant for use there, and nowhere else, that changes to the codebase are made according to WMF needs, and that external users can expect no support at all [11:32:01] I still support moving away from CentralAuth completely over forking, but we do use some CA unique features like global permissions that no other SSO extension in MW supports [11:51:49] tsbanned representative supports [11:58:35] [1/3] I personally find the CA a great feature. That WMF made it for them, doesn't necessarily mean we can't use it. [11:58:36] [2/3] The ability to login, and stay logged in even when you view different wiki's, is a help for many wiki's who do not want anonymous users editing from IP's. [11:58:36] [3/3] The global support is this way also easier for privat wiki's, who have an issue with a user, They can just refere to [m:user:vandal] and you guys can check the guy out from Meta. [11:58:45] I think also limiting how many revisions to import per job would also be useful. The script supports that [11:58:52] (I know you can login anyways, but yeah) [12:01:45] This is what I mean by forking: https://en.wikipedia.org/wiki/Fork_(software) [12:01:56] It's not like we're doing away with CentralAuth [12:02:25] the problem is that CentralAuth is made specifically for Wikimedia. It doesn't like farms like Miraheze with over 8000 wikis [12:02:49] though one day! hopefully.... [12:05:21] Okay. I just find it strange that Wikimedia Foundation is so unhappy about this. I mean, it's [[GNU General Public License]] [12:05:22]

[12:05:34] ...software [12:08:17] It's CentralAuth the one who doesn't like farms with lots of wikis, not Wikimedia [12:08:41] By doesn't like I meant it doesn't work at that well, obv software doesn't have feelings [12:08:43] ah my bad [12:12:25] [1/2] [[mw:Extension:CentralAuth]] states that warning indeed. [12:12:25] [2/2] But if one can create a similar code for our own farm, then I'm all for it. But you need soeone that knows the code in and out [12:12:26]

[12:14:13] Oh 100% [12:14:23] If we can safely fork and replace CA, good [12:14:27] Safely is the big question [12:14:43] It's a mammoth, complex pile of shitty unsupported software that's essential to the farm [12:17:49] It should be replaced with an silent OAuth like system [12:18:10] But redirect if 2FA etc [12:18:29] And then make a non shitty version of the special page [12:19:04] I'm not sure global edit count & displaying local edit count is that great and that's what wastes performance [12:19:35] Ask if Magnus Manke is interested to get involved 😄 I remember him from the BB-Forums time in the Early 2000's. [12:20:27] Shouldn,t that be able to be taken out all together? [12:21:10] Not without forking CA [12:21:19] yeah okay [12:23:10] One doesn't just make a new one overnight either. They've had years to patch up and understand what happens when you add/remove things of course. [12:40:10] WMF haven't really invested in CA [12:41:42] That's stupid 😮 [12:45:27] They seem to avoid maintaining the crucial parts of their infra [12:49:43] [1/5] One thing I do understand. [12:49:43] [2/5] -MediaWiki is basically the same for everyone. [12:49:43] [3/5] -But each language Wikipedia, Wikibooks, Commons, WikiVoyage has different needs, and they get heavily modified. [12:49:44] [4/5] I think they spend a lot of time patching up where problems arise. [12:49:44] [5/5] I remember when NLWP introduced the Zeusmodus.js which became heavily used. There was a lot of pro and cons, and a lot of time wasted in trying to incorperate it in MediaWiki. [12:50:31] And everytime MediaWiki get's updated, gadgets like these start to fail. [13:01:59] [1/2] I think the general consesus surrounding CA is "it works, leave it alone", which is generally the safest option. [13:01:59] [2/2] CentralAuth is definitely something it would be good to move away from. Especially given WMFs attitude surrounding support for other wikis using CA. [13:04:07] No, The WMF just lack useful technical direction [13:04:12] Something like kratos/ory-hydra would be nice, but we obviously can't afford that. [13:04:34] It's an insanely poorly managed org from a strategic perspective [13:05:05] If it ain’t broke don’t fix it [17:13:25] to be fair it likely isn't broken for them [17:13:51] other than SUL2 slowly dissappearing. WebAuthn not really working [17:14:57] we do have extra problems that they wouldn't face because of CentralAuth being made for Wikimedia, not MIraheze [17:17:27] to start with, user logins should have already been redirected to loginwiki. https://phabricator.wikimedia.org/T348388 [17:17:39] that would immediately unbreak WebAuthn [17:17:42] for starters [17:17:59] We may have to fork CA eventually, but for now I don't think ir is absolutely necessary, I actually like that logins redirect to loginwiki on 1.42 (which I notice even for us on 1.42) [17:19:20] My job won't use importDump directly but ImportStreamSource::newFromFile directly, as it's better, implementing Swift download will be a bit tricky, maybe some sort of config or hook so not MH specific. [17:21:06] when was that done?! [17:21:21] I don't see any patches on the SUL3-related tasks [17:22:03] I'm not sure, I couldn't find it in CA either but the reason had something to do with third party cookies IIRC [17:22:53] How so? [17:23:50] I can't remember I just remembered seeing something about it on third party cookies tasks [17:24:58] I mean, that's mentioned on T348388 as the "minimal effort" solution to logins [17:25:09] But I don't think that has actually been implemented [17:30:08] It does happen when I was testing 1.42 so not sure when it was done then... [17:30:31] so, when we upgrading 😎 [17:30:37] my dreams come true [17:31:07] finally I'll be able to login at wikis with a custom domain [17:32:33] probably late June [17:32:38] MW.org says May but they're always very off [17:34:40] on our upgrade task we should also mention that WebAuthn users will need to disable WebAuthn prior to the 1.42 upgrade [17:34:53] otherwise they'll get locked out [17:35:15] Why [17:35:19] Oh [17:35:31] That's a stupid idea WMF [17:35:37] Why would you do that [17:35:38] Why [17:35:59] @bluemoon0332 if we can tell in the task, we can probably do it on upgrade by force [17:36:17] But ye that's a horrible idea WMF [17:36:43] @bluemoon0332 maybe we should disable web auth n off loginwiki [17:36:44] probably [17:36:57] why? [17:37:31] So people can't get themselves on something that'll break in a few months [17:37:53] _goes to scream into the void_ [17:39:24] to be honest that change hasn't yet been made at WMF [17:39:26] https://phabricator.wikimedia.org/T354701 [17:39:47] they are still thinking on how to approach logins being moved to loginwiki and WebAuthn [17:42:21] Oh good [18:20:42] [1/2] Article in root now possible!? [18:20:42] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1208478142432550944/E.png?ex=65e36df9&is=65d0f8f9&hm=3c6252234653fb65169fd9b4c7769d8c8f60f62f735d6c475450febc0ffd0848& [18:20:55] it might in the future [18:21:01] It's been on WikiForge for ages [18:21:09] guess WF is losing its exclusive features \:P [18:21:15] lol [18:21:28] Will WebAuthn break though? [18:21:35] Also available to existing wikis too? [18:21:38] yes very much [18:21:43] On Miraheze, we have it set so that it works on all miraheze.org domains [18:21:53] so you can login via WebAuthn on any *.miraheze.org wiki [18:22:03] ohh, I forgor 💀 [18:22:11] then maybe we'll be fine [18:23:14] it will break if anyone however ignores the warning in the 2FA special page and registers the authenticator outside of Meta, like in a custom domain [18:23:40] since logins will be redirected to loginwiki [18:26:02] you'll have to request that a Steward changes it, since it will be a new setting in Special:ManageWiki/core iirc [18:26:08] but yes [18:27:21] Turning into a guinea pig [18:28:36] still waiting for my translations to be fetched- [18:29:04] if you mean the RequestSSL ones that'll first have to wait for translatewiki to push to GitHub [18:33:17] :devilish: [18:37:16] a:pepelmfa: [18:37:47] ik, but I mean I just almost fully translated everything that Miraheze offered- [18:38:13] :Hellnnah: [18:39:38] We'll try to deploy the new translations once translatewiki pushes [18:43:02] Ic [18:43:43] From your experiences, how long does it takes to do a push onces? [18:45:08] users will be able to change it themselves actually [18:45:11] hmmm, back when I had access to mwtask servers I would do this when I was bored, looking at dependabot PRs that only had i18n changes [18:45:13] that's how it's done on WF at least [18:45:53] don't really know what the ones with prod access are doing, sorry [18:58:29] https://github.com/miraheze/mw-config/pull/5478 [18:58:43] seems it is limited only to managewiki-restricted in the draft [19:00:16] 1984 [19:00:24] my freedom is being tread on [19:13:29] So we just remove those lines does it? [19:34:07] @Site Reliability Engineers nginx is failing to restart to deploy cert updates . Can someone check why asap? [19:34:14] And don't restart nginx whatever you do [19:35:33] well no or else anyone can edit it [19:36:10] enabling $wgMainPageIsDomainRoot can cause some performance issues iirc [19:37:54] @agentisai whatever you're doing with SSL, it's risking taking the farm down [19:38:09] I suggest checking conftest [19:38:34] it's not that complex [19:38:39] it's a perennial issue [19:38:50] bad permissions [19:39:10] @agentisai what you mean by bad permissions? [19:39:25] > Failed to generate additional resources using 'eval_generate': Error 500 on SERVER: Server Error: Permission denied - /etc/puppetlabs/puppet/ssl-keys/agesofconflict.wiki.key [19:39:43] @agentisai puppet can't edit there? [19:40:48] it can't read there, no [19:40:54] Why [19:40:55] I'm unsure what permissions ssl-keys is supposed to have [19:40:59] It runs as root [19:41:23] Puppet shouldn't be generating an error condition though in nginx [19:41:27] That's a stupid idea [19:46:03] should be fixed [19:46:11] perms must always be 644 for ssl keys it seems [19:46:34] @agentisai we should make puppet enforce that [19:47:01] or at least have the ssl-certificate script manually set it to that for all keys [19:47:32] Strange, this hasn’t previously been an issue [19:48:12] @agentisai https://github.com/miraheze/puppet/blob/master/modules/ssl/manifests/cert.pp#L25 ? [19:48:31] Or https://github.com/miraheze/puppet/blob/master/modules/ssl/manifests/all_certs.pp [19:49:00] Perms can probably be set somewhere in that module [19:49:19] @agentisai [20:19:41] [1/4] I have a quick question. [20:19:41] [2/4] Why do we use ```!important;``` in CSS, when the MediaWiki software warns against the use of it? [20:19:41] [3/4] It annoys me with all those yellow warning icons in front of the lines. [20:19:42] [4/4] Could anyone explain why I should ignore it or can I remove it? [20:20:19] yep, will look later [20:22:44] Not necessarily performance but it can cause redirect loops withojt Varnish properly purged which is why it'll be restricted, at least initially while testing is conducted on impact. [20:23:17] performance issue was actually fixed with 1.41 [20:23:22] see the MW.org page for it [20:23:28] and the task mentioned [20:23:49] I know, there are no performance issues as I just said the reason it's restricted was because Varnish [20:23:50] [1/3] I believe that CSS editor is like third party thing [20:23:50] [2/3] not sure [20:23:51] [3/3] but I always ignored that [20:25:03] <.labster> Sometimes you need !important to override another rule in the software and not worry about skins being different [20:25:15] Also why its in core @agentisai, if a redirect loop happens on the wiki you wouldn't be able to change it again if in settings at least this wah it can be centrally also [20:25:18] My OCD kicks in when I see those errors. 😄 [20:25:41] We should really move forward with the RemoteWiki idea [20:25:52] to allow Stewards to manage wiki settings remotely [20:26:02] <.labster, replying to rodejong> Don’t do it then, use other CSS tricks to increase specificity of your CSS rules. [20:26:24] The linter is hella old [20:26:31] I would ignore anything it says its so annoying [20:27:00] <.labster> It doesn’t know the :has() attribute [22:56:53] Any efforts to update it lately? [22:57:09] Or too much technical debt? [23:12:27] Idk its controlled by extension:Linter or extension:CodeEditor i think [23:12:31] Upstream issue