Change in IPTables: state vs conntrack

A quick one so as not to lose the rhythm :) it appears that the state match in iptables has been deprecated in favor of conntrack.

A quick sed on your firewall script should suffice:

s/-m state --state/-m conntrack --ctstate/g

To Hell and Back Again (or "How to update an old Gentoo without reinstalling")

Recently (ok, not recently, it was 5 months ago) I decided to set up a dedicated server. The hosting company stated that Gentoo was one of the distros which the server could be delivered with, so of course I chose that one. The server itself is not a big deal, but the catch is that the hosting company provides a symmetric, uncapped, unmetered 100mbps link for the server (the uncapped part comes with a little increase in price, as do additional public IPs, should you need them), which is a connection I can absolutely not get in my country. So, great, right? After paying the first bill I was handed a precious server connected to the Internet like if it was hooked up on the thing itself, carrying a precious Gentoo system in its womb.

NO

I log in to the server, start digging around and I notice something odd. Hmmm eselect does not work, eix reports very old versions (>4 years old) of the packages installed. So right then I remember that a friend a couple of weeks ago had told me that there was a time (ages past) when the eix-update command was actually update-eix. Shuddering, I type it and, like the worst of my nightmares coming true, I see that command exists. A quick cat /usr/portage/metadata/timestamp.chk confirms it: last portage sync was ON 2008.

Desperately, I check the kernel version: 3.2. Ok so... wait, wha? 3.2? Yes. The kernel is 3.2, some custom crappy, hosting-company-provided kernel based on 3.2 mainline, sitting atop a userspace from... 2008. The server does not have the udev support we know and love. It even has CONFIG_IDE enabled. While I start tearing my brains, my eyes and my common sense out, I ask the hosting company to see if they have an updated Gentoo version to plant on the server. The obvious reply was that no, that they work with what the master company provides ("master company" in this case being the company who actually owns the datacenter(s)). So I had to make a choice: either install some RHEL or Debian-based distro or stick to this mutant and bring it up to date (you already know what I did).

What followed was partly documented (since in the rush, sadly some of the details were lost) in a file called gentoo.hell. The name could not be farther from the truth. I have tried to keep my notes as useful as possible, so here follows more or less what you should do/take into account should you ever come upon a similar situation:

• python, failed modules: when compiling Python and/or Python extensions, you may get a message for "failed modules". Check for similar packages (e.g. dbm -> gdbm) and recompile those first (follow logical order)
• gcc/glibc: this is the hardest part to pull off. The server had gcc-3.4 and an according glibc version. This of course limits you on what you can install as part of the upgrade process. However, you cannot upgrade both freely to the latest available version since they are circularily-dependent. The upgrade path that should work is: gcc-4.1 --> glibc-2.10 -->gcc-4.5 --> glibc-2.14 (this upgrade path should merge gcc-4.5 on its own when installing glibc-2.10). Take care of portage tree versions which have the ebuilds you need.
• portage/python: under NO CIRCUMSTANCES should you upgrade portage tree right away! You will lose important ebuilds that are needed for this particular upgrade path and will have to dig around the Gentoo CVS in order to get those, which can be a real PITA. Upgrade path for this is more or less as follows: portage-2.1.6 --> python-2.7 (maybe use 2.6 first if you cannot compile/install 2.7) --> portage-2.2
• automake and related failures: make sure latest automake point release versions for each slot are installed. Also make sure latest automake-wrapper is installed.
• ssmtp, groupadd error ('r'): update shadow
• bash errors: may need updating too before some other things

Remember:

• gentoolkit/portage-utils are your friends
• Remember to run python-updater when updating Python versions. Same goes for perl-updater.
• Save all the eselect news and keep them in mind for later use
• stage4: as much as you can get of those (squashfs is the best). This will allow you to set "savepoints" to which you can always roll back if you're stuck.

There it goes, more or less. It was the most epic learning opportunity I ever had regarding GNU/Linux and Gentoo. However, beforehand, think twice if you really want to do this ;).

NOTE: no kittens were harmed during the upgrade of the beast. At least not by me.

KVM + network bridging

Recently I discovered the joy of having a CPU with VT extensions and using KVM thru libvirt. One of the not-soy-joyful things is that libvirt does not support creating a bridged environment for you (much as VMWare/VirtualBox do). After migrating my windows vbox VM to KVM I started hating NAT networking (my KVM host is behind an iptables gateway, so I had to choose between two iptables on my network, or tunneling via SSH. Of course I chose the later).

So after some digging I finally configured my KVM environment using network bridging. Here are the simple steps.

NOTE: libvirt creates a virbr0 bridge for you, under which all vnet* ifaces will reside if using NAT. Under no circumstances should you add eth0 to this bridge. Doing so will leave you with no network connection.

1. Create a new bridge:
   # brctl addbr br0
2. Add your physical interface to the bridge (eth0 in this example):
   # brctl addif br0 eth0
3. Create initscript:
   # ln -s /etc/init.d/net.lo /etc/init.d/net.br0
4. Modify /etc/conf.d/net accordingly (sample extract below):
   

   modules="dhclient"
   bridge_br0="eth0"
   config_br0="dhcp"
   config_eth0="null"
   

5. Correct rc:
   # rc-update del eth0 [runlevel]
   # rc-update add br0 boot
6. Either reboot or:
   # /etc/init.d/net.eth0 stop
   # /etc/init.d/net.br0 start

You could perform step 6 concatenated inside a screen so if everything works correctly, your network will come back up normally.

As a last step, inside your KVM VMs, go to networking and choose "Specify shared device name" under "Source device" and enter "br0" in the text box.

It may take your VMs a couple of reboots to load successfully with the new IP (you'll note the VM was loaded fine because the IP of its network card will be one in the range of your network, not in a NAT range).

Using vpnc with iptables

Another quick one after all this time.

If you use a vpn like vpnc (Cisco VPN) and also iptables on a gateway server, and you are having trouble and/or would like to make the vpn available to your private network, don't forget to include this on your iptables script:

(replace "tun0" with however your tunnel device is named)

iptables -A FORWARD -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE