Hello, friendly Habicats!
We are excited to announce the release of 19 Habitat Packages to a secure minor version.
Let’s go over what this means for us and, more important, what it means for you.
Habitat Plans 101
Currently, there are about 700 Habitat plans under the Core Origin on Builder.
These include everything from services like Postgresql to binaries like Go to very low-level system libraries like GCC, all of which you can easily pull into your Habitat artefacts.
What’s a Habitat Plan
Artefacts are cryptographically-signed tarballs uploaded, downloaded, unpacked, and installed in Chef Habitat. They are built from shell scripts known as plans, but may also include application lifecycle hooks and service configuration files that describe the behavior and configuration of a running service.
At the centre of Chef Habitat packaging is the plan. This is a directory comprised of shell scripts and optional configuration files that define how you download, configure, make, install, and manage the lifecycle of the software in the artifact
The Base Plans are a group of plans (mostly low level systems libraries) that:
· are used by nearly every other plan (or a dependency of that plan) on Builder
· are used to build Habitat itself
· need to be built in a certain order.
You can see the full list of Base Plans here 4 .
You can see the full list of Core plans here 1 .
Any time one of these plans is updated (especially ones that are nearly universally used, like glibc and GCC, all other plans which depend on it need to be built in a certain order, and then all plans that depend (or depend on a plan that depends) on those plans also need to be rebuilt.
Why are you refreshing them?
We perform periodic habitat package (Core Plans/Base Plans) refreshes to ensure that your applications built on Habitat are secure and performant. Many packages including GCC, OpenSSL, zlib, and glibc form the base cryptographic and security libraries that applications depend on.
We also perform periodic plan refreshes to make it easy for users of Habitat to receive the latest performance improvements, security patches, and bug fixes from the underlying software libraries that power your application. Our periodic plan refresh means you will receive these updates automatically, and you will never worry about your application being tied to an aging Operating System version.
This habitat package refresh upgrades the list of 45 packages listed below.
|Package Name | Package Version|
|--- | ---|
|buildkite-cli | 0.5.0|
|cabal-install | 3.0.0.0|
|cmake | 3.21.4|
|composer | 2.1.12|
|cpanminus | 1.9019|
|curl | 8.7.1|
|dd-agent | 5.32.8|
|dotnet-asp-core | 3.1.21|
|dotnet-core | 3.1.22|
|dotnet-core-sdk | 3.1.416|
|envoy | 1.20.1|
|etcd | 3.5.1|
|git | 2.33.1|
|github_changelog_generator | 18.12.0|
|gocd-server | 2023-11-01T01-57-10Z|
|grafana | 17.5.11|
|img | 0.5.11|
|jenkins | 2.319.1
|lastpass-cli | 1.3.3|
|netdata | 1.32.0|
|pango | 1.41.1|
|percona-xtrabackup | 2.4.24|
|phantomjs | 2.1.1|
|php | 7.4.26|
|prometheus-cpp | 0.13.0|
|qemu | 2.12.1|
|rethinkdb | 2.4.1|
|scaffolding-go | 0.2.0|
|scaffolding-go17 | 0.1.0|
|scaffolding-node | 0.6.14|
|sensu-agent | 2.0.0-beta.2-4|
|sensu-backend | 2.0.0-beta.2-4|
|shield-agent | 0.10.9|
|sqitch | 0.9999|
|sqitch_pg | 3.15.0|
|tlog | 12|
|wordpress | 4.9.18|
|chef-infra-client | 18.5.0|
|chef-infra-client | 17.10.163|
|chef-infra-client | 18.4.12|
|inspec | 4.56.61|
|inspec | 5.22.55|
|inspec | 5.22.58|
|scaffolding-chef-inspec | 0.25.5|
|scaffolding-chef-infra | 0.25.5|
|Package Name | Package Version|
Plans and You
So far we’ve discussed how and why we are refreshing the Habitat Packages, but what does that mean for the plans in your own origin?
How does this affect me?
Chances are, any plan within your origin depends on at least one of the Habitat Packages ( Base Plans /Core Plans) somewhere in its chain of dependencies. When that plan is updated, your plan also must be rebuilt. This sounds simple, but if you have plans in your origin that depend on other plans – and those plans depend on a Base Plan (let’s say glibc), all of them must be built with the same version of glibc. Let’s look at this visually.
Dependencies
Let’s say I have a plan under my origin (nellshamrell) called widget_world – let’s say it lives at
nellshamrell/widget_world on Builder.
nellshamrell/widget_world
Now, let’s say that plan depends on two more plans, nellshamrell/widget and nellshamrell/world (yes, it’s contrived, just go with it for now).
nellshamrell/widget_world
-> nellshamrell/widget
-> nellshamrell/world
And let’s say each of those plans depends on core/glibc for some reason:
nellshamrell/widget_world
-> nellshamrell/widget
--> core/glibc
-> nellshamrell/world
--> core/glibc
And let’s say both are using the current core/glibc plan, which means they are both using version 2.33:
nellshamrell/widget_world
-> nellshamrell/widget
--> core/glibc/2.33
-> nellshamrell/world
--> core/glibc/2.33
My nellshamrell/widget_world plan will build fine, because both of its dependencies are built with the same version of glibc.
(studio) $ build widget_world
...
Success!
I love when a plan.sh comes together!
Then suppose the Habitat team upgrades core/glibc to 2.34. And let’s say for some reason you only update one of the dependencies to use the updated glibc – so nellshamrell/widget will depend on core/glibc/2.34, while nellshamrell/world will still depend on core/glibc/2.33:
nellshamrell/widget_world
-> nellshamrell/widget
--> core/glibc/2.34
-> nellshamrell/world
--> core/glibc/2.33
This time, if I attempt to build nellshamrell/widget_world, it will return a very ugly error that looks similar to this:
(studio) $ build widget_world
(...)
widget_world: WARN
widget_world: WARN The following runtime dependencies have more than one version
widget_world: WARN release in the full dependency chain:
widget_world: WARN
widget_world: WARN * core/glibc ( core/glibc/2.33/ core/glibc/2.34/ )
widget_world: WARN
widget_world: WARN The current situation usually arises when a plan has a direct
widget_world: WARN dependency on one version of a package (acme/A/7.0/20160101200001)
widget_world: WARN and has a direct dependency on another package which itself depends
widget_world: WARN on another version of the same package (acme/A/2.0/20151201060001).
widget_world: WARN If this package (acme/A) contains shared libraries which are
widget_world: WARN loaded at runtime by the current plan, then both versions of
widget_world: WARN acme/A could be loaded into the same process in a potentially
widget_world: WARN surprising order. Worse, if both versions of acme/A are
widget_world: WARN ABI-incompatible, runtime segmentation faults are more than likely.
widget_world: WARN
widget_world: WARN In order to preserve reliability at runtime the duplicate dependency
widget_world: WARN entries will need to be resolved before this plan can be built.
widget_world: WARN Below is an expanded graph of all $pkg_deps and their dependencies
widget_world: WARN with the problematic lines noted.
widget_world: WARN
widget_world: WARN Computed dependency graph (Lines with '*' denote a problematic entry):
nellshamrell/widget_world/1.0.0/
nellshamrell/widget/1.0.0/ ( *)*
*core/glibc/2.34/ (* )
nellshamrell/world/1.0.0/ ( *)*
*core/glibc/2.33/ (* )
ERROR: Computed runtime dependency check failed, aborting
This error occurs because nellshamrell/widget_world has one dependency that was built with 2.34, and another that was built with 2.33. This makes them incompatible, and the nellshamrell/widget_world plan will not build.
How do I resolve this?
In this case, you can resolve this error by rebuilding nellshamrell/world with core/glibc version 2.34. If we do that, and now both dependencies depend on the same version of glibc, then nellshamrell/widget_world will build fine:
nellshamrell/widget_world
-> nellshamrell/widget
--> core/glibc/2.34
-> nellshamrell/world
--> core/glibc/2.34
Success!
Plans and You
So far we’ve discussed how and why we are refreshing the Habitat Packages, but what does that mean for the plans in your own origin?
How does this affect me?
Chances are, any plan within your origin depends on at least one of the Habitat Packages ( Base Plans /Core Plans) somewhere in its chain of dependencies. When that plan is updated, your plan also must be rebuilt. This sounds simple, but if you have plans in your origin that depend on other plans – and those plans depend on a Base Plan (let’s say glibc), all of them must be built with the same version of glibc. Let’s look at this visually.
Dependencies
Let’s say I have a plan under my origin (nellshamrell) called widget_world – let’s say it lives at
nellshamrell/widget_world on Builder.
nellshamrell/widget_world
Now, let’s say that plan depends on two more plans, nellshamrell/widget and nellshamrell/world (yes, it’s contrived, just go with it for now).
nellshamrell/widget_world
-> nellshamrell/widget
-> nellshamrell/world
And let’s say each of those plans depends on core/glibc for some reason:
nellshamrell/widget_world
-> nellshamrell/widget
--> core/glibc
-> nellshamrell/world
--> core/glibc
And let’s say both are using the current core/glibc plan, which means they are both using version 2.33:
nellshamrell/widget_world
-> nellshamrell/widget
--> core/glibc/2.33
-> nellshamrell/world
--> core/glibc/2.33
My nellshamrell/widget_world plan will build fine, because both of its dependencies are built with the same version of glibc.
(studio) $ build widget_world
...
Success!
I love when a plan.sh comes together!
Then suppose the Habitat team upgrades core/glibc to 2.34. And let’s say for some reason you only update one of the dependencies to use the updated glibc – so nellshamrell/widget will depend on core/glibc/2.34, while nellshamrell/world will still depend on core/glibc/2.33:
nellshamrell/widget_world
-> nellshamrell/widget
--> core/glibc/2.34
-> nellshamrell/world
--> core/glibc/2.33
This time, if I attempt to build nellshamrell/widget_world, it will return a very ugly error that looks similar to this:
(studio) $ build widget_world
(...)
widget_world: WARN
widget_world: WARN The following runtime dependencies have more than one version
widget_world: WARN release in the full dependency chain:
widget_world: WARN
widget_world: WARN * core/glibc ( core/glibc/2.33/ core/glibc/2.34/ )
widget_world: WARN
widget_world: WARN The current situation usually arises when a plan has a direct
widget_world: WARN dependency on one version of a package (acme/A/7.0/20160101200001)
widget_world: WARN and has a direct dependency on another package which itself depends
widget_world: WARN on another version of the same package (acme/A/2.0/20151201060001).
widget_world: WARN If this package (acme/A) contains shared libraries which are
widget_world: WARN loaded at runtime by the current plan, then both versions of
widget_world: WARN acme/A could be loaded into the same process in a potentially
widget_world: WARN surprising order. Worse, if both versions of acme/A are
widget_world: WARN ABI-incompatible, runtime segmentation faults are more than likely.
widget_world: WARN
widget_world: WARN In order to preserve reliability at runtime the duplicate dependency
widget_world: WARN entries will need to be resolved before this plan can be built.
widget_world: WARN Below is an expanded graph of all $pkg_deps and their dependencies
widget_world: WARN with the problematic lines noted.
widget_world: WARN
widget_world: WARN Computed dependency graph (Lines with '*' denote a problematic entry):
nellshamrell/widget_world/1.0.0/
nellshamrell/widget/1.0.0/ ( *)*
*core/glibc/2.34/ (* )
nellshamrell/world/1.0.0/ ( *)*
*core/glibc/2.33/ (* )
ERROR: Computed runtime dependency check failed, aborting
This error occurs because nellshamrell/widget_world has one dependency that was built with 2.34, and another that was built with 2.33. This makes them incompatible, and the nellshamrell/widget_world plan will not build.
How do I resolve this?
In this case, you can resolve this error by rebuilding nellshamrell/world with core/glibc version 2.34. If we do that, and now both dependencies depend on the same version of glibc, then nellshamrell/widget_world will build fine:
nellshamrell/widget_world
-> nellshamrell/widget
--> core/glibc/2.34
-> nellshamrell/world
--> core/glibc/2.34
Success!