ISE-311 (Spring 2010) Homework Assignment #3 Handout number 5 (100 points, 15% of your overall grade) Version 3 (4/27/2010) Due Saturday 5/8/2010 @ 11:59pm *** HARD DEADLINE -- NO EXTENSIONS *** * PURPOSE: To learn about storage reliability and email services. * TASK: This assignment has three sub-tasks: Linux CentOS and RAID-5 installation, a Mail and collaboration system setup and configuration, and firewall setup. They are described in detail below. ============================================================================== 1. Install CentOS 5.4 with RAID disks and test RAID [30 pts]. You can use the ISO image in /home/ise311/CentOS-5.4-i386-bin-DVD.iso. This time, setup four SCSI disks of 10GB each (use the LSI Logic controller type, not the older BusLogic one). Configure the disks as a RAID-1 and RAID-5 setup (three disks) plus leave the fourth disk as a Hot-Spare drive. Setup one small /boot partition and the rest a large root partition, no swap, and 256MB RAM (note, Zimbra may require 512MB or more to properly start, so you can use more as needed, but keep it as low as possible). No USB or sound devices. Use bridged networking. Use one virtual IDE CD-ROM device to boot/install the system. Use the same dedicated hostname/IP you've used in HW2 (don't forget DNS, netmask, default route, etc.). Be sure to fully update/patch your system. Setup NTP to synchronize your system time. Install only the packages needed and no more, to keep the system small. You may use HW1 as a starting point, but you must install a brand-new, fresh system. Setup the 'root' user on your VM with the standard root password (from /home/ise311/.r). Partition each of the disks into two partitions: partition 1, type Linux RAID, should be 100MB in size; partition 2, also type Linux RAID, should be the rest of the space. Combine /dev/sda1, /dev/sdb1, /dev/sdc1, into a RAID-1 setup (mirroring); this'll be your /boot partition. Combine /dev/sd[abc]2 partitions into RAID-5 (striping): this'll be your root (/) partition. Use /dev/sdd[12] as your hotspare disks/partitions, respectively. Why Hotspare? A RAID-5/RAID-1 will be configured with three disks (/dev/sda, /dev/sdb, and /dev/sdc), and using /dev/sdd as a hot spare. If, for example, /dev/sdb fails, then the RAID software will automatically start using /dev/sdd to replace the failed /dev/sdb. However, the switchover won't happen right away: RAID needs to "rebuild the array" in order to replace the failed drive with the hot spare. You are to test that array rebuild and hot-spares work well (we will test it too as part of grading). To test it, you can use the "mdadm --manage" command to force a disk to be marked as a bad disk (same as if an actual hard-disk died on you). After you mark a disk as bad, run "cat /proc/mdstat" to see the status of your array (esp. the rebuilding process). ============================================================================== 2. Setup Zimbra Collaboration Suite, configure/test it [50 pts]. Zimbra is a suite of tools for Unix/Linux/MacOS systems, which includes a secure mail server, Active Directory server, Web Mail, anti-spam/anti-virus, a Web management interface, integrated calendaring and mobile device sync, and more. Setting it up is not easy, but it is much easier than trying to install all of the individual components yourself, and configuring them. In many ways, Zimbra is the Unix equivalent to Microsoft Exchange. If you know how to install and configure Zimbra, you'd be able to install MS-Exchange one day. Go to www.zimbra.com, and download the binary tarball for the 32-bit package for Red Hat Enterprise Linux 5. The latest one as of 4/16/2010 is called zcs-6.0.6_GA_2324.RHEL5.20100406144520.tgz, but there may be a newer one released soon. Unpack it in your VM, read the documentation, and follow the instructions to install it. After you install Zimbra successfully, delete the tarball and the directory you unpacked it into, to save space. I strongly advise you to snapshot your VM before installing Zimbra for the first time. It is likely that something will go wrong and you'd have to undo the installation and try again (the first time I installed Zimbra I had to revert the snapshot and repeat the installation five times until I got it perfectly right!) Tips: - The Zimbra version you install was intended to RHEL5, but your system is a CentOS, an RHEL clone. You'll have to tell the Zimbra install script to override its checks and proceed with the installation anyway. (Otherwise you get an error and the installation aborts.) - If the Zimbra installation script reports an error or warning, and it aborts, then you should fix what it complains about, then try to reinstall. If the re-installation fails, you may have to revert to an early snapshot, fix what Zimbra complained about, and then install it afresh. - The Zimbra installation will ask you lots of questions during installation. For the most part, you can choose the default answers. That is, think carefully before you choose to change a default answer. - if your CentOS system already has a Web server or mail server installed, turn them off to avoid conflicts with Zimbra. - you must install the "postfix" package before installing Zimbra, or else the installation fails. During Zimbra's installation, you'll be asked to setup a password for admin. Use the common password from "cat /home/ise311/.r" as was done in previous homework assignments. If all works well during Zimbra's installation and you got no errors, then reboot. Once the system comes up, you will have to wait for Zimbra to complete its initialization. You can "tail -f /var/log/messages" to see its progress. Zimbra is a collection of multiple servers, and it takes time to initialize and start up. Even after a system has fully booted, Zimbra continues to come up in the background: it can take as much as 5-10 minutes more for it to complete. So be patient. Once Zimbra is up, login using its secure Web interface to your personal VM, and start configuring it. Create a user account called "jdoe" (full name John Doe); setup a password for that jdoe user that's the same as the admin user. Then, login as a the regular "jdoe" user, and test the email. Let's say that your personal VM host is named "myname.oslab.cs.sunysb.edu" (where "myname" is your personal hostname assigned to you). First, send an email from jdoe@myname.oslab.cs.sunysb.edu to your personal email account (say, gmail, IC, yahoo, hotmail, etc.): test that the mail was received. Second, send an email from an external email account (your personal IC, Gmail, etc) to jdoe@myname.oslab.cs.sunysb.edu and check that it got there. If both emails got through, then your email system has been setup correctly. Third, test the anti-spam and anti-virus system. Login as your normal OSLAB user, on vmpool directly, and try to send an email to jdoe@myname.oslab.cs.sunysb.edu, with a binary executable attachment such as an EXE: the Zimbra anti-virus system should block this email. You can use the "mutt" utility on vmpool to send attachments. Fourth, from the vmpool machine, try to send an obvious spam to to the jdoe@myname.oslab.cs.sunysb.edu account. You can be creative in composing a spam message, or pick one from the 'net and try to forward it. WARNING: do not try to send spam, even for testing purposes, from Gmail, IC, or your regular email accounts. If you do so, your GMail/IC accounts may be turned off! NOTES: - You may have to train the anti-spam system's Baysian rules to recognize spam vs. ham (non-spam). Otherwise the system may not properly classify spam vs. non-spam. Study the documentation for Zimbra on how to do that. - To debug incoming/outgoing email issues, check /var/log/messages and /var/log/maillog to on your myname.oslab host, and any other logs that Zimbra keeps around. (Zimbra likes to install itself into /opt, so its logs may be there too, and not necessarily in /var/log.) - In order for mail to be delivered to your individual VMs, I've already added MX records in DNS for each of your personal VMs. ============================================================================== 3. Setup firewall [20 pts] Reconfigure SSH to run on port 130. Allow the firewall to access port 130. Check which ports Zimbra needs to use for various services (SMTP, secure Web mail, Web management interface, IMAPS, POP3S, etc. You can use "nmap" to scan for ports on your system, but be careful not to enable unnecessary ports. Setup the f/w to allow access to ONLY the ports that are needed to Zimbra to work and be manageable remotely. Note: some of Zimbra's management ports may be in the 7000 range, far above the normal reserved ports (1-1024). Incoming access should be allowed only from campus networks (130.245.0.0/16 and 129.49.0.0/16). If you work from home, you may add 1-2 rules to allow access from specific IP addresses you use at home/work (be careful not to allow, for example, any Optimum Online host in). Note: the OSLAB firewall has been reconfigured to allow ALL access to each of your individual hosts from 130.245.127.51 to 130.245.127.132. Therefore, if you have access issues, it is more likely to be due to your firewall setup. * COLLABORATION For this assignment, you may work alone, or in groups of up to four (4) students. Groups larger than four are not permitted. All group members must be declared by email to me (the instructor) by Thursday 4/22/2010 at 11:59pm: your email should include the full name, Stony Brook ID number (SBID#), and OSLAB User IDs of all group members. In addition, your VM must include a short /root/README file that describes briefly what you have done (up to one page max), and list all group members, their names, and SBIDs. Failure to follow these group declaration procedures will impact your grade. If you work in a group, only one user should submit the assignment. All assignments will be graded without considering the size of the group. However, at the end of the semester, when I assign final course grades, I will take into account who worked on HW3 in groups, and the group size. People who worked alone or in small groups may be given special consideration for grading (e.g., if someone worked alone on HW3, and their final course grade is borderline between two letter grades, I may "bump" the student's grade to the higher letter grade). There is no set formula I use for deciding when/how/if to account for group sizes. * SUBMISSION To submit, you will execute a script which would make a copy of your virtual machine for us to run. The script archives and compresses your VM using GNU tar, then emails you and the instructor a short log to let you know what was submitted, how large, and when. To determine if you submitted on time, we will use the last modification time of the submitted archive and the email message which is sent at the END of submission. Follow these instructions: 1. Shutdown your VM. 2. Delete most of you snapshots to ensure that your VM is as small as it can be. You may leave 1-2 snapshots at most, but preferably none. 3. Run the script /home/ise311/submit-hw3.sh and follow the instructions. Notes: - The larger your VM is, the longer it'll take to submit it, so keep it as small as you can. Copying several gigabytes of data can easily take 10-15 minutes, more if the system is overloaded while everyone's submitting at the same time. - Deleting snapshots can take a long time, esp. if you have many of them. So don't start this five minutes before the deadline. While it is a good idea to keep snapshots you can revert to, once you are sure that something you did worked, you can delete the snapshots before that point. In other words, keep only 1-2 snapshots for the most recent unstable changes you've done. Once you're sure you've gotten a part of the system working, you can delete previous snapshots. - I prefer no snapshots in submissions, but if you keep 1-2, that's fine. I don't want to see a large number of huge snapshots (5+ taking many gigabytes of space). - you may submit as many times as you want, but we will grade only the last one submitted (with late-submission penalties as appropriate). * EXTRA CREDIT No extra credit for this assignment. Good luck. * Change History: 4/17/2010: first version 4/18/2010: minor typos fixed; make /boot use RAID1 4/19/2010: change typo (/proc/mdadm -> /proc/mdstat) 4/22/2010: mention setup NTP 4/27/2010: mention more ram for Zimbra; use LSI Logic adapter type