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
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.
This post isn’t designed to be a “how to” merely an overview of how I achieved the subject. It is possible to do this without any physical intervention but in practice I have had to visit site at least once to fix a boot error on every one I have done.
Disclaimer:- When attempting this having some sort of remote access solution that will give access to the server even when it won’t boot is desirable i.e. BMC, DRAC or KVM over IP. Obviously resizing and deleting partitions and file systems is very dangerous so you need to be ultra careful and ultra sure you understand the process and exactly what you are doing at each step. It may also be helpful to draw the partition layout at each stage so you have a clear view of what is happening. Don’t come crying to me when it all blows up in your face. You have been warned!
Continue reading Remotely upgrading a server from 32 to 64 bit linux