Tuesday Jul 24, 2007

Sun Connection and SunGDD

What is  SunGDD ? It is a project to help customer deliver the correct debug information back to Sun in case there are any bugs or issues. This is not Explorer. These scripts are product oriented and unique per product.

So SunGDD is now in the works to be released for Sun Connection 1.1 and 1.1.x. This is a screenshot of the help page:

This is the helpscreen
Usage: ./SUN-GDD_sun-connection-collect_noarch.sh [options]
  -collect                Collect Data
  -debugAgent             Enable Agent Debug
  -debugServer            Enable Server Debug
  -debugEngine            Enable Engine Debug
  -debugAll               Enable Debug for All
  -restoreAgent           Restore Agent Debug
  -restoreServer          Restore Server Debug
  -restoreEngine          Restore Engine Debug
  -restoreAll             Restore Debug for All
  -h or -help             Print this Information.

At least one option is mandatory or the script will just exit.

So the script will help to enable and restore debug levels of the product and then be able to collect all the needed logfiles, configuration files and other miscellaneous data that can help Sun with any kind of problem that may happen with the product.

Stay tuned for release date!!

Peter Charpentier
SysNet Field Enablement Team

Monday Jul 16, 2007

Marley's day at the dog park

Steve Wilson challenged us to put yourselves on YouTube. While I'm not ready to post videos of myself, I am ready to put my dog out there. This really happened, so it seems like a good place to start.

Marley and I were at the dog park a couple of weeks ago and I was chatting with Sue while our dogs played. When she learned that I work at Sun, she asked me about Sun Connection's Inventory Channel. She wanted the inside scoop. We talked for quite awhile and I thought that we'd covered everything. I was surprised when Sue tracked me down at work the next morning (impressive, since she hadn't written down my name or number) and set up an impromptu conference call with one of her co-workers. We went through everything that we talked about at the park, and more.

What is Sun Connection's Inventory Channel?
It's a new web-based service that you can use to register one or more of your eligible IT assets at the same time, and then use it to manage your registered inventory.

How does registration work?
If Sun Service Tags are embedded in your software, hardware, or storage devices, you can register them. Service tags are very lightweight and don't do anything on their own, you control the registration.
To register:

  1. Get the Product Registration Manager.
  2. Go to the Inventory Channel and click Discover Now to find out what's available for registration. You can define the scan parameters, such as scan your local subnet, or enter specific subnets, host names, or IP addresses.
  3. Log in to the Inventory Channel with your Sun Online Account ID and select the product or products you want to register, then click Next to complete the registration.
  4. View your registered assets in the Inventory Channel. If you want to track other information, edit the asset details.

That's it. Once registered, you can group the assets and then export the information in an XML, CSV, or PDF format. Just what the boss wants, without manually updating a spreadsheet ...and, it's free. No cost, nada!

Get more information here, or check out this screen cast to learn how to manage and organize your registered assets.
Want to see Marley in action? Check out his YouTube video.

See you at the park!
Marley and Laura


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


Thursday May 17, 2007

Best Practices - Using Probes, Pre and Post actions

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:

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


Monday Apr 30, 2007

Looking for a new way to patch your Solaris systems?

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

Friday Apr 27, 2007

Best Practices – Performance improvement

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:
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:

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




« July 2016