Port over existing posts, wordpress directory in wiki

10 files changed, 242 insertions, 0 deletions

diff --git a/pages/wiki/wordpress/NearlyFreeSpeech_Setup.md b/pages/wiki/wordpress/NearlyFreeSpeech_Setup.md
new file mode 100644
index 0000000..aed4d68
--- /dev/null
+++ b/pages/wiki/wordpress/NearlyFreeSpeech_Setup.md
@@ -0,0 +1,156 @@
+## Installing WordPress on NearlyFreeSpeech
+
+### Download WordPress
+
+We will use the `wp-cli` that comes packaged with NearlyFreeSpeech (NFS):
+
+1. Connect to your site via SSH.
+2. Change to the directory you want to be the base of your blog (e.g. /home/public if WordPress will be running the whole site, or /home/public/blog if you want to share the site with other content).
+
+For help using WP-CLI from the SSH command line, use this command:
+
+    wp help
+
+To download and unpack the latest version of WordPress, enter the following command:
+
+    wp core download
+
+## Create a MySQL Process and Database
+
+Follow the instructions in the NearlyFreeSpeech.NET FAQ to [create a MySQL process](https://members.nearlyfreespeech.net/faq?q=MySQL#MySQL) if you haven't already.
+
+Next, [create a new database](https://members.nearlyfreespeech.net/faq?q=CreateDatabase#CreateDatabase) within that process. Note the name of the process and the name of the database.
+
+**Important**: Do not use your own MySQL credentials to connect WordPress to your database. Instead, create a new user. This will protect your member password in the event that your site becomes compromised.
+
+
+- Click on the [MySQL tab](https://members.nearlyfreespeech.net/mysql) in the member interface
+- Click "[Open phpMyAdmin](https://phpmyadmin.nearlyfreespeech.net/" in the Actions box.
+- Enter the DSN ("Server") of your MySQL Process, MySQL username, and MySQL password. The DSN and username can be found on the Process Information page in our member UI.
+- Click on the "Users" tab.
+- Click "Add user." (It's toward the bottom left of the page.)
+- Give the user a descriptive name. We'll use exampledbuser here, but you should pick something better, like wpuser or something representative of your blog.
+- Make sure to leave the Host: selectbox on "Any host."
+- Click the "Generate" link to generate a nice strong password.
+- Use cut and paste to copy the new password somewhere, you'll need it later. (We'll use dbpassword here.)
+- Grant the following permissions to the new user:
+    - All the permissions except "file" in the "data" box,
+    - Everything in the "structure" box, and
+    - "LOCK TABLES" in the "administration" box.
+- Click the "Go" button in the lower right.
+- Exit phpMyAdmin.
+
+## Generate a WordPress Configuration File
+
+At the SSH command line (replace the examples with the info for the database and user you created above):
+
+    wp core config --dbhost=example.db --dbname=exampledb --dbuser=exampledbuser --dbpass=dbpassword
+    chmod 644 wp-config.php
+
+## Run the WordPress Installation and Setting Permissions
+
+To get your permalinks to work properly, you must set up an .htaccess file. 
+
+
+1. Go to the Dashboard for your WordPress site. (e.g. https://www.example.com/wp-admin/index.php)
+2. In the navigation sidebar, find Settings and, under that, Permalinks.
+3. Select your preferred link style under "Common Settings." (We like "Day and name.")
+4. Scroll down and select the "Save Changes" button.
+
+Next, create an `.htaccess` file for your WordPress site. We suggest doing this directly from the SSH command line using the cat shell command:
+
+    cat >.htaccess <<NFSNRULES # This line is a shell command, not part of .htaccess!
+    RewriteEngine On
+    RewriteBase /
+    RewriteRule ^index\.php$ - [L]
+    RewriteCond %{REQUEST_FILENAME} !-f
+    RewriteCond %{REQUEST_FILENAME} !-d
+    RewriteRule . /index.php [L]
+    NFSNRULES
+
+If you prefer, you can copy-paste the text into an editor:
+
+    RewriteEngine On
+    RewriteBase /
+    RewriteRule ^index\.php$ - [L]
+    RewriteCond %{REQUEST_FILENAME} !-f
+    RewriteCond %{REQUEST_FILENAME} !-d
+    RewriteRule . /index.php [L]
+
+We need to run the following commands in order to install, uninstall, activate, and deactivate plugins/themes from within the admin web GUI of WordPress:
+
+    chgrp web .htaccess
+    chmod 664 .htaccess
+    chgrp -R web *
+    find . -type d -exec chmod 775 {} \;
+    find . -type f -exec chmod 664 {} \;
+    wp config set FS_METHOD direct
+
+## Enable File Uploading
+
+In your main WordPress installation folder enter the following SSH commands:
+
+    cd wp-content
+    mkdir -p uploads
+    chgrp -R web uploads
+    chmod -R 775 uploads
+
+## Keeping WordPress Up-To-Date Automatically via Command Line
+
+It is **critically** important to keep your WordPress installation up-to-date including, if applicable, your theme and plugins. PHP, WordPress, and WordPress themes and plugins all have a track record of security problems. Most of those get fixed quickly, but if you don't update, you don't get the fixes.
+
+To help you keep WordPress up-to-date, NFS provides a streamlined script.
+
+This command, which must be run from an interactive ssh session, will set up our system to check your WordPress install (and themes & plugins) for you every day, and update them automatically when needed:
+
+    wp-update.sh -a
+
+By default, it will tell you via email when updates happen. If you don't want that, just add `-q` (for "quiet") to the command. It will work silently unless there is an error.
+
+If you get errors from wp-cron (not wp-update) about failed automatic updates, you may also wish to add this to your wp-config.php file:
+
+    define( 'AUTOMATIC_UPDATER_DISABLED', true );
+
+This disables the insecure automatic updater bundled with recent versions of WordPress.
+
+**Do not attempt** to use WordPress's built-in ability to update itself through its admin panel. That insecure, outdated approach should not still exist. It does not work on NFS, which is a feature, not a bug. Getting it to work requires almost completely destroying your site's security, thereby ensuring that any undiscovered security flaw can enable hackers to completely obliterate your site. The update methods described here are faster, easier, and safer.
+
+## Logging In
+
+You should be able to navigate to `yourwebsite.com/wp-admin`, login and have everything work as expected. Congrats - enjoy your blog!
+
+Below you can find more advanced configuration to get the most out of your WordPress project.
+
+---
+
+## Backing up WordPress
+
+NFS recommends backing up your WordPress setup on a regular basis.
+
+This is a two-step process. You must back up both the files and the database.
+
+### Backing up WordPress Files
+
+To back up your WordPress files directly from a Unix-like system of your own, you can use a command like:
+
+    ssh yourmembername_siteshortname@ssh.phx.nearlyfreespeech.net tar -C /home/public -cvf - . | gzip >name-of-wordpress-backup.tar.gz
+
+To back up WordPress to a file on our system that you can transfer via SFTP to your own computer, you can use a command like:
+
+    tar -C /home/public -cvzf /home/tmp/name-of-wordpress-backup.tar.gz .
+
+This assumes that your WordPress install is in the default location (`/home/public`). It will put your backup file in your `/home/tmp` directory.
+
+Do not try to back up your WordPress folder into your WordPress folder, as that occasionally results in attempts to use infinite disk space by trying to back up the backup of the backup of the backup of the...
+
+### Backing up the WordPress Database
+
+If you have a Unix-like system of your own (e.g. macOS or Linux), you can do the backup directly from there using your local command prompt using the MySQL username and password you created for WordPress:
+
+    ssh yourmembername_siteshortname@ssh.phx.nearlyfreespeech.net wp db export - | gzip >wordpress-backup.sql.gz
+
+Or you can do it from the SSH command line via WP-CLI:
+
+    wp db export /home/tmp/wordpress-backup.sql
+
+The `wordpress-backup.sql` file this generates will be stored in your site's `/home/tmp` directory. Download it from there to have a local copy.
diff --git a/pages/wiki/wordpress/database_update.md b/pages/wiki/wordpress/database_update.md
new file mode 100644
index 0000000..67d4b7b
--- /dev/null
+++ b/pages/wiki/wordpress/database_update.md
@@ -0,0 +1,21 @@
+# WordPress Database Update
+
+The following page contains a collection of scripts to update WordPress for numerous things.
+
+## Updating the URL of the Database
+
+    -- Replace in wp_options table
+    UPDATE wp_options SET option_value = REPLACE(option_value, 'example.com', 'example2.com') WHERE option_name = 'home' OR option_name = 'siteurl';
+
+    -- Replace in wp_posts table
+    UPDATE wp_posts SET post_content = REPLACE(post_content, 'example.com', 'example2.com');
+    UPDATE wp_posts SET guid = REPLACE(guid, 'example.com', 'example2.com');
+
+    -- Replace in wp_postmeta table
+    UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'example.com', 'example2.com');
+
+    -- Replace in wp_usermeta table
+    UPDATE wp_usermeta SET meta_value = REPLACE(meta_value, 'example.com', 'example2.com');
+
+    -- Replace in wp_users table
+    UPDATE wp_users SET user_url = REPLACE(user_url, 'example.com', 'example2.com');
diff --git a/posts/Fixing_Jekyll__39__s_dart-sass_Dependency_on_OpenBSD.mdwn b/posts/Fixing_Jekyll__39__s_dart-sass_Dependency_on_OpenBSD.mdwn
new file mode 100644
index 0000000..b6e862f
--- /dev/null
+++ b/posts/Fixing_Jekyll__39__s_dart-sass_Dependency_on_OpenBSD.mdwn
@@ -0,0 +1,15 @@
+# Fixing Jekyll's dart-sass Dependency on OpenBSD
+
+2024-06-30
+
+I recently wrote about [working with multiple Ruby versions on OpenBSD](https://btxx.org/posts/Building_rbenv_on_OpenBSD_7.5/) which still works just fine, but I noticed a bug when trying to build a couple of my Jekyll projects locally:
+
+    NotImplementedError: dart-sass for x86_64-openbsd7.5
+
+For reference, these projects are being built with Ruby 3.3.0 against Jekyll 4.3.3. After doing some research, I came across this ticket that was somewhat buried in the search results: [https://github.com/jekyll/jekyll/issues/9493](https://github.com/jekyll/jekyll/issues/9493)
+
+The issue *seems* to be caused by the lack of the `dart-sass` gem in OpenBSD. Luckily there is a fairly easy fix - we just need to hard-set the `jekyll-sass-converter` version in our `Gemfile`:
+
+    gem 'jekyll-sass-converter', '~> 2.2'
+
+After making this change and running `bundle install` again, my Jekyll projects started building (and serving) perfectly! Hopefully this helps others trying to build their own Jekyll projects on OpenBSD.
diff --git a/posts/x220-dual-boot.md b/posts/x220-dual-boot.md
new file mode 100644
index 0000000..291e1d7
--- /dev/null
+++ b/posts/x220-dual-boot.md
@@ -0,0 +1,50 @@
+Dual Booting OpenBSD and Alpine Linux on a X220 ThinkPad
+
+2024-07-10
+
+I've always found it useful to run both OpenBSD and some form of Linux variation on my personal machines. Most times, I would default to running one OS on bare metal, while the other would simply live in a VM. This works *okay* but I prefer my operating systems having a "hardware separator" - if that makes sense? So, I set off to start dual booting both OpenBSD and Alpine Linux on my X220 ThinkPad.
+
+I should mention that I planned to write this blog post a couple weeks ago, but the original Dogfish mSATA SSD I ordered wasn't compatible with my X220 (even though they say it is supported...). Luckily, I found a replacement drive in one of my "computer parts" drawer. Hoarding tech always prevails!
+
+<figure>
+  <img src="/public/images/dual-boot-2.jpeg" alt="The inside of my X220, showing the Dogfish mSATA drive in place.">
+  <figcaption>The original Dogfish mSATA slotted in the X220. Too bad it didn't work...</figcaption>
+</figure>
+
+I came across my old Raspberry Pi 400, which I previously [wrote about when stuffing an SSD inside it](/posts/pi-400-internal-ssd/), and proceeded to gut the drive. It's a cheap KingSpec SSD with a whopping 64GB of storage space. But that didn't matter since the plan was to install the wonderfully small Alpine Linux. 64 GB would be plenty of space for us!
+
+## Getting Started
+
+I already had the Alpine Linux ISO installed on a random thumb drive, so that made things quicker right off the bat. The next step was opening up my X220 and slotting in the very tiny mSATA.
+
+This introduced the first minor issue: the drive was too small. I could have looked into something more "professional-looking" in order to seat the drive properly but I decided to *stick* with electrical tape. Get it?... After applying the tape I closed the machine back up.
+
+<figure>
+  <img src="/public/images/dual-boot-3.jpeg" alt="The inside of my X220, showing the KingSpec mSATA drive in place with electrical tape.">
+  <figcaption>The KingSpec mSATA slotted in the X220 and secured with top-of-the-line electrical tape...</figcaption>
+</figure>
+
+## Installing Alpine Linux
+
+Next, I needed to tell the BIOS to boot into my thumb drive containing the Alpine ISO. Once the proper order was set, I rebooted the machine and ran through the standard Alpine installer. No problems to report there.
+
+<figure>
+  <img src="/public/images/dual-boot-4.jpeg" alt="My X220 booting into the Alpine ISO thumb drive">
+  <figcaption>My X220 booting into the Alpine ISO thumb drive</figcaption>
+</figure>
+
+<figure>
+  <img src="/public/images/dual-boot-5.jpeg" alt="The Alpine Linux installer showing both disk options for installation destination">
+  <figcaption>The Alpine Linux installer showing both disk options for installation destination. SDA is currently running OpenBSD.</figcaption>
+</figure>
+
+Once that was done, I rebooted the machine, being sure to remove the thumb drive and set the BIOS order to point to the new mSATA disk. Then I ran through my personal [Alpine Suck installer](https://git.sr.ht/~bt/alpine-suck-installer) to get my go-to applications installed alongside my `dwm` desktop environment. Again, no problems to report during this process.
+
+<figure>
+  <img src="/public/images/dual-boot-6.jpeg" alt="Alpine Linux running the dwm desktop environment on my X220">
+  <figcaption>Alpine Linux running my personal `dwm` setup. Absolutely beautiful.</figcaption>
+</figure>
+
+## Extras?
+
+That's really it. Nothing super interesting to report, but that seems to be the running theme with these older ThinkPad machines: they were built for tinkering and taking apart regularly. If I was less lazy, I could look into setting up a boot loader to avoid swapping between disks via BIOS settings, but for my use case this setup works fine. Now I have the power of OpenBSD *and* Linux on my personal machine!
diff --git a/public/images/dual-boot-1.jpeg b/public/images/dual-boot-1.jpeg
new file mode 100644
index 0000000..85ea897
--- /dev/null
+++ b/public/images/dual-boot-1.jpeg
diff --git a/public/images/dual-boot-2.jpeg b/public/images/dual-boot-2.jpeg
new file mode 100644
index 0000000..add74be
--- /dev/null
+++ b/public/images/dual-boot-2.jpeg
diff --git a/public/images/dual-boot-3.jpeg b/public/images/dual-boot-3.jpeg
new file mode 100644
index 0000000..fd0e6ed
--- /dev/null
+++ b/public/images/dual-boot-3.jpeg
diff --git a/public/images/dual-boot-4.jpeg b/public/images/dual-boot-4.jpeg
new file mode 100644
index 0000000..02bbd7e
--- /dev/null
+++ b/public/images/dual-boot-4.jpeg
diff --git a/public/images/dual-boot-5.jpeg b/public/images/dual-boot-5.jpeg
new file mode 100644
index 0000000..2f053e4
--- /dev/null
+++ b/public/images/dual-boot-5.jpeg
diff --git a/public/images/dual-boot-6.jpeg b/public/images/dual-boot-6.jpeg
new file mode 100644
index 0000000..0ee6205
--- /dev/null
+++ b/public/images/dual-boot-6.jpeg