Hacker News Reader

Comment by oneeyedpigeon | Hacker News Reader

I guess the main disadvantage is you can't reliably link to anything. Maybe not a problem if you only ever need one local server.

View on HN

Maybe this is an opportunity. Is there already a “DNS for ports” whereby the hosts file is propagated with application process identifiers that are mapped to localhost:port in hosts file?

SRV records do this.

hosts file (the hosts NSS database) does not speak DNS.

however I guess this line of thought comes from that web developers want a number of *.dev.myproject.net domain names to use in URLs and handle by different web listener processes. why don't just run a nginx as reverse proxy for all of your *.dev.myproject.net domains? update your port number ↔ domain name in nginx config; reload is quite cheap.

Careening back to inetd and /etc/services …

In some ways it is an inversion of inetd. Instead of something that listens to a bunch of ports and launches a port corresponding process, the user has a service that will listen to a random port and they wish to address it in a human-readable kind of way.

As far as I know, the hosts file does not afford a port number so a solution would look similar to a proxy on a known port like 443 listening for a particular domain name that hosts routes to localhost and the proxy routes to the service on port whatever. Also need to set up local CA to sign a cert for each of the hostfile domain names. . .

0. https://www.baeldung.com/linux/mapping-hostnames-ports

Isn't this "service discovery", which, at least, apple had 23 years ago "bonjour"? I'm not claiming that stuff like bonjour (I'm referring to the apparently infringing "rendezvous") and upnp did what we're discussing; but you could hack em to do it.

I know I generally use fing in a pinch, or nmap, or ask the DHCP server for all the hostnamr<->ip mappings and then nmap -A - t5 (that's threat level five - the system I use)

Is this thing on

It's amazing to me all of the fancy new ways eventually evolve into the thing they were trying not to be in the first place. We see this time and time again. I've been around long enough to have seen it in several situations to the point that at the start of the trend someone looks like the old dog refusing to learn a new trick, then eventually people realize they could have saved a lot of time/effort/money by taking the old's advice and experience.

I have said it before and I am unsure if I stole it: you can recreate nearly any "service" the web/internet has to offer today with only the RFCs prior to April, 1995, with the caveat that I'm technically fine with HTTP; I haven't given it much thought.

I think it was LogStash or Summit Patchy Project, that let you use IRC as a sync for redirecting logs or making a copy. So I made a PCI compliant logging service, immutable ircd (ro fs) that logged to itself via eggdrop locally. All little cattle VMs would have thier logs sourced and synced via logstash to an IRC channel for the vertical the VM "belonged to". All the irc stuff was on an append-only mount on the ircd server, so if audit just snapshot that mount and hand it over.

NOC was in the channels. I think some teams set up dashboard widgets that triggered on irc events.

All that was a POC done completely to prove that it could be done using only stuff from pre-1996 RFCs. I'm sure the company I built it for went with some vendor product instead and I don't blame them, I wouldn't have maintained that - you ever set up ircd? The volume of traffic just for logs was already fun to deal with.

Pedants: I'm working from 15 year old memories and I changed a few details to protect the innocent. I can't remember the project name other than it was a play on "BI" for business intelligence.

That's a good point. I assumed it being a single local server per app.

Reply on news.ycombinator.com