zcli login -i / profiles doesn't work on WSL v2 @ Windows

[joelhellman]

Expectations

Basic command zcli login -i works on modern Ubuntu on WSL2 @ Windows

• The new zat tool runs on node, so I was hoping it was more painless to set up the developer environment this time.
• Many windows developers run Ubuntu and other linux distros using WSL2 these days.
• Profiles are nice, I manage a few support accounts and typically push apps to all of them

Reality

There is some dependencies for the keystore (keytar?) that doesn't play with WSL2 on Windows, and it seems a display manager is also expected for this CLI tool (why?). So it didn't work on my WSL2 setup.

It seemed the only solution was to install some version of X11 on WSL2, I gave up on it, and had to use my own script for profile switching. Right now it's profiles, I assume the keystore could be used to store other things in the future as well.

Please test the tool on WSL2 in the future, many developers running Windows have switched to it. It should be easy to develop Zendesk apps.

After npm install @zendesk/zcli -g running zcli login -i gave me:

error /home/myuser/.local/share/zcli/node_modules/keytar: Command failed

$ zcli login -i
error /home/myuser/.local/share/zcli/node_modules/keytar: Command failed.
Exit code: 1
Command: prebuild-install || node-gyp rebuild
Arguments:
Directory: /home/myuser/.local/share/zcli/node_modules/keytar
Output:
prebuild-install WARN install libsecret-1.so.0: cannot open shared object file: No such file or directory
gyp info it worked if it ends with ok
gyp info using node-gyp@7.1.2
gyp info using node@14.17.0 | linux | x64
gyp info find Python using Python version 3.8.5 found at "/usr/bin/python3"
gyp info spawn /usr/bin/python3
gyp info spawn args [
gyp info spawn args   '/home/myuser/.nvm/versions/node/v14.17.0/lib/node_modules/npm/node_modules/node-gyp/gyp/gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make',
gyp info spawn args   '-I',
gyp info spawn args   '/home/myuser/.local/share/zcli/node_modules/keytar/build/config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/home/myuser/.nvm/versions/node/v14.17.0/lib/node_modules/npm/node_modules/node-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/home/myuser/.cache/node-gyp/14.17.0/include/node/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=/home/myuser/.cache/node-gyp/14.17.0',
gyp info spawn args   '-Dnode_gyp_dir=/home/myuser/.nvm/versions/node/v14.17.0/lib/node_modules/npm/node_modules/node-gyp',
gyp info spawn args   '-Dnode_lib_file=/home/myuser/.cache/node-gyp/14.17.0/<(target_arch)/node.lib',
gyp info spawn args   '-Dmodule_root_dir=/home/myuser/.local/share/zcli/node_modules/keytar',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
Package libsecret-1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libsecret-1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libsecret-1' found
gyp: Call to 'pkg-config --cflags libsecret-1' returned exit status 1 while in binding.gyp. while trying to load binding.gyp
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/home/myuser/.nvm/versions/node/v14.17.0/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:351:16)
gyp ERR! stack     at ChildProcess.emit (events.js:376:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:277:12)
gyp ERR! System Linux 5.4.72-microsoft-standard-WSL2
gyp ERR! command "/home/myuser/.nvm/versions/node/v14.17.0/bin/node" "/home/myuser/.nvm/versions/node/v14.17.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/myuser/.local/share/zcli/node_modules/keytar
gyp ERR! node -v v14.17.0
gyp ERR! node-gyp -v v7.1.2
gyp ERR! not ok
Failed to load secure credentials store: use environment variables to log in.
You can use credentials stored in environment variables:

# OPTION 1 (recommended)
ZENDESK_SUBDOMAIN = your account subdomain
ZENDESK_EMAIL = your account email
ZENDESK_API_TOKEN = your account api token see https://{subdomain}.zendesk.com/agent/admin/api/settings

# OPTION 2
ZENDESK_SUBDOMAIN = your account subdomain
ZENDESK_EMAIL = your account email
ZENDESK_PASSWORD = your account password

