My Projects: prologue

I'm going to begin a series of posts aimed to create some kind of portfolio of projects in which I was involved.

I'm not sure there is a dedicated target of this action, but this will be useful first of all for me.

However, if somebody find some of the posts interesting, I just would be happy about that.

Currently I have 16 drafts, that means 16 project witch I found interesting enough to share. But for sure there will be more, because those 16 was remembered just in 10 minutes.

You can find them all under "My Projects" label.

Advantages of PXE

It's just a note about my positive experience with PXE. Although I was working with it some years ago, but now it became so simple to setup, than it's definitely worth to have it in many cases.

First case is when you have to have some new systems installed pretty often. Of course, if you have to setup more than 5 identical systems it's reasonable to have an image or use some kickstart for example, but in this case it's also useful to have PXE configured to help you with that. But in my work I'm facing a situation when I need to prepare some new system for some special need with different hardware and unique post-install steps.

Second case is when you need some special tools available in simple way. It could be even tools for those mentioned purposes like imaging (Acronis True Image for example). Or (what we use pretty often) is a GParted tool and a BartPE image. Yes, it's not a good idea to give everyone in your network the tools like that, but now it's really easy to protect any item in your PXE boot menu with a password. Of course, the way this function is realized doesn't give you any strong protection, but if the guy is able to find and download a file with the password and decode this password, he will also be able to make his own bootable USB-drive with all the tools he needs. And, of course, I'm not talking about the systems without physical access for the "bad guys".

Also, what I have configured with the PXE, is some Live distributions. For example, I have prepared a special installation of Ubuntu, then have put it on NFS, and configured it to mount the root (/) in a special way: nfs+ramfs=unionfs(aufs). Thus, now I have a Network-Booted system, which is configured just how I need, and which anyone can boot on and configure just how he wants, but no changes are applied to the real image on the network - after reboot the system is clean and ready again.

I will not give any examples of code, since there are a lot of it in the Internet. I've started with this recipe, and then I just migrated it to the CentOS server. Unfortunately, I can't find the recipe with which I have configured unionfs, but I can provide anyone with the examples if needed, or you can just google by the  keywords like "PXE aufs ramfs".

How to preserve eth0 interface name for cloned or migrated CentOS or Ubuntu?

I'm sure that many people faced this nasty thing: after you clone or reconfigure a Virtual Machine, OS reconfigures the interface because it has another MAC. I will not say that this is bad behavior, but what can you do, if you need to preserve the eth0 name and configuration?

In CentOS it's very simple - all you need is just to remove a string like "HWADDR=00:11:22:aa:bb:cc" in file /etc/sysconfig/network-scripts/ifcfg-eth0. That's it! Now even after you clone this machine or in any other way change the ethernet card - config will not be changed. Of course, in some cases there is a risk to face an IP conflict, but you're good admin, right :)?

Well, I don't use Ubuntu for server often, so I didn't look for a persistent solution. But what I do time to time, is just removing all strings from file /etc/udev/rules.d/70-persistent-net.rules right before cloning. It makes Ubuntu to forget, that some ethX name is already assigned for some MAC address.