diff --git a/Directory.Build.props b/Directory.Build.props index 15d81ab..f9bb611 100644 --- a/Directory.Build.props +++ b/Directory.Build.props @@ -8,16 +8,6 @@ - - false - net462; - netcoreapp3.0 - $(WindowsFrameworks)$(CoreFrameworks) - win7-x64;win7-x86;win10-x64;win10-x86; - osx-x64;debian.8-x64;ubuntu.16.10-x64;ubuntu.16.04-x64;opensuse-x64;ol-x64;rhel-x64;fedora-x64;centos-x64 - $(WindowsRuntimeIdentifiers)$(UnixRuntimeIdentifiers) - - Microsoft Azure Relay Bridge https://github.com/Azure/azure-relay-bridge diff --git a/README.md b/README.md index 235c25e..e2b0e80 100644 --- a/README.md +++ b/README.md @@ -1,224 +1,224 @@ -# Azure Relay Bridge - -![img](https://ci.appveyor.com/api/projects/status/github/clemensv/azure-relay-bridge) - -The Azure Relay Bridge is a tool that allows creating TCP tunnels between any -pair of hosts, as long as those hosts each have outbound Internet connectivity on -port 443 (HTTPS) to the Azure Relay service. - -The Relay Bridge is designed for reaching networked assets in any environment -where it is impractical or impossible for those assets to be directly reachable -through a public IP address. - -For instance, if you need to reach an on-premises database or application from -a cloud-based solution, the on-premises assets are typically not accessible -from the public network. The Relay Bridge can help establishing a TCP tunnel -socket exclusive to a particular endpoint in such an on-premises environment, -and without the complexity of a VPN solution. - -Another example are on-premises applications that run behind network gateways -with dynamically assigned IP addresses, like in most residential and small-business -environments. An Azure Relay endpoint provides a stable network destination for -such application endpoints, without VPN, and without the complexity of a dynamic -DNS registration. - -Inside cloud and data-center environments, reaching into and bridging between -containerized workloads can also be tricky. The Relay Bridge can provide -every service inside a container instance with a stable and externally reachable -network address, and with the Relay's built-in load balancing support, you can -even bind multiple services inside separate container instances to the same name. -And you can do all that without configuring any kind of inbound network access -to the containers. - -Practically all TCP-based services, including HTTP(S), are compatible with -the Azure Relay Bridge. For services that require connections to be made from -both parties, the bridge can concurrently act as local and remote bridge. - -All Azure Relay endpoints are secure, requiring TLS 1.2+ (aka SSL) WebSocket -connections for all connections through the Relay, and both communicating -parties must provide an authorization token to establish a connection via the -Relay. - -The Azure Relay Bridge builds on this foundation and creates the illusion of a -local connection to the target service by ways of a *local forwarder* that listens -on a configured IP address and port, and that then forwards all incoming TCP -connections to a *remote forwarder* via the Azure Relay. The *remote forwarder* -connects each incoming connection to the target service. - - -## azbridge - -The Relay Bridge is a command line utility ("azbridge") with binary distributions -for Windows, macOS, and several Linux distributions. It can optionally also be -configured and run as a background service on Windows and Linux. - -Since the tool helps with scenarios not dissimilar to SSH tunnels (but without -requiring peer-to-peer connectivity) the command line syntax of *azbridge* uses -elements that resemble SSH's equivalent tunnel functionality, especially the -L -and -R arguments. The key difference to SSH is that *azbridge* always binds sockets -to an Azure Relay name, and that Azure Relay acts as the identifier for the -tunnel and as network rendezvous point. - -The bridge can either be used directly on the machines where a client or a server -resides, or it can be used as a gateway solution. When used as *local forwarder -gateway* (*-g* *-L*) and with externally resolvable listener addresses, the bridge -resides on a host in the network and allows connections from clients across the -network. The *remote forwarder* (*-R*) can always reach out to off-machine targets -within its network scope. - -When the bridge is used locally, the client can configure DNS names of the target -services in the local *hosts* file, picking a unique IP address out of the 127.x.x.x -range for each service, and then configuring a local forwarder for the respective -target address. Those addresses can only be reached on that local machine, shielding -the client from exposing TCP bridges to others. For instance, for reaching the remote -SQL Server "sql.corp.example.com", you would add an IP address like `127.1.2.3` to -the "hosts" file as `127.1.2.3 sql.corp.example.com`, and then use a local forwarder -configuration that refers to the `127.1.2.3` address, for example -`azbridge -L 127.1.2.3:1433:relay`. - -When used as a *local forwarder gateway*, you will need to use addresses that can be -reached by the clients in your network, and ideally have a multi-homed setup where -the gateway node has a network address, e.g. from the `10.x.x.x` range, per remote -target service host. For naming support, those network addresses should be registered -in a DNS service reachable and used by the clients in your network. A DNS service is -also required for resolving wildcard addresses, even for the local scenario. - -With a local configuration, when using *azbridge* to reach a Microsoft SQL Server -instance endpoint (port 1433) on a different network, you would use the following -constellation: - -* SQL Client connects to sql.corp.example.com:1433, whereby the local "hosts" file - re-maps the server name to a local address with the entry - `127.0.5.1 sql.corp.example.com` -* Local bridge on the same machine the client runs as - `azclient -L 127.0.5.1:1433:sql-corp-example-com -x {cxnstring}` -* Azure Relay has a configured endpoint - `wss://mynamespace.servicebus.windows.net/$hc/sql-corp-example-com` -* Remote Bridge on or near the server runs as - `azclient -R sql-corp-example-com:sql.corp.example.com:1433 -x {cxnstring}` -* SQL Server runs as `sql.corp.example.com:1433` - -The `{cxnstring}` represents the connection string for the configured -Azure Relay endpoint with appropriate send and/or listen permissions. - -The connection string can be obtained from the portal. - -Further details about how to use the tool and how to configure it can be found in -the [Configuration and Command Line Options](CONFIG.md) document. - -## Downloads - -This is an early preview. Unsigned (!) binaries are available for direct download -from the [Github Releases](../../releases) page for evaluation. Signed binaries will eventually -be available for download with common package managers. - -## Installation - -The tool has installation packages for a variety of platforms. All packages are -self-contained distributions, meaning they do not rely on a centrally installed -runtime. However, depending on the package type and platform, the installation -of some prerequisites may be required. - -### Windows - -The easiest way to install the bridge on Windows is by using the appropriate -*.msi package. The installer adds the tool to the PATH and also registers -the "azbridge" Windows service. The service is configured for on-demand -(manual) start at installation time. - -> **KNOWN ISSUE:** These early builds are not signed. Download the MSI file, -unblock it, and then install. Otherwise the application may not work as -expected. - -### Linux - -### Debian, Ubuntu, Linuxmint - -For Debian 8+ and all Debian-based distributions, like Ubuntu 16.04+ and Linuxmint 16+, -you can install the tool from the respective *.deb package with - -`sudo apt-get install ./{package-name}.deb` - -Using `apt-get` will automatically install the distribution prerequisites. The -.NET Core platform required by the tool is private and not installed machine-wide. - -The package install will put the tool into `/usr/share/azbridge`, place a machine-wide -configuration file into `/etc/azbridge`, add the tool to the PATH, and register two -BASH extensions for adding and removing entries from the `/etc/hosts` file: - -* `addhost {ipaddress} {name}` - adds an IP address with the given hostname to "hosts" -* `removehost {name}` - removes the entry for the given hostname - -### Fedora, CentOS, Red Hat Enterprise Linux - -For Fedora, CentOS, and Red Hat Enterprise Linux, you can install the tool from the -respective *.rpm package with - -`sudo yum install {package-name}.rpm` - -Using `yum` will automatically install the distribution prerequisites. The -.NET Core platform required by the tool is private and not installed machine-wide. - -The package install will put the tool into `/usr/share/azbridge`. - -> **KNOWN ISSUE 1:** The package will presently not install correctly if the install of -> documentation files is suppressed for `yum` and/or `dnf`. The is the case for many -> container base images. On CentOS, you should drop the respective configuration with -> `sed -i '/tsflags=nodocs/d' /etc/yum.conf` (RUN in a Dockerfile before installing -> the rpm) and on Fedora use `sed -i '/tsflags=nodocs/d' /etc/dnf/dnf.conf`. -> **KNOWN ISSUE 2:** The package does not yet perform any of the post-install tasks that -> the Debian package performs, meaning the tool is not added to the PATH. - -### Other distributions and platforms - -You can also install the tool from respective platform *.tar.gz archive. For Linux, -you need to [explicitly install Linux prerequisites for .NET Core](https://docs.microsoft.com/en-us/dotnet/core/linux-prerequisites?tabs=netcore2x) -for your respective distribution. For macOS, you need to [install prerequisites from -this list](https://docs.microsoft.com/en-us/dotnet/core/macos-prerequisites?tabs=netcore2x). - -## Building the code - -The repo contains a complete build and verification structure for all platforms. - -The Windows version MUST be built on Windows because the service integration requires -the full .NET Framework and the installer can only be built on Windows. You will at least -need the "Build Tools for Visual Studio 2017", and ideally a local install of -Visual Studio 2017 with desktop C# support. - -All other versions are built with the .NET Core 3.0 SDK. The DEB and -RPM packages are only created when building on a Unix (i.e. Linux or macOS) host. -dotb -The ideal build environment is a Windows 10/Windows Server 2016 host with Docker for -Windows installed. The `package-all.cmd` script will first build and package all Windows -targets, and then launch a docker-based build with the official Microsoft .NET Core 3.0 -SDK image for the remaining targets. The `package.sh` script will only build and package -the Unix targets, the `package.cmd` script only Windows targets. - -The latter two scripts are used with the AppVeyor build as well. - -All build output is placed into `./artifacts/build` - -## Tests - -Running the Unit tests and the Integration tests both require an Azure Relay namespace -to be available for use and configured. Before running any of the test scenarios, the -environment variable `AZBRIDGE_TEST_CXNSTRING` must be set to the Relay namespace -connection string (enclosed in quotes) on the build platform. - -An [Azure Resource Manager template](https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-template-deploy-cli) -to deploy a namespace with the definitions required for testing resides in -`./src/tools/azure/test-resource-template.json`. The template expects the name of a new namespace -and a region location as inputs. - -Once the template has been deployed using either Powershell or the Azure CLI, you can find -the "sendListenConnectionString" value (starts with "Endpoint...") in the returned output. -Copy and save that value for use in the `AZBRIDGE_TEST_CXNSTRING` environment variable. - -The Unit tests can be run from the command line with `dotnet test` with an .NET Core build. - -For integration testing that installs and executes the emitted packages, run `verify-build.cmd`/`verify-build.sh`. Expect for Windows, the integration tests depend on a -local Docker installation: The script cleans any existing images, builds CentOS, Debian, Fedora, and Ubuntu images with the newly built binaries, and then executes a series of tests on each image. - -## Contributions - -We're gladly accepting contributions. Please review the [contribution rules](CONTRIBUTING.md). +# Azure Relay Bridge + +![img](https://ci.appveyor.com/api/projects/status/github/clemensv/azure-relay-bridge) + +The Azure Relay Bridge is a tool that allows creating TCP tunnels between any +pair of hosts, as long as those hosts each have outbound Internet connectivity on +port 443 (HTTPS) to the Azure Relay service. + +The Relay Bridge is designed for reaching networked assets in any environment +where it is impractical or impossible for those assets to be directly reachable +through a public IP address. + +For instance, if you need to reach an on-premises database or application from +a cloud-based solution, the on-premises assets are typically not accessible +from the public network. The Relay Bridge can help establishing a TCP tunnel +socket exclusive to a particular endpoint in such an on-premises environment, +and without the complexity of a VPN solution. + +Another example are on-premises applications that run behind network gateways +with dynamically assigned IP addresses, like in most residential and small-business +environments. An Azure Relay endpoint provides a stable network destination for +such application endpoints, without VPN, and without the complexity of a dynamic +DNS registration. + +Inside cloud and data-center environments, reaching into and bridging between +containerized workloads can also be tricky. The Relay Bridge can provide +every service inside a container instance with a stable and externally reachable +network address, and with the Relay's built-in load balancing support, you can +even bind multiple services inside separate container instances to the same name. +And you can do all that without configuring any kind of inbound network access +to the containers. + +Practically all TCP-based services, including HTTP(S), are compatible with +the Azure Relay Bridge. For services that require connections to be made from +both parties, the bridge can concurrently act as local and remote bridge. + +All Azure Relay endpoints are secure, requiring TLS 1.2+ (aka SSL) WebSocket +connections for all connections through the Relay, and both communicating +parties must provide an authorization token to establish a connection via the +Relay. + +The Azure Relay Bridge builds on this foundation and creates the illusion of a +local connection to the target service by ways of a *local forwarder* that listens +on a configured IP address and port, and that then forwards all incoming TCP +connections to a *remote forwarder* via the Azure Relay. The *remote forwarder* +connects each incoming connection to the target service. + + +## azbridge + +The Relay Bridge is a command line utility ("azbridge") with binary distributions +for Windows, macOS, and several Linux distributions. It can optionally also be +configured and run as a background service on Windows and Linux. + +Since the tool helps with scenarios not dissimilar to SSH tunnels (but without +requiring peer-to-peer connectivity) the command line syntax of *azbridge* uses +elements that resemble SSH's equivalent tunnel functionality, especially the -L +and -R arguments. The key difference to SSH is that *azbridge* always binds sockets +to an Azure Relay name, and that Azure Relay acts as the identifier for the +tunnel and as network rendezvous point. + +The bridge can either be used directly on the machines where a client or a server +resides, or it can be used as a gateway solution. When used as *local forwarder +gateway* (*-g* *-L*) and with externally resolvable listener addresses, the bridge +resides on a host in the network and allows connections from clients across the +network. The *remote forwarder* (*-R*) can always reach out to off-machine targets +within its network scope. + +When the bridge is used locally, the client can configure DNS names of the target +services in the local *hosts* file, picking a unique IP address out of the 127.x.x.x +range for each service, and then configuring a local forwarder for the respective +target address. Those addresses can only be reached on that local machine, shielding +the client from exposing TCP bridges to others. For instance, for reaching the remote +SQL Server "sql.corp.example.com", you would add an IP address like `127.1.2.3` to +the "hosts" file as `127.1.2.3 sql.corp.example.com`, and then use a local forwarder +configuration that refers to the `127.1.2.3` address, for example +`azbridge -L 127.1.2.3:1433:relay`. + +When used as a *local forwarder gateway*, you will need to use addresses that can be +reached by the clients in your network, and ideally have a multi-homed setup where +the gateway node has a network address, e.g. from the `10.x.x.x` range, per remote +target service host. For naming support, those network addresses should be registered +in a DNS service reachable and used by the clients in your network. A DNS service is +also required for resolving wildcard addresses, even for the local scenario. + +With a local configuration, when using *azbridge* to reach a Microsoft SQL Server +instance endpoint (port 1433) on a different network, you would use the following +constellation: + +* SQL Client connects to sql.corp.example.com:1433, whereby the local "hosts" file + re-maps the server name to a local address with the entry + `127.0.5.1 sql.corp.example.com` +* Local bridge on the same machine the client runs as + `azclient -L 127.0.5.1:1433:sql-corp-example-com -x {cxnstring}` +* Azure Relay has a configured endpoint + `wss://mynamespace.servicebus.windows.net/$hc/sql-corp-example-com` +* Remote Bridge on or near the server runs as + `azclient -R sql-corp-example-com:sql.corp.example.com:1433 -x {cxnstring}` +* SQL Server runs as `sql.corp.example.com:1433` + +The `{cxnstring}` represents the connection string for the configured +Azure Relay endpoint with appropriate send and/or listen permissions. + +The connection string can be obtained from the portal. + +Further details about how to use the tool and how to configure it can be found in +the [Configuration and Command Line Options](CONFIG.md) document. + +## Downloads + +This is an early preview. Unsigned (!) binaries are available for direct download +from the [Github Releases](../../releases) page for evaluation. Signed binaries will eventually +be available for download with common package managers. + +## Installation + +The tool has installation packages for a variety of platforms. All packages are +self-contained distributions, meaning they do not rely on a centrally installed +runtime. However, depending on the package type and platform, the installation +of some prerequisites may be required. + +### Windows + +The easiest way to install the bridge on Windows is by using the appropriate +*.msi package. The installer adds the tool to the PATH and also registers +the "azbridge" Windows service. The service is configured for on-demand +(manual) start at installation time. + +> **KNOWN ISSUE:** These early builds are not signed. Download the MSI file, +unblock it, and then install. Otherwise the application may not work as +expected. + +### Linux + +### Debian, Ubuntu, Linuxmint + +For Debian 8+ and all Debian-based distributions, like Ubuntu 16.04+ and Linuxmint 16+, +you can install the tool from the respective *.deb package with + +`sudo apt-get install ./{package-name}.deb` + +Using `apt-get` will automatically install the distribution prerequisites. The +.NET Core platform required by the tool is private and not installed machine-wide. + +The package install will put the tool into `/usr/share/azbridge`, place a machine-wide +configuration file into `/etc/azbridge`, add the tool to the PATH, and register two +BASH extensions for adding and removing entries from the `/etc/hosts` file: + +* `addhost {ipaddress} {name}` - adds an IP address with the given hostname to "hosts" +* `removehost {name}` - removes the entry for the given hostname + +### Fedora, CentOS, Red Hat Enterprise Linux + +For Fedora, CentOS, and Red Hat Enterprise Linux, you can install the tool from the +respective *.rpm package with + +`sudo yum install {package-name}.rpm` + +Using `yum` will automatically install the distribution prerequisites. The +.NET Core platform required by the tool is private and not installed machine-wide. + +The package install will put the tool into `/usr/share/azbridge`. + +> **KNOWN ISSUE 1:** The package will presently not install correctly if the install of +> documentation files is suppressed for `yum` and/or `dnf`. The is the case for many +> container base images. On CentOS, you should drop the respective configuration with +> `sed -i '/tsflags=nodocs/d' /etc/yum.conf` (RUN in a Dockerfile before installing +> the rpm) and on Fedora use `sed -i '/tsflags=nodocs/d' /etc/dnf/dnf.conf`. +> **KNOWN ISSUE 2:** The package does not yet perform any of the post-install tasks that +> the Debian package performs, meaning the tool is not added to the PATH. + +### Other distributions and platforms + +You can also install the tool from respective platform *.tar.gz archive. For Linux, +you need to [explicitly install Linux prerequisites for .NET Core](https://docs.microsoft.com/en-us/dotnet/core/linux-prerequisites?tabs=netcore2x) +for your respective distribution. For macOS, you need to [install prerequisites from +this list](https://docs.microsoft.com/en-us/dotnet/core/macos-prerequisites?tabs=netcore2x). + +## Building the code + +The repo contains a complete build and verification structure for all platforms. + +The Windows version MUST be built on Windows because the service integration requires +the full .NET Framework and the installer can only be built on Windows. You will at least +need the "Build Tools for Visual Studio 2017", and ideally a local install of +Visual Studio 2017 with desktop C# support. + +All other versions are built with the .NET Core 3.0 SDK. The DEB and +RPM packages are only created when building on a Unix (i.e. Linux or macOS) host. +dotb +The ideal build environment is a Windows 10/Windows Server 2016 host with Docker for +Windows installed. The `package-all.cmd` script will first build and package all Windows +targets, and then launch a docker-based build with the official Microsoft .NET Core 3.0 +SDK image for the remaining targets. The `package.sh` script will only build and package +the Unix targets, the `package.cmd` script only Windows targets. + +The latter two scripts are used with the AppVeyor build as well. + +All build output is placed into `./artifacts/build` + +## Tests + +Running the Unit tests and the Integration tests both require an Azure Relay namespace +to be available for use and configured. Before running any of the test scenarios, the +environment variable `AZBRIDGE_TEST_CXNSTRING` must be set to the Relay namespace +connection string (enclosed in quotes) on the build platform. + +An [Azure Resource Manager template](https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-template-deploy-cli) +to deploy a namespace with the definitions required for testing resides in +`./src/tools/azure/test-resource-template.json`. The template expects the name of a new namespace +and a region location as inputs. + +Once the template has been deployed using either Powershell or the Azure CLI, you can find +the "sendListenConnectionString" value (starts with "Endpoint...") in the returned output. +Copy and save that value for use in the `AZBRIDGE_TEST_CXNSTRING` environment variable. + +The Unit tests can be run from the command line with `dotnet test` with an .NET Core build. + +For integration testing that installs and executes the emitted packages, run `verify-build.cmd`/`verify-build.sh`. Expect for Windows, the integration tests depend on a +local Docker installation: The script cleans any existing images, builds CentOS, Debian, Fedora, and Ubuntu images with the newly built binaries, and then executes a series of tests on each image. + +## Contributions + +We're gladly accepting contributions. Please review the [contribution rules](CONTRIBUTING.md). diff --git a/azure-pipelines.yml b/azure-pipelines.yml new file mode 100644 index 0000000..10452d3 --- /dev/null +++ b/azure-pipelines.yml @@ -0,0 +1,54 @@ +# Azure Pipelines Build +# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core + +trigger: +- master + +variables: + BuildVersion.MajorMinor: 0.3 + BuildVersion.Revision: $[counter(variables['Version.MajorMinor'], 0)] + BuildVersion: $(BuildVersion.MajorMinor).$(BuildVersion.Revision) + +jobs: + - job: WindowsBuild + workspace: + clean: all + pool: + vmImage: 'windows-latest' + + steps: + - task: DotNetCoreCLI@2 + inputs: + command: 'restore' + feedsToUse: 'select' + - task: MSBuild@1 + inputs: + solution: '**/*.sln' + msbuildArguments: '/t:clean,package /p:WindowsOnly=true /p:Configuration=Release /p:VersionPrefix=$(BuildVersion) /p:VersionSuffix=rel' + - task: DotNetCoreCLI@2 + inputs: + command: 'test' + arguments: '/p:WindowsOnly=true' + + - publish: $(System.DefaultWorkingDirectory)\artifacts\build\net462 + artifact: WindowsBuild + + - job: LinuxBuild + workspace: + clean: all + pool: + vmImage: 'ubuntu-latest' + + steps: + - task: ShellScript@1 + inputs: + scriptPath: './package.sh' + arguments: '/p:VersionSuffix=rel' + + - task: DotNetCoreCLI@2 + inputs: + command: 'test' + arguments: '/p:RuntimeIdentifier=ubuntu-x64 /p:Configuration=Debug' + + - publish: $(System.DefaultWorkingDirectory)/artifacts/build/netcoreapp3.0 + artifact: XBuild diff --git a/build/dependencies.props b/build/dependencies.props index 457415f..8fc767d 100644 --- a/build/dependencies.props +++ b/build/dependencies.props @@ -31,7 +31,8 @@ 3.0.0 3.0.0 2.4.1 - 2.3.1 + 5.3.1 + 2.4.1 2.4.1 2.4.0 12.0.3 diff --git a/build/repo.props b/build/repo.props index 11adb09..5df708a 100644 --- a/build/repo.props +++ b/build/repo.props @@ -6,7 +6,7 @@ netcoreapp3.0 $(WindowsFrameworks)$(CoreFrameworks) win7-x64;win7-x86;win10-x64;win10-x86; - osx-x64;debian.8-x64;ubuntu.16.10-x64;ubuntu.16.04-x64;opensuse-x64;ol-x64;rhel-x64;fedora-x64;centos-x64 + osx-x64;debian.8-x64;ubuntu.16.10-x64;ubuntu.18.04-x64;ubuntu.16.10-x64;ubuntu.18.10-x64;opensuse-x64;ol-x64;rhel-x64;fedora-x64;centos-x64 $(WindowsRuntimeIdentifiers)$(UnixRuntimeIdentifiers) diff --git a/package.cmd b/package.cmd index b6b85e3..4a6f6cc 100644 --- a/package.cmd +++ b/package.cmd @@ -1,3 +1,3 @@ if not "%APPVEYOR_BUILD_VERSION%"=="" set _VersionProp="/p:VersionPrefix=%APPVEYOR_BUILD_VERSION%" -msbuild /t:clean,restore,build /p:WindowsOnly=true /p:Configuration=Debug %_BuildProp% %_VersionProp% %* -msbuild /t:clean,restore,build,package /p:WindowsOnly=true /p:Configuration=Release %_BuildProp% %_VersionProp% %* \ No newline at end of file +if not "%BUILDVERSION%"=="" set _VersionProp="/p:VersionPrefix=%BUILDVERSION%" +msbuild /t:clean,build,package /p:WindowsOnly=true /p:Configuration=Release %_BuildProp% %_VersionProp% %* \ No newline at end of file diff --git a/package.sh b/package.sh index 7005d30..e37b96a 100755 --- a/package.sh +++ b/package.sh @@ -1,7 +1,7 @@ #!/bin/bash pushd "${0%/*}" > /dev/null if [ ! -z $APPVEYOR_BUILD_VERSION ]; then _VersionProp="/p:VersionPrefix=$APPVEYOR_BUILD_VERSION"; fi +if [ ! -z $BUILDVERSION ]; then _VersionProp="/p:VersionPrefix=$BUILDVERSION"; fi dotnet restore -dotnet msbuild /t:clean,restore,build /p:Configuration=Debug /p:TargetFramework=netcoreapp3.0 $_BuildProp $_VersionProp $@ -dotnet msbuild /t:clean,restore,build,package /p:Configuration=Release /p:TargetFramework=netcoreapp3.0 $_BuildProp $_VersionProp $@ +dotnet msbuild /t:Package /p:Configuration=Release /p:TargetFramework=netcoreapp3.0 $_BuildProp $_VersionProp $@ popd diff --git a/run.ps1 b/run.ps1 index bdce1ef..f5f88e3 100644 --- a/run.ps1 +++ b/run.ps1 @@ -1 +1 @@ -msbuild -t:Clean,Restore,Build $args \ No newline at end of file +msbuild -t:Clean,Build $args \ No newline at end of file diff --git a/src/Microsoft.Azure.Relay.Bridge/Microsoft.Azure.Relay.Bridge.csproj b/src/Microsoft.Azure.Relay.Bridge/Microsoft.Azure.Relay.Bridge.csproj index 893dd57..a98afc7 100644 --- a/src/Microsoft.Azure.Relay.Bridge/Microsoft.Azure.Relay.Bridge.csproj +++ b/src/Microsoft.Azure.Relay.Bridge/Microsoft.Azure.Relay.Bridge.csproj @@ -1,13 +1,7 @@  - false - net462; - netcoreapp3.0 - $(WindowsFrameworks)$(CoreFrameworks) - win7-x64;win7-x86;win10-x64;win10-x86; - osx-x64;debian.8-x64;ubuntu.16.10-x64;ubuntu.16.04-x64;opensuse-x64;ol-x64;rhel-x64;fedora-x64;centos-x64 - $(WindowsRuntimeIdentifiers)$(UnixRuntimeIdentifiers) + true @@ -64,6 +58,16 @@ + + + + + if [ -f /etc/profile.d/azbridge.sh ]; then + rm /etc/profile.d/azbridge.sh; + fi + + + ResXFileCodeGenerator diff --git a/src/azbridge/azbridge.csproj b/src/azbridge/azbridge.csproj index 7ad9093..9edd2f3 100644 --- a/src/azbridge/azbridge.csproj +++ b/src/azbridge/azbridge.csproj @@ -1,16 +1,16 @@  - false - net462; - netcoreapp3.0 - $(WindowsFrameworks)$(CoreFrameworks) - - win7-x64;win7-x86;win10-x64;win10-x86; - osx-x64;debian.8-x64;ubuntu.16.10-x64;ubuntu.16.04-x64;opensuse-x64;ol-x64;rhel-x64;fedora-x64;centos-x64 - $(WindowsRuntimeIdentifiers)$(UnixRuntimeIdentifiers) + true + true + false + true + + + + Debug Exe @@ -28,25 +28,24 @@ - - - - - /etc/azbridge/azbridge_config.yml + + + + /etc/azbridge/azbridge_config.svc.yml - - /etc/azbridge/azbridge_config.yml + + /etc/azbridge/azbridge_config.machine.yml - - - - - - + + + /etc/profile.d/azbridge.sh + 0555 + + + + + @@ -85,14 +84,7 @@ true - - - - - + @@ -117,11 +109,18 @@ - + - + + + + + + + + @@ -135,29 +134,22 @@ - + + - - - - + + + + - - - . /usr/share/azbridge/debpostinst.sh - . /usr/share/azbridge/debpostrm.sh - - + + + + + diff --git a/src/tools/bash/hostnames.sh b/src/azbridge/azbridge.sh similarity index 97% rename from src/tools/bash/hostnames.sh rename to src/azbridge/azbridge.sh index 12a355a..d0086a3 100755 --- a/src/tools/bash/hostnames.sh +++ b/src/azbridge/azbridge.sh @@ -1,5 +1,7 @@ #!/bin/bash +export PATH="$PATH:/usr/share/azbridge" + # remove specified host from /etc/hosts function removehost() { diff --git a/src/azbridge/debpostinst.sh b/src/azbridge/debpostinst.sh deleted file mode 100644 index bb6dc03..0000000 --- a/src/azbridge/debpostinst.sh +++ /dev/null @@ -1,11 +0,0 @@ -echo '#!/bin/bash' > /etc/profile.d/azbridge.sh -echo 'export PATH="\$PATH:/usr/share/azbridge"' >> /etc/profile.d/azbridge.sh -echo '. /usr/share/azbridge/hostnames.sh' >> /etc/profile.d/azbridge.sh -chmod a+x /etc/profile.d/azbridge.sh -if [ ! -d "/etc/azbridge" ]; then - mkdir /etc/azbridge; -fi -if [ ! -f "/etc/azbridge/azbridge_config.machine.yml" ]; then - mv /usr/share/azbridge/azbridge_config.machine.yml /etc/azbridge/azbridge_config.machine.yml; -fi -/etc/profile.d/azbridge.sh \ No newline at end of file diff --git a/src/azbridge/debpostrm.sh b/src/azbridge/debpostrm.sh deleted file mode 100644 index a634a4c..0000000 --- a/src/azbridge/debpostrm.sh +++ /dev/null @@ -1,3 +0,0 @@ -if [ -f /etc/profile.d/azbridge.sh ]; then - rm /etc/profile.d/azbridge.sh; -fi \ No newline at end of file diff --git a/test/docker/ubuntu/build.cmd b/test/docker/ubuntu/build.cmd index 0be9475..0993b37 100644 --- a/test/docker/ubuntu/build.cmd +++ b/test/docker/ubuntu/build.cmd @@ -10,7 +10,7 @@ if "%TargetFramework%"=="" set TargetFramework="netcoreapp3.0" pushd "%~dp0" if not exist "tmp" mkdir tmp -set DebFile=azbridge.%VersionPrefix%-%VersionSuffix%.ubuntu.16.04-x64.deb +set DebFile=azbridge.%VersionPrefix%-%VersionSuffix%.ubuntu.18.10-x64.deb copy /y ..\..\..\artifacts\build\%TargetFramework%\%DebFile% tmp > NUL docker build -f Dockerfile . --tag azbridge_ubuntu1604_test --build-arg deb_package=%DebFile% rd /s /q tmp diff --git a/test/docker/ubuntu/build.sh b/test/docker/ubuntu/build.sh index 577b1f7..58b19a9 100755 --- a/test/docker/ubuntu/build.sh +++ b/test/docker/ubuntu/build.sh @@ -10,7 +10,7 @@ if [ -z ${TargetFramework+x} ]; then TargetFramework='netcoreapp3.0'; fi pushd "${0%/*}" > /dev/null if [ ! -d "tmp" ]; then mkdir tmp; fi -DebFile=azbridge.$VersionPrefix-$VersionSuffix.ubuntu.16.04-x64.deb +DebFile=azbridge.$VersionPrefix-$VersionSuffix.ubuntu.18.10-x64.deb cp ../../../artifacts/build/$TargetFramework/$DebFile tmp/ > /dev/null docker build -f Dockerfile . --tag azbridge_ubuntu1604_test --build-arg deb_package=$DebFile diff --git a/test/unit/Microsoft.Azure.Relay.Bridge.Tests/Microsoft.Azure.Relay.Bridge.Tests.csproj b/test/unit/Microsoft.Azure.Relay.Bridge.Tests/Microsoft.Azure.Relay.Bridge.Tests.csproj index fa94a2c..12c90f8 100644 --- a/test/unit/Microsoft.Azure.Relay.Bridge.Tests/Microsoft.Azure.Relay.Bridge.Tests.csproj +++ b/test/unit/Microsoft.Azure.Relay.Bridge.Tests/Microsoft.Azure.Relay.Bridge.Tests.csproj @@ -1,16 +1,5 @@  - - false - net462; - netcoreapp3.0 - $(WindowsFrameworks)$(CoreFrameworks) - - win7-x64;win7-x86;win10-x64;win10-x86; - osx-x64;debian.8-x64;ubuntu.16.10-x64;ubuntu.16.04-x64;opensuse-x64;ol-x64;rhel-x64;fedora-x64;centos-x64 - $(WindowsRuntimeIdentifiers)$(UnixRuntimeIdentifiers) - - false Azure Relay Bridge Tests