Category: Linux

IPv6 on RedHat linux

To setup IPv6 on a RedHat based operating system, follow below steps:

vi /etc/sysconfig/network-scripts/ifcfg-ethX

IPV6INIT=yes
IPV6ADDR=2a00:1630:1:13d::13d/56
IPV6_DEFAULTGW=2a00:1630:1:100::1

Restart the network, check if the default route is available:

ip -6 route

Should be something like:

default via 2a00:1630:1:100::1 dev eth2  metric 1  mtu 1500 advmss 1440 hoplimit 4294967295

Doing Simple Source Policy Routing on RedHat

I’m not for sure when they did it, but the RHEL folks made it a bunch easier to setup simple source policy routing. By using source policy routing, we fix the issue of firewalls freaking out when the reply packet to a host leaves a multihomed host on a different interface than what the request came in on. In prior versions, you had to setup some custom scripts, but that’s no longer the case – all the hooks are there in the OS now.

In this example, imagine a CentOS host with two nics. 192.168.0.2/24 is on eth0, and 10.0.0.2/24 is on eth1. The default gateway is set to 192.168.0.1. Any host accessing 10.0.0.2 from any subnet that isn’t on 10.0.0.0/24 will have it’s reply packets sent out via 192.168.0.1. Some firewalls drop this type of traffic *cough* Cisco ASA’s *cough*.

Thanks to the iproute2 package in Linux, this is easy enough to fix. RedHat has made it even easier now – we can do this in 3 steps (all performed as root):

Step 1: Create a table

We need to create a table for iproute2. Name it anything you want, and add it to /etc/iproute2/rt_tables, like so:

echo -e "200 SecondSubnet" >> /etc/iproute2/rt_tables

Step 2: Create a route

We need to create a route for eth1 that says to use our SecondSubnet table defined in Step 1.

echo "default table SecondSubnet via 10.0.0.1" > /etc/sysconfig/network-scripts/route-eth1

Step 3: Create a rule

We need to create a rule for eth1 that says to use our route above for traffic received on eth1.

echo "from 10.0.0.2 table SecondSubnet" > /etc/sysconfig/network-scripts/rule-eth1

Step 4: Restart networking

/etc/init.d/network restart

That’s it. Fire up a packet sniffer and verify your config!

Search and repair a broken ext4 superblock in CentOS

sudo fdisk -l

The above will list all the partitions on all the drives in your computer. To recover a lost partition, your going to need Testdisk. Testdisk is included in Parted Magic, and there’s a great guide on their site. For this though, we just need the partition number, such as /dev/sda3 or /dev/hdb1.

Now, make sure your superblock is the problem, by starting a filesystem check, replacing sdX with your partition name. Here, you can change ext4 to ext3, or ext2 to suit the filesystem.

sudo fsck.ext4 -v /dev/sdX

If your superblock is corrupt, the output will look like this

fsck /dev/sdb1
 fsck 1.41.4 (27-Jan-2009)
 e2fsck 1.41.4 (27-Jan-2009)
 fsck.ext4: Group descriptors look bad... trying backup blocks...
 fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a correct ext4
filesystem.  If the device is valid and it really contains an ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:

e2fsck -b 8193 <device>

Now lets find where your superblock backups are kept.

sudo mke2fs -n /dev/sdX

Down at the bottom of this output, should be a list of the backups

Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Your almost there. Finally, restore the superblock from the backup, again replacing the x’s with your partition name, and block_number with the first backup superblock.

Now reboot, and your superblock should be fixed. If it’s not, repeat the steps, but restore a different backup superblock :)