CS4610: Linux Notes

Setting Up Your Own Linux Host

There is nothing magic about the ohmmkeys — they are just Ubuntu 11.04 workstations (as VMWare virtual macines) with some extra packages installed. It will likely be very helpful if you want to install Ubuntu on your own physical or virtual machines.

Once you have Ubuntu installed, just run the following commands to install the extra packages:

> sudo apt-get install ntp
> sudo apt-get install build-essential libusb-1.0-0-dev
> sudo apt-get install cmake mercurial git subversion 
> sudo apt-get install doxygen graphviz
> sudo apt-get install python-yaml python-setuptools
> sudo apt-get install wget traceroute x2x
> sudo apt-get install avr-libc avrdude
> sudo apt-get install gcc-doc libstdc++6-4.5-doc make-doc cpp-doc
> sudo apt-get install sun-java6-jdk (must enable "canonical partner" repositories first in synaptic)
> sudo apt-get install minicom ckermit
> sudo apt-get install guvcview

Then follow the instructions in the Orangutan SVP user manual to set chip_erase_delay to 55000 for m324p and m1284p in /etc/avrdude.conf.

Optional:

> sudo apt-get install emacs23
> sudo apt-get install eclipse
> sudo apt-get install gimp inkscape transfig pstoedit
> sudo apt-get install mplayer

Installing ROS

Later in the course we will likely be using ROS. The download is very large, so you may want to wait until we begin using it. Following the instructions here and here:

> sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu natty main" > \
  /etc/apt/sources.list.d/ros-latest.list'
> wget http://packages.ros.org/ros.key -O - | sudo apt-key add -
> sudo apt-get update
> sudo apt-get install ros-electric-desktop-full
> sudo apt-get install ros-electric-openni-kinect
> echo "source /opt/ros/electric/setup.bash" >> ~/.bashrc . ~/.bashrc

Tweaks for a Virtual Machine on a Flash Drive

If you specifically want to run ubuntu from a VMware virtual machine on a USB flash drive, like the ohmmkey, you may want to make a few optimizations that seem to significantly improve performance. These only apply to running from a flash drive; we do not recommend any of these for a regular virtual machine stored on your hard drive. First, set these values in the VMware VMX file:

mainMem.backing = "unnamed"
mainMem.useNamedFile = "FALSE"
logging = "FALSE"
# suppress the "I moved it/I copied it question" (always moved)
uuid.action = "keep"

Then boot the VM and make these edits in the indicated files:

/etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=noop"
/etc/fstab: tmpfs     /tmp    tmpfs   defaults,noatime,mode=1777  0   0

The first one sets the “elevator” to “noop” which can help resolve stuttering behavior due to the default disk IO scheduler (elevator). The second puts /tmp on a ramdisk, which increases the speed of access to the temporary but frequently modified files that many programs automatically put there. Finally run

> sudo update-grub

and reboot.

Changing/Setting Hostname

/etc/hostname: your-special-hostname
/etc/hosts: 127.0.1.1 your-special-hostname

Scripts

Passwordless SSH

