Chapter 1 An Overview of the N1 Service Provisioning System Software

This chapter introduces the N1^TM Service Provisioning System software solution for managing applications in data centers. It discusses the problems that the provisioning software solves. It also describes the provisioning software architecture and the object-oriented methodology that is applied to application management.

This section discusses the following topics:

• The Challenges Facing Data Centers

• The N1 Service Provisioning System Software Solution

• The N1 Service Provisioning System Software Architecture

• The N1 Service Provisioning System Software Object Model

• Approaches to Modeling

• The N1 Service Provisioning System Software Interfaces

• Using the N1 Service Provisioning System Software

The Challenges Facing Data Centers

Businesses of all kinds depend increasingly on software applications for their core operations. Managing these applications is a mission-critical task. Yet, until now, IT operators in data centers have had only rudimentary tools for deploying, configuring, and analyzing applications. Most data centers find themselves relying on custom scripts to perform essential functions. IT operators recognize the risk involved with these scripts:

• Scripts are usually hastily written and are prone to error.

• Scripts tend to operate using a long lists of files and lack the ability to manage applications as discrete units.

• Scripts are written with an imperfect knowledge of application requirements, component dependencies, host environments, and other factors that can affect the success or failure of a deployment.

• Scripts lack the benefits of a complete management platform; for example, they typically can not rollback operations systematically, dynamically adjust configuration values, and so on.

The N1 Service Provisioning System Software Solution

N1 Service Provisioning System software is an enterprise-class software platform that automates the deployment, configuration, and analysis of applications in data centers. The provisioning software applies an object-oriented approach to:

• Application components

• Tasks that IT operators perform on application components: deployment, configuration, and analysis.

This object-oriented approach ensures that all the intelligence about an application component is automatically taken into account every time that component is acted upon. This consistency makes data center operations more accurate and less prone to error. Through Application Awareness–knowledge of what an application requires as a whole–IT operators gain unprecedented control over applications and data center operations.

N1 Service Provisioning System software can:

• Automate and manage software rollouts, patches, and upgrades

• Develop models of your existing deployment processes

• Determine what software is installed on your hosts

• Compare the configurations of hosts

• Monitor and maintain documented and consistent configurations.

N1 Service Provisioning System software offers a full range of features that help make that task of managing an enterprise wide computing environment easier and faster.

The provisioning software provides:

Automated Deployment

End-to-end automation of the deployment process, including distribution, configuration, and startup of packaged and custom applications.

Differential Deployment

Enabling delta-only distribution of large content directories thereby speeding up deployments significantly and optimizing incremental directory updates.

Deployment Simulation

Complete simulation of deployments to ensure that key requirements for success are in place before deployment.

Dynamic Configuration

Real-time generation of application configuration for the target environment provides flexibility during deployment.

Dependency Management

Ability to encode application dependency information which is checked during Deployment Simulation to prevent errors that cause downtime and to leverages best practices across entire operations team.

Application Comparison

Ability to track application configuration drifts, and pinpoint unauthorized changes to servers reduces the time required for root-cause analysis of application errors.

Version Control

Central repository that tracks all deployment and configuration data for reference, reconstruction, and to automate rollback to previous states.

Logging and Reporting

Detailed logs of every action taken by the system across all applications and managed servers provides complete audit history of every change made to every server.

Native Windows Support

For COM+ components, no XML editing is required in order to install COM+ components as either InteractiveUser or a particular User and Password.

Windows System Reboot

Many applications require that a server be rebooted during or after software installation. Plans include steps that can reboot a Microsoft Windows server.

The N1 Service Provisioning System Software Architecture

The N1 Service Provisioning System software is a distributed software platform that automates the deployment and configuration tasks in an enterprise wide computing environment and provides increased visibility and control of the servers, installed applications, and file structures.

The provisioning software includes the following special-purpose applications:

• Master Server, a server that hosts the N1 Service Provisioning System software application. This server stores components and plans and provides an interface for managing application deployments. There can only be one Master Server within an enterprise.

