Auto update wordpress plugins using WP-CLI

After installing Wordfence to all of my wordpress sites, I receive a dozen e-mails a day about plugins that should be updated. I don’t use many plugins, so usually I just go ahead and update them with wp-cli, because I feel they are safe to update. Main advantage of the wp-cli is that I don’t get http timeouts or stuff like that.

Updating all the plugins for multiple sites (I think I have about 10 of them) did become a repetitive task, so I wrote a little shell script for it. Of course you have to make sure that all the websites can be auto updated, or if there may be a plugin that will break after an update. So only use this if you are certain you just want to go ahead and take a little risk of breaking things.

I added an .auto-update file in each document root of the site I want to update automatically. I changed the owner permissions of .auto-update to root:webuser so that the webuser cannot remove this file, but still I can use this file to determine the owner of the wp-content folders. I need this to change the ownership back to the website owner after updating.

Very simple and easy script, but well, the stackoverflow generation (myself included) just loves to copy ans paste right? ;-)

I put this script in my /root folder with 700 permissions. I didn’t put this in a cronjob, I keep monitoring the e-mails that Wordfence sends me to see if I need to take action.

Fail2Ban on CentOs 6.6 with SELinux

So, I kind of manage a server for somebody else, running on CentOS and Plesk. Today I found out again why I hate this combo so much. The box auto-updates Plesk and other stuff, and all of the sudden my fail2ban wasn’t working anymore. I accidently found out because of all the password errors in de syslog.

Turns out there is a problem with SELinux. I have heard of that name before, but never knew what it was or what it did. Now I do, although I still don’t really understand. All I wanted was to get fail2ban running again.

So when you google for SELinux and fail2ban you get a lot of posts about this error. The suggestion I saw most was to run sudo /sbin/restorecon -v -R -F /sbin but for me this had no effect. The label was still bin_t after that.

Then I tried to create my own module. This didn’t succeed in the beginning, but after adding and adding stuff from the log, I finally got to the point where a restart of fail2ban didn’t give me errors. First I had to install audit2allow, because that wasn’t on my system.

Eventually, I came up with this. Save this under /root/myFail2ban.te :

Now, as root, compile this thing. Enter this while you are in /root:

make -f /usr/share/selinux/devel/Makefile

Output should be something like this:
[root@web ~]# make -f /usr/share/selinux/devel/Makefile
Compiling targeted myFail2ban module
/usr/bin/checkmodule:  loading policy configuration from tmp/myFail2ban.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 10) to tmp/myFail2ban.mod
Creating targeted myFail2ban.pp policy package
rm tmp/myFail2ban.mod.fc tmp/myFail2ban.mod

Now, enable the module:

semodule -i myFail2ban.pp

Restart fail2ban and check your fail2ban logs for errors, and your /var/log/audit/audit.log if ACL’s are still denied. This worked for me, with just the ssh jail active. Maybe if you enable other jails, extra acl’s are needed to those logfiles.

If it doesn’t work, you probably want to remove the module again. Just type:

semodule -r myFail2ban

You can list all active modules with semodule -l.

WP All Import cron from CLI (update)

My previous post about executing the WP All Import cron jobs with PHP cli didn’t work too well. Apparently the processing part still stops executing after a while. I ended up with import jobs stating “last activity 5 hours ago”.

Still I don’t want to run this through the webserver. So I wrote a little wrapper shell script to execute my imports in cron. It checks if the line “is not triggered” was partially returned. The wp cron script would return “<p>Import #26 is not triggered. Request skipped.</p>” if you execute the processing action without triggering it first. In other words: the import is really complete now.

I put the shell script outside my document root, and it uses the “logs” directory to store the log files. So make sure this directory is writable and points to the right path.

Now just put this in your /etc/cron.d/yoursite: