Using RDAP (preferably) or WHOIS is a better solution for these kinds of issues.

I think importimages will be introduced to Special:RequestImport directly not a seperate special page, ImportDump is also in the process of being renamed to better accommodate this. Also probably will add a hook or something to support RestoreManageWikiBackups with it also.

This is now done!

https://github.com/miraheze/ImportDump/pull/66

Moving to low as this script has only been used like once in 2023 so it's really not urgent to have at all, plus the old way can be used in the meantime.

Triaging as low as domains that are not pointed aren't usually even removed on sight

I can now confirm that since notifications are fixed (thanks @Universal_Omega !) RequestSSL is operational.
What remains to be done is to add a check on-wiki for whether CNAME or NS is pointed (@Universal_Omega has an idea for how to do that easily) and then for the puppet API

This sounds like a task for @RhinosF1 !

In T7582#237196, @OrangeStar wrote:

@Reception123 If you want to get RequestSSL working right now, we could look at sending emails the way core does with Special:EmailUser

@Reception123 If you want to get RequestSSL working right now, we could look at sending emails the way core does with Special:EmailUser

In T7582#234826, @Reception123 wrote:

In T7582#234817, @OrangeStar wrote:

Regarding step 4:

This is too Miraheze-specific for inclusion in the RequestSSL codebase in my opinion. It is better suited as part of T11710. In the Miraheze-specific setup of this extension, once RequestSSL sends the request to puppet, the server program receiving the request should take care of determining if we should add new DNS zones. So I think steps 4 and 5 should be merged together.

