Replacing IBM X3650 (7979-C3U) Planar (FRU: 43W8250/43W0331)

For those of you who may have followed along on my original post of me troubleshooting of an IBM X3650, I found a system planar for $20 (lol). Just arrived today, with shuttle, which is awesome. I’ll be putting this in the server chassis today and hopefully getting a successful boot.

Left is the new board and right is the old.

Update 5/12

After being out of the office with other tasks, I finally had some time this morning to get this swapped out.

Everything went well with the exception of the memory. I had to put in 2x1GB sticks in DIMM slots 1 and 4 as the previously installed 4GB modules were not working and I was finally able to get a POST.

The BIOS at post is 1.03 and ServeRAID 8k-l initialized. I do need to update the BIOS as well as ServeRAID BIOS. The board I swapped from was at BIOS 1.19 and ServeRAID BIOS was at 17003.

WordPress Unauthorized Password Reset Vulnerability (CVE-2017-8259)

WordPress has a password reset feature that contains a vulnerability which might in some cases allow attackers to get hold of the password reset link without previous authentication.

Such attack could lead to an attacker gaining unauthorized access to a victim’s WordPress account.  This affects all versions of WordPress, including the current version, 4.7.4.

Description

The vulnerability stems from WordPress using untrusted data by default when creating a password reset e-mail that is supposed to be delivered only to the e-mail associated with the owner’s account.

This can be observed in the following code snippet that creates a From email header before calling a PHP mail() function:

wp-includes/pluggable.php

if ( !isset( $from_email ) ) {
        // Get the site domain and get rid of www.
        $sitename = strtolower( $_SERVER['SERVER_NAME'] );
        if ( substr( $sitename, 0, 4 ) == 'www.' ) {
                $sitename = substr( $sitename, 4 );
        }

        $from_email = 'wordpress@' . $sitename;
}

3 separate example scenarios (both the ones that require victim interaction and those that do not) include:

  1. Attacker can perform a prior DoS attack on the victim’s email account/server (e.g by sending multiple large files to exceed user’s disk quota, attacking the DNS server etc) in order to prevent the password reset email from reaching the victim’s account and bounce back to the malicious sender address that is pointed at the attacker (no user interaction required)
  2. Some autoresponders might attach a copy of the email sent in the body of the auto-replied message (no user interaction required)
  3. Sending multiple password reset emails to force the user to reply to the message to inquiry explanation for endless password reset emails. The reply containing the password link would then be sent to attacker. (user interaction required)

Workarounds

  1. If you are using Apache, you can turn on UseCanonicalName (see: https://httpd.apache.org/docs/2.4/mod/core.html#usecanonicalname)
  2. I created a simple plugin that you can install in your WordPress installation. It will disable the last password functionality.
    Disable Password Reset

400 Million Records in MySQL

So I’m trying to figure out a way to make searching a VARCHAR in MySQL “fast” when there are 400 million rows.
I tried the UNIQUE approach using alter table names add unique(name(15)); in the table but I have some duplicates apparently, so now I’m trying a different method.

I’m going to create multiple tables;  a-z, 0-9.

Based on the input query such as SELECT * FROM name WHERE name='rich' I’ll split that out and re-write the query such as SELECT * FROM r_name WHERE name='rich'.  r_name table is considerably smaller than the entire name table of 400 million rows.  I’ll just say 30 million.

Here’s my bash script to process the main plain text file that I’ll then create LOAD for in MySQL for each split file.

#!/bin/bash

# Split names.txt into a.txt, b.txt, c.txt etc.

for x in {a..z}
do
 echo Scanning $x
 grep -i ^$x names.txt >$x.txt
done
for x in {0..9}
do
 echo Scanning $x
 grep -i ^$x names.txt >$x.txt
done

echo.
echo Done

This is currently processing, so I’ll update when this is finished and see how much more optimized this will be.

Update

Well, crap.  I think I screwed up when I initially parsed out the main names.txt and tried to only grab unique lines.  I should have passed a case insensitive uniq command using uniq -i.

So now I’ll try doing that again and reloading the database.

Update 2

I reloaded the names database from text file.  Doing a create index idx_name on names(name(767)); changed a query execution time of select * from names where name='rich' from 12 minutes to 0.03 seconds.  I’m happy now. And really happy I don’t need to create a bunch of tables and add logic to some PHP/MySQL. Just goes to show I’m green behind the ears when it comes to database technology.

Note: Not quite 400 million after removing duplicates and invalid names from the file 😉

MariaDB [data001]> select max(id) from names;
+-----------+
| max(id)   |
+-----------+
| 321995408 |
+-----------+
1 row in set (0.00 sec)
MariaDB [data001]> select * from names where name='rich';
+----------+-------------+
| id       | name        |
+----------+-------------+
| 86382207 | rich        |
+----------+-------------+
1 row in set (0.00 sec)

A start job is running for dev-disk-by\uuid-

I recently used GParted to delete a Swap partition on my Linux server so I could extend my primary partition. In doing so, the UUID changed of the disk and during boot, I was presented with a message “A start job is running for dev-disk-by…” which takes 90 seconds to then boot.

To fix this, I needed to change the UUID in /etc/fstab of the Swap partition to match the newly recreated swap partition I made after extending my primary partition.

To get the UUID, I used blkid command:

I then modified /etc/fstab and replaced UUID= ID with the output of the swap ID above.

Before:

UUID=bb64a5ed-17d4-2a39-5371-982d3ee2267e none            swap    sw

After:

UUID=2078ee54-36e1-4a78-9867-798d3bb22673 none            swap    sw

I saved changes and rebooted. Now I have a boot time of less than 15 seconds.