summaryrefslogtreecommitdiff
path: root/internal/handler/exec.go
Commit message (Collapse)AuthorAgeFilesLines
* Improve error message for Gitaly `LimitError`sAlejandro Rodríguez2022-10-241-1/+19
|
* Update Gitaly to v15Igor Drozdov2022-08-051-1/+1
| | | | | | | | | | | This commit also excludes gitlab-shell from dependencies: Gitaly specifies Gitlab Shell as a dependency as well in order to use gitlabnet client to perform API endpoints to Gitlab Rails. As a result, Gitlab Shell requires Gitaly -> Gitaly requires an older version of Gitlab Shell -> that version requires an older version of Gitlab Shell, etc. Let's use exclude to break the chain earlier
* go: Bump major version to v14Patrick Steinhardt2022-07-051-4/+4
| | | | | | | | | | | | | While gitlab-shell currently has a major version of v14, the module path it exposes is not using that major version like it is required by the Go standard. This makes it impossible for dependents to import gitlab-shell as a dependency without using a commit as version. Fix this by changing the module path of gitlab-shell to instead be `gitlab.com/gitlab-org/gitlab-shell/v14` and adjust all imports accordingly. Changelog: fixed
* Display constistently in gitlab-sshd and gitlab-shellIgor Drozdov2022-05-211-5/+3
| | | | | - Use console package to format the errors in gitlab-sshd - Suppress internal Gitaly errors in client output
* Always use Gitaly sidechannel connectionsJacob Vosmaer2022-05-021-4/+3
| | | | | | | Before this change, the GitLab internal API could use a boolean response field to indicate whether gitlab-shell should make sidechannel connections go Gitaly. We now ignore that response field and always use sidechannel connections.
* Reuse Gitaly conns and SidechannelIgor Drozdov2022-03-071-80/+34
| | | | | | | | When gitlab-sshd has been introduced we've started running our own SSH server. In this case we're able to cache and reuse Gitaly connections and Registry. It helps to reduce memory usage.
* Optionally use SSHUploadPackWithSidechannelJacob Vosmaer2022-01-251-9/+15
| | | | | | | If the GitLab API returns an allowed response with use_sidechannel set to true, gitlab-shell will establish a sidechannel connection and use SSHUploadPackWithSidechannel instead of SSHUploadPack. This is an efficiency improvement.
* Add logging to RunGitalyCommand funcid-logging-for-handlerIgor Drozdov2021-10-201-4/+11
|
* Improve err message given when Gitaly unavailableIgor Drozdov2021-09-171-0/+8
|
* Add context fields to loggingid-context-fieldsIgor Drozdov2021-09-151-1/+1
| | | | It adds correlation ids wherever possible
* Fix formatting via make fmtStan Hu2021-07-261-2/+2
|
* Switch to labkit/log for logging functionalityIgor Drozdov2021-07-221-9/+9
|
* fix: upgrade of the gitaly dependencyPavlo Strokov2021-06-021-3/+3
| | | | | | | | | | | Gitaly project now properly respects module release flow and includes a module suffix in the package name. It requires to re-write all non-suffixed imports with suffixed of a specific version of tha module. With proper module versioning we don't need to use a 'replace' directive to point to specific commit and can use semantic versioning for the gitaly dependency. Part of: https://gitlab.com/gitlab-org/gitaly/-/issues/3177
* Fix opentracing setup for gitlab-sshdNick Thomas2021-05-171-52/+37
| | | | | | | | | | | | | | | | | | | | Previously, opentracing (if configured) was initialized late in the gitlab-shell process's lifespan, coming just before making a gRPC call to Gitaly. By moving the opentracing initialization to be at process startup, we make it available for the whole process lifecycle, which is very useful to gitlab-sshd, as it means we'll only call tracing.Initialize() once on process startup, rather than once per SSH connection. To get this working, we need to introduce a context to gitlab-sshd. This carries the client/service name, but also carries an initial correlation ID. The main outcome of this is that all calls to the authorized_keys endpoint from a given gitlab-sshd process will now share a correlation ID. I don't have a strong opinion about this either way. Changelog: fixed
* Merge branch '501-gitaly-respect-parent-context' into 'main'Nick Thomas2021-05-101-18/+12
|\ | | | | | | | | Respect parent context for Gitaly calls See merge request gitlab-org/gitlab-shell!469
| * Respect parent context for Gitaly callsNick Thomas2021-05-051-18/+12
| | | | | | | | | | | | | | | | | | Without these changes, Gitaly calls would not be linked to a parent context. This means that they would have an unassociated correlationID, and Gitaly RPC calls would not be cancel()ed by parent context cancellation. Changelog: fixed
* | Stop changing directory to the filesystem rootNick Thomas2021-05-061-6/+0
|/ | | | | | | | | | | This behaviour dates from when Gitaly RPCs were executed in Ruby by a Go subprocess. It's not needed for gitlab-shell now that it's in Go, and it's a very strange thing for gitlab-sshd. Best just to remove it. If we wanted to retain this behaviour, we could have an `os.Chdir` call in the gitlab-shell binary, but I just don't think it's needed. Changelog: fixed
* chore: Refactor env introspection to rely on command initialization496-move-env-introspection-to-sshenvLucas Charles2021-03-151-6/+6
| | | | | | | Refactors introspection of execution environment to rely on per-connection state (`gitlab-shell`) or per request (`gitlab-sshd`) Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/496
* Include key ID and type in metadataAsh McKenzie2020-11-201-0/+3
|
* Propagate client identity to gitalyIgor Wiedler2020-11-171-0/+9
|
* Generate and log correlation IDsStan Hu2020-07-311-11/+29
| | | | | This will make it easier to tie an SSH access request to Rails API and Gitaly requests.
* Log SSH key detailsStan Hu2020-07-231-0/+2
| | | | | | | | | | | | | | | | | | | | | Right now when a client such as gitlab-shell calls the `/api/v4/internal/allowed` API, the response only tells the client what user has been granted access, and it's impossible to tell which deploy key/token was used in the authentication request. This commit adds logs for the following when available: 1. `gl_key_type` (e.g. `deploy_key` or `key`) 2. `gl_key_id` These fields make it possible for admins to identify the exact record that was used to authenticate the user. API changes in the `/internal/allowed` endpoint in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37289 are needed to support this. Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/203
* Log remote IP for executed commandssh-log-remote-ipStan Hu2020-07-201-0/+2
| | | | | | | | Admins may want to know what client IP originated the request. This commit adds a `remote_ip` field to the log that extracts the IP address from the `SSH_CONNECTION` environment variable. Closes https://gitlab.com/gitlab-org/gitlab-shell/-/issues/199
* Set client name when making requests to Gitalycl-client-nameChangzheng Liu2020-05-211-3/+16
|
* Remove unnecessary command argumentDavid Kim2020-04-081-2/+2
|
* Move logging to handler insteadDavid Kim2020-04-071-0/+17
|
* Merge branch 'pass-ff-to-gitaly' into 'master'Ash McKenzie2019-10-291-0/+16
| | | | | Add support for Gitaly feature flags See merge request gitlab-org/gitlab-shell!351
* Rename import pathsNick Thomas2019-10-181-1/+1
|
* Move go code up one levelNick Thomas2019-10-181-0/+96