ObeyTimeouts() facility was handling errors more arggessively than
needed.
So if you pass net.Conn implementation which does not support timeouts,
it would simply fail on every read() and write() instead of ignoring
them.
Now it ignores them.
client runs with elevated permissions and the command fails (for
instance, when the auth server state has not yet been generated), it
will leave the file behind possibly making further attempts to properly
generate content in data directory by a lower-privilege process impossible.
* Downgraded many messages from `Debug` to `Info`
* Edited messages so they're not verbose and not too short
* Added "context" to some
* Added logical teleport component as [COMPONENT] at the beginning of
many, making logs **vastly** easier to read.
* Added one more logging level option when creating Teleport (only
Teleconsole uses it for now)
The output with 'info' severity now look extremely clean.
This is startup, for example:
```
INFO[0000] [AUTH] Auth service is starting on turing:32829 file=utils/cli.go:107
INFO[0000] [SSH:auth] listening socket: 127.0.0.1:32829 file=sshutils/server.go:119
INFO[0000] [SSH:auth] is listening on 127.0.0.1:32829 file=sshutils/server.go:144
INFO[0000] [Proxy] Successfully registered with the cluster file=utils/cli.go:107
INFO[0000] [Node] Successfully registered with the cluster file=utils/cli.go:107
INFO[0000] [AUTH] keyAuth: 127.0.0.1:56886->127.0.0.1:32829, user=turing file=auth/tun.go:370
WARN[0000] unable to load the auth server cache: open /tmp/cluster-teleconsole-client781495771/authservers.json: no such file or directory file=auth/tun.go:594
INFO[0000] [SSH:auth] new connection 127.0.0.1:56886 -> 127.0.0.1:32829 vesion: SSH-2.0-Go file=sshutils/server.go:205
INFO[0000] [AUTH] keyAuth: 127.0.0.1:56888->127.0.0.1:32829, user=turing.teleconsole-client file=auth/tun.go:370
INFO[0000] [AUTH] keyAuth: 127.0.0.1:56890->127.0.0.1:32829, user=turing.teleconsole-client file=auth/tun.go:370
INFO[0000] [Node] turing connected to the cluster 'teleconsole-client' file=service/service.go:158
INFO[0000] [AUTH] keyAuth: 127.0.0.1:56892->127.0.0.1:32829, user=turing file=auth/tun.go:370
INFO[0000] [SSH:auth] new connection 127.0.0.1:56890 -> 127.0.0.1:32829 vesion: SSH-2.0-Go file=sshutils/server.go:205
INFO[0000] [SSH:auth] new connection 127.0.0.1:56888 -> 127.0.0.1:32829 vesion: SSH-2.0-Go file=sshutils/server.go:205
INFO[0000] [Node] turing.teleconsole-client connected to the cluster 'teleconsole-client' file=service/service.go:158
INFO[0000] [Node] turing.teleconsole-client connected to the cluster 'teleconsole-client' file=service/service.go:158
INFO[0000] [SSH] received event(SSHIdentity) file=service/service.go:436
INFO[0000] [SSH] received event(ProxyIdentity) file=service/service.go:563
```
You can easily tell that auth, ssh node and proxy have successfully started.
`tsh` has always supported reverse tunnels via undocumented "sites"
command.
This commit:
1. Renames "sites" to "clusters" to be consistent with the rest of
Teleport naming conventions
2. Adds --cluster flag to `tsh ssh`
3. Updates the User Manual in the documentation dir
Refs #437
- Friendly error messages when parsing configuration and establishing
connection
- Bugs related to "first start" vs subsequent starts (reverse tunnells
added to YAML file won't be seen upon restart)
- Nicer logging
Teleport has always worked on OSX, but not all tests were OSX
compatible:
- some wouuld hang
- others would fail
This commit fixes that. `make test` passes on OSX.
When a user tries to login with a non-existing mapping (local OS does
not know anything about 'vince') he gets an ugly message:
"ERROR: cannot start shell"
Instead I wanted to show a nicer "host 'turing' does not have a local
user 'vince'"
The closest I could get was a generic 'access denied' + an informative
logging message in teleport logs.
- replay now works in both web and CLI
- fixed two nasty connection bugs in web sessions
- removed verbose logging/diagnostics
- refactoring of web code by Alexey
Sasha Klizhentas