Navigation

    Inedo Community Forums

    Forums

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    1. Home
    2. jeff.peirson_4344
    J
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    jeff.peirson_4344

    @jeff.peirson_4344

    0
    Reputation
    17
    Posts
    3
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online

    jeff.peirson_4344 Follow

    Best posts made by jeff.peirson_4344

    This user hasn't posted anything yet.

    Latest posts made by jeff.peirson_4344

    • RE: Error getting npm package versions: The JSON value could not be converted to System.DateTime ...

      @rhessinger There are only two versions of the problematic package that I'm able to download from ProGet. It's a private package, not one pulled via a connector. This is the actual package.json (some string replacements made) for one:

      {
        "name": "volante",
        "description": "SNIP",
        "version": "6.9.0",
        "author": "USER <USER>",
        "url": "https://github.com/USER/volante",
        "repository": "USER/volante.git",
        "main": "./src",
        "keywords": [
          "hub",
          "spoke",
          "framework",
          "wheel",
          "configuration",
          "events"
        ],
        "devDependencies": {
          "volante-console": "^3.3.1"
        }
      }
      

      And for one of the versions I can't get to in ProGet, I'm able to see in the NpmPackageVersions db table a similiar looking entry under PackageJson_Bytes:

      {
        "description": "SNIP",
        "author": "USER <USER>",
        "url": "https://github.com/USER/volante",
        "repository": "USER/volante.git",
        "main": "./src",
        "keywords": ["hub", "spoke", "framework", "wheel", "configuration", "events"],
        "devDependencies": {
          "volante-console": "^3.3.1"
        },
        "readme": "SNIP"
      }
      

      Also, can you confirm the actual latest ProGet docker image version? Through the dashboard, it describes an upgrade to 2024.23. I use docker compose to pull the latest 24.0 image, and the latest currently points to 2024.24.

      posted in Support
      J
      jeff.peirson_4344
    • RE: Error getting npm package versions: The JSON value could not be converted to System.DateTime ...

      and I can log this in the upack github repo instead, but the upack command line tool now fails to push packages against ProGet v2024.24:

      The JSON value could not be converted to Inedo.ProGet.Feeds.Universal.JsonModels.UPackManifest. Path: $.createdDate | LineNumber: 14 | BytePositionInLine: 39.

      For now, since the regression to upack push is a showstopper for us, I've rolled back to 2024.22 but then of course I get the originally posted JSON error.

      posted in Support
      J
      jeff.peirson_4344
    • RE: Error getting npm package versions: The JSON value could not be converted to System.DateTime ...

      I've upgraded to ProGet 2024.24, and I still get an error, although a different one now:

      JSON deserialization for type 'Inedo.ProGet.Feeds.Npm.NpmPackageResponse' was missing required properties, including the following: versions

      Is there any kind of re-index or repair or something I'm supposed to do?

      posted in Support
      J
      jeff.peirson_4344
    • Error getting npm package versions: The JSON value could not be converted to System.DateTime ...

      I'm getting this error for my private npm feed:

      JsonException: The JSON value could not be converted to System.DateTime. Path: $.time.unpublished | LineNumber: 0 | BytePositionInLine: 2874.

      It's only happening for a specific package, and only for specific versions of that package. I also can't use the web UI to list package versions via /feeds/myfeed/mypackage/versions, since it also shows this error. I also get the same error when I try to download the package directly using curl https://host/npm/myfeed/mypackage/-/mypackage-version.tgz.

      I don't know what the JSON path $.time.unpublished refers to, I'm guessing something internal to ProGet?

      Any ideas?

      posted in Support
      J
      jeff.peirson_4344
    • RE: Unable to pull remote npm package after upgrade to ProGet 2023

      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.

      posted in Support
      J
      jeff.peirson_4344
    • RE: Unable to pull remote npm package after upgrade to ProGet 2023

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

      posted in Support
      J
      jeff.peirson_4344
    • Unable to pull remote npm package after upgrade to ProGet 2023

      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 @@

      posted in Support
      J
      jeff.peirson_4344
    • RE: Error uploading asset via API - Access to the path '/var/proget/packages/.assets/dir' is denied.

      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.

      posted in Support
      J
      jeff.peirson_4344
    • RE: Error uploading asset via API - Access to the path '/var/proget/packages/.assets/dir' is denied.

      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?

      posted in Support
      J
      jeff.peirson_4344
    • Error uploading asset via API - Access to the path '/var/proget/packages/.assets/dir' is denied.

      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?

      posted in Support
      J
      jeff.peirson_4344