I spend a lot of my time in front of my laptop in the terminal. When Terminal.app finally was equipped with tabbed terminals, it suddenly became a lot easier to execute several processes within the same window without reaching out for the mouse. But, drawing on the Unix tradition of Mac OS X, there exists a simpler and faster alternative for switching between applications with the keyboard.

Every basic Unix shell provides a concept called job control which allows for switching back and forth between your applications simultaneously from within a single shell session. This text based multitasking functionality was implemented way back before Microsoft developed the Program Manager for Windows 3.x, and it certainly demonstrates why Unix was invented inherently as a multiuser, multitasking system. Let’s take a quick tour of the basics of job control using my favourite shell zsh (bash might apply as well, but the syntax for C derivatives might be different):

1. Start a zsh session and open a text file with your favourite $EDITOR, e.g. vim (or the standard editor, ed):

meeho:[aj] % vim doc1.txt

2. Now vim opens up the file doc1.txt. Now, say you want to briefly look for other files containing a specific pattern without exiting vim or opening a new terminal — what is the trick? Easy as pie: press control-Z, and your current process is suspended to the background of your shell (process suspension also implies that the process execution is paused):

[1]  + 22023 suspended  vim doc1.txt

meeho:[aj] %

3. Now you can grep for the relevant content and finally return to your vim session:

meeho:[aj] %  grep -ir 'important pattern' *

meeho:[aj] %  fg

4. Now, you are back in vim. ‘fg’ simply means ‘foreground’ and pushes your recently ‘backgrounded’ process of yours into the foreground of the shell session. Now, what if you want to background more than one process in the same shell session? Easy, control-Z out of the shell, open a new vim instance (vim doc2.txt) and background that process with control-Z as well. Now you can list the available jobs with the zsh built-in ‘jobs’ command:

meeho:[aj] % jobs

[1]  - suspended  vim doc1.txt

[2]  + suspended  vim doc2.txt

5. Finally, you can now swap back and forth between the applications using %<ID> (ID being the number in the squared brackets, e.g. %1 for ‘vim doc1.txt’ and %2 for ‘vim doc2.txt’):

meeho:[aj] % %1

The syntax for job control varies a bit from shell to shell, but the concept is basically the same. It is particularly useful if you are working on a remote machine through a slow network SSH connection, or if you simply have no graphical environment (e.g. X11) available.

There are, however, alternatives to the simple, but elegant Unix job control: GNU Screen is one of them. In terms of multitasking it is much more powerful, since it allows you to shuffle back and forth between several terminal sessions (thus, Screen is described as a terminal multiplexer rather than a single shell process). Some people even describe it as a window manager for the console, and it is truly powerful. But for now, I will save that walkthrough for next time.

If you have SSH access to a UNIX/Linux based system somewhere and want to copy a file located on the server to your computer via SSH, you can use the scp command found in most UNIX/Linux systems, including Mac OS X.

Say you want to copy a file from the remote server to your own computer, a file called my_file.txt. In this case, you would issue the following command in your terminal:

scp your_login@addres.of.remote.server:my_file.txt .

This makes your computer connect to the server with the login you provide, and copy the my_file.txt file to the directory you are currently working (using the exact same file name locally on your computer, that’s why there is a dot in the end of the command).

If you are a Ruby on Rails developer, use PostgreSQL and receive the error

undefined method `quote_ident' for PGconn:Class

… when you have updated your rails to version >2.2, you can solve the above problem by 1) creating a new file in config/initializers with the name new_rails_defaults.rb, and 2) insert the following content:

def PGconn.quote_ident(name)
%("#{name}")
end


… so the file looks like this, thus making your rails application work again:

new_rails_defaults.rb with the code shown in TextMate.

Safe, reliable, and effective backup strategies is a known issue in every system administrator’s daily life. Here at Meeho!™, we do everything we can to ensure the safety of our clients’ data. Doing the daily backup, we make use of rsync, a truly effective, safe, and well-proven tool for doing incremental backup. In this entry, I’ll show you how to quickly use rsync to manage a new backup setup or your existing backup.

rsync does a lot more than just backup, but in our case we wish to move our data from one server (named source) to another server (named target). In the transport layer, we use SSH (Secure Shell) ensuring that all data is encrypted while being moved. At the source you create a key (as the root user) and write the key to a separate folder so it won’t interfere with any pre-existing SSH keys. The following examples require that SSH, rsync, and similar UNIX tools are preinstalled. In the following example, we create an SSH key containing an empty password:

sudo ssh-keygen -f /backup/ssh_key -t rsa -N ''

The above command creates a new RSA key for Secure Shell access in the folder /backup with an additional public key:

source:[aj] % ls
ssh_key      ssh_key.pub

Then, you copy the file to the server (by using scp, for instance) and copy the content of SSH’s authorized_keys file so that the backup user now can log on automatically and encrypted:

scp ssh_key.pub backup@target:/home/backup
ssh target -l backup

(Where backup is your backup user.) Finally, we do an append on the file:

cat /home/backup/ssh_key.pub >> /home/backup/.ssh/auhorized_keys

Now, create a folder (on the target) to contain the backup from the source:

mkdir /home/backup/backup-source

At source you run the following rsync command creating a complete mirroring of the given folder, harnessing the power of “incremental forever” (which is a continuous incremental backup of modified files between the two folders on source and target):

/usr/local/bin/rsync -avz --delete -e "ssh -i /backup/ssh_key"
"/backup" backup@target:/home/backup/backup-source

Where /usr/local/bin/rsync of course has to be changed to reflect where you have placed rsync (the above path is standard for FreeBSD). The folder being synchronized is /backup (in bold above), which you can change as you please. The synchronize action is recursive so that every subfolder is moved as well. Please note that the switch –delete will delete files on the target server if the same files are no longer present at the source server. Should you choose to not make use of –delete, nothing will be deleted when rsync is synchronizing.

If you wish to automate the above backup procedure, a good idea is for you to create a shell script (with an rsync command for every script) and finally call the given shell script from cron once every 24 hours (reflecting your need for backup – you could change it to 48 hours or whatever you feel like).

I hope that this entry has given you some inspiration as to how you, in all relativeness, can setup a high-performing, effective, and secure backup procedure in very short time using FreeBSD and rsync. The algorithm is incredibly effective and minimizes both transfer times plus bandwidth use.

Note: remember that empty SSH keys represent a security risk, and that the above examples should be used with regards to the protection of your data. Meeho!™ will not be held responsible for any security breaches or loss of data that the above presented examples may occur.