I got an email yesterday from my host (DigitalOcean) that I was running a phishing website. So, I’m not, but I quickly guessed what happened: my WordPress got hacked. This is just one of the risks of running silly little PHP apps. I logged in, deleted the themes directories, reinstalled clean ones, and ensured this doesn’t happen again by doing the following:
- useradd apache_ro
- chown -R apache_ro:apache_ro $WP/wp-content/themes
Now apache can’t write to those directories. This means you can’t update WordPress via the web UI, but I’m ok with that.
I manage a bunch of Postgres DBs and one of the things I almost always forget to do when setting up a new one is set the readahead up from the default of 256. I created this script and run it out of /etc/rc.local and sometimes cron it too. The 3 commands at the top are only really relevant on systems with “huge” memory – probably over 64 GB. We ran into some memory problems with CentOS 6 on a box with 128 GB ram which we ended up working around by reinstalling CentOS 5, but the
/sys/kernel/mm/redhat_transparent_hugepage/ options below should fix them in 6.x (though we haven’t actually tried it on that DB, we haven’t seen any problems in other large DBs).
echo no > /sys/kernel/mm/redhat_transparent_hugepage/khugepaged/defrag
echo never >/sys/kernel/mm/redhat_transparent_hugepage/defrag
echo 1 > /proc/sys/vm/dirty_background_ratio
BLOCK_DEVICES=`perl -ne 'chomp; my @a=split(/[s]+/); next unless $a; next if ($a =~ /sd[a-z]+[d]+/); print "$an";' /proc/partitions `
logger -t tune_blockdevs "Block devices matching: $BLOCK_DEVICES"
for DEV in $BLOCK_DEVICES; do
logger -t tune_blockdevs "Setting IO params for $DEV"
### Uncomment the below line if using SSD
# echo "noop" > /sys/block/$DEV/queue/scheduler
/sbin/blockdev --setra 65536 /dev/$DEV