Using Upstream Sources on Azure DevOps Server that's behind a HTTP Proxy - azure-devops

Our Azure DevOps Server infrastructure is behind all behind a HTTP Web Proxy server for all outbound traffic. We want to enable the Upstream Sources feature in Azure Artifacts, so that Azure DevOps downloads packages from nuget.org, etc. when they are requested.
We have however not found any documentation on how to make the Azure DevOps Server Application Tier (which we're assuming is making the outbound connection to the upstream sources). When we enable the upstream sources feature on one of our feeds, and adding nuget.org to it, we get the following error when trying to download any package in our feed:
Response status code does not indicate success: 500 (Internal Server Error - Failed to retrieve data from the upstream package source 'https://api.nuget.org/v3/index.json': An error occurred while sending the request. (DevOps Activity ID: F2C6C7EF-6651-4FB2-B650-5221ABC80F64)
When we disable the upstream sources, this error goes away, and package download succeeds from Azure DevOps cache instead of the upstream source.
Searching through the Application Tier's directories on the server, we saw the that the web.config for the DevOps website already has the following proxy settings applied:
<system.net>
<defaultProxy useDefaultCredentials="true"/>
</system.net>
We've modified this further to explicitly provide our proxy server address as such:
<system.net>
<defaultProxy useDefaultCredentials="true">
<proxy proxyAddress="http://<ourproxyserver>" />
<defaultProxy/>
</system.net>
And then tried again, but received the same Failed to retrieve data from the upstream package source error.
We've tried looking for more detailed error logs from Azure DevOps server but have not found any trace of it in the log files we've found. But we're not exactly sure where Azure DevOps Server writes its error logs too.
Is there something that we're are missing to get Upstream Sources working in our scenario? Is Azure DevOps Server capable of making outbound requests through a HTTP proxy?

It turns at that #Leo Liu-MSFT answer is not quite accurate; Azure DevOps Server can work behind a HTTP proxy server.
The problem in our instance was that the infrastructure team forgot to install the CA certificates for the proxy server on the host which was the actual cause of the HTTP 500 error message we were seeing.
Once the certificates were correctly installed, our best guess of updating the web.config file for the Azure DevOps site to use our proxy server details was correct.
<system.net>
<defaultProxy useDefaultCredentials="true">
<proxy proxyaddress="http://<ourproxyserver>" />
</defaultProxy>
</system.net>
See the following for additional proxy options: https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/network/proxy-element-network-settings
As a good measure, we also set the proxy server settings at the Windows server level too, using the following command in a console session:
netsh winhttp set proxy proxy-server=http://<ourproxyserver>
Once these steps were done, upstream sources started working in our Azure DevOps instance.

Using Upstream Sources on Azure DevOps Server that's behind a HTTP Proxy
I am afraid there is no such out-of-box way to use Upstream Sources on Azure DevOps Server behind a HTTP Proxy at this moment.
As workaround, we could disable the upstream sources, then place the following setting in each project’s nuget.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="http_proxy" value="http://proxy_hostname_or_ip:xxxx" />
<add key="https_proxy" value="http://proxy_hostname_or_ip:xxx" />
</config>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
</configuration>
Use this nuget.config file when you restore nuget packages.
Hope this helps.

Related

Whitelisting Azure DevOps Pipeline

I have a server in AWS, which is hosting a security tool. Azure DevOps supports this tool and I've installed the add on for it. I've added the step to my Pipeline and configured the service connection.
We are using Hosted Agents in a Cloud AZD instance.
When I run my pipeline, I get the following error:
##[error][TOOL] API GET '/api/server/version' failed, error was: {"errno":"ETIMEDOUT","code":"ETIMEDOUT","syscall":"connect","address":"1.1.1.1","port":443}
In my AWS security group, I have allowed the Inbound IP's for Azure DevOps listed here https://learn.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url?view=azure-devops&tabs=IP-V4#ip-addresses-and-range-restrictions
I have also allowed the Geographical IP's for listed in the json file here https://www.microsoft.com/en-us/download/details.aspx?id=56519
If I allow all traffic for 443 through the security group as a test, this works as expected. This is not a solution however as this is a security tool and should not be public.
In my pipeline, I added a task to run a curl command to inspect the IP's of the pipeline. Neither of these ranges appear in any list I can find published.
51.142.72.0/24
51.142.229.0/24
I was advised to post here by AzureDevOps on Twitter for some help, so hopefully someone can assist me here.

unable to connect to Azure DevOps Server from VS 2019

I just installed Azure Devops 2019 on my server. I can access the devops server fine through the web portal but when I try to connect using VS 2019 - team explorer - manage connections - Add Azure Devops Server I get a error "TF400324: Azure DevOps Service are not available from server http://xx.xx.xx.xx:8080/tfs."
I also see that VS add :8080/tfs to the IP I add. But thats not the correct adress. When using Team Foundation Server this adress was valid but Azure Devops does not use the same.
So how can I connect to the new Azure DevOps server from VS 2019?
So how can I connect to the new Azure DevOps server from VS 2019?
You can try:
1.Close all VS instances and then clean VS cache(%LocalAppData%\Microsoft\VisualStudio\16.xxx\ComponentModelCache) and TFS cache(%LocalAppData%\Microsoft\Team Foundation\xx\Cache).
2.Go to Control Panel -> User Accounts -> Manage your Credential -> Windows Credential, select the VSTS url to remove it.
3.Restart VS to re-connect to Devops server.
In addition:
1.Make sure you enter the correct URL. In VS if I don't enter correct URL of tfs instance, I would get this error:
2.Many factors can cause TF400324, just like above. So it could be better if you can share more details about your TF400324, remote name not resolve,Could not create SSL/TLS secure channel or what.
I had issues connecting to DevOps. I was using https and http. The trick for me was to "Change Public URL" in the "Azure DevOps Server Administration Console". This was done on the "Application Tier". Once I had this done the redirect for HTTPS worked because it used a fully qualified DNS name that matched the certificate I was using.
If you are not using HTTPS, then you may just have a DNS server issue. Check the DNS settings on the client PC and use something like ping or nslookup to see if the server name resolves to the correct IP address.

Cannot connect to service fabric secure cluster

I created new secure service fabric cluster on azure with cluster and admin client certificates in keyvault on azure. I installed the admin client certificate for current user and local machine stores but whenever I try to connect that cluster or explore it in browser its gave access denied error. I am also trying to connect from visual studio but it failed. In visual studio following is connection parameters:
<ClusterConnectionParameters ConnectionEndpoint="my.end.point.com:19000"
X509Credential="true"
ServerCertThumbprint="ClusterCertificateThumbPrint"
FindType="FindByThumbprint"
FindValue="AdminClientCertificateThumbPrint"
StoreLocation="CurrentUser"
StoreName="My" />
What I am doing wrong?
I experienced something similar, my issue was that I had the wrong servercertthumbprint. I created my service fabric cluster as part of the visual studio publish step and in that case the configuration looked like this:
<ClusterConnectionParameters ConnectionEndpoint="myservicefabricname:19000"
X509Credential="true"
ServerCertThumbprint="certicateThumbprint"
FindType="FindByThumbprint"
FindValue="certicateThumbprint"
StoreLocation="LocalMachine"
StoreName="My" />
The thumbprint used for the local certificate and the service fabric one has the same certificate thumbprint.
Additionally, it seems that even though I added the ClusterConnectionParameters in the xml config, when I went "Publish" and expanded "Advanced Parameters" I had to manually enter the values.
In case you don't know how to find the thumbprint you can follow this tutorial: https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/how-to-retrieve-the-thumbprint-of-a-certificate

VSTS Build Fails with SVN Forbidden Exception

I have setup a build process in VSTS that is pulling source code from a public facing SVN url. It works great when I manually queue the build from the dashboard or if I schedule a build to run at a certain time. However, when a build gets queued by continuous integration it throws the following exception:
An exception occurred while polling the repository. Error: Microsoft.TeamFoundation.Build2.Server.Extensions.BuildPollingException: Unable to connect to a repository at URL '<Path to the URL I am referencing>' --->
SharpSvn.SvnRepositoryIOForbiddenException: Unable to connect to a repository at URL '<Path to the URL I am referencing>' --->
SharpSvn.SvnRepositoryIOForbiddenException: Access to '<Path to the trunk of the repository>' forbidden
When I look at the event log on the server that Subversion lives on, it shows that the build agent is trying to access the URL with an anonymous login, hence the exception I am seeing.
Has anyone ran into this before? I know I have configured the service endpoint correctly with user credentials since it works when I manually fire off or schedule queue the build. I've done pretty extensive searching on this topic but have not found much info that involves VSTS and SVN issues. Any guidance or questions will be greatly appreciated.
The CI's Polling Job is executed by the Job Agent on the TFS server. Apparently, your Job Agent is configured to run as NT AUTHORITY\NETWORK SERVICE (i.e., as DOMAIN\TFSSERVER$). On the other hand, it looks like you VisualSVN Enterprise instance is configured to use NTLM. In this case, basic credentials are not used by the SharpSvn library the Polling Job uses to access the repository. Unfortunately, that's SharpSvn restriction. You either should provide the computer account (DOMAIN\TFSSERVER$) with the READ access to the SVN repository in the VisualSVN server configuration (to continue using NTLM), or disable NTLM on the VisualSVN server to switch to Basic authentication.
[Few technical details]The anonymous requests you see in SVN logs are part of the normal HTTP request flow implemented in the SharpSvn library:
The library first submits an anonymous request to the server.
If the server rejects the request, the library inspects the WWW-Authenticate response headers to detect the authentication scheme
requested by the server.
The WWW-Authenticate: NTLM header has a higher priority comparing to WWW-Authenticate: Basic. That's why username and password
specified in the connection endpoint are not used at all.
If only the WWW-Authenticate: Basic header is present in the response, the library uses a callback function provided by the client
To request credential information. At this point username and
the password specified in the connection endpoint is provided to the
library by the Polling Job.
[Note 1] The Polling Job does not download any sources from the SVN repository, it only requests the list of files changed since its last successful execution and decided if it's time to schedule a build.
[Note 2] If the Polling job continuously fails for the same reason, it reports each 100th failure to TFS as a failed build providing a reason of the failure.
Alex
I look to be having a similar issue. Using TFS 2015 Update 3 and VisualSVN Server 3.4.6. I get the same error with CI polling. On the SVN Server I get the following errors every time TFS polls: Access denied: 'TFSSERVER$' OPTIONS : [client ]
Here TFSSERVER$ is the computer name of our TFS Server.
So I gave DOMAIN\TFSSERVER$ Read Only permissions at the root of the repository and then things worked OK. Not happy that I had to do that of course.
Filed this bug about it: SVN CI Polling Uses TFS Machine Account Not SVN Account Set in the Service EndPoint
There isn't any big difference between CI and manual/scheduled build for SVN repository. When you configure it to continuous integration, it just keeps checking the SVN repository by the Polling interval you set and then run the build if there is any new change. The only difference between them is that you need to set "Filters" for CI and base on the access forbidden error message you get, you don't have the permission to read the path. So you need to check if your account has the read permission to the path you set in "Filters".

Handshaking with Octopus server fails from a TeamCity agent

We've been successfully using TeamCity and Octopus on a single machine, and now we have added a new build agent due to growing number of simultaneous builds. I have set up a new Octopus Tentacle and verified that Tentacle is reachable from the Octopus server in Listener role. However,any build that uses Octopack fails when executed on the new TeamCity agent. Here is an extract from the build log:
Running command: octo.exe create-release --server
servername:8443 --apikey SECRET --project NRK Bridge (Legacy)
--enableservicemessages --version 0.0.0.662 --deployto Dev --waitfordeployment --package=NRK.Bridge.Web:0.0.0.662 --packageversion=0.0.0.662
[12:06:02]Creating Octopus Deploy release
[12:06:02]Octopus Deploy Command Line Tool, version 2.0.8.22
[12:06:03]Handshaking with Octopus server: servername:8443
[12:06:06]The following certificate errors were
encountered when establishing the HTTPS connection to the server:
RemoteCertificateChainErrors
[12:06:06]Certificate subject name: CN=servername
[12:06:06]Certificate thumbprint: 79C26(...)
[12:06:07]The following certificate errors were encountered when
establishing the HTTPS connection to the server:
RemoteCertificateChainErrors
[12:06:07]Certificate subject name: CN=servername
[12:06:07]Certificate thumbprint: 79C26(...)
[12:06:08]The following certificate errors were encountered when
establishing the HTTPS connection to the server:
RemoteCertificateChainErrors
What I noticed is that the certificate thumbprint in the build log is different from thumbprints shown in Octopus server machine page. I tried to generate a new API key and re-register a Tentacle. Am I overlooking something here?
Did you copy the Api key into Team City? The api key is different to thumb prints. Api Key can be found in Octopus Admin section, under users tab.