Just to be clear, what you propose is the following? In my example, the domain is pointed via NS.
1: User requests SSL
2: RequestSSL checks (with puppet181's help) whether domain is pointed or not
3: RequestSSL submitted
4: ssl-certificate script once again checks whether domain is pointed and if it's pointed via NS, adds zone to GitHub
5: RequestSSL marked as completed

EDIT: in the fully automated version, steps 2 and 4 would probably be repetitive and would need merging

In T7582#234817, @OrangeStar wrote:

Regarding step 4:

This is too Miraheze-specific for inclusion in the RequestSSL codebase in my opinion. It is better suited as part of T11710. In the Miraheze-specific setup of this extension, once RequestSSL sends the request to puppet, the server program receiving the request should take care of determining if we should add new DNS zones. So I think steps 4 and 5 should be merged together.

Regarding step 4:

In T7582#234814, @MacFan4000 wrote:

I’m not sure that ssl-admins should be decommissioned, as cert removals would still be done manually, and this would allow us to investigate should something go wrong, and also somebody might not want letsencrypt.

I’m not sure that ssl-admins should be decommissioned, as cert removals would still be done manually, and this would allow us to investigate should something go wrong, and also somebody might not want letsencrypt.

@Reception123 I think it's about time we get a RequestSSL project and workboard on Phab. Also, add me as a member of the project if it will not have an open join policy please.

Thinking about it, it would still definitely be useful to check whether the domain is pointing before the request is submitting but the python script running on puppet141 would still be needed in the end in order to be able to create the DNS zone for wikis pointing NS. The script already exists but needs some adjustments.

@OrangeStar Thanks for the ideas. Indeed, it might be better to check whether the domain is pointed via PHP rather than having that in the python script and then having to contact the user afterwards and tell them it isn't. I guess what could be done then if it is not pointed is have an error display that clearly directs users to somewhere where they can get help pointing their domain.

Functional but not yet over! Can't do much right now since I'm waiting for T11680 which will introduce some utility functions (To avoid reinventing the wheel) that the server program that automates cert generation would need, but I want to cleanup some of my PRs (the ones yesterday were just to make stuff work), move strings into i18n, change existing i18n strings too, remove some ID leftovers I saw while skimming the code, and automate checking that the domain is pointed correctly at least.

Noting that the repo has been transferred to https://github.com/miraheze/requestssl

Thanks to @OrangeStar, RequestSSL is now functional! There's unfortunately one late issue that I thought of that will mean it can still not be made operational. For custom domains it is quite often the case that users don't point their domains properly and need guidance. My understanding is that RequestSSL uses Echo to notify users when there's a comment on their request and if they don't manually enable email notifications they might not get any and would not know that there's been a comment.

https://github.com/Reception123/RequestSSL/pull/5

In T7582#234462, @OrangeStar wrote:

In T7582#213501, @Reception123 wrote:

• Implement logging so that when RemoteWiki is executed with ManageWiki it logs it as if someone had changed managewiki on wiki

Does MediaWiki even have a concept of other wikis existing other than the one currently "running"? We could open the database for the remote wiki and manually write to the logs, but I don't think that's very good.

Assuming you want to log to the remote wiki's managewiki log.

In T7582#213501, @Reception123 wrote:

• Implement logging so that when RemoteWiki is executed with ManageWiki it logs it as if someone had changed managewiki on wiki

In T7582#234396, @OrangeStar wrote:

https://github.com/Reception123/RequestSSL/pull/4

https://github.com/Reception123/RequestSSL/pull/4

UO for the rescue! I was about to commit a grave sin against best practices.

In T7582#234392, @OrangeStar wrote:

In T7582#213501, @Reception123 wrote:

• Add a method so that $oldstatus and $newstatus is known in order for the updateManageWiki function to be executed only when the status is changed from something else to completed

So, I have an idea for this, but... it involves reading the $wgRequest global. Would this be acceptable? I'll keep searching for better ways to do this anyway.

In T7582#213501, @Reception123 wrote:

• Add a method so that $oldstatus and $newstatus is known in order for the updateManageWiki function to be executed only when the status is changed from something else to completed

In T11680#234284, @Universal_Omega wrote:

https://github.com/miraheze/python-functions

https://github.com/miraheze/python-functions

After talking with you about a few things privately and discussing this request with other members of SRE, I have decided to approve it.

In T7582#234273, @OrangeStar wrote:

Heads up: some custom domains are pointed using CNAME flattening. So any automation attempts should not only check for CNAME records or whether the authoritative nameservers are pointed to us, but if the A or AAAA returned points to the known IPs of cp* servers.

Heads up: some custom domains are pointed using CNAME flattening. So any automation attempts should not only check for CNAME records or whether the authoritative nameservers are pointed to us, but if the A or AAAA returned points to the known IPs of cp* servers.

Timestamps are no longer an issue. For any SRE that is a more competent developer than me (most will be!), the two remaining things for Step 3 are:

P494 would be an initial draft. Still needs error handling

Due to the large number of tasks in this area and the particular use that automation can provide, moving this task to normal priority. It'd be nice if at least the remaining fixes for RequestSSL (Step 3) can be completed soon.

Due to the large number of tasks in this area and the particular use that automation can provide, moving this task to normal priority. Assigning to @Universal_Omega as they are almost done with a version of this.

Please note that a similar task is currently being worked on by @Universal_Omega.

Since there's already extensions with similar names, we should probably call ours MaintenanceScripts.

Noting that this would be done in a similar way to https://github.com/miraheze/DataDump/blob/master/includes/jobs/DataDumpGenerateJob.php but would require additional security

https://github.com/Reception123/RequestSSL has been created based on ImportDump. Things that are required to make it operational

• Add a method so that $oldstatus and $newstatus is known in order for the updateManageWiki function to be executed only when the status is changed from something else to completed
• Implement logging (can be copied from ManageWiki) so that when RemoteWiki is executed it logs it as if someone had changed managewiki on wiki
• Fix issues with timestamp (might just be a problem with the SQL implemented on beta)

Due to limited knowledge on my part, it would be preferable if someone else had a go at this.

• Check if all i18n messages make sense (can be done by anyone) [DONE!]

I wrote some scripts, and am currently doing mass renewals in batches a few times per day.

Closing, since mirahezerenewssl works again (which this task is for) but it does seem all currently missed certs still need redone again.

Works now.

https://github.com/miraheze/puppet/commit/566c0e20719dbb4511498255e7decfe1f238dfc5

Hmm, an alert came in about 20 minutes ago, and a renewal should have happened but it didn’t which means there is still something going on. That above change was deployed.

Regarding the failure, I'm not sure ssl-acme failed, but rather the logging for mirahezerenewssl.py filled the disk space causing the entire process to fail. See https://github.com/miraheze/puppet/pull/3145

In T10311#210798, @OrangeStar wrote:

Man, robots extensions really are stealing our jobs volunteer positions. I have to ask though, what's so bad about SSH? It's more secure than regular web browsers, at least in my opinion.

Man, robots extensions really are stealing our jobs volunteer positions. I have to ask though, what's so bad about SSH? It's more secure than regular web browsers, at least in my opinion.

My script won't work for the new version of ssl-certificate, but should be able to make a new one for it.

I think @Universal_Omega might have had a script or some way to do this. What I'd recommend is now that we have this opportunity to manually renew is to separate renewals so that next time they don't all attempt to be renewed in the same day (so a batch tomorrow, a batch Friday, etc.)

Just so we don't forget, the current idea would be to try using https://github.com/wikimedia/acme-chief and have an API backend for ManageWiki with the web app being MediaWiki.