Vassun, >>Sure - dryrun is exist it is as I remember "-a" option and it reports all >>what it discovered in great extent.
ok, then it's a useful feature for us even if we only use it to create the list of patches to install >>We can keep -t as long as you need for transition period. ok >>I thought patching from directory will actually be more useful for big >>company IT, because you may put all tested patches in one place and run >>patchadd pointing to it - and you do know what will be applied, all patches >>from this directory. That's okay if the company can decide which patches should be applied to all Solaris machines. But if the customers that are using the machines can decide which patches should be installed and which not (depending on the application demands) it's not very useful. In the worst case using this approach we would need one directory for every machine. >> And this is additional feature - everything else - patchlist file, >> command line etc, work as it work before, except no need for ordering. Is this feature "no need for ordering" already included in the patchadd of Solaris 10 Update 3? >>The question is which failed patch to report. Kshell script has exit >>first time it finds error and it is always first bad patch in the sequence. That's the reason why we do call the "old" patchadd always only for one patch (and not with a list of patches). >>Recursive pdo algorithm do not have concept of sequential check - order >>for patches to be installed is what it determines also. I can exit with >>single error code easy, but which failed patch should I report, one of >>them incompatible, another one do not have requirement met? For our environment it's sufficient if patchadd returns a non-zero return code if at least one patch installation failed. If this is the case there should be more information in the logfile about the reason for the patch installation failure and maybe a summary printed to STDERR. patchadd errors because a package is missing or because a patch is already installed should be ignored. >>I can report >>one which first in the list provided to patchadd, but what about patching >>from directory? Which one to pick? I'm not sure if we could use the "patching from a directory" method at all. We still have Solaris 8 and Solaris 9 in place and we must take care that the patch process is equal as much as possible for all Solaris versions in production. When the majority of our Solaris Boxes are using Solaris 10 or newer it might be again an option to redesign our patch process using more of the new features of Solaris 10. >>I can imagine something like - "report status of this patch if we try to >>install it with that other patches". Like additional option specifying >>patch which you are interested in. Pdo is so fast that analyzing all >>patches to report only one will take no time and not a problem. ?? >>But how apply this exit policy to the zones? It is not even linear but >>two-dimentional - zones x patches. Indeed, zones make it more complicated. At this time we do not support zones in our environment but we will support them in the future. >>Other question is now if I have rejected patches I will proceed with >>all applicable anyway and install them. Reason for this - we should >>not stop installation if on one zone one of the patches already >>installed by zone admin. So for this reason if there is a subset >>of patches applicable patchadd will apply it. That's okay - our patch script uses the same approach: If the installation of one patch fails, it prints an error message, saves the return code, and continues to install the remaining patches. At the end it returns either 0 if there were no patchadd errors or a return code not equal 0 if there were at least one patchadd error. In this case an engineer has to check the logfile to see which patches failed and to correct the situation. >>What exit code should be if some patches installed and some did not? an exit code not equal zero, see my explanation above. >>It is not a complete failure on my opinion. No, but it is a failure that must be checked and corrected. >>BTW, You may try recursive patching demo it is awailable for download. I saw it today (I'm not subscribed to this discussion) regards Bernd This message posted from opensolaris.org
