Due 11:59 PM, Friday, March 14, 2014
In this lab, you will start with a "clean" system and install the Ubuntu Linux OS, Server edition. You will go through all basic configuration options, including the network configuration. Finally, you will recompile the Linux kernel with a set of minimal configuration options.
You may do the lab alone, or with one partner. If you work with a partner, only one student will hand in the assignment for you. Be sure to list both partners' names on the handed-in assignment.
We will provide you with a virtual machine and an Ubuntu server disk. You will access the machine's virtual console through the VMware vSphere client, which is accessible from the department's terminal server, or from any windows machine in a computer science lab.
Each student will be given a virtual machine on the OS teaching cluster which you should use to complete the assignment. You will have root access to this machine, as you will install the OS on it, and be able to install additional tools (editors, debuggers, etc) as you see fit.
Good citizenship. You have administrator access to this VM and can install anything you like. That said, to keep load down, DO NOT INSTALL A GRAPHICAL DESKTOP on the VM. You may tunnel the X protocol (ssh -X) to your local machine and display your editor in a window.
Warning: It is highly advisable that you take a checkpoint of your VM as you complete exercises. If something goes horribly wrong, you won't lose your work, and can instead roll the VM back to a working state. The button to take a checkpoint in vSphere is next to the button you used to power on the VM.
Additional notes on checkpointing your VM are posted here.
When you are ready to hand in your lab code and write-up, upload the following to blackboard under Lab 2:
Note: Within a few days, the system administration staff will clone your VM, which will temporarily take it offline.
Because cloning the VM is a somewhat involved procedure, please do not submit multiple times unless the change in your grade will be substantial.
In this and all other labs, you may complete challenge problems for extra credit. If you do this, please include in your handin text a short (e.g., one or two paragraph) description of what you did to solve your chosen challenge problem and how to test it. If you implement more than one challenge problem, you must describe each one.
This lab will be graded on a 20 point scale.
The common procedure to install an operating system on a new computer is to load an installation program from removable media, such as a CD-ROM or USB flash drive, or over the network (a procedure called PXE-booting). In this lab, your virtual machine will be connected to a virtual CD-ROM device, from which you will boot the installer.
Initially, you will need to access your VM via VMware's vSphere client. Later in the lab, you will set up other remote access tools. There are some helpful notes on using vSphere here.
Use a remote desktop client to connect to ts1.cs.stonybrook.edu:22. Use CS\netid to log in, using the same password you use for department email. Note, you can use remote desktop to access ts1 from anywhere in the world---you do not need to be in any particular lab to do this assignment.
This will connect you to a remote desktop session on a Windows server. Once you are connected, launch the vSphere client application. Select the vm server assigned to you, eg. esx6sc.cs.stonybrook.edu, esx8sc.cs.stonybrook.edu, or esx9sc.cs.stonybrook.edu and again use your CS department credentials.
Once you have logged in, click on "Inventory", then select your VM from the list. The name will include your netid. Right click on it, and select "Open Console." Click the green "Play" button to start the VM. This will boot the virtual machine, which is configured to access the virtual CD-ROM device for the first boot. Similar to the demonstration in class, you will follow the dialog on the CD to install the system.
In order to get a full screen console, click the button labeled "launch client console". Also, if you need to release your mouse from the console, press Ctrl+Alt.
Exercise 1. (2 points) Complete the basic Ubuntu installation procedure. Follow the instructions from the lecture slides, and you are welcome to consult other online resources if you have questions.
Be sure to configure the network to obtain its IP address using DHCP.
Once you have a basic system up and running you should immediately install any pending updates using apt, lest your system have unpatched security vulnerabilities.
Once you have the basic system installed, you should install and configure the OpenSSH implementation of secure shell (ssh). The installation dialog may offer to install SSH for you, which is ok as well.
You can learn more about OpenSSH configuration by reading the manual.
Important note: The firewall blocks direct access to port 22. You should instead configure your ssh daemon to listen on port 130. After you change the configuration file, you need to reload the configuration, using sudo service ssh reload.
Once you have installed SSH, verify that you can connect via ssh from an outside machine, using a command like:
ssh porter@130.245.120.2:130
where you substitute your newly created user ID and IP address for what is listed above. If this works, you have ssh working properly.
Exercise 2. (4 points) Create an account for the TA on your system. Please use a very strong password, and you will not need to share this with the TA over email or any other medium.
Please make the account name exactly the string 'ta' to simplify grading.
Instead, you will configure this account to permit ssh access via a public key without a password (specifically the one here. An account can permit multiple public keys, so you can also create your own keypair to test that the keypair setup is working.
Hint: To use public keys, read the manual entries for ssh-keygen and the Authorized Keys format section of the ssh manual. Type man ssh-keygen and man ssh.
After ssh works, you no longer need to use vSphere---you can just ssh directly from your personal computer, which is generally more responsive than running a virtual desktop.
A common source of attacks on Linux systems are brute-force, scripted password guessing. In other words, there are attack scripts that look for Linux hosts and try as many common account names (e.g., root, guest, the name of the system), with brute force password guesses. Left unchecked, the attacker may guess a system password and break into the system. Or, if you are lucky, just waste loads of CPU time and network bandwidth on fruitless guesses.
Thus, a common defense strategy is to block machines, by IP address and hostname, after too many incorrect guesses. A common utility that does this on Linux is called denyhosts. It is a simple script that monitors the authentication log (/var/log/auth.log), and adds entries to files including /etc/hosts.deny.
Exercise 3. (4 points) Install and configure denyhosts. You can verify that it works by attempting to log in from a public computer (say at the library) with a bad password. After 5 tries, it should refuse to allow any more attempts.
One drawback of the default denyhosts configuration is that it is very draconian. For instance, after 5 total failed attempts, a machine gets blocked. Yet users commonly mistype passwords. A more suitable default is to reset the counter after a successful login. In other words, a better configuration is to block a host after five consecutive failed login attempts.
Configure your denyhosts system to only block hosts after 5 consecutive failed logins, rather than 5 total.
Note: after changing a configuration, you will need to restart the denyhosts service. For this to work, you should learn to use init scripts. On Ubuntu, you can use the service command---read the manual to learn how it works.
Although one can configure a password for the administrator to log in, Ubuntu generates a random password by default. Instead, one uses sudo to issue commands as root selectively. This dramatically reduces the risk of mistyped commands harming the system, as well as weak root passwords being guessed. For a system with multiple administrators, sudo also logs commands, which can help with diagnosing errors. Finally, sudo allows otherwise unprivileged users to issue certain commands, as the administrator sees fit.
In order for the TAs to be able to grade the assignment, you need to read the manual for sudo and configure the TA account to have unrestricted system access. By default, users with administrative access must enter a password; since the TAs won't know their password on the machine, you should allow the TA to bypass password authentication in sudo.
Important note: Be sure to put any configurations for the TA after this line of /etc/sudoers
%sudo ALL=(ALL) ALL
Exercise 4. (1 point) Grant administrative permission via sudo to the TA user on your system. Be sure this does not require a password. Also, be sure to test that this works via a command like:
sudo su ta sudo cat /var/log/auth.log
Because clock manufacturing technologies are imperfect, no two clocks keep time exactly in sync. This is also true of the clocks in your computers.
This creates a problem for Linux software, such as make, that uses time and can span multiple computers. In other words, if a network file server and a client have different times of day, the result of a make compilation can be incorrect.
Thus, most computer systems include a tool to deal with this problem, called clock skew. In the case of Linux, the most common utility is the Network Time Protocol Daemon, or ntpd. An NTP daemon checks a time server periodically to identify the current time of day. These checks are frequent enough to keep the clock skew minimal.
Exercise 5. (1 point) Configure your system to use NTP for time synchronization. Any public NTP server is fine. Be sure you are running the daemon, and not just the client.
One particularly nice touch as an administrator is having the system email you if something goes wrong, say during a daily or weekly maintenance task. Even better is when you combine a disk (SMART or RAID) monitoring utility with this.
It is actually surprisingly easy to set up an email server to send mail only, but not acting as a full-fledged email server (i.e., not accepting or relaying mail from outside, not servicing mail clients, etc.).
We recommend using the exim4 mail server, but you are welcome to use a differnt one.
After you have done a basic apt install, use the command
dpkg-reconfigure exim4-configto modify the configuration. Set the system to deliver mail by a smarthost only. Keep all other settings the same, except list the smarthost as smtp.gmail.com::587.
At this point, you need a full-fledged mail server to deliver these messages. In order to reduce spam, most mail servers will not accept email from an untrusted sender. Fortunately, it is fairly easy to create a throw-away gmail account. Create a new, temporary gmail account (don't use your personal gmail account).
To configure exim to use the gmail account information, you must create the file /etc/exim4/passwd.client, and fill it with the appropriate contents (and set permissions appropriately---it should be readable by group Debian-exim, and not world readable). Read the manual to identify the format of this file.
Finally, you need to tell the system your email address. You do this by creating an entry in /etc/aliases, aliasing root to your personal email address.
Once this is done, restart the exim4 service, and test that it works:
exim -v 'root' (type a message, when finished, type Ctrl-D)
If the email is delivered, your setup is working. If not, check your spam folder, check for bounce messages in your forwarding gmail account, and check the local exim logs for error messages.
Exercise 6. (4 points) Configure your system to email root messages to your personal email account, as described above.
Challenge! (2 bonus points) Configure your system to print using CUPS and the sshlpr backend. This backend can use ssh public keys to tunnel print commands to another system.
In this case, create a keypair to use on the CS department server compute.cs.stonybrook.edu, and get local printing to print to a department printer.
The final task you will do in this assignment is configure and build your own custom Linux kernel. This will also be discussed in class, but we will summarize the essential steps here.
First, install the kernel-package tools, as well as an ftp client (I recommend ncftp).
Then use the file transfer protocol client to download the latest kernel from ftp.kernel.org.
Once you have downloaded the kernel, unpack it using tar -jxvf kernel-(version).tar.bz2.
Change into the unpacked kernel, and run make menuconfig. Here you can select different options through a curses-based interface. You can enable and disable different options, and press escape when you are finished to exit and save.
You can also copy a known-working configuration from /boot and then type make oldconfig. For this exercise, start by doing this.
Once your kernel is configured, you can build it as a debian/ubuntu package using make-kpkg linux_image --rootcmd fakeroot --initrd --append-to-version=(your custom version name) . Once the build is complete, you can manually install using sudo dpkg -i (your new kernel).deb.
Exercise 7. (4 points) Build and install a working, custom kernel, according to the directions above.
Challenge! (2 bonus points) We will award 2 bonus points to the team with the smallest, working kernel configuration. By smallest, we mean the fewest number of selected options in the kernel configuration (this generally also leads to a smaller kernel binary).
This completes the lab. Hand in the assignment as explained above. The system staff will clone your VM a few days after you hand in the assignment via blackboard, which temporarily takes the VM offline. After the VM is cloned for grading, you may use it to complete lab 3.
Last updated: 2014-05-09 22:40:26 -0400 [validate xhtml]