Especially when working with svn over ssh, you really want to set up passwordless access. Say you want to ssh from a “client” machine, like Ubuntu running in vmware on your ohmmkey, to a “server”, like login.ccs.neu.edu.

  1. On the client machine run the command

    > ssh-keygen -t dsa
    

    If you have already done this at some point in the past, you do not want to do it again. If you are not sure, check if the file ~/.ssh/id_dsa.pub exists (~ is shorthand for your home directory) — if it does, you had run ssh-keygen before.

  2. Now copy the generated public key to the server. On the client machine, run the command

    > scp ~/.ssh/id_dsa.pub <server-dns>:~/<client-name>-id_dsa.pub
    

    whhere is e.g. login.ccs.neu.edu and is e.g. ohmmkey.

  3. Now ssh in to the server (using your password still) and run the commands

    > mkdir .ssh
    > cat <client-name>-id_dsa.pub >> ~/.ssh/authorized_keys
    > rm <client-name>-id_dsa.pub
    > chmod 700 .ssh
    > chmod 600 .ssh/*
    

    The mkdir command will give an error message if ~/.ssh already exists, but this is harmless.

  4. Return to the client and try to ssh in to the server again — you should not be prompted for a password.

Remote X Window Display

The X.org display system now used in Linux is a descendant of a very old windowing system architecture called X11, or just “X”. A key design aspect of this system is that it is fundamentally a client-server architecture. You may be used to thinking of interacting with web “servers” as remote machines, with your local desktop machine the “client”. In the X system, the X server is a daemon (background service) program running on your desktop, i.e. on the computer with the monitor to which graphics should be displayed. X clients are all programs that want to display graphics in windows: web browsers like firefox, terminal programs, video players, etc. When you run such a program, it implicitly checks the value of the DISPLAY environment variable, which has the format [server]:d[.s]; server can be the DNS name or IP address of the machine running the X server, which does not need to be the same as the machine running the client program. It can also be “localhost” or omitted, in the common case that both the X client and server are on the same machine. d and the optional s are integers that can be used to select which part of a multi-screen display should be targetted; they are usually both 0 unless you know you need something else.

So, it seems that if we want to run an X client program, like xterm, on one machine (let’s call it client), and have it display on (possily another) machine server, then it should suffice to run these two commands on client:

> export DISPLAY=server:0.0
> xterm &

Once upon a time, that would have worked, almost. Even in the old days there was a security mechanism: on the server you would have had to run

> xhost +client

to indicate that incoming X connections from client should be accepted. (Here we are using client and server as standins for the corresponding DNS names.)

Unfortunately, nowadays increased security means that the above steps alone usually do not work. Also, networks are now often relatively complex; the above example assumes that both client and server can “see” each other on the network. In practice, it is now common to have “local subnets” like 192.168.1.* which, to machines outside the subnet, appear as a single address corresponding to a router machine running network address translation (NAT, which used to be called “IP Masquerading”, possibly a more informative name). Machines inside a local subnet can see out, but unless special arrangements are made, they cannot be seen from the outside.

Remote X display is usually still possible despite these challenges.

Connecting from server to client

The usual situation is that you are sitting at the machine running the X server (server, e.g. your home machine), and you SSH from there to client (e.g. login.ccs.neu.edu; note that we are using the server and client terms to refer to the “backwards” X connection; the SSH connection is actually from server to client.) client needs to be visible from server (but not vice-versa), and client also needs to be running an ssh server. Ubuntu desktop editions to not come with SSH server installed by default, but it can be easily added simply by running

sudo apt-get install openssh-server

(this both installs the ssh server and starts it, or does nothing if it’s already installed and up to date). There are only two steps needed in this common server-to-client use case:

  1. Make sure X11Forwarding is set to yes in /etc/ssh/sshd_config on client (this requires root perms on client to change, of course).
  2. On server run

    > ssh -X -C [user@]client
    

    which will log you in to client with X forwarding enabled. Then on client you can run

    > echo $DISPLAY
    

    which should return a value like localhost:10.0. This may seem confusing; what is happening is that ssh has arranged a tunnel so that when you run an X client program like

    > xterm &
    

    on client, it will connect to a special port on client that is tunneled back to the X server on server, all through the SSH connection.

Connecting from client to server

It is less common, but possible, to do this all the other way around, i.e. to start on client (e.g. your panda), establish an ssh tunnel to server (e.g. your ohmmkey), and then run X client programs on client that display on server. It is trickier to set this up. Assuming server is running Ubuntu 11.04, here is a recipe:

  1. Make sure that server is visible over the network from client (i.e. you should be able to ping server from client). If server is actually a virtual machine (like your ohmmkey), you will either have to configure it to use “bridged” networking (not “NAT”; this is an easy switch in VMWare settings, and does not even require a reboot), or you can install a secondary network interface device, like a USB wifi dongle, that you ask VMWare to connect directly to the virtual machine. The first option requires that the VM have privlidges to connect directly to the external network (which will not work on managed networks like at CCIS unless we ask the sysadmins to allow the virtual machines directly onto the network). The second option enables the VM to potentially connect to the same wifi router to which client (e.g. your panda) is connected, thus putting them both on the same local subnet.

  2. Make sure that openssh-server is installed and running on server (see above).

  3. Download this file and copy it to /etc/iptables.rules on server:

    > sudo cp iptables.txt /etc/iptables.rules
    > sudo chmod 644 /etc/iptables.rules
    > sudo chown root:root /etc/iptables.rules
    
  4. Download this file and copy it to /etc/NetworkManager/dispatcher.d/01firewall on server:

    > sudo cp firewall.txt /etc/NetworkManager/dispatcher.d/01firewall
    > sudo chmod 755 /etc/NetworkManager/dispatcher.d/01firewall
    > sudo chown root:root /etc/NetworkManager/dispatcher.d/01firewall
    
  5. That puts a simple but effective firewall in place, in a way that plays nicely with the NetworkManager service, because in a moment we are going to be opening the X server port and we don’t want just anyone to be able to connect. Start the firewall for the first time by running

    > sudo /etc/NetworkManager/dispatcher.d/01firewall foo up
    
  6. Edit the file /etc/gdm/custom.conf on server (create it if it doesn’t exist). Add the lines

    [security]
    DisallowTCP=false
    

    and then run

    > sudo service gdm restart
    

    on server. Warning: this will immediately restart X, which will effectively log you out. You only need to do this configuration once ever on server.

  7. Log in graphically and run

    > xhost +
    

    on server (this will be forgotten when you log out). This step and the last two have opened the X server TCP port 6000, which would allow any X client to connect, if it were not for the firewall. The firewall only allows local X clients (i.e. those that appear as if they originate from server itself), but still allows incoming ssh connections.

  8. Finally, on client run

    > ssh -f [user@]server -L 6010:server:6000 -N
    > export DISPLAY=localhost:10.0
    > xterm &
    

The first command establishes an SSH tunnel from the X server port 6010 on client to that port on server; the second tells X client programs on client to connect to that local port (the convention is that the port number is 6000+d where d is the display number, here 10), which will be tunneled back to server.