Handling the ndtrack Binary

IT Asset Management (Cloud)

The purpose of imgtrack, given a target image, is to create a derived image, temporarily run a container from it, and deliver to it the inventory component (ndtrack) of the standard FlexNet Inventory Scanner.

Choosing the ndtrack binary

The imgtrack tool needs access to a copy of ndtrack appropriate to the particular Linux platform. Like the FlexNet Inventory Scanner (ndtrack.sh) for Linux platforms, imgtrack includes (concatenated on the end of the script) a tarball of various versions of ndtrack to extract and run on the relevant Linux platform(s). It determines the platform using the uname utility, and installs and runs the appropriate edition of ndtrack for the platform. It is normal, and best practice, to simply allow imgtrack to extract the appropriate edition of ndtrack from its embedded tarball. However, where this does not suit your corporate strategies, there are two alternatives:

• You can instruct imgtrack to use a pre-installed copy of ndtrack.sh (this may have been installed through adoption or through third-party deployment). For success, this must be a standard installation, where the tracker is located in /opt/managesoft/libexec/support. To look here for the tracker, and if found run that version instead of choosing one from the attached tarball, use the --local-ndtrack option when invoking imgtrack.
• Otherwise, you can direct imgtrack to use a copy of the FlexNet Inventory Scanner (ndtrack.sh) saved in a custom location, using the --from-ndtrack option. (If both these options are specified, this --from-ndtrack option takes precedence.)

Compatibility is only guaranteed between imgtrack and the versions of ndtrack embedded within its own tarball. If you choose either of the above options, it is your responsibility to ensure both the compatibility and the integrity of your copy of ndtrack.sh.

Providing the appropriate libc

The ndtrack binary is implemented in the C/C++ code family, and requires the standard runtime and libraries to execute. However, the target container image may be constructed without a C language runtime, standard system libraries, or typical system tools, directory layouts, or configurations; or it may contain an incompatible library. When imgtrack creates a derived image, any C library included in the source image is, of course, also included in the derived image.

To determine what C library (if any) is included in the target (source) image, imgtrack briefly instantiates a container from the source image.

Tip: Under no circumstances does imgtrack run any of the software within this temporary container. It invokes the command

ldd --version 2>&1

to capture output that includes the specific implementation of the C library (if any). Immediately afterwards, the container is deleted.

If the command fails, or if the output from the command does not contain the information to identify the C library implementation, imgtrack exits with an error, as the image is unsupported.

You can bypass the process for detecting the standard C library implementation in the source image by directly specifying the implementation to use with the ‑‑libc-variant option, which must identify one of the supported implementations:

• glibc – the standard GNU implementation
• muslc – the standard in the Alpine Linux distribution.

Example:

imgtrack example:latest --libc-variant glibc