Difference between revisions of "Patching Instructions"

Latest revision as of 21:05, 10 October 2012

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.

The KIDS menu option is under EVE->Programming->KIDS

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 At WorldVistA 7/1/06

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

Kevin Toppenberg's extra notes:

Missing Patches

The source of patches is on the ftp server: ftp.va.gov However, there seem to be patches missing for various reasons. I am going to document these here.

• KIDS file for LEX*2.0*29
• CTD_MS_1_0.KID
• NDF4P98.KID needed for patch PSN*4*98 SEQ #93 (seems to be copyrighted patient handout information)