Sun Connection Sun Connection

What is Patch Management? Why are people so afraid of talking about this and there are so many opinions regarding this topic. They vary from patch the latest all the time when it is available, never patch because it is dangerous, patch when vendor tells you or when something breaks.

So what is the reality? Is it dangerous? Will it create more downtime?

I cannot say that we have all the immediate answers, but I will explain some details and these are taken from the new version of the Patch Management Whitepaper that is being reworked and updated.

Patching first of all is not dangerous. It all comes down to the Process on how to handle it. Patching should be planned, qualified, tested, etc, etc.... It should follow very much like Release Management when developing Software. It is not that much different. So this means that any downtime should be planned, then it is ok of course. The test cycle should be complete also before going to the next level.

So an example of the process could be something like:
Analyze->Assess->Download->Schedule->Deploy (if approved)
Where  (if approved) is very important.

So in the paper we will talk about the link to ITIL and how that can help understanding the process and cycle. So stay tuned for the updated paper and more info will follow here :) Then to facilitate the whole Patch Management Process we have tools such as Sun Connection.

For those of you who are experienced with Sun Connection, you know that first time you run a job to deploy a baseline - downloading can take a very long time, especially when you have 100-200 patches or RPMs.

This article will explain how to speed up those downloads!

Let's take a look at normal agent<->management server<->internet communication:
Step 1: Agent finds out it needs 200 patches, it then requests those one by one from the management server:
[Agent] --(Please give me patch A)--> [Management Server]            [Internet]

Step 2: If management server has this patch in cache - it provides it right away to the agent:
[Agent] <--(Here you go, patch A)-- [Management Server]            [Internet]

However, if the cache doesn't have those patches, either because it's the first time or because the cache was cleaned - that's when the slowness begins. The management server will tell the agent "Please wait!" and will go to the internet (either to Sun, RedHat or Suse) to download the requested patch:
[Agent] <--(Please wait! Error code 302)-- [Management Server] --(I need patch A)--> [Internet]

The agent, sadly but patiently says "ok, I'll just sleep for 30 seconds and try again..." while the Managment server is working to download the patch from the internet:
[Agent](sleeping 30 seconds)     [Management Server] <--(Downloading patch A)-- [Internet]

The problem is that many times it takes only a few seconds to download the patch, and then you waste the rest of the time waiting. So if you have 200 patches - waiting for nothing for about 25 seconds each time adds up quickly: 200*25 = 5000 seconds, or about 1 hour and 30 minutes of wasting time!

The solution is quite simple: instead of waiting for 30 seconds, you can reduce the time the agent waits for the management server to about 5 seconds. Here's how:

The agent has a "uce.rc" file with default values, and a ".uce.rc" file with values that were customized by the user. The location of the relevant configuration file is:
$UCEDIR/agent/bin/uce.rc
$UCEDIR/agent/bin/.uce.rc

By default - Linux $UCEDIR is /opt/local/uce and Solaris $UCEDIR is /opt/SUNWuce/.
Never change the file "uce.rc". You would want to copy the relevant line from "uce.rc" and add it to ".uce.rc" and modify it there.
The relevant line is:
( all ) ( invisible.server.__general.knowledgebase_conflict_reconnect_interval, 30 );

You can easily copy this line with the following command:
# cd /opt/local/uce/agent/bin/
# grep knowledgebase_conflict_reconnect_interval uce.rc >> .uce.rc
Before performing this, make sure you don’t have this line already in .uce.rc.

Then, change the value in .uce.rc to:
( all ) ( invisible.server.__general.knowledgebase_conflict_reconnect_interval, 5 );

Then restart the agent - and you're done!

If you have any questions or suggestions for future best practices, please feel free to contact me at Eran.Steiner-AT-Sun-DOT-com.

Happy patching!

Eran Steiner
Field Enablement Team

 

I just returned from a long road trip where I had the
opportunity to visit with several key customers using our systems management
products. For the most part the product that we were discussing was N1SPS
(Service Provisioning System). During this trip I met with three customers as
well as one of our partners. The format was basically the same for each
customer visit. We reviewed the Connected Systems Network roadmap which
included all of our products and then spent some time learning about how the
customer used N1SPS and our other products in their environment. We then took
them into a demo of our latest release, N1SPS 6.0 which is scheduled to release
in the near future. The feedback was overwhelmingly positive. The customers
especially appreciated the much improved user interface as well as the SPS
modeler.

 
In learning about how these key customers implemented N1SPS
in their environment the following was just some of the feedback

 
Extremely reduced time for environment deployment (example given
of 4 hours as compared to multiple days)

 Consistent and reproduceable deployments – reduced errors

 Improved process and better user acceptance

 Increased “process stability” and proper traceability of
