Cluster 3. Update 11 for Solaris 10 is probably last Release of Solaris 10 and has some new features, which are not available if you only patching a system with Recommended Patches. Before starting with upgrade it is good to check and fix any issues with current system and environment. Please check a Cluster status, Quorum device status, running services, zpools, metadevices, metasets, hardware components etc. If you have any issues, fix them before you start. Plan your Maintenance Window, make backup of your files and configuration.
If you have the newest version of OS or Cluster, you can just omit related part of this article. You can download binaries from Oracle after login to Oracle Support. Copy above software to servers and unpack in local directory. Do not use shared directory from NFS, because you will not be able to install patches. Leave ISO image as is, it will be mounted as lofs. A propos lofs: if you have automounter autofs service and SUNW.
There is no other way, sorry. This is my list: Without this patch your chances to hit a bug with ABE creation are significally increased. For x86 systems this patch has number increased by one: XX. If you have root filesystem on ZFS, just make:. And the same on other Cluster nodes. There is another school, which tells that one should split mirror manually and then make a lucreate, but above scenario is much faster, because data are up to date, and lucreate does not need to copy them.
ABE creation process looks as follows:. If you believe that everything is OK, analyze truss output or send it to Oracle Support. You will need to wait some time for data synchronization betweend current and new BE. Check BE with lustatus:. Mount the Solaris 10 u11 ISO image and make luupgrade:.
Once you have a list of possible patches, use the showrev -p command to see which patches are currently installed on the system and remedy any differences.
As always, be sure you have a working backup of your system before making major changes such as installing patches. Note that, rarely, patches that are installed do not appear in the showrev -p list. These are patches which include only firmware, and make no system code changes. Because there are no software changes, they are not recorded as an installed patch.
The Web site can send a notification when any document of interest changes. PatchDiag uses information from uname, pkginfo, and showrev -p to determine the software and patches installed on your system. It then uses a patch cross-reference patchdiag. The result is a report that lists up-to-date patches, patches that are out-of-date, and needed, recommended, security, and Y2K patches. You can then use this list as a basis for patch installations. The program also allows command-line arguments which direct it to pkginfo and showrev output stored in files.
In this way, PatchDiag can work on state information saved on other hosts. You could collect package and patch information from all Solaris machines, run PatchDiag against each set of information, and have a report listing the patches needed on each host. If desired, it will reboot the machine after it is through. It provides many different ways to get the files, from a common NFS directory to local directory access.
It will take a list of patches to be installed from the source directory and skip the others, or it will let you specify patches to install on the command line.
Finally, it will take compressed patches from one directory and uncompress them in another, just in case you have read-only NFS. PatchReport is written in Perl and does require a few extra Perl libraries. If this column has convinced you to revamp your patch practices, PatchReport could be just to tool to make your patch duties more manageable.
One lesson system administrators learn the hard way is to open support ticket, no matter what. For instance, a search of may reveal that a patch exists that looks like an exact remedy to a problem.
Great, but a quick exchange via ticket can sometimes reveal that the problem is a hardware issue, or that there's a procedure that needs to be followed that isn't indicated in the patch README. The folks at technical support have more information available than you'll find. Use them whenever you have any doubts. They often contain crucial information! Patching production systems more often then once a month is a questionable practice. Typically once a quarter schedule is adequate as it gives time to test the patch cluster.
Here definitely less is more. One thing to look out for with firmware patches PROM patches in particular is that some don't like having a serial-port-attached terminal for a console.
I just installed such a patch, and it took quite some time before this was discovered. Make sure you read the postscript files before you install patches, because the README files don't have this information. A little FYI from a slightly burnt admin. Some patches replace binaries wholesale, and most recommended and suggested clusters include updates to Sendmail and BIND. Many people are using later versions of Sendmail and Bind then supplied by Sun.
When you apply the recommended patch cluster, these binaries are overwritten. Be sure to save such binaries before patching and restore afterward, or edit the patch list, or both, to avoid this problem. Long story short: preconfigured, prepatched and stringently tested Solaris images. This is what system engineering and platform lifecycle management are all about. At the very core, we can summarize the above terms to standardized Flash TM builds, preconfigured, prepatched and rigorously tested Solaris images.
Note that I'm not referring to Sun development, although one can surmise they have similar practices. Also, ad-hoc changes , and this includes patching, are strictly banned, prohibited, and forbidden, unless engineering tested them and approved them.
Today, most customers don't run OpenSolaris; they run a supported version of Solaris such as Solaris 8, 9 or A supported release means that someone will answer the phone, and that patches for problems are available. Patches are a separate software change control mechanism distinct from package versions in Solaris.
Each patch may affect portions of several packages; patches are intended to include all the files necessary to fix one or more problems, either directly or by specifying dependencies. If a patch affects packages which are not installed on this system typically because it has been minimized , those portions of the patch are not installed.
If the administrator later adds the missing package, he must remember good luck to re-apply the patches since the packaging code knows nothing of patches.
Customers are today free to install which ever patches they feel are appropriate for their environment, consistent with the built-in dependency requirements. This customization is a technique I refer to as Dim Sum patching, and is a major cause of patching difficulties. Many customers pick and choose amongst the thousands of patches available for Solaris 10, for example; this means that customers are often pioneering new configurations. Note that each Solaris release consists of a single source base; all Solaris 10 updates, for example, are but snapshots of the same Solaris patch gate at different times.
As a result, the developers are working on a cumulative set of all previous changes; when a new patch is created, the files in the patch not only contain the desired fix, but all previous fixes as well. Thus, the software change is constructed as a linear stream of change, but customers installs selected binaries from the various builds via patches. When I've discussed the hazards of Dim Sum patching with customers, the reasons given are typically characterizable as :. For our new packaging system, there is a powerful incentive to eliminate Dim Sum patching: since we wish to use a single version numbering space for any package, attempting to support fine-grain Dim Sum patching would require very small packages - affecting the performance of packaging operations, and significantly increasing the workload of OpenSolaris developers.
Instead, we can set package boundaries according to what makes sense for minimization purposes. This implies that future post Solaris 11 patches will be completely cumulative aside from some exceptions for urgent security fixes , at least for the core OS.
Your system will be able to determine what is needed to bring the installed software up to the desired revision level automatically; needing to pick and choose patches will be a thing of the past. About: Patch Check Advanced pca generates lists of installed and missing patches for Sun Solaris systems and optionally downloads patches. It resolves dependencies between patches and installs them in the correct order. Changes: Checks for patches that are only partly installed have been added.
A bug with missing patches with multiple versions of the same package has been fixed. Failed patch installs are logged to syslog. Minage option being one day off has been fixed. The code was simplified in several places. Patch handling has been added for several new patches. Get information about how Sun Connection can help you to deploy, manage, and track software updates on your systems that use the Solaris OS or Linux OS.
This community web site is the place to share and view tips and tricks from other sys admins who are using Sun Connection. To see contributions from the community, or to submit content, click Participate.
Would you like to use Sun Update Connection System and the Sun Update Connection Proxy to manage your systems against fixed "baseline" patch sets representing a point in time, using a local source of patches? Although Sun's tools don't directly support this, it can be done. The following write-up explains how. Sun Update Connection uses a patch set file that it retrieves from its patch source, either directly from Sun's patch server or indirectly through a Sun Update Connection Proxy also known as a local patch server or LPS.
The default patch set, current. The current. If you copy today's current. For example, to create a baseline for November 10, , copy the current.
Perform these tasks to configure a proxy server for your environment and establish a patch baseline:. The server can be configured in either connected or standalone mode. If the server is configured in connected mode, it will send requests to Sun to get patches and patch metadata that are not in its local cache.
The requests can be sent to Sun through an intervening server. If a server is configured in standalone mode, it does not have any connections to Sun and is limited to the data that is available in its local repository. Once your proxy is configured, point your clients to the proxy server. Set the server's patch source:.
Congratulations, you now have a local patch server. If you're running in connected mode there is really nothing more you need to do but get to work. If you are running in standalone mode you need to plan how you will populate and manage the local repository.
If you are running in standalone mode you must manually populate your server's repository with patches and patch metadata files. The format of the local repository is as follows. The most straightforward way of populating a standalone patch server is to alternate between connected and disconnected modes.
When connected, the Proxy can retrieve the current patch metadata file, current. If you know the specific patches that your environment will need you can also use the smpatch download command with the -f option to download the specific patches. You can use other methods to get the right set of patches into the cache that might be needed in your environment.
You could then do this same operation on your local client systems to produce a master list of patches needed for these systems. Once you have a master patch list, you can include it in the smpatch command as follows:.
When your local patch source is populated with a current detectors. I need this patchset to avoid downloading 30 individual patches that I need to install an Oracle upgrade. Join Date: Jul Find all posts by DukeNuke2. Join Date: Feb They have a script you can use to retrieve the info. They just want everyone to have a sunsolve account in order to retrieve the patches. I retrieved the script and modified it to retrieve the patchdiag. Code :. I tried to retrive the Patch Cluster from Sun but got the following error: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster sunsolve. More information about this error may be available in the server error log. I sent mail to the e-mail address yesterday, but have not heard back. I just tried the posted link I provided yesterday and it works fine. Perhaps the server was down. Try again. Here is the URL with quotes to prevent abbreviation. I went through sunsolve. That is where I got the error. Thanks for the link.
I downloaded the file with no problem. NIS broken after installing patch cluster on Solaris After reboot global zone is fine, but a lot of services was in uninitialized state. Now I can't login to server with NIS account Hi all, I am exploring how I can automate the download and patching of my AIX servers via a central management mechanism.
I will need to patch all my servers annually to a certain pre-determined Service Pack SP level.
0コメント