Posts made by jeff.peirson_4344

I pulled the ci.4 image and that fixed the issue. I haven't noticed any other issues, so I'll just leave the ci version installed until the next ProGet release.

Thanks again for the quick fix.

No problem - thanks for the quick reply. Yes we can upgrade to a pre-release version.

I'm running ProGet 2023.3, and I'm getting an error installing scoped npm packages, but only under some conditions...

• some my-npm feed is connected to the default npmjs registry
• e.g. for package @uirouter/angularjs, go to the /feeds/my-npm/@uirouter/angularjs/1.1.0 page in a browser
• ensure the package isn't pulled locally to ProGet yet (has "remote" icon next to the package version). Delete the package version if it's already pulled locally.
• from an npm client, configured to use the my-npm registry, run npm i @uirouter/angularjs@1.1.0 --> fails with E404 Package Not Found
• from the package version page in the browser again, use the dropdown to "Pull To ProGet"
• run npm i ... again --> works

I saw that ProGet 2023.4 was released today. I upgraded to that, but no change in behavior. This was working fine prior to 2023.x.

Note that while I was troubleshooting, trying to rule out issues on my side, I think the package name is being mangled when it's requested via the connector. I tried temporarily creating a connector for the my-npm feed, which pulled from temp-npm feed, which pulled from the default npmjs registry. When I did that and tried npm i I saw, "An error occurred processing a GET request to http://127.0.0.1:8095/npm/temp-npm/@@uirouter/angularjs: Package was not found." --> note the double @@

Bah - turned out to be user error. I was posting the file to https://server/endpoints/myfeed/content/dir instead of https://server/endpoints/myfeed/content/dir/. I suppose ProGet could better handle this error case with a non-500 error response, but in any case I've fixed my own problem.

So I have an nginx reverse proxy set up as part of my docker stack, which includes other software dev services besides ProGet. I did some more troubleshooting, and if I issue the same HTTP request via curl, I get the same error as with powershell, so powershell doesn't seem to be a factor. But if I issue the curl request from another container inside the docker stack so that the request isn't going through the reverse proxy, it works fine.

I haven't made any changes to the nginx container or configuration, and it's been running for over a month, well before I started having this issue, so I don't think any nginx config change is to blame. But the reverse proxy is a factor somehow.

My nginx config fragment for the proget container looks like:

server {
        server_name myserver.com;
        listen 8096 ssl http2 default_server;
        access_log /var/log/nginx/access.log vhost;
        ssl_session_timeout 5m;
        ssl_session_cache shared:SSL:50m;
        ssl_session_tickets off;
        ssl_certificate /etc/nginx/certs/myserver.com.crt;
        ssl_certificate_key /etc/nginx/certs/myserver.com.key;
        add_header Strict-Transport-Security "max-age=31536000" always;

        location / {
                proxy_pass http://proget:8095/;
        }
}

Other env details: I'm accessing the nginx proxy over https on port 8096, and nginx forwards the request to the proget container on non-ssl port 8095. I read that there are issues with using any kind of URL rewrite with ProGet, so aside from the port number, there's no URL path changing taking place.

Other nginx config if it's relevant:

client_max_body_size 0;
chunked_transfer_encoding on;
proxy_http_version 1.1;
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
proxy_set_header X-Forwarded-Ssl $proxy_x_forwarded_ssl;
proxy_set_header X-Forwarded-Port $proxy_x_forwarded_port;
proxy_set_header X-Original-URI $request_uri;
proxy_set_header Proxy "";
proxy_buffering			on;
proxy_buffers			128 4m;
proxy_busy_buffers_size	256m;
proxy_buffer_size		16m;
proxy_max_temp_file_size 0;
client_body_buffer_size	4m;
proxy_connect_timeout	300;
proxy_read_timeout		3000;
proxy_send_timeout		300;
proxy_intercept_errors	off;

and if it's relevant I'm using jwilder/nginx-proxy:1.0 as the proxy image.

Does ProGet have more detailed logs somewhere? The error isn't being logged anywhere I can find (API key access logs, Diag Center log, ProGet Event Log, stdout/stderr from the running ProGet docker container). The "access denied" error I posted before is the literal body of the response, with no other info.

And does any of my nginx config stand out as having problems with ProGet?

