Posts made by viceice

@carl-westman_8110 said in Getting 500, "Could not find stored procedure 'Security_GetRoles', but /health show no errors:

Unhandled exception

i don't see those, only the XX000: cache lookup failed for type exceptions

it returns code 200, so i assume yes

I same problem but a different error:

2025-09-19T11:31:52.055874602+02:00 info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
2025-09-19T11:31:52.055917374+02:00       Request starting HTTP/1.1 GET http://proget.xxx.de/ - - -
2025-09-19T11:31:52.058745038+02:00 An error occurred in the web application: XX000: cache lookup failed for type 641322
2025-09-19T11:31:52.110076806+02:00 info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
2025-09-19T11:31:52.110107728+02:00       Request finished HTTP/1.1 GET http://proget.xxx.de/ - 500 0 - 54.3259ms

2025-09-19T11:30:23.356843497+02:00 Running Connector Cache Check...
2025-09-19T11:30:23.369384274+02:00 Getting list of connector responses...
2025-09-19T11:30:23.381026135+02:00 Unhandled exception: XX000: cache lookup failed for type 641314

Downgrading to 25.0.9 doesn't help. I recently migrated to integrated PostgreSQL.

This is the error i get:

"options": {
      "headers": {
        "user-agent": "Renovate Bot (GitHub App 2740)",
        "accept-encoding": "gzip, deflate",
        "authorization": "***********",
        "accept": "application/json"
      },
      "url": "https://proget.inedo.com/v2/productimages/inedo/proget/tags/list?n=10000",
      "username": "",
      "password": "",
      "method": "GET",
      "http2": false
    },
    "response": {
      "statusCode": 500,
      "statusMessage": "Internal Server Error",
      "body": null,
      "headers": {
        "cache-control": "public, max-age=300",
        "content-type": "application/json; charset=utf-8",
        "content-encoding": "gzip",
        "vary": "Authorization",
        "server": "Microsoft-IIS/10.0",
        "x-proget-version": "5.3.27.18",
        "docker-distribution-api-version": "registry/2.0",
        "x-aspnet-version": "4.0.30319",
        "x-powered-by": "ASP.NET",
        "date": "Wed, 21 Apr 2021 05:57:33 GMT",
        "connection": "close",
        "content-length": "84"
      },
      "httpVersion": "1.1"
    }
  }

Seeing 500 on https://proget.inedo.com/containers/registry?feedId=22.

Maybe that is related?

I know, i saw that difference. Just wanted to inform you

It's now always dooing upgrade

ProGet version is 5.3.24.7.
Current DB schema version is 5.3.24.
Executing untracked script DDL-DML/0000. Untracked/10. Block 5.3 Upgrades.sql...
Executing untracked script DDL-DML/0000. Untracked/10. Block SQL Server 2005.sql...
Tracked script DDL-DML/v1-3/0002. 0.1.0/10 SET DATABASE PROPERTIES.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/20 CREATE TYPES.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/21 CREATE ROLE ProGetUser_Role.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30 CREATE TABLE Configuration.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30 CREATE TABLE Environments.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30CTC1 CREATE TABLE Connectors.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30CTC2 CREATE TABLE ConnectorFilters.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30EVT1 CREATE TABLE EventTypes.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30EVT2 CREATE TABLE EventTypeDetails.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30EVT3 CREATE TABLE EventOccurences.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30EVT4 CREATE TABLE EventOccurenceDetails.sql has already been executed; skipping...
Tracked script DDL-DML/v1-3/0002. 0.1.0/30USR1 CREATE TABLE Groups.sql has already been executed; skipping...

It should skip updates update at all if already uptodate, otherwise startup will be very slow

@viceice said in [ProGet] Manual database upgrade (docker, kubernetes):

upgradedb

needs to be ProGet.Service upgradedb. fixed it in my pr

getting this when trying to run upgrade command

For help on a specific command, type: ProGet.Service help [command]
To run interactively, type: ProGet.Service interactive
Invalid command: upgrade

ProGet.Service 5.3.24.7
Usage: ProGet.Service [command]

Commands:
run Runs the ProGet service and/or the ProGet web server interactively.
install Installs the ProGet service as a Windows service.
uninstall Uninstalls the ProGet Windows service.
resetadminpassword Switches to the built-in user directory and changes the Admin account password to "Admin".
upgradedb Upgrades the database schema version to this version of ProGet.

For help on a specific command, type: ProGet.Service help [command]
To run interactively, type: ProGet.Service interactive

https://github.com/Inedo/inedo-docs/pull/223

The issue is closed, so can i implement it to my kubernetes deployment?

ok, database upgrade command can be run in init_container (wicch can be without any probes)

here a new sample:

kind: StatefulSet
apiVersion: apps/v1
metadata:
  name: proget
  namespace: services
  labels:
    app: proget
spec:
  replicas: 1
  selector:
    matchLabels:
      app: proget
  template:
    metadata:
      labels:
        app: proget
    spec:
      volumes:
        - name: packages
          emptyDir: {} # should be pvc
        - name: extensions
          emptyDir: {} # should be pvc
      init_container:
        - name: upgrade-db
          image: 'ghcr.io/visualon/proget:5.3.21'
          command: ["/usr/local/proget/service/ProGet.Service.exe", "upgrade"] # Updates the database if required
          env:
            - name: SQL_CONNECTION_STRING
              value: Data Source=proget-sql; Initial Catalog=ProGet; User ID=sa; Password=<YourStrong!Passw0rd> # should be come from secret
          volumeMounts:
            - name: packages
              mountPath: /var/proget/packages
            - name: extensions
              mountPath: /var/proget/extensions
      containers:
        - name: proget
          image: 'ghcr.io/visualon/proget:5.3.21'
          ports:
            - containerPort: 80
              protocol: TCP
          env:
            - name: SQL_CONNECTION_STRING
              value: Data Source=proget-sql; Initial Catalog=ProGet; User ID=sa; Password=<YourStrong!Passw0rd> # should be come from secret
          volumeMounts:
            - name: packages
              mountPath: /var/proget/packages
            - name: extensions
              mountPath: /var/proget/extensions
          livenessProbe: # additional startupProbe and readyness probes are available
            httpGet:
              path: /log-in
              port: 80
            initialDelaySeconds: 15
            periodSeconds: 5
  serviceName: proget

This will call the database update command with an init container which has no timeouts. After that is done (exit code zero), kubernetes will start the normal container(s) which can skip upgrade, as it's aready done.

So an proget upgrade would simply be an image update

probes: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes

So the init container runs before the normal proget container.

Normally the proget container gets some startup and liveness probes, if they fail proget will be restartet.

So if i upgrade the image and a database update is needed, this would currently trap theed by the probes and i get an endless restart loop.

Of cause i can extend the startup probes timeout, but that would cause a lot of failues in kubernetes logs.

It would be nice, if there is a possibillity to check the version and only run the update if the version doesn't match.

here a simplified stateful set:

kind: StatefulSet
apiVersion: apps/v1
metadata:
  name: proget
  namespace: services
  labels:
    app: proget
spec:
  replicas: 1
  selector:
    matchLabels:
      app: proget
  template:
    metadata:
      labels:
        app: proget
    spec:
      volumes:
        - name: packages
          emptyDir: {} # should be pvc
        - name: extensions
          emptyDir: {} # should be pvc
      init_container:
        - name: upgrade-db
          image: 'ghcr.io/visualon/proget:5.3.21'
          command: ["/usr/local/proget/db/inedosql", "update", "/usr/local/proget/db/SqlScripts.zip"] # should only update if required
          env:
            - name: SQL_CONNECTION_STRING
              value: Data Source=proget-sql; Initial Catalog=ProGet; User ID=sa; Password=<YourStrong!Passw0rd> # should be come from secret
          volumeMounts:
            - name: packages
              mountPath: /var/proget/packages
            - name: extensions
              mountPath: /var/proget/extensions
      containers:
        - name: proget
          image: 'ghcr.io/visualon/proget:5.3.21'
          ports:
            - containerPort: 80
              protocol: TCP
          env:
            - name: SQL_CONNECTION_STRING
              value: Data Source=proget-sql; Initial Catalog=ProGet; User ID=sa; Password=<YourStrong!Passw0rd> # should be come from secret
          volumeMounts:
            - name: packages
              mountPath: /var/proget/packages
            - name: extensions
              mountPath: /var/proget/extensions
  serviceName: proget

@atripp Simply running the upgrade didn't help, as the services is upgrading again because the new version is missing in the database.

So it would really helpful to have a simple upgrade command which can be run before running the service.

OK, found this and will try

docker run --rm -it proget:5.3.21 /usr/local/proget/db/inedosql update /usr/local/proget/db --connection-string="...."

Ok, can use inedosql_cs env for connection string

https://github.com/Inedo/inedosql/blob/41550402277bbf468583d3346bb0458d55f5a482/inedosql/Program.cs#L314

Yes, a initContainer runs before the normal container and should simply exit with code 0 when done or any other exit code to indicate a failure.

I already have a kubernetes deplyoment and can easily add an init container myself. So i only need a way to call the inedosql before running the normal proget service.

I've checked the image contents and found the indedosql at /usr/local/proget/db can i simply override the docker entrypoint an call that executable? Do i need any special commands args?

I'm using the proget image in a kubernetes deployment.

Currently i have some trouble when auto upgrading the database. This will sometimes timeout in my startup probe.

So my idea is to run the database upgade as an InitContainer with other limits. So the normal proget container can startup without migration.

Is there any ways to run the proget docker image to only upgade the database and then exit?

I'm not sure which package causes this issue, but the packages are all public, see https://github.com/orgs/visualon/packages

I'm pretty sure it was one of those packages:

You need a github account to use the feed above, because github requires you to login.
So i think you should be able to reproduce the issue.

Today i got some proget errors from my github package connector:

System.NullReferenceException: Object reference not set to an instance of an object.
at Inedo.ProGet.Feeds.NuGet.NuGetConnector.FindPackagesByIdAsync(NuGetQueryOptions options, String id) in C:\InedoAgent\BuildMasterTemp\192.168.44.60\Temp\_E91433\Src\ProGetCoreEx\Feeds\NuGet\NuGetConnector.cs:line 296

My connector:

Using ProGet on Docker for Linux: Version 5.3.19 (Build 9)

proget.inedo.com/productimages/inedo/proget:5.3.19@sha256:03b64607a3c7be571bc37acec8965efa05723994678d8f99ecac6e45d7ae8c53

As for the security concern: maybe add an environment config option to pass trusted proxy ips like traefik supports forwardedHeaders.trustedIPs

Maybe another option is to use the ASP.NET Core proxy config options to solve the issue.

Ok, my reverse proxy isn't able to rewrite headers traefik/traefik#6047

So i will go with setting BaseUrl and hope that the licensing issues get fixed in a later version.
I only see the issues when using an admin user, which we normally not use.
I also hope you won't block this usage scenario in a future version whithout a proper solution.

@rhessinger said in docker login failed via https reverse proxy:

Thanks for testing this for me. I think I may see your issue. When the Web.BaseUrl is set to https://proget-test.kriese.eu, the connector should use the URL https://proget-test.kriese.eu/nuget/b/v3/inedx.json. If you set it up that way, do you still get the license violations?

yes, i can use https://proget-test.kriese.eu/nuget/b/v3/index.json or http://localhost/nuget/b/v3/index.json and always get licensing issues. (baseUrl=https://proget-test.kriese.eu)

So i'll set the BaseUrl on our other proget too and get starting licensing issues, even if the connector url matches the BaseUrl.

One thing to note is, if i set the BaseUrl to https://proget-test.kriese.eu all requests from proget connector will go through the proxy. So i think this is causing the licensing issue.

ok, setting BaseUrl fixes the docker login but causes new license violations

I now have 2 feeds a and b and configured a loopback connector on a to feed b

Errors / Warnings:

The visualon.test test nuget packages was added to feed b

btw: license issues are only go away, if i configure a diffrent license key. If i simply try to update existing key, license violations aren't removed. So the docu is wrong.

I think the solution would be that the licensing code checks passed request url against the configured baseUrl and ignore those requests.

Ok, next issue with a new nuget feed:

proget    | Unable to open file VisualOn.NCrontab.Advanced/VisualOn.NCrontab.Advanced.2.0.0.nupkg: System.IO.DirectoryNotFoundException: Could not find a part of the path '/var/proget/packages/.nugetv2/F3'.
proget    |    at System.IO.Enumeration.FileSystemEnumerator`1.CreateDirectoryHandle(String path, Boolean ignoreNotFound)
proget    |    at System.IO.Enumeration.FileSystemEnumerator`1.Init()
proget    |    at System.IO.Enumeration.FileSystemEnumerator`1..ctor(String directory, Boolean isNormalized, EnumerationOptions options)
proget    |    at System.IO.Enumeration.FileSystemEnumerable`1..ctor(String directory, FindTransform transform, EnumerationOptions options, Boolean isNormalized)
proget    |    at System.IO.Enumeration.FileSystemEnumerableFactory.FileSystemInfos(String directory, String expression, EnumerationOptions options, Boolean isNormalized)
proget    |    at System.IO.DirectoryInfo.InternalEnumerateInfos(String path, String searchPattern, SearchTarget searchTarget, EnumerationOptions options)
proget    |    at System.IO.DirectoryInfo.EnumerateFileSystemInfos()
proget    |    at Inedo.ProGet.Extensions.FileSystems.DirectoryFileSystem.ListContentsAsync(String path) in C:\InedoAgent\BuildMasterTemp\192.168.44.60\Temp\_E75101\Src\ProGetCoreEx\Extensions\FileSystems\DirectoryFileSystem.cs:line 77
proget    |    at Inedo.ProGet.Extensions.FileSystems.CaseInsensitiveFileSystem.ListItemsInternalAsync(String path)
proget    |    at Inedo.ProGet.Extensions.FileSystems.CaseInsensitiveFileSystem.<>c__DisplayClass12_0.<<OpenFileAsync>g__getAllMatchesAsync|0>d.MoveNext() in C:\InedoAgent\BuildMasterTemp\192.168.44.60\Temp\_E75101\Src\ProGetCoreEx\Extensions\FileSystems\CaseInsensitiveFileSystem.cs:line 212
proget    | --- End of stack trace from previous location where exception was thrown ---

Workaround again: create directory manually docker exec -t proget mkdir -p /var/proget/packages/.nugetv2/F3

@csyy321_2677 You need to forward to port 80 instead of 8080, eg docker run .... -p 8080:80 .../proget. The linux proget docker container is listening on port 80 as root.

Hi @atripp

My BaseUrl is empty, so proget is correctly assuming the hostname from headers.
But as you said, it isn't respecting the X-Forward* headers.
That why proget falsy returns a http url, because the reverse proxy is doing http to proget.

If i add the baseUrl, i'll get licensing issues for a nuget v3 loopback connector, so i was told to empty baseUrl. see https://forums.inedo.com/topic/3037/how-to-configure-the-proget-free-with-self-connector/13

So my assumption would be, that proget will respect the X-Forward* headers as already doing in other feeds.

Another options would be, if we can configure proget to listen on https with a provided tls certificate, so i would have end-to-end tls encryption.

Hi @rhessinger,

Sorry my bad, it's a typo, first request is going to https://proget-test.kriese.eu/v2/ and second is going to http://proget-test.kriese.eu/v2/_auth

The second request is expected by docker to go to http because of the wrong www-authenticate header

@viceice said in docker login failed via https reverse proxy:

www-authenticate: Bearer realm="http://proget-test.kriese.eu/v2/_auth",service="proget-test.kriese.eu"

docker login proget-test.kriese.eu make a get request to http://proget-test.kriese.eu/v2/ which return the header www-authenticate: Bearer realm="http://proget-test.kriese.eu/v2/_auth",service="proget-test.kriese.eu.
Then docker is maoking a reuest to http://proget-test.kriese.eu/v2/_auth as told in the response, which fails, because protokoll changed from https to http.

The proget auth header should be like:
www-authenticate: Bearer realm="https://proget-test.kriese.eu/v2/_auth",service="proget-test.kriese.eu

The http://proget-test.kriese.eu/v2/_auth is not available, as i do not forward these insecure http requests from proxy to proget

for reference my daemon.json

{
  "registry-mirrors": [],
  "insecure-registries": [],
  "debug": true,
  "experimental": false
}

pretty default config

I've created a new minimal test setup to reproduce the login issue (docker desktop on windows 10).

