Hi @jolaka9284_9458,

Thanks for providing all these details. I was able to pinpoint the reason for the slow down and why it specifically happens on some crates and not others. This is related to some code that we have to determine when to point cargo to pull dependencies from ProGet vs crates.io. Specifically this comes from cargo's API specs for dependencies:

registry — cargo metadata uses a value of null to indicate that the dependency comes from crates.io. The index uses a value of null to indicate that the dependency comes from the same registry as the index. When creating an index entry, a registry other than crates.io should translate a value of null to be https://github.com/rust-lang/crates.io-index and translate a URL that matches the current index to be null.

As you can see, the value specified in the metadata is different than the value the index needs to return. In ProGet, we will return null if the package exists in the feed (including connectors) and https://github.com/rust-lang/crates.io-index if it does not. This is to support the case when ProGet is not used as a mirror and instead for only local crates. Unfortunately the use ProGet as a mirror option is stored only in the client config and is not sent to ProGet.

This is the reason why crates with a lot of dependencies take longer to generate the index than ones that don't and why you'll occasionally get timeouts, but after the retry it works. We have some caching on this to help with performance, but it's not a forever cache.

I'm going to work on some potential improvements for this and will let you know when I have a solution ready. Unfortunately, the only workaround we have for this currently is to use a package approval workflow (like our npm Package Approval blog article).

Thanks,
Rich

Hi @gravufo,

Would you be able to rerun the database scripts on your database? You will just need to run the Run inedosql to update the database step of our manual install guide. Can you see if this fixes your issue?

Thanks,
Rich

Hi @viceice,

That error is safe to ignore. It is currently a known bug and we are looking to fix that in an upcoming version of ProGet. The ticket tracking the fix for the log message is PG-1841.

Long story short, the ProGet service correctly detected that the product wasn't activated, and then logged that message. But it was doing it every time it accessed license information, which is on every connector health check, replication run, etc.
Activation happens automatically as soon as someone visits the Web application, and re-activation is required after upgrading certain versions.

Thanks,
Rich

Hi @mcascone ,

We have fixed the issue and the published date will now update when the package is overwritten. This will be released in ProGet 5.3.9 which is due out this Friday Augst 14, 2020.

Thanks,
Rich

Hi @viceice,

Thanks for the clarification on your environment! I see what is going on now. I have created a ticket, PG-1809, to track the fix for this. We expect this to be released in ProGet 5.3.11 which we are expecting to be released in September 11, 2020. Basically in that instance, we are not respecting the values within the X-Forwarded-* headers. I'll let you know if anything changes on the timeline.

Thanks,
Rich

Hi @markus4830,

I'm definitely sorry about this. The change was made to help to aide in improvements to other areas of the system related to NuGet. Unfortunately, it looks like it affected the NuGet API. Expect a more permanent solution in the near future.

Thanks,
Rich

Hi @nuno-guerreiro-rosa_9280,

We have finally been able to recreate this issue in our sandbox. We are currently looking into a fix, but we expect to have one in the next version of ProGet, 5.3.10. This looks to be an issue with the mono framework. We use mono runtime in our Docker images for ProGet. We are also going to be releasing a .Net Core based technical preview of ProGet Docker in version 5.3.10. This will be in addition to our standard mono based version. Our internal testing is going very well and it looks to have removed a lot of the gotchas that mono has.

Thanks,
Rich

Hi @harald-somnes-hanssen_2204,

The fix is scheduled for release in ProGet 5.3.16 which is due out on Friday. I'll reply back if anything changes.

Thanks,
Rich

Hi @tkolb_7784,

If you are hosting on a windows machine, the easiest solution right now is to migrate your server to use IIS and then add an SSL binding to your site. If you do not want to purchase a new certificate and the self-signed certificate is too much work, you can use Let's Encrypt and configure it via winacme.

If you do not want to use IIS, then you will need to use a reverse proxy to handle SSL connections. Any reverse proxy can be used and a pretty simple one to configure is stunnel. Most reverse proxies can also be used with Let's Encrypt.

If you are hosting via Linux (Docker), then you will need to use a reverse proxy to handle SSL connections. We have a documentation page for different Linux-based reverse proxies including an example for setting up NGINX. These reverse proxies also support Let's Encrypt also.

Please let me know if you have any questions.

Thanks,
Rich

Hi @gravufo,

Great! Glad to hear it! Please post back if you find anything else.

I also recommend that you switch to the Inedo Hub in the future. We are in the process of deprecating our traditional installer. The Inedo Hub has the ability to update an installation previously installed with the traditional installer and the Inedo Hub now supports offline installations as well, if you need that functionality.

Thanks,
Rich

Hi @jeremy-oaks_9309,

After digging into this further, there are a handful of issues that have all hit here. Before I dive into these, is there a reason you chose to use InedoDB over using the embedded database? Our guidance is when using a single ProGet container, use the embedded database. InedoDB is only recommended to be used with clustered installations of ProGet.

In your case for using InedoDB and ProGet, there were basically 3 main issues that occurred.

Issue 1:
Your docker compose file is not quite correct. You currently have your volume mappings backwards which will cause your data to not be persisted through restarts. This is also why when you updated the the pg_hba.conf file, it did not persist. I should also point out there was a typo in our DockerFile, which pointed to the wrong directory for an InedoDB volume path. This is fixed in InedoDB 17.10.2. We also updated our InedoDB Docker Installation Docs to include the volume as well.

Here is a modified version of your docker compose that will fix these issues:

services:
  inedodb:
    image: proget.inedo.com/productimages/inedo/inedodb:17.10.2
    container_name: inedodb
    restart: unless-stopped
    ports:
      - "5432:5432"
    volumes:
      - /mnt/volume_nyc1_proget/postgres:/var/lib/inedodb

  proget:
    image: proget.inedo.com/productimages/inedo/proget:26.0.5
    container_name: proget
    restart: unless-stopped
    depends_on:
      - inedodb
    ports:
      - "8634:80"
    environment:
      PROGET_POSTGRES_CONNECTION_STRING: Host=inedodb;Port=5432;Database=proget;Username=inedodb;Password=<REDACTED>
    volumes:
      - /mnt/volume_nyc1_proget/proget/packages:/var/proget/packages
    deploy:
      resources:
        limits:
          memory: 2g

Issue 2:
The default for pg_hab.conf was too restrictive. This was actually updated in the Windows installer, but not in the inedodb create --name=proget command. This has now been fixed in InedoDB 17.10.2 and it will work out of the box. With that said, it is stored in a persisted volume, so changes will stay in affect. The other part of this is that when create a database, the container needs to be restarted. We have now added a message in the inedodb create command to restart the container.

Issue 3:
The connection string confusion. This is a side effect of Docker. When we generate the connection string in InedoDB, we use the get host name command from within the container. That hostname does not match the container name or network alias of the InedoDB . We have now added a warning when creating a database in InedoDB on Docker that you may need to update the host in the connection string.

With all those addressed in docs and InedoDB 17.10.2, you should be good to create a new ProGet instance with InedoDB. If you have already started adding packages using your existing setup, I would be worried that your database and package files are not persisting through restarts. I would recommend:

1. Set up a new instance using the DockerFile I used above and a trial key
2. Import your packages from that instance to the new instance
3. Shut down you old instance and move the license key to the new instance

I know this is kind of long, so if you are confused on anything or have any other questions, please let me know!

Thanks,
Rich

Hi @jeremy-oaks_9309,

Thanks for bringing this to our attention. This looks like a change will will need to make to the InedoDB container. Let me do some digging and I'll have an update for you soon.

Thanks,
Rich

Hi @joris-guex,

Thanks for sending an example over. It looks like this is related to an issue in the libssh2-sys's manifest. I have created a ticket, PG-3321, to handle these issues better. We are expecting to have a fix out within the couple of maintenance releases of ProGet 2026.

Thanks,
Rich

Hi @Nils-Nilsson,

Thanks for bringing this to our attention. This looks to be a regression that happened right before release. I have created a ticket, PG-3289, to track the fix and we will release it this Friday in ProGet 2026.2.

Thanks,
Rich

Hi @Nils-Nilsson,

We identified the issue with the UI and have fixed it in PG-3277. This will be released next week in ProGet 2026.1.

As for the UserNotFoundException after the rollback, that is most likely related to your cookies. Once the cookie expired, it then let you login again. You can verify that by using an private/incognito window and logging in or clearing your cookies and logging in again.

Thanks,
Rich

Hi @cole-brand_2889,

I have identified the issue, PG-3268, and this should now be fixed in ProGet 2025.27. Please upgrade to 2025.27 and see if that resolves your issue.

Thanks,
Rich

Hi @geraldizo_0690,

Thanks for providing all of this information. I was finally able to recreate the issue. I have created ticket PG-3263 to fix that issue. That fix will be released next week in ProGet 2025.27. Just to make sure I cover all my bases, can you tell me which database backend you are using?

Thanks,
Rich

Hi @kien-buit_2449,

This is partially fixed in our vulnerability aggregator. You should see alpine vulnerabilities showing up next time your vulnerability updated runs. I also recreated a situation where certain packages may not be removed upon update of the vulnerability. I have created ticket PG-3263 to fix that issue. That fix will be released next week in ProGet 2025.27.

Thanks,
Rich

Hi @sigurd-hansen_7559,

This is a known issue, PG-3246, and will be fixed on Friday in ProGet 2025.25.

Thanks,
Rich

Hi @sigurd-hansen_7559,

We can add back support to not do the recursive search. If you would like to use a search scope, we would recommend using the OpenLDAP/Generic LDAP user directory and specifying your own LDAP queries. With that said, I think that is overkill for this situation and adding a way to disable recursive groups will be the easiest. I will get that added on the April 3rd release of ProGet 2025.25.

Thanks,
Rich