-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
teleport start listen port #123
Comments
Yes. Command line flags are a subset of the configuration, the advanced settings (like configuring each of the 4 port numbers) are only available via the config file. |
gravitational-jenkins
pushed a commit
that referenced
this issue
Jul 15, 2020
35b7560 [teleport] Various fixes (#123) gravitational/webapps@35b7560
gravitational-jenkins
pushed a commit
that referenced
this issue
Jul 15, 2020
35b7560 [teleport] Various fixes (#123) gravitational/webapps@35b7560
zmb3
added a commit
that referenced
this issue
Feb 8, 2022
The script for updating webassets uses the commit message from webapps as the commit message for the PR to teleport. This commit message is almost always a merged PR, which has the format: do some awesome thing (#123) Where '#123' is the number of the **webapps** PR that was merged. The problem with this is, when the teleport PR is created, it interprets the #123 as the number of a **teleport** PR. And since the Teleport repo has a lot more issues/PRs than webapps, Github ends up linking to an old and completely unrelated PR. Fix this by replacing (#123) with (gravitational/webapps#123), which Github correctly renders as a link to the webapps PR in question.
zmb3
added a commit
that referenced
this issue
Feb 8, 2022
The script for updating webassets uses the commit message from webapps as the commit message for the PR to teleport. This commit message is almost always a merged PR, which has the format: do some awesome thing (#123) Where '#123' is the number of the **webapps** PR that was merged. The problem with this is, when the teleport PR is created, it interprets the #123 as the number of a **teleport** PR. And since the Teleport repo has a lot more issues/PRs than webapps, Github ends up linking to an old and completely unrelated PR. Fix this by replacing (#123) with (gravitational/webapps#123), which Github correctly renders as a link to the webapps PR in question.
zmb3
added a commit
that referenced
this issue
Feb 8, 2022
The script for updating webassets uses the commit message from webapps as the commit message for the PR to teleport. This commit message is almost always a merged PR, which has the format: do some awesome thing (#123) Where '#123' is the number of the **webapps** PR that was merged. The problem with this is, when the teleport PR is created, it interprets the #123 as the number of a **teleport** PR. And since the Teleport repo has a lot more issues/PRs than webapps, Github ends up linking to an old and completely unrelated PR. Fix this by replacing (#123) with (gravitational/webapps#123), which Github correctly renders as a link to the webapps PR in question.
hatched
pushed a commit
to hatched/teleport-merge
that referenced
this issue
Nov 30, 2022
* Open new tab when clicking on active session icon * Use hostname instead of relying on serverId as fallback (fallback is handled in backend) * Simplified quicklaunch regex to just check for white spaces * Encode URL when finding documents by url to handle special characters * Update sessions story and snapshot
nick-inkeep
pushed a commit
to nick-inkeep/teleport-docs
that referenced
this issue
Jun 20, 2023
* Check config.json URLs for corresponding files Fixes gravitational#101 When loading the `docs/config.json` file for each version of the docs site, we have some logic in `normalizeDocsUrl` that validates URLs (i.e., checks if the URL has a trailing slash) and adds a version-specific path segment to the URL path. This changes `normalizeDocsUrl` to also check if a file exists at the given URL path. This way, docs site builds fail if (a) a navigation entry exists for a nonexistent docs page; or (b) a redirect points to a nonexistent docs page. Unfortunately, throughout the code that handles `config.json`, there is logic that assumes the file lives in `content/<version>/docs/config.json`. To test this change on a test data directory, rather than an actual docs site directory, we would need to refactor a lot of `server/config-docs.ts` and the code that imports from it. As a result, in order to test only `normalizeDocsUrl`, I had to make it an exported function. I also had to make assumptions in the tests that there would be a `content` directory populated with per-version subdirectories. * Respond to PR feedback * Refactor the config.json checker We can't guarantee that our CI server will have loaded this repo's git submodules before running tests. This change refactors the config.json checker so we can test it with any docs content directory, e.g., the `server/fixtures` directory. This also provides better separation of concerns between the URL normalization code (which doesn't need to know about a directory tree) and the file path checker code.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Help says I can set up listen IP, but not listen port:
> teleport start --listen-ip=10.5.0.1 --roles=node --auth-server=10.5.0.2 --token=xyz Starts a SSH node listening on 10.5.0.1 and authenticating incoming clients via the auth server running on 10.5.0.2.
The text was updated successfully, but these errors were encountered: