Does this support starting a webdav server over an ssh tunnel to remote server? It looks like it from the readme, will attempt asap.
Ok, checked it out, dufs is a cool tool. Definitely replaces python -m http.server. This is a new standard rightalong side ripgrep.
Cargo is the package manager that pip wanted to be. We should just use cargo anyway. Why have distros when you have Cargo? Why have homebrew when you have Cargo?
I looked at the Bashbro source and said NOPE. And I've written a lot of increasingly complex Bash. At some point you just have to realize that you're using the wrong tool for the job. Dufs even has tests!
Ultimately, this is a toy, but it can be handy. I originally made it to attempt using for serving config for networked debian unattended installations[1] while automating VM creation, but never went that far.
For Bash with `--enable-net-redirections` set at configure time (not a default, not enabled on popular distros to my knowledge), `/dev/{udp,tcp}/$host/$port` is available for this purpose.
You can consider the use of Unix sockets (sockets as named files). There are lots of limitations but the most pervasive and frustrating of those is the general lack of support for them across apps.
You could set up Nginx and some local subdomains to reverse proxy to the intended applications, regardless of whether they're hosted on Unix sockets or plain ports, if that makes accessing them easier. It definitely makes them easier to make accessible outside of the local machine.
As for using Nginx, you should be able to install Nginx and enable its service and in that way immediately get a local HTTP server. You can then edit the config such that requests for the Host `myfiles.localhost` are `proxy_pass ...` to your bashbro server. Then `http://myfiles.localhost` in your browser should just work.
Ok, I appreciate your suggestions. But now I'm thinking about some utility where you can say:
run-http-service myfiles bashbro -s -p PORT
And then it would just allocate a new port (clash-free), invoke bashbro with the given flags and substitute PORT by the newly allocated port number, and such that it uses myfiles.localhost as the domain. And when bashbro exits, the port number is garbage collected. Somehow, it feels like this should already exist ...
Perhaps it would be enough to have a folder in your Nginx config that is imported by glob, and to have the port number and service name in the filename of each file in the folder. The contents might be templated out from some template (`envsubst` and `sed` are probably acceptable ways to fill the template). To allocate a service is to check if it's already allocated, then find the greatest port number in use and add 1 (the filesystem can help you with this if you name the files appropriately), then check to make sure nothing else is already listening, then write the config file and restart Nginx.
I would not bother with service management to the extent that you are checking to see if the process is still running. Maybe garbage collection is worth doing, you could do it in a single run of `lsof` (the temptation to do it with multiple should be resisted).
I think this does not exist because stuff like foreman/overmind have their own method for allocating ports per-project (add 100 for each line in the config file, set the PORT env var to that) as would any sort of production-ready solution.
But it is a fun idea. And perhaps it should exist.
No way to allocate port numbers without clashes ever. What I do is having a Ports.md in my personal knowledge base with all port assignments in my personal projects and networks: port, description, project link and/or service host:port. This works very well, I don’t have tens of thousands of projects so I’m not going to exhaust port numbers. I used to try to use Unix domain sockets as much as possible for anything fronted by nginx, but stopped bothering with that since I started centrally maintaining port assignment.
You can listen on an anonymous port. It's similar to how the kernel allocates a port for outgoing connections. It's very useful if you want to listen ephemerally, especially in tests. The downside is that you need your server to report which port it's actually listening on, and if it restarts, it will get a different port.
If you can ssh to the remote, you can simply use Emacs (dired and trump). I suppose the advantage here is that once you turn a machine into a file server you can access it from other devices.
https://github.com/sigoden/dufs