Once these environment variables are set, zcli profile is not required for authentication and will be ignored.

I decided to installed the libsecret dependency (apt install libsecret-1-dev on my WSL2 distro), and re-ran zcli login -i.

Then I ended up with the error Cannot autolaunch D-Bus without X11 $DISPLAY, after successfully authenticating:

$ zcli login -i
Subdomain: mysubdomain
Email: myname@example.com
Password: ********************
    Error: Cannot autolaunch D-Bus without X11 $DISPLAY

From that point I tried various things without installing a whole X11 setup on my WSL2 setup, but I gave up.

Steps to Reproduce

1. Windows running Ubuntu on WSL2, node installed
2. npm install @zendesk/zcli -g
3. zcli login -i
4. complete authentication steps
5. expected: Error: Cannot autolaunch D-Bus without X11 $DISPLAY

Issue details

Command: zcli login -i
Version: @zendesk/zcli/1.0.0-beta.8 wsl-x64 node-v14.17.0
OS: Ubuntu-20.04 on WSL v2 on Windows

[eric-at-nocoast]

Hey Joel,

Just letting you know that I've seen this and will speaking with the appropriate team about it. In regards to your question " it seems a display manager is also expected for this CLI tool (why?)" - a Display Manager is another name for a login manager, when utilizing multiple profiles this is needed to manage / track these profiles.

[joelhellman]

Yeah, I run Windows on my work laptop, and as many developers on Windows I have migrated to WSL2, which makes it really neat to work in an environment that is very close to linux. But WSL2 doesn't come with a login mechanism.

Try googling how to get a login screen to work on WSL2 for windows and you will find many frustrated users.

I feel that the mechanism currently used by zcli to provide the secure cache for the profile feature will therefore not work for the majority of developers using WSL2 on Windows, i.e. a significant portion of windows devs.

As many devs that have used WSL2, I really don't want to go back to use nodejs on my windows host, I wouldn't switch back to windows to run zcli either.

Now I understand you can still use zcli without the profile feature (I have custom scripts to swap in my different environments and cred stores using ZAT). But if you could take a look at the technology choice here and see if you could find any way to offer this functionality so devs running windows/WSL2 could leverage the very useful profiles, it would be really appreciated.

Otherwise I'll have to setup new custom scripts for zcli to provide the profiles functionality, and I would love to just run the zcli provided by you guys without that hazzle. Thanks.

[dan-cummings1]

Bump. Wondering if there was any progress made on this issue?

[zach-anthony]

Hi @joelhellman as you've probably seen, getting access to the default credential store on WSL is quite difficult and this is an issue flagged with Microsoft themselves on the WSL project.

From what I've understood this is because the credential store (gnome-keyring) requires DBus APIs to communicate. DBus itself requires Linux's windowing manager (X11) to automatically start, which doesn't work on Ubuntu on WSL because there is no UI. Typically, to unlock the Keyring in Ubuntu there is a prompt in the GUI. There is a number of workarounds for this, but they are quite convoluted including:

• Manually starting a DBus session and unlocking the Gnome keyring with a password supplied via STDIN
• Using X11 forwarding to be able to enable the Gnome keyring prompt to display

I understand that neither of these workarounds are particularly friendly, however directly integrating with an alternative credential store for WSL users would still require a reasonable amount of system configuration as you would need to install OS level packages for whatever store we chose.

However, it does look like this issue may be solved when Microsoft releases support for running Linux GUI applications on WSL which is currently in preview.

In the meantime, while we won't discount exploring alternative solutions for the profiles feature on WSL, I would recommend that exploring one of the workarounds or sticking with your custom scripts is probably the best option.

[joelhellman]

@zach-anthony thanks for engaging. I understand that decision and I think that's fair given the upcoming support for GUI apps on WSL2.

I think the GA + real-life availability for WSL GUI is some time away for most business users (since it requires a new windows update, right now the preview requires windows 11), so probably this warrants a mention to WSL2 users on Windows in the docs. I'll make a pull request to have it added to the README.