kubo
kubo copied to clipboard
ipfs
use standard, unassigned ports for the daemon
port 8080 is often in use on servers. it's the case here, and blocks that part of the daemon from starting up:
anarcat@marcos:~$ ipfs daemon
Initializing daemon...
API server listening on /ip4/127.0.0.1/tcp/5001
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
23:18:02.772 ERROR cmd/ipfs: listen tcp 127.0.0.1:8080: bind: address already in use <autogenerated>:24
IANA allocated port 8080 to web caches:
http-alt 8080/tcp webcache # WWW caching service
...but it's frequently squatted by a hodge-podge array of random offenders (e.g. Icecast, in my case, Apache Tomcat, Syncthing, etc). ipfs is the latest addition to the stack. :p
5001 is allocated to an obscure:
commplex-link 5001 tcp
... but it is also used by iperf (oh that could be pretty fireworks), Slingbox and Synology, according to Wikipedia.
the port should at least be customizable, maybe it is, but ipfs daemon --help doesn't tell me how.
i also believe a standard port pair should be requested from IANA, unless an RFC is made for HTTP/3 and the ipfs port becomes 80. :p but maybe that's a separate issue?
at least finding less busy ports would be a good idea. according to wikipedia at least 8082, 8084 and 8085 are free if you like the 80XX range, and 5020+ is also free.
For more sources on ports:
ports are already customizable. you can change them in the config. See:
ipfs config Addresses.Gateway
ipfs config Addresses.API
ipfs config Addresses.Swarm
ipfs config Addresses
they can be set like:
ipfs config Addresses.Gateway /ip4/0.0.0.0/tcp/9001
the port should at least be customizable, maybe it is, but
ipfs daemon --helpdoesn't tell me how.
Agreed ipfs daemon should note ability to change config values for ports. i've changed the title of this issue accordingly.
if you don't mind, i created a PR for documenting the ports changing procedure in #879. we can therefore keep this ticket for changing the default ports to more standard behaviour.
@anarcat on the ports, the reasoning for 8080 is what a lot of developers use to develop things, so it's a familiar place. agreed that it's annoying to clash-- but i would like to keep the gateway in the 8000/9000 range. 8888 is also typical, but less nice.
I dont care much about it, whatever works and is intuitive to people.
I guess is also needed a change of the default port 5001, because port is used by iperf program by default...
We had a related discussion recently (@batcer in https://github.com/ipfs/go-ipfs/issues/1678#issuecomment-145756135 and myself):
http://localhost:8080
Not a good idea. I have Apache Tomcat on port 8080 and it is by default. Doesn't IPFS deserve dedicated port by default? Why use so common one?
(..)
8080 (..) follows unwritten convention championed by other HTTP proxies (a port in 8xxx range).
(..)
Moving to something like 8001 would unify the 'look and feel' of default ports, and solve us some setup time.
The gist: 8080 is very popular and often clashes with other software, using something else (in 8xxx range) would remove need of changing deault port for a lot of people.
Yes, ok -- I think we should use something like:
- Swarm:
4737(IPFS) - Gateway:
8X80 - API:
8(X + 1)80
Maybe X=1 ?
Some port clashing will be inevitable, and configurability is fine. But making the common case is nice.
One thing to note: lots of ipfs things today assume localhost:8080 so we
should itemize them to update them.
On Thursday, October 8, 2015, Marcin Rataj [email protected] wrote:
We had a related discussion in #1678 (comment) https://github.com/ipfs/go-ipfs/issues/1678#issuecomment-145756135:
http://localhost:8080
Not a good idea. I have Apache Tomcat on port 8080 and it is by default. Doesn't IPFS deserve dedicated port by default? Why use so common one?
(..)
8080 (..) follows unwritten convention championed by other HTTP proxies (a port in 8xxx range).
(..)
Moving to something like 8001 would unify the 'look and feel' of default ports, and solve us some setup time.
The gist: 8080 is very popular and often clashes with other software, using something else (in 8xxx range) would remove need of changing deault port for a lot of people.
— Reply to this email directly or view it on GitHub https://github.com/ipfs/go-ipfs/issues/874#issuecomment-146769238.
Get here while googling for a commplex-link (5001) conflict with ipfs daemon. So the problem is actual.
One thing to note: lots of ipfs things today assume
localhost:8080so we should itemize them to update them.
Is this still the case?
I also have Tomcat installed and I needed to change the default port. So I chose port 6437 for my ipfs gateway.
How did I come to this idea? I converted the lowercase letters of ipfs to their decimal values and just added up the digits.
i = 105 = 6 p = 112 = 4 f = 102 = 3 s = 115 = 7
The fact that apparently this port is unasigned (according to speedguide.net) made me think it was a good alternative port. At least it's not a totally random number.
Somehow related: a proposal for ipfs-desktop (GUI wrapper for go-ipfs) to automatically pick a free port is discussed in https://github.com/ipfs-shipyard/ipfs-desktop/issues/912
@hsanjuan @Stebalien we may want to address this sooner than later.
Port 8080 is often taken and go-ipfs fails to start – pretty bad first impression when it comes to dev exp.
Thoughts on reopening this?
+1, these are unwinnable situations that only get harder over time and as we grow. Best to cut losses by changing immediately to a port or range that's off the beaten track (do a google search to look for any obvious conflicts) and win back all that future time that will otherwise been spent by us and potential IPFS developer users on it.
So, one solution is "do both". That is: try to listen on mulitple ports but succeed if at least one of the listen addresses succeeds.
Related: #7053
So, one solution is "do both". That is: try to listen on mulitple ports but succeed if at least one of the listen addresses succeeds.
This still means that if ipfs manages to occupy :8080 other applications will not be able to use it. And we don't have a predictable port number, and we need to maintain some extra code, and docs, and clients like Companion may need to do guesswork to figure out in which port the gateway managed to run this time...
I'd just change the default port. Having our app listening on multiple ports and not failing unless all fail is just not how I'd expect something to work (https://en.wikipedia.org/wiki/Principle_of_least_astonishment).
Having the default port change over night is likely even worse. I'd like to give users a transition period.
My thinking is along these lines:
-
:8080is the problem, other ports are fine (i think?) - the port would not change for existing users – we would not change their configs
- we would only change the default in:
-
go-ipfs-config/init.go, so all new users/installs get something other than
8080 - all tests, docs and examples – so we remove confusion related to
:8080being something else on users system already
-
go-ipfs-config/init.go, so all new users/installs get something other than
Why not change the IP instead of the port?
We could just use 127.0.0.80:8080 or something like this :)
Ah, nevermind. The issue is browsers. localhost -> 127.0.0.1 and "localhost" is treated as a secure origin, even without TLS. If we used a non-localhost address, HTTPS websites wouldn't be able to make requests to the IPFS API.
so, i've been just hit by this (a conflict with jenkins port in my case). i think picking a stable non-assigned and non-popular port is a must for further wider adoption of ipfs (especially for the non-savvy).
while a sudden change may (and will) bring confusion for some but this will be time-limited (a month at most? imo it's just about updating the defaults in most popular programs such as ipfs-companion and official documentation) and it in the long term it will settle this issue forever! also, when ipfs is widely adopted, this has to be done anyway so why do it now?
after reading through rfc6335 (iana port number application process) i suggest we come up with:
- list of ports (currently it's 8080, 4001, 5001 ...anything else?)
- sensible names for the services (ipfs-gateway, ipfs-node, ipfs-webui ...or something like that)
- a contact person (i can be the contact but i suppose you'd like to have there someone from the core team)
and fill this form:
https://www.iana.org/form/ports-services
if you provide the information in this issue's comments, i can try to go through the registration process on your behalf.
cheers!
That will work for IPv4, but not ipv6.
True.
Hm. Although I guess we don't even listen on IPv6 by default.
A thing we might want to change, as the browsers are probably trying both protocols.
Ah, nevermind. The issue is browsers. localhost -> 127.0.0.1 and "localhost" is treated as a secure origin, even without TLS. If we used a non-localhost address, HTTPS websites wouldn't be able to make requests to the IPFS API.
Using non-localhost addresses is difficult since we would need to tweak the dns-calls, since .localhost is basically a catch-all, while something like .local would need to be answered.
I think the port idea 6437 is nice, thanks @ruverav.
Well, no browser show localhost websites as secure:
Click to expand
(all freshly installed)
Well, no browser show localhost websites as secure:
It's a little more complicated.
- Firefox:
-
localhost:*- UI: Not marked as secure but not marked as insecure either.
- JS APIs: Treated as a "secure" context.
-
*.localhost- UI: Marked as insecure.
- JS APIs: Treated as an "insecure" context.
-
- Chrome:
-
localhost:*,*.localhost- UI: not marked
- JS APIs: secure context
-
By "not marked", I mean that the URL bar doesn't explicitly say "Not Secure" or include a lock with a line through it. Try http://example.com for an example.
By "secure context", I mean the website can access APIs reserved for websites running in a secure context (can make requests with HTTPs, can access the web crypto APIs, can access the camera, etc.).
The other half of this is that the subdomain gateway feature only works with localhost (ipfs.io.ipns.localhost`).
By "not marked", I mean that the URL bar doesn't explicitly say "Not Secure" or include a lock with a line through it. Try
http://example.comfor an example.
Well, at least Firefox do should an 'insecure' lock.
The other half of this is that the subdomain gateway feature only works with
localhost(ipfs.io.ipns.localhost`).
Yeah that's what I meant with catch-all.
Is it possible to register new protocols in the modern browsers (like we basically already do with ipfs:// and ipns:// via the addons) but let the browser speak directly to the API instead of redirecting it to the web gateway? 🤔
@Stebalien
Hm. Although I guess we don't even listen on IPv6 by default.
I've changed that:
https://github.com/ipfs/go-ipfs-config/pull/84