The Last Monkey

Picryption: TrueCrypt for the Pi

thepadawan42 — Mon, 07 Apr 2014 17:12:00 +0000

Journey to the Clouds series.
3. Encrypting an external USB drive using TrueCrypt.

TrueCrypt allows full disk encryption and we are going to use it to encrypt the USB drive attached to the Raspberry Pi so you can happily carry it around when needed. This post will also present two solutions for auto-mounting TrueCrypt volumes. We will use the latest version available, for that we will have to compile it from source and since the target is a headless Raspberry Pi we will compile it without graphical support.

Journey to the Clouds index:

Install Raspbian on a headless Raspberry Pi.
Configuring Dynamic DNS using FreeDNS.
Encrypting an external USB drive using TrueCrypt.
Setting up Nginx web server.
Setting up MySQL database.
Setting up PHP.
Installing ownCloud.

The first question that comes to mind is why TrueCrypt? Because it works in Linux, Windows and Mac, since we are dealing with an external drive it is quite likely that, at some point, you would like to use it in another computer, therefore it is best if no matter the operating system you can access to it. The next question is, why on earth will you compile it? If you find a pre-compiled binary officially supported let me know.

The last philosophical issue to point out is how secure you want it to be. TrueCrypt uses passwords and keyfiles, if you want to avoid user interaction and have the USB drive automatically mounted then the password will have to be stored locally in plain text. That is a big drawback but you will have to make your peace with it or mount the encrypted drive manually. Basically there are two scenarios where storing the password is a major disadvantage: someone steals your Raspberry Pi along with the drive plugged in or someone hacks into the root account of the Raspberry Pi and a later point steals the USB drive attached. The former scenario could be likely in a house break-in due to the small nature of the Pi, but the later usually involves pissing off your geeky revengeful friend (maybe you said that Firefly deserved to be canceled? My advice, do not upset geeks with a lot of free time in their hands).

1. Required packages.

In order to compile TrueCrypt and use exFAT or NTFS we need to install some packages:
$ sudo apt-get install nasm libwxgtk2.8-dev libfuse-dev libgtk2.0-dev ntfs-3g exfat-fuse exfat-utils byobu

What follows is an explanation of the packages.

nasm libwxgtk2.8-dev libfuse-dev libgtk2.0-dev: required to compile TrueCrypt, the last package libgtk2.0-dev will install a bunch of extra packages, do not be alarmed.
ntfs-3g: provides support for NTFS partitions.
exfat-fuse exfat-utils: provides support for exFAT partitions. I recommend exFAT over NTFS because, in my experience, the Linux NTFS driver is quite CPU hungry and the Raspberry Pi is not a abundant in that regard.
byobu: a terminal multiplexer (say what???), this package is not actually needed but it can become quite handy. Let me explain, the compilation of TrueCrypt may take a while (~40 min.) therefore it would be a good idea to use a tool which allows us to start processes in a SSH session, close the session, reconnect in a later time and reattach again to the process you left running. In case the SSH connection drops the compilation process would continue instead of stopping, note that you could accomplish a similar behavior using the standard nohup.

2. Download necessary files.

There are three sets of files to download: the TrueCrypt source code, the wxWidgets source code and the PKCS-11 headers. I tried to compile TrueCrypt using the wxWidgets provided by Raspbian but no luck, so better download source code as it mentions the TrueCrypt’s README file.

Since it is a good idea to create a directory and store everything at the same location, create it and change to it:
$ mkdir ~/truecrypt_files $ cd ~/truecrypt_files

Download wxWidgets:
$ wget https://sourceforge.net/projects/wxwindows/files/2.8.12/wxWidgets-2.8.12.tar.gz And extract it $ tar zxvf wxWidgets-2.8.12.tar.gz

