If callers want errors to create events, they can do so
by wrapping the error. Sometimes we don't want db
errors to be events, and before this there was no way
to supress them.
Fixes the comments on functions wt_add_seconds, wt_add_seconds_to_now,
wt_sub_seconds, and wt_sub_seconds_from_now which were the tragic
victims of a copypasta error.
The schema changes introduced in 0.10.2 introduced a bug where an org
could not be deleted if there was a session for an org scoped user. It
would result in an error like:
scope.(Service).deleteFromRepo: unable to delete scope: \
iam.(Repository).DeleteScope: failed for o_VkNy46KwfS: \
iam.(Repository).delete: db.DoTx: iam.(Repository).delete: \
db.Delete: insert or update on table "session" violates foreign key constraint "target_fkey": integrity violation: error #1003
A worker around would be to first delete all projects in the org, then
finally delete the org.
This fix adds a regression test to the sqltests and updates several
constraints on the session table to be deferrable. Since the org delete
is a single transaction, this allows all of the necessary resources to
be deleted before attempting to enforce these constrains.
See: https://www.postgresql.org/docs/current/sql-set-constraints.html
Blame: 3a28ab614
If the database url is updated on Boundary's config and then a SIGHUP
triggered, we now connect to the new database, ensure it's OK to use
and use that one going forwards instead.
This allows a controller to be deployed in a more dynamic infrastructure
where, for example, database credentials could change, without having
to restart the controller. In this case only a database url config
change and a SIGHUP signal to all controllers would be required.
This uses an atomic.Pointer to store wrapped DB objects. This allows
atomically swapping to the new object. A timeout is introduced so that
if the object is swapped after the existing one has been looked up it
isn't immediately invalidated. The timeout is a maximum; a ticker once a
second that looks at stats to determine how many database connections
are still in use and then closes the driver as soon as none are in use.
This could be done with mutexes to avoid checking stats in a loop, but
that carries its own risk: if a write lock is attempted to be acquired
while a query is holding a read lock, the write lock will block, and any
subsequent read locks will also block since write locks take priority.
As a result, if a query is long-running or timing out, all other queries
in the system will become blocked. Our default user request timeout is
90 seconds and some jobs have no timeout at all, so this is not a purely
theoretical concern, even if it's unlikely.
Refs: #2435
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
This commit introduces closing the Schema Manager's underlying driver
connection. We were only releasing the shared lock but not actually
cleaning up the db connection and relied on the fact that the process
would exit to do that for us.
* feat(workers): Add ability to read and reinitialize cert authority (#2312)
* feat(workers): Return Release Version on worker list and read (#2377)
* feat(cli): Read and reinitialize worker certificate authority (#2387)
The session repository can now be passed an optional set of permissions.
The permissions are used to restrict results from the repository.
Currently this only impacts the List method. This enabled the sessions
service to use a single query to retrieve sessions and replaces the
previous behavior where the session service would first request all
sessions for a given set of scopes, evaluate the permissions, and then
request sessions based on a set of session ids.
* bug(vault): Correctly handle credential stores with expired tokens
Boundary makes use of a database view to perform CRUD operations on
Vault credential stores and libraries. This view did not include
credential stores with tokens that have expired in Vault, causing
errors when attempting to perform any action against them.
This adds an action to the API that allows pulling out an activation
token that can be given to a worker in its config (directly or via env
or file). The worker can pass this along with its normal request in
place of its normal nonce and the server will automatically accept it.
Co-authored-by: Irena Rindos <irenarindos@users.noreply.github.com>
* feat(sql): Fork pgtap to support arm64
This forks pgtap-docker and builds the image locally,
and updates our references to use our forked image.
* fixup! feat(sql): Fork pgtap to support arm64
This adds the ability to define hooks that will run prior to a schema
migration. The hooks should only be used when a migration would fail due
to data being in an invalid state, likely due to a bug in the previous
schema definition. For example if a column was missing a constraint, and
a new migration is attempting to add the constraint, there might already
be values that violate the new constraint. In such cases, we would want
the user to make a decision to address the data, and need to provide
them with details about what data is problematic in case they want to
manually address the problem. To help the user, if there is a sane way
to address the data, we should provide an option to automatically
"repair" the data, allowing the migration to continue. However, this
still should be an explicit opt-in from the user, and we need to clearly
describe what the repair option would do to the user so they understand
the consequences of opting in.
To accomplish this each migration can be provided a hook that contains a
CheckFunc, RepairFunc, and RepairDescription. These functions must
operate at the point-in-time of the migration immediately preceding the
current migration, as as such they should not use and domain packages or
repositories, instead they should use direct sql with the sql library.
The description is used to explain what the RepairFunc will do.
Hooks should be defined in `internal/db/schema/migrations/oss/oss.go`
and registered with the schema edition.
See the example in `internal/db/schema/manager_example_test.go` for more
details.
* chore(deps): Update grpc-gateway dependency
This fixes an issue which would allow an attacker to trigger a
(recovered) panic in the gateway handler.
* fix(server): Use cmp.Diff instead of assert.Equal
Testify is not great at handling protobuf types, and
was for some reason returning a diff here when in
reality there is none. Switch to go-cmp for the
comparison to remove the error.
* chore: update go-dbw dependencies
This update included an update of the upstream gorm dependency.
In the latest update, gorm appears to have become more sensitive when
a slice is passed into operations. The ptr to slice must now
be a ptr to slice of ptrs. This change required an update to how
boundary handles slices of PrincipalRole, which now must return a ptr
to PrincipalRole. There were also some tests that needed to be
updated because of this change.
* fixup! chore: update go-dbw dependencies
* feat(credentials): Refactor credential purposes
* Application credentials have been refactored to Brokered credentials
* Egress credentials have been refactored to Injected Application
credentials
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
* Add support for ssh_private_key credential type in Vault libraries
* Add support for ssh_private_key credential type
* Support jsonpointer for Vault library mapping overrides
This adds two new config options for the `database` stanza:
- `max_idle_connections`
- `max_idle_time`
These correspond to settings for the underlying `sql.DB` instance. They
can be used to have finer control over the controller's database
connection pool. For example this can be used to mitigate the high
connection overhead when connecting to postgres by setting a high
`max_idle_connections` and either setting `max_idle_time` to zero or to
a high duration.
Alternatively, if using a connection pool like pgpool-II or pgbouncer,
`max_idle_connections` can be set to 0.
See:
https://pkg.go.dev/database/sql#DB.SetMaxIdleConnshttps://pkg.go.dev/database/sql#DB.SetConnMaxIdleTimehttps://www.pgpool.net/mediawiki/index.php/Main_Pagehttps://www.pgbouncer.org/
* bug(scheduler): Fix controller id length check
The job_run table has a foreign key to the server_controller private_id.
While this column is called a prviate_id it does not implement the wt_private_id
postgres domain type, and therefore does not have a minimum length of 10 characters.
Johan Brandhorst-Satzkorn
Irena Rindos
Michael Gaffney
Todd
Timothy Messier
Damian Debkowski
Jeff Mitchell
Hugo VieiraandJeff Mitchell
Louis Ruch
Danielle
Jim
Damian Debkowski
irenarindos
Jeff Malnick