current states

 One customer was able to provision applications to 27 hosts
with125 zones in 5 days. This had taken weeks using the customers previous
application provisioning process

 We also took the time to listen to the customers ideas on
their most important requirements for future product enhancements. I see these meetings
as being very beneficial for the customer and for Sun. If you are a Sun
customer or a Sun employee who has customers that we can engage with for this
type of activity regarding any of our systems management products send a note
to robert.lusk@sun.com

 

Thanks,

 

Bob Lusk -Connected Systems Network

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. 

 

The latest sets of release notes for N1 System Manager and N1 SPS include a workaround for installing the N1 SM managed server and N1 SPS master server on the same physical host. Essentially, you install the N1 SPS master server in an alternate root directory by prepending the following to your N1 SPS installation script.

#!/bin/ksh
alias -x pkgadd='pkgadd -R $NEW_PKG_ROOT'
alias -x pkginfo='pkginfo -R $NEW_PKG_ROOT'
alias -x pkgparam='pkgparam -R $NEW_PKG_ROOT'

One limitation: You can't install the OS provisioning plug-in for N1 SPS on the master server.

This is a really brief description of what's involved. Take a look at the release note for the full details.

 

Check out these demos to see Sun Connection's satellite deployment architecture at work.

Patching With Sun Connection – This 10 minute screen cast does a great job of showing you how to use Sun Connection to patch your Solaris OS system.

What Can Sun Connection Do? – This 40 minute screen cast goes into more detail about what Sun Connection can do. The demo includes centralized security patch analysis, system snapshot comparison and rollback, application deployment and configuration, and reports for your Solaris and Linux systems.

Learn More about Sun Connection.

In case you missed this year's JavaOne conference, I thought I'd throw in a word about our demo. We had a booth at the pavilion, and built a great exhibit of our systems management technologies.

The systems were all located in our Santa Clara campus, while we performed remote administration from downtown San Fran. We worked with a variety of mid-range servers: V240, X4100 and a T2000. We set up three logical groups of servers, with each group targeted to different jobs: Infrastructure, Test and Production.

We started with the N1 System Manager. We used  it for "bare metal provisioning"... loading an OS profile onto a bunch of clean systems. Working with a base OS, we created a bunch of Solaris zones to provide independently manageable application hosting environments. (BTW, we also automated zone creation with the Solaris Container Manager)

 

Next, we used Sun Connection for OS patching. Sun Connection simplifies patch management on a bunch of Solaris,Red Hat or SuSE systems. Depending on your needs, you can install standard patch baselines or create a custom mix of patches and config files.

 

 
After that, we used the N1 Service Provisioning System. N1 SPS is often used for advanced application provisioning... not only does it let you install software to one or many systems, you can also configure the installation on a server-by-server basis. In this case, we installed Sun's App Server, then added a JavaServer Faces application.

 

 
To round things out, we used the Sun Management Console to monitor the application. Sun MC can monitor a wide range of values on a server, from hardware all the way down to installed software. In this case, we monitored the application server configuration, looking at Web traffic, resource pool configuration... and of course the Web application itself.

 

 

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='http://www.w3.org/2001/XMLSchema-instance' name='StartServer-plan' version='5.0' path=/ >
    <paramList>
        <param name='ServerName' prompt='Enter server to start:'>
    </paramList>
    <varList>
        <var name='RunUser' default=':[session:UserName]'>
    </varList>
    <simpleSteps>
        <execNative userToRunAs=':[RunUser]'>
            <exec value='start.sh'></exec>
            <arg value=':[ServerName]'></arg>
        </execNative>
    </simpleSteps>
</executionPlan>

For more information, please read at the following links:

BigAdmin:
http://www.sun.com/bigadmin/hubs/sysmgmt/learn/training.jsp

Forums:
http://forum.java.sun.com/forum.jspa?forumID=887

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

Sun Connection allows uploading scripts as local components. There are several types of local components, 3 of them are Probes, Pre action and Post action.

Pre action runs prior to deploying a package. It can be used to stop services, notify users on the machine etc.
Post actions are being executed after the package was deployed. They can be used to restart services, clean temporary files, extract any tar balls that were deployed etc.
Probes are a Boolean conditions – if the probe returns "Yes" – the job will continue. If it returns "No" – the job will stop. Probes are used to determine requirements for deployment: enough disk space in certain partitions, enough RAM, low CPU load, no users logged in etc.