Download the PKCS-11 headers in a sub-directory:
$ mkdir -p ~/truecrypt_files/pkcs $ wget -P ~/truecrypt_files/pkcs ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/*.h

Finally obtain the TrueCrypt source code for Linux. There is no direct link because you have to accept the license. Go to TrueCrypt source code download page and select Mac OS X / Linux (.tar.gz), accept the license and download it. Place the file into the Raspberry Pi in the folder we created above, you can use scp for such a task. For instance, if you downloaded the file in your local computer in the user’s Downloads folder:
(your computer) $ scp Downloads/TrueCrypt\ 7.1a\ Source.tar.gz pi@IpAddressOfPi:~/truecrypt_files

Once the file is in the Raspberry Pi, extract it, remember to be in ~/truecrypt_files:
$ cd ~/truecrypt_files $ tar xvzf TrueCrypt\ 7.1a\ Source.tar.gz

3. It’s compile time.

As mentioned above, I will use byobu, this is the crash course:

Execute byobu to start a new session.
Execute any command you like, it will run inside this session.
Press F6 to detach from the running session.
Execute byobu to reattach again to the running session.

Of course there is more to it but if you only have one byobu session that’s enough.

Just for fun, you can measure the time it takes to compile the packages by appending Bash 'time' command at the beginning of each instruction:
$ byobu $ cd ~/truecrypt_files/truecrypt-7.1a-source $ export PKCS11_INC="/home/pi/truecrypt_files/pkcs/" $ export WX_ROOT=/home/pi/truecrypt_files/wxWidgets-2.8.12 $ time make NOGUI=1 WX_ROOT=/home/pi/truecrypt_files/wxWidgets-2.8.12 wxbuild $ time make NOGUI=1 WXSTATIC=1

I hope everything went well and the compilation did succeed, you should have the TrueCrypt binary at ~/truecrypt_files/truecrypt-7.1a-source/Main/truecrypt; as a root copy it to /usr/bin and assign proper ownership and permissions:
$ sudo cp Main/truecrypt /usr/bin/ $ sudo chown root:root /usr/bin/truecrypt $ sudo chmod 555 /usr/bin/truecrypt

From now one we are going to extensively make use of sudo because many commands require root privileges. As usual, when a command needs to be executed as root it will be denoted by starting the line with # instead of $. You can either become root permanently by executing 'sudo -i' or insert 'sudo' at the beginning of each command as we have been doing so far.

4. Let’s encrypt something.

Plug the USB drive and find out its device name (e.g. use lsblk), in my case is /dev/sda.
Create the TrueCrypt container (I will not use any keyfiles):
$ truecrypt --keyfiles="" --protect-hidden=no --filesystem=none --volume-type=normal --create /dev/sda1

You will be asked to select the encryption and hash algorithms to use and a passphrase.

Load the container, you will be prompted for the passphrase:
$ truecrypt --keyfiles="" --protect-hidden=no --filesystem=none --volume-type=normal /dev/sda1

Format it using exFAT:
# mkfs.exfat -n DATA /dev/mapper/truecrypt1

Or, if you prefer, format it using NTFS:
# mkfs.ntfs -L DATA --fast /dev/mapper/truecrypt1

Unmount it:
$ truecrypt --dismount

Our USB drive is encrypted and formatted, it is time to create a permanent mount point. I will use the directory /external and assign public access plus the sticky bit:
# mkdir /external # chmod 777 /external # chmod +t /external

I will assume the filesystem used is exFAT if you are using NTFS replace 'exfat' by 'ntfs-3g'. Mount the TrueCrypt volume:
$ truecrypt --verbose --keyfiles="" --protect-hidden=no --slot=1 --filesystem=exfat /dev/sda1 /external

Do not use a password in the command line because it will show when listing the processes (ps -ef). If you want to write the password in the command line use the here-documment approach, e.g.:

truecrypt --verbose --keyfiles="" --protect-hidden=no --slot=1  --filesystem=exfat /dev/sda1 /external <
In that fashion the password will not show in the processes list still it will show in the command history. The best approach for not writing the password is to store it in a file owned by root and only accessible by him. At the beginning of this post I commented on the security risk of this approach however we cannot automate the process otherwise.

# echo 'HereWriteYourPassphrase' > /etc/volume.password

# chmod 600 /etc/volume.password

# truecrypt --verbose --keyfiles="" --protect-hidden=no --slot=1  --filesystem=exfat /dev/sda1 /external < /etc/volume.password
5. Don’t bother me: automating TrueCrypt mounting
The big issue: how do we auto-start the TrueCrypt mounting process? Currently cryptsetup is able to handle TrueCrypt containers however support started on version 1.6 and unfortunately the version available in Raspbian is 1.4.3 therefore we need an ad-hoc solution. I am very generous and instead of one I will give you two, both retrieving the passphrase from external files. The first solution is the simplest, it uses the the command of the above section in a script. The second solution is a bit more complex but it is extensible, it will use a LSB compliant init script, storing the truecrypt information in /etc/fstab.
5.1 Simplicity is beauty: simple auto-mount script.
In this approach we’ll use a simple script which will contain all the information except the volume’s passphrase which will be stored in /etc/volume.password. When the script is invoked without any arguments or with 'start' it will mount the TrueCrypt volume and it will unmount all TrueCrypt volumes when invoked with 'stop'. Error messages, if any, will be logged in /var/log/messages. 
/etc/init.d/simplemounttruecrypt.sh
#!/bin/sh
#
# Usage: simplemounttruecrypt.sh [start|stop]
#   no argument | start: Mount a truecrypt volume
#   stop:  Unmount all truecrypt volumes
#
# On success do not print any message
# On failure:
#      1. Record the failure in the temporal file /tmp/truecrypt.error
#      2. Append the error message along with the timestamp to /var/log/messages
#      3. Delete the file temporal file /tmp/truecrypt.error
PROTECT_HIDDEN=no
KEYFILES=""
SLOT=1
#FILESYSTEM=ntfs-3g
FILESYSTEM=exfat
VOLUME_PATH=/dev/sda1
MOUNT_DIRECTORY=/external
PASSWORD_FILE=/etc/volume.password

EXITSTATUS=0
case "$1" in
  ''|start)
    truecrypt \
      --verbose \
      --keyfiles=$KEYFILES \
      --protect-hidden=$PROTECT_HIDDEN \
      --slot=$SLOT  \
      --filesystem=$FILESYSTEM $VOLUME_PATH $MOUNT_DIRECTORY \
      < $PASSWORD_FILE \
      >/tmp/truecrypt.error 2>&1 \
    || EXITSTATUS=1 
    action=mounting
    ;;
  stop)
    truecrypt --dismount >/tmp/truecrypt.error 2>&1 \
    || EXITSTATUS=1 
    action=unmounting
   ;;
  *)
    echo "Usage: $0 [start|stop]"
    exit 3
    ;;
esac

if [ $EXITSTATUS -ne 0 ]; then 
  echo "$(date +"%b %_d %T") $(hostname) $0: ERROR $action device: $(cat /tmp/truecrypt.error)" >> /var/log/messages
fi

rm -f /tmp/truecrypt.error 2>/dev/null
exit $EXITSTATUS

Assign proper permissions and add it to the run levels:

# chmod 755 /etc/init.d/simplemounttruecrypt.sh

# insserv simplemounttruecrypt.sh

When executing insserv you may see several warnings because this script, and possible others, are not LSB compliant.
In order to remove the scripts from the init system execute:

# insserv --remove simplemounttruecrypt.sh

The flag -f forces the services remove even if the files still exist in /etc/init.d
5.2 Automating better: data, logic & LSB.
The previous script is good enough to work with however the script itself contains the information of the TrueCrypt volume. It would be better to separate the data (the info about the TrueCrypt volume) from the logic (the process to mount it). By doing so we can easily extend it to be able to handle any number of TrueCrypt volumes without modifying the logic and only adding more entries to the data files. Since we are in the improving path, we will enhance the script’s output by using the following trick: if it is invoked from a terminal it will output to the screen however if it is invoked by the system then the output will be redirected to the system log /var/log/messages. Finally, let’s also make it LSB compliant.
These are the three files used in this approach:

/etc/init.d/mounttruecrypt.sh

Script which mounts all truecrypt volumes defined in /etc/fstab using the passphrases stored in /etc/truecrypt.pass

The script will also unmount all truecrypt volumes.
/etc/truecrypt.pass

File,  which should be accessible only by root (i.e. chmod 600), containing a passphrase per volume using the following syntax:

device:Passprhase

Example:

/dev/sda1:This is a very good passphrase 49373!@#@!.;Mono
/etc/fstab

As you know, this file defines the filesystems, we are going to append the TrueCrypt definitions using the following syntax:

##truecrypt:device  mountPoint  filesystemType  filesystemMountOptions

Example using exFAT without any extra options:

##truecrypt:/dev/sda1   /external   exfat

Note that due to the use of fstab and truecrypt.pass we could add as many entries as we like without modifying the script. In fact, the script will walk through the '##truecrypt:' entries of fstab, retrieve the device name and fetch the passphrase for such a device from truecrypt.pass. You can read the logic below.
/etc/init.d/mounttruecrypt.sh
#!/bin/bash
### BEGIN INIT INFO
# Provides:          mounttruecrypt.sh 
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: mount/unmount truecrypt volumes from /etc/fstab
# Description:       on start  mounts the truecrypt 
#                        - volumes are specified in /etc/fstab 
#                        - passwords are defined in  /etc/truecrypt.pass
#                    on shutdown unmount all truecrypt volumes, not only the specified by fstab
#
#                    The entries of /etc/fstab must start by '##truecrypt:'
#                    Entries can be commented by introducing an extra #, i.e. ###truecrypt
#                    The rest of the line is the same as a fstab entry
#                    ##truecrypt:VOLUME_PATH  MOUNT_DIRECTORY   FILESYSTEM  options
#                    Example:
#                    ##truecrypt:/dev/sda1   /external   ntfs-3g options
#
#                    /etc/truecrypt.pass must contain a single line for entry with the format:
#                    volume_path:password
#                    Example
#                    /dev/sda1:MySuperPassphrase
#                    Make sure /etc/truecrypt.pass has permission 600
### END INIT INFO


#VARIABLES for the truecrypt volume
PROTECT_HIDDEN=no
KEYFILES=""
PASSWORD_FILE=/etc/truecrypt.pass

mount_all(){
    slot=0
    while read line; 
    do 
        read -a fields <<< $line
        VOLUME_PATH=${fields[0]}
        MOUNT_DIRECTORY=${fields[1]}
        FILESYSTEM=${fields[2]}
        OPTIONS=${fields[3]}
        slot=$((slot+1))

        truecrypt \
          --text \
          --verbose \
          --keyfiles=$KEYFILES \
          --protect-hidden=$PROTECT_HIDDEN \
          --slot=${slot} \
          --fs-options=$OPTIONS \
          --filesystem=$FILESYSTEM $VOLUME_PATH $MOUNT_DIRECTORY \
          < <(grep $VOLUME_PATH $PASSWORD_FILE | sed "s,^${VOLUME_PATH}:,,")  \
          | grep -v "Enter password for"

    done < <(grep '^##truecrypt' /etc/fstab | sed 's/##truecrypt://g')

}
# Function to redirect the output to syslog 
log_to_syslog(){
    # Temporal file for a named pipe
    script_name=$(basename "$0")
    named_pipe=$(mktemp -u --suffix=${script_name}.$$)
    
    # On exit clean up
    trap "rm -f ${named_pipe}" EXIT

    # create the named pipe
    mknod ${named_pipe} p

    # start syslog and redirect the named pipe
    # append the script name before the messages
    logger <${named_pipe} -t $0 &

    # Redirect stout and stderr to the named pipe
    exec 1>${named_pipe} 2>&1
}

# If the script does not run on a terminal then use syslog
set_log_output(){
    if [ ! -t 1 ]; then
        log_to_syslog    
    fi
}

case "$1" in 
    ''|start)
        EXITSTATUS=0
        set_log_output
        mount_all || EXITSTATUS=1
        exit $EXITSTATUS
        ;;
    stop)
        EXITSTATUS=0
        set_log_output
        truecrypt --verbose --dismount || EXITSTATUS=1
        exit $EXITSTATUS
        ;;
    restart|force-reload)
        EXITSTATUS=0
        $0 stop || EXITSTATUS=1
        $0 start || EXITSTATUS=1
        exit $EXITSTATUS
        ;;
    status)
        EXITSTATUS=0
        truecrypt --list 2>/dev/null || echo "No truecrypt volumes mounted"
        exit $EXITSTATUS
        ;;
    *)
        echo "Usage: $0 [start|stop|restart]"
        exit 3
        ;;
esac

Assign the appropriate permissions and add the service:

# chmod 755 /etc/init.d/mounttruecrypt.sh

# insserv /etc/init.d/mounttruecrypt.sh
In order to remove the service:

# insserv --remove /etc/init.d/mounttruecrypt.sh
By the way, if you have tried the simplemounttruecrypt.sh script and you want to use/try this new one remember to remove the previous:

# insserv --remove simplemounttruecrypt.sh 
The End.
In the next chapter we will set up the Nginx web server.

Find Pi Everywhere: FreeDNS a free Dynamic DNS service

thepadawan42 — Sun, 23 Mar 2014 10:08:02 +0000

Journey to the Clouds series.
2. Configuring Dynamic DNS using FreeDNS.

Dynamic DNS is what allows common mortals to have a domain name without paying for a static IP address. Why FreeDNS? Because it is free of charge, you only need an email address to register and to update the IP address it is as easy as it gets: execute a command. I will walk you through the process to create a domain and configure the Pi to update the IP address when needed.

Journey to the Clouds index:

Install Raspbian on a headless Raspberry Pi.
Configuring Dynamic DNS using FreeDNS.
Encrypting an external USB drive using TrueCrypt.
Setting up Nginx web server.
Setting up MySQL database.
Setting up PHP.
Installing ownCloud.

As you know, Domain Name System (DNS) converts names into IP addresses. Every time you connect to a web server you type a name (i.e. google.com) but you actually connect to an IP address (i.e. 74.125.28.105) behind the scenes the names are converted to an IP address so you don’t need to remember any number but just a catchy name. In that sense, the IP address is like the phone number of your router, so a DNS will act as a telephone listing where you look up for a specific name and it will tell you the associated “phone number”. Usually residential connections do not have a static IP address, that is, every now and then your IP address will change, thus dynamic. If you want to have a domain name you need to update the IP associated to it every time in changes, so it can be located; that is the objective of the Dynamic DNS providers, they keep the association Domain Name↔IP address up to date.

Less chit-chat and more chop-chop, head to the FreeDNS site and at the bottom of the page click on “Sign Up!” you will be presented with the following screen:

Once you fill it up, wait for the activation email and then you are set to go. To create a domain name click on “Registry” in the left menu. You will be presented with a list of possible server names, as shown below, choose the one you like most, note that your domain will be a sub-domain of the chosen one, that is, if you choose “info.tm” your domain will be “something.info.tm“.

Leave ‘Type‘ as it is, the IP address should be already there, you only need to come up with a good domain name. In the example above I wrote “raspberry.liar” because I am planing to have other XXX.liar domains, but you could simply write a name without any dots.

OK, you created your domain and now what? How does FreeDNS work? How does it update your IP address? FreeDNS assigns a unique identifier, a hash key, to your domain, when you want to update the IP your send a HTTP request along with your hash key. When FreeDNS receives such a request, it retrieves the IP address of the system sending the request (your router) and it updates it in its database for the associated hash key. The simple HTTP request have the following structure:
http://freedns.afraid.org/dynamic/update.php?HASHKEY

Therefore in order to update the IP we only need to send that sort of request when needed, that can be accomplished in different ways but in my opinion the easiest is to use wget in a cron job, both standard programs in all Linux systems therefore no extra packages are needed.

How do you find out which is your hash key? Click on ‘Dynamic DNS‘, scroll down to the bottom of the page until you see the domain you created, right click on ‘Direct URL‘ and copy the link location.

Paste the link in a text file and you will see something like:
http://freedns.afraid.org/dynamic/update.php?c29Q2s1Ml9df604bba2b1359ff62MTEyMT185e7=

The blue string is your hash key. Indeed if you (left) click on such link the IP will be updated, you can also execute wget to update the IP:
$ wget -q --read-timeout=0.0 --waitretry=5 --tries=400 http://freedns.afraid.org/dynamic/update.php?c29Q2s1Ml9df604bba2b1359ff62MTEyMT185e7=

Let’s have a command like that being executed by cron every five minutes. The following script will be a cron job that when started it will check the public IP address of the Pi, then check the IP address of your domain, if they don’t match it will send the HTTP request to FreeDNS to update it. All the actions are logged in /var/log/messages.

Script /etc/cron.d/freedns_update.sh replace DOMAIN and HASHKEY with your own values.

#!/bin/sh
# freedns_update.sh: Update the public IP on freedns.afraid.org only if it has changed.
## Place this script in the cron's job directory /etc/cron.d and assign the proper permissions
## and owner
## sudo chmod 500 /etc/cron.d/freedns_update.sh
## sudo chown root:root /etc/cron.d/freedns_update.sh
## Add to /etc/crontab to execute on reboot and every 5 minutes
## Edit /etc/crontab and append these two lines:
## @reboot root /etc/cron.d/freedns_update.sh >/dev/null
## */5 * * * * root /etc/cron.d/freedns_update.sh >/dev/null

