NuGet Server problem

I'm trying to set up TeamCity to act as a NuGet server. Under Administration, the NuGet server is enabled, and I'm able to hit the "Authenticated Feed URL" via the browser to get a WSDL.

I'm also able to add the feed to Visual Studio after providing credentials. It can see what packages are present in the feed. However, when I try to actually add a package I get an "unable to connect to remote server" error.

Does anyone have any idea what this might be? Are there logs I can check to see what's going wrong?

I'm not sure if this matters, but we don't have SSL set up and there is no "Public Feed URL" available. TeamCity gives the warning, "NuGet Feed must contain server URL inside. Current TeamCity server configuration does not let TeamCity server to get original request URL from HTTP request. It looks like TeamCity server is wrongly configured with reverse proxy. Make sure reverse proxy and TeamCity server is configured to let TeamCity server know request real request URL", but I think that has to do with SSL, which we don't need as this is all internal to our network. (That warning is very poorly written by the way, I have no clue what it is supposed to mean even after reading documentation and googling)

Thanks.

13 comments
Comment actions Permalink

Hi Sam,

Do you have proxy server configured?
Please attach the build log and the screenshot of build step settings.

0
Comment actions Permalink

We have an IIS website which uses URL rewriting to redirect to TeamCity.

The build log doesn't show anything useful here. The NuGet package artifacts are showing up correctly for the build. I'm able to download them manually from the TeamCity site and they appear in the NuGet feed. I just can't download them from the feed.

0
Comment actions Permalink

Which TeamCity version do you use?
Please check the settings mentioned in the first answer for this question - http://serverfault.com/questions/382411/teamcity-nuget-feed-via-iis-arr-urlrewrite.
If nothing helps, please attach server logs.

0
Comment actions Permalink

We're on the latest version of TeamCity.

I didn't understand the first answer on the post you linked. I also followed the linked guide before and it did not work for us.

After some more digging, I'm pretty sure the request to download packages is not making it to the destination correctly, which is odd because it's able to list the packages with no problem.

We're using an IIS website which is bound to a certain name. We have a URL rewrite rule which rewrites anything with that name to localhost:port number. Is there something on the Tomcat side I should do?

What logs might be helpful here and where are they located?

0
Comment actions Permalink

I think maybe I may need to set do something akin to the instructions on this page?

However, this page only talks about Apache and Nginx, not IIS. I don't think IIS adds the x-forwarded-for field by default, so the section about the Valve doesn't seem applicable. I tried adding a Connector, following the directions on the page, but it doesn't seem to do anything.

Any suggestions?

0
Comment actions Permalink

Unfortunately we do not have example of IIS config. The proxy server should set the following headers (for more details see https://youtrack.jetbrains.com/issue/TW-21224):

  • X-Forwarded-Host
  • X-Forwarded-Server
  • X-Forwarded-For
  • Host

You can find an example of config in this forum thread: http://devnet.jetbrains.com/message/5493992#5493992.

0
Comment actions Permalink

Ok, I finally figured out the solution. I'll illustrate the whole thing here to help myself in the future and hopefully others.

This error message:

NuGetConfigProblem.png

means that TeamCity's TomCat instance needs to know about any reverse proxy you have set up in order for NuGet to work correctly.

I am using IIS as a reverse proxy to rewrite URLs to point to TeamCity. To configure this with TomCat correctly, I had to navigate the maze of outdated and incomplete documentation on JetBrains' website, blogs, forums, bugtrackers, and StackOverflow.

In fact, all I need to do was add two line items to the file "server.xml" located under ''TEAMCITY_HOME/conf/server.xml''.
NuGetConfigSolution.jpg
Steps:
1. Stop TeamCity's service.
2. Make a backup of server.xml.
3. Open server.xml.
4. Find the existing Connector node.
5. All you need to do is add two properties, proxyName and proxyPort.
     5a. proxyName- The domain name that your reverse proxy is publishing. (What clients will actually type into their browser.)
     5b. proxyPort- The port that your reverse proxy is publishing. This is almost certainly port 80, otherwise, what the heck was the point of making a reverse proxy?
6. Save the file and restart the TeamCity service. The error message on the NuGet config page in TeamCity should be gone.

JetBrains-
- Why the heck was this simple issue so hard to resolve? You need to update your documentation and include an IIS use case. NuGet is mainly a .NET/Microsoft thing, Microsoft makes IIS, it seems like a lot of your customers probably have IIS.
- Your warning message is horrible. It wasn't clear to me at all what it meant without a lot of research. In addition, clicking the question mark brought me to a page about SSL, which has literally nothing to do with the problem.
- Why doesn't the application itself handle this? It seems like if it knows there is a reverse proxy problem it should either be able to automatically update the server.xml file itself or provide fields within TeamCity itself to allow you to update the values with clear explanations.

0
Comment actions Permalink

In our documentation for Nginx we mentioned necessity to configure RemoteIpValve in server.xml:

<Valve

   className="org.apache.catalina.valves.RemoteIpValve"

   remoteIpHeader="x-forwarded-for"

   protocolHeader="x-forwarded-proto"

   internalProxies="192\.168\.0\.1"

   />



I believe this is equivalent to proxyName attribute.
0
Comment actions Permalink

Again, I'm using IIS, not Nginx. Also, IIS does not support x-forwarded-for without downloading and configuring an additional component (which I also couldn't get to work).

0
Comment actions Permalink

I understand that you're using IIS, but this part is for Tomcat, it is not related to proxy. If IIS does not support x-forwarded-for without additional configuration, then your solution looks ok and it is described in our documentation as well.
BTW, am I right that with this configuration if you go to TeamCity host directly (not proxy) you are redirected to proxy?

0
Comment actions Permalink

Yes, going to localhost now redirects to the proxy.

0
Comment actions Permalink

Ok, thank you. We'll add IIS specific section in our documentation. As to configuring HTTP proxy settings from the TeamCity itself, maybe we'll add it in the future, however this can be rather tricky.

0
Comment actions Permalink

Great. Thanks.

0

Please sign in to leave a comment.