Nice work! :)

All to-be-removed servers have had their cabling removed, except in rack OE12.

The last RAID array (md2) is now resyncing.

All esams racks have been audited with their Racktables counterparts, and object location and unusable items are now correct.

This has now been corrected and verified on-site.

After consultation with Ema and considering how long this server has been broken, is 1 out of 4 misc varnish servers and the misc cluster is being folded into text anyway, we decided it's not worth repairing this server.

ms-be3003 is still connected, and eth0 and eth1 are connected to ports 4 and 5 of csw2-oe11-esams respectively. (csw2-esams).

bast3002 (aka hooft) sdb has been swapped with amslvs3's sdb (both LFF, non-hotswap). The server has booted back up, and sdb is being repartitioned and added to the RAID arrays.

Because cp3048 is out of warranty and it's unlikely we can get it fixed, I've used it as a parts donor for other broken systems:

Swapped DIMM B3 with DIMM B3 from cp3048 (parts donor). Server booted up just fine afterwards.

cp3043 drive 2 (sdb) has been swapped for cp3048's drive 2 (sdb), as cp3048 is out of warranty and unfixable anyway. RAID1 md0 has been restored, and the server is back up and running.

More recently:

As Chris confirmed, this is either due to CPU or memory.

These were purchased by Rob and given to me in January.

It looks like cp3030-cp3039 are in OE13 (despite what Racktables says), and cp3040+ are in OE40. So this is swapped from reality in Racktables. This is confirmed with LLDP info from the switch.

In T195623#4243588, @RobH wrote:

@mark: Is this something you would want to approve? If it was a permanent allocation, I know it would be. Since it is a temp allocation, I'm not certain.

Please advise.

This is now in the latest PyBal releases, so resolving this ticket.

Unfortunately we've had an issue with managing access to the admin account for the Google search console for a long time. Currently the only option is sharing the single password to this account with multiple people, which besides the obvious security problems this entails, also causes Google to detect abuse all the time.

In T184666#4033042, @kaldari wrote:

@jcrespo: One thing that hasn't been mentioned is that GlobalPreferences will almost certainly reduce the growth of the user_properties tables in the long run. Instead of users having to duplicate all of their preference selections across all the wikis they use, they will only have to set them once on their home wiki and declare them to be global. So the net effect on db storage should actually be positive in the long run.

You are setting up a publicly accessible web service, right? So you should probably open up port 80 (and/or 443) to the entire world, not just LVS servers.

In T172459#3939141, @jcrespo wrote:

@BBlack The thing is, we physically could do this in 2 weeks- if we put it on our top priority and do nothing else- I don't know how urgent is this- if it is long tail maintenance that can wait, or things are literally breaking apart. A manager would know were to put it on our pile and how to prioritize with more context, that is why I mentioned, so we can provide you with a more accurate timing.

In our case, literally as I write things, mysql is breaking apart... wait for the ticket.

you just need to find an answer to the question from your end

If it was entirerly on a reasonable expectation, I would wait until a failover, in 4+ months, as it save us time- but I do not think it is entirely up to us, we can discuss.

asw-oe14-esams, asw-oe15-esams and asw-oe16-esams have all been mounted in their respective racks, all at position 24 (so midway).

cr2-esams is mounted facing the hot row (like all network equipment) so this makes sense.

cp3048 had one PSU loosely connected, fixed. All other systems in the rack have redundant power atm.

Have we acquired a new image for AS14907 yet?