#Use your own values
DOMAIN=raspberry.liar.info.tm
HASHKEY=c29Q2s1Ml9df604bba2b1359ff62MTEyMT185e7=

UPDATE_URL="http://freedns.afraid.org/dynamic/update.php?${HASHKEY}"
   
current_ip=$(wget -q --output-document - http://checkip.dyndns.org | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}')
registered_ip=$(ping -qn -c 1 $DOMAIN | head -n 1 | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}')

if [ "${current_ip}" != "${registered_ip}" ]; then   
   wget -q --read-timeout=0.0 --waitretry=5 --tries=400 --output-document /dev/null $UPDATE_URL
   if [ $? -eq 0 ]; then
     echo "$(date +"%b %_d %T") $(hostname) $0: IP address updated on freedns.afraid.org: new IP '${current_ip}', old IP '${registered_ip}'" >> /var/log/messages
   else     
     echo "$(date +"%b %_d %T") $(hostname) $0: ERROR IP address could not be  updated on freedns.afraid.org: current IP '${current_ip}', registered IP '${registered_ip}'" >> /var/log/messages
   fi
fi

As stated in the above script’s comments, create the script in /etc/cron.d, set the owner and permissions:
$ sudo chmod 500 /etc/cron.d/freedns_update.sh $ sudo chown root:root /etc/cron.d/freedns_update.sh

In order to execute every time the Raspberry Pi reboots and every 5 minutes append these two lines to /etc/crontab

@reboot root /etc/cron.d/freedns_update.sh >/dev/null */5 * * * * root /etc/cron.d/freedns_update.sh >/dev/null

Finally you have to configure your router to forward the ports you want to the Raspberry Pi. At this time only the SSH server is active so add a rule to forward whichever public port you like to private port 22 of the Raspberry Pi IP address. Once we set up the Nginx web server then you will also have to redirect the ports 80 and 443 but for now it is not needed not recommended.

For instance if you have set the public SSH port to be 4563 then you can connect, and follow the rest of the steps, by
$ ssh pi@raspberry.liar.info.tm -p 4563

Remember you can always add the appropriate entries to ~/.ssh/config.

In the next chapter we will install TrueCrypt version 6 and encrypt a USB drive, see you around.

Headless Pi Mess: Installing Raspbian

thepadawan42 — Sat, 22 Mar 2014 20:15:17 +0000

Journey to the Clouds series.
1. Install Raspbian on a headless Raspberry Pi.

In this post we will install Raspbian, a Debian based distro, in the Raspberry PI. Usually I’d go for Arch Linux but for this project I will side with Debian because the lower frequency of updates and therefore less maintenance once it is up and running. As a downside we will have to install TrueCrypt, PHP, Nginx and ownCloud either from source either from their repositories to take advantage from the latest packages.

Journey to the Clouds index:

Install Raspbian on a headless Raspberry Pi.
Configuring Dynamic DNS using FreeDNS.
Encrypting an external USB drive using TrueCrypt.
Setting up Nginx web server.
Setting up MySQL database.
Setting up PHP.
Installing ownCloud.

I will use my Linux box to flush the image onto the SD card and to connect to the Raspberry Pi through SSH, but you could use whatever OS that lets you sleep at night. Especially for the part of writing the Raspbian image onto the SD card, remember GIYF.

Grab the image from the Raspbian downloads site, at the time of writing this post the latest image is ‘2014-01-07-wheezy-raspbian’ and the direct links are the ones shown below:

Image http://downloads.raspberrypi.org/raspbian_latest
Torrent http://downloads.raspberrypi.org/raspbian_latest.torrent
SHA-1 Checksum 9d0afbf932ec22e3c29d793693f58b0406bcab86
Default login pi / raspberry

Once you get the image, verify the image with the SHA1 signature:
$ sha1sum -c <(echo "9d0afbf932ec22e3c29d793693f58b0406bcab86 2014-01-07-wheezy-raspbian.zip")

If you would like to optimize the SD card read this previous entry otherwise flush the image as described below.

Plug the SD card into your computer and find out the device name. In my opinion the easiest way it to execute lsblk, plug the SD card, execute again lsblk and spot the differences. However feel free to use fdisk -l, inspect the journal (journalctl -f) or the messages file for non-systemd (tailf /var/log/messages) or even use a graphical application like GParted. Whichever method you choose just make sure it is the SD card, don’t come crying later on if you messed it up.

In my case the SD card is assigned to /dev/sdb. In the following commands notice I am using the whole device (/dev/sdb) and not the partition (/dev/sdb1). If you have enough free RAM unzip on the fly and flush it all at once:
$ gunzip -c 2014-01-07-wheezy-raspbian.zip | sudo dd of=/dev/sdb bs=64K

Otherwise do it in two steps or it will hog your computer:
$ gunzip -k -S .zip 2014-01-07-wheezy-raspbian.zip $ sudo dd if=2014-01-07-wheezy-raspbian of=/dev/sdb bs=1M

If you want to monitor the progress you can open a new terminal, find out the PID of the dd command and send the USR1 signal to it. The output will show in the terminal where dd was launched.
$ sudo watch kill -USR1 $(pidof dd)

Next is to insert the SD into the Raspberry Pi but, since it is a headless installation, repress yourself from doing it just now and keep reading before proceeding. The way to find out the IP address of the Raspberry Pi is to list the IP addresses in your network before and after you connect it and compare the differences (the before-after-comparison again, it’s like the MAcGyver chewing gum). Of course you could always log into your router and see the connected devices if you prefer. If you, wisely, choose the path of the console, execute:

dirA=$(fping -i 10 -r 1 -aAgq 192.168.1.0/24 | tee /dev/tty) && \
echo -e "\nPlug the Raspberry Pi, wait at least one minute and press enter"; read novar && \
dirB=$(fping -i 10 -r 1 -aAgq 192.168.1.0/24| tee /dev/tty) && \
echo -e "\nNew IP address found:"; \
diff <(echo "$dirA" | sort) <(echo "$dirB" | sort) && echo "  |-> None"

As the black terminal says, and your are bound to obey because it is the black terminal, plug the Pi when it says so and wait for a minute, then hit enter. If everything went alright you should see the new IP. This is the output of my network:

192.168.1.1 192.168.1.19 192.168.1.12 192.168.1.20 Plug the Raspberry Pi wait at least for a minute and press enter 192.168.1.1 192.168.1.11 192.168.1.19 192.168.1.20 192.168.1.12 New IP address found: 1a2 > 192.168.1.11

Log into the Pi and finish the installation. As it was shown earlier, the default login for the image we installed is username: pi and password: raspberry
$ ssh pi@192.168.1.11 $ sudo raspi-config

Essential adjustments:
1 Expand Filesystem
3 Enable Boot to Desktop/Scratch
  |→ Console Text console, requiring login (default)
8 Advanced Options 
  |→ A3 Memory Split → 16

Recommended adjustments:
2 Change User Password
4 Internationalisation Options 
  |→ I2 Change Timezone
8 Advanced Options 
  |→ A2 Hostname

To my taste:
4 Internationalisation Options 
  |→ I1 Change Locale
      - deselect en_GB.UTF-8 UTF-8  
      + select en_US.UTF-8 UTF-8
      → Default locale for the system environment: en_US.UTF-8

Before rebooting, one final thing is to assign a static IP to the Pi, for that edit /etc/network/interfaces, comment out the line 'iface eth0 inet dhcp' and add the static definition. Below you have an example assigning the IP 192.168.1.106 to the Raspberry and declaring that the router IP is 192.168.1.1

Excerpt of /etc/network/interfaces #iface eth0 inet dhcp iface eth0 inet static address 192.168.1.106 netmask 255.255.255.0 gateway 192.168.1.1

If you don’t know how to edit that file type:
$ sudo nano /etc/network/interfaces
Make the changes, save by pressing ctrl+o and exit by pressing ctrl+x (then be a man and learn how to use vi).

Now you can reboot your Pi
$ sudo reboot

It is recommended to update the system after a fresh installation:
$ sudo apt-get update && sudo apt-get upgrade

Sit back and triumphantly exhale, you’ve done it!!!!!!

But as a bonus, let’s ingest a SSH candy and configure the SSH connection to simplify future log ins from your Linux computer. The following is to be done in your Linux box, not in the Raspberry Pi. If you don’t have an authentication key pair yet, generate one:
$ ssh-keygen -t rsa -f ~/.ssh/id_rsa_raspbian
Copy the public key to the Pi
$ ssh-copy-id -i ~/.ssh/id_rsa_raspbian.pub pi@192.168.1.106
Test that it works
$ ssh pi@192.168.1.106

Finally add the new entry in your SSH configuration file.

Excerpt of ~/.ssh/config # Entry for the Raspberry Pi Host pi_root User root #by default root access is not permitted in Raspbian Host pi User pi Host pi pi_root HostName 192.168.1.106 IdentityFile ~/.ssh/id_rsa_raspbian #Default values to all connections Host * ForwardAgent yes ForwardX11 yes PubkeyAuthentication yes

From now on, we can simply log in by typing
$ ssh pi

In the next chapter we will configure Dynamic DNS to access the Raspberry Pi from everywhere.

Journey to the Clouds: Launching a Headless Raspbian

thepadawan42 — Sat, 22 Mar 2014 20:14:44 +0000

In these posts series we will set up ownCloud on top of a LEMP stack, that is Linux (Raspbian), Nginx, MySQL and PHP. The storage to be used will be an USB drive encrypted using TrueCrypt and we will achieve Dynamic DNS through FreeDNS. With such a configuration we will get our very own Dropbox replacement that we will be able to control as we pleased. All that on a headless Pi, that is, no need for monitor nor screen. The only thing to do is to insert the SD card, the USB drive and connect it to the router.

Journey to the Clouds index:

Install Raspbian on a headless Raspberry Pi.
Configuring Dynamic DNS using FreeDNS.
Encrypting an external USB drive using TrueCrypt.
Setting up Nginx web server.
Setting up MySQL database.
Setting up PHP.
Installing ownCloud.

Using TrueCrypt has some caveats but it is compatible with all major operating systems, so you can always unplug the USB drive from the Raspberry Pi and plug it into a Windows computer with no much hassle.

The decision to use Nginx instead of Apache is due to the lightweight nature of the former, thus lower RAM consumption. More on that when we address its installation.

For the Dynamic DNS there are plenty of providers, some free of charge, some charging a little and some free of charge under certain conditions. FreeDNS has no charge at all and it only requires an email address to register. The Dynamic DNS configuration could definitely be the last topic but maybe you are going to find yourself away from the little Pi and you would like to guarantee remote access without having to ask your cat to tell you its IP address.

So let’s start… in the next chapter.

Are those processes talking to you? Kill them all!

thepadawan42 — Sat, 16 Nov 2013 11:26:30 +0000

This is not a very known feature of the killing command but it is possible to kill a process along with all its children, this is very convenient when a script spawns into several processes and you want to terminate all of them at once.
The key is to pass the PGID (the process group ID) with a minus sign in front:
$ kill -9 -PGID $ kill -- -PGID

Use 'ps -j' to list the processes’ PGIDs.

In the first example the SIGKILL (9) signal is sent to all the processes belonging to the process group ID denoted by PGID. When using PGID you must state the signal to be sent, if you want to send the default TERM (15) signal then you can use a double hyphen '--' as shown in the second example.

How does it work? Well, the first created process has as PGID the same value as its PID (process ID), afterwards each newly created child-process will inherit the PGID of the parent. Therefore, the most of the times you can simply execute:
kill -- -{PID_of_the_first_process}

To list the processes’ PPID and PGID use the command ps with the flags -f and -j respectively.

Let’s see a very simple example. We’ll create a C program that the only thing it does is to delay for some seconds and then call such program from a couple of scripts. These are the listings:

test.c

main(){
    sleep(600);
}

parent.sh

#!/bin/bash
./test parent &
./test parent &
./child.sh

child.sh

#!/bin/bash
./test child &
./test child &
./test child

Open a terminal, compile the C program and execute the parent.sh script:
$ gcc -o test test.c $ ./parent.sh

Now, in another terminal let’s see the processes:
$ ps -efj | grep '[U]ID\|[p]arent\|[c]hild' UID PID PPID PGID SID C STIME TTY TIME CMD stewie 4562 3715 4562 3715 0 14:07 pts/6 00:00:00 /bin/bash ./parent.sh stewie 4563 4562 4562 3715 0 14:07 pts/6 00:00:00 ./test parent stewie 4564 4562 4562 3715 0 14:07 pts/6 00:00:00 ./test parent stewie 4565 4562 4562 3715 0 14:07 pts/6 00:00:00 /bin/bash ./child.sh stewie 4566 4565 4562 3715 0 14:07 pts/6 00:00:00 ./test child stewie 4567 4565 4562 3715 0 14:07 pts/6 00:00:00 ./test child stewie 4568 4565 4562 3715 0 14:07 pts/6 00:00:00 ./test child
What do we see here? We have two Bash scripts and five 'test' programs running. The parent.sh has PID 4562 which is the PGID of all the processes. Note that the 'test' programs started by 'child.sh' have a different PPID but the same PGID. If we wanted to terminate all the processes at once, it would not work to kill the parent process you can verify this by executing kill on the parent.sh PID:

$kill 4562 $ ps -efj | grep '^[U]ID\|[p]arent\|[c]hild' UID PID PPID PGID SID C STIME TTY TIME CMD stewie 4563 1 4562 3715 0 14:07 pts/6 00:00:00 ./test parent stewie 4564 1 4562 3715 0 14:07 pts/6 00:00:00 ./test parent stewie 4565 1 4562 3715 0 14:07 pts/6 00:00:00 /bin/bash ./child.sh stewie 4566 4565 4562 3715 0 14:07 pts/6 00:00:00 ./test child stewie 4567 4565 4562 3715 0 14:07 pts/6 00:00:00 ./test child stewie 4568 4565 4562 3715 0 14:07 pts/6 00:00:00 ./test child

Only parent.sh was terminated, the rest of processes are still alive. Try now to use the PGID instead:
$ kill -- -4562 $ ps -efj | grep '^[U]ID\|[p]arent\|[c]hild' UID PID PPID PGID SID C STIME TTY TIME CMD
Now we have killed them all, and yes, we are bad asses.

Finally, it is worth noting that your shell may have a built-in kill command, in fact the most common shells like bash, dash, mksh, zsh, tcsh do have it. If kill does not behave as expected it may be due to that and you should call kill using the full path (use which to determine it). The only universal way I am aware of for finding out if a command is built-in is to read the manual page (e.g. man bash); however shells usually have utilities to query the nature of a command, here is a small list

bash:	type -a kill
mksh:	type -a kill (type is equivalent to whence -v)
zsh:	type kill (type is equivalent to whence -v)
dash:	type kill
tcsh:	where kill

This GRUB does not start (in Ubuntu)

thepadawan42 — Mon, 11 Nov 2013 08:32:14 +0000

This is the situation, for some unfortunate reason your Ubuntu system crashed, maybe there was a black out, maybe your cat seeking more attention unplugged the computer. In any case, at some point the computer is switched back on but it does not automatically start, it stays in the GRUB’s selection menu waiting for any entity, usually a humanoid form of it, to hit enter.

That’s fine if it is your main computer, but what about if it a headless server in the other side of the city (or the room)? Well, this falls in the category of “not a bug but an undocumented feature” kind of thing. To be all fair, it is somehow documented here, long story short, in Ubuntu after a failed boot/crash GRUB is designed to stay in the selection menu. Is there a way to disable such a behavior?

The Ubuntu documentation explains the old way to get rid of this “feature”. From 12.04 (Precise Pangolin) and above, there is a simpler way, that is to define the GRUB_RECORDFAIL_TIMEOUT variable in /etc/default/grub:

GRUB_RECORDFAIL_TIMEOUT=0 # disables the menu, boots right away
GRUB_RECORDFAIL_TIMEOUT=-1 # waits until the user selects an entry, default behavior
GRUB_RECORDFAIL_TIMEOUT=XX # XX in seconds, waits for that amount of time before proceeding

After modifying /etc/default/grub you will have to update grub configuration file, as root:
$ sudo update-grub

By the way, as far as I have seen this affects only the Ubuntu family, the original GRUB package does not provide this behavior, in fact, GRUB_RECORDFAIL_TIMEOUT is not part of the GRUB’s configuration options, Ubuntu modifies it to support this functionality.

Listing built-in modules

thepadawan42 — Thu, 11 Jul 2013 09:29:30 +0000

Have you ever wondered how to list the built-in kernel modules? Here you are, they are in the file modules.builtin. Now it is easy to check if a module is built-in or not, grep will suffice:
$grep module_name /lib/modules/$(uname -r)/modules.builtin

Too short? OK keep reading for a longer modules’ tale.
As you already know, the Linux kernel is the software that controls the computer’s hardware and it is composed by an essential core and optional modules. These optional modules, sort of “add-ons”, expand the kernel capabilities and give support to a big variety of hardware, for instance a webcam or a scanner. The modules can be statically built into the kernel or dynamically loadable.

The external loadable modules are usually located under /usr/lib/modules/ in a directory named after the kernel released, therefore in order to list it use 'uname -r':
$ ls /usr/lib/modules/$(uname -r)

These kind of modules can be loaded (modprobe), unloaded (rmmod) and listed (lsmod). On the other hand, built-in modules do no accept any of those actions. They are always loaded, they cannot be unloaded and they cannot be listed. Being always loaded does not mean they are always active (in use), a module can be loaded but it will be active only when it is required. For example, suppose that your webcam’s module is built-in, then it will always be loaded but only active (being used) when a program (e.g. Skype) uses the webcam.

Part of the kernel building process is to configure it, that is, to select which features we will activate or deactivate, for that matter a configuration file is used defining for each feature if it will be enabled or not. There is no one-to-one correspondence between features and modules; a feature may have associated zero, one or more modules. For instance, the ext4 filesystem support requires the single module ext4 but the support for SGI Ultraviolet systems requires 5 modules (tlb_uv, bios_uv, uv_irq, uv_sysfs, uv_time).
For each feature the configuration file define three possible values:

"y": the feature is enabled, all associated modules will be built-in.
"m": the feature is enabled, all associated modules will be externally loadable.
not enabled: the feature will not be supported, this state is indicated either by removing the entire line either by commenting it out with “#”

It is quite common for the different Linux distros to distributed this configuration file along with the kernel, this is normally done either as a regular file either under the (runtime) /proc filesystem.

Regular file
This is the approach followed by Debian and its derivatives (like Ubuntu). The kernel package includes the text file /boot/config-$(uname -r), for example to query if the kvm_intel feature is enabled:
$ grep -i kvm_intel /boot/config-$(uname -r)

/proc filesystem
Many other distributions, like Arch Linux, enable the option to include the running kernel configuration within the /proc filesystem. In this case the file is a compressed text file located at /proc/config.gz, you can use the zcat/zgrep utilities to inspect it; for instance:
$ zgrep -i kvm_intel /proc/config.gz

The final piece of the puzzle is to establish the relationship between features and kernel modules. Bad news: this relationship is not stored anywhere. Good news everyone: you can obtain the info from the Linux source code. In the Linux sources, the MakefileS contain lines such as:
obj-$(CONFIG_XXX) += module_1.o module_2.o

As you may have guessed, the above line means that the feature ‘XXX‘ requires the modules ‘module_1‘ and ‘module_2‘, therefore creating your local “database” is simply a grep command:
$ cd /path/to/linux/sources $ grep -R --include=Makefile 'obj-$(CONFIG_.*\.o.*' . | sort -u > feature_modules.txt

Now you can easily look for modules and features:
$ grep CONFIG_ZRAM feature_modules.txt ./drivers/staging/zram/Makefile:obj-$(CONFIG_ZRAM) += zram.o

As a side note I will add that modprobe will not fail when loading a built-in kernel hence another (empirical) way to assert if a module is built-in consist in loading the module using modprobe and if it does not fail then try to list it using lsmod, if the module is not listed then it is built in. In bash:
$ module=XXX; $ modprobe ${module} &>/dev/null; if [[ $? -ne 0 ]]; then echo module ${module} does not exist; elif [[ $(lsmod | grep -cw ${module}) -eq 0 ]]; then echo ${module} is built-in; else echo ${module} is loadable module, NOT built-in;fi

That was a long mambo-jumbo but is there any practical application in all this? Why should you care if a module is built-in or not? That’s a good question and the answer is: let’s hope you don’t need it. This is another tool for troubleshooting so unless something is not working you should not care. A scenario could be when something in your computer (e.g. the Wi-Fi) does not work in distro-1 (e.g. Debian) but it works in another distro-2 (e.g. Knoppix), so you think it is a module issue and decide to compare between both distros the loaded modules to find out which is one you are missing. Such an attempt will fail if the Wi-Fi module is built-in as it will not be listed in lsmod and you will just get crazy wondering which spell distro-2 casts for the Wi-Fi to work.

SSH candies: config, copy-id, keygen.

thepadawan42 — Sun, 16 Jun 2013 05:39:04 +0000

There is a time when being cool it is simply too much work. Sure we all want to impress a newbie by typing long cryptic commands in a black screen and then say “I’m in”, but at the end of the day, let’s accept it, we don’t have many visitors except the little nephews who are lurking around trying to use our machines to surf porn. In this post we’ll see how to reduce our number of keystrokes when connecting through ssh by the usage of configuration files.

As you know, ssh accepts many input parameters and usually you will type them in the command line, for instance:
$ ssh -i ~/.ssh/id_rsa_lab.pub bender@10.1.1.42

In the above example we are saying to ssh to connect to '10.1.1.42' using the username 'bender' and the keyfile '~/.ssh/id_rsa_lab.pub'. All those options could be saved in the ssh configuration file and avoid typing them, so we can simply execute something like:
$ ssh lab

And so it begins. OpenSSH uses two default configuration files (/etc/ssh/ssh_config and ~/.ssh/config) but you could use any file you like and pass it to ssh through the option '-F'. The configurations options are loaded in the following order:

Command line arguments, options passed directly to ssh when invoking it, for example ssh -Y
~/.ssh/config: user default configuration file, this file only applies to the current user.
/etc/ssh/ssh_config: global file for all users and all connections; only the admin can modify it.

Once a parameter is set its value will not change, in other words, if the same option is given multiple times with different values, ssh will use the first value and ignore the rest. Having that in mind it is easy to understand that command line arguments override the settings of the personal ssh configuration file (~/.ssh/config) which in turn also override the settings provided by the global configuration file (/etc/ssh/ssh_config). The same principle applies inside each configuration file and therefore global settings should be always located at the end of the files.

The ssh configuration file is divided in entries, each entry sets the specific options for a given server and it starts by the keyword 'Host' followed by a name, that name will be the alias of the connection that you will use to invoke it. Actually, it is not a name but a pattern so you could define entries like 'Host lab*', more on this in a second. If you want to specify global options for all the connections use the '*' wildcard, that is, 'Host *'. As usual, comments are entered by ‘#’ symbol and blank lines are ignored.

The following is a simple configuration file:

Host lab
  HostName 10.1.1.42
  User bender
  PubkeyAuthentication yes
  IdentityFile ~/.ssh/id_rsa_lab

#Options applicable to all connections
Host *
    ForwardAgent yes
    ForwardX11 yes

The first entry (Host lab) sets the options to be used for the server denoted as 'lab' the address is 10.1.1.42, the user name is 'bender', it should use public key authentication and the key is the file '~/.ssh/id_rsa_lab'.
The second entry (Host *) sets the parameters global to all connections, in this case: use X11 forwarding (so we can start graphical applications) and forward the ssh-agent credentials (that is for another post).

If now we want to connect to 10.1.1.42 we will simply type:
$ ssh lab
which is equivalent to
$ ssh -i ~/.ssh/id_rsa_lab -X bender@10.1.1.42

Using patterns we can avoid duplicate options, let’s say we want to define another connection to the same server 'lab' but for a different user, this time for root. We could create a new entry having all the same fields except User or we could use a pattern that will match both defintions. For instance, we can define 'lab' for the regular user, 'lab_root' for the root and use the pattern 'lab*' for both. Remember to always put first specific options and then the more general ones.


#Options only for the regular user
Host lab
  User bender
#Options only for root
Host lab_root
  User root
#Options applicable for both, the regular user and the root
Host lab*
  HostName 10.1.1.42
  PubkeyAuthentication yes
  IdentityFile ~/.ssh/id_rsa_lab

#Options applicable to all connections
Host *
    ForwardAgent yes
    ForwardX11 yes

To connect as a root simply type:
$ ssh lab_root

Most likely, you will be prompted for a password, this is normal, you need to install your public key into the target server. And this is what starts making all this very useful: all ssh programs will use the settings of the configuration files; from now on we will be very cheap with our keystrokes (saving them for important usage like playing HHGTTG). If you don’t have a key pair yet it is time to generate the default set, to be honest, the key generation should have been the first step but that was a boring way to start a post.

Generating default RSA key pair:
$ ssh-keygen -t rsa
This will generate the following keys:
~/.ssh/id_rsa: private key, keep it safe.
~/.ssh/id_rsa.pub: public key, which you will install onto the servers you want to connect to.

Note: if you enter a passphrase instead of leaving it blank then you should make use of ssh-agent. I’ll discuss passphrases and the ssh-agent in a following post.

Since I am bit paranoid, I usually create a key pair for each server I want to log into. For that you need to specify the output file otherwise the default keys (id_rsa, id_rsa.pub) will be overwritten. For example, for the server 'lab' I will generate:
$ ssh-keygen -t rsa -f ~/.ssh/id_rsa_lab
This will generate the following keys:
~/.ssh/id_rsa_lab: private key.
~/.ssh/id_rsa_lab.pub: public key to install in 'lab'.

Continue generating as many keys as your paranoia level dictates and lets you sleep at night.

The actual key installation consist in appending the public key to the file '~/.ssh/authorized_keys' of the target system, you can do this manually (by editing the file) or faster and easier by using ssh-copy-id:
$ ssh-copy-id -i ~/.ssh/id_rsa_lab.pub lab
This is equivalent to:
$ cat ~/.ssh/id_rsa_lab.pub | ssh bender@10.1.1.42 'cat >> ~/.ssh/authorized_keys'

No passwords should be requested anymore when connecting to 'lab' or copying files to/from it. Try it by creating a file and copying it:
$ touch test.txt $ scp test.txt lab:~/

That was a very simple usage but yet it is very convenient. What else can you configure? Everything really, all the input parameters that ssh accepts can be statically set in the configuration files. To spice things up, let’s use the config file to define ssh multi-hop connections, that is to access a system through another system. Let’s take as an example my home set up.

As you can see from the above picture, in my house I have set up a PC (actually a virtual machine) named 'firewall' as the solely entry point to my network. In order to connect to the rest of systems I will always connect through 'firewall' and therefore I only have to configure my router to open a single port instead of one port per machine. (The router should be configured to use dynamic DNS and to forward all incoming traffic on port 40022 to 192.168.1.200 port 22).

If I intent to connect from the office or from a public place (e.g. a cafeteria), the entries for such a scenario will look like this:

Host firewall
  HostName firewall159357.dyndns.org
  Port 40022
  User cartman
  PubkeyAuthentication yes
  IdentityFile ~/.ssh/id_rsa_firewall

Host mycomputer
  HostName 192.168.1.201
  User stewie
  PubkeyAuthentication yes
  IdentityFile ~/.ssh/id_rsa_mycomputer
  ProxyCommand ssh firewall nc %h %p 2>/dev/null

Host pi
  HostName 192.168.1.203
  User raspberry
  PubkeyAuthentication yes
  IdentityFile ~/.ssh/id_rsa_pi
  ProxyCommand ssh firewall nc %h %p 2>/dev/null

The first entry, 'Host firewall', defines how to access my LAN, it configures the connection to the machine 'firewall'; this connection will be used by the rest of the entries. 'Host mycomputer' specifies how to connect to my computer and 'Host pi' how connect to the Raspberry Pi. The key here for the ssh multi-hop is the 'ProxyCommand' where we use 'nc' (netcat) to transparently send and receive data through a ssh connection. ProxyCommand is briefly explained in the manual page of ssh_config and this article gives a very good explanation about the use of netcat and the ProxyCommand.

Installing now the public keys is a piece of cake:
$ ssh-copy-id -i ~/.ssh/id_rsa_firewall.pub firewall $ ssh-copy-id -i ~/.ssh/id_rsa_mycomputer.pub mycomputer $ ssh-copy-id -i ~/.ssh/id_rsa_pi.pub pi

And to connect simply:
$ ssh pi
Compare that with the cumbersome command line equivalent:
$ ssh -i ~/.ssh/id_rsa_pi -X raspberry@192.168.1.203 -o 'ProxyCommand ssh -i ~/.ssh/id_rsa_firewall -X cartman@firewall159357.dyndns.org nc %h %p 2>/dev/null'

Likewise, copying files is straight forward:
$ scp localFile pi:~/remoteDirectory $ scp pi:~/remoteDirectory/remoteFile ~/localPath/

It is clear the advantage of spending a bit of time setting your ~/.ssh/config. Consult the manual (man ssh_config) for a complete list of available options. Of course, you should memorize all the full commands to be prepared for a zombie break out or simply to show off in front of lamers picking into your screen (in this latter case do not forget to lean back and loudly exhale saying ‘FBI here I am’).

Finally, as a sweet end of post, an easy way to remove stale entries from ~/.ssh/known_hosts file. First of all, what is that file? For security reasons, the first time you connect to a server ssh will retrieve its digital fingerprint and store it in that file, afterwards every time you connect again to the same server, ssh will dynamically retrieve the server’s fingerprint and compare it against the stored value. If the values don’t match then ssh will refuse to proceed and it will abort. For a given system the digital fingerprint will always be the same, the problem arises when the same IP address refers to a different system, this is typically the case when you install a new operating system into the same machine and give the same IP address as it had before. In such an example the following will occur:

$ ssh pi
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
aa:df:df:57:53:4f:53:c2:a4:38:bf:b7:11:8d:4b:3e.
Please contact your system administrator.
Add correct host key in /home/bender/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/bender/.ssh/known_hosts:2
ECDSA host key for 192.168.1.203 has changed and you have requested strict checking.
Host key verification failed.

If you are certain the new fingerprint is valid then you should remove the entry for 192.168.1.203 which corresponds to the line number 2 of known_hosts (or alternatively, if you have no security concerns, become a Rambo and delete the whole file). You can edit the file with your favorite editor and remove such a line or you can use 'sed':
$ sed -i '2d' ~/.ssh/known_hosts
I prefer to use the OpenSSH utility ssh-keygen:
$ ssh-keygen -R 192.168.1.203

Here is where we should all hail ssh-keygen obscurity! Who would think that a program named '-keygen' had the ability to remove anything? Anyway, that’s it.

Tutti Frutti: 7zip + KDE + Arch Linux

thepadawan42 — Wed, 29 May 2013 11:35:22 +0000

I like 7zip, it is a free (LGPL), fast, simple but powerful, multi-platform file archiver (aka compressor). In every computer I use I always install it. Here is the thing, in Arch Linux under KDE it does not work out of the box (a penny for each time I say this sentence). It actually has two problems: it does not start (this is the main issue) and the Dolphin’s context (right-click) menu has duplicate entries. The later is simply annoying, the former is frustrating.

For the impatient archers:
# pacman -S wxgtk2.8 # rm /usr/share/kde4/services/ServiceMenus/p7zip_compress2.desktop

2014-04-22 Update: Originally this post mentioned the wxgtk package however currently the required package is wxgtk2.8. On 2014 Arch Linux, following upstream development, updated it from version 2.8 to version 3.0 but some applications, among them 7zip, still require the older 2.8 version to work and therefore the package wxgtk2.8 was introduced.
Thank you Tobias.

For those who like to waste their time reading stupid troubleshooting stories because they don’t have other better things to do while their consoles update to the latest firmware, keep on.

The reason 7zip was not starting was a missing library, how do you find out? If you launch 7zip from the terminal you will get the following exotic error:
$ 7zFM /usr/lib/p7zip/7zFM: error while loading shared libraries: libwx_gtk2u_adv-2.8.so.0: cannot open shared object file: No such file or directory

This is one of the easiest troubleshooting cases, the error is telling us which library we miss. Next step is to find out where such a file resides; for such a task we will use pkgfile (in Ubuntu/Debian the equivalent is called apt-file). pkgfile creates a database with all the packages’ files therefore you can search afterwards which package provides file X (tururururuuuuuuu).

If you don’t have it installed yet, you know what to do:
# pacman -S pkgfile
Update the database, that is, let pkgfile to create a database with all the packages’ information. The man page advises us to have the following in a cron job:
# pkgfile -u

Now look for the file (search is the default action):
$ pkgfile libwx_gtk2u_adv-2.8.so.0 extra/wxgtk2.8 multilib/lib32-wxgtk2.8

There are two packages that provide such a file, the native 64 bit version and the package for the 32 bit compatibility layer. I just installed the 64 bit version because I only install software on a need basis:
# pacman -S wxgtk2.8

I searched in the bug tracker and I found it has been reported several times as a bug (26225, 31584) however the 7zip maintainer has a different stand, he explains that 'wxgtk2.8' is listed as an optional dependency for the GUI and therefore you should install it if you’d like to have the graphical interface. I disagree, if 7zip cannot be started in KDE out of the box, then it should not install the KDE launch menu entry neither the Dolphin’s context menus, of course I also admit that I should have paid more attention to the 7zip’s optional dependency field when I installed it in the first place.

For the duplicate Dolphin entries the troubleshooter was Mr. Google and the credit for the fix goes to Juan’s answers.

FreeBSD 9.1 on VirtualBox: FAIL!!!

thepadawan42 — Fri, 24 May 2013 16:57:14 +0000

My first attempt to try out a BSD was a failure by default: the default VirtualBox settings don’t work. I started VirtualBox, created a new machine for FreeBSD 9.1, loaded the CD ISO, run it and enjoyed an infinite reboot loop. It seemed the little demon Beastie was laughing at me, now I understand the mascot…

Fortunately, Tom did already the investigation and found the solution: change the system motherboard from PIIX3 to ICH9. After that change the installation started but in the middle of it always aborted. I found out that it required more than the default 128 MB of RAM that VirtualBox gives for the new machine; I increased the memory to 512 MB and the installation finally was successful. Both parameters can be set in the VM settings System → Motherboard.