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

Orchestration for starting ipfs daemon without port conflicts #7709

Open
lidel opened this issue Sep 30, 2020 · 11 comments
Open

Orchestration for starting ipfs daemon without port conflicts #7709

lidel opened this issue Sep 30, 2020 · 11 comments
Labels
kind/feature A new feature need/triage Needs initial labeling and prioritization topic/config Topic config
Milestone

Comments

@lidel
Copy link
Member

lidel commented Sep 30, 2020

Requirements

Native support in Brave (brave/brave-browser#10220) requires a way of starting daemon without worrying about user having the default ports taken.

Specific needs are:

  • $IPFS_PATH/config should be the source of truth about Swarm, API and Gateway ports
  • Conflict avoidance should be future-proof, meaning if current port gets taken by something else in the future, daemon will automatically pick next one and update source of truth

Note that setting ports to 0 is not feasible:

  • it is meant to be used in tests, reading config tells us nothing about Gateway port, produces different port every time, and it is hard to read randomly-picked ports without capturing stout of ipfs daemon
  • we don't want gateway URLs to change all the time, as that would mean Origins are different every time daemon restarts, which breaks web storage on websites. it should change only if there is a conflict.

Proposed implementation

Add a parameter ipfs daemon --update-ports-if-taken
(or --find-free-ports ? suggestions? 🚲 🏚️ )

This new parameter should enable additional checks before ipfs daemon starts:

  • check if ports defined in $IPFS_PATH/config are free before starting (Swarm, API, Gateway)
    • if not
      • increase them +1 and retry until all are free
      • save new values to $IPFS_PATH/config
      • start regular ipfs daemon

cc @autonome @aschmahmann

@lidel lidel added need/triage Needs initial labeling and prioritization P0 Critical: Tackled by core team ASAP kind/feature A new feature topic/config Topic config labels Sep 30, 2020
@tysonzero
Copy link

On a related note would it be reasonable to change the default ports? Port collisions seem unnecessarily common due to the current choice of fairly popular ports. I know I've run into collisions locally.

@Stebalien
Copy link
Member

See #874.

@Geo25rey
Copy link

Geo25rey commented Nov 9, 2020

It might be worth while to add a config option to randomly select available ports at launch instead of requiring application of the "randomports" profile for each port change.

Edit: Something like this:

// Open the repo
repo, err := fsrepo.Open(repoPath)
if err != nil {
	return nil, err
}

cfg, err := repo.Config()

// Sets swarm ports to random - helps with port conflicts
maxTries := 3
err = config.Profiles["randomports"].Transform(cfg)
for i := 0; i < maxTries; i++ {
	if err == nil {
		break
	}
	err = config.Profiles["randomports"].Transform(cfg)
}
if err != nil {
	return nil, err
}

err = repo.SetConfig(cfg)
if err != nil {
	return nil, err
}

// Construct the node

nodeOptions := &core.BuildCfg{
	Online:  true,
	Routing: libp2p.DHTOption, 
	Repo: repo,
}

node, err := core.NewNode(ctx, nodeOptions)
if err != nil {
	return nil, err
}

// Attach the Core API to the constructed node
return coreapi.NewCoreAPI(node)

@Stebalien
Copy link
Member

There are two sets of ports:

  • Ports used to communicate with other libp2p nodes. This is what "randomports" randomizes. If you want a new random external port on every restart, just set them to zero.
  • Ports used on the by the API and the gateway. That's what this issue is about. It's again possible to do this by setting the port to 0 in the config and it's possible to learn the API port by reading the ~/.ipfs/api file. However, there's no "good" way to learn the chosen gateway port, other than to capture stdout (as noted in the first post).

@Stebalien
Copy link
Member

This new parameter should enable additional checks before ipfs daemon starts:

@lidel I'm very wary about modifying the config this way. The config is something that should generally be managed by the user.

What about exiting with a special code indicating the port conflict? That would let the caller decide how it wants to handle the issue (e.g., by modifying the config). That would also allow the application to tell the user "hey, you appear to have something else running on your IPFS gateway port, try on port XYZ?".

@Geo25rey
Copy link

Why not add a ~/.ipfs/gateway file?

@Stebalien
Copy link
Member

Stebalien commented Nov 10, 2020 via email

@Geo25rey
Copy link

Perhaps port 8008 as a gateway port alternative. It's a less common http server port, and most of its use cases in software are heavily dated, according to wikipedia.

@RubenKelevra
Copy link
Contributor

I was wondering if this is still an issue since brave/brave-browser#10220 was closed and the brave browser released the native support 🥳

Regardless of what the brave support needs, I think IPFS should change the default port - which is still 8080 as far as I can tell :)

In #874 we have had two ideas how to "encode" the characters of IPFS into a port number and got 4737 from @jbenet and 6437 from @ruverav - see #874 (comment).

@Stebalien Stebalien removed the P0 Critical: Tackled by core team ASAP label Apr 22, 2021
@Stebalien
Copy link
Member

@lidel I assume we found some way to work around this?

@BigLep
Copy link
Contributor

BigLep commented Mar 3, 2022

@lidel : is this an issue still, or can this be closed?

@BigLep BigLep added this to the TBD milestone Mar 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature A new feature need/triage Needs initial labeling and prioritization topic/config Topic config
Projects
No open projects
Status: 🥞 Todo
Development

No branches or pull requests

6 participants