Tag: hosting

Posted on

Creating and renewing Let’s Encrypt SSL certificates with certbot

After purchasing SSL certs for many years for my personal project websites, I recently switched to creating free Let’s Encrypt certs using CertBot instead.

To install with python and pip on Debian based Linux, for nginx (from here):

Install deps and install:

sudo apt install python3 python3-dev python3-venv libaugeas-dev gcc
sudo python3 -m venv /opt/certbot/
sudo /opt/certbot/bin/pip install --upgrade pip

sudo /opt/certbot/bin/pip install certbot certbot-nginx
sudo ln -s /opt/certbot/bin/certbot /usr/local/bin/certbot

To generate certificate and renew manually (same command):

sudo certbot certonly -v --reinstall --webroot --webroot-path=/var/www/html/ --email your@email --agree-tos --no-eff-email -d your.domain.name

To view current status of your certificates:

certbot certificates

For websites not on the public internet where the validation step can’t use the webserver to host a validation file, certbot also can validate using a DNS record with a generated value – follow the prompts to use this approach:

certbot certonly --manual --preferred-challenges dns -d your.domain.name
Posted on

Resetting WordPress user passwords in the database

After restoring a backup mysqldump file from one server to another, I found that my WordPress user passwords were no longer working correctly, despite knowing I was using the correct password. Apparently because WordPress hashes passwords with md5 in the user table, it could be that attempting logon on another server the md5 hash was computing differently.\, The simple fix was to reset passwords in the wp_users table with a new hash, using:

update wp_users set user_pass = md5('NEW_PASSWORD') where user_login = 'USER-TO-UPDATE';

Posted on

WordPress 5.6 image upload error: not a valid JSON response

For larger image file uploads I’ve been getting this error recently:

Reducing the image file size and then retrying avoids the issue, but this adds additional steps.

Multiple posts online like this one suggest this is an error with the permalinks and resaving the current settings on that page in the Admin panel will fix the error, but this didn’t fix it for me.

Looking around in my server logs, I found this error in my /var/log/nginx/error.log:

2020/12/23 00:36:45 [error] 36#36: *311 client intended to send too large body: 4132609 bytes

This post suggests adding a client_max_body_size param in nginx.conf (or increasing the value already there). I added a larger value than the size in the error and this fixed the issue.

Posted on

nginx and php-fpm configuration errors

Moving an nginx install from Ubuntu 14.04 to 18.04 and upgrading to more recent versions of nginx, php, php-fpm, I ran into this error in my nginx config:

2020/02/28 04:45:47 [crit] 11784#11784: *1 connect() to unix:/var/run/php7.2-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 192.168.x.x, server: , request: "GET /index.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php7.2-fpm.sock:", host: "10.x.x.x"

The “No such file or directory” error is talking about the nginx connection to the php7.2-fpm.sock, rather than the file the GET request is for.

On closer look at where the .sock file is located, this was a subtle error to find and fix, but the fix was simple as I was pointing to the wrong path.

In my nginx default config, I had this line (migrating from a config for an older nginx and pphp-fpm version, this is where it was before):

fastcgi_pass unix:/var/run/php7.2-fpm.sock;

… I was missing a /php/ dir in the path, so changing to the correct path was the fix:

fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
Proudly powered by WordPress