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

It looks like when we migrated pgscan in to pgutil, the functionality for this was removed. We will add a new flag to pgutil builds scan called --do-not-scan-npm that will ignore scanning for npm packages. I should have this released later this week or early next week. I will let you know as soon as we push the change.

Thanks,
Rich

Hi @carl.westman_8110,

Always happy to help! I have actually already made the fix internally. If you would like, I can provide a pre-release build of ProGet 2026.13 that includes the fix.

Thanks,
Rich

Hi @carl.westman_8110,

I did a little more digging. The actual issue was that the Azure Simple API was including extra information in the response Content Type. That triggered our connector to switch to the old HTML based parsing, which prevented the files from being found. I have corrected this in PG-3399, which is due out October 16, 2026 in ProGet 2026.13.

Thanks,
Rich

Hi @Ashley,

I can confirm that F7\._proget_file_history_ is specific to the Feed with an ID 7.

Thanks,
Rich

Hi @carl.westman_8110,

I ran a test against our test Dev Ops instance. I created a connector and I used basic authentication with my Microsoft account username (my email) as the username and the PAT as the password. I found it was finding my package, but ADO's simple API was not returning the file list which is causing our connector to skip over it. We are currently investigating this further.

As a work around, have you tried importing those packages into your ProGet feed? You can do that by using Import Package -> Download Package from Another Source. That will allow you to import all the packages and version from your ADO artifact feed.

Thanks,
Rich

Hi @Ashley,

The F7\._proget_file_history_, is specific to the Feed with an ID 7. I'm guessing that is the asset feed that you disabled the history on. You can verify the ID by navigating to the Asset Directory, then click the Manage Directory button. Then in the URL you will see FeedId=. That number will be your feed id and should match 7. If so, then you can just delete F7\._proget_file_history_.

Please note, if you delete that folder and re-enable versions, the version history will no longer exist.

Thanks,
Rich

Hi @hardik.turakhia,

Using nginx as a reverse-proxy in front of ProGet is definitely the easiest way. I'm guessing you already took a look at our example nginx config file. When it comes to certificates, I find that it's easiest to use .pem files on Linux. There are a lot of guides out there on how to convert certificates to .pem files and configure them in nginx. The best source is to check with your SSL provider on how to create a fullchain (includes the intermediate certificates) .pem file. We do have some notes in the HTTPS on Windows guide in the update config section that has some commands on how to convert a .pfx file to .pem, which includes some crossover with converting .crt files to .pem files.

If you are planning to use a dynamic SSL provider like Let's Encrypt, certbot has an extension called certbot-nginx on most distros or via snap on ubuntu/debian distros. That will configure nginx for you.

Thanks,
Rich

Hi @sai.pabbareddy,

If you could pull a full LDAP trace/packate capture that would be great. I also setup a single-domain/single-dc. I can even share my setup as I used a VM and docker to set it up. My VM is a base alpine install with docker, docker-compose, and nano installed. Here is my the compose file I tested with. NOTE: my container uses the host network mode because that was the only way I could get it to bind the port in Samba. This is probably not needed if ProGet sat in the same Docker network as the Samba container.

version: '3.8'

services:
  samba-test-ad:
    image: diegogslomp/samba-ad-dc:latest
    container_name: samba_test_ad
    hostname: DC1
    privileged: true
    network_mode: host
    environment:
      - REALM=PLANETEXPRESS.COM
      - DOMAIN=PLANETEXPRESS
      - ADMIN_PASS=GoodNewsEveryone123!
      - DNS_FORWARDER=8.8.8.8
    # NOTE: "ports" was removed because network_mode: host opens the container ports on the host natively

  samba-provisioner:
    image: alpine:latest
    container_name: samba_provisioner
    depends_on:
      - samba-test-ad
    # Shares host network context to communicate with the main container smoothly
    network_mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    entrypoint:
      - /bin/sh
      - -c
      - |
        apk add --no-cache docker-cli
        echo "🚀 Monitoring Active Directory operational readiness..."

        while true; do
          if docker exec samba_test_ad /usr/local/samba/bin/samba-tool user list >/dev/null 2>&1; then
            break
          fi
          echo "⏳ Samba is compiling directory tree schema... checking back in 3s"
          sleep 3
        done

        echo "🔌 Active Directory Engine Online and Accepting Modifications!"

        echo "--- Creating Test Groups ---"
        docker exec samba_test_ad /usr/local/samba/bin/samba-tool group add ship_crew || true
        docker exec samba_test_ad /usr/local/samba/bin/samba-tool group add admin_staff || true

        echo "--- Creating Pre-populated Test Users ---"
        docker exec samba_test_ad /usr/local/samba/bin/samba-tool user create fry FryPassword123! --given-name='Philip' --surname='Fry' --mail-address='fry@planetexpress.com' || true
        docker exec samba_test_ad /usr/local/samba/bin/samba-tool user create leela LeelaPassword123! --given-name='Turanga' --surname='Leela' --mail-address='leela@planetexpress.com' || true
        docker exec samba_test_ad /usr/local/samba/bin/samba-tool user create professor ProfPassword123! --given-name='Hubert' --surname='Farnsworth' --mail-address='professor@planetexpress.com' || true

        echo "--- Assigning Group Members ---"
        docker exec samba_test_ad /usr/local/samba/bin/samba-tool group addmembers ship_crew fry,leela || true
        docker exec samba_test_ad /usr/local/samba/bin/samba-tool group addmembers admin_staff professor || true

        echo "✅ Active Directory data successfully populated! Setup complete."

Then for my ProGet configuration, I created a new V5: Active Directory and here were the settings:

• General
  • Name: V5: Samba 4
  • Domain: planetexpress.com
  • User name: Administrator
  • Password: GoodNewsEveryone123!
• Connection
  • Domain Controller Host: <IP Address of my VM>
  • LDAP Connection: Use LDAP

Then I tested using Load user by username for the user fry in the group ship_crew. For recursive groups I used the user Administrator and the Group Denied RODC Password Replication Group.

Then I added ship_crew to the Administer task and I logged in using fry/FryPassword123!.

Thanks,
Rich

Hi @sai.pabbareddy,

I realized that how I was enabling it in code left it disabled still in practice due to how that library handles search constraints. I enabled it the right way and did some testing against a Samba 4 server I setup locally and referral chasing ended up making it so slow that it was unusable. With that said, I'm not getting referral exceptions when testing against it, so there may actually be something else going on. Is there anything unique about how your Samba 4 server is configured?

Thank,
Rich

Hi @forbzie22_0253,

Unfortunately, this is still required. By default on Windows, HTTP.sys reserves all ports below port 1024. The netsh http add urlacl url=https://*:443/ user="NETWORK SERVICE" tells HTTP.sys that NETWORK SERVICE can register port 443 and listen to all traffic on it bypassing HTTP.sys.

If you specified a domain, https://my-domain.com:443 instead of https:://*:443, then HTTP.sys will handle all traffic but will allow NETWORK SERVICE to subscribe at that domain. HTTP.sys will still handle all traffic though. That will then cause the integrated web server (IWS) to use HTTP.sys instead of Kestrel, which is why we recommend the port binding method. This is all outside of IIS. That reason is also we added documentation on how to Use IIS as a reverse proxy.

Hope this helps!

Thanks,
Rich