Backing up one’s home directory with tar

This is something that should be fairly easy. However in practice there are some problems:

1. Tar has a proliferation of options and can be an effort to use – at least if you are using it infrequently
2. One’s home directory often contains large files (like perfectly legally downloaded music and videos), which you don’t really want to back up repeatedly.
3. Some applications put rather large things in hidden directories under your home directory

There are various solutions:

How to backup a directory using tar in one line.

This is all terribly simple… but I’m rather inclined to forget it. The reason I’m putting this here is that I’ve written something like this at least twice.

file=$(basename `pwd`);
backupName=$file-$(date +%Y-%m-%d.tgz);
tar -C .. -czf $backupName $file --exclude=$file/$backupName

This creates a gunzipped tar file of the current directory, in the current directory and includes the current date in the name. This is quite useful for your home directory.

A local firewall for ubuntu

A very simple local firewall for Ubuntu machines using iptables.

I use the following set up:

In /etc/network/if-pre-up.d, I have an executable shell script called firewall which uses iptables-restore to load firewall settings stored in /etc/network/firewall. This script is as follows:

#!/bin/bash
#/etc/network/if-pre-up.d/firewall - A script to restore a saved firewall on startup.
cat /etc/network/firewall | iptables-restore

The firewall settings file /etc/network/firewall was created using the command:

iptables-save > /etc/network/firewall

after I set up a working firewall using iptables. (See man iptables). This file currently looks like this.

#/etc/network/firewall
*filter
:INPUT ACCEPT [1745:1484069]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1763:303728]
:DROPCHAIN - [0:0]
:LOGCONNECT - [0:0]
-A INPUT -s 127.0.0.1 -p tcp -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j LOGCONNECT
-A FORWARD -j DROPCHAIN
-A LOGCONNECT -j LOG --log-prefix "IPTABLES: BLOCK TCP CONNECT"
-A LOGCONNECT -j DROP
COMMIT

This stops any forwarding and any attempts to form incoming tcp connections. Any attempts to open a connection are logged via kernel logging.

I couldn’t find an easy way to filter just these messages into a file (short off piping all appropriate messages to a process in /etc/syslogd.conf that only keeps iptables messages… though I’m sure there is a clever way of doing this).

Also, I probably should be paying attention to rpc udp packets… or something like that.

Shout at me if there is some better way of doing this.

Ant troubleshooting

If you get an error like this:

    No supported regular expression matcher found: java.lang.ClassNotFoundException: org.apache.tools.ant.util.regexp.Jdk14RegexpRegexp)

when using ant then it may well be because you don’t have the ant-optional package installed (if you are using Ubuntu or similar.) You can install this with apt-get by typing:

apt-get install ant-optional

as root.

Fixing catastrophic mistakes with apt-get

Story for the patient

I managed to utterly break a linux installation yesterday, by trying to install a single package with apt-get. Apt helpfully decided to suggest removing a number of important packages, and I absentmindedly agreed.

The lesson learned here would be that you should always press ‘n’ immediately and think whenever apt suggests removing more than a couple of packages, if I didn’t know this. I suppose the real lesson is just to be less dim, but alas this never seems to work. Another lesson is to especially be less dim when you only have a wireless internet connection and you decide to remove the things that make it work.

Anyway, I found a moderately nice way of reverting these damaging changes.

Although apt does not do any logging, it uses dpkg for installation (on debian type systems at least) and dpkg does do logging.

Looking at /var/log/dpkg.log I found that it neatly recorded all of dpkg’s operations so I was able to get a list of all the packages I had absentmindedly removed by using some crpytic shell commands:

cat /var/log/dpkg.log | grep remove | cut -d " " -s -f 4 > ~/removed-packages

I then could reinstall these with:

apt-get install `cat removed-packages`.

Hurrah for copious logging and shell textual data processing… or something like that.

Summary for the impatient:

Apt doesn’t store a log, but dpkg does and apt uses dpkg. The relevant log file is /var/log/dpkg.log. To get a list of the removed packages, and install them again you can run:

cat /var/log/dpkg.log | grep remove | cut -d " " -s -f 4 > ~/removed-packages; apt-get install `cat ~/removed-packages`

as a root user.

How to stop the bell ringing in bash

To stop bash from trying to ring the bell add

set bell-style none

to the /etc/inputrc file. You can also be added to a local ~/.inputrc file – but this won’t work if
you log in as root.

Also, note that this won’t stop other applications from trying to ring the
bell – for this it might be best to switch off the bell at BIOS level.

See man bash.

Other applications whose bells you might like to stop:

less: Use the -q option. This can be acheived permanently by adding alias less=”less -q” to your .bashrc file.

man: man uses the $PAGER environment variable to display man pages, or the default pager (normally less) otherwise. Therefore add export PAGER=”less -q” to your .bashrc file.

vim: By default vim rings the bell. To stop this type set vb t_vb= at the colon-line, or add it to your .vimrc file.

emacs: Set the variable ring-bell-function to a function that doesn’t do anything. (setq ring-bell-function (lambda () nil)

How to uninstall packages with apt

Installing packages with apt is generally very easy. Uninstalling (or removing) packages can be slightly more annoying.

The standard command for removing packages with apt is

apt-get remove <package-name>

This should always work as long as

• The package doesn’t have dependencies
• The commands needed to remove the package execute correctly.

Note that this leaves all the configuration files in place – so that if you decide to reinstall the packages again at a later date they should be configured exactly as before.

If you want to remove these configuration files for some reason (for example if you’ve completely destroyed them by your editting) then you purge the package instead with:

apt-get --purge remove <package-name>

Things that can go wrong

You don’t know the name of the package

This can be more of a probably than one might at first envisage – and it is definitely annoying when it happens. To find the package name you can use apt-cache, a command for returning information from the local cache of all available packages.

apt-cache search <keyword regex>

searches for all packages in the repository that contain the regular expression in their name of description and returns a list. Performing

apt-cache search <word> | less

and then searching for other relevant words using “/<other-word>” can be a very effective way of finding package names.

If you are getting too many results you might like to try

apt-cache --names-only search <keyword>

which will only search the package name and not the description.