• login to to localhost:8082 works
• login to to localhost:8083 works
• login to to proget-test.kriese.eu fails, because docker tries to login with http instead of https which failes, because my proget does not listen to http://proget-test.kriese.eu

Here is the compose file i use for testing:

version: "2.4"
services:
  proget:
    image: proget.inedo.com/productimages/inedo/proget:5.3.15
    restart: unless-stopped
    container_name: proget
    environment:
      SQL_CONNECTION_STRING: Data Source=mssql; Initial Catalog=proget; User ID=proget; Password=proget
    volumes:
      - proget-packages:/var/proget/packages
    ports:
      - 8082:80/tcp
    networks:
      - mssql
      - default
    labels:
      - "traefik.http.routers.proget.rule=Host(`proget-test.kriese.eu`) || Host(`localhost`)"
      - traefik.enable=true
      - traefik.http.services.proget.loadbalancer.server.port=80
      - traefik.docker.network=proget

  whoami:
    image: containous/whoami
    restart: unless-stopped
    labels:
      - "traefik.http.routers.whoami.rule=Host(`wai-test.kriese.eu`)"
      - traefik.enable=true
      - traefik.docker.network=proget

  proxy:
    image: traefik:2.3.2
    restart: unless-stopped
    command:
      - --entryPoints.web.address=:80
      - --entryPoints.websecure.address=:443
      - --api.insecure=true
      - --providers.docker.exposedByDefault=false
      - --providers.file.directory=/etc/traefik.d
      - --providers.file.watch=true
      - --accesslog=true
      - --accesslog.format=json
      - --accesslog.fields.defaultmode=keep
      - --accesslog.fields.headers.names.RequestAddr=keep
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./conf:/etc/traefik.d:ro
      - ./letsencrypt:/etc/letsencrypt:ro
    ports:
      - 443:443/tcp
      - 8083:80/tcp
      - 8084:8080/tcp

volumes:
  proget-packages:

networks:
  default:
    name: proget
  mssql:
    external: true

and the traefik tls config file ./conf/tls.yml

tls:
  certificates:
    - certFile: /etc/letsencrypt/live/kriese.eu/fullchain.pem
      keyFile: /etc/letsencrypt/live/kriese.eu/privkey.pem

thanks, this is low prio, as there is a simple workaround.

I'm using proget.inedo.com/productimages/inedo/proget:5.3.15

