Today is Doctor Who Day, the anniversary of the first ever episode of Doctor Who. And seeing as it’s also the day that my Reston Writers’ Review meets, I decided I should try my hand a fan fiction once again.
For 2020, I wanted to use the Sixth Doctor again only this time with his second companion, Melanie ‘Mel’ Bush, a software engineer—and in my story, a cyber-security expert. I teamed her up with Yasmin ‘Yaz’ Khan and the Thirteenth Doctor. And for fun, I had them fight Missy, with cameos from all the other Masters. Of course, I did need one final cameo to make the multi-Doctor story complete. I added the Doctor’s Granddaughter, Susan Campbell and her husband David as well.
But, let me be honest. The story was total rubbish. I rushed to write the whole thing on my phone on Sunday night just to get it uploaded in time, and like my feeble attempt at a Halloween story with only 101 words, it sunk like a lead balloon. I guess I’m just not on my writing A-game these days. I just need to find the time… does anyone have a TARDIS!
EDIT 2020-12-10: Forgot to post this on Doctor Who day. It was originally scheduled for posting on Monday, 23 November, 2020. Sorry for the delay.
I haven’t been able to use the TeslaCam since 27 July 2019. That’s because, around TeslaOS 2019.28.1, Tesla broke most USB Sticks used for Dashcam functionality, because, it claimed, they were too slow.
Not having a DashCam and having such a mysterious and incomprehensible error—my USB stick was fast enough—I was afraid to buy a new USB stick to see if I could get it working again. For months I dithered on the issue, totally unsure what Tesla wanted, and wanting so badly not to waste money on a device that would fail with Tesla.
Compound that with, in December, 2019, thanks to an AutoPilot, #CO2Fre failed to stop when a vehicle with California plates cut me off by jumping into the exit lane ahead of me at the last minute, causing $4,000 worth of damage I can’t remotely afford to pay. The scratches, therefore, remain to this day. And as no solace, I don’t even have the Dashcam video to go over the details even if I wanted to make an Insurance claim. So, I have scratches but still no Dashcam.
Then TeslaOS 2020.12.5 came out, which added support for watching Dashcam videos within #CO2Fre. Since I had the time off thanks to Covidapolis, I decided to try again with the Dashcam, and found this neat video:
I didn’t have access to my car because of the hypochondriac until the day of my #CO2Fredemo. I plugged in the SanDisk drive with its USB-C to USB-A adaptor and… nothing. I had the drive plugged in, but no camera was showing, and I couldn’t show off any of the Dashcam features during my entire presentation, including Dashcam footage of the speed test on the main screen after I parked, despite having the drive plugged in. The demo still went well, but I’m annoyed how hard I tried to get this working and still failed.
Afterwards, I tried to play around some more. Doing so requires me to go through decontamination because, for some reason, the hypochondriac thinks #CO2Fre has SARS-CoV-2. Meaning, I have to keep changing my clothes every time I go to the car because sitting in my car contaminates my clothes.
The drive was exFAT, so I reformatted it as FAT32. The drive did flash on the screen after some cord giggling, but it said it wasn’t formatted properly despite having the TeslaCam folder and being named TeslaCam. Since I’ve read that Tesla supports exFAT, I formatted it back as that, and it sits now, unable to connect.
I also tried my MicroSD chip with an adaptor. Originally, the chip was supposed to be part of the Raspberry Pi, but I wanted to test to see if it could be used as the TeslaCam directly. No dice. I’d hook up the Raspberry Pi and try with that, but I have to finish updating my Résumé and fix my broken Zone File updater for Reston Writers first. I just have too much going on to worry about going any further with this nightmare of Tesla‘s.
The way I see it, the drive works in a PC, the drive works in a Mac, it just doesn’t work in #CO2Fre. When you’ve tried everything else, the simple answer it so blame Tesla. So, I made a Mobile Service Request and they should be here Friday morning.
Why must Tesla make this so hard!?!?
In any case, unless I find another set of clothes to wear, even without my Dashcam, I shall very much miss cruising on a cloud.
Today, at Reston Writers Review, we had a major Zoom snafu. One of our writers was having a dickens of a time trying to communicate through the Zoom interface when we were reviewing her piece. We had a similar problem on Sunday with The Hourlings but were able to solve that with the person being reviewed just shutting off her video and only using the microphone.
Today, even that didn’t work. One member had to leave the meeting, the connection was so bad and even when the woman being reviewed turned off her video, her voice was still astoundingly choppy.
The only thing for it was to use the backdoor option provided by Zoom: the telephone interface. I hastily logged into the Zoom account provided to me, copied the full meeting info from the Zoom side—including the dial in numbers for connecting to Zoom on the telephone—and, finally, our author was back in the meeting.
Overall, it took about 10 minutes for us to fix all the difficulties listed above, but fortunately we only had five more folks who wanted to give their review, and we were still done by 21:00, our normal meeting end time.
All in all, it was a great and successful meeting despite the glitch. It’s more than likely Internet bandwidth is getting frayed due to an upswing in online meeting. But we adopted and adapted, and improved, just like the motto of the round table suggests.
Late last night, just as I completed my post about Tesla trying to scam me, I decided to upgrade WordPress to version 5.4. Normally, this shouldn’t be an issue, but for me, since I run a multisite system, there are extra security issues and directory layout complications that must be taken into account.
The first step was, apparently, to backup my database. Since I’ve never backed up the mysql database before, I felt this seemed like a reasonable approach. I certainly didn’t want to pay JetPack to do it; I’m a genuine code jockey, I can do my own backups. After some digging around, I found mysqldump. Unfortunately, all the instructions on how to use it were incorrect.
After some further poking around, I finally came across the correct syntax. Essentially, the user name and host have to come before the --all-databases command. Also, the host can’t be localhost, it must be the IP for the local host. Unfortunately, I was not able to find a way to get it to prompt for my password which meant I had to type my password in the command line, leaving all there in the open for any history recall to see. Not very secure at all.
mysqldump command; note <uid> and <pw> are placeholders for the user name and password; you must replace this with your own values.
Alas, I was not able to find a way to get mysqldump to prompt for a password. I think if I have more time, I may write a python script which builds the command by first prompting for the password. At least that way, the password wouldn’t be stored in the command line history.
The mysqldump command is quite clever. It just stores the list of sql commands that would be required to recreate the databases you have stored. However, the file is rather big and being text, it compresses nicely with bzip2 -9, which is what I did.
Once I did this, I was ready for the main Upgrade. I held my breath and pulled the trigger…
The install progressed along nicely until it tried to write a file to the wordpress directory. 🤦🏻♂️ I logged into my server and sure enough, the permissions on the wordpress directory were 755, which meant the user could add and remove files, but the group and anyone else could not. You see, with my multisite, I try to have all wordpress files with user wp-user and group as www-data, to work with apache. And apache runs all web processes as www-data for both user and group. Thus, when WordPress asked to add a file to its codebase, apache could not write it because the www-data group didn’t have permission, only wp-user did.
Change all the wordpress directors to allow www-data to add and remove files from them.
Realizing my mistake, I changed the permissions on all directories to be 775 (both wp-user and www-data could add and remove files). Unfortunately, it was too late. Instead, I had no choice but to blow away my current install and replace it with a fresh, new install of WordPress 5.4. At least, that’s what I did on a high level. The details, though, are a bit more complex.
Once I extracted all the wordpress files, I needed to get their ownership to match the settings for my wordpress install. I was able to do this quite easily with the chown command.
sudo chown -R wp-user:www-data wordpress/
Command to set the right file ownership for wordpress.
Next, I set the directories as above. Finally, the files themselves had to have the right permissions. Namely, they should be readable and writable by wp-user and the www-data group, but only readable to others, not writable. Namely, they needed to be set to permission 664.
Change all the wordpress files to allow www-data to modify them.
Next, I had to copy over the active wordpress configuration file. This file is actually fairly spartan as all the active site configurations are actually stored in /etc/wordpress; my wp-config.php actually just scans this directory for configurations. The configurations, in turn, point to directories in /srv/www/wp-content with the site-specific files. I thuns needed to bring that file over to the new install.
cp /usr/share/wordpress/wp-config.php wordpress
Copy the configuration to the new wordpress install.
Next, I wanted to preserve the Languages I had installed. I just copied the entire directory over to the local install.
Copy the Upgrades directory to the wordpress install.
Finally, I needed to move the links to my shared, dynamic contents that are for all the sites on my server. Specifically, the uploads, themes, and plugins folders all rest in /var/lib/wordpress/wp-content. (Technically, Uploads rests in blog.restonwriters.org site-specific Uploads directory, but that’s something I’ll fix later to conform with the same layout Themes and Plugins use.) Since these are already symbolic links, they can be moved to the new wordpress install directory to replace the defaults.
One caveat however, is the default install for wordpress comes with one plugin and three themes. In order to preserve those, I renamed the default plugins directory to plugins-default, and the default themes directory to themes-default. This was necessary before the symbolic links could be moved since those directories were in the way.
Move the symbolic links to the plugins, themes, and uploads directories.
Finally, the apache permissions file needed to be moved as it was also a link, pointing to /etc/wordpress/htaccess. I store the file there because it makes it easier to maintain in case I accidentally bow the .htaccess file away.
cp /usr/share/wordpress/.htaccess wordpress
Move the symbolic link to the .htaccess file.
Once all this is done, it’s a good idea to run the chown and chmod commands from above on the wordpress install directory once more to make sure the copied files and moved links are also properly attributed.
Finally, it was time to perform the brain transplant and move my staged wordpress install to the active /usr/share/ directory. I moved the current install to a temporary directory and then moved my staging install to the /usr/share/ directory to replace it.
Replace the installed wordpress with the new version.
Once all this was done, I was able to get to my web page, and wordpress prompted me to upgrade my database. Once this was done my sites were back online. In total, this site and its sister sites were down for a total of about forty-five minutes. It was a long day yesterday and I was exhausted but I did get it done and you can now see the results.
I hope you enjoyed my story about hacking UNIX. Please note, I am available for hire if you like what you see!
From about 2020-03-23T14:30:00Z (10:30 am, Monday) to about 2020-03-23T23:30:00Z (7:30 pm, Monday), Google was redirecting all my email and either bouncing it or deleting it.
Let me repeat, google deleted or bounced my email for Nine Hours, as a part of the setup of my setup for a paid Google Apps account. The setup for these accounts are a bit weird. They require you to create a new google entity with your own company URL. Fortunately, I have multiple domains I own and maintain, including this one, TimeHorse.com.
I probably should have used my writing group domain, RestonWriters.org. After all, the whole reason I wanted to get a paid Google account is because Meetup was moving to Online-Only meetings, following the outbreak of SARS-COV-2, and I needed a tool that allowed for video conferencing.
Skype was a non-starter. For one thing, it’s great for person-to-person communications, but for group chats, it has this annoying habit of muting everyone except the current speaker and you have to wait until that speaker stops to get a word in edgewise. My understanding is WhatsApp has the same problem.
Meetup actually suggested using Google Hangouts or Zoom. I happen to like Zoom. I use it for my regular NPVIC Grassroots strategy meetings and for Toastmasters and it’s always worked great. Zoom does support up to a hundred participants, both free and Pro. The only problem is, each of those Zoom sessions are either limited to the free forty-minute block or are using an up-to-24-hour Zoom Pro Account. Since most of my Meetups are at least an hour, breaking meeting up into forty-minute chunks would be tedious. And, at $14.99 a month, the professional account is well out of my price range.
Just before the first week of Virtual meetings began, my writing colleagues and I, including Elizabeth Hayes, who runs The Hourlings, tested both free Zoom and Google Hangout. Despite being limited to ten people, we decided on Google Hangout and I mapped it to our official Virtual Meeting URL.
Ten people worked fine for Reston Writers and for the Saturday Morning Review. The Saturday Morning Review actually worked out quite well because Meetup, despite suggesting we move to a virtual platform, still won’t let you delete the venue from your event and mark it as virtual, which, when editing events can cause some confusion. But when the Library cancelled all our events, I just deleted them all from the Meetup Calendar, and recreated them with no Venue and just announced them as occurring in Cyberspace.
Stay with me folks, I’m getting to the email…
As Sunday approached, I new ten participants wouldn’t be enough. Google Hangout would be fine for Bewie Bevy of Brainy Books and Saturday Morning Review, and likely The Science Book Club, as they all usually have fewer than ten participants for each meeting. The Hourlings, on the other hand, often had twelve, and sometimes as many as sixteen!
I new Zoom was $14.99 a month, but I read that Google App accounts could up the number of participants to twenty-five. Unfortunately my 2TB Google Drive account didn’t qualify. I had to get a Google Apps account.
And that’s where my troubles began.
At first, I could only sign up for the $12 per month account, even though I’d read it could be had for $6. Since the setup has a fortnight trial period, I didn’t worry about the financial discrepancy. I set up the account with my business email address for TimeHorse, LLC. I associated it with with that email, it connected to my Gandi Registrar, and my account was ready to go. I created a Google Hangout and assigned it to the Virtual Meeting URL, hoping it would allow twenty-five. The plan was to use it with the Hourlings to verify that fact.
It failed! We still could only get ten people into the meetup despite it being a paid account.
Unfortunately, since Monday I’ve been on Weather and Safety Leave from work because my Telework agreement was revoked, but that’s a story for another day as this post is long as it is! However, it did allow me to speak to Google and they suggested I try Google Meet. Meet was included with all Google App paid accounts, and it would allow for up to a hundred people and could be as long as I needed. Also, I could downgrade to the $6 per month account and I would still be able to use it. I thus downgraded.
We tried it with Reston Writers Review and it worked wonderfully. We had up to twelve connections simultaneously! But I’m getting ahead of myself.
At around 10:30 am, that Monday, after chatting with Google, I was examining my Google Apps account more closely. It was telling me I had one last step I needed to complete: integrate me email with Gmail.
That’s when my troubles began. You see, what this innocuous, turn-key step says it does is it says it sets up GMail for your company. What it actually does is obliterate all the MX Records (email routing information) of your DNS (Internet routing information) Zone File (routing configuration file) on Gandi and replace it with MX Records that point to Google. The setup wizard doesn’t actually tell you this and I’m totally oblivious.
At current writing, I have 188 forwarded email addresses set up on Gandi with their MX Servers. One of those is my business email, the one Google took over and is my Google Apps login. That’s the email google set up as the official email address used in GMail. Once the GMail setup goes through and I send an email from the GMail interface to my personal email address on the timehorse.com domain.
It never arrives. All day long, I watch my email and, strangely, nothing arrives after 10:30 in the morning. I refresh and refresh, and it’s still nothing. Where have all my emails gone?
It’s not until I’m setting up for Reston Writers that I decide to contact Google about this. I’m crazy-busy setting up the Google Meet, opening up the pieces we’d be reviewing on my computer, and, simultaneously, chatting with Google, trying to figure out why I’m not receiving any email.
Eventually, Google Tech Support starts talking about MX Records and a chill runs down my spine. As you probably gathered by now, I am well versed in DNS records and Zone File manipulation. I even have a Python script which updates my DNS A Record when the IP Address for this server changes.
With trepidation, I logged into my Gandi account and saw the damage. Google had modified my Zone file and added a bunch of strange new MX Records pointing to Google. They had nuked all my Gandi Email forward since they’d redirected all email traffic to google. As google only had one account registered on the domain, timehorse.com, namely my business email address, every other email address I possessed was either being deleted or bounced by google!
Fortunately, Gandi’s Email Forwarding page provides a warning when the Zone file doesn’t point to their email server, listing the correct MX Record settings to use Gandi as the mail hosting server. I quickly commented out the Google MX Records and pasted in the Gandi MX Records around 7:30 pm, in the middle of my Reston Writers meeting.
Needless to say, I was miffed that I could not give my full attention to my writers during our weekly writing gettogether. But it’s good I finally did figure out the disastrous actions committed by Google after only nine hours, and not a day or more.
I may never know what was contained in those nine hours of lost emails. I suppose there is one blessing, though. I get too much email already and still have dozens of unread messages I’m desperately trying to catch up on. One Covidapolis, novel-length email after another from every business under the sun. STFU companies, you’re all doing the same thing and I don’t like reading the same message again, and again, and again! You have a plan, that’s all I need to know!
Maybe Google was doing me a favor?
In the end, I was able to solve the problem because I got skills and I’m available for hire!