Can you import a package to local feed A from local feed B (which uses a remote connector)?

[Eric Cain]

I have a feed for a specific project (let's call that feed A), and another feed that proxies the NuGet official feed (that's feed B). If I try to add a package to feed A from feed B by specifying the local, proxied feed's URL (e.g., http://server:port/nuget/FeedB), the package name, and version, I get this error in the UI: "The package could not be installed. The package was not found on the remote repository." I do not show any errors in ProGet's error logs. The error occurs regardless of whether I have pulled the package to my local feed from the remote connector.

If I use the external URL that Feed B's remote connector uses (e.g., https://nuget.org/api/v2) then the package loads successfully.

Product: ProGet
Version: 3.5.5

[Alana]

Generally speaking this should work, but unfortunately NuGet is extremely complicated, so any little detail could make this not work.

Please provide the exact steps to reproduce this, including the package name/id/etc rom nuget.org that you're trying to get. We can then try to repro it here.

[Eric Cain]

Thanks for the reply, Alana. For this repro, the ProGet server is running behind a proxy, and ProGet is correctly configured to connect through that proxy. Hopefully this will help you figure out what's going on, or what I'm doing wrong.

1. Create FeedA, which has no connectors

---

2. Create FeedB which has a connector to the public NuGet.org feed

---

3. Verify that the log4net package appears in FeedB

---

4. Attempt to pull the log4net package from ProGet's FeedB into FeedA via Add Package/Pull From Another Repository

---

5. Receive this error

---

6. Now try to pull log4net from the public NuGet.org feed into FeedA

---

7. Works!

---

8. There are no failures in the event log

[Dean]

I've just followed those steps exactly on a test instance and I can't seem to reproduce this. Perhaps it's attempting to route the request through the proxy server. How do you have proxying configured? Is it set up to use the OS defaults or manually specified? Either way, is it set to bypass local addresses for proxying?

[Eric Cain]

Hi Dean,

I ruled out the proxy since I know I'm getting to the server; I can see it in my IIS logs. What I did notice, is that when I tried to load the package from FeedB into FeedA again, the user the ProGet web app was using to authenticate was DOMAIN\MACHINENAME$ (e.g., NETWORK SERVICE). This account didn't have any rights to access ProGet, so the attempt was failing.

My ProGet instance is hosted in IIS and the app pool was running using the application pool ID, so I first tried allowing DOMAIN\MACHINENAME$ access to the feed, but ProGet ignored that principal (I'm guessing you don't allow computer accounts to be added from AD). Next, since I have multiple service accounts lying around, I made the following configuration changes:

1. Granted access to the service account to view FeedB in ProGet's Privileges & Roles
2. Granted the service account access to the ProGet database, and put the user in the ProGetUser_Role role
3. Changed the app pool of the site that the ProGet web app runs under to use the service account credentials
4. Added my service account to the IIS_IUSRS group

When I tried loading the package again, it worked correctly. So, the root cause here was that when ProGet is hosted in IIS using a built-in account that translates to DOMAIN\MACHINENAME$, you have to do some additional configuration to grant ProGet access to itself.

Although this solved the problem, it would be handy to allow the specification of built-in accounts like BUILTIN\NETWORK SERVICE, or use the computer principal from AD such as DOMAIN\MACHINENAME$ when assigning privileges.

Thanks!