I'm using the asset content API endpoint to post a file to an asset directory. This has been working, but stopped working around 3 Jan 2023 for some reason. I'm not sure what changed around that time, but I suspect we upgraded our ProGet installation to the latest 2022 patch (would have been a patch upgrade only - we've been using v2022 for several months).

I'm using powershell to send the post request, which looks something like:

Invoke-WebRequest -ErrorAction Stop -Uri 'https://proget/endpoints/my-asset-feed/content/path/to' -Method POST -Headers @{'X-ApiKey' = 'XXX'} -InFile 'myfile.json' -ContentType 'application/json'

I get a 500 error response back with:

"Access to the path '/var/proget/packages/.assets/F19/path/to' is denied."

What's weird is that I can upload the file manually through the ProGet feed page from my browser, and can create and delete folders with no issues.

I'm running ProGet as a docker container, with the 2022.17 image from your registry. The packages are mounted as an external volume into /var/proget/packages. I can log into the docker container and verify the path exists. The directory attributes for the asset are drwxr-xr-x all the way up, the file is -rw-r--r-- and the file and directories are all owned by root:root. As far as I can tell, the ProGet service itself is running as root within the container.

Is this an known issue within ProGet? or could it be something with my environment?

@gdivis That was it - I had to override PROGET_SQL_CONNECTION_STRING.

I had to override it as:

  environment:
    - "PROGET_SQL_CONNECTION_STRING= "
    # would fail:
    #- PROGET_SQL_CONNECTION_STRING=
    - PROGET_SQL_CONNECTION_STRING_FILE=/run/secrets/mssql-cs

Else startup would fail with "System.ArgumentNullException: Value cannot be null. (Parameter 'connectionString')"

In any case, I have a working docker compose file now - thanks!

@atripp I've updated the var name, but I'm still unable to get this working.

I can verify the the secret file exists and has the correct text in the container by running cat /run/secrets/mssql-cs. Also, I oversimplified my pasted docker compose file - it does correctly include the secret under the proget service, and I've since updated it with the correct env var name:

services:
  proget:
    secrets:
      - mssql-cs
    environment:
      - PROGET_SQL_CONNECTION_STRING_FILE=/run/secrets/mssql-cs

secrets:
  mssql-cs:
    file: ./secret.txt

Does the file require certain permissions to be recognized by the ProGet service? Should the file text be the literal connection string, no quoting, no trailing newline? What happens if this env var is set, but the file does not exist?

I don't think ProGet is trying to read the file, because if I provide an invalid connection string, like server6=mssql;..., I'd expect to see connection string parse error in the ProGet log, but instead I just see, "A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections" which I'm assuming means ProGet is using a default connection string to localhost or something.

This is with the ProGet v22 image from proget.inedo.com/productimages/inedo/proget:22.0.7.

The docs say that you can specify an environment variable SQL_CONNECTION_STRING_FILE with the connection string as the file text, but when I use this variable, it has no effect. If I use SQL_CONNECTION_STRING instead with the connection string, then this works fine.

My docker compose file looks something like:

services:
  proget:
    environment:
      - SQL_CONNECTION_STRING_FILE=/run/secrets/mssql-cs

secrets:
  mssql-cs:
    file: ./secret.txt

I've fixed this in https://github.com/Inedo/pgscan/pull/3 .

I did some minimal testing with providing a feed name vs a source URL in pgscan, which at least worked for me.

Ignore my question from my previous comment - guessing the field names wasn't hard after all. Looks like they are dependentFeed and dependentUrl.

Thanks @stevedennis , I'll look into fixing this.

What is the name for the consumer source field in the /api/dependencies/dependents request body? I see an example in the package consumer docs, but the example doesn't specify a consumer source. And I see the request body JSON in ProGetClient.cs, but not sure what JSON property name to give to the PackageConsumer.Feed/.Url without just guessing.

Thanks,
-Jeff

If I understand the pgscan tool correctly, the --consumer-package-source arg maps to this field from the ProGet UI when you manually add a package consumer for a nuget package:

If I test manually adding a consumer via the UI with some existing feed name for "Source feed/url", the consumer is listed in the UI with as a link to my consumer package in ProGet, which is what I'd expect (which makes tracking dependencies nice and easy).

If I specify the same feed name in pgscan, I don't see the same kind of link in the consumer list in the UI - it's just static text like "MyGroup/MyPackage v2.0.0-alpha.117". Looking at the HTTP traffic that pgscan sends to ProGet, I don't even see the feed name that I set for the consumer package source.

Sample pgscan cmd line:

pgscan publish --type=nuget --package-feed=feed-a --proget-url=https://proget.local --consumer-package-name=MyPackage --consumer-package-group=MyGroup --consumer-package-version=2.0.0-alpha.117 --consumer-package-source=feed-b --api-key=xxx --input=MyPackage.csproj

Screenshot of what pgscan sent to the /api/dependencies/dependents endpoint, captured from Fiddler:

Is this bug in pgscan? or am I misunderstanding what --consumer-package-source is for?