To manually run cron tasks you can use the run-parts command in Linux.
So to run your cron-weekly, for example, to test that a fix you just made runs without error (this is what I just did, in fact)
run-parts will run all the executables in a directory (you must point at the directory). So if you have several files in cron-weekly to run, you can’t just point to one of the files.
You may run into environmental differences running the script as a different user than the cron test runs at, so you can run as that user if needed. You need to be aware this is a quick and simple way of testing part of the process but it doesn’t do a perfect job of testing if it works as a cron task. But it will let you catch some failures quickly and fix them in time for the actual cron task to run. So do check that the everything works after the real cron job runs.
This is just the kind of thing I said I would put in this blog. Simple stuff but things I forget – so I put it here to remember and maybe help out others, like me, that need really basic tips.
If you have a cron task item (or have setup the whole task this way) that is just a script and you just want to test that 1 item you may run the script directly. For example (for a Linux shell script):
Sadly one of the hassles in managing your own WordPress blog is dealing with people that use your blog to serve spam content. These hacks can insert spam links into your pages and posts or create spam directories that are completely their own content on your domain.
There are many issues to deal with in re-establishing control of your server; but that isn’t the scope of this post.
This is just a tips if you are troubleshooting to try and determine what is going on. Often your server has been hacked to allow uploaded php pages to be added or for WordPress php files to be edited.
One way to track down if the files have been changed or new ones added is to compare the WordPress files on your server to the current files for a fresh WordPress install. This assumes your blog is using the current version, which hopefully it is because on the big improvement WordPress made is to make those updates automatic. That greatly reduces the chance to have WordPress be the vector to infecting your server. If you were using a older version then just compare to the field for that version from the WordPress server.
If you don’t have a current backup I would make a backup before I tried this. Obviously, don’t make any deletions or changes to your server unless you understand what you are doing. You can create big problems for yourself.
You can use the diff command to view the difference between WordPress on your sever and the fresh install from WordPress. I install the new WordPress in a new directory outside public_html. At the cli on a Ubuntu/Linux server:
I found rsync when I wanted to use scp to copy files to a server but not overwrite files already there. Rsync is actually more efficient no matter what (it seems) but it is really great if there are a bunch of duplicate files (Rsync will just skip them).
To copy files from your current computer to a server:
a = archive mode
z = compress file data
v = verbose
r = recurse through subdirectories and copy all of them
Compressing file data saves bandwidth so if that is an issue it is another big win over scp. And in my reading it seems rsync can restart a broken file transfer in process (while scp you have to redo the whole file transfer).
To copy from the server to your computer just reverse the order of the locations. And you can even just put in two addresses not on your current computer and copy between then.
As a reminder, I realize this blog is made up of stuff that is obvious to a large number of people. It is really aimed at me (so I can quickly find what I found before), and to a lessor extent others like me (who use cli some but are not system administrators or programmers to any significant extent).
Mod_Security is a web application firewall. I found a couple things to add to my servers.
The same site includes a very good guide to installing it (you also may well want to whitelist Googlebot, instructions in the link). However it blocked my access to one of my sites. You end up just getting the message:
You don’t have permission to access / on this server.”
on the bottom of modsecurity.conf which is found /etc/modsecurity (for me, on Ubunutu 12.04). Then restart Apache
[bash]sudo service apache2 restart[/bash]
and see if the problem goes away. If it does then you have a very good indication modsecurity was blocking access and can continue to narrow the scope of the problem by adding the WordPress whitelist rules in the link above.
Another note, service apache2 start, failed in a non-obvious way to me anyway. For me if I use sudo it works fine. If I don’t it gives odd errors which lead me on a 10 minute wild goose chase before remembering to try sudo.
For a Virtual Private Server (VPS) or any other web or other server you should have alerts sent by email for various things. So for example if you automate security updates for an Ubuntu web server you want to be notified if there is some issue with the automatic update.
In order to check and be sure email is setup and working on the sever there is simple command line code to use:
[bash]mail -s Test[/bash]
you then get a prompt to enter
To: [enter the email and press return]
Cc: [press return]
then a blank where you can type in any text you want in the body of the message.
Then you send the message with by pressing CTRL-d
If you don’t receive the email then you can troubleshoot what is going wrong.
A full update of all packages can be done using the follow, remember this may create some issues is one update makes something else you have no longer work properly. You should test to make sure things all work after the updates (for production systems obviously you should test things before [first updating the staging server to make sure the updates don’t cause any problems] and after the updates).
First update the local package index (to find what needs to be upgraded).
Host keys are used to security log into remote servers (such as Virtual Private Servers – VPS). With Ubuntu if you are using host keys to sign into servers securely and have asked for strict checking, if you make a change (such as rebuilding your VPS) the host key will change and you cannot login and will get a message like:
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Please contact your system administrator.
RSA host key for 188.8.131.52 has changed and you have requested strict checking.
Host key verification failed.
if that happens you need to remove your local host key. Then you can sign back in and you will be able to save a new copy of the host key. If you don’t know why the key has changed you should figure that out first as it maybe be an indication of an important security problem. To remove you local key, you can use ssh-keygen -R [ip address of server with the bad key] for example: ssh-keygen -R 184.108.40.206
Then when you try to sign in you will get
The authenticity of host '220.127.116.11 (18.104.22.168)' can't be established.
RSA key fingerprint is ed:...:ea.
Are you sure you want to continue connecting (yes/no)?
And if you know why (such as you made changes to the server) you can say yes and connect and save the new known host key.