In T7230#143735, @Paladox wrote:

On https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592149 it says ionice -c 3 /usr/share/mdadm/checkarray --cron --all

In T7227#143773, @Reception123 wrote:

In T7227#143576, @Universal_Omega wrote:

My mistake, it's the Header Footer extension that causes this actually.

I tried disabling it on test3 and that didn't seem to fix it.

My apologies for the delay. Ok I think I've set up CloudFlare properly now. I would like the below as my custom url if possible:

In T7203#143774, @Julien wrote:

I cannot add a CNAME entry for arru.xyz (my DNS server returns me an incompatibility error because of the other NS and MX entries for arru.xyz). I can only add an A entry. Does miraheze support that?

I cannot add a CNAME entry for arru.xyz (my DNS server returns me an incompatibility error because of the other NS and MX entries for arru.xyz). I can only add an A entry. Does miraheze support that?

In T7227#143576, @Universal_Omega wrote:

My mistake, it's the Header Footer extension that causes this actually.

in progress

In T7191#143669, @Psych_Ji wrote:

Hi, have spoken to GoDaddy (domain registrar) and they have confirmed that the nameservers have been changed to Miraheze as per above and it all looks okay on their end. The customer service person asked me to check with you if you had a link to the domain in your database, so setting up 'domain hosting' in their terms. If this doesn't work out they suggested setting up the A name or CNAME record (but unsure if I'd need to point the name servers back to them first, as they can't troubleshoot issues any further without it pointing back to them at this stage)

Hope this makes sense?

It would probably be best if you would remove the redirect on your side, point www to Miraheze and let us do the redirect.

No response. Please feel free to reopen this if it's still needed.

In T7226#143738, @HopelessNightOwl wrote:

In T7226#143599, @Dmehus wrote:

@HopelessNightOwl If I'm understanding you correctly, Are you saying that you want the existing horrorstories.miraheze.org wiki to be deleted, then move creepypasta.miraheze.org to horrorstories.miraheze.org? In this scenario, creepypastawiki would become horrorstorieswiki, and creepypasta.miraheze.org would be no longer exist and become available. This would be much easier and simpler than generating dumps, deleting, and recreating wikis, if possible.

Other way around. Delete current creepypasta.miraheze.org, move horrorstories.miraheze.org to creepypasta.miraheze.org, and release horrorstories.miraheze.org for availability

Looks like the user was able to log in. Please close this ticket. Thanks!

Yes sorry i didnt explain it in the right way. I meant that earlier this year you had granted me the possibiity to set those settings to true but while we were discussing about DPL3 those setting were made available only for DPL and not DPL3.

In T6838#143742, @Ilias_Siachos wrote:

Hello. I just noticed that the wgDplSettings['allowUnlimitedCategories'] and wgDplSettings['allowUnlimitedResults'] are available only for DPL and not DPL3. As i would prefer to use DPL3, is it possible to be made accessible for this particular extension? Sorry for the inconveniece.

Hello. I just noticed that the wgDplSettings['allowUnlimitedCategories'] and wgDplSettings['allowUnlimitedResults'] are available only for DPL and not DPL3. As i would prefer to use DPL3, is it possible to be made accessible for this particular extension? Sorry for the inconveniece.

What seems to be left:

• Twitter
• gofundme
• Phabricator badges
• possibly hund?

Test backup: mydumper -G -E -R -v 3 -t 2 -c -L "/home/dbcopy/dbbackup1-mnt/$(date +"%Y%m%d%H%M%S").log" --trx-consistency-only

• db11
  • Duration: 2095 minutes (34.9 hours)
  • Size: 14 GB
  • Tables: 204,174
• db12
  • Duration: 1615 minutes (26.9 hours)
  • Size: 26 GB
  • Tables: 156,104
• db13
  • Duration: 1359 minutes (22.7 hours)
  • Size: 35 GB
  • Tables: 125,530

In T7226#143599, @Dmehus wrote:

@HopelessNightOwl If I'm understanding you correctly, Are you saying that you want the existing horrorstories.miraheze.org wiki to be deleted, then move creepypasta.miraheze.org to horrorstories.miraheze.org? In this scenario, creepypastawiki would become horrorstorieswiki, and creepypasta.miraheze.org would be no longer exist and become available. This would be much easier and simpler than generating dumps, deleting, and recreating wikis, if possible.

OVH/RamNode done.

The script runs with --idle which uses ionice, so it's already using it?

On https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592149 it says ionice -c 3 /usr/share/mdadm/checkarray --cron --all

