So, I have been using LXC to host my server services for a period of time, with a view to keeping things portable should I need to change provider. It’s very good in that it’s integrated into the Linux kernel and in Ubuntu at least it’s not too difficult to setup, however there are a number of problems with it.
First and foremost, every time the container operating system upgrades anything to do with init scripts, it won’t boot any more, so you are forced to hold back packages with varying amounts of success. Secondly, there does seem to be some overhead running things in an LXC container, and thirdly it isn’t as portable as it could be i.e. there is no live migration. and you will have to change config files if you move hoster to reflect you new IP address.
As I’m not selling containers as VPS, I only need to run 1 server instance, and therefore don’t really need containerisation at all, enter schroot. Schroot is like chroot without the hassle and with added flexibility, in a nutshell it will mount and start everything correctly for you to the point where you can automate startup and running of services in the chroot, it doesn’t suffer from init script borkage since the init system isn’t used at all, and it’s more portable as networking is irrelevant to a chroot (it simply uses the hosts networking).
Ok so where to start, well if you are already using LXC you can use the directory your container is stored in. I opted to move mine to a sane location before starting, in the interests of convention and easy administration. So, I created a “schroot” directory in the /home directory i.e.
Continue reading Using schroot instead of LXC containers
I came across recently, as you do, an option to maximise the performance of my lowly OCZ Core V2 SSD in Ubuntu. Apparently the kernel goes to quite extreme lengths (in terms of using CPU cycles) to avoid doing seeks. With a “standard” hard drive this is desirable because the time it takes the head to move to the correct location is more costly. Seeking is irrelevant as far as an SSD is concerned and using extra CPU time only serves to reduce I/O performance. Happily there is an option to tell the kernel that you are using a non-rotational media for a specific drive designation i.e. sda, sdb, etc. and therefore maximise SSD performance.
Continue reading Improve response in Ubuntu Desktop
Today’s post is definitely of the short and sweet variety. I happened across the file list for iptables the other day and noticed a binary I had not come across before “iptables-apply”. Iptables-apply is a script that applies firewall rules and then waits a configurable amount of time, for user input, to confirm the changes were successful. In other words if you aren’t a perfect admin (who is right!) and manage to accidentally lock yourself out by putting an iptables rule in wrong, iptables-apply will automatically revert back to the previous set of rules and you’ll get access again.
Could’ve saved me literally some diesel over the past few years that one!
From the iptables-apply man page:
iptables-apply will try to apply a new ruleset (as output by
iptables-save/read by iptables-restore) to iptables, then prompt the
user whether the changes are okay. If the new ruleset cut the existing
connection, the user will not be able to answer affirmatively. In this
case, the script rolls back to the previous ruleset after the timeout
expired. The timeout can be set with -t.
This has the advantage over Shorewall in that Shorewall will only keep existing connections open when new rules are applied. If you happen to lose connectivity, tough luck, Shorewall will obediently block further connections on your borked firewall.
I have spent literally hours over the last year or two searching for an elegant way to remove configuration files left over from package installs, in a command line environment, with Ubuntu.
Googling would provide a frustrating list of solutions that would either involve installing extra packages, using a complicated command line, or script, solutions that I would never be happy with and would “redo” the search again, each time I wanted to perform the same task, in the hope of finding something better.
In the end Aptitude and Xargs were my friends. Without further ado ….
Continue reading Remove residual config files in Ubuntu – A one liner
I have long been an avid user of the well known interface to iptables – Shorewall. Of late though I have suspected it is slowing my network down. I once decided to see what actual iptables rules it was creating and ran “iptables -L”. There was a lot of output and I wasn’t sure was all of it necessary. It niggled away at the back of my brain for the last few months, and I decided yesterday it was time to do something about it.
I first looked at another “user-friendly” interface that would perhaps give me more control and proper ipv6 support, so I installed Firewall Builder. However it seemed quite complex and after spending some time trying to get to grips with the interface I decided it would be easier to type the rules in manually and anyway that would be the only way I was 100% sure everything in there was needed.
I familiarised myself with the Packet Filtering HOWTO and thought the easiest thing to do would be use “iptables-save” to copy the existing Shorewall rules into an iptables friendly format. The resultant file was 9k long and appeared to have a lot of user defined chains for no good reason. It also didn’t make good use of the multi-port option for tcp connections and therefore there were dozens of rules where there only needed to be one.
Continue reading The importance of a minimal firewall.