Wingetty over Dns record

[BouuuuuuH]

Hello,

We just have a fresh install of wingetty, this seems cool. We have configured nginx as reverse proxy and we can now add our source on winget client. Our wingetty is on a specific computer over our DNS, the computer name is “repository”. To use https we are using our wildcard certificate (like *.contoso.com) and register the computer with a dns record (repository.contoso.com). So, we can add our source like that: “winget source add -n WinGetty -t "Microsoft.Rest" -a https://repository.contoso.com /wg/” Everything works fine, and source can be list:

And my package for the test can be “search”

But when I want to install it:

As you can see on the screen capture, the URL returned is not the good one, and we cannot download. The process stays stuck at this point. We assume that is normal, because wingetty cannot know our dns record, but do you have a setting to set this information, to fix download part? To be clear if, with my browser, I go to https://repository.contoso.com/api/download/Publisher.TestPackage/1.1/x86/user download start and succeed.

Thanks a lot, Thomas.

[thilojaeggi]

So I've just read up on this. This could be due to a misconfigured reverse proxy but mitht be fixable by setting WINGETTY_SERVER_NAME with the domain including the port, so 443.

Also, on the Setup page is the setup url correct including port or does it reference 8080 as well?

If that doesn't work try adding the following property to the nginx proxy configuration: proxy_set_header Host $host;

[BouuuuuuH]

Thanks for your quick answer,

"Also, on the Setup page is the setup url correct including port or does it reference 8080 as well?"

Setup page give us an url with :8080 yes, and I had to change with our .contoso.com to the winget client

About reverse proxy, we don't really know nginx and as you said it is probably a misconfiguration. Do you have nginx.conf sample ?

We also tried setting WINGETTY_SERVER_NAME with our "repository.contoso.com" and this block everything :

proxy_set_header does not change anything.

[thilojaeggi]

Sure, although this one is generated by Nginx proxy manager: I assume server_name is of importance.

# ------------------------------------------------------------
# wingetty.thilojaeggi.ch
# ------------------------------------------------------------

server {
  set $forward_scheme http;
  set $server         "10.10.1.175";
  set $port           8080;

  listen 80;
listen [::]:80;

listen 443 ssl http2;
listen [::]:443 ssl http2;

  server_name wingetty.thilojaeggi.ch;

  # Let's Encrypt SSL
  include /etc/nginx/conf.d/include/letsencrypt-acme-challenge.conf;
  include /etc/nginx/conf.d/include/ssl-ciphers.conf;
  ssl_certificate /etc/letsencrypt/live/npm-3/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/npm-3/privkey.pem;

  # Block Exploits
  include /etc/nginx/conf.d/include/block-exploits.conf;

  # HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
  add_header Strict-Transport-Security "max-age=63072000; preload" always;

    # Force SSL
    include /etc/nginx/conf.d/include/force-ssl.conf;

  access_log /data/logs/proxy-host-2_access.log proxy;
  error_log /data/logs/proxy-host-2_error.log warn;

proxy_set_header X-Scheme "https";

  location / {

  # HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
  add_header Strict-Transport-Security "max-age=63072000; preload" always;

    # Proxy!
    add_header       X-Served-By $host;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto  $scheme;
    proxy_set_header X-Forwarded-For    $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP          $remote_addr;
    proxy_pass       $forward_scheme://$server:$port$request_uri;
  }

  # Custom
  include /data/nginx/custom/server_proxy[.]conf;
}

[BouuuuuuH]

Thanks for you .conf file, it works pretty fine with it. We can add source, install package, and all of that using https.

Just one point is not working on https, and not a big deal for us, we cannot add package on https, only using http://repository:8080 web interface. Is that a known problem ? or again a missconfiguration on our side ?

[thilojaeggi]

That's quite a weird issue, any error output when that happens in the browser console or in the container? Also, if it's of type ('inno', 'inno'), ('nullsoft', 'nullsoft'), ('wix', 'wix'), ('burn', 'burn'), ('pwa', 'pwa'), ('msstore', 'msstore') it won't work in the current release due to a bug which is solved in the next version which will be published soon

[BouuuuuuH]

Right, console talks about "413 (Payload too large)" so I increase client_max_body_size on nginx.conf

Everything is working now. Thanks a lot for your time.