Do I need to create a `ziti` user on debian?

Hello again. During the install of the tunneler program on a debian12 system, the instructions include the example below. The command sudo -u ziti is assuming a user named ziti exists. There isn’t a reference to creating this user.

Is this necessary? Does there need to be a ziti user or service account. Or, can it run as another privileged or non-privileged user?

I ran it as root, and I got a green dot for API connection, but not for edge-router connected.

I expected user ziti to be created by the Debian install package. Did you use the apt install method?

I did, and it was. I wonder why it failed. Perhaps I need to chown the jwt, or chmod it?

EDIT: I figured it out. it was my method of copying and pasting. In the end, I had to hit enter before pressing ctrl+d to exit out of the echo command.

That copy and paste method is not very intuitive. And it obscures what is happening, making you figure out what is going on by taking the command apart. Instead, it would be nice to say where the file needs to go, and what the permissions/ownership should be.

Just my $.02

1 Like

Thanks for that feedback! How about this?

sudo -u ziti vi /opt/openziti/etc/identities/ziti-id.jwt
# paste the contents of the enrollment token JWT on a single line, save, and exit

I’m putting my documentation critique hat on; this isn’t me being a jerk, lol.

That’s a bit easier, for sure. But then you contend with someone people who don’t know how to exit vim, lol.

But, again, if you already have terminal access, why can’t you just scp the file? It gives me the impression that you intend to obscure what is actually happening. Why take a lesser known path of doing sudo -u ziti ... when a well understood scp file user@source:~/file then chown ziti:ziti file && cp file /path/to/newfile would be instantly recognizable even to noobs. I have been doing this 20 yrs and didn’t recognize the significance of the sudo -u ziti. Instead I thought I understood the expected result and plowed ahead.

I totally get the challenges. As an engineer there are shortcuts and methods I take all the time that would look like magic to someone less experienced. This is why documentation needs to be clear and without assumptions. If you haven’t read it, the Divio documentation standard is extremely useful in helping a doc writer separate the concepts of how-tos, tutorials, and references into appropriate compartments and not to mix them.

Thanks for taking the time. I welcome the ideas and resources and edits! Maybe we’re being too prescriptive with this particular task of placing the enrollment token in the identities dir. You’re right. We’re not aiming to obscure the steps, and they should be plain, if they need to be stated at all.

I’ll change it like this: "Place the token in this location. Make sure it’s owned and readable by user “ziti, e.g., sudo chown ziti JWT; sudo chmod u+r JWT.”

I avoided prescribing scp because the dest dir could be local or remote, and I recall that the dir containing the token JWT file must be writeable so the systemd service’s startup script can delete it after successful enrollment.

edit: correct filemode bits

edit2: clarify the token dir must allow write so that user ziti can delete the token file

Haha... see there, my own bias came out on that. You are right, it isn't necessary to the end goal. I am very impressed at your willingness to consider feedback. That's a good trait in an open-source project!

1 Like