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

I have an idea on how to accomplish this. It looks like Docker allows you to expose ports in the run command. Here is what I'm thinking should work. The first thing to do is to map a volume to /usr/share/Inedo/SharedConfig. In my example, I'll map to SharedConfig.

So here would be the steps to try:

1. Create the config file using port 8080

echo '<?xml version="1.0" encoding="utf-8"?><InedoAppConfig><ConnectionString Type="SqlServer">'"`$SQL_CONNECTION_STRING"'</ConnectionString><WebServer Enabled="true" Urls="http://*:8080/"/></InedoAppConfig>' > SharedConfig/ProGet.config

2. run the container using the following command

podman run -d --userns=keep-id -v proget-packages:/var/proget/packages -v  `SharedConfig:/usr/share/Inedo/SharedConfig` -v /etc/pki/ca-trust/source/anchors:/usr/local/share/ca-certificates:ro --expose=8080 -p 8080:8080 --name=proget -e ASPNETCORE_URLS='http://+:8080' -e SQL_CONNECTION_STRING='Server=SERVERNAME;Database=ProGet;User ID=USERNAME;Password=PASSWORD' -e TZ='America/New_York' -i -t proget.inedo.com/productimages/inedo/proget:5.3.32 /bin/bash

Can you please give that a try?

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

Thanks for bringing this to our attention. I added a ticket, OT-502, to fix the issue. This should be released next week in Otter 2023.2.

Thanks,
Rich

Hi @mwatt_5816,

Thanks for all of the detail. I have fixed the code, BM-3982, for this template and it will be released in the next maintenance of BuildMaster 2024.0.7 on Friday.

Thanks,
Rich

Hi @jeff-peirson_4344,

I have been able to recreate the issue and created a ticket, PG-2870, to track the fix. We expect this to release in ProGet 2024.25 on January 24, 2025. This looks to be related to the package name existing on npmjs.org with all versions being unlisted. If you need a fix sooner, we can provide a pre-release version of ProGet 2024.25 that includes the fix.

Thanks,
Rich

Hi @NUt ,

Thank you for bringing this to our attention. This bug, PG-2126, will be fixed in ProGet 6.0.12. Going forward it will allow you to configure everything and even test it via the "Test User Directories" button, but it will only allow you to login using the Built-In user directory and the username/password login option when using ProGet free.

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

I think I have identified the issue. I have just pushed another version of InedoCore, version 1.10.7-CI.2 . Could you update and give that a try? I also added an option to bypass the LDAPS certificate verification. It is something that I would only use while testing. The solution you have with adding your certificates as valid certs is a more secure solution. One last thing to make sure you set is the Domain Controller Host. It can just be set to your domain (ex: domain.network using your steps from above). Linux/Docker does not seem to translate domain URLs the same way windows does.

Thanks,
Rich

Hi @sai.pabbareddy,

Glad to hear it all works as expected!

Thanks,
Rich

Hi @sai.pabbareddy,

Thanks for the heads up. The cache fix should exist in 26.0.11-rc.15, but I'll be very interested to hear if you still see those issues after the upgrade. Please keeps us informed and we can look into it further.

Thanks,
Rich

Hi @sai.pabbareddy,

My apologies. Looks like I typoed the date on that other post. I had the day of Friday correct, but the date should have been Sept 18, 2026. It will be releasing later today (normally in the evening in EST). I updated that response also to have the correct date.

Thanks,
Rich

Hi @sai.pabbareddy,

I think it would be a good idea to have you send over the exact directory config. The code paths for searching for users and groups are virtually identical, with the only difference being the LDAP filter. You can see what we are doing directly by looking at the code in GitHub: https://github.com/Inedo/inedox-inedocore/blob/16155c425cf4b4d180e2e7ced7af90e36fb4ed35/InedoCore/InedoExtension/UserDirectories/OpenLdap/OpenLdapUserDirectory.cs#L300

I'm guessing there is something else going on that is causing this, maybe a hidden unicode character or something. When you paste in the ldap queries, can you make sure to include them using a markdown code block (``` ... ```)?

Thanks,
Rich

Hi @sai.pabbareddy,

Let me run some other tests. It could be related to the LDAP escaping that is happening, but that would be highly unlikely as we have many other users currently using the OpenLDAP/Generic LDAP user directory. I think the more peculiar thing is that when you hard coded the uid, the logs didn't show ?uid=, but with the %s it did. That makes me think that it does not like the value that is being passed in. Does the group search have the same issue and log message?

Thanks,
Rich

Hi @sai.pabbareddy,

Glad to hear those settings fixed the initial error.

The LdapReferralException is probably an issue with Samba 4's communication pattern. An LDAP referral typically happens when the AD server is handing off the AD connection to a different LDAP server. The fix is traditionally to connect ProGet to the upstream LDAP server directly. As ProGet supports multiple user directories to be active, this typically isn't a problem. My guess is that Samba 4 uses referrals as a hack for some issue that came up with AD. Based on your comments, I'm guessing the hack is to fix something how it looks up groups (or recursive groups), but I can't confirm that for sure. In v5, we moved this user directory to Active Directory only and force the magic OID for recursive group searches that Microsoft uses.

You can test if the group portion is the issue by selecting the load by username option in the Test User Directory option and entering a group and username.

We have not seen any direct Samba 4 ProGet users in support as of yet, so Samba 4 quirks are still a bit unknown to us. Looking at the code, it is most likely due to ProGet running in a container versus installed on Windows. We have to use a different library for LDAP based on the operating system. In this case, I think the issue is that referral chasing is disabled by default on linux. We can enable that feature in code, but it will require some extra testing on our part because this affects ALL ldap queries on the docker version of ProGet.

Another option is to use the OpenLDAP/Generic LDAP user directory and configure it for Active Directory.

Thanks,
Rich

Hi @sai.pabbareddy,

The port can be changed to a custom port on the advanced tab.

It looks like the %s is actually working in ProGet, but instead this is a feature of osixia/openldap OpenLDAP Server. When the logs shows a ? mark in front of an attribute in a sqerch query (like ?uid=), it means that either the uid attribute is missing of the objectClass does not exist, which therefore cannot confirm that uid exists on those objects. It also could be that the value is hidden for security reasons and you have to change your logging level to see. If you can provide me with the LDAP object for ldapuser1, I can help you build the proper search queries.

Thanks,
Rich

Hi @sai.pabbareddy,

You will have to also set the Group Search Base as well. Can you test that and let me know if anything changes?

Also, what OpenLDAP server are you using to run these test with?

Thanks,
Rich

Hi @sai.pabbareddy,

We will be releasing ProGet 2026.11 this Friday, September 18th.

Thanks,
Rich

Hi @sai.pabbareddy,

The Domain controller host field does not accept a comma separated list. I meant first try setting that to the IP address of your domain controller and then test the connection. Then if that works, then change the value to the DNS name of the Domain Controller (just progetpoc.local) and test it again. That just helps to verify if there is a DNS lookup issue.

Thanks,
Rich