Software Delivery job fails with error that package has been tampered with.

book

Article ID: 49972

calendar_today

Updated On:

Products

CA Automation Suite for Data Centers - Configuration Automation CA Client Automation - Asset Management CA Client Automation - IT Client Manager CA Client Automation CA Client Automation - Remote Control CA Client Automation - Asset Intelligence CA Client Automation - Desktop Migration Manager CA Client Automation - Patch Manager CA Server Automation

Issue/Introduction

Description:

Problem

  • Particular package fails consistently with following error:
  • "This package has consistency check enabled and has been tampered with at the server. [SDM228429]"
  • This happens regardless of the scalability server that the agent receiving the package reports to.
  • Restaging the package does not help.

Environment

  • CA Client Automation r12.5
  • CA IT Client Manager r12.5, r12.0 SP1, r12.0
  • CA Software Delivery r12.5, r12.0 SP1, r12.0

Cause

  • When a package is registered into ITCM, we create a checksum based on the number, names and size of the contained files. When a package is being deployed, the checksum is calculated again and compared with the number calculated during registration. If the two do not match, the "tampered with" error is generated. So it basically means that somebody/something changed the package after registration.

Solution:

  1. If you are sure this is not the case, you could disable this check:

    Go to the package properties on the ITCM Explorer and uncheck "Checksum control of package consistency". Click OK. Then deploy the software package again and the error will no longer show up.

    <Please see attached file for image>

    Figure 1

  2. If you do not like to disable checksum control, consider the following:

    If you have NOS agents, they install directly from the share (rather than first copy the package to the local hard drive) and with a symbolic link/junction point to the actual source (being only a pointer rather than a complete copy of the installation package), the installation procedure could change the source of the package.

    You can disable symbolic links to overcome this problem: when a job container is built, the package is copied to the scalability server's activate area which the target connects to. Since the installation process now no longer runs on the actual package, but on a copy of it, there is no chance the procedure is able to modify it in any way.

    You can disable the feature from configuration policy:

    DSM > Software Delivery > Shared > Software Library access: Use symbolic links -> false (default is true).

    <Please see attached file for image>

    Figure 2

    The only downside of this is that building the container will take slightly longer as the package will need to be copied over to the activate area rather than just setting a pointer.

Environment

Release: UASIT.99000-12.5-Asset Intelligence
Component:

Attachments

1558709985526000049972_sktwi1f5rjvs16ro9.gif get_app
1558709983523000049972_sktwi1f5rjvs16ro8.gif get_app