Category: WordPress

How to use Lightsail snapshots to revert to a previous version

I have the new Bitnami WordPress multisite web server up and running. I’d like to make a backup of it, prior to mucking with it, so that I can revert back if needed.

Schrodinger’s Backups: The condition of any backup is unknown until a restore is attempted.

Murphy’s take on Schrodinger’s Backups: You’re fucked. The backup is dead.

Well, that is often the case when you just lost the computer, and you now need to restore from your “backups”.

Let’s see what it takes to successfully take a Lightsail snapshot and restore to it.

Technically, you spin up a new instance, move the IP address, and delete the old instance. So you will be incurring a little bit more extra charges with Lightsail, because for a little while, you had two instances. Snapshots cost money, too.

Step the first: shut down your instance.

In theory, this step should not be necessary. The snapshot process should work on the running image. It probably will.

In theory, there is no difference between theory and practice. In practice, there is.

Although it is a remote chance, there is a problem of database coherency. What if, at the exact moment you take a snapshot, some database transaction is only half-posted? What if one half of the transaction is written to disk, then the snapshot happens, then the other half of the transaction gets written to disk? When you restore, the database is going to no longer be coherent.

For some databases, there are a whole subset of features and work done to ensure atomic transactions that prevent any piece of the transaction of being committed until all of it can be verified to be done. That’s all nice and everything, but what’s wrong with just shutting down the server? If your server is so mission critical that you cannot have a minute or two of downtime, you should be working on clusters of machines that can announce themselves into the cluster, and announce themselves out of the cluster and gracefully transition between states.

Power down the server, and the server is quiescent with the world.

Step the second: take the snapshot.

A picture being worth a thousand words, here’s thirteen thousand words:

Go to the snapshot manager tab a click the Create snapshot button
Lightsail picked a name for you; click the Create button to launch the snapshot process
This takes a minute or three
Once the snapshot is complete, you get the raindrops menu button

Step the third: the snapshot becomes the machine.

The raindrops menu has the option to create a new instance from the snapshot

See that big orange Create Instance button? Click it!

I may be a stockholder of Amazon.com stock, and will see revenue slightly rise as you invoke an additional charge on your account. Click it!
Now there are two instances; one pending, and the other stopped

Eventually, the new instance is running. But we still need to move off of the old instance.

The static IP address that DNS points to is connected to the server that crashed and is going away
The new instance, WordPress_Multisite-2, has a random IP address assigned during creation
After selecting the static IP from the list, click the green Checkmark button to assign it to the new instance
We now see the new instance in the wild, at the old IP address DNS points to
Delete the old instance, so as to not leave trash laying around

That’s pretty much it. The snapshot has been launched as a new instance, and is almost a verbatim copy of the old instance. Almost.

When the new instance was spun up, it got a new security certificate fingerprint.

Bitnami WordPress Multisite – DNS spoofing

In an earlier post, I said I hope you have pointed your domain name at your static IP address. Well, what if you don’t want to?

The point being that the DNS entry for the domain name currently points to the production WordPress site, and really, I would like to set up this multisite WordPress installation without having to change the public DNS entry.

Also, setting up this, my personal blog, I was using No-IP DNS services. I could update the DNS entry for gerisch.org, and the DNS replicated out almost instantly. It was great. But the other web site I’m working on (the one that got me into WordPress at all), is using Network Solutions for their DNS. They take their good sweet time replicating DNS entries out to the world. I don’t really want to post an update to DNS, wait, dink around with the new site while the production site is down, decide to revert to production, post an update to DNS, wait again while Network Solutions gets around to pointing everyone back to the production web site.

It would just be better if the new web server machine never got away from it’s own self when doing lookups for the domain name it will eventually be.

So I can start the WordPress install from the IP address of the server out on the public Internet. However, WordPress during it’s install, is going to do a DNS lookup, and try to invoke code on the server where the DNS really does resolve. Which isn’t where I am. So I’m going to try to install a fake DNS server on the new server, and have it redirect all calls to the old domain to the new server.

Step the first: install dnsmasq

sudo apt-get install dnsmasq

Next, set up listening on the local host address:

sudo vim /etc/dnsmasq.conf

Find your way to the line #listen-address= and edit it thus:

listen-address=www.gerisch.org

And save and exit

sudo vim /etc/dhcp/dhclient.conf

Find your way to #prepend domain-name-servers www.gerisch.org; and uncomment this line. Save and exit.

And now it gets weird.

The Bitnami / AWS Lightsail images use something called cloud-init : https://cloudinit.readthedocs.io/en/latest/topics/modules.html

So if you were going to try to edit /etc/hosts or /etc/resolv.conf you get warned to not edit them by hand, because they will be replaced on next boot. But they sure as heck don’t tell you where to implement edits. Just don’t do it here.