If i set Web.BaseUrl, i get license errors, because of loopback nuget v3 connector :-(

I've installed a fresh proget instance and added a single docker feed.

Yes, I've used docker exec proget mkdir /var/proget/packages/.docker/F1 to create folder.

If i put a reverse proxy for https termination infront of proget, docker client can't login because a wrong www-authenticate header. the response tries to redirect to http instead of https which isn't allowed

passed proxy headers (fetched via containous/whoami docker image)

Hostname: 68ff07e4f3c9
IP: 127.0.0.1
IP: 172.22.0.4
RemoteAddr: 172.22.0.2:60372
GET / HTTP/1.1
Host: wai-test.kriese.eu
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,de-DE;q=0.8,de;q=0.7
Cache-Control: max-age=0
Dnt: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 172.22.0.1
X-Forwarded-Host: wai-test.kriese.eu
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Forwarded-Server: ee3e7e9207a9
X-Real-Ip: 172.22.0.1

proget response header

curl -sv https://proget-test.kriese.eu/v2/
*   Trying 192.168.158.122:443...
* TCP_NODELAY set
* Connected to proget-test.kriese.eu (192.168.158.122) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=kriese.eu
*  start date: Sep 13 03:22:32 2020 GMT
*  expire date: Dec 12 03:22:32 2020 GMT
*  subjectAltName: host "proget-test.kriese.eu" matched cert's "*.kriese.eu"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x564ea06937c0)
> GET /v2/ HTTP/2
> Host: proget-test.kriese.eu
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
< HTTP/2 401
< cache-control: private
< content-type: application/json
< date: Thu, 29 Oct 2020 15:17:28 GMT
< docker-distribution-api-version: registry/2.0
< server: Kestrel
< vary: Authorization
< www-authenticate: Bearer realm="http://proget-test.kriese.eu/v2/_auth",service="proget-test.kriese.eu"
< x-proget-version: 5.3.15.2
< content-length: 145
<
* Connection #0 to host proget-test.kriese.eu left intact
{"errors":[{"code":"UNAUTHORIZED","message":"Anonymous is not permitted to perform the Feeds_ViewFeed task for the current scope.","detail":[]}]}

fresh installed proget free on as docker container
trying to push a image

commands

❯ docker push localhost:8082/d/alpine
The push refers to repository [localhost:8082/d/alpine]
ace0eda3e3be: Layer already exists
received unexpected HTTP status: 500 Internal Server Error

proget log

proget    |       Request starting HTTP/1.1 PUT http://localhost:8082/v2/d/alpine/manifests/latest application/vnd.docker.distribution.manifest.v2+json 528
proget    | A 500 error occurred in d: Could not find a part of the path '/var/proget/packages/.docker/F1'.

found in settings of feed the following storage path: /var/proget/packages/.docker/common

docker compose file

version: "2.4"
services:
  proget:
    image: proget.inedo.com/productimages/inedo/proget:5.3.15
    mem_limit: "2g"
    memswap_limit: "2g"
    restart: unless-stopped
    container_name: proget
    environment:
      SQL_CONNECTION_STRING: Data Source=mssql; Initial Catalog=proget; User ID=proget; Password=proget
    volumes:
      - proget-packages:/var/proget/packages
    ports:
      - 8082:80/tcp
    networks:
      - mssql
      - default

volumes:
  proget-packages:

networks:
  mssql:
    external: true

Workaround manually create the missing folder

Now moved to docker based sql server 2019 and it works. but now i get a new error in logs:

Product activation error: machine UID mismatch.
Expected: 5.3; Actual: G2fKz***redacted***tHtI=

test on local docker host now and it works as expected, so it must be something with the old sql server

docker run --name proget-sql \
      -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=ProGetTest!1234' \
      -e 'MSSQL_PID=Express' -p 1433:1433 \
      -d mcr.microsoft.com/mssql/server:2019-latest

# restore db

docker run \
    -e SQL_CONNECTION_STRING='Data Source=docker-m01; Initial Catalog=Proget; User ID=sa; Password=ProGetTest!1234;Connection Timeout=10' \
    -e Logging__LogLevel__Default='Trace' --rm -p 8085:80 -t --name proget \ 
    proget.inedo.com/productimages/inedo/proget:5.3.12

SQL Server is installed on a Windows Server 2012 R2 Core vm. That is directly accessable via IPv4 and IPv6. Nothing special here.

I'll more a copy of the db to a single docker host and try running sql server and proget on same docker host.
I'll also test Connection Timeout=30 to my connection string, so i should get a timeout while trying to connect.

No, I don't change anything. We are using the official docker image.
I can reproduce it even on a plain docker container, so kubernetes isn't the cause.
I can also reproduce it on a similar vm, where nothing else is running.

We are also deprecating / migrating the sql server in near future.

So i can move the database to a linux docker sql server to check, if there are any changes.

Another thing is the proget database is pretty old. it was migrated since 2014-08-27 12:19:06.093.

The host is a hyper-v virtual machine running on a dual socket amd opteron 6300 server with 256GB RAM. ~50% physical memory used.

Our prod proget server is running in k3s kubernetes v1.18.9+k3s1 (630bebf9). But i tested the simple docker command posted above, which fails too.

VM stats:

• 8 cores
• 16GB ram (no swapfile)
• ubuntu 18.04.5 with linux-azure kernel 5.4.0-1025-azure
• k3s v1.18.9+k3s1 (630bebf9)
• docker-ce 19.03.13 (btrfs)

let me know if you need more specs.

Using ip doesn't change anything.

I additionally see, that it will use 100% of one cpu core. So it doesn't hung, but seems to be in an endless loop.

Is there any env variable or somethings else i can set to get some more debug output?

I can try the ip.

I don't get any output after the ProGet version is 5.3.12.21. line. It simply hungs.

btw: our sql server it at version: 12.0.6372.1

Currently we have 9 feeds (nuget, powershell, docker, npm)

Our proget sql user has db_owner rights. As said above, the mono version runs fine, but the dotnet core version seems to hung on sql connection.

Hi, I'm trying to migrate to the new dotnet core based docker image proget.inedo.com/productimages/inedo/proget:5.3.12 which hungs after printing version number.

docker run -e SQL_CONNECTION_STRING='Data Source=db02; Initial Catalog=ProGet; User ID=proget; Password=XXXXXX' --rm -p 8085:80 -it proget.inedo.com/productimages/inedo/proget:5.3.12
Unable to find image 'proget.inedo.com/productimages/inedo/proget:5.3.12' locally
5.3.12: Pulling from productimages/inedo/proget
d121f8d1c412: Already exists
7b2d5a029506: Already exists
778ad5bbc2d1: Already exists
6de7a0eb2598: Already exists
6d9bf7184ec4: Already exists
efa13847425c: Already exists
Digest: sha256:398060e737b34d2afe85c837c395e056ba37938896140bf1d7ecfc61e029caf1
Status: Downloaded newer image for proget.inedo.com/productimages/inedo/proget:5.3.12
ProGet version is 5.3.12.21.

Switching to the mono image proget.inedo.com/productimages/inedo/progetmono:5.3.12 works fine.

I'm using the docker linux version with default settings. then i added traefik as https reverse proxy with ssl ofload. it will pass the normal X-Forwarded- http headers, which seem to work correct.

if i download the index.json only one of the urls is missing the https prefix and uses http. So because only one url is wrong i assume a bug on the PackageDetailsUriTemplate url generation.

Yes, i think so, using traefik as reverse proxy.

as you can see in above posted json most urls look right, only PackageDetailsUriTemplate has http instead of https protocol.

I also see no new Licensing Violations since friday. Editing and saving license key does not remove the red banner.

yes, I'm already passing the proxy headers and it basically works.

Only the PackageDetailsUriTemplate url in index.json now points to http instead of https. So i think there is a small bug.

Seeing the same error after disabling anonymous access

now trying again with Web.BaseUrl set to empty.

so the index.json looks like for http://localhost

{
    "version": "3.0.0",
    "resources": [{
            "@id": "http://localhost/nuget/Release/v3/search",
            "@type": "SearchQueryService",
            "comment": "Query endpoint of NuGet Search service"
        }, {
            "@id": "http://localhost/nuget/Release/v3/search",
            "@type": "SearchQueryService/3.0.0-rc",
            "comment": "Query endpoint of NuGet Search service"
        }, {
            "@id": "http://localhost/nuget/Release/v3/search",
            "@type": "SearchQueryService/3.0.0-beta",
            "comment": "Query endpoint of NuGet Search service"
        }, {
            "@id": "http://localhost/nuget/Release/v3/autocomplete",
            "@type": "SearchAutocompleteService",
            "comment": "Autocomplete endpoint of NuGet Search service"
        }, {
            "@id": "http://localhost/nuget/Release/v3/autocomplete",
            "@type": "SearchAutocompleteService/3.0.0-rc",
            "comment": "Autocomplete endpoint of NuGet Search service"
        }, {
            "@id": "http://localhost/nuget/Release/v3/autocomplete",
            "@type": "SearchAutocompleteService/3.0.0-beta",
            "comment": "Autocomplete endpoint of NuGet Search service"
        }, {
            "@id": "http://localhost/nuget/Release/v3/registrations/",
            "@type": "RegistrationsBaseUrl",
            "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
        }, {
            "@id": "http://localhost/nuget/Release/v3/registrations/",
            "@type": "RegistrationsBaseUrl/3.0.0-rc",
            "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
        }, {
            "@id": "http://localhost/nuget/Release/v3/registrations/",
            "@type": "RegistrationsBaseUrl/3.0.0-beta",
            "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
        }, {
            "@id": "http://localhost/nuget/Release/v3/registrations-gz/",
            "@type": "RegistrationsBaseUrl/3.4.0",
            "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
        }, {
            "@id": "http://localhost/nuget/Release/v3/registrations-gz/",
            "@type": "RegistrationsBaseUrl/3.6.0",
            "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
        }, {
            "@id": "http://localhost/nuget/Release/v3/flatcontainer",
            "@type": "PackageBaseAddress/3.0.0",
            "comment": "Base URL of where NuGet packages are stored, in the format https://api.nuget.org/v3-flatcontainer/{id-lower}/{version-lower}/{id-lower}.{version-lower}.nupkg"
        }, {
            "@id": "http://localhost/feeds/Release/{id}/{version}",
            "@type": "PackageDetailsUriTemplate/5.1.0",
            "comment": "URI template used by NuGet Client to construct details URL for packages"
        }, {
            "@id": "http://localhost/nuget/Release/v3/registrations/{id-lower}/index.json",
            "@type": "PackageDisplayMetadataUriTemplate/3.0.0-rc",
            "comment": "URI template used by NuGet Client to construct display metadata for Packages using ID"
        }, {
            "@id": "http://localhost/nuget/Release/v3/registrations/{id-lower}/{version-lower}.json",
            "@type": "PackageVersionDisplayMetadataUriTemplate/3.0.0-rc",
            "comment": "URI template used by NuGet Client to construct display metadata for Packages using ID, Version"
        }, {
            "@id": "http://localhost/nuget/Release/",
            "@type": "LegacyGallery"
        }, {
            "@id": "http://localhost/nuget/Release/",
            "@type": "LegacyGallery/2.0.0"
        }, {
            "@id": "http://localhost/nuget/Release/package",
            "@type": "PackagePublish/2.0.0"
        }
    ]
}

and for https://proget.xxx.com

{
    "version": "3.0.0",
    "resources": [{
            "@id": "https://proget.xxx.com/nuget/Release/v3/search",
            "@type": "SearchQueryService",
            "comment": "Query endpoint of NuGet Search service"
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/v3/search",
            "@type": "SearchQueryService/3.0.0-rc",
            "comment": "Query endpoint of NuGet Search service"
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/v3/search",
            "@type": "SearchQueryService/3.0.0-beta",
            "comment": "Query endpoint of NuGet Search service"
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/v3/autocomplete",
            "@type": "SearchAutocompleteService",
            "comment": "Autocomplete endpoint of NuGet Search service"
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/v3/autocomplete",
            "@type": "SearchAutocompleteService/3.0.0-rc",
            "comment": "Autocomplete endpoint of NuGet Search service"
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/v3/autocomplete",
            "@type": "SearchAutocompleteService/3.0.0-beta",
            "comment": "Autocomplete endpoint of NuGet Search service"
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/v3/registrations/",
            "@type": "RegistrationsBaseUrl",
            "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/v3/registrations/",
            "@type": "RegistrationsBaseUrl/3.0.0-rc",
            "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/v3/registrations/",
            "@type": "RegistrationsBaseUrl/3.0.0-beta",
            "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/v3/registrations-gz/",
            "@type": "RegistrationsBaseUrl/3.4.0",
            "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/v3/registrations-gz/",
            "@type": "RegistrationsBaseUrl/3.6.0",
            "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/v3/flatcontainer",
            "@type": "PackageBaseAddress/3.0.0",
            "comment": "Base URL of where NuGet packages are stored, in the format https://api.nuget.org/v3-flatcontainer/{id-lower}/{version-lower}/{id-lower}.{version-lower}.nupkg"
        }, {
            "@id": "http://proget.xxx.com/feeds/Release/{id}/{version}",
            "@type": "PackageDetailsUriTemplate/5.1.0",
            "comment": "URI template used by NuGet Client to construct details URL for packages"
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/v3/registrations/{id-lower}/index.json",
            "@type": "PackageDisplayMetadataUriTemplate/3.0.0-rc",
            "comment": "URI template used by NuGet Client to construct display metadata for Packages using ID"
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/v3/registrations/{id-lower}/{version-lower}.json",
            "@type": "PackageVersionDisplayMetadataUriTemplate/3.0.0-rc",
            "comment": "URI template used by NuGet Client to construct display metadata for Packages using ID, Version"
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/",
            "@type": "LegacyGallery"
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/",
            "@type": "LegacyGallery/2.0.0"
        }, {
            "@id": "https://proget.xxx.com/nuget/Release/package",
            "@type": "PackagePublish/2.0.0"
        }
    ]
}

here the PackageDetailsUriTemplate/5.1.0 type is using http instead of https

Nope, the http://localhost/nuget/Release/v3/index.json points back to the public url, and proget will follow and use the https reverse proxy again.

So i again get the error.