Used Ports?

Can you be more specific about what it is that is failing?

There are (at least) 3 separate network exchanges that happen in Sun Update Connection:

1. Registering your client system. When you do the initial system registration, there is communication between your client and Sun.

2. Downloading the patches to your client system. When your client system is instructed to install patches, it has to connect to Sun to download the patch files. This happens both with the local Update Manager or when managing from the portal.

3. Communication between your client system and Sun when managing from the portal. When you manage from the portal, patch install/remove instructions are sent down to your client from Sun, and status of these requests are sent back up to Sun. For this communication, I believe it is all done using standard https on the default port, 443.

I'm not sure what ports are used for (1) and (2).

But first we should try to determine where you are seeing a failure. Are you failing to successfully register the client system? Are you failing to do patch management using the Update Manager? Or are you failing to successfully manage a registered system from the Sun Update Connection portal?

smithey at 2007-7-6 13:26:11 >

During the registration process, there is an explicit selection that you have to make to allow the system to be managed from the web portal (updates.sun.com). Are you sure you selected that option?

I think you can test for this by doing (as root):

# /usr/lib/cc-ccr/bin/ccr -g cns.transport.serverurl

if it says "Property not defined: cns.transport.serverurl", you are not enabled for management at the updates.sun.com portal. If it prints out what looks like a proper URL, you should be enabled for portal-based management.

You might also try:

# /usr/lib/cc-ccr/bin/ccr -g cns.assetid

and let us know if you got a value back, or "Property not defined". That will help us evaluate the status of your registration.

As for the firewall, your stateful outgoing setting should be ok for the communication that I mentioned earlier related to sending commands from the portal down to your registered client. I don't know about the others, although I suspect all traffic on port 443 is initiated on your system.

smithey at 2007-7-6 13:26:11 >

Your account is more than likely setup correctly. We had a problem with the process that puts together the "catalog" for the updates. Instead of returning a normal catalog, we returned an empty one. A quick way to tell would be to do an

ls -l /var/sadm/spool/cache/Database

If the returned size is 382, then you did get the empty catalog (technically known as the patch db file.) A new file was already pushed to the delivery servers.

This file is normally cached for a day on the client side. One way to force Update Manager to get a fresh copy is to delete the content of the /var/sadm/spool/cache/Database directory before launching the Update Manager (or running smpatch...).

Frederic Jean

LostInColorado at 2007-7-6 13:26:11 >

Thanks, this was exactly the problem. I did have that empty database as you showed below, and removing that and running "updatemanager" and checking for updates again showed all the fixes.

Thanks for the help, and glad it was not my lack of not "RTFM".

Next question, when will this work with servers with zones setup? I noticed you can't update if you have zones on the machine (even if they are turned off when you try).

> Your account is more than likely setup correctly. We

> had a problem with the process that puts together the

> "catalog" for the updates. Instead of returning a

> normal catalog, we returned an empty one. A quick way

> to tell would be to do an

>

> ls -l /var/sadm/spool/cache/Database

>

> If the returned size is 382, then you did get the

> empty catalog (technically known as the patch db

> file.) A new file was already pushed to the delivery

> servers.

>

> This file is normally cached for a day on the client

> side. One way to force Update Manager to get a fresh

> copy is to delete the content of the

> /var/sadm/spool/cache/Database directory before

> launching the Update Manager (or running

> smpatch...).

>

> Frederic Jean

mrlancealot at 2007-7-6 13:26:11 >

So what are my options to patching a machine with zones setup on it if patchadd doesn't even support a machine with zones correctly?

This must of been turned off recently in "smpatch", because when I ran "smpatch" in the past it updated on my machine with zones. I guess problems were found and was disabled.

So what can I do to patch my machine that has zones setup on it?

> smpatch and Patchpro uses patchadd to install

> patches. My understanding is that there is are a

> number of issues in regards to local zones support

> with patchadd and patchrm (you'll see them if you go

> to sunsolve and do a search for "patchadd zones").

>

> Once patchadd and patchrm works correctly with zones,

> we will be able to add support for patching local

> zones to the Update Manager (through smpatch).

>

> Frederic Jean

mrlancealot at 2007-7-6 13:26:11 >