Turns out there are template files in /etc/cloud/templates that hold the magic.

cd /etc/cloud/templates
sudo cp hosts.debian.tmpl hosts.debian.tmpl.original
sudo vim hosts.debian.tmpl

Now I’m going add a line below www.gerisch.org localhost which will be the IP address I want this machine to go to whenever it tries to resolve the domain name of the production web site

And indeed, if I use dig from an ssh session in the machine, dig reports back the local machine’s address, not the one out on the public Internet

WordPress super admin – three tables to update

I recently did a migration from a single site to a multisite here in WordPress. It was painful. But I did learn how to change the super admin login name.

The three tables are: wp_users, wp_usermeta, and wp_sitemeta

Upon creation of a brand-spanking-new WordPress multisite, wp_users has but one record in it. ID = 1, which is the super admin user. I changed the user_login field (and other fields) to the login name I wanted. WordPress “knew” that this did not qualify me to be a network admin, so it would present me with only the one site.

A little bit of searching told me that I needed to make sure that in table wp_usermeta, the field wp_capabilities was correct. Well, it was. But there were other parts of my login name that I wanted to update here. So I suppose that technically, only two fields must be updated, to swap out the super admin login name.

The last piece, that was not easy to find, was that the table wp_sitemeta has a field: site_admins which needs to have a PHP array entry in it. There was an entry in it already, but, it listed the default login ID, not the one I wanted to log in as. Because it’s an array, there is an index number, and a string length, that precede the actual data in quotes.

Once both wp_sitemeta:site_admins and wp_users:user_login both linked up, then I could log in with my preferred login ID and be super admin.

Bitnami WordPress multisite installation

Make an ssh connection in to your Bitnami server installation. I’m using AWS, and they had instructions for me to get the password / ssh private key. ssh bitnami@your-ip-address-here

cat bitnami_application_password

While logged in to the ssh session, execute the Bitnami configuration script that assigns a domain name to your WordPress multisite server.

cd /opt/bitnami/apps/wordpress

sudo ./bnconfig --machine_hostname your-domain-name-here.tld

sudo mv bnconfig bnconfig.disabled

First, we changed to the directory with the bnconfig script. Then we ran it, with the machine_hostname option. (I wanted to put a dash in there, between machine and hostname, but it’s an underscore). Lastly, we moved the bnconfig script out of the way. This is because if the server rebooted, and bnconfig did run, it would be as if it ran bnconfig –machine_hostname your-ip-address-here.xip.io

xip.io is a Bitnami thing, I guess.

Hopefully, you already have the domain name, and have pointed it at the static IP address of your server.

On to configuring WordPress the familiar way: point your favorite browser at the ip address and go to https://your-domain-name-here/wp-admin

This redirected me, but really it was the same as going to https://your-ip-address-here.xip.io/wp-login.php

Log in as user with the password from bitnami_application_password

Upon logging in, the administration page looks almost the same as a regular WordPress installation. However, in the upper left corner, there is now a menu named “My Sites”. Hanging off of it is “Network Admin”

Hanging off of “Network Admin” are a whole bunch more sub-menu items, but I’m going to ignore those for the moment.

Clicking on “Network Admin” actually takes me to the first sub-menu item: “Dashboard”

And here, I had made my life more complicated. I’m actually trying to move this site, gerisch.org to the multisite, under the same domain name. Tell me “good luck with that.” Part of the multisite login process is to redirect to the domain name – which is the production server on some other IP address.

I’m going to have to go into DNS, and point the gerisch.org at the multisite IP address, before I can successfully log in (and remain logged in) to the multisite server still being set up.

Of course, I’m going to have to export this (the production site) to a file, for importing later, prior to taking it’s presence off teh interwebs.

And I don’t know if there is going to be any weird http://www.gerisch.org versus http://gerisch.org versus https://

Yeah, “stuff” in the databases that will need to be cleaned out during export, for import later.

Super WordPress Day – Meetup Fresno – 2019-09-24

Phil Derksen: Plugins you should install on every WordPress site

Akismet Anti-Spam

Backups:

  • BackWPup
  • UpdraftPlus
  • VaultPress (JetPack)
  • BackupBuddy
  • BlogVault

SEO

  • Yoast SEO
  • All in One SEO Pack
  • The SEO Framework
  • Broken Link Checker (resource intensive; run manually after changes)

Forms

  • Gravity Forms (long history of the product)
  • Ninja Forms
  • WPForms
  • Formidable
  • Contact Form 7 (very popular and free, but older and takes more work / detailed to implement)

Email – don’t skip this step

  • WP Mail SMTP
  • Easy WP SMTP
  • Service-specific (Postmark, Mandrill, Sendgrid)

