How to protect your CentOS server from the Shellshock exploit

Shellshock is quite a serious security hole found a couple of days ago in Bash; to check whether your CentOS server is vulnerable run the following in a terminal:
env VAR='() { :;}; echo Shellshock vulnerable!' bash -c "echo Bash Testing"
If your system is vulnerable, you will see:
Shellshock vulnerable! Bash testing
If it is not vulnerable, you will see:
bash: warning: VAR: ignoring function definition attempt bash: error importing function definition for `VAR’ Bash testing
If you are vulnerable, you can update bash by running the following:
sudo yum update bash
Once the update has finished, run the code to check your vulnerability again and it should be sorted.



How to cache yum repositories on CentOS using apt-cacher-ng on Debian or Ubuntu

  If you have a lot of virtual (or real) machines running Debian or Ubuntu and a limited internet connection, it can make a lot of sense to use apt-cacher-ng to create a local cache of the packages you use so that they are only downloaded once. The current version of apt-cacher-ng can also help out with yum repositories!   On CentOS, edit /etc/yum.conf and add:  
proxy=http://[ip-of-your-local-apt-cacher-ng-server]:3142
  If you have changed the default port of apt-cacher-ng from 3142, you will need to modify that. Our example file:  
[main] cachedir=/var/cache/yum/$basearch/$releasever keepcache=0 debuglevel=2 logfile=/var/log/yum.log exactarch=1 obsoletes=1 gpgcheck=1 plugins=1 installonly_limit=5 bugtracker_url=http://bugs.centos.org/set_project.php?project_id=16&ref=http://bugs.centos.org/bug_report_page.php?category=yum distroverpkg=centos-release proxy=http://10.1.1.12:3142 #  This is the default, if you make this bigger yum won’t see if the metadata # is newer on the remote and so you’ll “gain” the bandwidth of not having to # download the new metadata and “pay” for it by yum not having correct # information. #  It is esp. important, to have correct metadata, for distributions like # Fedora which don’t keep old packages around. If you don’t like this checking # interupting your command line usage, it’s much better to have something # manually check the metadata once an hour (yum-updatesd will do this). # metadata_expire=90m # PUT YOUR REPOS HERE OR IN separate files named file.repo # in /etc/yum.repos.d
  As you can see, our local apt-cacher-ng VM is 10.1.1.12.   Run yum update and check your apt-cacher-ng’s cache – you should now see some CentOS respositories cached there.

Rsync error when connecting to CentOS: rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]

  We helped rebuild a backup VM which receives data over rsync today; the first rsync attempt failed with the vague error message:  
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]
  The problem ended up being that the rsync package was not installed. A simple:  
yum install rsync -y
  …fixed the problem and shortly the backups were back to normal.

New CentOS WordPress install: Error 500

  Was asked to troubleshoot a client’s installation technique for WordPress on CentOS 6.x yesterday; they were receiving an Error 500 when they tried to access index.php for the first time. Checking the Apache logs showed:  
SoftException in Application.cpp:431: Mismatch between target GID (522) and GID (65531) of file “/home/andrea/public_html/index.php” Premature end of script headers: index.php
  What was happening was that the client was un-tarballing the latest.tar.gz file as root and then changing the ownership of the file with the following:  
chown -R [user] *
  Changing that command to:  
chown -R [user]:[usergroup] *  
e.g. here:  
chown -R andrea:andrea *
  fixed that error. By not specifying the new group there was an ownership mismatch where the system expected one group but got another. There are many  causes for an Error 500 – it’s a good habit to check the Apache logs first for pointers as to where to start troubleshooting.

How to find number of cores in Ubuntu (or other versions of Linux)?

  If you’re using a virtual server (whether online or your own physical machine) it can be handy sometimes to check how many CPU cores are available; here are two easy methods of doing this. The first:  
nproc
  This will return a single number, whether it be 1, 2, 4 or otherwise. For a more detailed look, try:  
lscpu
  This will usually give a more complex readout, e.g.:  
[email protected] [/]# lscpu Architecture:          x86_64 CPU op-mode(s):        32-bit, 64-bit Byte Order:            Little Endian CPU(s):                1 On-line CPU(s) list:   0 Thread(s) per core:    1 Core(s) per socket:    1 CPU socket(s):         1 NUMA node(s):          1 Vendor ID:             GenuineIntel CPU family:            6 Model:                 45 Stepping:              7 CPU MHz:               2000.024 BogoMIPS:              4000.04 Hypervisor vendor:     Xen Virtualization type:   para L1d cache:             32K L1i cache:             32K L2 cache:              256K L3 cache:              15360K NUMA node0 CPU(s):     0