It's like someone should make a file... maybe in /etc ... and put short names for services in it... maybe it could be called /etc/services...
$ getent services gopher
gopher 70/tcpalso `curl -v http://127.0.0.1:gopher/` gives error message
* URL rejected: Port number was not a decimal number between 0 and 65535
* Closing connection
curl: (3) URL rejected: Port number was not a decimal number between 0 and 65535
is it http or gopher? :)
i just wanted to make the point that even if you have service names in /etc/services, it is not possible to use that names easily to host/access http(s) services.
the OP made a tool which helps them to avoid using port numbers. people commented in a way that looked like laughing at him, like he reinvented the wheel, and talking about /etc/services. well ok, i decided to try using /etc/services for the purpose of using names instead of port numbers.
would it be possible to add "myapp 60001/tcp" to /etc/services and then work with "http://localhost:myapp"? NO! browsers do not translate these names into port numbers. netcat does. curl does not.
so probably the OP's solution is not that questionable and really solved their need? and "good old friend /etc/services" is not useful for this? i dont know what it is useful for as running services on non-standard ports actually helps with hiding from security/vuln scanners and is practiced widely.
Also URL parsing is a completely different matter. Browsers are primarily an HTTP(s) client. If you do not mention the ":port", it will try to connect to 80 (HTTP) or HTTPS (443). Because that the default ports for a web server. Other services have different port. So if your URL has the ftp scheme, the default port would be 21.
nc is for generic connections and handles it well.
if you host an http(s) service on port 11111 you can reach it with url http://127.1:11111, but url http://127.1:vce/ would not work in most software.
$ grep 11111 /etc/services
vce 11111/udp # Viral Computing Environment (VCE)
vce 11111/tcp # Viral Computing Environment (VCE)how about "ssh://git@ssh.github.com:https/golang/go.git" instead of "ssh://git@ssh.github.com:443/golang/go.git"? does not work, hmm.
zdw: It's like someone should make a file... maybe in /etc ... and put short names for services in it... maybe it could be called /etc/services...
tolciho: And then they might code up some sort of service lookup tool thingy to use on the train wreck that is the modern web.
$ getent services gopher
gopher 70/tcp“http://127.0.0.1:70/“ is unambiguous since 70 is not a valid host.
Generally host and port mapping gets shoved somewhere into the configuration management layer and hopefully does not become too complicated (or have too many security holes) as this could vary from "configuration files and a few scripts" to database and services layers that few can debug, especially not a sysadmin at 3 AM in the morning running on an hour of bad sleep. Hypothetically.
You can still publish port numbers along with addresses in DNS though (SRV records).
It's never.
After decentralisation we always see decentralisation. After a period of growth, a decline will follow. After the vibe coding hype, consolidation will follow. After rain comes sunshine.
“[X] is so powerful that problems which are technical issues in other programming languages are social issues in [X].”
— <https://www.winestockwebdesign.com/Essays/Lisp_Curse.html#ma...>
The article is short; go read it then come back and delete.
http:// means port 80 unless specified otherwise
https:// means port 443 unless specified otherwise
ftp:// means port 21 unless specified otherwise
sftp:// means port 22 unless specified otherwise
...
The practical solution for TFA is actually just an nginx server running on port 80 with proxy_pass
location /blog/ {
proxy_pass http://127.0.0.1:3000 ;
}
location /tensorboard/ {
proxy_pass http://127.0.0.1:6006;
}
server {
listen 80;
server_name "tensorboard.localhost";
location / {
proxy_pass http://127.0.0.1:6006;
}
}
server {
listen 80;
server_name "blog.localhost";
location / {
proxy_pass http://127.0.0.1:3000;
}
}
https://meta.wikimedia.org/wiki/Cunningham%27s_Law
Sidenote: A good AI would interject, Clippy-like, "It looks like you're trying to recreate /etc/services. Would you like me to explain what that is?"
People shit-talk container orchestration systems like Kubernetes, but if anything they greatly simplified (if not completely eliminated) the need for this sort of network bookkeeping.
Way more often it’s developers who can’t figure out that their http library only supports 2 concurrent connections, or emit garbage/malformed log lines and then bitch that they can’t see their app logs because we dropped them, or can’t be fucked to do “kubectl describe” in their own developer namespace that they have full permission for.
If you truly experience issues with just using YAML then you need to skill up probably.
Your comment unironically is something I prefer and one of my biggest pain points with Linux.
As a newb, I'm sure there's something called with a mycommonproblemd name that has a stateful interface. But sometimes that all adds up to make things feel complex. And it let's me make stupid mistakes, like I forgot to close or open a port on firewalld, or I disabled a container but forgot to commit a change to my systemd units.
It's nice to just have a nice file called myservice.nix that tracks the firewall port, name, systemd startup and update scripts.
But go ahead. /etc/services, please, share with me how it's setup to do thing likes create the HTPS and makes it trusted and sets up the domain. Go ahead.
Go ahead. You can ONLY use /etc/services.
Or, you are admit you don't actually have a clue as to what /etc/services does.