In general, Probes, Pre and Post actions can be written in Shell, Python Perl etc. The only limitation is that the target machine needs to have this interpreter installed. When writing the script for those actions, always state the interpreter in the beginning, otherwise the execution will fail. For example, the first line would be:
#!/bin/sh

With regards to exit codes – it is the same for all the scripts:  exit with a value of "0" will indicate all went well, and exit with any other code would indicate a failure. For probes, exit 0 means condition is met, meaning - continue with the job.

One important thing about Probes is that unlike the other components, Probes actually run also in simulation mode. The reason for that is that in simulation you want to check if the environment is ready for the job. For that reason, be very careful when writing probes – make sure they don’t change anything in the environment as those changes will take place in simulation mode.

Few tips:
1) Always write the script and test it outside Sun Connection first. This will speed up debugging of errors
2) Always assume that the script can be executed twice, so before changing anything – check if it was changed already
3) When running those scripts, the standard output and standard error (stdout and stderr) will go to the log file. This log file can be viewed per machine through the console.
4) The log will be available only when the job is completed

If you have any questions or suggestions for future best practices, please feel free to contact me at Eran.Steiner-AT-Sun-DOT-com.

Happy patching!

Eran Steiner
Field Enablement Team

 

Digging around on BigAdmin can really pay off where N1 SPS is concerned. In my last post, I talked about the N1 SPS Usage Best Practices Guide (PDF). For this post, I'll highlight the N1 SPS Developer Guidelines (PDF) document.

This guide describes a lot of key information about how to work with the N1 SPS XML schema for containers, components, and plans. Personal highlights for me:

• Pro/Con tables describing the advantages and disadvantages for using key features of the N1 SPS XML schema
  
• Good section describing how to use variables in components and plans
• Detailed discussion of how to use the <execNative> element to execute commands native to the target operating system
• Command line samples for common or useful commands

Definitely worth a look, as is the IT Management Hub on BigAdmnin.

Have you tried using baselines?

Every month, Sun releases a collection of patches called baselines. You can use the baselines in Sun Connection's satellite deployment architecture to patch your connected systems. If you don't want to apply certain patches, you can create black lists and white lists to create custom patch sets.

Want to take a test drive first?

Run a simulation to test the patches on your managed hosts before applying them. When you run the simulation, you can check for dependencies and find out how long it'll take to install the patches.
 

Want to learn more?

Check out this new article about How to Use Sun Connection and Baselines to Patch the Solaris OS. Stay tuned ... Doug Schwabauer has an article coming soon about how to use a baseline pre-caching script with Sun Connection to patch your Solaris OS. 

To see the latest Sun Connection information, go to the Sun Connection hub on BigAdmin.

 

Want to stay current with the latest articles on BigAdmin? 

Sign up for the New Article RSS feed on BigAdmin.

 

Laura Hartman

Tech Writer, Sun Connection

Sun N1 System Manager 1.3.3 is the next dot release of N1SM. This release is another hardware qualification release from Sun.

Sun N1 System Manager 1.3.3 adds support for more hardware platforms like Sun Blade T6300, Sun Blade X6220, Netra X4200 M2, Sun Fire V125, and Sun Blade X8420. Sun N1 System Manager 1.3.3 also supports Solaris 10 Update 3 (11/06) on the management server.

Sun N1 System Manager 1.3.3 Documentation Collection is available at http://docs.sun.com/app/docs/coll/1283.7

The documentation team has written Release Notes for this release and is available at http://docs.sun.com/app/docs/doc/820-1166

Chapter 1 talks about the new hardware and OS support for this release. Chapter 2 talks about the bugs and known issues.  Chapter 3 talks about the complete hardware and OS support of N1 System Manager. 

BigAdmin can be a tough place to find information. It's big, it's community driven, and it's trying to satisfy the needs of a variety of customers. It's your best friend -- and, sometimes, your best friend can be incredibly frustrating to work with.

 So let me be your BigAdmin search engine, and point you to a great document you might not know about -- the N1 SPS Usage Best Practices Guide (PDF). Peter Charpentier and Toli Kuznets, the authors, have compiled a bunch of great information here to help you get the most of out N1 SPS software. And it's short and sweet -- 31 pages total. Not even long enough to put you to sleep.

 The two sections of this guide that got me interested?

• CLUI Command Deciphering (p. 12, despite what it says in the table of contents) - This section breaks down the N1 SPS command line syntax, mapping out the architecture of the CLI.
  
• Modeling (p. 17) - This section describes two approaches to modeling your applications in N1 SPS -- essentially, how you break down your application into distinct parts, then capture those parts as SPS objects.

