There are two options in terms of where to point to:
- A local update proxy/cache.
Requires a fully functional patchsvr
More convenient and efficient.
- Directly to Oracle after proper system registration.
Requires individual configuration of proxy parameters.
Could be left as a last resort.
# smpatch set patchpro.patch.source=http://patchsvr-1:3816
$ smpatch get
patchpro.backout.directory | "" | "" |
patchpro.baseline.directory | "" | /var/sadm/spool |
patchpro.download.directory | "" | /var/sadm/spool |
patchpro.install.types | - | rebootafter:reconfigafter:standard |
patchpro.patch.source |
...
| https://updates.oracle.com/ |
patchpro.patchset | - | current3 |
patchpro.proxy.host | - | "" |
patchpro.proxy.passwd | **** | **** |
patchpro.proxy.port | - | 8080 |
patchpro.proxy.user | - | "" |
Don't set any special backout directory as it doesn't work probably due to a bug.
This way the default backout directory /var/sadm/patch is used which is fine.
Some changes to an updating configuration may require cleaning caches:
If using a patchsvr, stop and clear the server cache first.
Then, proceed with the client cache clean-up:
# cd /var/sadm/spool
# rm cache/xml/*
# rm cache/updatemanager/analysis.results/*
# rm cache/entitlement/*
# rm cache/Database/*
# rm cache/*detectors*
At last, start the patchsvr again:
patchsvr-1# patchsvr start