We have a service contract and a host registred at update connection.
Previously we could use this host as a proxy to get any patch
but now we only seem to be able to get security patches via the
proxy.
Is this a new limitation of Update Connection or is it a bug?
Dp we need to revert to downloading tha patches manually
for tehse systems?
(This is for hosts s running Solartis 10.)
We've set the smpatch propery on all hosts to fetch from the proxy.
This works fine exept for non securty patches. This changed about 1 month ago,
Now you get
client# smpatch download -i 118959-03
Error: One or more of the updates specified do not have entitlement permissions.
But on the proxy (registered with Sun) you get
patchproxy# smpatch download -i 118959-03
118959-03 has been validated.
(The proxy host uses itself as proxy for the updates...)
So the patch may be downloaded via proxy but only on hosts registered for updates.
(which is the same behavioir as without using proxy previuosly.).
Our type of contract only allow us do register 1 host (I think).
We can fix workouroud for this, by downloading the patches manually, but we like the
ide of smpatch and hope to get it useable in our environment.
> Hi klas.h
>
> It should not be necessary to register hosts behind a
> Sun Update proxy.
Then this is a change. We have used the proxy and updated
all hosts with all recommended patyches previously.
>
> Could you check 'smpatch get' on the client, and make
> sure it's pointing to the proxy host for updates?
It does use he proxy and we can download security patches via the proxy, but not
others recommended anymore.
It is sad to loose this functionallity. Do we need to use a wget-script to get
the recommencded patches? (We can even get them from the proxy via
another webserver of via nfs, since we do have them downloaded.)
Why was this restriction added?
Message was edited by:
klas.h
Message was edited by:
klas.h
> When using a Sun UC proxy the only system you need to
> register with a subscription key is the proxy itself.
> All other clients using the proxy do not need to be
> registered with a subscription key but will still be
> entitled to all updates through the Sun UC proxy.
As I wrote, this was they way it worked before here. Beginning in June, this
is no longer the case. The proxy (using itself as prox) is entitled to download.
We have to omit recommended patches for our wishlist when downloading.
Here is output from the sessions (with names changed to reflect setup):
client# smpatch download -i 118959-03
Error: One or more of the updates specified do not have entitlement permissions.
client # smpatch get
patchpr.backout.directory-""
patchpro.download.directory-/var/sadm/spool
patchpro.install.types standardrebootafter:reconfigafter:standard
patchpro.patch.sourcehttp://proxy:3816//solaris https://getupdates1.sun.com/solaris/
patchpro.patchset-current
patchpro.proxy.host -""
patchpro.proxy.passwd********
patchpro.proxy.port -8080
patchpro.proxy.user -""
proxy# smpatch get
patchpro.backout.directory-""
patchpro.download.directory-/var/sadm/spool
patchpro.install.types standardrebootafter:reconfigafter:standard
patchpro.patch.sourcehttp://proxy:3816//solaris https://getupdates1.sun.com/solaris/
patchpro.patchsetsunu45 current
patchpro.proxy.host -""
patchpro.proxy.passwd********
patchpro.proxy.port -8080
patchpro.proxy.user -""
proxy# smpatch download -i 118959-03
118959-03 has been validated.
> Can you post the output of the following command run
> on the SunUC proxy server -
>
> # patchsvr setup -l
proxy# patchsvr setup -l
Patch source URL: https://getupdates.sun.com/solaris/
Cache Location: /disk0/updates/solaris
Web proxy host name:
Web proxy port number: 8080
Web proxy user:
I notice in a previous post, 'smpatch get' produced:
patchpro.patch.source http://proxy:3816//solaris https://getupdates1.sun.com/solaris/
This should read:
patchpro.patch.source http://proxy:3816/solaris/ https://getupdates1.sun.com/solaris/
Since the first URL was incorrect, smpatch was probably falling back to the getupdates1 URL.
> I notice in a previous post, 'smpatch get' produced:
> patchpro.patch.source http://proxy:3816//solaris
> https://getupdates1.sun.com/solaris/
>
> This should read:
> patchpro.patch.source http://proxy:3816/solaris/
> https://getupdates1.sun.com/solaris/
>
> Since the first URL was incorrect, smpatch was
> probably falling back to the getupdates1 URL.
Hm, it really does not seem to matter what the last part of the URL is.
Setting this to
http://proxy:3816/junk/
will still work .I get the patches via the proxy (from a host that cannot reach
suns update server).
Setting another port number WILL make it fail, and this dows not fall
back to Suns update server.
But now updates works again. I can get non security patches via the proxy,
(I even think I at some time could get them from Sun, but I cannot verify this right
now.)
I guess there are things happening on the server side that implements the
policy for getting patches.
