In theory we can recycle jobrunner3 to jobchron1. We'd need to remove the mediawiki and jobrunner roles, update hostname and DNS, and then adjust hardware settings. However, a downside to this approach will be that we will remain using a 47GB disk instead of 10GB. I don't believe we can resize this to be smaller.

I'm planning we recycle the existing jobrunner4 into this new task1 server. In theory, all we should need to do is update hostname and DNS, then a short restart to adjust hardware settings, and it should be good.

PRs:

• https://github.com/miraheze/ManageWiki/pull/294
• https://github.com/miraheze/WikiDiscover/pull/54

In T7713#155082, @RhinosF1 wrote:

I'll create announcements before doing this

I like this idea. I think is a great idea. And i think a field for adding a description in /Special:ManageWiki/core could be a good idea too.
I made a mockup of my idea.
Current: https://cdn.discordapp.com/attachments/435711390544560128/870395174918946917/Managewiki_core_01.png
Mockup: https://cdn.discordapp.com/attachments/435711390544560128/870395132405493760/Managewiki_core_02.png

In T7565#155045, @Universal_Omega wrote:

Should be fixed now and the new Kartographer configs are now done as well.

can someone please look at this and tell me what do i need to do.

I agree with Void in that dropping the maximal doesn’t make a lot of sense when it’s already set at that level by default. You’d need a good reason really to lower it and a standard that chose the length based on software we don’t use doesn’t seem it.

I strongly doubt that anyone has a >128 charecter password.

In T7713#155095, @RhinosF1 wrote:

In T7713#155094, @Void wrote:

I'm not certain I would reduce the maximum (currently 4096). In theory, the only problem with having a password longer than 128 characters is potential server load.

It comes from 2.1.1 and 2.1.2 of https://github.com/OWASP/ASVS/blob/v4.0.2/4.0/en/0x11-V2-Authentication.md#v21-password-security-requirements

No objections raised by me.

In T7713#155094, @Void wrote:

I'm not certain I would reduce the maximum (currently 4096). In theory, the only problem with having a password longer than 128 characters is potential server load.

I'm not certain I would reduce the maximum (currently 4096). In theory, the only problem with having a password longer than 128 characters is potential server load.

In T6127#124197, @Universal_Omega wrote:

Due to the fact that this extension is being requested on a "possible use-case" bases and not for the particular requester, closing the task. If any wiki in particular does want this, I would then be happy to review the extension. Typically tasks that request extensions on a theoretical use-case are closed, therefore closing this task.

I'll create announcements before doing this

Your DNS is pointing at a Softlayer Technologies IP

Hello, excuse me, I didn’t understand correctly. Could you try with https://wiki-asterix.fr.to? It shoulds redirect to Miraheze’s servers.

@Khamset Unfortunately there are none of my personal backups that go that far back. Was your wiki public? In that case there should be some on archive.org.

Why is this a security task?

Some pages like https://crappygames.miraheze.org/wiki/Wild_West_Online and https://crappygames.miraheze.org/wiki/Afro_Samurai_2:_Revenge_of_Kuma still actually use the old category. Please remove it from them and reopen this task if the issue still remains. Thanks!

I think we shouldn't deploy this change globally for minimal, if any true performance improvements, which would also have negative impact on wikis' special query pages being updated less often. I don't think the community would fully appreciate a sudden change like this globally due to the impact. It seems to not have the impact I wanted when creating this task. My opinion, revert the opt-in, remove it from all current wikis, and remove the updateSpecialPages cron from puppet so it isn't being unnecessarily ran. This can be probably be reconsidered later if it is necessary but for now I don't think it is.

Test worked in seconds so resolving

There seems to be no method to do this exactly how you want on Miraheze at this time. The best that could potentially be done is non case-sensitive searches it would seem. But even that I'm not certain.

We can't reveal user information publicly. I'll note the global account wasn't created properly but the user can email us if they need help.

Should be fixed now and the new Kartographer configs are now done as well.

I don't think there is much we can really do about this. I looked into the MirahezeMagic stuff regarding this, and it doesn't seem to be anything we could do to resolve this.

Regrettably declining this task.

anybody working here?
can i get some help..
i need this white listed.

In T5412#154985, @Universal_Omega wrote:

This has now been deployed.

Yes it's the number 211th on the list.

Ping @Reception123. Looks to have been deleted in P344.

This has now been deployed.

In R9:66ca12362dded50a849c10b85b50ad6fd87c6337#91670, @Apicciau wrote:

Hello! Do you have an idea of when this extension is going to be re-enabled?

Hello! Do you have an idea of when this extension is going to be re-enabled?

XML dump done. For images, you will have to find an external tool or do it manually.