I set up the payment agreement, so the charge should be taken automatically from Paypal.

Seems worthwhile to me. ES can consume a lot of resources.

Minor note: at least I got them to update their docs on sub accounts: https://www.name.com/support/articles/205934117-Creating-a-Sub-Account

until next year.

Unfortunately, I no longer have access to the name.com account that hosts our domain names. It appears that someone turned on 2FA, which means that I cannot access the sub account. I tried to talk to support, but they basically said no, because the account is in your name. If you'd like me to pay it, please disable 2FA or send me the code to access by google authenticator @Southparkfan

Crowncloud is cheap but the ToS worries me a bit. Get two DMCA takedowns, your account is terminated immediately. Host any content that educates about piracy, your account is terminated immediately. (???) For backups they're probably fine, but for any other service I'd start to worry. From their ToS, I think their business model is cheap because it's based on shutdown first, ask questions later.

More RAM for Redis sounds good. Approved.

Yes. Not permitted is the set of content ("erotic", "pornographic", extremist", "not deemed in good taste"). Therefore pornographic material is expressly prohibited, as are erotic writing and tasteless jokes.

The placement of erotic, pornographic, extremist material or material not deemed in good taste is not permitted.

I'm pretty okay with this idea. If this works out, we may want to move all of the file storage to another DC, so we don't get too much replication traffic. But static data would be fine to keep in another DC.

Encryption is one thing, but I meant bad from a performance point of view. It shouldn't take less time to round trip through your database than your cache. You want to put cache as close as you can to your application servers. Possibly even with read-only replicas running on the mw servers, if you can spare the memory.

Wait, if misc2 runs Redis, does that mean that our cache will be in a different DC than our app servers? This seems like a questionable idea.

I'm not sure at what level funds are lacking -- last I heard we were trying to buy a CVZ and RN NL didn't have one available. What sort of server are we looking at to resolve this?

Give it a shot. The current searches don't work well, either.

Sorry I've been somewhat jet lagged. Let's go ahead and do this.

All paid up now. Waiting for final transfer.

Initiated the domain transfer. Revi, you need to tell me how much we owe you. Can I get you the money by Paypal, or is there some other way you'd like?

I'm not really sure that we could install this. It needs a secret key, and we don't really have any provision to store per-wiki secret keys secretly. LocalSettings is a public file. So enabling this extension would be equivalent to allowing arbitrary HTML, with an additional security by obscurity layer.

I was waiting until we got to 60 days so we got a full extra year of renewal when I transfer the domain. And...

Retroactively approved. This is really my fault as I should be able to just give you a budget, and as long as you stay within it, everything should be fine. I did a budget last year, but no one ever looked at it, so I slacked this year.

If content was ever available under 3.0, it is always available under 3.0 until the copyright term expires. You should be able to continue to export content.

If John was going to steal Miraheze, he would have done it a long time ago, lol. But seriously, I don't really use the upgrade power, because I'm not really a sysadmin, that's only because I need to be able to get in and pay the bills.

Sure, I'm just going to authorize a net increase of $5 per month here, because I'm not really sure what you're planning to do. Tech:Cp4 has two different numbers, lol. Not really in a position to say which concern wins out, reliability or having less servers to maintain.

So we're better off than when we started the task, so we have a bit of time to discuss here.

Verified that a user emailed us this database, and that Miraheze did not use any form of scraper to retrieve this data. As such, there is no reason to halt this request at this time.

Nope, they don't allow it. That's why I disabled Extension:DonateBoxInSidebar.

IP address can be PII too, especially when tied to a user account. You'd have to get all IPs recorded for all edits from that user. And a list of all edits made by that user -- honestly not sure if we'd have to include the revision text or not.

I've read the GDPR, and found nothing that suggests this to be true. Closing as invalid.

Just FYI I'm reading the GDPR now.
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN

Approved. Go ahead and purchase it.

I'd assume that we try to move into compliance on our own first. It reduces billable hours.

No opinions in particular. I've heard of the GDPR, but I don't really know what, if anything, we'd need to do to come into compliance.

Maybe I need to find another way for people to pay first. But yeah, I noticed the large chunk of server cost this month, too.

I would like to know what I'm approving first, thanks. Is this 1GB SVZS to 2GB SVZS?

Sent a message upstream, looks like it's a corporate-managed git, so I sent an email to their security address.

Security review failed. I kind of feel bad because it would be the most obvious XSS to any admin, because people would probably notice a page title named Foo" onload="alert('hax!');, but so it goes. The whole extension could stand to be rewritten using the mediawiki Html class.

Extension looks good to me. Nothing to complain about, all modern looking code with appropriate stripping. Security approved.

Yes. Mainly I just didn't want to verify it worked, but I noticed that the issue I opened a long time ago closed.

Oh yeah, very simple. Security approved, go ahead and install.

Someone needs to run refreshLinks.php on allthetropeswiki. I would, but I've lost my sysadmin bit recently.

This is a WMF extension, and therefore bypasses the security review. I assume the Maps service is subject to the same privacy policy as is normal for WMF projects, so we don't really have issues with that, either. It's just a matter of installation and configuration, now.

Well, on-wiki kinda counts for me, as managing finances are a decent part of my contributions here. But not from an ops standpoint.

Approved by me.

Talked to Namecheap support. They said it wouldn't be possible for me to transfer funds into that account. While I can pay bills for the current domain, I can't add money to the account.

Remind me again why needing 2x more RAM counts as a software upgrade.

Note that the security review was already approved in T2247, so really what we need here is a sysadmin review, as to whether we can handle the additional queries.

Yes. The extension is almost misnamed, except for the function it serves. It can put literally anything in the sidebar, so long as you have access to the config files.

Yeah, approved. 16GB VDS looks like a good deal for us without changing too much on the billing side either. There's enough money in the RamNode balance to make the purchase, so go ahead whenever you're ready.

Note this extension creates three tables, so we probably want to push install until after we get a new db server set up.

It looks like @Samwilson's PR was merged, so we can go ahead and install this.

Extension:CustomSidebar is declined. There have been like 3 reports that it hasn't worked since at least Mediawiki 1.27, so I'm pretty sure it wouldn't work on Miraheze. That said, if anyone wants to make a git repo and update it, I'd be happy to entertain the extension. What there is looks safe enough. I'm sure it could be improved, as this is a slightly scary line:

Actually deferrable updates are not the job queue, it happens at the end of each request. https://www.mediawiki.org/wiki/Manual:Job_queue/For_developers Hm. Maybe a feature request for E:HitCounters would be in order.

Extension:TopTenPages is approved. However, it's not gonna work without Extension:HitCounters. This was originally WMF written, so the code is still in great shape. So this extension is approved as well, from a security point of view.

First of all, I really need to congratulate this extension's idea of security:

Ugh really are we asking me to review a Flash widget? It's a little hard to security review a binary, but I guess the PHP looks fine.

They're asking for renewal for this month, so are we going to use them or should I drop the service?

Hey guys tell me what to order and I'll do it.

Europeans have to do everything backwards, huh. Like when we have night, they have day.

I guess the phone call is not happening? There was some weird messages about it because I'm a first time buyer or something. Anyway the order number is NL20180104259060.

OK, created an account and bought a server. Apparently they need to give me a phone call to activate it or something?

And paid the upgrade cost (looks like we get to keep the discount).

Opened a ticket for an upgrade.

Yes, we obviously need to add more space to backups. I'm just hoping that the 40% coupon still applies to the upgrade!

I just created an account on TransIP, but I'm not sure what to do next.

OK, let's go ahead and do it.

Time to retry? @revi ---> @Southparkfan

This one is approved for install, everything looks great.

OK, so in general, I feel like RamNode doesn't have any plans that meet our requirements for a database server. Just by our design -- make all the tables in advance, have lots of small wikis -- this implies we're going to have a lot of data at rest. Some of our services, like the wright*wikis, sit inactive most of the time by design. So we don't really need high-CPU, high-memory DB servers. It's probably worthwhile to look at other providers.

Yeah, the lack of redundancy is troubling. I think we're big enough now -- and have enough usage -- that we ought to have some level of redundancy, so let's go ahead and buy a new mw server.

Looking at https://gerrit.wikimedia.org/r/#/c/387075/1/includes/RandomFeaturedUser.php alone, for T891, I think I feel comfortable saying that @Samwilson is fine at security reviews. Welcome to the team!

Cool, a best practices list. Everything is pretty good there except the first item, obviously.

The cause of the problem is simple: no one else is qualified to review, and no one has time to recruit more qualified people. Your assumption along with the word "surely" is entirely incorrect. None of the other system administrators can help on this, because they're not programmers. SPF used to do reviews, but isn't as skilled at it as I am, and similar time restrictions apply on his end as on mine. And honestly, his time is more useful as a sysadmin right now.

I feel like giving Reception123 more access is unlikely to make matters worse around here. In my experience Reception knows when he's out of his depth, and then asks for help. That's good enough for me.

I reckon there's more to improve.

I'd love to have another reviewer. The security reviewer checklist is basically:

• Are you a programmer?
• Can you read an entire codebase of an extension?
• Do you know what XSS and SQLI are without looking them up?
• Can you see the above things in Other People's Code?

Declined per security issues as stated in T1640.

OK, if even a fraction of wiki.wiki wikis come to us, we're going to need this, as we have only a fraction of the volunteer time needed to deal with all of their TLDs.

Yes, having different servers for different task is a good idea. I approve this proposal, though at some point someone needs to tell me the specs of the new servers so I can figure out how much it costs.