Friday Jul 27, 2007

Handy N1 SPS Import-Export Feature

The N1 Service Provisioning System just got a lot easier to use,
thanks in part to a great new import-export feature. Now, you can very
simply copy a whole raft of artifacts at once between your SPS master
servers. You can roll a bunch of SPS artifacts up into what's called a "bundle
" on, say, master servers your test environment. What SPS artifacts might these be? They might be things like host types,
components, component types, folders, and any plans you want. 
And you can then get access to these SPS artifacts from another master server. How is this done? Well, you declare a list of  "search criteria" that
represent these SPS artifacts. This list of search criteria forms the bundle template. For example, a bundle template might contain criteria for searching for component types and plans. Then, with a few simple clicks, you can save this bundle template, and export it into a bundle jar. On another master server, import that bundle jar. Once you've imported the bundle jar to a master server, the SPS artifacts are now held on that master server. This means of course that you can easily copy several SPS artifacts from one master server to another, which is great for testing things out before putting them in live environments. This new feature will make things easier for those customers who want to really be able to test complex things out on in one or several SPS environments before going live. Learn how to do this using the command line. This feature is already available through the command line in the recent N1 Service Provisioning System 5.2 Update 2 release. In the upcoming N1 Service Provisioning System 6.0 release, you can also use this feature through the new, improved browser user interface.

Tuesday Jun 12, 2007

Sun Connection Inventory Channel Goes Live

The new Sun Connection Inventory Channel is up and running, enabling you to easily discover, register, and manage your Sun products. This is a pretty valuable service, whether you're trying to register a single installation of the Solaris OS, or trying to keep track of all the Sun products in a large network environment.

The whole process for working with the Inventory Channel looks something like this:

1. Set up your products to work with Service Tags.

Service Tags are a set of XML tags that store basic information about your Sun product and the environment in which they're installed. Some Sun products are currently enabled to work with Service Tags out of the box; other products require a patch or additional packages.

For more information about Service Tags, see the FAQ.

2.  Discover the Sun products in your environment.

Go to the Sun Connection Inventory Channel, and click the Discover Now button. The Inventory Channel registration client discovers the Sun products in your environment that are Service Tag enabled.

3. Register your Sun Products.

Once you discover the Sun products in your environment, upload your product information to Sun Connection to register your products.

4. Manage your Sun Products in Sun Connection.

After you register your products, you can perform a variety of management tasks through the Sun Connection web interface:

  • Organize your products in logical groups
  • Create product filters to zero in on particular products
  • Create PDF, XML, or comma-separated reports on your products
  • Track information updates on your products through RSS feeds
For a detailed review of this process, take a look at this animated tutorial


Sunday May 27, 2007

SPS - More Best Practises and hints

Have you always wondered how things are coded and why, or why someone uses more execNative than others. Some people like to distribute a whole bunch of scripts that they run after deploying them. Why should I create a component type and when you I just create XML templates and use a lot of copy paste.

We have tried to answer some of these questions in documents that we would refer to as best practises document but also guidelines based on years of experience.

Here is one example (taken from the document):

5.6. Plan Parameters

 Pros Flexible to use since you set them when installing the components.
Static components due to "interactive" installs... Passwords since they
may not always be allowed storing somewhere.
 Cons The variables are not stored after install of component. Hard to re-use
variables. This will however change a little bit when we release SPS
6.0 later this year, where we are introduciong Variable Sets for Plans.
 Example of usage
 Using this kind of variables is perfect for non static data that is
only needed when doing the installation and when you need an
interaction from the operator running the plan. This should be used
when doing ad-hoc plans where one just need a quick response back
without the complexity of updating the component or container and also
avoid the version number increase. A typical example when this is used
is when you have a plan that simply reports a specific logfile or
textfile back to the Web UI, i.e. /usr/bin/cat <filename> where
filename would be the parameters inputted by the user at run-time.

The following example is a complete XML of a working plan. This is because all sections are needed to exemplify the use of plan parameters, e.g. paramList is needed to be able to use the parameter in combination with the execNative procedure.

<executionPlan xmlns:xsi='' name='StartServer-plan' version='5.0' path=/ >
        <param name='ServerName' prompt='Enter server to start:'>
        <var name='RunUser' default=':[session:UserName]'>
        <execNative userToRunAs=':[RunUser]'>
            <exec value=''></exec>
            <arg value=':[ServerName]'></arg>

For more information, please read at the following links:



Stay tuned for information about the SPS 6.0 release coming up...




« August 2016