* Add generic read/update/delete commands
This adds three generic commands that use the resource prefix to
determine the subcommand to run and pass through args over to that
subcommand. Since this occurs very early on and to avoid loading
essentially every internal resource package, I moved subtype definitions
to globals.
This replaces #3967
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
* De-duplicate Subtype code (#4031)
Co-authored-by: Timothy Messier <tim.messier@gmail.com>
---------
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Co-authored-by: Timothy Messier <tim.messier@gmail.com>
* Add generic read/update/delete commands
This adds three generic commands that use the resource prefix to
determine the subcommand to run and pass through args over to that
subcommand. Since this occurs very early on and to avoid loading
essentially every internal resource package, I moved subtype definitions
to globals.
* Update main.go
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
* Update changelog and remove another deprecated command
---------
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
* fix: monitorUpstreamConnectionState CPU consumption
`monitorUpstreamConnectionState()` is a goroutine that listens for GRPC client connection changes using GRPC's `WaitForStateChange` method. `monitorUpstreamConnectionState()` was consuming the a lot of CPU. It was continuously running and not actually waiting for state changes. The `state` for `monitorUpstreamConnectionState()` was not getting correctly updated which caused the loop to continuously run instead of waiting for new state changes.
Update GRPC `WaitForStateChange` method to use the same `state` that gets updated.
When the boundary client establishes a connection to the websocket used
to communicate with a worker, it was configured with a max websocket
message size of 32KiB. This was the default behavior for v1.8.7 of
nhooyr/websocket. However, there are cases where the worker can send
messages to the client that are larger than 32KiB. When this happens the
client returns an error and terminates the connection.
Notably this seems to only currently impact sessions made to SSH
Targets, although it could theoretically impact any target type
depending on the details of how the worker performs the writing of the
messages. The issue can be reproduced by attempting to scp a large
enough file from an SSH Target to the client. In this case the
connection gets terminated and results in a partial transfer of the
file.
This message size limit appears to be unnecessary, and the default
behavior is changing in v1.8.8 of nhooyr/websocket to make the message
size unlimited. Since this version is not yet released, this commit
switches the dependency to a fork with a version that is v1.8.7 plus the
patch to disable the limit. Once v1.8.8 is release this dependency can
be set back.
See:
https://github.com/nhooyr/websocket/pull/254https://github.com/nhooyr/websocket/pull/256
With a suitably slow system -- say, if you're waiting on a Windows
Terminal to output text inside a virtual machine -- the expected order
of things can be thrown off. One specific way this can happen is that
the worker can attempt to dial and have its dial fail because of the
slowness causing the dial context to time out. If, because of the
slowness, we also haven't released the log gate yet, then the event with
the failure information will be queued, along with the context that was
used.
Unfortunately, in some of these error cases, the context that was used
was the dial context instead of the system base context. In many other
places in the function it was the system base context so this is just a
mismatch, probably from code written at different times.
Normally this wouldn't be a problem as we'd fall back to the underlying
logger, but when we release the log gate, things happen differently:
it's a synchronous function and on error it causes us to abandon
system startup entirely.
This commit fixes the issue with using the incorrect context. It's an
open question whether we should change the behavior around errors when
replaying queued events, falling back to the underlying logger instead
of erroring.
* chore: Fix comment typo
* test(e2e): Update to use new credential library type
* test(e2e): Update to use new field name
* test(bats): Remove tests that use deprecated subcommand
* chore: Update to 0.14.0
* test(credentiallibraries): Update to use new credential library type
* doc: Add deprecation notices for 0.14.0
* fixup! doc: Add deprecation notices for 0.14.0
* feat (auth/ldap): add Repo support for max page size and deref aliases (#3670)
* chore: update cap/ldap dependency
This latest version of cap/ldap adds support for MaxPageSize and
DerefAliases
* feat (auth/ldap): add MaxPageSize and DerefAliases to storage proto
* feat (api/authmethods): add new ldap fields.
Add support for maximum_page_size and dereference_aliases
* feat (auth/ldap): schema changes to support new LDAP attributes
* feat (auth/ldap): add Repo support for max page size and deref aliases
* feat (handlers/ldap): add support for new fields (#3674)
Added API support for new ldap fields: MaximumPageSize and
DereferenceAliases
* chore: add CHANGELOG entry for new api auth ldap fields
This allows specifying multiple IDs in grants via an `ids` field, which
will eventually become the normal way to specify IDs. Internally, each
grant with multiple IDs turns into multiple ACL grants each with a
single ID; to make this distinction clearer and allow for better
separation of concerns an AclGrant type has been introduced, so really
multiple IDs in a Grant turn into multiple AclGrants.
The nice thing about doing it this way is that it becomes purely a
parsing concern; no actual validation logic has changed.
For backwards compatibility with grants already stored in roles, we do
not error out if `id` is specified. However, eventually we will simply
not support grants with `id` coming via the API; they will fail API
validation, such that new grants will require the use of the updated
`ids` field.
A follow-on PR will plumb this through the service handlers/API/CLI, but
I decided to do it in separate chunks to make reviewing easier, given
that they are easily separable into the internal and external aspects of
the change.
* Add CLI/API checks around using ID in grants (#3264)
* Plumb through some contexts to remove a lot of deprecated errors (#3268)
As part of the performance improvements for listing sessions for v0.9.0,
the view used to retrieve sessions for listing was updated to no longer
include a join on session_connection. However, a later migration that
was adding additional columns to this view inadvertently re-added the
join and session_connection columns. This resulted in requests to list
sessions performing this join, and returning additional rows for each
connection in a session. The application would ignore this additional
data, since it is no longer returned via the API. This would be
particularly impactful in cases where there are a large number of
connections per session, as this would greatly increase the amount of
data returned by the database.
This fix removes the session_connection join from this view, which
should restore the original performance improvements even in cases where
there is a large number of session connections per session.
See: https://github.com/hashicorp/boundary/pull/2160
Ref: 32070678dc
Fixes: 1e3c941be1
The hcp monthly billing views build a range of buckets using the
`generate_series` and the `now()` functions along with relative offsets
like `+ 1 month`. The calculated start and end times for these views can
vary depending on the time zone setting of the PostgreSQL server.
This adds 3 table functions that call their respective views with the
time zone set to UTC. Calling these functions instead of their
underlying views directly prevents the returned values from varying when
the server's time zone is not set to UTC.
This also drops support for PostgreSQL 11. The included tests use the
`date_trunc(field, source [, time_zone ])` function added in PostgreSQL
12.
Fixes: 41b1b5b4b7
This option did not respect whether or not versioning was enabled when
writing it out during generation.
This does mean that there is a breaking change for auth tokens, but as
it was a no-op anyways it's easy to fix and not something I want to /v2
about.
Do not allow PKI-KMS workers to have names updated via API
This would cause their public IDs to change, which we do not want.
Descriptions are also disallowed, since those come from the config file.
This also adds logic to allow upgrading from old KMS method to new, with
a test.
Co-authored-by: Irena Rindos <irenarindos@users.noreply.github.com>
Elim Tsiagbey
Jim
Hugo
irenarindos
Devon Anderson
Michael Li
daniandDanielle Miu
Sepehr
Louis Ruch
Irena Rindos
Michael Gaffney
Cameron Perera