Automatically update CentOS 7 with yum-cron

  1. Install yum-cron:
    sudo yum -y install yum-cron
  2. Open /etc/yum/yum-cron.conf in your favorite editor and make sure each of the following values are set to ‘yes’.
    update_messages = yes
    download_updates = yes
    apply_updates = yes
  3. Other optional settings in yum-cron.conf
    # Change from 'default' to 'security'
    # if you only want security fixes.
    update_cmd = security
    # For email alerts (recommended):
    email_to = you@domain.com 
    # If you use a different mail host:
    email_host = smtp.domain.com
  4. Start the service:
    sudo systemctl start yum-cron
  5. Enable the service (makes sure it will start again after a reboot.)
    sudo systemctl enable yum-cron

Automatically Update WordPress, Themes, and Plugins using WP-CLI

WordPress is a hugely popular blog/CMS platform, but with widespread adoption comes risk: It is a common target for hackers, exploits, etc. Accordingly, you should make sure it gets regular updates.

WordPress has a built-in update mechanism but this also requires that its PHP files be writable by the web server, introducing a new set of security risks.

Luckily there is another option. Instead you can use a command-line tool called WP-CLI, which enables us to script WordPress updates.

These instructions will outline the steps necessary to install WP-CLI, create a script to update multiple sites at once, and install that script as a cron job to ensure updates happen on a regular schedule.


Before You Begin

As with any WordPress maintenance tasks, I recommend making regular backups of your database and files.

For this process to succeed, you’ll need to run your script as a user who has permission to modify the WordPress files. This could be your regular user account, but you might also want to create a dedicated user such with a name like ‘scripts’, and give it write permissions to your WordPress files. It is not recommended to run this as root.


  1. Install WP-CLI
    Install WP-CLI (adapted from http://wp-cli.org/#installing)

    curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
    chmod +x wp-cli.phar
    sudo mv wp-cli.phar /usr/local/bin/wp
  2. Test WP-CLI
    Run as a user who has write privileges to your WordPress site. If everything works you should get a series of “Success” messages, and/or a list of updated items.

    cd /var/www/html   # replace with path to your site 
    /usr/local/bin/wp core update
    /usr/local/bin/wp core update-db
    /usr/local/bin/wp theme update --all
    /usr/local/bin/wp plugin update --all
  3. Create an Update Script
    Use your favorite text editor to create a new shell script. In that script, put the following code:

    #!/bin/bash
    
    # Absolute paths of WordPress sites. Space-separated.
    sites="/var/www/html/site1 /var/www/html/site2 /var/www/html/site3"
    
    for site in $sites; do
    
    echo $site
    
    /usr/local/bin/wp core update --path=$site --quiet
    /usr/local/bin/wp core update-db --path=$site --quiet
    /usr/local/bin/wp theme update --all --path=$site --quiet
    /usr/local/bin/wp plugin update --all --path=$site --quiet
    
    done
  4. Make The Script Executable
    chmod 700 wp-update
  5. Test The Update Script
    ./wp-update

    If everything works you’ll see a series of “Success” messages, and/or a list of updated items. If you see errors, double-check that your current user has permission to write to the WordPress site directories.

  6. Install Cron Job
    Make sure you’re still logged in as a user who has write permissions for the WordPress site directories.

    crontab -e

    Now create a new cron entry like this one, including the correct path to your update script. In this example it will run every day at 2:30am.

    30 2 * * * /home/scripts/bin/wp-update

    Close and save your crontab file.

  7. If everything worked correctly, your WordPress sites will now auto-update every night.

Using SSH Keys for Passwordless Authentication

SSH keys can provide an additional layer of security (if you also disable password authentication on the server), or they can simplify the process of connecting to remote servers. For our purposes we’re interested in the latter – connecting to the server without entering a password.

The basic idea is that you create a public/private key pair on your computer, then upload the public key to the remote server. When you connect to the remote server, your computer can use the private key to authenticate instead of entering your password.

First we’ll create the key:

ssh-keygen -f ~/.ssh/id_rsa -N ""

If a key already exists, you’ll be asked if you want to overwrite it. If this happens you can respond by pressing “n” (no) and continue to the next step.

Next we need to upload the key to the server. Replace “user” with your username, and “host” with the address of the SSH server.

ssh-copy-id -i ~/.ssh/id_rsa user@host

If it worked, you should now be able to SSH to the remote host without entering your password.

File ownership considerations with Nginx and php-fpm

I recently switched my CentOS 7 web server over to Nginx and php-fpm.

From my experience with Apache I assumed that PHP scripts would be executed by the same user the web server is running as — ‘nginx’ in this case. But this could no longer be taken for granted since php-fpm is a separate process from the web server.

In my configuration php-fpm was actually running as the ‘apache’ user. This meant any files that need to be writable by PHP scripts should still be owned by that user or group rather than ‘nginx’.

A common scenario where this matters is if your users need to be able to install WordPress updates, Plugins, or Themes via the browser without entering additional credentials. In order for this to work, the web server (or in this case, php-fpm) must be able to write to the files in question.

If you are wrestling with file permissions, or are unsure of the correct permissions to set in this scenario, be sure to confirm which user and group are specified in /etc/php-fpm.d/www.conf

# grep "^user\|^group" /etc/php-fpm.d/www.conf 
user = apache
group = apache

Or you can check the actual running process with pstree:

$ pstree -ua | grep "nginx\|php"
  |-nginx
  |   |-nginx,nginx
  |   |-nginx,nginx
  |   |-nginx,nginx
  |   |-nginx,nginx
  |   |-nginx,nginx
  |   |-nginx,nginx
  |   |-nginx,nginx
  |   `-nginx,nginx
  |-php-fpm
  |   |-php-fpm,apache              
  |   |-php-fpm,apache              
  |   |-php-fpm,apache              
  |   |-php-fpm,apache              
  |   |-php-fpm,apache              
  |   |-php-fpm,apache              
  |   `-php-fpm,apache