• Remote Agent, small management applications that perform operations on the individual host on which it is installed. Every host that is under provisioning software control must have the Remote Agent installed.

• Local Distributors, optional servers that act as a proxy for the Master Server to optimize network communications across data centers, through firewalls, and to reduce the load on the Gold Server.

• Command Line Interface Client, establishes a communication path to the Master Server allowing command execution on the Master Server.

• Web Server, establishes a communication path to the Master Server allowing control of the N1 Service Provisioning System software through the use of a web browser.

The following illustration shows how an example of how applications might be installed on an enterprise network.

Figure 1–1 The N1 Service Provisioning System Software Architecture.

Master Server (MS)

The Master Server is the main processing engine of the N1 Service Provisioning System software . It is installed on a dedicated machine and provides the primary processing engine that drive the various provisioning software functions. The Master Server houses the database that defines all the objects, object attributes, and plans that define the tasks to be performed. The Master Server also runs a Command Line Interface (CLI) client to provide typed control over the N1 Service Provisioning System software and a web server that provides the HTML (graphical) interface.

The Master Server:

• A database identifying all hosts registered in the provisioning software

• A database of system objects, components, and plans

• Performs version control on the objects stored in the repository

• Authenticates IT operators and ensures that only authorized users perform specific operations

• Includes special purpose engines for performing tasks such as dependency tracking and deployments

• Provides both an HTML interface and a command-line interface for users

The N1 Service Provisioning System software repository stores components and plans in a secure, embedded SQL relational database accessible only to authorized users. The repository tracks the version of each component and each plan. For example, as part of a deployment, an IT operator can run plan version 5, which deploys version 3 of a Web server and a version 4 of a custom application.

In live data center operations, proposed changes to applications can come from many sources: from the original application development group, from the QA team, and from the IT team managing production servers. The provisioning software enables IT operators to capture configuration data from any of these sources and check these changes into the repository. IT operators can use the command line interface (CLI) to access any machine on the network and capture its configuration data. Alternatively, they can install a Remote Agent on a machine and then use the HTML interface to select resources from the machine that the provisioning software stores in the repository and combines with configuration data to create a component.

Remote Agent (RA)

A Remote Agent is a Java^TM application that runs on every system managed by the N1 Service Provisioning System software . Its job is to perform the tasks requested by the Master Server. Because Remote Agents are typically invoked only when application is being brought up or taken down, Remote Agents do not compete for resources with applications on data center servers.

Remote Agents:

• Report server hardware and software configurations to the Master Server

• Start and stop services

• Manage directory contents and properties

• Caches applications and/or directories and files before actual installation

• Install and uninstall software

• Run OS commands and native scripts specified in component models

Local Distributor (LD)

The use of Local Distributors is optional. When used they become a proxy that temporarily acts as the Master Server to optimizes the distribution and management of applications, files, and directories.

Data centers can use Local Distributors to:

• Minimize network traffic during deployments. The Master Server can send one copy of a component to a Local Distributor, which then replicates the component for installation on a collection of servers through the use of the Remote Agent.

• Minimize firewall reconfigurations. If a firewall stands between the Master Server and a collection of servers, administrators can open the firewall just for the servers running Local Distributors, rather than for every server involved in a deployment.

• Minimize the load to the Master Server during large scale deployments.

Command Line Interface Client

The Command-Line Interface Client provides a communication path to the Master Server to enable the execution of N1 Service Provisioning System software commands from a remote system. These commands are entered using the Windows command line or a UNIX® shell such as bash. The command-line interface also supports the use of shell scripts using sh or Perl.

The Command-Line Interface Client can also use the Jython programming language. Jython is a Java implementation of the high-level, dynamic, object-oriented language Python. You should install Jython on any system on which you plan to install the Command-Line Interface Client. For more information about Jython and to download Jython, visit http://www.jython.org.

Web

The Web provides a communication path to the Master Server.

Network Protocols

N1 Service Provisioning System software supports a variety of network protocols for communication among the N1 Service Provisioning System software applications. The protocols are:

• Raw TCP/IP

• Secure Shell (SSH v1 and v2)

• Secure Sockets Layer (SSL)

Raw TCP/IP

Raw TCP/IP is standard TCP/IP without additional encryption or authentication. The advantage of raw TCP/IP is that it requires no additional set-up and configuration. If your data center network is protected by a firewall and secured from intrusion, using raw TCP/IP provides a convenient method for communication among N1 Service Provisioning System software applications.

Secure Shell

ssh (Secure Shell) is a UNIX-based command suite and protocol for securely accessing a remote computer. ssh secures network client/server communications by authenticating both endpoints with a digital certificate and by encrypting passwords. ssh uses RSA public key cryptography to manage connections and authentication. Because it is more secure than telnet or other shell-based communication methods, many system administrators use ssh to manage Web servers and other remote systems.

The provisioning software can be configured so that its applications communicate using ssh. N1 Service Provisioning System software supports OpenSSH explicitly. OpenSSH is a free version of ssh that has been primarily developed by the OpenBSD Project. (For more details, see http://www.openssh.com.) The provisioning software can be configured to support other versions of ssh, as well.

Secure Sockets Layer

Secure Sockets Layer (SSL) is a protocol for securing communication over IP networks. SSL uses TCP/IP sockets technology to exchange messages between a client and a server, while protecting the message with a public-and-private key encryption system developed by RSA. Support for SSL is included in most Web server products, as well as in the Netscape and Microsoft Web browsers.

N1 Service Provisioning System software applications can be configured to use SSL for their network communications, preventing the provisioning software's messages from being read or tampered with. Optionally, N1 Service Provisioning System software applications can be configured to use SSL to authenticate each other before communicating, further increasing network security.

Selecting Protocols to Meet Specific Needs

N1 Service Provisioning System software enables you to select the protocol you will apply to each of the following types of network communication:

• Communication between the Master Server and its children (Local Distributors and Remote Agents)

• Communication between a particular Local Distributor and its children (Remote Agents)

• Communication between the Master Server and a Command Line Interface Client

You can tailor your network security to meet the needs of your particular network topology. For example, if communication within each of your data centers is secure, but your network connection to a remote data center passes through the public Internet, you could configure the Master Server to use SSL when communicating a Local Distributor installed inside the firewall for the remote data center, so that all communication over the Internet is secured. The Local Distributor could use raw TCP/IP to communicate with its children, since all the communication over the local network is secure, and SSL is not required.

For information on configuring SSL and SSH, please see N1 Service Provisioning System 4.1 Installation Guide.

Complex Heterogeneous Data Center Environments

The N1 Service Provisioning System software is designed to fit into data center environments and complement the management, monitoring, and control systems already in place.

Recognizing the diversity of hardware and software found in most Internet data centers, the provisioning software has been designed with cross-platform support in mind. It uses standard communication protocols (HTTP, HTTPS, SSH, and TCP/IP) and standard file and presentation formats (HTML and XML), and it works with standard application architectures (J2EE^TM and .Net). It provides data centers with a standards-based system for managing all their applications, whether those applications are UNIX-based or Windows-based.

Supported Operating Systems

You can install the N1 Service Provisioning System software Master Server on systems that are running the following operating systems:

• Solaris 8, Solaris 9

• Red Hat Linux 7.2, 7.3, 8.0 and Red Hat Advanced Server 2.1

• Microsoft Windows 2000 Server and Microsoft Windows 2000 Advanced Server

You can install the N1 Service Provisioning System software Remote Agent, Local Distributor, and CLI Client on systems that are running the following operating systems:

• Solaris 2.6, Solaris 7, Solaris 8, Solaris 9

• Red Hat Linux 7.2, 7.3, 8.0 and Red Hat Advanced Server 2.1

• IBM AIX 4.3.3, 5.1, 5.2

• Microsoft Windows 2000 Server and Microsoft Windows 2000 Advanced Server

For more information about system requirements, see the N1 Service Provisioning System 4.1 Installation Guide.

Supported Web Browsers

The following table summarizes the Web browser requirements for the HTML user interface.

Supported Locales

The N1 Service Provisioning System software has been internationalized to install and run in localized environments. You will need to adhere to the following requirements if you want to run the software in a localized environment.

• All applications must be run in the same locale or in locales that are equivalent. The Remote Agent, Local Distributors, and CLI Client must run in the same locale as the Master Server.

• The software accepts only ASCII characters for file names, directory names, and other input.

The N1 Service Provisioning System Software Object Model

N1 Service Provisioning System software provides an object-oriented methodology for managing application deployment and configuration. It provides increased visibility and control of the servers, installed applications, and file structures.

The objects are loosely grouped as infrastructure, main, and supporting. Infrastructure objects are things like Users, User Groups, Hosts and Host Sets. Main objects are things like Resources, Components, and plans. Supporting objects are things like Comparisons and Notifications.

Components

A component is a logical grouping of source information (software and/or file structures or other components) that define an application.

The N1 Service Provisioning System software supports two types of components, simple and composite. A simple component is a component that references a single source item. The type of source items that simple component references corresponds to the component's Component Type. For example, a file, a directory of files, a registry key, a COM object, a Java^TM Archive (JAR), an EAR, an IIS website, etc. A composite component is a component that references other components. Composite components can contain any number of simple and/or composite components.

All components, regardless of whether they are simple or composite have the following characteristics in common:

Name

A text field that identifies the component. This includes the path where the component is stored.

Type

A user definable object (Component Type) that is used to control how to handle source information. The component type object is actually another component that manages the acquisition and deployment of source objects such as files, directories, and configurations. The provisioning software comes populated with a large number of component types that support WebLogic and Windows, UNIX® , and some generic models.

Version

The revision number of the component. Each time a component is modified, the repository increments its version number.

Platform

Identifies the platform(s) or operating system(s) that are valid targets for the component's deployment.

Source

Identifies from where the component source information came. This include the path.

Checked in

The date and time when the component was checked in. That is, created or modified.

Checked in by

The user ID of the person who checked in the component. This provides an audit trail when trying to troubleshoot problems or inconsistencies.

Label

A user definable text string that can be used to control the sorting on the components page.

Description

A text string that describes the component object. This attribute is not used by the provisioning software but can provide meaningful information to the user.

For a more complete description of component attributes see Building a Component.

The N1 Service Provisioning System software stores each component along with metadata that contains important information about the component, including how to:

• Install and uninstall the component

• Configure the component

• Control the component (e.g., through administration consoles or other interfaces)

• Analyze the component in comparison to other application components (for example, specifying whether log files and /tmp directories should be considered in comparisons)

• Start up and shut down the component

By reading this metadata and comparing components, the provisioning software can identify and track dependencies among components.

Figure 1–2 shows the contents of a component.

Figure 1–2 N1 Service Provisioning System software components include software, templates, and metadata.

In addition to this metadata, components include configuration templates that enable IT operators to adjust specific configuration parameters—for example, port numbers—on a server-by-server basis or according to the rules defined in an execution plan. These variables can be set when an operation is performed, rather than being hard-coded in traditional data center scripts.

Component models are written in XML. The object model incorporates features from the Common Information Model (CIM) and from JSR-77, a Java Specification Request proposing a standard management model for J2EE components. Through the N1 Service Provisioning System software console, you can use component templates to quickly customize existing components. You can also author new templates for applications developed in-house. To perform advanced customizations on complex J2EE components, you can edit components through the HTML interface on the console or with an XML editing tool such as XML Spy.

The provisioning software stores components and plans in a secure repository. Using the console, you check components and plans in and out of the repository, run comparisons, and make changes.

To perform a data center operation such as a deployment, you apply plans to components. Through the N1 Service Provisioning System software , every data center operation incorporates all the knowledge available about each component. Errors are automatically detected. Missing information is flagged. Through automation, deployments and configuration changes become faster and more accurate.

The Component Library

N1 Service Provisioning System software makes it easy for IT operators to begin using component models right away. The Master Server includes a component library with templates for the most common components used in Internet data centers. Table 1–2 lists the templates included in the library.

In addition to working with these components, the provisioning software can coordinate activities with standard databases, load balancers, and operating systems as part of deploying, configuring, and analyzing applications. Table 1–3 lists the databases, load balancers, and operating systems that can be acted upon.

Plans

Just as it captures information about applications in component models, the N1 Service Provisioning System software stores information about data center procedures in plans. A plan is an XML document containing a sequence of instructions used to manipulate one or more components or calls to other plans. Plans can encode this information explicitly, or they can leave some details, such as specific server names and port numbers, for the IT operator to specify at run time. When the provisioning software runs a plan, it reads component models for details about configuration requirements, dependencies, and instructions for performing specific operations, such as installing a particular set of files and setting permissions on a directory.

N1 Service Provisioning System software uses plans to:

• Perform operations such as deployments

• Coordinate activities among components during these operations

• Coordinate activities among servers during these operations

There are two types of Plans, simple and composite. Simple plans contain a sequence of instruction that is performed on the target host or hosts unilaterally and cannot call other plans. Composite Plans can only call other Plans so that each step in a multi-step deployment—shutting down an application, removing servers from a load balancer, etc.—can be managed by its own carefully written plan.

For example, a plan to roll out a multi-tiered application might consist of four sub-plans:

• a subplan for removing servers from the load balancer

• a subplan for updating web servers

• a subplan for updating application servers

• a subplan for re-inserting the servers into the load balancer

The rollout plan itself would coordinate activities among the sub-plans and servers. For example, running this plan on a cluster of 10 servers, the N1 Service Provisioning System software would ensure that each subplan had completed successfully and all ten servers were synchronized before proceeding with the next subplan.

Inserting variables in components, plans, and sub-plans gives operators fine-grained control over data center operations. For example, a component can be configured to include a variable for a port number. A plan can assign a value for this variable. Alternatively, the IT operator can assign a value for variable (overriding the value specified in the plan) through the CLI or the HTML interface. Variable settings can be applied to sets of hosts or individual hosts.

By providing a common format for execution plans, the provisioning software replaces the chaotic variety of script formats and languages found in most data centers. Rather than trying to understand the contents of a hastily written script, operators can select the plans they need from a central, version-controlled repository.

Built-In Procedures vs. Plans

The N1 Service Provisioning System software automatically generates procedures for many operations, such as installation and un-installations, for the most common types of components. If your deployments involve installing one component at a time on a single set of hosts, you can use these built-in procedures and never have to author a plan.

Use plans, rather than built-in procedures, if you want to:

• automate the installation of multiple components through a single procedure

• automate the installation of components onto different sets of target hosts

• add dependency checking to installation procedures (e.g., have the installation confirm that a particular component is installed and running before installing the next component)

• synchronize the steps in an installation, so that a particular step does not begin until a previous step has completed successfully

Hosts

The N1 Service Provisioning System software makes it easier to manage servers or hosts by modeling them as objects and storing the model in the host database. The provisioning software enables you to define host types, so you can classify hosts by their configuration or function. The software also enables you to create host sets–groups of hosts that you can manage as a single unit. Host searches enable you to dynamically group hosts based on current attributes. These host management functions, combined with the component and plan objects described above, significantly reduce the complexity of deploying, configuring, and analyzing applications in data centers. To enable the provisioning software to work with a host it must have a Remote Agent installed, registered in the database, and prepared by the provisioning software for use. Hosts that have gone through all of these processes are also called Nodes. For more information on Hosts see Chapter 4, Hosts.

Object Attributes

All of the N1 Service Provisioning System software objects have many attributes that either serve to identify the object such as its name, to classify it in some way, provide revision tracking, define grouping, hiding, and so on. Some attributes are unique to a specific object while others are available for some or all of the objects.

Categories

The N1 Service Provisioning System software includes a built-in category called system, which is automatically applied to internal resources. All other categories are user definable. As with naming conventions, careful planning should go into defining categories. When category naming conventions are well thought through they become powerful tools when used with searches and views to quickly identify or select groups of objects. Categories for each object are discussed in more detail in the sections relating to each particular object.

You can use categories to classify:

• plans

• components

• resources

• comparisons

Show/Hide

Over time these objects may become obsolete. To reduce the visual clutter you can hide unwanted objects so that they are not shown by default on web pages or listed by CLI commands. It is also possible to delete most of the objects.

Approaches to Modeling

Modeling creates a representation of an application, so that the application can be installed, configured, and managed on targeted host computers. The model for the application can be based on the configuration of a specific host computer running an application, or it can be based on components stored in a repository such as a source code control system.

A host computer that is designated to serve as a reference system for a particular application is called a gold server. [For an overview of the design philosophy behind gold servers, see Traugott and Huddleson, “Bootstrapping an Infrastructure,” Twelfth USENIX Systems Administration Conference (LISA "98), Boston, Massachusetts. This paper, along with others devoted to the issues of IT infrastructure, is available at http://www.infrastructures.org. ] In many organizations, a development team, a QA team, or a data center team creates a gold server, so that IT operators have a tested and approved example of an application that needs to be deployed in a production environment.

Using the N1 Service Provisioning System software , you can model an application from a gold server or some other repository. The component model that you create can:

• preserve the unalterable aspects of the configuration–the contents and configuration settings that should be used wherever the application is installed

• establish variables for dynamically adjusting the host- or installation-specific aspects of the configuration (e.g., port numbers or IP addresses that vary from host to host)

• omit the incidental aspects of the configuration (e.g., the contents of log files on a gold server)

Creating models makes applications more manageable. An application model can includes vast amounts of information (files, directories, and so on) that it would be difficult or impossible to manage manually.

A Typical J2EE Modeling Process

In J2EE applications, components typically comprises several resources, such as directories, archives, and so on. In modeling a J2EE application, then, you check in the resources that make up a component and then build the component model based on the resources.

These are the steps typically involved in modeling J2EE applications.

1. Define and configure hosts.

2. Check in resources that make up each component.

   • Install a Remote Agent on the gold server or development system with the components you want to model.

   • Select the resources you want to include in components.

3. Define components.

   • In addition to defining the resources that make up a component, you can create variables for configuration parameters, add information about component dependencies, etc.

4. Write plans for deploying and configuring components.

5. Run plans.

6. Run comparisons as necessary to analyze your application environment.

A Typical Windows Modeling Process

Windows application components are usually managed as a whole units, rather than as a collections of distinct resources.

These are the steps typically involved in modeling Windows applications.

1. Define and configure hosts.

2. Check in components.

   • Install a Remote Agent on the gold server or development system with the components you want to model.

   • Select the components you want to model. The N1 Service Provisioning System software includes model templates for the most common Windows application components (see Table 1–2 for a list). In many cases, once you have selected the resource template for the Windows component, no further modeling will be necessary.

3. If appropriate, add additional resources to components.

   • In addition to defining the resources that make up a component, you can create variables for configuration parameters, add information about component dependencies, etc.

4. Write plans for deploying and configuring components.

5. Run plans.

6. Run comparisons as necessary to analyze your application environment.

The N1 Service Provisioning System Software Interfaces

There are two interfaces to the N1 Service Provisioning System software :

• an HTML interface accessed through a Netscape^TM or Internet Explorer Web browser

• a Command-Line Interface (CLI) accessed through a shell, a Windows prompt, or a script

The HTML Interface

The HTML interface consists of a series of web pages that enable authenticated users to model components, develop and run plans, and perform other operations with the . The HTML interface is designed to be easy to use. It works with both Netscape and Microsoft Web browsers and uses a few basic navigation tools on every page.

All web pages in the HTML interface use the following conventions:

• The left-hand navigation menu appears on all pages (except pop-up windows). The left-hand navigation menu can be collapsed or expanded by clicking on the plus (+) or minus (-) signs.

• All major headings, when clicked, displays a collection of useful links associated with the major heading.

• Information is presented in tables.

• New objects, such as a plans or components, are created by entering information in the top row of a table.

• Clicking Edit takes you to a Web page with graphical controls for editing the content of an object, such as a component.

• Clicking Advanced Edit takes you to a Web page that enables you to edit the XML of a component or plan.

• Information about problems is presented in red.

• The location of the current page is always listed at the top of the page, and the symbol > is used to indicate one page being linked from another (for example, the location Components > Details > Variables Settings tells you that you are viewing the Variable Settings page, which is accessible from the Component > Details page, which in turn is accessible from the main Components page).

The HTML Interface Navigation

Between the many built-in components and the ones you create, the number of components, component types, and plans can become extremely large making it difficult to locate the one you want. To help in locating and using a specific object, easier, the N1 Service Provisioning System software allows you to organize components, component types, and plans in a hierarchical filing system.

The following text describes the Path area of the HTML user interface.

Path

Displays the name of the current working directory.

Show

Allows you to list either components or plans. If you select plans The HTML user interface displays the plans page as though you had click on the plans option in the left-hand navigation menu.

Category

Filters the lists objects by category.

To access objects (either components, component types, or plans) in a specific directory click on the “change path...” text. The provisioning software brings up the Change Path page.

Simply enter the desired path into the “selected path” text field or click on the desired icon to select a path.

The Command Line Interface (CLI)

The command-line interface (CLI) is a suite of tools for accessing the provisioning software through non-HTML interfaces, such as a Windows prompt, a shell, or a script. CLI commands can be used in scripts to automate operations, such as checking in files. They can also be used to access the Master Server from systems that lack a Web browser or an HTTP connection.

The CLI is a Command-Line Interface Client which can be installed on any computer that can make a network connection to the Master Server. The client parses the commands into native objects and sends them to the Master Server. Results of the commands are then translated by the client to a textual format and presented to users.

Most CLI commands require authentication. Users authenticate themselves by specifying a user name and a password or a session ID with each command. See Authentication by Username and Password or Session ID in N1 Service Provisioning System 4.1 Reference Guide for more information.

There are two tools for invoking the CLI:

• cr_cli, which operates in single-line command mode, executing one command at a time

• cr_clij, which operates in interactive command mode using a Jython interpreter

cr_cli: Single-Line Command Mode

The single-line command mode accepts one command at a time as input. Each command submitted must be complete; the user is not interactively prompted for the next input parameter. Operating in this mode, the Command-Line Interface Client does not maintain a command history.

Here is an example of a CLI command executed with the cr_cli tool. This command adds a host of type prodserver to the host database. The user running this command, rbarnes, supplies his password to authenticate himself to the Master Server.

cr_cli –cmd hdb.h.add -u barnes -p bar123 -name webb1  -desc `web server 1' –tID prodserver  

cr_cli commands can be stored in a file and be called from a shell script. This is useful for repetitive tasks such as running execution plans, comparisons or populating hosts.

cr_clij: Interactive Command Mode

The interactive command line mode uses the Jython interpreter as its shell. Operating in this mode, the CLI offers you these advantages:

• You do not have to type an entire command on a single line. You can simply enter a command name and then enter the command arguments that cr_clij prompts you for.

• You can take advantage of the command history stored by the shell.

• You can call a N1 Service Provisioning System software command from within a Jython script.

• You can create more powerful scripts for more complex, repetitive operations.

• For the purposes of automation, the interactive mode results are more detailed.

  ---

  Note –

  To call commands from within a Jython script, include the following at the beginning of the script:

  from clui import * app=PyCLUI() make Jython calls to the N1 Service Provisioning System app.execStr(CLI command) invoke Jython methods from the new Jython object App.close() delete the instance of this Jython class

  ---

The Structure of CLI Commands

Whether invoked through cr_cli or cr_clij, all CLI commands use the following format:

subsystem.object.command arguments  

For example, the command for adding a host to the N1 Service Provisioning System software database is hdb.h.add. This command consists three elements that identify:

• a N1 Service Provisioning System software subsystem, in this case the host database (hdb)

• an object to operate on, in this case a host (h)

• a command or operation, in this case adding (add)

Table 1–4 lists the CLI prefix for each N1 Service Provisioning System software subsystem, along with the chapters in this guide that discuss the subsystem.

This user manual does not contain a complete list of CLI commands. Each section does list the more frequently used CLI commands that relate to the specific topic. For a complete list of CLI commands, please see N1 Service Provisioning System 4.1 Reference Guide.

Using the N1 Service Provisioning System Software

This section provides an overview of how you use the N1 Service Provisioning System software to deploy and configure applications. The steps you will follow vary depending on whether you are using the HTML user interface or the command-line interface. Other chapters in this guide provide detailed instructions for performing each of these steps.

How to use the HTML User Interface

You can use the HTML user interface to model components and to install components on target hosts.

Steps

1. Install a Remote Agent on each server that you want to model, whether it be a gold server, source code control system, or some other type of server.

   ---

   Note –

   See the N1 Service Provisioning System 4.1 Installation Guide for information on installing Remote Agents.

   ---

2. Define a host type for the host you will be modeling and for the hosts you will be deploying the application to. Include host type attributes (name-value pairs) for any configuration variables you want to set dynamically.

   ---

   Note –

   For a description of host types, see Working With Host Types.

   ---

3. Using the Hosts page, add each host to the host repository. The final step in adding a host is “preparing a host,” which enables the provisioning software to fine tune the configuration of the host's Remote Agent in preparation for operating upon the host.

   ---

   Note –

   For more information about adding and preparing hosts, see Working with Hosts.

   ---

4. If you are going to define multiple components from a collection of resources, you can check in resources next. Most likely, though, you're working with components that have their own set of resources, so you should begin by creating components directly.

   • Use the Components page to create a new component.

   • On the Component > Details page, add the resources that make up the component. If a resource has already been checked in, you add it as an existing resource. Otherwise, check in the resource as a new resource.

   • Save the component. Saving the component builds the component–that is, the N1 Service Provisioning System software saves the component with a specific name and version number and associates this specific version of the component with the specific versions of the resources that make it up.

5. You can now either install the component or to extend the component by editing XML.

   • With most components, you're now ready to run installation procedures using the install procedure that the provisioning software has automatically generated. To run an installation procedure–or some other extended control service associated with this component–display the Component > Details page for the component, select the check box for the procedure you want to run, and click run. This method of running procedures is called direct run.

   • If you want to add more information to the component, such as additional configuration variables, additional steps to perform during specific procedures, or more details about what to include and what to exclude during comparisons, check out the component, edit its XML, and then check it back in.

6. Once you've edited the XML, you're ready to continue with operations.

   If you want to install one component at a time on a single set of hosts, you can run the install procedure listed on the component details page of the component. If you want to automate the installation of the component on different sets of hosts, add dependency checking to the installation, synchronize steps in the installation, write a plan for the component, and then run the plan to install the component.

How To Use the Command Line Interface

You can also use the command-line interface to model components and install them on target hosts

Steps

1. Install the Command Line Interface Client on the server where you will be executing CLI commands. The server must be able to establish a network connection to the Master Server.

2. Using an XML editor such as TurboXML, write the XML definition of the component.

3. Run the cdb.cd.ci command to check in the component.

   ---

   Note –

   Once you have checked in the component, you have the option of installing it on a single set of target hosts by using the HTML user interface to directly run the component's install procedure. Direct run procedures can be called through the HTML user interface, but not through the command line interface.

   ---

4. Use an XML editor such as TurboXML to write a plan for the component.

5. Run the pdb.ci command to check in the plan.

6. Run the pe.p.run command to run the plan.

   ---

   Note –

   The CLI commands that run plans do not report on the progress of the plan's execution. To monitor the progress of a plan while it is running, run the plan from the HTML user interface.

   ---