How to version control /etc directory in Linux

http://xmodulo.com/2013/08/how-to-version-control-etc-directory-in-linux.html

In Linux, /etc directory contains important system-related or application-specific configuration files. Especially in a server environment, it is wise to back up various server configurations in /etc directory regularly, to save trouble from any accidental changes in the directory, or to help with re-installation of necessary packages. Better yet, it is a good idea to “version control” everything in /etc directory, so that you can track configuration changes, or recover from a previous configuration state if need be.
In Linux, etckeeper is a collection of tools for versioning content, specifically in /etc directory. etckeeper uses existing revision control systems (e.g., git, bzr, mercurial, or darcs) to store version history in a corresponding backend repository. The advantage of etckeeper is that it integrates with package managers (e.g., apt, yum) to automatically commit any changes made to /etc directory during package installation, upgrade or removal.
In this tutorial, I will describe how to version control /etc directory in Linux with etckeeper. Here, I will configure etckeeper to use bzr as a backend version control repository.

Install Etckeeper on Linux

To install etckeeper and bzr on Ubuntu, Debian or Mint:

$ sudo apt-get install etckeeper bzr

To install etckeeper and bzr on CentOS or RHEL, first set up EPEL repository, and then run:

$ sudo yum install etckeeper etckeeper-bzr

To install etckeeper and bzr on Fedora, simply run:

$ sudo yum install etckeeper etckeeper-bzr

Set up and Initialize Etckeeper

The first thing to do after installing etckeeper is to edit its configuration file. You can leave other options as default.

$ sudo vi /etc/etckeeper/etckeeper.conf

# The VCS to use.
VCS="bzr"

# Avoid etckeeper committing existing changes to /etc automatically once per day.
AVOID_DAILY_AUTOCOMMITS=1

Now go ahead and initialize etckeeper as follows.

$ sudo etckeeper init

At this point, everything in /etc directory has been added to the backend bzr repository. However, note that the added content has not been committed yet. You need to either commit the action manually, or install/upgrade any package with a standard package manager such as apt or yum, which will trigger the first commit automatically. Here, I will do the first commit manually as follows.

$ sudo etckeeper commit “initial commit”

Etckeeper Examples

To check the status of /etc directory, run the following command. This will show any (uncommitted) change made to /etc directory since the latest version.

$ sudo etckeeper vcs status

To show differences between the latest version and the current state of /etc:

$ sudo etckeeper vcs diff /etc

To commit the current (changed) state of /etc directory:

$ sudo etckeeper commit “any comment”

To check the commit history of the entire /etc dirctory or specific files/subdirectories:

$ sudo etckeeper vcs log
$ sudo etckeeper vcs log /etc/sysconfig/*

To check the difference between two specific revisions (revision number 1 and 3):

$ sudo etckeeper vcs diff -r1..3

To view the change made by a specific revision (e.g., revision number 3):

$ sudo etckeeper vcs diff -c3

To revert the content of /etc directory to a specific revision (e.g., revision number 2):

$ sudo etckeeper vcs revert --revision 2 /etc

Automatic Commits by Etckeeper

As mentioned eariler, etckeeper automatically commits changes made to /etc as part of package installation or upgrade. In this example, I try installing Apache HTTP Server as a test.

$ sudo yum install httpd

To view the commit history auto-generated by package installation:

$ sudo etckeeper vcs log

------------------------------------------------------------
revno: 5
committer: dan 
branch nick: fedora /etc repository
timestamp: Mon 2013-08-05 06:39:33 -0400
message:
  committing changes in /etc after yum run
  
  Package changes:
  +0:apr-1.4.6-3.fc18.x86_64
  +0:apr-util-1.4.1-6.fc18.x86_64
  +0:httpd-2.4.4-3.fc18.x86_64
  +0:httpd-tools-2.4.4-3.fc18.x86_64
------------------------------------------------------------

To view the changes made in /etc directory by package installation:

$ sudo etckeeper vcs diff -c5 

Multi-Booting the Nexus 7 Tablet

http://www.linuxjournal.com/content/multi-booting-nexus-7-tablet

 Anyone who knows me well enough knows I love mobile devices. Phones, tablets and other shiny glowing gadgets are almost an addiction for me. I've talked about my addiction in other articles and columns, and Kyle Rankin even made fun of me once in a Point/Counterpoint column because my household has a bunch of iOS devices in it. Well, I was fortunate enough to add an Android device to the mix recently—a Nexus 7 tablet. I actually won this device at the Southern California Linux Expo as part of the Rackspace Break/Fix Contest, but that's a different story.
If you've not seen a Nexus 7, it's a nice little device. Like all "Nexus"-branded Android devices, it's a "reference" device for Google's base Android implementation, so it's got a well-supported set of hardware. I'm not trying to make this article sound like a full-fledged review of the device, but here's a few tech specs in case you're not familiar with it:

• 7" screen with 1280x800 resolution.
• 7.81" x 4.72" x 0.41" (198.5mm x 120mm x 10.45mm).
• 16 or 32GB of Flash storage (mine is the 16GB model).
• 1GB of RAM.
• NVIDIA Tegra 3 Quad-Core Processor.
• Wi-Fi, Bluetooth and optional 3G radios.
• Android 4.2 Jelly Bean.

The Nexus line of Android devices makes up the reference implementation for Android, so that tends to be the series of device that sees the fastest movement in terms of new builds of the OS, and in unique OS derivatives like CyanogenMod. Right about the time I received the Nexus 7, Canonical released the developer beta of Ubuntu Touch, which targeted the Nexus 7 as its deployment platform.
Because I can't leave nice things well enough alone, I decided to start trying alternate OS ROMs on my shiny new Nexus 7. Ordinarily, each new OS would require you to reflash the device, losing all your configuration, apps and saved data. However, I found a neat hack called MultiROM that lets you sideload multiple ROMs on your device. How does it work? Well, let's walk through the installation.

Prep for MultiROM Installation

First, and I can't stress this enough, back up your device. I really, really mean it. Back up your device. You're messing around with lots of low-level stuff when you're installing MultiROM, so you'll want to have copies of your data. Also, one of the first steps is to wipe the device and return it to an "out-of-the-box" configuration, so you'll want your stuff safe.
Second, grab copies of the "stock" Nexus 7 ROMs as they shipped from the factory. You will want these in the event something goes wrong, or if you decide you don't like this MultiROM hackery and want to roll your device back to a stock configuration.
Third, check the links in the Resources section of this article for up-to-date documentation on MultiROM. It's possible for things to change between this writing and press time, so follow any instructions you see there. Those instructions will supersede anything I type here, as this kind of hack can be a rapidly moving target. Also, do your own homework—lots of great YouTube videos describe this process, and a video sometimes can be worth several thousand words.
Notice: please make sure you follow these three steps, then follow the MultiROM documentation exactly. I'm not responsible if your tablet gets bricked or turns itself into SkyNet and goes on a rampage against humanity. Though I have to say, if that happened, it'd be kind of neat, in a geeky sort of way.

Unlocking Your Bootloader

Your device should be on the latest available factory ROM supported by MultiROM before you begin the installation. At the time of this writing, on my Nexus 7 (Wi-Fi-only) model, that was 4.2.2. The Nexus 7 comes from the factory with a "locked" bootloader. The first thing you've got to do is unlock the bootloader before you can proceed.
To unlock the bootloader, you need the Android SDK tools installed on your computer (see the Resources section for a download link). Specifically, you'll need the fastboot and adb tools for this, so make sure they're on your system and in your shell's PATH environment variable.
Next, hook up your tablet to your computer via the USB-to-MicroUSB cable, and then run:

adb reboot bootloader

Your tablet then will reboot, and you'll be in the Android bootloader. Once you're in the bootloader, run the following command:

sudo fastboot oem unlock

Next, you'll be prompted to confirm the command and accept that all data on your device will be erased. The tablet then will reboot, winding up in the setup wizard where you'll be prompted for all your setup information as if it were fresh out of the box once more.

Installing MultiROM

Now that your bootloader is unlocked, you can proceed to the trickiest part of this process—installing MultiROM. Grab a copy of it from the XDA-Developers MultiROM thread (the link is in the Resources section of this article; currently the filename is multirom_v10_n7-signed.zip). You'll also need to get the modified TWRP install file (TWRP_multirom_n7_20130404.img) and a patched kernel (kernel_kexec_422.zip). Rename the TWRP install file to recovery.img, then hook your tablet back up to your computer, and place these files in the root of its filesystem (keep the .zip files zipped—don't unzip them).
Next, from your computer's command line, you'll need to run the adb utility from the Android SDK again, but this time, with the proper argument to get the system to boot to "recovery" mode:

adb reboot recovery

This will bring the device to "Clockwork Recovery" mode. From the Recovery menu on the device, choose "Install zip from sdcard", followed by "choose zip from sdcard", then specify the MultiROM zip file you moved to the root of your tablet's filesystem earlier. When it's done flashing, select "reboot system now", and your Nexus 7 will reboot.
Once the device boots normally, issue the following command from your computer to get the system back in the bootloader:

adb reboot bootloader

The device will reboot in bootloader mode. Select the fastboot option on the screen, then type the following on your computer:

sudo fastboot flash recovery recovery.img

That'll flash the modified recovery image that MultiROM requires to your tablet. Next, just tell the tablet to reboot by issuing the following command to it:

sudo fastboot reboot

Your Nexus 7 now is ready to install alternate ROMs.

 Adding ROMs to MultiROM

Adding ROMs to MultiROM is fairly straightforward from here. Just hook your tablet up to your computer, drop the .zip file for the ROM you want to install onto the root of the filesystem, and then shut down the tablet. Restart your Nexus 7 in MultiROM by holding the "Volume Down" button while pushing the power switch. You'll see a screen with what appears to be the Android logo lying on its back (Figure 1). This is the bootloader. Push the "Volume Down" button until the red arrow at the top of the screen indicates "Recovery Mode", then push the Power button. This will boot the Nexus 7 into MultiROM.
Figure 1. Android Bootloader Screen
Now that your Nexus 7 is actually in MultiROM, select the "Advanced" button in the lower-left corner, then select "MultiROM" in the lower-right corner. Now, to install a ROM, touch "Add ROM" in the upper-left corner (Figure 2).
Figure 2. MultiROM "Add ROM" Screen
Accept the defaults (unless you're trying the Ubuntu Touch developer release), and just press Next. The next screen will ask you to select a ROM source. Touch the Zip file button, then pick the .zip file of whatever ROM you want to install. The system will go ahead and install it, and it'll let you know when it's complete. Push the Reboot button when the install is complete, and your tablet will reboot into the MultiROM selection screen (Figure 3).
Figure 3. MultiROM Boot Menu
Looking at my boot menu, you'll see I've got cm-10.0.0-grouper installed, otherwise known as CyanogenMod. To boot that, I simply touch it, then press the large blue Boot button at the bottom of the screen. It's as simple as that—the Nexus 7 will just start booting CyanogenMod. At one point, I had the stock ROM, CyanogenMod, AKOP and Ubuntu Touch on my Nexus 7, all coexisting nicely (but they took too much of my limited 16GB storage space, so I pruned back some).
If you decide a particular ROM isn't for you, you can get rid of it quite easily. Just go back to the MultiROM install by booting with the Power and Volume Down buttons depressed, then select Recovery, and press the Power button again. Dive back into the MultiROM menus, just like you're installing a ROM, but instead of pressing Add ROM, press List ROMs. Touch the ROM you want to delete, and then just select Delete from the buttons that pop up. This will let you keep your MultiROM install clean, with only the ROMs you want to test active at any given time.

 Getting Ubuntu Touch Running

Ubuntu Touch is something I've been watching closely, particularly because I spent a little time with an Ubuntu Touch-equipped Nexus 7 at the Southern California Linux Expo. The Ubuntu Touch developer builds can be a little finicky, although they've stabilized in recent weeks. The key to getting them going in MultiROM is to select the "Don't Share" radio button when adding the ROM (Figure 2). The Ubuntu Touch builds come in two parts. Add the smaller hardware-specific zip file first (on my Wi-Fi Nexus 7, it's quantal-preinstalled-armel+grouper.zip), but do not reboot—go back, list the ROM again, then push Flash Zip, and select the larger ROM file (quantal-preinstalled-phablet-armhf.zip). After that completes, you can reboot your tablet into Ubuntu Touch. Be advised, though, that Ubuntu Touch is under very heavy development, and sometimes the daily builds exhibit issues—and may not work at all. Your mileage may vary. If you do get Ubuntu Touch going, but it seems unresponsive to touch, try sliding from the left bezel toward the center. That'll bring up a Unity-style launcher, and things should work from there. It took me a few tries to figure this out. I thought my Ubuntu Touch installation was broken or that I had a bad build. It turns out, it's just a different operating paradigm.
Figure 4. Ubuntu Touch on the Nexus 7!

Conclusion

The Nexus 7 by itself is a great, low-cost, high-power tablet. However, thanks to its status as a reference device, there's a lot of alternate OSes out there for it. MultiROM lets you try them all without requiring you to wipe your device each time you want to try a new OS or ROM build. Check it out, but back up your data, and read the documentation thoroughly.

Pong

The programmer who wrote the MultiROM program has a great sense of humor, and he left a "Pong" easter egg in the software. From the main MultiROM boot screen, just touch the MultiROM logo, and you'll get a proper portrait-orientation port of Pong (say that three times fast!)
Pong!

Resources

XDA-Developers MultiROM Install Thread: http://forum.xda-developers.com/showthread.php?t=2011403
Nexus 7 Factory ROM Images: https://developers.google.com/android/nexus/images
Android SDK Tools Download Page: http://developer.android.com/sdk/index.html
CyanogenMod Home Page: http://www.cyanogenmod.org
AKOP Home Page: http://aokp.co
Ubuntu Touch Installation: https://wiki.ubuntu.com/Touch/Install
Ubuntu Touch Download Page: http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current

Unix: Getting from here to there (routing basics)

http://www.itworld.com/networking/367760/unix-getting-here-there-routing-basics

You need to understanding routing tables if you're going to do any kind of network troubleshooting. Let's take a look at what Linux commands can tell you about how your system is making connections.

What is routing? It's the set of rules that govern how you make connections to other systems. Any time you make a connection from one system to another system -- whether you're sending email, transferring a set of files or logging in with ssh -- you're routing. And, since most connections aren't direct (in other words, they're travelling through one or more system en route to the target), most of the time you're going to be crossing a router -- or maybe a long series of routers -- to get there.

To view the routing table on a Linux system, use the netstat -rn command. The output of this command will tell you how connections you initiate are going to be handled. The routing table on most Linux systems will look something like this:

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth0

The fields in this output are:

Destination -- where the connections are headed. This can be a specific network, one particular system or everything not covered by some other routing entry (i.e., the default).
Gateway -- where those connections first have to go before being sent to the ultimate destination. This can be a local router or a "0.0.0.0" (no router involved) kind of entry.
Genmask -- the network mask that determines what systems are covered by your destination.
Flags -- indicators that tell you more about each routing table entry (e.g., whether it's a gateway).
MSS -- maximum segment size
Window -- size of packet that can be transmitted
irtt -- initial round trip time
Iface -- the network interface that is involved
For several of these settings, a size of 0 means that the default value is being used.
Now, let's examine this output line by line.

Line 1

First, 192.168.0.0 is the local network. How do you know this? Well, with a gateway of 0.0.0.0, connections clearly aren't going through another system.

  0.0.0.0 in this position in the routing table means your system will send packets directly to the target system (i.e., not through a router).
You can confirm that your system is, indeed, on the 192.168.0.0/24 network by running ifconfig.

$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:16:35:69:BD:79
          inet addr:192.168.0.11  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe88::211:35aa:fe66:bd79/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:64419467 errors:0 dropped:0 overruns:0 frame:1
          TX packets:62220642 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4012707801 (3.7 GiB)  TX bytes:382601808 (364.8 MiB)
          Interrupt:217 Memory:fdef0000-fdf00000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:433441 errors:0 dropped:0 overruns:0 frame:0
          TX packets:433441 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:36036194 (34.3 MiB)  TX bytes:36036194 (34.3 MiB)

The lo entry represents the loopback interface. If you have additional network interfaces, you will need to add the -a option to have them reported as well.

The network mask or "Genmask" of 255.255.255.0 tells us that our address space for this route is 192.168.0.0/24. The use of 192.168.0.0 is not surprising for a small LAN. It's one of the three internal IP ranges that anyone can use and the one that is the one most commonly used on small routers. The destination address of 192.168.0.0 with the 255.255.255.0 mask means any address between 192.168.0.1 and 192.168.0.254 (i.e., the local network) would be on the same LAN.

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
...

Notice the netmask is 255.255.255.0. So, this is the route you will use for any connections to other systems on the same LAN. The interface, which is likely the only one of this system, is eth0. And the flag set to U tells you this route is up.
Flags can have various values, although the most commonly seen are U and G. Here they are with some of the other flags you might see.

• U - route is up
• H - target is a host (i.e., only that host can be reached through that route)
• G - route is to a gateway
• R - reinstate route for dynamic routing
• D - dynamically installed by daemon or redirect
• M - modified from routing daemon or redirect
• A - installed by addrconf
• C - cache entry
• !

 - reject route

Line 2

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
...
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
...

The 169.254.0.0 entry requires some explanation. This is a link-local address -- a special address defined in RFC 5735 for link-local addressing. Its appearance in your netstat output doesn't mean it's being used. It just shows up unless you take steps to remove it. A link-local address is an Internet Protocol address that is intended only for communications within the segment of a local network (a link) or a point-to-point connection that a host is connected to. Routers do not forward packets with link-local addresses.
You can add NOZEROCONF=yes at the end of your /etc/sysconfig/network file to remove this additional route, though it does no harm being there.

$ cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=vader.aacc.edu

Line 3

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
...
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth0

0.0.0.0 is your default route. This is where connections are routed whenever those connections aren't headed for the local network segment or other specific routes. If you use the command netstat -r (without the -n option) , the word "default" will appear in place of 0.0.0.0. The -n option suppresses translation of addresses to symbolic names.

$ netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.0.0     *               255.255.255.0   U         0 0          0 eth0
169.254.0.0     *               255.255.0.0     U         0 0          0 eth0
default         pix             0.0.0.0         UG        0 0          0 eth0

This also shows the name of the gateway -- appearently a Cisco PIX router.
Think of the default route as "everywhere else". In this case, we can see that to connect to systems anywhere other than the local network, we have to go through 192.168.0.1. Most network admins will use the .1 address of each LAN for its router -- a very is a sensible convention.
So, if your connection is headed anywhere else, you need to go through the gateway listed in the second column -- generally your default router.
The flags for the default route line clearly include G, confirming that this is a router or "gateway".

Using traceroute

If you want to see the specific route that a connection might take and get an idea how well that route performs, then traceroute is the command to use. This command will display each hop that a connection might take and will show you how long each hop takes.

  The traceroute command does this by sending a number of echo request packets (like ping does) but with varying time-to-live (TTL) settings so that it can calculate the time that each hop requires. For example, for the first hop, the TTL is set to 1. For the second hop, it's set to 2, etc.

$ traceroute world.std.com
traceroute to world.std.com (192.74.137.5), 30 hops max, 40 byte packets
 1  * * *
 2  gig0-8.umcp-core.net.ums.edu (136.160.255.33)  2.634 ms  2.632 ms  2.610 ms
 3  ten2-0.stpaul-core.net.ums.edu (136.160.255.198)  3.515 ms  3.508 ms  3.486 ms
 4  te4-3.ccr01.bwi01.atlas.cogentco.com (38.104.12.17)  4.169 ms  4.163 ms  4.143
     ms
 5  te4-2.ccr01.phl01.atlas.cogentco.com (154.54.2.174)  6.268 ms  6.262 ms 
     te3-3.ccr01.phl01.atlas.cogentco.com (154.54.83.221)  6.950 ms
 6  te0-0-0-19.mpd21.jfk02.atlas.cogentco.com (154.54.2.110)  9.835 ms 
     te0-0-0-7.ccr22.jfk02.atlas.cogentco.com (154.54.31.53)  8.937 ms  8.925 ms
 7  te0-1-0-4.ccr22.bos01.atlas.cogentco.com (154.54.6.9)  14.768 ms 
     te0-2-0-6.ccr22.bos01.atlas.cogentco.com (154.54.44.58)  14.129 ms te0-1-0-    
     2.ccr21.bos01.atlas.cogentco.com (154.54.44.6)  14.740 ms
 8  te4-1.mag01.bos01.atlas.cogentco.com (154.54.43.50)  14.450 ms 
     te7-1.mag02.bos01.atlas.cogentco.com (154.54.7.42)  13.859 ms  
     te4-1.mag01.bos01.atlas.cogentco.com     
     (154.54.43.50)  14.816 ms
 9  vl3884.na31.b000502-0.bos01.atlas.cogentco.com (38.20.55.82)  18.336 ms  16.398
     ms  16.699 ms
10  cogent.bos.ma.towerstream.com (38.104.186.82)  13.925 ms  13.840 ms  13.720 ms
11  g6-2.cr.bos1.ma.towerstream.com (64.119.143.81)  21.495 ms  15.647 ms  15.458 ms
12  69.38.149.18 (69.38.149.18)  33.680 ms  33.602 ms  33.419 ms
13  64.119.137.154 (64.119.137.154)  31.961 ms  30.079 ms *
14  world.std.com (192.74.137.5)  34.695 ms  34.698 ms  34.159 ms

The ping command is popularly used to test connectivity with a remote system and verifies that you can (or can't) reach the remote system.

Route Caching

The route -Cn command displays routing cache information. This shows routes associated with active connections. Linux caches this information so that it can route packets faster.

route -Cn
Kernel IP routing cache
Source          Destination     Gateway         Flags Metric Ref    Use Iface
192.168.0.3     192.168.0.6     192.168.0.6     il    0      0       13 lo
192.168.0.6     204.111.97.254  192.168.0.1           0      0        0 eth0
192.168.0.6     204.111.97.254  192.168.0.1           0      2        0 eth0
192.168.0.6     204.111.97.254  192.168.0.1           0      0        4 eth0
192.168.0.6     192.168.0.3     192.168.0.3           0      1        0 eth0
204.111.97.254  192.168.0.6     192.168.0.6     l     0      0       79 lo

Rejecting connections

You can also specifically reject specific network connections using route commands.

  Using a command such as this one, you would redirect connections to a system you don't want to permit to your loopback interface.

# route add 66.55.44.33 gw 127.0.0.1 lo

To reverse this, you would do this:

# route delete 66.55.44.33

You could also do block connections to a particular system or subnet using a command such as these:

# route add -host 66.55.44.33 reject
# route add -net 66.55.44.0/24 reject

Wrap Up

Managing routing configuration on Linux systems is relatively easy, but a good handle on what the basic commands can tell you and do for you is essential.