Noted for future reference (by me): How to reset the MySQL root password in Ubuntu 18.04

As a bleeding-edge early adopter, here in June 2018 I am already using Ubuntu 18.04 LTS for new sites I’m setting up for clients. (How daring!)

I ran aground this afternoon with a new server setup, because I couldn’t log into phpMyAdmin as root (or, therefore, as anyone, since I hadn’t set up my own user yet).

All of the old familiar ways I had been trying, and the tutorials I had referred to for at least the past two years, were not working. So then I specifically searched for a solution for Ubuntu 18.04 and found this excellent tutorial.

First off, mysql_secure_installation wasn’t working. That was one of the “old familiar ways” I had already tried thrice. THRICE I TELL YOU!

The key, I think, was these two unexpected lines:

$ sudo mkdir -p /var/run/mysqld
$ sudo chown mysql:mysql /var/run/mysqld

Because that folder didn’t exist and/or didn’t have the proper permissions, some other steps were failing silently or giving error messages that failed to point me in the direction of the actual problem.

The other thing to note is that with the version of MySQL included in Ubuntu 18.04, these are the proper MySQL commands to run:

USE mysql;
UPDATE user SET authentication_string=PASSWORD("") WHERE User='root';
UPDATE user SET plugin="mysql_native_password" WHERE User='root';

And it is actually important to run both of those UPDATE commands, because in the tutorial the results displayed show that the first one updated a record for them, while the second didn’t. I had already run the first command (but not the second) in one of my failed updates. So when I ran these, the first one didn’t update any records and the second one did.

Yes, Virginia, there really is a difference between null and false

Fairly often, it’s necessary in PHP programming to write your code around the fact that, most of the time, PHP does not distinguish between null, false and 0, although there is, nonetheless, a distinction between all three.

Today I ran into one of the few instances where I was expecting PHP to treat them as equivalent, but it did not.

Often I am working with arrays, and I write conditionals that should only execute if there are elements in the array. Technically the proper check for the status of an array-type variable is the is_array() function, but most of the time I don’t use that. I may have initialized the array variable or not, but that’s irrelevant to me; what I care about is whether there’s anything in the array, so I just use count() instead.

These days I’m working on some object-oriented code, and I’ve been writing several “get” methods that return either an array of data or, as I had originally written them, a false value if no matching data exists.

Fine. But then I applied some of this new OO code to an existing page, and found that one of my count()-based conditionals was evaluating incorrectly. I checked the variable, whose value was set by one of the object methods, and as anticipated, its value was false. But strangely, the count() function was returning 1 rather than 0 when applied to the variable.

I resisted my initial temptation to switch from count() to is_array() because I don’t want to have to change every place where I use it. Then I tried changing the “failed” return value of the method from false to null and, what do you know, it worked!

So now I’ve gone through all of my various “get” methods and, on failure, they’re returning null instead of false.

What the bell…?

OK, I had several ideas for the title of this entry, all of them lame. The one I chose was no more or less lame than the others. Anyway…

We spent last night at a hotel in Baltimore. A convention happened to be going on at the hotel. A convention the likes of which I had never even imagined could exist.

It was Bells Galore in Baltimore! This was the 2006 convention of the American Bell Association. Yes, bells. These people collect bells. They talk about bells. They dream about bells. And they most certainly ring bells. Throughout the afternoon and evening, the sound of ringing bells could occasionally be heard wafting through the halls.

Now, the range of ages in attendance spanned from teenagers upward, but I would have to guess that the median was somewhere around 83. And it just so happens that the East Coast has been hammered for the past several days with heavy rains from a stalled front. Last night the rain was particularly heavy, and around 10 PM the power in the hotel went out. It was rather odd, since all of the adjacent buildings, including a large mall across the street, still had power. Luckily, it was late enough that we just decided to go to bed, but around a half hour later, the fire alarms started going off. Disturbingly, the hotel had no emergency lights, so the hallways were completely dark. Several of us illumated our own path with our cell phones. (Ah, the wonders of the modern age.)

Well, halfway down the stairs we were met by the hotel manager, who informed us that there was not an emergency and we did not need to evacuate; the alarms were simply malfunctioning due to the power outage. Of course, the hotel was filled with octagenarians; not the best time for such a fandango. So a while later the fire department arrived (formalities), and they had to go door to door knocking and asking if anyone needed medical assistance.

Fortunately we didn’t, although the fire alarms continued to sound about every 10 minutes for the next half hour or so, spaced out just perfectly to wake up our 3-month-old daughter each time just as she was falling asleep.