Centos 6 patching bind for bind bug CVE-2015-5477

In order to patch centos 6 for bind bug CVE-2015-5477 it is necessary to use the CR (continuous release) repository as it is not available for 6.6 and will be released in 6.7 and thus must be installed as a hot fix.

To do this simple enable the CR repository

# yum install centos-release-cr

Then update bind

# yum update bind

For good measure restart bind

# service named restart

And then I suggest you remvoe the CR repository

# yum erase centos-release-cr

You can check which repositories are in use

# yum repolist

 

redirecting tcp traffic

Sometimes I see a transit issue on the internet which I can't fix as I don't have a contract with the particular company in question. Whilst I am waiting for it to be resolved I sometimes route traffic round the issue by bouncing it off another server in another part of the world.

So for instance if I wanted to send tcp traffic to a particular port from a server in say the UK to a server in Singapore when there is a traffic issue between them then I could bounce the traffic off a server I have in Japan using iptables.

SERVERIP="x.x.x.x"
DESTIP="y.y.y.y"
ORIGIP="z.z.z.z"
PORT="nnn"

iptables -F -t nat
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p tcp -s $ORIGIP -d $SERVERIP --dport $PORT -j DNAT --to-destination $DESTIP
iptables -A POSTROUTING -t nat -o eth0 -s $ORIGIP -d $DESTIP -j MASQUERADE
iptables -A POSTROUTING -t nat -o eth0 -s $DESTIP -d $ORIGIP -j MASQUERADE

Simply run the commands above on the server in Japan setting SERVERIP to the address of the server in Japan, DESTIP to the address of the server in Singapore and ORIGIP to the address of the server in the UK.

Once that's done send the traffic to SERVIP rather than DESTIP and it will be redirsted to DESTIP and appear to be from ORIGIP.

Bear in mind you won't be able to send traffic to SERVERIP on the port specified so it's probably not a good idea to redirect port 22!

resize an lvm partition on a vm guest

So you've order an upgrade to your virtual disk from your cloud provider and the virtual disk has been extended but df show it is still the same size.

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_test-lv_root
                       28G  1.4G   26G   6% /
tmpfs                 504M     0  504M   0% /dev/shm
/dev/sda1             477M   48M  404M  11% /boot

e2fsck won't work because it's mounted.

# e2fsck -f /dev/mapper/vg_test-lv_root
e2fsck 1.41.12 (17-May-2010)
/dev/mapper/vg_test-lv_root is mounted.
e2fsck: Cannot continue, aborting.

resize2fs says there is nothing to do!

# resize2fs /dev/mapper/vg_test-lv_root
resize2fs 1.41.12 (17-May-2010)
The filesystem is already 7473152 blocks long.  Nothing to do!

You need to extend the partition with lvextend....

# lvextend -l +100%FREE /dev/mapper/vg_test-lv_root
  Size of logical volume vg_test/lv_root changed from 28.51 GiB (7298 extents) to 78.51 GiB (20098 extents).
  Logical volume lv_root successfully resized

and then resize the file system....

# resize2fs -p /dev/mapper/vg_test-lv_root
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/mapper/vg_test-lv_root is mounted on /; on-line resizing required
old desc_blocks = 2, new_desc_blocks = 5
Performing an on-line resize of /dev/mapper/vg_test-lv_root to 20580352 (4k) blocks.
The filesystem on /dev/mapper/vg_test-lv_root is now 20580352 blocks long.

now you can see the space you have ordered!

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_test-lv_root
                       78G  1.4G   72G   2% /
tmpfs                 504M     0  504M   0% /dev/shm
/dev/sda1             477M   48M  404M  11% /boot

As always such operations carry a risk so take a backup or better still a snapshot and carry out at your own risk.

centos resolv.conf keeps getting overwritten

So if ever resolv.conf keeps getting overwritten when you boot linux you can tear your hair out trying to
work out why various web sites will tell you its NetworkManager (as does the file) or dhcpd or netctl.

Having ruled out all those, checked all sorts of boot scripts and even tried to use audit to find out what is changing the file check for /etc/resolv.conf.save. If it exists it will get copied to /etc/resolv.conf when the server boots.

remove /etc/resolv.conf.save and all should be well.