The reason, I’m sure, is because of my company’s proxy that requires a username and password. The problem is the same on both Windows and Ubuntu. I can access that file through a web browser, since the browser respects the configured https_proxy environment variable. If I change networks to one without a proxy, the launcher goes ahead as normal. Unfortunately I can’t leave it connected to the unsecured network, so even after accepting the EULA etc the launcher is fairly useless.
I have tried using the --proxy-server=username:password@proxy.xxx option on both Windows and Ubuntu, without any luck. The wiki says to leave off the http:// string. It seems like the option might not respect the username:password part? Is there a workaround?
Working solution: I set proxy ONLY with --proxy-server option, disabled any proxy settings in Ubuntu Desktop. Ran the launcher to get past initial accepting EULA. Then terminated app and enabled Ubuntu Desktop proxy, and left --proxy-server option enabled, was able to proceed normally.
So it looks like the launcher might be getting the proxy configuration from both the Ubuntu Desktop network manager and the command line? If I disable the network manager proxy (ensuring http_proxy is blank in terminal) and start the launcher with --proxy-server set, it works. If I put anything in the network manager proxy settings, it will not work, with or without the --proxy-server option.
For the devs, my best guess is that since Ubuntu Desktop’s network manager requires http:// in front of the address, and --proxy-server requires only host and port, there is some kind of mismatch. Please let me know if I can test any other configurations to help solve the issue.
Has there been any update on this? It seems to me like the error is in the string parsing of the --proxy-server parameter. If you launch like this:
--proxy-server=SERVER:PORT
the launcher logs will look like this:
13:48:06.351 › Using proxy server SERVER:PORT for the main process.
and of course fail to authenticate if the proxy server requires authentication. However, if you launch like this:
--proxy-server=USER:PASS@SERVER:PORT
the launcher logs will look like this:
13:48:06.351 › Using proxy server USER:PASS@SERVER for the main process.
See how it simply used the first two strings surrounding the “:” for the server and port? The argument parser needs to split the string on the LAST “:” character (and only on the last “:” character) for the simplest fix, or better yet, properly handle the optional USER:PASS authentication.
Hello @OOYEOO! Can you attach a copy of your logs found here: C:\Users\<USERNAME>\.nvidia-omniverse\logs\launcher It might have some clues that will help us troubleshoot the issue.
It turned out for us that the easiest solution was to set up CNTLM in Ubuntu to handle our company proxy authentication, and then pass the local proxy to the launcher using --proxy-server=127.0.0.1:3128. This works for everything but Isaac Sim, which I’ll make a new post about.
I confirm @OOYEOO 's remark.
It appears that the port gets lost when including the username and password in this form --proxy-server=username:password@server:port
So when I put that I get : Using proxy server username:password@proxy.server.com for the main process.
I have attached an extract of my launcher log with that part where I changed some strings for privacy purposes. launcher_extract.log (5.0 KB)
And when I only put the server and port info without user:password@, I get : Using proxy server proxy.server.com:80 for the main process.
And no errors except aPROXY_AUTH_REQUIRED notification when when trying to connect to https://messages.launcher.omniverse.nvidia.com which is normal I think.
let me know if there is a workaround I can do for now, this issue prevents many of my colleagues from testing omniverse.
Unfortunately it looks like the launcher doesn’t pass the proxy settings to the applications it launches (like Nucleus and Isaac Sim), so even though we handled proxy authentication with CNTLM we’re still stuck when Isaac Sim needs to access resources or when Nucleus mounts the AWS NVIDIA share. We’re looking into using a transparent proxy on our workstations to avoid configuring it in applications altogether.
IMO it would be nice if all of the Omniverse applications would simply respect the http(s)_proxy and no_proxy environment variables - that’s what they’re for.
@michael.s1.ellis I tried your suggestion and did not see any effect.
In my case I am using OV enterprise. I use the corporate proxy to run Launcher and everything seems to work. I can access the amazon aws resources (materials, environments…) when I enter the URL in a browser, where the corporate proxy settings are use by default. Launcher uses the proxy settings, but some of the services are not using the Launcher proxy settings and they get blocked. In the workstation version of OV, there are 7 endpoints (urls) that need to be whitelisted (allow through the firewall). The Enterprise version does not mention needing this whitelisted.
Do the workstation whitelist apply to enterprise? https://docs.omniverse.nvidia.com/prod_launcher/prod_launcher/firewalls.html
That is rather unfortunate, i do not know much about the firewalls applied to the machines i am using, but may still be able to offer suggestions. As much as I would like to use the launcher for everything you may be able to circumvent the issue in the interim by navigating to the app’s install directory and launching the bat/sh with the additional proxy flag directly eg: .\installloation\omni.code.bat --proxy=http://MY-proxy-server.com:80
note the if it has never been launched you should run the warmup bat first.
Also, the issue may be a nucleus authentication issue, i would suggest setting the following environment variables: OMNI_USER and OMNI_PASS.
Great information and suggestions. NVIDIA and my local IT people have been very helpful. I will share what I find out. I am in a very secure environment. It has been a challenge to get the OV and apps approved, then getting a Linux Nucleus Server (with certificates https). Everything is working, but to do demos and easily impress people I would like the have the samples and other resources available.
I will ty both of your suggestions.
I tried the proxy setting on the create bat file. It was informative and interesting to run from the command line. Didn’t help.
Tried the OMNI_USER and OMNI_PASS, using the Nucleus server user and password. Didn’t help.
I think I do have a nucleus authentication issue. When I launch Create the server is available and I can access content on the server.
But, if I click on NUCLEUS tab on the Launcher, I get an error “Something went wrong” and I have to restart. Even though Create has access. This is a different issue and probably my misunderstanding. Sorry if this is getting off topic.
Brad Carvey
My Colleague is also facing the same issue, and the issue is with Privacy.toml, if we update with the below snippet it is getting updated to the fault one
Ugh, proxies can be a real headache. I’ve been down that road. For the username: password hitch, try encoding it (like base64). On Ubuntu, export it as HTTPS_PROXY in the terminal. For Windows, set it in system variables. Worked for me once. Or you can try this Proxy service provider. I hope that helps!