Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can I use this with the Linux package? #37

Open
qrkourier opened this issue May 14, 2024 · 2 comments
Open

can I use this with the Linux package? #37

qrkourier opened this issue May 14, 2024 · 2 comments

Comments

@qrkourier
Copy link
Member

I see this tool can install ziti and create the service unit. If I install the Linux package, then those are already managed by the package.

I see the --skipSystemd flag now, so that should protect the service unit.

What about the binary? I want to ensure the version of ziti that was installed by the package manager is used by the service, so is there a way to disable handle_ziti_install()?

If I can disable installing ziti and the service unit this might still be useful for generating a config with --installDir /var/lib/ziti-router to place the config in the service's working dir.

@emoscardini
Copy link
Member

emoscardini commented May 14, 2024

I was under the impression the Linux package would take over all the functions of this script, so we could deprecate this script. Are you thinking otherwise now? I can certainly update it as suggested above by adding a --skipBinaryInstall or some other argument.

We could also enhance it to install via the deb package/repo instead of downloading the binaries directly & even add the repo if it doesn't already exist locally.

@qrkourier
Copy link
Member Author

I'd prefer to keep enhancing the ziti create config router generator to support common use cases, but I don't know how flexible/powerful this auto-enroll tool is in comparison. I think it's covering at least a few bases that the built-in config generator is not.

If the gap is huge between what ziti create config router can do and what auto enroll can do, then it probably makes sense to modify auto enroll so it can serve as an alternative means of generating a config for the router service provided by the Linux package.

hypothetical 1 - alternative config generator for the Linux package

sudo dnf install openziti-router </dev/null
sudo ./ziti_router_auto_enroll.py --skipBinaryInstall --skipSystemd --installDir /var/lib/ziti-router
sudo systemctl enable --now ziti-router.service

hypothetical 2 - converge the features of both config generators

  1. figure out what does auto enroll do that ziti create config router doesn't
  2. sanity check: is this a common use case? proceed if "yes"
  3. implement in ziti create config router

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants