PROJECT ON

Configuration & Deploying of system images

SHASTRI INDRAVADAN
Roll No.Al020510 UNDER GUIDED BY MANOJ PARMAR

CERTIFICATE
This is to certify that SHASTRI INDRAVADAN roll no. is AL020510 and batch no C-VL-03-12-10, the student of jetking institute has successfully completed his term work in module-2

Signature Of Faculty

Signature Of Examiner

ACKNOWLEDGEMENT
THE DISSERATION WAS UNDERTAKEN IN PART OF FULFILLMENT OF THE REQUIREMENT FOR THE JCHNP OF JETKING HARDWARE AND NETWORKING INSTITUTE.

I UNDERTAKE THIS OPPORTUNITY TO EXPRESS MY VIEWS AND INCREASE GRATITUDS OF MINE BY HELP OF MANOJ SIR TO GUIDE ME AND GIVE THE ADVICE BY TIME TO TIME.

INDEX
INTRODUCTION STRUCTURE TYPES OF

Configuration

& Deploying of system images

Introduction
System deployment refers to a very common task for IT departments: setting up a computer system with all the software it needs the operating system and base set of applications. Because this is a very routine task, the goal is to fully automate it in a reliable, consistent way. This document discusses how to do this for server hardware; another strategy document, System Imaging, discusses how to accomplish this for desktop and laptop systems. It encompasses the initial installation of an operating system and base applications on new or repurposed hardware or in a newly created virtual machine, rebuild of a system for major operating system upgrades, and support for tasks such as hardware diagnosis, wiping disks before decommissioning, and a "rescue" boot when the operating system is corrupted or nonfunctional. The goal for system deployment is a fully automated deployment of a supported operating system on either physical or virtual systems. Physical access to the system must not be required so that staff can support remote lights-out data centers or remote client locations. Build services are a critical component in fast provisioning of new systems and provide a consistent

foundation for deployment of applications and configuration. Automated OS (operating system) installations over freshly formatted disks are preferred above OS upgrades or cloned copies from templates or captured images, even in a virtualized world with better support for system cloning. Installing operating systems this way ensures that a newly deployed system starts fully patched, without any unnecessary confusing configurations from previous patches and upgrades. Doing fresh builds rather than upgrades or cloning of existing systems also tests, on a day-to-day basis, the ability to automatically regenerate the base OS install from first principles, ensuring that the automation stays up-to-date. Separating the modifications from the base OS image, using a script or set of scripts to perform all the actions necessary to take the computer to final build, also allows an easier upgrade to new releases of an OS since the underlying OS image is interchangeable (within bounds). The long-term goal is to provide OS builds with necessary customizations (such as a preferred authentication service) as an automated service, along with supporting documentation for how to customize supported operating

systems for the Stanford environment. IT Services will use, and improve where necessary; the standard automated build facilities provided by supported operating systems, contributing improvements back to the OS provider or broader community when possible. Current state The standard industry way to automate system builds is to use a PXE (Preboot Execution Environment)-based network boot (configured via DHCP, or Dynamic Host Configuration Protocol) alongside the automated deployment system for the operating system being built: WDS (Windows Deployment Service) for Windows, FAI (Fully Automated Installation) for Debian and Ubuntu, and Kickstart for Red Hat. IT Services has been doing this for some time, as have Stanford's peer institutions and most large organizations. On UNIX, IT Services supplements the standard operating system package repositories with local repositories for Stanford-specific packages, which is also common among peer institutions and large organizations. IT Services is somewhat behind the trend towards digital signatures of all package repositories on Debian and Ubuntu; that is already being done for Red Hat. Servers are provisioned using an automated server deployment. Server builds require a small amount of input to

initiate and then complete without human interaction using the following technologies:

PXE to start system builds, both physical and virtual; UNIX and Windows.PXE relies on DHCP for configuration. The use of PXE on virtual environments is problematic, especially for Windows deployment, since the more efficient Hypervisor-integrated virtual network interfaces (NICs) do not support PXE. Kickstart for building Red Hat systems Yum for Red Hat package repositories. Red Hat deployment is available to campus. FAI for building Debian and Ubuntu systems in Computing Services. WDS (Windows Deployment Service) and Microsoft Deployment Toolkit (Lite Touch) for building Windows Server systems in Computing Services. Yum server to provide Red Hat build services to campus and ESX3 package updates for legacy BCDR ESX servers at Duke University.

For virtual servers, managed virtual server host environments are available on both VMWareESXi, offered as a service by IT Services, and Microsoft Hyper-V, which is used for internal Windows infrastructure. These environments are managed by the following:

 VMware ESXi and Virtual Center for management of VMWare virtual machines System Center Virtual Machine Manager for management of Hyper-V virtual machines Client Support has a service called RaDIS (Rapid Deployment and Imaging Service) for deployment of operating systems on new or repurposed hardware at client sites. System deployments can be done from anywhere on campus with a sufficient network connection. A single, hardware-independent universal image for each OS is developed that can be deployed to all business-level desktops and laptops. Macintosh OS images are applied manually to client computers through a custom NetBoot installer and NetRestore. NetRestore is no longer in development. For Windows systems, the question of licensing comes up often. Stanford acquires licenses for Microsoft from a large number of avenues, including retail purchase, bundled with new machines, Select, MSDNAA, and Campus Agreement. Vision The current build infrastructure is stable and sufficient for most needs within IT Services. No major investment

is required for IT Services' internal needs. However, IT Services has received multiple requests for better support for other campus system administrators, and better documentation and dissemination of expertise around system build and configuration for Stanford's environment. Therefore, the primary effort is to turn build services into a more general service and significantly improve build and configuration documentation. Some ongoing operational effort is required to adopt build services for new releases of supported operating systems and, for the Linux systems, some work remains to bring the level of support for Ubuntu up to that provided for Debian and Red Hat. Since system builds are a common system administration task, IT Services should also make ongoing efforts to improve the automation of the build and bootstrap process. Time saved per build has a significant impact on reducing operational overhead for systems administration. Organizations that deploy large server farms have been investing in automation of initial system keying and bootstrapping into a configuration management system, a step that is still currently manual for IT Services' systems. The current rate of system builds probably doesn't warrant a lot of investment here, but it is expected that the rate of system builds will increase with research computing and

with the growth of virtualization and desire for automated deployment of new virtual machines. Virtual desktops and application virtualization are becoming more and more prevalent. With the growth of virtualization, there is a growing trend towards deployment of systems from virtual machine templates or by cloning existing