From
https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4498#note_397401883,
if you specify a relative path such as:

```
external_url 'http://gitlab.example.com/gitlab'
```

gitlab-shell doesn't have a way to pass the `/gitlab` to the host. For example, let's say we have:

```
gitlab_url: "http+unix://%2Fvar%2Fopt%2Fgitlab%2Fgitlab-workhorse%2Fsocket"
```

If we have `/gitlab` as the relative path, how do we specify what is the
UNIX socket path and what is the relative path? If we specify:

```
gitlab_url: "http+unix:///var/opt/gitlab/gitlab-workhorse.socket/gitlab
```

This is ambiguous. Is the socket in
`/var/opt/gitlab/gitlab-workhorse.socket/gitlab` or in
`/var/opt/gitlab/gitlab-workhorse.socket`?

To fix this, this merge request adds an optional
`gitlab_relative_url_root` config parameter:

```
gitlab_url: "http+unix://%2Fvar%2Fopt%2Fgitlab%2Fgitlab-workhorse%2Fsocket"
gitlab_relative_url_root: /gitlab
```

This is only used with UNIX domain sockets to disambiguate the socket
and base URL path. If `gitlab_url` uses `http://` or `https://`, then
`gitlab_relative_url_root` is ignored.

Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/476

Release v13.6.0

See merge request gitlab-org/gitlab-shell!407

Add support obtaining personal access tokens via SSH

See merge request gitlab-org/gitlab-shell!397

Implements the feature requested in gitlab-org/gitlab#19672

This requires the internal api counterpart in gitlab-org/gitlab!36302 to
be merged first.

It can be used as follows:
```
censored@censored-VirtualBox:~/git/gitlab$ ssh git@gitlab-2004 personal_access_token
remote:
remote: ========================================================================
remote:
remote: Usage: personal_access_token <name> <scope1[,scope2,...]> [ttl_days]
remote:
remote: ========================================================================
remote:

censored@censored-VirtualBox:~/git/gitlab$ ssh git@gitlab-2004 personal_access_token newtoken read_api,read_repository 30
Token:   aAY1G3YPeemECgUvxuXY
Scopes:  read_api,read_repository
Expires: 2020-08-07
```

Specify more recent go version in go.mod

See merge request gitlab-org/gitlab-shell!405

Release v13.5.0

See merge request gitlab-org/gitlab-shell!404

Generate and log correlation IDs

See merge request gitlab-org/gitlab-shell!400

Stan Hu authored 4 years ago and Igor Drozdov committed 4 years ago

This will make it easier to tie an SSH access request to Rails API and
Gitaly requests.

Revert "Update executable.go"

See merge request gitlab-org/gitlab-shell!403

This reverts commit 869aeb90

Release v13.4.0

See merge request gitlab-org/gitlab-shell!402

Log SSH key details

See merge request gitlab-org/gitlab-shell!398

Stan Hu authored 4 years ago and Igor Drozdov committed 4 years ago

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 commands

Closes #199

See merge request gitlab-org/gitlab-shell!399

Drop Go v1.12 support

See merge request gitlab-org/gitlab-shell!401

We officially use Go v1.13+ for everything
(https://docs.gitlab.com/ee/install/requirements.html#go-versions), and
dropping Go v1.12 allows us to use new methods such as
`http.NewRequestWithContext`.

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

Merge branch '459-system-default-ssl_cert_dir-is-being-used-during-remote-gitaly-over-tls' into 'master'

Support ssl_cert_dir config setting

See merge request gitlab-org/gitlab-shell!393

Extract coverage for Go code on CI pipeline

See merge request gitlab-org/gitlab-shell!392

Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>

Use simplified setup for code intelligence

See merge request gitlab-org/gitlab-shell!386

Use codequality CI template

See merge request gitlab-org/gitlab-shell!389

In https://gitlab.com/gitlab-org/gitlab/-/issues/218797, it was
determined that gitlab-shell is using an outdated image that no
longer exists.

To ensure that we are using up to date codequality image, we
can use the built-in template instead.

Release v13.3.0

See merge request gitlab-org/gitlab-shell!391

Upgrade Ruby version to v2.6.6

See merge request gitlab-org/gitlab-shell!390

GitLab has now been upgraded to use Ruby 2.6.6:
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33253

Use default puma socket in example config

See merge request gitlab-org/gitlab-shell!388

The unicorn replacement 'puma' uses a unix socket in the example config [1] instead of a tcp port.
Using the non-existing tcp port results in "Internal API unreachable" on
git operations.

[1] https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/puma.rb.example#L34

Set client name when making requests to Gitaly

See merge request gitlab-org/gitlab-shell!387