When this command is executed:
```
$ scp host:path/with/wildcards/* .
```
Teleport would launch "SSH exec" request on the sever side, which in
turn would execute the following:
```
/bin/bash -c /usr/bin/teleport scp --remote-addr=127.0.0.1:44226 --local-addr=127.0.0.1:3022 -r -f path/with/wildcards/*
```
The problem is that bash will attempt to "expand" the wildcard, sending
a bunch of files as an input into -f, but `teleport scp` needs to see
the _exact_ string as passed via scp client.
The proposed solution is to detect shell wildcard characters and wrap
them in single quotes preventing them from being expanded.
Another potential solution is to NOT use shell to execute SCP commands.
* Add prometheus endpoint to expose system stats
* Add heealthz endpoint
* Add gops endpoint for real time troubleshooting
* Deprecate httprof endpoint
BoltDB backend is now compatible with how all backends should
initialize.
Also all BoltDB-specific code/constants have been consolidated inside of
`backend.boltbk` package.
Trusted clusters and cert authorities static configuration
sections were not properly processed and we've been creating
incomplete V2 objects in the database. This commit fixes the problem
Originally Teleport had facilities to configure events/recordings via two
separate backends.
In reality those two objects (session events and session recordings)
need each other and currently there is only one implementaiton of it.
The old structures were unused. This commit is 100% dead code removeal.
- Added ability to read AWS config from `~/.aws` directory for testing
- Fixed TTL bug in DynamoDB back-end
- Made FS back-end return similar error types as Boltdb does
- Cleaned up buggy tests for DynamoDB
- Removed unnecessary locks everywhere in code
Functionality:
`teleport` binary now serves web assets from its own binary file.
Unless `DEBUG` environment variable is set to "1" or "true", in
this case it will look for ../web/dist (as located in github repo)
which can be used for development.
Design:
To avoid accumulating 3rd party dependencies with a ton of extra
features and licenses, this implementation uses minimalistic
implementation of http.FileSystem interface on top of the embedded ZIP
archive.
1. The assets are zipped into assets.zip during build process
2. assets.zip gets appended to the end of `teleport` binary
3. The resulting file is converted into a self-extracting ZIP
4. Teleport opens itself using the built-in zip unarchiver, and loads
the assets on demand.
Notes:
1. LOC is tiny (dozens)
2. RAM consumption is CONSTANT regardless of the ZIP size, about 500Kb
increase vs load-from-file, and most of it is linking zip archive
code from the standard library. Tested with a 20MB ZIP archive.
This backend can be enabled by optionally adding a new build flag.
See lib/backend/dynamo/README.md for details.
It should not affect default Teleport builds.
