It gives you unified, near real-time visibility and enforcement to deploy and manage patches to all Debian endpoints. For more information about the download cacher, see Solaris download cacher tool overview. For air-gapped environments, you can run the Solaris download cacher utility manually. Learning Academy.
Customer Support. Home Patch User Guides BigFix Patch provides an automated, simplified patching process that is administered from a single console. Patch for Solaris User's Guide BigFix Patch for Solaris provides an automated, simplified patching process that is administered from a single console.
Using the Solaris download cacher Use the Solaris download cacher utility to pre-cache Solaris updates to the BigFix server or to a specified target directory before deploying the Fixlets to targeted endpoints. Patch User Guides BigFix Patch provides an automated, simplified patching process that is administered from a single console.
Patch for Ubuntu User's Guide BigFix Patch for Ubuntu provides an automated, simplified patching process that is administered from a single console. Overview BigFix Patch for Solaris provides unified, real-time visibility and enforcement to deploy and manage patches to all Solaris endpoints from a single console. Manage Download Plug-ins dashboard overview Use the Manage Download Plug-ins dashboard to oversee and manage download plug-ins in your deployment.
Mirror management BigFix provides tasks to help with the failback options for your mirror management solution. Patching using Fixlets You can apply Solaris patches to your deployment by using the Fixlets on the available Solaris sites. Local repositories BigFix provides a method for using local repositories to store patch updates for Solaris Single-user mode patch application You must bring computers into single-user mode to prepare them for kernel-level or cluster-level patching.
Creating a baseline for single-user mode Create a baseline to modify a Solaris patch Fixlet for single-user mode.
Deploying Solaris packages You can control which packages to deploy to Solaris computers that have the BigFix client installed. Retrieving installed package information You can retrieve a list of all installed packages on Solaris 10 and 11 endpoints by activating analyses on the BigFix console. Retrieving the endpoint upgrade list You can retrieve a list of the Solaris 10 and 11 endpoints that contain packages with available updates by activating analyses on the BigFix console.
Superseded Fixlets Superseded Fixlets are Fixlets that contain outdated patch packages. Enabling superseded Fixlets You can install an earlier version of a Solaris patch by enabling superseded Fixlets. Solaris zone patching Patch Management for Solaris supports zone patching on Solaris 10 endpoints. Solaris Live Upgrade support Use the Solaris Live Upgrade tool to manage system downtime and risk when installing patches on alternate boot environments on Solaris 9 and 10 computers.
Frequently asked questions To better understand BigFix Patch for Solaris, read the following questions and answers. Patch for Debian User's Guide BigFix Patch for Debian provides an automated, simplified patching process that is administered from a single console. Virtual Endpoint Manager User's Guide. Note: The Windows BigFix server and relays must be subscribed to the Patches for Solaris site for the task to be relevant.
Note: Solaris Download cacher Solaris 11 does not support caching files for Patches. To run in interactive mode: SolarisDownloadCacher. The current state of all fixes is available in the development version of pca. And Sun did it again - there have been some modifications to sunsolve.
A first attempt to fix the issue is available in the development version of pca. If the fix doesn't work for you, please report back to me. Unfortunately, Sun's download server seems to be a little flakey, too. Patch downloads seem to fail from time to time. You might be able to workaround this issue by setting pca's --dltries option to something higher than 1. Thanks to all of you who reported the problems, and provided fixes or workarounds.
In the next days, I will try to get out a new release of pca which should fix the mentioned issues and I'll reply to the messages which I received while I was gone. Messages will be answered when I'm back. The article is a great introduction for new pca users as well.
I'd be happy to get my hands on a printed copy of that magazine for my wall of fame. If you have it, and are willing to send it to me, contact me by e-mail to martin par. Thanks to all! In today's patchdiag. I have added a workaround in the development version of pca. I had implemented a workaround in pca so these were shown nevertheless, and sent countless queries to Sun in the last 18 months. Thanks a lot to the unknown Sun engineer s who fixed this!
Both take a URL as argument. By separating localurl into two options, it's now possible to specify different local sources for the patchdiag. One example is to point patchurl at pca-proxy. For downward compatibility, localurl is still recognized, and its argument will be used as the value for patchurl and xrefurl if those are not set.
Well worth reading to get up-to-date on Sun's patch access policy. A new and simpler algorithm for automatic download of the xref file is used; if the file is older than three hours, pca will download it again.
The check for patches which require a reboot has been enhanced. After patch installation, pca will tell whether a reboot or reconfiguration reboot is required or recommended.
In combination with the change in the URL for downloading the xref file, this creates a nasty problem: pca now downloads the xref file on every run. To stop it from doing that, you can use the nocheckxref option, either in a configuration file or on the command line. Background: pca tries to be clever; it knows that every week from Monday to Friday at a certain time a new xref file is published, and from the timestamp on the local xref file it can guesstimate when a new one is available.
When the new file should be there, pca tries to download it on every run. Until recently, it wasn't a big problem when Sun skipped a day which happens rarely anyway. Update : I decided to implement a much simpler algorithm for the automatic download of the xref file. If there is no local copy of the xref file or if it's older than one hour, pca will download the file from sunsolve or localurl.
If the local copy has been updated in the last hour, pca will use the file as is. This change does away with all the sophisticated guessing and checking if a new version might be available. The change is available in the development version of pca. I have put a fix with the new link into the development version of pca. Please download and use this to make automatic downloads of the cross reference file work again. Thanks not to Sun for not announcing this properly in advance.
The policy and URLs to download patches for Solaris 8 and 9 have changed as well. Feed account data to pca via its user and passwd options, or by using --askauth.
If you do not have a free! I will test the implications of the changes next week, and come up with an official version of pca including the fixes as soon as possible. Thanks to all the pca users who reported the problem! I have fixed the bug in the development version of pca.
Thanks to Martin Wismer for reporting this! In the most recent patchdiag. I have added a workaround to the development version of pca. For example, m can be used for missing , mrs for missingrs , but missrs is not allowed. This applies to all patch groups missing, installed, all, total, unbundled, bad. The operand specified when running pca will be shown in the header output of pca.
Unlike the old options, these can be used in configuration files, environment variables and on the command line.
Example: pca --ignore --ignore The old options are still used, but deprecated. Patches set to be ignored will now be ignored with all patch groups. Download of any restricted patch fails or returns size 0 files, and interactive access via the Patch Finder is either delayed infinitely or returns proxy errors, HTTP code or size 0 files.
When trying to download the affected patches from SunSolve, a size-zero file is returned. This is Sun's fault, and I reported it to them repeatedly.
It's extremely annoying, but there's no way for pca to fix this. See the contrib page for detail. Thanks a lot to Chris for the contribution! It's only about a quarter of the size it should have. The result is that pca output is broken, too. I reported the problem to Sun, who hopefully will fix this soon, at least in the next release of patchdiag. For your convenience, here's a temporary copy of the last valid patchdiag.
Use touch -t patchdiag. Thanks to all pca users who reported this to me, too! There have been reports about the broken showrev behaviour on systems with the new kernel patches for SPARC and for x86 , too.
If you install these patches, make sure to install and , too. No other patches can be installed before the system has been rebooted.
Another important change in Sun's patch access policy has been announced in InfoDoc The most important change is that access to Solaris 8 and 9 patches will be restricted in the same way as access to Solaris 10 patches already is.
As soon as the policy change is enforced I've heard about March 31st, , a free Sun Online Account will be necessary to access Solaris 8 and 9 security patches, and a Sun Service Plan non-free will be needed to access any non-security Solaris 8 and 9 patch. As far as pca is concerned, it should continue to work as-is.
As this command is used by pca to get the list of installed patches, pca's output is incorrect, too. I have implemented a workaround to avoid the showrev command on Solaris 10 x86 and to use patchadd -p instead. You can get the fix by downloading the current development version of pca. A new official release of pca will follow in the next days.
Unfortunately, no new comments can be posted anymore, but here's what I would have liked to post: You correctly noticed that "most administrators still choose to manage their updates through legacy, non-connected tools". In fact it's more like that administrators again use other tools, after getting upset with Sun Update Connection, especially its bugs, slowness, incorrectness and inability to run on older Sun gear and stripped-down machines.
I'm the author of PCA , an alternative and free tool for patch management. A huge number of Solaris administrators have switched from SUC to PCA, and this includes especially experienced staff managing large networks of Sun hardware.
I received a lot of feedback, much of it concluding in "This is the tool that Sun should include for patch management". Feel free to take a look at it, and maybe experience the same. I'm a long-time fan of Sun and Solaris and have read and heard a lot about administrators' experiences with patch management.
Sun should be aware that this is one huge topic driving people away from Solaris, and not attracting them. While he tells his boss that the SUC is used for patch management to not get him upset, he in fact switched to PCA a year ago, and is now happy again.. Also, there is a new patch group total , which will list all patches from the xref file, no matter whether they apply to the current system or not.
This makes pca much more flexible. Examples: To list all Sun Studio patches which are missing on a system, use pca -p Studio. To install the current sendmail patch, use pca -p sendmail -i. To see all sendmail patches for all Solaris releases and architectures, use pca -p sendmail -l total. Other new features requested by pca users are that a single pager process is called for multiple READMEs allowing to switch back and forth between files , and that downloaded patches will be removed after installation to save space; if you want to keep the downloaded patches, use pca --download --install instead of pca --install.
As it is now, the search pattern is only useful when trying to find certain patches for all Solaris versions and architectures. I have already implemented a much more flexible solution for search patterns, available in pca 5. This seems to have been fixed, as the last three releases of the xref file again had a whole lot of new patches. See this blog entry for more detail.
We discussed this in a thread on the Solaris x86 mailing list. Bruce Riddle has been trying to get this fixed via Sun Support, but to no avail. It takes another day until they actually make it onto Sun's patch server. As an example, today's xref file shows , , and which can't be downloaded. For pca users this means that these patches will fail to download today, but most probably they will download fine tomorrow. My recurring proposal to SunSolve support staff to make sure that patches are available for download before they are published in patchdiag.
Unfortunately the old problem I've mentioned multiple times before is showing up again, too: Many of the new patches for Solaris 10 are unavailable on Sun's patch server, so pca will fail to download them. Once again, I immediately reported this to Sun's patch team. There are about 40 new patches in the most recent patch cross reference file, and all of them downloaded and installed successfully. This gives hope that both the problem with no new patches appearing in the last 2 or 3 weeks and the problem with failing patch downloads have been fixed.
This probably explains why there have been no new patches for the last 10 days. Z patches more robust Fix signal handler and cleanup on exit Fix bugs where a zero size patch file was created Fix error output in local caching proxy mode Set umask for extracted patches to make sure patchadd won't fail Fix bugs in lockfile handling Use HTTP redirection with Location header in local caching proxy mode Update whitelist for safe patch install mode Update patch-specific function to avoid showing uninstallable patches If the localurl option is set, pca will now look for the patchdiag.
This version of pca contains a lot of fixes for small bugs, mostly for patch installation and the local caching proxy mode of pca. I'm in contact with Sun's Patch Team, who have acknowledged this as a timing issue. They confirmed that they are working on a fix. Many of the patches which are listed as new or updated in today's patchdiag. For Solaris 10, I get failed downloads for , , , , , , , Most probably the patches will be available tomorrow, but it's a real nuisance that Sun can't coordinate patchdiag.
The new configuration files are completely optional, too. The functionality of the pca. The new caching proxy mode of pca replaces the pca-proxy script I had offered on the Contrib page before. The readme option -r, --readme now accepts any operand, just like the list, download and install options. This affects pca's -r option, too. I will try to fix it in the next release of pca, but as long as Sun breaks existing interfaces and won't replace it with stable procedures, it's impossible to promise anything.
Patch downloads fail intermittently, causing failed patch downloads with pca. Therefore, I modified pca to re-try failed patch downloads. The fix will be in the next official version of pca.
If you need it immediately, grab the development version of pca which already includes the fix. Sometimes a patch re-delivers and silently overwrites files which have been modified locally. If any file is in danger of being overwritten, pca issues a warning and does not install the affected patch.
Safe mode is off by default, and can be turned on by using -s in combination with -i install patches or -I pretend to install patches. You must be root to use -s, as root permissions are required for pkgchk with certain files. Sometimes the file checksums used by pkgchk are wrong, because patches modify files without updating the checksum. Only Sun can fix this. For now, pca uses a whitelist which I built during testing the new feature with a huge set of patches.
I'm very interested in real-world experience with the new feature. Running pca -s -I is a safe way of identifying problematic patches without actually installing them. It will speed things up dramatically and ease bandwidth usage on your connection to Sun's patch server. If it doesn't, it uses pca to download the file from Sun's patch server, puts it into the cache and delivers it.
Migration Robot asked a question. Another question, how does the downloader actually reach out for the files We are attempting to execute the downloader while filtering the patches by Cluster Name. I believe we have the cluster name correct but it gives us the following message when we attempt to run it:. Downloader warning: Cluster name and cluster payload location is not found.. Skipping cluster filter from update.
We have it working using the OS filters, we just can't get it to work using cluster filters. We are on sp7p4 and everything is working fine other than the cluster filtering. That will be my next step. We have a ticket open with Oracle to make sure that the Cluster name's are what they should be. On a related note, has anyone else seen problems downloading some patches on the patch catalogue update since the Oracle changes?
We are seeing some HTTP errors when doing the catalog update for specific patches. If we connect directly to the Oracle pages with the support account, it does not see the patches either, so it looks like the support accounts may be restricted on the patches that they can download.
This then really slows down the downloads though as it seems to wait nearly 3 minutes between patches if it gets a error. The issue Paul mentions appears to be that our support contract does not allow access to all Oracle Solaris patches - there are a subset of 89 patches to which our contract doesn't allow downloads.
When BladeLogic comes to download these it appears to pause for around 3 minutes even though Oracle reply with a status code.
0コメント