Accept "related" ("packet is starting a new connection, but is associated with an existing connection") and "established" ("packet is associated with a connection which has seen packets in both directions") packets:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
SSH; set port (XXXXX) to 22 if you're running the default, which you perhaps should not do as the script kiddies will not leave you alone. If this is changed to something non-default then do not forget to change the port in /etc/ssh/sshd_config (the Port configuration directive) and do these changes coordinatedly. Otherwise you will be locked out.
While looking for a virtualization solution in order to make computational matters more flexible, efficient and manageable (et cetera, et cetera) here at home, various offerings that are listed below were tested. To be honest, to say that I "tested" these would be twisting the truth quite a bit as the methodology used was not very scientific and things were guided more by hunch than strict reason. But then again as I would be the only one who would get hurt if things went horribly wrong it wouldn't really matter that much if the "wrong" solution was chosen. So far, after a few days, it's looking like the choice I made was right. The following took part in our non-scientific non-review:
At first Eucalyptus sounded like an awesome choise, given for example its Amazon EC2 API compatibility, but in practice it turned out that while the idea of having a private cloud at one's disposal is great, having this much flexibility brings with it a much higher level of complexity in managing the system, which pretty much makes the whole idea of having a cloud a moot point. And as I have just one host machine, running Eucalytus wasn't as straightforward as it could be. And also, what I'm really looking for is virtualization of a couple of servers that I like to have around, not a pool of cloud computing resources which can these days be bought at very reasonable rates (or for free, even) if needed. Nice offering, though, which I bet we will see gaining more and more ground in the future. Oddly, I'm unable to find a single service provider offering a service similar to EC2, but built on top of Eucalyptus. Perhaps the tools that would facilitate selling an Eucalyptus-based cloud service do not yet exist?
As for Parallels, I think it's debatable just how "bare metal" their hypervisor really is. It may be so that I have let myself be enchanted by marketers to believe that this bare metal thing is something radically different. The other possibility is that Parallels themselves are bending the meaning of the term here and are selling their system as "bare metal" when in fact it's not that bare. At least to me it looked like a full host operating system was installed and I can't see how this makes things that much different from having a regular server and running the hypervisor on it. Of course one difference is that you don't need for example a Windows server license to run the software but there's still a regular operating system involved that's running the show. Don't get me wrong, I use Parallels products almost on a daily basis (for example the illustration image on top, of the XenCenter management tool, is running on Windows XP installation inside a Parallels Desktop for Mac virtual machine) and I have nothing against them, it's just that this personal experience I have with their server offering wasn't that super. Their management tools are cross-platform (all three Windows, Mac, Linux) which is a plus but they want $500 for a license per server which I'm not going to pay them. Also, Parallels Server could be considered somewhat obscure in comparison to the others so this may very well turn out to not be a good choice in the long run.
VMWare's offer just wouldn't work for some reason, perhaps my hardware was somehow incompatible. Or something, I don't know. VMWare being such a traditional virtualization house, this would've been the "correct" choice in a similar way to "No manager ever got fired for buying IBM". But as no one was going to fire me for whatever choice I made here I gave up and moved on.
Last on the table was XenServer from Citrix. I went with the default installation and just used one whole disk and let the installer set things up the default way, i.e. a few gigabytes for all the Xen stuff and the rest for LVM storage. Like rest, the system can be managed from command line (local console or over SSH) but as my primary aim here is to get things done and having a point and click interface makes learning curve that much less steep, I went and installed the XenCenter management console on a Windows XP virtual machine (which was of course not hosted on this machine).
Making a paravirtual Ubuntu guest did not require any kind of wizardy, I just followed steps 3–5 in Installing Ubuntu Server 10.04 (32bit and 64bit) LTS (steps 1 and 2 were not necessary as the Ubuntu 10.04 64-bit template was already there after a fresh install). After I had one machine set up I turned that in to a virtual machine template and using this template it's super-fast to start new servers when needed. Also, these (para)virtual machines don't seem to be taking much of a performance hit and all and all I'm really pleased with the results.
The only thing missing here is lm-sensors or something similar so that I could at least see CPU and motherboard temperatures of a running system but I suppose this can be arranged.
Update: A Windows XP guest, with paravirtual device drivers, was also easy enough to install. And following the instructions in chapter 3.4. "Preparing to clone a Windows VM", working with Redmond is greatly simplified as an XP template can be prepared and new virtual machines invoked on demand and disposed of after use – this way one doesn't have to worry if for example installing a software package for testing purposes will mess the system up somehow.
