Difference between revisions of "Patching Instructions"
(→Conflict Resolution) |
|||
| Line 1: | Line 1: | ||
| + | ===Patching Instructions=== | ||
This will be filled in over time... | This will be filled in over time... | ||
Revision as of 22:18, 1 July 2006
Contents
Patching Instructions
This will be filled in over time...
Example name: XWB-1p1_SEQ-10_PAT-11.kid
XWB is package name
SEQ-10 means this is the 10th sequence number
Patch-11 means this is patch number 11
Because multiple teams may be working on a project, occasionally patch 4 might come out before patch 3. Thus the sequence numbers were introduced, to ensure proper ordering.
To make a long story short, install the KID patches in numerical SEQUENCE NUMBER ordering.
I think the KIDS menu option is under EVE->Programm->KID
Patches have to be first loaded, then applied Always read the .TXT file that accompanies a patch (.kid). This will tell the special conditions that should be met before applying a patch.
Rick's Talk
These are things that can be included in a KIDS package
Package elements: Primary
- Package (?)
- Build (file 9.6)
- Data Dictionary (0)
- Data (file 1)
- Routine (*)
- Routine (file 9.8) entries <--- possible conflicts with local stuff.
- Option (file 19)
- Protocol (file 101)
- Remote Procedure (file 8994)
Package Elements: Secondary
- Function (.5) -- fileman functions
- Dialog (.84) -- i.e. internationalization text
- Parameter (8989.5) -- i.e. adjustable parameters for CPRS etc.
- Parameter Definition (8989.51)
Below are not included in KIDS, but instructions might specify for user to edit them.
- Device
- Domain
- bulletin
- Mail Group
- Help Frame
- Security Key
- New Person
Package Elements: Templates Print Template sort Template Input Template Form Block Foreign Format ...
Non-KIDS stuff -- not included in KIDS Manuals Script Configuration File Non-MUMPS programs
Instructions will tell you to go get separate programs.
Update Ingredients
- Package File (9.4)
- Package Elements
- Build File -- defines which things are to be transported, but doesn't contain actual data
- Install file -- tracks which patches have been installed.
- Transport global -- temporary storage place to see how it will affect system before actually applying changes. So, when you "load" a patch, it has not been applied yet. You can change your mind before commiting to use of it.
- Distribution file or message -- mail message is the primary format (esp in the VA). But there are some things it does not handle. Outside the VA firewall, they use a file format.
- Patches -- Patches contain a distribution of a build. User uses patches.
Lifecycle
- Productions Sites
- problems or opportunities arise
- Support Hub (Forum and OpenForum)
- national Online Information Sharing (NOIS) - can see if someone else has faced problem
- Development Sites
- Kernel Installations & Distribution Systems (KIDS)
- Forum and OpenForum
- If a fix is found, Patch Module is released
- it has a subscription list of people that want the patch.
- Test and Verification Sites
- VistA online (FTP site) & Vista documentation Library
- Production Sites (Test & Live Environments)
- first apply them to the test environment, then apply to Live
Software Stream
- Occasional Package Releases (i.e. 4/yr)
- Frequent Patches (about 10/wk)
- Most patches only depend on other patches from within their own package
- Some depend on those from other packages
- A few are compound patches, combining patches from differenct packages
- these are not sent as emails (can only be as files so far)
- This is a partially ordered set, and must be installed as such
Most of the time, it does not matter which order. But sometimes it does matter. The documentation will show this.
How to Patch in Order
- Each patch lists its dependencies, and includes a sequence number (by package)
- Put them in in **sequence number**, not by the number found in the name. - the number in the name is the order in which patches were *started*, but still, apply them in the sequence number (the order that they were released in)
- Keeping up is the easies approach--just install whatever is new each week.
- it gets harder when you get further behind
- Running reports on the install file can tell you what you are missing
- You should create and maintain one or more spreadsheets to track your patching.
- "The spreadsheat is your friend", so one can see where one is in the patching process.
- Checking Routine Patch Lists
- occasionally (rarely) the patching process gets messed up by the user, and you might get a half patch. You can look at the second line on a routine and see the patch history.
A Sample Patch
- Identification
-Name -Sequence Number
- Description
-Dependency -Explanations -Checksums Important. Apply to the routines only. Helps to ensure file not corrupted. You can compare the "pre" number from the patch to YOUR "pre" number. That will help you tell if you have modified the file on your system, or if yours is the same as the KIDS creater had.
- KIDS Distribution
- a bunch of nodes and values that contain the changes to the system.
Reports for the Install File
- Sorting by Package
- Sorting by Install completion date
- Sorting by Sequence Number
- demo
Spreadsheet Issues
List out the patches applied Good to record which batch a patch was applied. If you mess up on one patch, the others that you did at the same time (the patch) might also be messed up. Use the spreadsheet for planning which patches to apply, in which order.
Pearl:
Turn on logging (to disk) in Putty so you can see what you did. Or on linux, use a utility called "script"
Patch Batch Checklist
- Record you current patching status
- Acquire All Missing Patches
- add the distribution files to your directoreis - add the patches to the spreadhseet ... this will check the checksums do CHECK^XTSUMBLD <-- there is an option for this one do CHECK1^XTSUMBLD
Individual Patch Checklist
- Acuqire patch and all distribution files
- Install predecessor (usualy) & dependants
- check for non-forward-compality conflicts
- study patch (features & package elements)
- Load, check, print, compare, backup
- manually backu non-routine elements if conlict
- Install, including any manual post-install
- Manually resolve conflicts, if any.
Conflict Resolution
- conflict resolution is programming
- It involves four copies of a routine:
- class III before (which you wrote)
- Class I Before (which you overwrote)
- Class I After (introducted by the patch)
- Class III After (which you must now write -- including your modifications)
- Comment extensively
- who, when, why, before, after, change history - put this on the patch list on the second line