As discussed; candidate for Goal-2021-Jul-Dec.

Discussed; handing over some of the tasks to me (see subtasks), we won't delay this.

Puppet 6 is EOL in December 2022, no need to rush this. Scheduled for Q4 2021 / Q1-Q2 2022.

Until configuration has been synced (mostly) with Varnish'.

Until configuration has been synced (mostly) with Varnish'.

I found this https://github.com/kopchik/scripts/blob/master/checkarray#L70 when searching up.

Discussed; paladox will contact Wikimedia DBAs.

Done now, my bad,

+ Phabricator admin?

Most things should be done. OVH access (why I can't seem to do) and Twitter remain.

As I have also said privately, this is very unfortunate and I would like to again thank you for your service and commitment to Miraheze in these past 6 years. I'll remove the rights, regretfully.

Hi, have spoken to GoDaddy (domain registrar) and they have confirmed that the nameservers have been changed to Miraheze as per above and it all looks okay on their end. The customer service person asked me to check with you if you had a link to the domain in your database, so setting up 'domain hosting' in their terms. If this doesn't work out they suggested setting up the A name or CNAME record (but unsure if I'd need to point the name servers back to them first, as they can't troubleshoot issues any further without it pointing back to them at this stage)

@J-Josyu Done. Restored bureaucrat rights per this request. Closing as invalid as Phabricator is not normally used for these requests handled by Stewards.

This is normally requested here and performed by Stewards, but I'll take a look at this now

Oh, great. :)

Okay, I transferred the nameservers from cloudflare to you, not sure if that has caused a delay?

This should have been broken since last year when the configuration was changed to disallow the img tag, which AFAIK, has been deprecated by upstream. Is there any reason you simply can't use Wikitext?

It is fixed now. Thank you.

Thank you very much for your support. Cutom domain works but one question remains:

url is https://officer46.miraheze.org

In T7233#143597, @MarioMario456 wrote:

I have closed horribletvshowepisodeswiki.

EDIT: Wait, nevermind. This may interfere with the import, so temporarily re-opening.

@HopelessNightOwl If I'm understanding you correctly, Are you saying that you want the existing horrorstories.miraheze.org wiki to be deleted, then move creepypasta.miraheze.org to horrorstories.miraheze.org? In this scenario, creepypastawiki would become horrorstorieswiki, and creepypasta.miraheze.org would be no longer exist and become available. This would be much easier and simpler than generating dumps, deleting, and recreating wikis, if possible.

I have closed horribletvshowepisodeswiki.

In T7233#143593, @MarioMario456 wrote:

In T7233#143591, @Dmehus wrote:

@MarioMario456 This is quite an involved task and would take quite some time. With regard to redirecting horribletvshowepisodes.miraheze.org, preferred practice is not to redirect Miraheze subdomains because it becomes challenging to remember which subdomains are redirected to another wiki. So would you be okay with not redirecting horribletvshowepisodes.miraheze.org and instead you could just keep horribletvshowtvshowepisodeswiki active as a read only wiki with a local sitenotice pointing users to terribletvshowswiki for, say, 2-3 months, then you could request the former wiki be deleted?

ok

In T7233#143591, @Dmehus wrote:

@MarioMario456 This is quite an involved task and would take quite some time. With regard to redirecting horribletvshowepisodes.miraheze.org, preferred practice is not to redirect Miraheze subdomains because it becomes challenging to remember which subdomains are redirected to another wiki. So would you be okay with not redirecting horribletvshowepisodes.miraheze.org and instead you could just keep horribletvshowtvshowepisodeswiki active as a read only wiki with a local sitenotice pointing users to terribletvshowswiki for, say, 2-3 months, then you could request the former wiki be deleted?

@MarioMario456 This is quite an involved task and would take quite some time. With regard to redirecting horribletvshowepisodes.miraheze.org, preferred practice is not to redirect Miraheze subdomains because it becomes challenging to remember which subdomains are redirected to another wiki. So would you be okay with not redirecting horribletvshowepisodes.miraheze.org and instead you could just keep horribletvshowtvshowepisodeswiki active as a read only wiki with a local sitenotice pointing users to terribletvshowswiki for, say, 2-3 months, then you could request the former wiki be deleted?

In T7229#143569, @Void wrote:

In case anyone with eyes on this missed, but I've identified the cause upstream: https://phabricator.wikimedia.org/T221560#7051371

Not 100% certain on a fix, but knowing the cause might at least get someone else to fix.