Speech:Spring 2013 Systems Group


 * Home
 * Semesters
 * Spring 2013
 * Proposal
 * Report

Groups

 * Proposal Draft Group
 * [Systems Group]
 * Experiment Group
 * Tools Group
 * Data Group
 * Modeling Group

Group Member Logs

 * Michelangelo Bianchi
 * Brian Drouin
 * Tyler Martin
 * Michael Tormos

To Do's
Proposal for a Clonezilla backup solution

Summary

The UNHM CIS790 capstone class is using a system comprised of ten interconnected servers to run speech recognition software on an open source Linux operating system (OpenSUSE 12.2). The main server, a Dell PowerEdge 2650 with the hostname of Caesar, serves as the systems NFS repository with all other clients (Dell PowerEdge 1750s) in the stack sharing Caesar’s 500GB of hard drive space in a mounted configuration. This system will become increasingly prone to hardware failures as the equipment ages. With an estimated 200 hours of transcripts and all other data derived through the production of language models it’s essential to not only back up the data but the entire system through imaging.

In a traditional file backup only specified data is copied to external space, however, imaging software creates an entire backup of a drive which captures everything currently running in a production system. Imaging the system will eliminate timely restoration effort as it can recover the running configuration as well as the programs that are currently installed.

Benefits

1.	A complete backup of the entire system configuration 2.	Reduced downtime in the event of a failure 3.	Easily performed by system technicians 4.	This is a free solution (depending on if external HDD space can be acquired)

Scope

This backup project will also serve as the foundation backup solutions in the future and will provide information for future classes on how to orchestrate a backup using this outline methodology.

Methodology:

As specified on the clonezilla site their software cannot backup a mounted system. We will have to shut down in order to perform the backup. A backup will occur during a scheduled maintenance period in which the system can be powered down.

Confirm you have the correct path name before executing commands! Failure to do so could cause loss of data or your GNU/Linux not to boot!!! /dev/sdd is a device path name /dev/sdd1 is a partition path name

1.	Download the Clonezilla Live zip file. 2.	If you already have a FAT16 or FAT32 partition on your USB flash drive then skip to the next step (3). Otherwise prepare at least a 200 MB partition formatted with either a FAT16 or FAT32 file system. If the USB flash drive or USB hard drive does not have any partition, you can use a partitioning tool (e.g. gparted, parted, fdisk, cfdisk or sfdisk) to create a partition with a size of 200 MB or more.

Here we assume your USB flash drive or USB hard drive is /dev/sdd (You have to comfirm your device name, since it's _NOT_ always /dev/sdd) on your GNU/Linux, so the partition table is like:

Disk /dev/sdd: 12.8 GB, 12884901888 bytes 15 heads, 63 sectors/track, 26630 cylinders Units = cylinders of 945 * 512 = 483840 bytes Disk identifier: 0x000c2aa7
 * 1) fdisk -l /dev/sdd

Device Boot     Start         End      Blocks   Id  System /dev/sdd1  *           1       26630    12582643+   b  W95 FAT32

Then format the partition as FAT with a command such as "mkfs.vfat -F 32 /dev/sdd1"

WARNING! Executing the mkfs.vfat command on the wrong partition or devic could cause your GNU/Linux not to boot. Be sure to confirm the command before you run it.

mkfs.vfat 2.11 (12 Mar 2005)
 * 1) mkfs.vfat -F 32 /dev/sdd1

3.	Insert your USB flash drive or USB hard drive into the USB port on your Linux machine and wait a few seconds. Next, run the command "dmesg" to query the device name of the USB flash drive or USB hard drive. Let's say, for example, that you find it is /dev/sdd1. In this example, we assume /dev/sdd1 has FAT filesystem, and it is automatically mounted in dir /media/usb/. If it's not automatically mounted, manually mount it with commands such as "mkdir -p /media/usb; mount /dev/sdd1 /media/usb/".

4.	Unzip all the files and copy them into your USB flash drive or USB hard drive. You can do this with a command such as: "unzip gparted-live-0.4.5-2.zip -d /media/usb/"). Keep the directory architecture, for example, file "GPL" should be in the USB flash drive or USB hard drive's top directory (e.g. /media/usb/GPL).

5.	To make your USB flash drive bootable, first change the working dir, e.g. "cd /media/usb/utils/linux", then run "bash makeboot.sh /dev/sdd1" (replace /dev/sdd1 with your USB flash drive device name), and follow the prompts. WARNING! Executing makeboot.sh with the wrong device name could cause your GNU/Linux not to boot. Be sure to confirm the command before you run it.

NOTE: There is a known problem if you run makeboot.sh on Debian Etch, since the program utils/linux/syslinux does not work properly. Make sure you run it on newer GNU/Linux, such as Debian Lenny, Ubuntu 8.04, or Fedora 9.

TIP:  If your USB flash drive or USB hard drive is not able to boot, check the following:

Ensure that your USB flash drive contains at least one FAT partition. Ensure that the partition is marked as "bootable" in the partition table. Ensure that the partition starts on a cylinder boundary. For the first partition this is usually sector 63.

Risk Analysis

This is a low-risk project as it doesn’t change any of the configurations of the system. The only risk is the downtime required in which the backup will occur.

Project Coordination

The systems team will coordinate a scheduled maintenance schedule and will ensure that the class is aware of the outage prior to the maintenance event.

Clonezilla Backup Procedure:

Requirements:
 * CD or USB with clonezilla installed
 * External hard drive for storing the image


 * Download the ISO clonezilla from http://clonezilla.org/ on to a CD
 * Use a program such as nero to burn to a disc
 * Insert the disc
 * Boot off the server and go into bios
 * Change the boot settings to disc
 * Enter to continue
 * Choose your language
 * Select “don’t touch key map” and hit enter
 * Start clonezilla
 * Select device image work with discs or partitions using images
 * Select USB local device (external HDD)
 * Hit enter on the default “Do you want to use a USB drive as a clonezilla repository”
 * Select your hard drive
 * Choose the directory in which you want to save the image to
 * Save the entire disc
 * Name the image
 * Select the disc that you’re backing up from (The server’s OS disc) and hit enter to continue
 * Click yes when asked if you’re sure you want to continue
 * After the backup has been completed, you’ll be prompted to either reboot or shutdown
 * Select reboot (and boot into windows) and your disc will be ejected and your image

Restoral Procedure:


 * Insert the clonezilla disc
 * Boot off the server and go into bios
 * Change the boot settings to disc
 * Enter to continue
 * Choose your language
 * Select “don’t touch key map” and hit enter
 * Start clonezilla
 * Select device image work with discs or partitions using images
 * Choose the local hard drive in which the image is located
 * Find the directory that contains the image
 * Use beginner mode
 * Instead of Saving the entire disc, choose “restore disc”
 * Choose the image file to restore
 * Select the drive that you want to restore
 * You’ll be asked if you’re sure twice. Click yes through both prompts.

Proposal For OS Update

Summary:

As of Spring 2013, The UNHM Capstone Project class has full use of 10 file servers (9 of which feed off of the main server, Caesar) with which they can use to conduct speech recognition experiments on with the use of a program called Sphinx. The operating system that Caesar uses is OpenSUSE 11.3, this system seems to function well with the needed experiments and also easily enables one to SSH into Caesar and the 9 other drives. It should also be noted that this system works well with the RAID array that has been set up to protect the data contained on them in case of drive failure (this was very helpful when Caesar’s hard drive failed one week in mid-February). However, OpenSUSE 11.3 is an old system that is no longer supported by its developers and not only has outdated drivers, but also has an older Linux kernel as well. It should also be noted that OpenSUSE 11.3 only has basic security features such as password entry and a "partially" functional version of AppArmor (as noted by OpenSUSE themselves in the 11.4 release notes).

A newer system such as Fedora 18 will have updated drivers along with a more recent Linux kernel (3.6 as opposed to 2.6). Fedora 18 also has better security features such as the ability to easily work with an active directory (which is what the class wants to use to enable individual logins to the system) and the ability to run programs in "sandboxes" (secure containers that will not affect how the system or other programs work). Sandboxes are created through the use of SELinux (Security-Enhanced Linux), which not only sets user policies but also limits what programs and processes can do with the system itself. The installation of the system should also be easy enough as it can be downloaded for free onto a blank DVD or a USB drive and installed onto Caesar. It has also been established that Fedora 18 will work on the 10 machines (especially after the proposed memory upgrade from another Systems team member) and will support LDAP and the current RAID array as well. It should also be noted that Fedora 18 also comes with an updated version of the Perl scripting language, which will improve upon how to write scripts as it has a better debugger and will have improved coding as well.

Benefits:
 * 1. Newer system will be faster and can handle more programs
 * 2. Still supports RAID and LDAP
 * 3. Is more secure than the current system
 * 4. Updated drivers will help programs to run smoother
 * 5. Will still work with the programs and languages that we use
 * 6. Perl update will improve scripting for Sphinx.
 * 7. Active Directory is also supported.

Scope:

The update will serve to keep the project experiments running smoothly and patch up whatever "major" bugs the current system has. The update will also make the system more secure so that the OS does not become corrupted again or face other security/system issues in the future.

Methodology:

The method that we will use for installing and testing Fedora will follow these steps that the Installation guide for Fedora 18 suggests:


 * 1. A Fedora 18 ISO image will be downloaded onto a computer that has the capability to burn DVDs.


 * 2. The ISO image will then be burned onto a blank DVD that, upon a successful DVD burn will then be inserted into Caesar's CD drive.


 * 3. The system will need to be taken down for a while as the Systems team will need to restart the computer and boot it from the DVD (done by hitting F10 at startup) in order to run the installer.


 * 4. Caesar will boot up using the DVD and the "Install Fedora" option will be selected. The GUI Install will be used, as Fedora strongly recommends installing with the use of a GUI.


 * 5. All of the general settings (Date/Time, Language, etc.) will be taken care of and the network will be set up so that the system can interact with UNHM's Internet connection and allow students to access the system via SSH (which according to the guide is setup during installation).


 * 6. The desktop environment will be decided on as well [it will most likely be GNOME].


 * 7. The system will be partitioned either by the team or automatically before being installed, a /boot, /swap, /root and /home partition may need to be made as well. After the program has been told where to install the OS, the installation process will begin.


 * 8. The root password to log into the system will also be set as well. When the installation finishes, the system will be restarted and brought back up when Fedora is up and running and all of the essential programs for the project function correctly.

Risk Analysis:

This is a medium-risk project because while it will change the system that is currently running on Caesar, all of data will be backed up before we do anything to change the setup of the drives. Fedora 18 will also be tested for compatibility on hot-swappable drives before we install it on the main drive (which will require more downtime for Caesar).

Comparison of OSs:

The table that is displayed below reiterates why we picked to update Caesar with Fedora instead of Ubuntu. It also shows why we should update from OpenSUSE 11.3 as well.

Project Coordination:

The Systems team will pick a day to test the new system and install it. We will also alert the other teams of this day in case others need to access Caesar before it goes down for testing and installation.