I am working through the following command to understand what each specific element does
ziti edge create config "${service_name}"-host.v1 host.v1
so I ran ziti edge create config to get the help
ziti edge create config [JSON configuration data] [flags]
This raised an interesting question.. as "host.v1" is a type.. but I am not sure what this means..
Any tips?
I am assuming this is some type of configuration.. where this is a predefined type.. though I am unsure if there is a v2.. vn..
PS.. I have also noticed something.. when I compare the cheat sheet against what I did in my initial attempt
When I setup the reflect exercise.. I use the following to create the service
ziti edge create service reflect
And.. when I created the Bind.. I used the "#all" flag
ziti edge create service-policy allbind Bind --service-roles "#all" --identity-roles "#all"
So.. I am assuming that "all" is a special preset configuration...
In contrast.. I am now using the parameterised format that is included in the cheat sheet
ziti edge create service "${service_name}" --configs "${service_name}"-client-config,"${service_name}"-host.v1
ziti edge create service-policy "${service_name}"-binding Bind --service-roles '@'"${service_name}" --identity-roles '#'"${service_name}"'ServerEndpoints'
In these cases.. you specify the specific service name that you created with a @
On another note.. I do remember watching a OpenZiti TV session.. where # tags were being used instead of specific service names using @
So.. it would be also interesting to know more about how tags can be used in different scenarios..
is there a specific way to create preset tags?.. like there appears to be a default for #all?
Ahh… I also just noticed that the config is used when you create a service bind / dial
I missed this when doing by reflect example… because I used the default all settings
Making more sense now
we don't seem to have the built-in config types documented well yet (or at all). every service can have 0-n configs associated with it. These configs are used by 'sdk applications' to do interesting things. our tunneling apps are "sdk apps" (of course). Since OpenZIti wants to provide these tunneling apps - we also invented and distribute 5 types of configs with the base install. There are two different types - the "host side" (where data leaves the ziti overlay) and the "client side" - where data gets onboarded to the overlay...
There are two 'client' related config types that are associated with intercepting packets: ziti-tunneler-client.v1, intercept.v1.
There are three 'host' related config types:ziti-tunneler-host.v1, host.v1, host.v2
To use a tunneling app - like the ziti desktop edges you need these configs on the service. that's why you see them both in the cheatsheet.
If you are writing you OWN app (like the reflect example) you don't need any configs (and thus you don't need them for the reflect example)
ok.. a few more clogs are clicking into place.
now I see what this does.. it sets up the configuration for the listener on the edge router.. ?? .. which is used for the Server endpoint
In this specific example.. its assuming a localhost.. but if you have installed the QuickInstall on a remote machine.. you need to replace this with $(hostname)
ziti edge create config "${service_name}"-host.v1 host.v1 '{"protocol":"tcp", "address":"localhost","port":'"${the_port}"', "listenOptions": {"bindUsingEdgeIdentity":true}}'
Then.. in my case.. I am setting up an edge client that I will run from my mobile.. so I need an intercept for this..
ziti edge create config "${service_name}"-client-config intercept.v1 '{"protocols":["tcp"],"addresses":["'"${service_name}.ziti"'"], "portRanges":[{"low":'"${the_port}"', "high":'"${the_port}"'}]}'
In this command.. there is the use of intercept.v1 which I imagine is indicating the version of OpenZiti
The command also includes creates a .ziti extension to the service name..
I understand that this is the name that will appear on the MobileZitiEdge app that I have installed on my mobile.. which could be called anything.
the example is for zssh - so you can definitely use localhost. you don't need to use the hostname. the host.v1 config is informing the tunneling app to send traffic to "localhost:22" (sshd). You could choose to use ziti like an ssh bashtion if you wanted to - and choose to send the data to some OTHER machine than localhost - however usually it's better to not trust your network. Trusting the local host os is better for sure and that means only using 'localhost' which will resolve to your loopback ip.
I think it'd be easier if you describe the solution you're trying to implement with ziti. Then I could recommend some commands to work from. It'll be easier to have a shared, common vision. That'd help me help you better. Would you mind making one new post that outlines what you're trying to do and we can try to keep these conversations more narrow? I think it'd help both of us - you to understand and me to give you better, and more targetted advice.
I do have to say your questions are very good and it's impressive how much you're picking up!