Integrate zsocks

[iwanbk]

Is your feature request related to a problem? Please describe

Give ability for the users to connect to the internet through SOCKS5 proxy

Describe the solution you'd like

By using zsocks as the proxy, which is based on fast-socks5 (https://github.com/dizda/fast-socks5)

The rough plan:

• understanding zos network subsystem and mycelium in zos
• playing with fast-socks5, maybe on zos as well
• plan and implement the proper solution

Detailed plan (WIP):

• [ ] understanding zos, mainly the network subsystem
• [x] create the socks5 server (initial version done at https://github.com/iwanbk/zsocks)
• [ ] investigate error logs from our simple test at https://gist.github.com/iwanbk/d1f0d76305070f00509e8aee05ff4ed9#file-fast-sock5-error
• [ ] upload zsocks binary on github release to zsocks repo assets
• [ ] add zsocks to flists
• [ ] add zsocks to network subsystem of zos as optional service

[xmonader]

Please don't start working on anything before planning these tickets

[iwanbk]

Please don't start working on anything before planning these tickets

if what you mean by "working" is coding, then sure.

[muhamadazmy]

Here is my 2 cents on this issue:

• ZOS is built to only provide generic "primitives" that can be used to run applications on the grid.
• ZOS should not provide everything for the user, but a general purpose small modules to build and run apps.
• For this feature, ZOS doesn't not need or care what apps are running in VMs/Containers, since this is only coming from flists.
• This mean, a user can simply run an app that is basically a SOCKS5 server in one VM that is running in the target country (Say Belgium) since the user built the app, he can pre configure the flist, or make it configurable.
• The user then can connect and use his socks5 server, either over WG, Mycelium, or Public Ip based on his VM configuration.
• It can also be used by other VMs in his network that runs in other locations in the world.

The point is: ZOS doesn't need to change to support this, this is all supported by current primitives. Adding a new workload type or primitive for each feature will just make the code unmanageable and unnecessary complicated

[iwanbk]

ZOS doesn't need to change to support this, this is all supported by current primitives. Adding a new workload type or primitive for each feature will just make the code unmanageable and unnecessary complicated

Thanks for the input. I think it is similar with what @xmonader said in the Telegram.

So, what steps need to be done @muhamadazmy @xmonader ?

• create zsocks repo with binary uploaded every release
• how to upload it to flists? My initial plan was to add script to bins package of zos, but i think there is other way?

[muhamadazmy]

We use some github actions to automatically create flists for applications. You can check the zos github worklflows for inspiration.

Simply your github action first build your binary(s) then the flist action that packs it and upload it to the hub. Simple as that.

Once it's on the hub, it can be used to create workloads on the grid.

[muhamadazmy]

check docs for action here

https://github.com/threefoldtech/publish-flist

[iwanbk]

Once it's on the hub, it can be used to create workloads on the grid.

where i can find the docs to create the workload?

[xmonader]

https://manual.grid.tf/documentation/developers/javascript/grid3_javascript_vm.html

https://manual.grid.tf/documentation/developers/go/grid3_go_vm.html

[xmonader]

Closing this as it's beyond the scope of zos