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

Hi @michael-day_7391,

What version of Windows Server are you running?

When generating that command, ProGet will call Environment.UserName to determine the username the service is running as. I'm guessing this is returning the computer account instead of NETWORK SERVICE. I have crated a ticket, PG-3219, to review it, but I would like to test it on the same version of Windows Server as you.

Thanks,
Rich

Hi @michael-day_7391,

The docs say to use NETWORK SERVICE because that is the default account ProGet users when it's installed. You need to use the username of the account that the ProGet service is running as. If your ProGet service is running as MYDOMAIN\PROGET-SERVER$", then your netsh command should use that. If it is using NETWORK SERVICE, then you should be use NETWORK SERVICE. If you want to switch to a different username, then you need to first remove the urlacl by running the following, then re-add it with the correct name.

netsh http delete urlacl url==https://*:443/

The event viewer error Windows event viewer shows event id 1000, can be ignored. That is a default message that shows because we configure the URL binding in code.

The netsh http add sslcert command should only be used when you are using a haostname binding, since you are unsign *:443, you should not need this.

While you are working through this issue, I would change UseHttpsRedirection="True" to UseHttpsRedirection="False" in your config so you can still access the site over HTTP until you get this figured out. The ERR_CONNECTION_CLOSED message typically indicates an issue with the certificate binding. The most common issue that can cause this is when the permissions are incorrect on your certificate.

1. Open the Certificate Manager using Window's MMC
2. Navigate to Certificates (Local Computer) -> YOUR_STORE (ex: Personal) -> Certificates
3. Right click on the certificate and select All Tasks -> Manage Private Keys
4. And give read access to your service account

See more in our Troubleshooting guide.

Can you verify the permissions on the certificate?

Thanks,
Rich

Hi @caspacokku_2900,

I apologize for the confusion. I meant that running through the test example you provided (looks like that comment has since been deleted) and this new one, I was unable to recreate both the PostgreSQL errors and the "The given key 'version' was not present in the dictionary." error. I'm thinking the dictionary error is related to either the PostgreSQL errors or a hiccup in the network connection where the response was not fully returned, but had a successful response code causing the request to still be cached. What is also confusing is that the cache should refresh the request after 30 minutes. This means if the caching is causing the issue, it should resolve itself within 30 minutes. Also, I see you have set the metadata caching to 100, which cargo hits pretty quickly. I typically set that to 1000 requests in a crates.io connector because cargo is a very chatty client.

The main reason I was asking for a reproduction case is that I wanted to rule out an error in parsing the cargo metadata. With this latest test case you provided, I can verify that everything appears to be parsing correctly. I ran this build 30 times back to back with your settings and connector caching enabled (both metadata and crate caching). In between each build, I cleared the local registry cache and ran cargo clean. I was not able to reproduce these errors or cause issues with the connector cache. This leads me to believe that there is an environmental factor that is causing this issue. Can you please check with your IT team to see if there is anything they are seeing (external HTTP request manipulation, network packets dropping, RAM correction errors, etc..) on your server?

Thanks,
Rich