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

I just pushed out a pre-release version of ProGet 2025.24-rc.3 and can be installed via InedoHub. Please see our our guide on installing pre-release verions for more information. Please let us know if you have nay problems.

Thanks,
Rich

Hi @phil-sutherland,

Thanks for sending this over to us. This looks to be a regression in the PostgreSQL migration. I have created a ticket, PG-3241, to fix the issue. This will be fixed in the next maintenance release of ProGet 2025.24, due out on March 20, 2026.

Thanks,
Rich

Hi @gbeckett,

It looks like there was a merge issue and part of this fix was undone. I have created a new ticket, PG-3240 to fix it. If you would like, I can create a pre-release of ProGet 2025.24 with the fix that you can install now. If not, the fix will be released at the end of next week in ProGet 2025.24.

Thanks,
Rich

Hi @Valentijn,

We had a hiccup in one of our edge nodes that was preventing this version from showing up. If you check now, it should be available.

Thanks,
Rich

Hi @phil-sutherland_3118,

There is nothing off the top of my head that would fix this. The next step would be to see your LDAP queries and potentially some example data. It would probably be best to wait until you get a license if you do not feel comfortable sharing that data on the forums. If you care to look, you can see our code for both our AD User Directories and our OpenLDAP/Generic LDAP user directories on our GitHub repo: https://github.com/inedo/inedox-inedocore

Thanks,
Rich

Hi @sirko_6724,

Please let us know what you figure out. When we built our OpenLDAP user directory, we built it based on OpenLDAP's best practices for groups and this is the first time we have seen an issue with groups missing the member attribute. I know you are adverse to making changes to your OpenLDAP server, but another option would be to populate the users on the groups using a Dynamic List. That would allow you to add the user's dn to the group without having to change all the records.

Thanks,
Rich

Hi @phil-sutherland_3118,

Just to confirm, are you using an Active Directory domain or OpenLDAP doimain in your environment? Your initial post makes it sound like you are using Active Directory and not OpenLDAP. If you are connecting to Active Directory, you can use the following two LDAP settings to get groups and members:

• For List User's Groups: (&(objectCategory=group)(member:1.2.840.113556.1.4.1941:=%s)) and for get a groups
• For List Group's Members: (&(objectCategory=user)(memberOf:1.2.840.113556.1.4.1941:=%s))

These will only work when using our OpenLDAP/GenericLDAP user directory and connecting to an Active Directory domain, OpenLDAP domains do not implement these special queries.

That other forums post is a OpenLDAP domain that is using custom attributes for groups.

Thanks,
Rich

Hi @phil-sutherland_3118,

That is expected behavior. ProGet will always strip off the domain suffix from the username. Users in the past have created multiple user directories (one for each suffix) and then using the username@suffix (ex: user.name@company.group) as the login.

An alternative approach is to use the OpenLDAP/GenericLDAP user directory instead. It requires you to enter the AD-based LDAP attributes and queries, but it will not strip off the domain suffix.

Thanks,
Rich

Hi @caspacokku_2900,

Thanks for posting this! We are happy to hear you up and running! We are currently reviewing a default value for the concurrent request limit in ProGet. As more and more package managers push towards a larger dependency tree, this limit is becoming a requirement for some feeds (cargo, npm, and NuGet being among the highest).

Thanks,
Rich

Hi @michael-day_7391,

Thanks for sending this over! We'll get this resolved within the next couple of maintenance releases of ProGet.

Thanks,
Rich