The vulnerability has been withdrawn but it may be a while until
it is removed from the DB used by scanning. Suppressing this
removes the false result in scanning processes. The change should
be reverted once the DB is updated.
In #24526 we updated the Consul and Vault fingerprints so that they are no
longer periodic. This fixed a problem that cluster admins reported where rolling
updates of Vault or Consul would cause a thundering herd of fingerprint updates
across the whole cluster.
But if Consul/Vault is not available during the initial fingerprint, it will
never get fingerprinted again. This is challenging for cluster updates and black
starts because the implicit service startup ordering may require
reloads. Instead, have the fingerprinter run periodically but mark that it has
made its first successful fingerprint of all Consul/Vault clusters. At that
point, we can skip further periodic updates. The `Reload` method will reset the
mark and allow the subsequent fingerprint to run normally.
Fixes: https://github.com/hashicorp/nomad/issues/25097
Ref: https://github.com/hashicorp/nomad/pull/24526
Ref: https://github.com/hashicorp/nomad/issues/24049
Resolve scan job runner
Resolve linting alerts
adding EOF on files
adding EOF on gitignore too
add hclfmt and bump action versions
update scan.hcl comments
Co-authored-by: Tim Gross <tgross@hashicorp.com>
fix typo
move scan.hcl file and paths-ignore for scans
change action runner
use org secret to checkout
typo
change runner
use hashicorp/setup-golang@v3
Co-authored-by: Tim Gross <tgross@hashicorp.com>
pin the github action sha
In #23720 we removed the 1.7.x and 1.6.x release branches from the "active"
versions for backports. But we forgot that we needed these backports to remain
active for documentation backports because of versioned docs.
As of Nomad 1.8.0 LTS we're no longer backporting changes to Nomad CE versions
1.7.x and 1.6.x. We never got around to removing the flags in the file the
backport assistant uses to control automated backports.
The default root:root is used as this provides permissions to run
both server and client agents. The comment details what changes
can be made to operators if needed.
When running the service file prior to this change, root:root
would be the default.
Configuration changes to use backport assistant with LTS support. These include:
* adding a manifest file for active releases
* adding configuration to send backport to ENT repo
Nomad agents expect to receive `SIGHUP` to reload their configuration. The
signal handler for this is installed fairly late in agent startup, after the
client or server components are up and running. This means that configuration
management tools can potentially reload the configuration before the agent can
handle it, causing the agent to crash.
We don't want to allow configuration reload during client or server component
startup, because it would significantly complicate initialization. Instead,
we'll implement the systemd notify protocol. This causes systemd to block
sending configuration reload signals until the agent is actually ready. Users
can still bypass this by sending signals directly.
Note that there are several Go libraries that implement the sdnotify protocol,
but most are part of much larger projects which would create a lot of dependabot
burden. The bits of the protocol we need are extremely simple to implement in a
just a couple of functions.
For non-Linux or non-systemd Linux systems, this feature is a no-op. In future
work we could potentially implement service notification for Windows as well.
Fixes: https://github.com/hashicorp/nomad/issues/3885
In #13374 we updated the commented-out `license_path` in the packaged example
configuration file to match the existing documentation. Although this config
value was commented-out, it was reported that changing the value was
confusing. Update the commented-out line to the previous value and update the
documented examples to match that. This matches most of the examples for
Consul/Vault licensing as well. I've double-checked the tutorials and it looks
like it'd been left on the previous value there, so no additional work to be
done.
### Description
Pattern matching was [recently added](https://github.com/hashicorp/crt-orchestrator/pull/51) so that teams no longer have to explicitly list every branch that should trigger the CRT pipeline. This simplifies release preparation- anytime a new release branch is created, it will produce releasable artifacts and exercise the full pipeline.
### Testing & Reproduction steps
This has been tested in multiple projects since being rolled out. There are no nomad-specific tests that need to be done.
### Links
PR where this functionality was added: https://github.com/hashicorp/crt-orchestrator/pull/51
### PR Checklist
* [ ] updated test coverage
* [ ] external facing docs updated
* [X] not a security concern
During the release there are several files that need to be modified:
- .release/ci.hcl: the notification channel needs to be updated to a
channel with greater team visibility during the release.
- version/version.go: the Version and VersionPrerelease variables
need to be set so they match the release version.
After the release these files need to be reverted.
For GA releases the following additional changes also need to happen:
- version/version.go: the Version variable needs to be bumped to the
next version number.
- GNUMakefile: the LAST_RELEASE variable needs to be set to the
version that was just released.
Since the release process will commit file changes to the branch being
used for the release, it should _never_ run on main, so the first step
is now to protect against that.
It also adds a validation to make the user input version is correct.
After looking at the different release options and steps I noticed that
automatic CHANGELOG generation is actually the exception, so it would be
better to have the default to be false.
