diff options
author | Bradley Taunt <brad@serpapi.com> | 2024-06-13 14:57:38 -0400 |
---|---|---|
committer | Bradley Taunt <brad@serpapi.com> | 2024-06-13 14:57:38 -0400 |
commit | 26c7db12364e8eba08e2f8e85bb534ed735a0be8 (patch) | |
tree | 0e1d2f6e2456ca2266993eef72881057ee5b3dd9 /_posts | |
parent | a134c38317e808d6535af990cc505dab1bc7bbfe (diff) |
Major overhaul and cleanups
Diffstat (limited to '_posts')
4 files changed, 98 insertions, 51 deletions
diff --git a/_posts/2024-02-16-Website_Backups_with_Apple_iCloud.md b/_posts/2024-02-16-Website_Backups_with_Apple_iCloud.md index e8836e6..d736012 100644 --- a/_posts/2024-02-16-Website_Backups_with_Apple_iCloud.md +++ b/_posts/2024-02-16-Website_Backups_with_Apple_iCloud.md @@ -7,19 +7,25 @@ My main work machine, an M2 MacBook Air, meshes really well with my iPhone SE (t Recently I've been using iCloud as my "middle-man" backup system. I still have local, offline storage for most personal data but having additional off-site backups is never a bad thing. I make things easier for myself by taking advantage of `rsync`. You'll need to make sure you have that program installed before trying this yourself: - # This assumes you have homebrew installed first - brew install rsync +```sh +# This assumes you have homebrew installed first +brew install rsync +``` Then, whenever I feel like backing up an existing project or website I simply run: - rsync -a user_name@ssh.webserver.domain:/home/var/www/ /Users/username/Library/Mobile\ Documents/com\~apple\~CloudDocs/Backups/site-backup +```sh +rsync -a user_name@ssh.webserver.domain:/home/var/www/ /Users/username/Library/Mobile\ Documents/com\~apple\~CloudDocs/Backups/site-backup +``` > Note: The `-a` option tells `rsync` to sync directories recursively, transfer special and block devices, preserve symbolic links, modification times, groups, ownership, and permissions. The beautiful magic of `rsync`! Obviously, you'd want to properly name your directories (ie. `/Backups/site-backup`) for a cleaner structure and ensure that your iCloud directory is set correctly. (remember to read code before just copy-pasting!). With this approach you can backup entire server directories or be specific with each individual project folder. I would also recommend setting up some alias in your `.bashrc` or `.zshrc` etc. to make things more streamlined when running backups manually: - alias site-backup="rsync -a user_name@ssh.webserver.domain:/home/var/www/ /Users/username/Library/Mobile\ Documents/com\~apple\~CloudDocs/Backups/site-backup" - # Then you simply run the following for a manual backup: - site-backup +```sh +alias site-backup="rsync -a user_name@ssh.webserver.domain:/home/var/www/ /Users/username/Library/Mobile\ Documents/com\~apple\~CloudDocs/Backups/site-backup" +# Then you simply run the following for a manual backup: +site-backup +``` You can take this further by automating things via cron jobs, but for my use case that is a little overkill. Hopefully this helps anyone looking for a quick and dirty backup system, especially one that can piggyback of your existing iCloud that you might be paying for already. diff --git a/_posts/2024-02-23-Please_Make_Your_Table_Headings_Sticky.md b/_posts/2024-02-23-Please_Make_Your_Table_Headings_Sticky.md index c9005e4..6d71cb2 100644 --- a/_posts/2024-02-23-Please_Make_Your_Table_Headings_Sticky.md +++ b/_posts/2024-02-23-Please_Make_Your_Table_Headings_Sticky.md @@ -23,8 +23,10 @@ Your browser does not support the video tag. Pretty awesome, right? It might look like magic but it's actually very easy to implement. You only need to add 2 CSS properties on your `thead`: - position: sticky; - top: 0; +```css +position: sticky; +top: 0; +``` That's it! Best of all, `sticky` has [~96% global support](https://caniuse.com/?search=sticky) which means this isn't some "bleeding-edge" property and can safely support a ton of browsers. Not to mention the improved experience for your end-users! diff --git a/_posts/2024-05-27-Installing_WordPress_on_NearlyFreeSpeech.md b/_posts/2024-05-27-Installing_WordPress_on_NearlyFreeSpeech.md index 716a3c0..08b5c80 100644 --- a/_posts/2024-05-27-Installing_WordPress_on_NearlyFreeSpeech.md +++ b/_posts/2024-05-27-Installing_WordPress_on_NearlyFreeSpeech.md @@ -17,11 +17,15 @@ We will use the `wp-cli` that comes packaged with NearlyFreeSpeech (NFS): For help using WP-CLI from the SSH command line, use this command: - wp help +```sh +wp help +``` To download and unpack the latest version of WordPress, enter the following command: - wp core download +```sh +wp core download +``` ## Create a MySQL Process and Database @@ -52,8 +56,10 @@ Next, [create a new database](https://members.nearlyfreespeech.net/faq?q=CreateD 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 +```sh +wp core config --dbhost=example.db --dbname=exampledb --dbuser=exampledbuser --dbpass=dbpassword +chmod 644 wp-config.php +``` ## Run the WordPress Installation and Setting Permissions @@ -67,41 +73,50 @@ To get your permalinks to work properly, you must set up an .htaccess file. 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 +```sh +# This line is a shell command, not part of .htaccess! +cat >.htaccess <<NFSNRULES +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] +```sh +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 +```sh +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 +```sh +cd wp-content +mkdir -p uploads +chgrp -R web uploads +chmod -R 775 uploads +``` ## Keeping WordPress Up-To-Date Automatically via Command Line @@ -111,13 +126,17 @@ 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 +```sh +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 ); +```sh +define( 'AUTOMATIC_UPDATER_DISABLED', true ); +``` This disables the insecure automatic updater bundled with recent versions of WordPress. @@ -141,11 +160,15 @@ This is a two-step process. You must back up both the files and the database. 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 +```sh +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 . +```sh +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. @@ -155,11 +178,15 @@ Do not try to back up your WordPress folder into your WordPress folder, as that 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 +```sh +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 +```sh +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/_posts/2024-06-02-Building_rbenv_on_OpenBSD_7.5.md b/_posts/2024-06-02-Building_rbenv_on_OpenBSD_7.5.md index 08774af..1e6a9fb 100644 --- a/_posts/2024-06-02-Building_rbenv_on_OpenBSD_7.5.md +++ b/_posts/2024-06-02-Building_rbenv_on_OpenBSD_7.5.md @@ -17,33 +17,45 @@ First, be sure to install the required packages in order to build from source, a Add `rbenv` to your PATH and initialize it (place this inside your `.bashrc` or `.zshrc` etc): - export PATH="$HOME/.rbenv/bin:$PATH" - export PATH="$HOME/.rbenv/shims:$PATH" - export RUBY_CONFIGURE_OPTS="--with-openssl-dir=/usr/local" - eval "$(rbenv init -)" +```sh +export PATH="$HOME/.rbenv/bin:$PATH" +export PATH="$HOME/.rbenv/shims:$PATH" +export RUBY_CONFIGURE_OPTS="--with-openssl-dir=/usr/local" +eval "$(rbenv init -)" +``` Then reload your shell (zsh in this example): - source ~/.zshrc +```sh +source ~/.zshrc +``` Next we will need to install `ruby-build` as a `rbenv` plugin. Clone the ruby-build repository into the rbenv plugins directory: - git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build +```sh +git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build +``` ## Installing Ruby and Setting Our Version Now use `rbenv` to install the desired version of Ruby (we will get an older version for this example): - rbenv install 3.3.0 +```sh +rbenv install 3.3.0 +``` If you run into issues, you may need to specify your openssl directory: - RUBY_CONFIGURE_OPTS="--with-openssl-dir=/usr/local" rbenv install 3.3.0 +```sh +RUBY_CONFIGURE_OPTS="--with-openssl-dir=/usr/local" rbenv install 3.3.0 +``` If you're on a slower machine (like mine) this might take a little bit. Just grab a coffee or a snack while you wait! Then navigate to your project of choice and set the `local` Ruby version: - rbenv local 3.3.0 +```sh +rbenv local 3.3.0 +``` That's it! If you'd prefer to set this version of Ruby for all projects going forward, simply replace `local` with `global`. |