[16:12:14] Orange_Star: which utility functions do you need? [16:13:43] Well, while I plan on doing the domain checks on MediaWiki, ideally the server program on puppet* as part of step4 will also check that the domain is pointed correctly just in case [16:14:07] remember what you said about a function that will check for CNAME/NS/A/AAAA pointed to a Miraheze server? [16:14:13] that's what I'm talking about [16:14:26] Orange_Star: okay, yes, I can port that first [16:14:29] Maybe Sunday [16:14:39] That's easy [16:14:46] So you want check_reversedns exposing [16:15:12] The code already exists for that [16:15:31] basically [16:15:32] I just need to package it [16:15:53] would also have to tell what kind of server it is: cache proxy/nameserver/mw appserver, all that stuff [16:18:46] It checks for NS records pointing to NS1 & NS2 in any order, for CNAME pointing to .miraheze.org or an AAAA/A record pointing at cp* [16:19:18] CNAME should check rdns is cp* too [16:26:09] RhinosF1: we'll probably still need to replicate those checks in a separate python script for the DNS zone to be created, so it'll be nice to have the utility function then [16:26:21] then we don't need to copy paste stuff all over [16:27:26] Ye I saw your dns one [16:27:40] Icinga has most of it built [16:27:51] I just need to move it to a tested utility [16:27:56] That won't take too long [16:27:59] Orange_Star: the email notification part is a bit confusing as as far as I know the ones with echo don't actually work by default [16:28:13] Also, if you look at https://phabricator.miraheze.org/maniphest/query/II0kjGARV7NG/#R this is proof that even people who pay for their domains often don't end up responding to questions [16:29:24] I have email notifs from people mentioning me on talk pages on Meta [16:29:28] works for me at least :p [16:29:54] for that yeah but for extensions like ImportDump/RequestSSL I don't know [16:30:20] echo works fine, people just don't read stuff [16:30:46] RhinosF1: as far as I know, unless you enable it manually, people won't get an email from an ImportDump reply to your request [16:30:50] or even a request wiki one [16:31:00] I can test it out now actually [16:31:02] You can change the default [16:31:14] well yes, but people won't and then they forget about their tasks [16:31:15] It's just a user preference [16:31:22] So change the default [16:31:25] that happens on phab so often, even _with_ email [16:31:31] So all new users get emails [16:31:35] well Orange_Star said it is already the default [16:31:54] If the default is they get emails and people don't read them, that's not our problem [16:31:59] I also talked to CA about this the other day and he said it might not work due to something being overriden somewhere [16:32:08] RhinosF1: obviously not, I mean people don't actually get them [16:32:23] Then it's clearly not set correctly somewhere [16:32:39] That's a bug probably in our config [16:34:25] I see now yeah. Well I probably want what's not possible. I don't want us to have to set the default option of everyone getting an email for everything. I just want people to get emails by default for: RequestWiki, ImportDump and RequestSSL replies [16:36:28] Yes of course you can do that [16:36:39] It's a user preference [16:36:51] You can change the default preference for notifications for people [16:36:57] It's really simple [16:37:05] Why on earth would it not be possible [16:37:19] Go into your settings and look at the list of types [16:37:28] It has an email and echo tickbox [16:37:38] Anything in that list we can adjust the default for [16:43:55] Can someone comment on https://meta.miraheze.org/wiki/Special:RequestImportDumpQueue/1 ? [16:44:01] I have it enabled to notify me via email [16:44:05] but I don't remember it ever working [16:44:34] reception123: if your fear is changing it for everyone, changing $wgDefaultUserOptions only affects new accounts, not existing ones [16:44:51] yeah that's fine, what RhinosF1 makes sense. My fear is that it doesn't work! [16:45:00] I can't comment [16:45:11] so if someone could comment on that request that'd be great [16:45:33] You'll need another SRE in the onwiki group I think [16:45:40] Hopefully it works [16:45:50] If it doesn't, that's a bug [16:47:38] done [16:47:46] thanks [16:48:06] as predicted, no email [16:48:27] so I guess the problem is we need to find out what is broken [16:48:49] [1/2] I'm sure the setting is enabled properly [16:48:50] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1197583385791570078/image.png?ex=65bbcb71&is=65a95671&hm=3cec042bb2350171e9b35dfbb9aceefc67e8f28457c1c6ba14d841756d114905& [16:49:33] there's no actual echo notification either actually [16:49:49] so not even an on-wiki notif [16:51:05] at least that narrows it down to the ImportDump-Echo integration not working [16:53:12] integration not really complex: https://github.com/miraheze/ImportDump/blob/062337d97268645e7c4b22201e3b0cf7b61be834/includes/ImportDumpRequestManager.php#L164 [16:58:01] tbh I'm not sure it's working for wiki requests either [16:58:43] if someone wants to create a wiki request that I can decline we can test it! [16:58:56] on it [16:59:51] https://meta.miraheze.org/wiki/Special:RequestWikiQueue/40049+ [17:01:12] I got a Echo notif on-wiki! [17:02:22] no email despite having Wiki request declined set? [17:03:15] i meant email notifications enabled for that [17:06:15] https://github.com/miraheze/CreateWiki/blob/58546d93c11d9131208f56d0895d432cb2246faf/includes/CreateWikiNotificationsManager.php#L164 notification is created on CreateWiki [17:09:53] wow Tali is so fast he didn't even give me a chance! [17:10:06] but yes, that definitely proves my theory that Echo email notifications are broken [17:10:34] @cosmicalpha mentioned that it was overriden by SiteConfiguration or ManageWiki before [17:10:46] Orange_Star: did you get a notification on-wiki? [17:10:49] yes [17:10:52] no email tho [17:11:11] @tali64: If SRE are testing something, please leave it alone [17:11:38] RhinosF1: tbf, he couldn't have known [17:11:50] I will make some new notifications today probably without Echo [17:11:59] er, well, if it says "Testing wiki request notifications", I'd leave it alone [17:12:11] Yes you can [17:12:30] An SRE created a request that says testing notifications [17:12:35] That's good but wouldn't it be easier to fix the current ones so then we don't have to replace everything everywhere? [17:12:52] If an SRE is testing anything, you leave it alone unless instructed otherwise [17:13:12] I'm not SRE tho [17:14:04] Well description still fine [17:14:12] You should be SRE again [17:14:18] lol [17:14:23] In either case, I still think it's probably better to try to fix echo emails if we can [17:14:27] No, I don't like Echo notifications anyway, I can make nicer formatted ones then what Echo does. [17:14:27] But you can clearly tell it's a test of software [17:14:33] It should have been left [17:14:37] fair enough [17:14:49] Or at least they spoken to you [17:14:54] Like the WF ones that provides a lot of guidance on how to use ManageWiki also. [17:15:09] oh yeah, those email notifs are beautiful [17:15:10] What if you were testing comments, approvals, a specific scenario [17:15:47] @tali64 if you are around, please either DM or comment here [17:15:58] I am [17:16:23] rhinosf1: I think he got the idea, let's move on to something else [17:16:54] https://phabricator.miraheze.org/T11693 [17:16:55] I'll leave the notifications to CosmicAlpha, I'll get with cleaning RequestSSL on the meanwhile [17:17:29] as soon as the email notifs are good, there will be nothing to stop the first version of RequestSSL from being launched! [17:19:03] @cosmicalpha would your new notifications be customizable via Preferences? (though I guess it's not really needed anyway if they're only for RequestWiki,ImportDump,RequestSSL) [17:20:31] [1/3] Is like what WikiForge does that I want to do similar here for a lot of different things. [17:20:32] [2/3] https://cdn.discordapp.com/attachments/1006789349498699827/1197591363374559372/image0.jpg?ex=65bbd2df&is=65a95ddf&hm=cd6dd08e6522af8088014db6d00a9230823384dae336c1db69ed4f3050e03b55& [17:20:32] [3/3] https://cdn.discordapp.com/attachments/1006789349498699827/1197591363663970334/Screenshot_20240118_102005_Gmail.png?ex=65bbd2df&is=65a95ddf&hm=3f67ed4bdb3e47b38a6043f344280789b7881069a7e39c7b1be4abb93d442110& [17:22:09] Echo is just a mess and often unreliable it seems. [17:22:20] It could be, but doesn't have to be. [17:23:42] [1/3] so would we be able to do something like: [17:23:42] [2/3] "Hello! [17:23:42] [3/3] This email is to let you know that someone has commented on your recent wiki request. Please check it out [here]" [17:24:18] Yep. [17:25:14] The Miraheze emails on wiki creation are so plain and dull also I'd like something better than that also... [17:25:53] true, though at leat those work! [17:27:59] Yeah that's true also. [18:03:15] [1/2] @reception123 if you want I think I can push a quick fix right this minute for fixing CW echo notifications for comments, I just realized ImportDump echo notifications works fine. CW actually does work for declined, but by default not for comment. I remember that was to avoid 3 different emails on creation, the approve comment, the "Wiki created.", and the default your wiki has b [18:03:16] [2/2] een created email. It also doesn't send to own actor if you comment, so it was harder to test. [18:06:37] hmm, it didn't work for declined for Orange_Star though [18:08:25] ImportDump obviously works all those "New ImportDump Request Received" notifications are Echo. Only works if you have a verified email though IIRC also. [18:10:08] just in case, I do have a verified email on my wiki account [18:12:13] Dang the logouts are coming fast and furious today. I'm barely staying logged in for more than 5-10 minutes at a time. [18:14:12] Those yeah what I meant is that for CW, OrangeStar didn't get a declined comment and you said it does work [18:15:40] all this email stuff is quite confusing [18:17:31] CW doesn't seem to use Echo...? [18:17:41] I mean for email [18:17:53] It does for declined and comments. [18:18:05] https://github.com/miraheze/CreateWiki/blob/0168c59965e072c7bdd6eb3ad50a2030c404486a/includes/CreateWikiNotificationsManager.php#L142 [18:18:26] oops, meant L164 [18:19:02] right... [18:19:03] https://github.com/miraheze/CreateWiki/blob/0168c59965e072c7bdd6eb3ad50a2030c404486a/includes/CreateWikiNotificationsManager.php#L184 [18:19:06] sorry [18:19:27] its used based on type, some use email others echo [18:19:31] https://github.com/miraheze/CreateWiki/blob/0168c59965e072c7bdd6eb3ad50a2030c404486a/includes/CreateWikiNotificationsManager.php#L93 [18:20:48] huh, curious [18:22:12] Originally the logic was a mess and all over the place I combined it all into that service in https://github.com/miraheze/CreateWiki/pull/256 [18:26:56] This is why Gamepedia created Reverb [18:57:03] coming along pretty well https://github.com/miraheze/RequestSSL/pull/6 [18:57:12] well, not like it's very hard [19:01:31] looking good! seems like I forgot a few things during my borrowing stealing from ID [19:19:29] and I think that's all [19:19:44] PR ready for review, hopefully I didn't break anything, but I don't think I did [19:21:58] this reminds me we still don't have a PR [19:22:01] I mean CI [19:22:18] should probably write at least the most basic of tests tomorrow [19:22:34] could probably lift a lot of them from ImportDump hehe [19:26:00] oh looks like reception already took care of that [19:28:34] reception123: pls do CI one of these days [19:29:28] my bad 😦 [22:46:40] I have a small python script for fixing containers when setContainersAccess fails for some reason. The script probably shouldn't live in my home directory on mwtask141 though. Anyone have better ideas where to put it? Current ideas are to put it somewhere in puppet, MirahezeMagic, or the new python-functions repo. Would like some input. [22:48:03] is the intention to only have to run from 141? [22:48:44] No, but it can only be run from a MediaWiki server (preferably a mwtask) [22:56:10] I'm happy with a phab paste until I add it to Python-functions [23:03:01] 👍 Sure, I'll do that for now, especially since it still needs proper multiversioning support [23:06:08] [23:09:32] I won't ask why [23:09:42] But I'll add a new version of it to Python-functions [23:12:13] It was originally created as a hacky solution a couple of months ago the last time cloud11 crashed. It's a simple solution to a problem that should probably be fixed in setContainersAccess.php, but I'm not immediately sure how to accomplish that. Hence the creation of a simple script that does what it needs to. [23:42:48] @orduin can you also do your script for the swift object server