Skip to content
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

Closed
klizhentas opened this issue Feb 13, 2016 · 1 comment
Closed

teleport start listen port #123

klizhentas opened this issue Feb 13, 2016 · 1 comment
Assignees

Comments

@klizhentas
Copy link
Contributor

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. 
@kontsevoy
Copy link
Contributor

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
Projects
None yet
Development

No branches or pull requests

2 participants