Site Migration

  • WP Migrate DB
  • Duplicator
  • (most backup plugins)

What do Phil’s co-workers say?

  • User Switching – see what logged in users see.
  • Regenerate Thumbnails – change your theme or thumbnail size? This does the work.
  • Public Post Preview
  • Duplicate Post
  • Plugin Toggle
  • Editorial Calendar – Calendar view of past and future posts 😉

Community says

  • Simple Links – will randomize a list of links
  • WP Simple Pay – uses Stripe and other payment processors
  • Woo Commerce – manage inventory for physical sales, among other things
  • Event Espresso – booking
  • Sugar Calendar – booking

Generate WP for plugin development – generatewp.com

Matt Reeves: WordPress Customizer

The customizer does do instant WYSIWYG – which is better than before.

While inside the customizer, you can change the device type: full PC web site, tablet, and smartphone.

Kirki Theme Customizer; but can be temperamental re: the themes it works with.

Elementor is a theme builder that Matt has started using, that he actually admires the power in it.

WordPress multisite and Let's Encrypt certificates for multiple sites

I’m using the Bitnami images for my WordPress installations, and am very happy with them. However, it got a little weird when I added a new site to my WordPress multisite instance.

The secret was to run a few commands by hand:

sudo /opt/bitnami/ctlscript.sh stop apache
sudo /opt/bitnami/letsencrypt/lego  --path="/opt/bitnami/letsencrypt/" --email="david@some-domain-name-i-am-not-publishing-here" --domains="gerisch.org" --domains="www.gerisch.org" --domains="test.gerisch.org" --http run
sudo /opt/bitnami/ctlscript.sh start apache

Earlier, I had run the Bitnami bncert-tool which wrangled my Apache configuration so that all attempts to go to an http:// address were re-written to go to an https:// address. This is very good. But when I added the test.gerisch.org web site, the certificate provided by Let’s Encrypt did not have a SAN (Subject Alternative Name) entry for “test”. So trying to visit that site got the ominous “this site is insecure – nothing provides for an SSL certificate for it”. True enough.

By running the /opt/bitnami/letsencrypt/lego script with multiple –domains arguments, I could update the requested certificate to have the additional SANs I wanted. Very nice. It was the Bitnami community support web site that gave me this information. The same page warns me that more than five requests for new certificates puts the certificate issuer into a time-out corner for one week. So that is something to be aware of.

All-in-One WP Migration prior to being crippled by it's authors

Newer versions of the WordPress plugin All-in-One WP Migration have been re-written to refuse to work if the migration file is larger than 512MB. The plugin has been deliberately crippled to induce you to pay for an upgrade that unlocks larger file sizes.

One thing that is (in my opinion) a little sleazy is that the export function will create and download any size file you have. It’s only after you need to import that you get mugged for the upgrade.

The nice lady at https://marionblackonline.com/all-in-one-wp-migration-plugin-hack/ showed how to get the old version of the All-in-One WP Migration plugin. Version 6.77, although it has the artificial limit, can be edited to a different limit. Getting the file is slightly opaque, as the plugin page on wordpress.org does not let you go back that far, version -wise. But the file is on the servers, and downloadable.

https://downloads.wordpress.org/plugin/all-in-one-wp-migration.6.77.zip

Once you’ve installed it (by uploading it from a .zip file instead of from the WordPress Plugins store), WordPress will constantly nag you to update to the crippled version. Edit the file wp-content/plugins/all-in-one-wp-migration/all-in-one-wp-migration.php and change the Version string to an impossibly high number.

As long as you are editing files, you might as well edit wp-content/plugins/all-in-one-wp-migration/constants.php

Original file size limit: 

define( 'AI1W†M_MAX_FILE_SIZE', 2 << 28 );

Make it your preferred file size limit:

define( 'AI1WM_MAX_FILE_SIZE', 4294967296 ); // 4 GB file size limit

Bitnami WordPress automatic start of services

First off, KVM and QEMU are wonders of technology, and I’m thankful for those projects and their magic.

Background is that I made a default install of OpenSUSE 42.3.  I also tried OpenSUSE 15 (which is newer than 42.3, but whatever).

OpenSUSE 15 really did not like the Bitnami invocation of MySQL; but, it could be that I tried the initial install as a LAMP server, running at level 3.  With OpenSUSE 42.3, I tried an initial install as a KDE Desktop running at level 5, plus the LAMP server pattern.  That had worked in the past, so I wasn’t going to fight “well, at least this works”.

I did get the Bitnami stack installed and running.  I even got the default URL changed from “/wordpress/” to just “/”

Next step to accomplish, so I have a nice snapshot to revert to, is for the Bitnami stack to automatically start.  For whatever reason, searching for this information never easily comes up with results.  So I’m writing it down here.

cp installdir/ctlscript.sh /etc/init.d/bitnami-APPNAME

Edit the file /etc/init.d/bitnami-whatever-you-named-it

Add this near the top:

#
# chkconfig: 2345 80 30
# description: Bitnami services

And run this:

chkconfig --add bitnami-whatever-you-named-it

Test with an init 6, and if you can get to your web site without having to start MySQL and Apache with the ctlscript.sh, then you’re good.

Take that snapshot!

How I moved a local development Bitnami WordPress to the root of the web server

What it took to move WordPress from /wordpress to just /

Turns out it was not as easy as I first thought.

First, let’s define the environment:

  • OpenSUSE 42.3 in a virtual machine
  • Downloaded and copied into the machine:
    • bitnami-wordpress-4.9.8-0-linux-x64-installer.run
  • KVM / QEMU with sudo virsh snapshot-create-as every step of the way.

I should point out that during the install, it asked me where to put the web site.  I told it /opt/bitnami

So actually, the WordPress code is in /opt/bitnami/apps/wordpress

Note that this is for the files on disk; it has nothing to do with the URL scheme.

The installer does it’s thing, and I get a WordPress site running on the URL scheme <ip address>/wordpress/

Irritation for me is, the production web site I’m wanting to experiment for is <ip address>/

Five changes are needed for the fix.

  • Search and replace the database
  • Edit the /opt/bitnami/apps/wordpress/conf/httpd-prefix.conf file
  • Edit the /opt/bitnami/apps/wordpress/htdocs/wp-config.php file
  • Edit the /opt/bitnami/apps/wordpress/conf/httpd-app.conf file
  • Settings –> Permalinks –> Save Changes

Search and replace the database

Before, I was using the All-In-One WP Migration plugin, because it came with the Bitnami image, and, at a WordPress meetup I went to, the people there said this was a great way of doing a development site.  And it was, for a while.

Problem is, the All-In-One WP Migration guy decided to change the rules, and the latest update refuses to work unless you pay up, for any site larger than 40MB.  I’ve never seen a site less than 200MB, so that’s a no-go for me.

I’ve been using UpdraftPlus for backups (for free), and decided that it wouldn’t hurt to pay them for some of their premium services, which were advertised as also being able to do migration.  Turns out that isn’t nearly as easy as it was with All-In-One WP Migration, but it can be wrestled to the ground and made to work, with a bit of effort.

Anyway: Settings –> UpdraftPlus Backup –> Advanced Tools –> Search / replace database.  Search for /wordpress and replace with /

Note that you do not want to restart services after the search-and-replace but before the file editing below.

Edit httpd-prefix.conf

The httpd-prefix.conf file is explained here: Move WordPress to a different URL path on the same domain

The change is that the Alias setting goes from /wordpress/ to simply /

Edit wp-config.php

The wp-config.php file gets edits, so that

define(‘WP_SITEURL’, ‘http://’ . $_SERVER[‘HTTP_HOST’] . ‘/wordpress/‘);
define(‘WP_HOME’, ‘http://’ . $_SERVER[‘HTTP_HOST’] . ‘/wordpress‘);

define(‘WP_SITEURL’, ‘http://’ . $_SERVER[‘HTTP_HOST’] . ‘/‘);
define(‘WP_HOME’, ‘http://’ . $_SERVER[‘HTTP_HOST’] . ‘/‘);

Edit httpd-app.conf

The httpd-app.conf file gets edits, so that

RewriteBase /wordpress/
RewriteRule . /wordpress/index.php [L]

RewriteBase /
RewriteRule . /index.php [L]

Save Permalinks

One thing I learned during this whole ordeal, is that the Save Permalinks action creates a new .htaccess file for you, which I needed before the root /wordpress/ URL would go away.

Gotcha’s

One thing that caused me quite a bit of trouble is that just doing the edits of the files was not enough; but I didn’t know that.  After doing the edits of the files (only), the WordPress Admin site worked fine.  But every attempt to go to any of the content resulted in a 500 internal server error.

By the way, the WordPress community and debugging tools truly suck to help one figure out what’s wrong here.  But that’s a rant for a different post.

So I thought my migrations were failing because I couldn’t get to my content after migration.  But really, because I had a default-out-of-the-box installation, I never tried to check the First Post comment or any of the other links.  I made the changes to httpd-prefix.conf and wp-config.php and the Admin site worked fine.  After the restore, I could log in to the Admin site (with the password from the production site), and that worked fine.

But my content was always broken, and I didn’t know it until I stripped down everything back to the most rudimentry snapshot I took before I edited anything.