| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| | |
# Conflicts:
# internal/command/twofactorverify/twofactorverify.go
|
| |
| |
| |
| | |
We need to pass time.Now as a param, otherwise it's calculated on call
|
| | |
|
| | |
|
| |\
| | |
| | |
| | |
| | | |
Reuse Gitaly connections and sidechannel
See merge request gitlab-org/gitlab-shell!575
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I'd assumed that the `omitempty` directive for LogLevel in
internal/config/config.go would get us this behaviour. If it did, we
wouldn't have had to specify the default twice. Unfortunately, it
doesn't, which is to say that given a config file like:
```
log_level:
```
The default *is* overridden by the empty string.
It's an easy enough fix.
Changelog: fixed
|
| |
| |
| |
| |
| |
| | |
- Counter of HTTP merge requests
- Gauge of HTTP requests currently being performed
- Gauge of connections currently handled by gitlab sshd
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently, we don't process the results of this execution,
because it's not really imprortant
Let's at least log the err if the execution went wrong
That will also make Vulnerability report happy
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| | |
This field will act as a feature flag that controls whether
gitlab-shell uses the old SSHUploadPack RPC or the new
SSHUploadPackWithSidechannel.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reduces coupling between tests in
internal/gitlabnet/accessverifier/client_test.go, and will make it
easier to add new test cases in the future.
Note that the test server had a special behavior for the username
"second", but this was never used. So we removed that behavior in this
commit.
|
| |
| |
| |
| |
| | |
This log entry doesn't respect log level, because the log level
is configured after this logging happens
|
| |
| |
| |
| |
| | |
- Use require.Regexp to expect ssh handshake error
- Use require.Eventually to refactor verifyStatus
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Due to the way sshd works, gitlab-shell could be called with a single
string in the form:
```
/path/to/gitlab-shell -c key-id
```
However, due to the tightening of the regular expressions in fcff692b
this string no longer matches, so logins would fail with:
```
Failed to get username: who='' is invalid
```
This can be reproduced by changing the user's shell to point to
gitlab-shell. For example:
```
usermod git -s /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell
```
While setting gitlab-shell as the user's shell isn't officially
supported, gitlab-shell still should be able to cope with the key being
specified as the last argument. We now split the argument list and use
the last value.
Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/530
|
| | |
|
| | |
|
| |\
| | |
| | |
| | |
| | | |
Improve logging for non-git commands
See merge request gitlab-org/gitlab-shell!538
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Several of our commands only touch the internal API, and go nowhere
near Gitaly. Improve logging for each of these in a single MR. In
general, we want to be able to tell what happened in the execution of
each command, and to track failures down to a specific line of code.
Changelog: added
|
| |/
| |
| |
| |
| |
| | |
This will help to prevent misconfigurations.
Changelog: fixed
|
| |
| |
| |
| |
| |
| |
| |
| | |
Use reflection to log the command we are about to execute, both in
gitlab-shell and gitlab-sshd. Include the environment, which has all
the context we need to understand what the command is expected to do.
Changelog: added
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently we get this in some log messages:
logrus_error="can not add field \"channel_type\""
This is because we're trying to add a function, rather than the result
of the function call (a string) to the `log.Fields`. Whoops!
Changelog: fixed
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
This was lost in the move from Ruby to Go. Restore it now.
Changelog: fixed
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
refactor: unify instantiation of command.Shell
Closes #517
See merge request gitlab-org/gitlab-shell!520
|
| | | |
|
| |/ |
|
| |
| |
| |
| | |
It adds correlation ids wherever possible
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|