[Feature Request]: Building planet server

f0re1gnKey commented 1 year ago

🚀 Feature Summary

Support planet building

📝 Detailed Description

using mkworld to build planet file, so i can be a private planet root.

https://github.com/kmahyyg/ztncui-aio

🎯 Use Case

No response

💡 Willing to Contribute

Yes, I could help with testing

sinamics commented 1 year ago

Interesting. Im not familiar with planets config, but it seems like a neat feature to build private root. Will look into it when time permits.

sinamics commented 1 year ago

@f0re1gnKey Just pushed version 0.3.3 with mkworld for creating planet file. Check it out and let me know if this worked for you.

Just keep in mind that you will need to remove the :ro from the zerotier volume attached to ztnet, if not you will get an error in UI. should be:

    volumes:
      - zerotier:/var/lib/zerotier-one

f0re1gnKey commented 1 year ago

@f0re1gnKey Just pushed version 0.3.3 with mkworld for creating planet file. Check it out and let me know if this worked for you.

Just keep in mind that you will need to remove the :ro from the zerotier volume attached to ztnet, if not you will get an error in UI. should be:
    volumes:
      - zerotier:/var/lib/zerotier-one

Hi, I have upgraded to the new build, thanks for your contribution.

The UI seems great.

Sometimes we need to custom the planetID and birthID, and re-generate the planet file with new external IP address without changing the secret. It seems the ztnet will change the secret when re-generating?

The external IP address shows to me is wrong, i think it is better to save it to database (configure by user), because complex network is hard to auto configure the external IP address.

sinamics commented 1 year ago

Sometimes we need to custom the planetID and birthID, and re-generate the planet file with new external IP address without changing the secret. It seems the ztnet will change the secret when re-generating?

Understood. I will add these inputs to the user interface.

When you refer to "secrets," I assume you mean the signing keys? They won't be re-generated unless you recreate the container and then recreate the planet file. The signing keys do not reside on the Docker volume.

I plan to make improvements by storing some content in the database to persist the state. Additionally, I'll move the signing keys to a persistent volume and will only re-generate keys if the user requires it. This way, you likely won't need to re-authorize every peer on the network if you just want to change the external IP, etc.

sinamics commented 1 year ago

Furthermore, I'll be adding functionality that allows you to download and upload the config. This should provide greater flexibility and ease in managing your setup.

sinamics commented 1 year ago

can you give sinamics/ztnet:main-0ea2d8c a try. I have added option for editing birth and id. Its now possible to download and upload config file as well. I recommend to use a test server, just in case. I will perform more testing myself, but it would be great if you could give it try too since you are familiar with this config.

f0re1gnKey commented 1 year ago

can you give sinamics/ztnet:main-0ea2d8c a try. I have added option for editing birth and id. Its now possible to download and upload config file as well. I recommend to use a test server, just in case. I will perform more testing myself, but it would be great if you could give it try too since you are familiar with this config.

Hi, thanks for your new version and it is very nice.

The custom planet is working well. I have migrated the production environment for several days and found no error.

In import function, the planet.custom file is unnecessary. It can be regenerated by current.c25519/previous.c25519/mkworld.config.json.

If we change the external ip default port 9993 to custom port(eg. 10000), not only the port need to be changed in planet file but also in zerotier-one local.json. The local.json should add [primaryPort: 10000]. I think it is very difficult to manage local.json in UI because it has too many options, so it will be better to write a text in UI warning people modify their zerotier-one local.json when they are not using default port 9993.

{
    "settings": {
        "primaryPort": 10000,
        "softwareUpdate": "disable",
        "allowManagementFrom": [
            "x.x.x.x/x"
        ]
    }
}

It will be better if ztnet provide a link to download the custom planet file. It is useful when using script to setup a new zerotier client. eg. when i setting up a new client and need my custom planet file, use wget -O /var/lib/zerotier-one/planet http://ztnet.example.com/planet

sinamics commented 1 year ago

Thank you for the feedback.

In import function, the planet.custom file is unnecessary. It can be regenerated by current.c25519/previous.c25519/mkworld.config.json.

You dont need to upload the planet.custom file. It will be re-generated based on the mkworld.config.json and the current.c25519 & previous.c25519 if they exist. The only "required" file is the json file.

it will be better to write a text in UI warning people modify their zerotier-one local.json when they are not using default port 9993.

Thank you for that information, i will add a note if users change the port number.

It will be better if ztnet provide a link to download the custom planet file. It is useful when using script to setup a new zerotier client.

Sure. Will be added. :)

sinamics / ztnet