This guide's been available on BigAdmin for a while, and perhaps many of you have seen it already. But, for those who haven't, there's a lot of good information there, and on the IT Management Hub on BigAdmin.

 

Sun Connection automatically takes snapshots of the database every hour. This is done as a backup mechanism. However, in environments where a backup is performed regularly (i.e. daily or better) it is possible to disable this feature as it is an overlapping protection.
This will greatly improve the performance of the management server in environments with many machines, users and various operating systems.

Disabling database dumps in Sun Connection 1.1

Important Before disabling this feature, make sure you have the backup utility running at least once a day. The backup utility is located in:
$UCEDIR/install/backup.sh
Please refer to the Administrator guide for information on how to set this up.

All server components have "uce.rc" file with default values, and a ".uce.rc" file with values that were customized by the user. The location of the relevant configuration file is:
$UCEDIR/engine/bin/uce.rc
$UCEDIR/engine/bin/.uce.rc

By default - Linux $UCEDIR is /usr/local/uce/ and Solaris $UCEDIR is /opt/SUNWuce/.
Never change the file "uce.rc". You would want to copy the relevant line from "uce.rc" into ".uce.rc" and modify it there.
The relevant line is:
( all ) ( invisible.database.__general.save_engine_data_base_dump, true );

You can easily copy this line with the following command:
# cd /usr/local/uce/engine/bin/
# grep general.save_engine_data_base_dump uce.rc >> .uce.rc
Before performing this, make sure you don’t have this line already in .uce.rc.

Then, change the value in .uce.rc - change it to:
( all ) ( invisible.database.__general.save_engine_data_base_dump, false );

You would then want to restart the engine service:
If the management server is installed on a Solaris machine:
# svcadm disable SUNWuce/engine

Wait for the service to be offline:
# svcs –a | grep SUNWuce | grep engine
disabled 14:21:10 svc:/application/SUNWuce/engine:default

Restart the service:
# svcadm enable SUNWuce/engine

If the management server is installed on a Linux machine:
# /etc/init.d/uce_engine stop
# /etc/init.d/uce_engine start

Last, you may want to remove the current dumps. They are stored in $UCE_DIR/engine/bin/dumps/

If you have any questions or suggestions for future best practices, please feel free to contact me at Eran.Steiner-AT-Sun-DOT-com.

Happy patching!

Eran Steiner
Field Enablement Team

Sun Connection automatically manages downloads from Sun, RedHat and Suse. When a job is sent to 100 machines, each machine requests the proper patch or RPM from the management server. The management server then goes once to the internet, downloads the patch or RPM, caches it and provides it to all the machines.

This cache size is limited to make sure the disk is not getting full. The default value, however, is relatively small – only 512 megs, so if you have a big baseline to download, it's probably not going to be enough. The following procedure will allow you to increase this cache size so you can optimize the cache operation.

Increasing the cache size in Sun Connection 1.1

All server components have "uce.rc" file with default values, and a ".uce.rc" file with values that were customized by the user. The location of the configuration file is:
$UCEDIR/server/cgi-bin/uce.rc
$UCEDIR/server/cgi-bin/.uce.rc

By default - Linux $UCEDIR is /usr/local/uce/ and Solaris $UCEDIR is /opt/SUNWuce/.
Never change the file "uce.rc". You would want to copy the relevant line from "uce.rc" into ".uce.rc" and modify it there.
The relevant line is:
( all ) ( invisible.server.__general.cache_size, 512000 );

You can easily copy this line with the following command:
# cd /usr/local/uce/server/cgi-bin/
# grep general.cache_size uce.rc >> .uce.rc
Before performing this, make sure you don’t have this line already in .uce.rc.
In addition, make sure you have enough disk space available in /usr/local/uce/server/ (or /opt/SUNWuce/server in Solaris) - that's where the cache is being stored.

Then, change the value in .uce.rc - for example, in order to get about 2.5 gigs of cache, change it to:
( all ) ( invisible.server.__general.cache_size, 2500000 );

It is recommended to have anywhere between 2.5 to 5 or even 10 gigs of cache.

You would then want to restart the server:
If the management server is installed on a Solaris machine:
# svcadm disable SUNWuce/server

Wait for the service to be offline:
# svcs –a | grep SUNWuce | grep server
disabled 10:47:21 svc:/application/SUNWuce/server:default

Restart the service:
# svcadm enable SUNWuce/server

If the management server is installed on a Linux machine:
# /etc/init.d/uce_server stop
# /etc/init.d/uce_server start

If you have any questions or suggestions for future best practices, please feel free to contact me at Eran.Steiner-AT-Sun-DOT-com.

Happy patching!

Eran Steiner
Field Enablement Team