Re: [pca] confirming the validiting of a home grown patch_order file
Thomas Gouverneur wrote: I've managed to de-obsolete patches where dependencies weren't included into the patchdiag.xref so now PCA should really be happy with the output.. Yes, the obsoletion chain now looks fine in the example I tried. Let's see whether somebody else will give it a try. Martin.
Re: [pca] confirming the validiting of a home grown patch_order file
Martin, This one was a bit more delayed to be implemented ;) I've managed to de-obsolete patches where dependencies weren't included into the patchdiag.xref so now PCA should really be happy with the output.. Can you check also to have a second-brain view on that ? Regards, Thomas On Tue, 31 Jan 2012 16:16:37 +0100 Martin Paul mar...@par.univie.ac.at wrote: - populating the xref - Assume only one rev (the last used in dependencies) is present per patch - Removing any obsolete flag and Obsoleted by: text inside the synopsis. Correct? Yup, think so. I can also do it this way... I got all the info I need, I can even imagine to allow the user to choose which method is the best for him Yes, at the end having an option would probably be best. Like if you would apply the 10 Recommended patch cluster without downloading every single patch which is in it. You simply could generate xref from the list of patches it contains and then run pca against this xref... wouldn't that be a wonderful world ? The basic design of Sun's patching design using patchdiag.xref really isn't (or wasn't) all that bad. Besides just having one current master xref file, one can put it to good use which such custom xref files; Sun, with the access to all the patch metadata could've done wonderful things. Alone the fact that one can use a frozen copy of an xref file to put a certain patching milestone on any given machine even months later is a great thing, used by many. It's just sad that all this has an expiration date on it since Solaris 11 and IPS appeared. Martin. -- Thomas Gouverneur _ _ | |___ _ __ (_)_ __ | _| / __| '_ \| \ \/ / | |___\__ \ |_) | | |_|___/ .__/|_/_/\_\ Network |_| SPRL TVA: BE6836018011 T: +32 498 23 00 40 W: http://espix.net M: tho...@espix.net
Re: [pca] confirming the validiting of a home grown patch_order file
Thomas, So, from that point, I think that I can forget to remove patches being obsoleted by other PATCH_IDS (like if 11 was obsoleted by 22, we don't cause trouble by including both inside patchdiag.xref, right ? as PCA only got trouble when two patches with the same revision are present). Maybe you could just add required patches recursively in a first step, and then go over the file again and only keep one line per patch-ID - the one with the highest revision number. I think that should be fine for PCA, as it's the same style as used by the official patchdiag.xref. On another side, couldn't we add an option to PCA to allow obsoleted patches to be used ? I'd prefer not to do that :) It's hardly foreseeable whether this could cause problems in some obscure situations. With that change, PCA would accept that the xref file in itself doesn't have to be consistent, and not even I know the code good enough to anticipate what's gonna happen .. I think there's another viable solution: One could assume the only thing that happens when patch 11-01 is obsoleted by 22-02 is that its O flag is set and the synopsis is prefixed with Obsoleted by: 22-02 . So it should cause no harm if you simply remove these two things in the generated xref file. It seems to be a right thing to do - at the time when a patch required 11-01 for the first time, this of course wasn't obsolete yet. Again one could also argue that the most correct thing to do would be to follow the requirements/obsoletion chain until reaching a non-obsolete patch and to include that one (plus all the redirections, for PCA to know), even if this pulls in new dependencies. But then especially people with hand-tuned patch lists won't like that. *sigh* :) Martin.
Re: [pca] confirming the validiting of a home grown patch_order file
- populating the xref - Assume only one rev (the last used in dependencies) is present per patch - Removing any obsolete flag and Obsoleted by: text inside the synopsis. Correct? Yup, think so. I can also do it this way... I got all the info I need, I can even imagine to allow the user to choose which method is the best for him Yes, at the end having an option would probably be best. Like if you would apply the 10 Recommended patch cluster without downloading every single patch which is in it. You simply could generate xref from the list of patches it contains and then run pca against this xref... wouldn't that be a wonderful world ? The basic design of Sun's patching design using patchdiag.xref really isn't (or wasn't) all that bad. Besides just having one current master xref file, one can put it to good use which such custom xref files; Sun, with the access to all the patch metadata could've done wonderful things. Alone the fact that one can use a frozen copy of an xref file to put a certain patching milestone on any given machine even months later is a great thing, used by many. It's just sad that all this has an expiration date on it since Solaris 11 and IPS appeared. Martin.
Re: [pca] confirming the validiting of a home grown patch_order file
Thomas Gouverneur wrote: - I've fixed the header for PCA to admit the date parsing (i hope at least ;)) Nearly :) You should replace month numbers by their 3-letter-abbreviations in the date (01 - Jan, 02 - Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec). - I've also fixed the multiple-release present, it now take the biggest release of a patch present into every dependancy. Yes, the number of patches in the generated xref file has now been reduced. So, whenever there is a bad patch, should I look at the first upper revision which is not a bad patch ? is it safe to do that ? Yes, that's what I'd do. Any other remark ? I still see empty patch lines. E.g. in the xref file generated for a list with only patch 148301-01 on it, the resulting xref file contains: 125369|05|Jan/01/70| | | | 125547|01|Jan/01/70| | | | There's also: 123839|01|Jan/01/70| | | | which wouldn't have to be included anyway, as it is obsoleted by 126897-02, which is included due to some other dependency requirement. Martin.
Re: [pca] confirming the validiting of a home grown patch_order file
Don O'Malley wrote: Basically, as soon as you start to use patches in the form of xx-yy with PCA it will (and has to) assume that you take care of the dependencies and the ordering yourself. If you have a self-maintained list of patches, it's probably easiest to to try to install them on a test machine to get the correct ordering. Dumping all the patches in a single directory and using 'patchadd -M' may help... A recent idea for a service that Oracle could provide was to allow a customer to submit a list of patch-IDs and revisions, and to get a copy of patchdiag.xref which includes exactly these patches (plus required patches) in return. This patchdiag.xref file could then be fed into PCA via its xrefdir option, and it would allow the admin to verify any system against (and patch up to) this very patchset. This would not only be useful for such home-grown patch lists (which Oracle doesn't like anyway), but also for patching prerequisites enforced by some applications. E.g. Sun Studio, which always had a list of certain required and/or recommended patches to be installed to make it work flawlessly. It's a common FAQ as to how to verify such a list. If a patchdiag.xref with these patches would be provided, again checking and patching would be a breeze. Any spare time, Don? :) Martin.
Re: [pca] confirming the validiting of a home grown patch_order file
Martin, I've tried to make a PoC for all this... To generate a custom patchdiag.xref based on a patch list: - Register on wesunsolve.net - Login - Create a custom patch list (http://wesunsolve.net/add_clist) - Add some patch into it.. * visit a patch page, select the list in the drop down menu on the upper side of the page and click add... - get back to your panel (http://wesunsolve.net/panel) - Click on Generate patchdiag.xref - This should give you a patchdiag.xref customized with only the patch that you requested + recursives dependancies... I plan to allow the generation of theses patchdiag also for patch clusters and also ease the process (outside of user lists also, just copy/paste a list of patch and get the patchdiag associated...) Can someone provide me feedback about theses custom patchdiag.xref ? I didn't really tested the data that are exported there.. but I think they should be relevant... Kind Regards, -- Thomas Gouverneur T: +32 498 23 00 40 W: http://espix.net M: tho...@espix.net On Fri, 27 Jan 2012 09:40:15 +0100 Martin Paul mar...@par.univie.ac.at wrote: Don O'Malley wrote: Basically, as soon as you start to use patches in the form of xx-yy with PCA it will (and has to) assume that you take care of the dependencies and the ordering yourself. If you have a self-maintained list of patches, it's probably easiest to to try to install them on a test machine to get the correct ordering. Dumping all the patches in a single directory and using 'patchadd -M' may help... A recent idea for a service that Oracle could provide was to allow a customer to submit a list of patch-IDs and revisions, and to get a copy of patchdiag.xref which includes exactly these patches (plus required patches) in return. This patchdiag.xref file could then be fed into PCA via its xrefdir option, and it would allow the admin to verify any system against (and patch up to) this very patchset. This would not only be useful for such home-grown patch lists (which Oracle doesn't like anyway), but also for patching prerequisites enforced by some applications. E.g. Sun Studio, which always had a list of certain required and/or recommended patches to be installed to make it work flawlessly. It's a common FAQ as to how to verify such a list. If a patchdiag.xref with these patches would be provided, again checking and patching would be a breeze. Any spare time, Don? :) Martin.
Re: [pca] confirming the validiting of a home grown patch_order file
Thomas Gouverneur wrote: I've tried to make a PoC for all this... You're quick :) Can you please change the header in the generated xref file to match the one from the original, ie: ## PATCHDIAG TOOL CROSS-REFERENCE FILE AS OF Jan/26/12 ## PCA is quite picky with the syntax of the first line and won't accept the file if it doesn't match. You can put the FOR BUNDLE xxx part into another comment line (they are ignored by PCA). Even in a simple example with just one patch on the list, which pulls in a kernel patch, I once again realized how complicated all those patch dependencies have become, and how difficult it is to prove correctness. One thing I noticed is that the xref file contains lines like 119254|14|Jan/01/70| | | | . It seems as if the xref creator doesn't check whether a patch has already been included with a higher revision, and then adds these half-empty lines. When different patches require different revisions of some other patch, only one line with the newest required revision should be included. I also saw a bad patch (B) included in the xref file (120272-12). I guess the script should look for the patch which obsoleted it and include that one instead. The format of the lines themselves seems to be OK. Are you generating them from your patch database or are they taken from your archive of patchdiag.xref files? Guess that more people have to try that with real-world examples to see whether the output makes sense and delivers a patch set which can indeed be applied. Trying to analyze that with a handful of theoretical samples seems just too complicated and cumbersome. Martin.
Re: [pca] confirming the validiting of a home grown patch_order file
Gael Martinez wrote: What would be the fastest/cleanest way with pca to confirm/correct the right patching order for all patches placed in a flat file ? Assuming that the patches are specified in patchID + revision format (xx-yy), PCA can't help you much here. The problem is that PCA uses the information from patchdiag.xref to build the patch dependency tree, but the file only contains information about the most recent revision of each patch. patchadd knows about those dependencies because it uses the patchinfo file contained in the patch zip file. For PCA to do the same for a list of patches, it would have to download all patches first instead of relying on the xref file, which is kind of impractical. Basically, as soon as you start to use patches in the form of xx-yy with PCA it will (and has to) assume that you take care of the dependencies and the ordering yourself. If you have a self-maintained list of patches, it's probably easiest to to try to install them on a test machine to get the correct ordering. Martin.
[pca] confirming the validiting of a home grown patch_order file
Hello All What would be the fastest/cleanest way with pca to confirm/correct the right patching order for all patches placed in a flat file ? Regards -- Gaël Martinez
