Hey Guys
Today I'm bringing a tool for you guys, mount servers with old phones Or have servers in your phone for testing.
Tool: Servers Ultimate Pro
Web:: https://icecoldapps.com/app/...

Note1.: Doesn't handle well above android 6+, So test one of the free servers you're intending to use before buying.

Note2.: This App costs around 10€/$ but you can get single App servers for free (I think even html + php + mysql package for free).

Not promotional, I'm just a user that loves this App.
I already talked about this a few times (usually I just call the cell phone I'm using my web server), but as a noob I don't even knot the possibilities.

This App comes with more then 70 protocols (60+ servers and a mix of servers).
From ssh, ftp, html (nginx, lightppd, Apache, simple) with php and mysql, Webdav...

<quote>

Run over 60 servers with over 70 protocols!

Now you can run a CVS, DC Hub, DHCP, UPnP, DNS, Dynamic DNS, eDonkey, Email (POP3 / SMTP), FTP Proxy, FTP, FTPS, Flash Policy, Git, Gopher, HTTP Snoop, ICAP, IRC Bot, IRC, ISCSI, Icecast, LPD, Load Balancer, MQTT, Memcached, MongoDB, MySQL, NFS, NTP, NZB Client, Napster, PHP and Lighttpd, PXE, Port Forwarder, Proxy, RTMP, Remote Control, Rsync, SMB/CIFS, SMPP, SMS, Socks, SFTP, SSH, Server Monitor, Stomp, Styx, Syslog, TFTP, Telnet, Test, Time, Torrent Client, Torrent Tracker, Trigger, UPnP Port Mapper, VNC, Wake On Lan, Web, WebDAV, WebSocket, X11 and/or XMPP server!

</quote>

Dear Lord, please stop people from enforcing standards and bypassing them themselves.

Take kubernetes for example. Since v1.24 CRI has been announced as the standard, and kubernetes is shifting to live by it.

But it's not.

Yes, it's got the CRI spec defined and the unix://cri.sock used for that standardised communication. What nobody's telling you, is that that socket MUST be on the same runtime as the kube. I.e. you can't simply spin up a dockerd/containerd/cri-o server and share its CRI socket via CIFS/NFS/etc. Because kube-cp will assume that contained is running on the same host as cp and will try to access its services via localhost.

So effectively you feed the container via a socket to another machine, it spins up the container and that container tries to
- bind to your local machine's IP (not the one's the container is running on)
- access its dependencies via localhost:port, while they are actually running on your local machine (not the CRI host)

I HOPE this will change some day. And we'll have a clear cut between dependencies and dependents, separated by a single communications channel - a single unix socket. That'd be a solution I'd really enjoy working with. NOT the ip-port-connect-bind spaghetti we have now.