主页 / server / 问题

问题[azure](server)

Martin Hope
Michael Brown
Asked: 2024-10-10 21:24:55 +0800 CST
  • 5

我在使用 AzCopy 时遇到了一个问题，我的脚本在 CMD 中运行正常，但通过批处理文件执行时却出现身份验证错误。以下是情况的细分：

目的是通过任务计划程序将我们的日常文件备份到存储帐户中；很可能每天/运行仅 1 个文件。

我的批处理脚本：

@echo off
cd "C:\Program Files\AzCopy"
azcopy cp "G:\Backup\UATBackups\*" "https://<storage-account-name>.blob.core.windows.net/test/?sp=rw&st=2024-10-08T15:28:58Z&se=2024-10-08T23:28:58Z&spr=https&sv=2022-11-02&sr=c&sig=<SAS-token>" --recursive=true --block-blob-tier=Cold --overwrite=false

当我在 CMD 中手动运行此命令时：（导航到 AzCopy 目录之后）

azcopy cp "G:\Backup\UATBackups\*" "https://<storage-account-name>.blob.core.windows.net/test/?sp=rw&st=2024-10-08T15:28:58Z&se=2024-10-08T23:28:58Z&spr=https&sv=2022-11-02&sr=c&sig=<SAS-token>" --recursive=true --block-blob-tier=Cold --overwrite=false

它运行完美，并且所有文件都按预期上传。

但是，当我运行批处理文件时，我得到：

RESPONSE Status: 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.

我还尝试修改批处理文件，以便它打开 CMD 并运行命令，就像我手动执行一样：

start cmd /k ""C:\Program Files\AzCopy\azcopy.exe" cp "G:\Backup\UATBackups\*" "https://<storage-account-name>.blob.core.windows.net/test/?sp=rw&st=2024-10-08T15:28:58Z&se=2024-10-08T23:28:58Z&spr=https&sv=2022-11-02&sr=c&sig=<SAS-token>" --recursive=true --block-blob-tier=Cold --overwrite=false"

但这给了我：

RESPONSE 401: 401 Server failed to authenticate the request. Please refer to the information in the www-authenticate header.
ERROR CODE: NoAuthenticationInformation

我已经检查过的事项：

  • SAS 令牌有效且未过期。
  • VM 时间已正确同步。
  • 我使用同一个用户帐户来运行 CMD 和批处理文件。

我的问题：

  • 为什么当我在 CMD 中手动运行该命令时，它能完美运行，但通过批处理文件运行时（即使使用相同的用户帐户）却出现 403 错误？
  • 需要改变什么以及我如何解决这个问题！

任何帮助或建议都将不胜感激。谢谢！

azure
Martin Hope
Swiftniscate
Asked: 2024-08-31 05:23:49 +0800 CST
  • 4

我在 Azure 中安装了一台 centos 机器，它的 ip 地址是 10.5.0.4，然后我在 Azure 中安装了一台 openVPN 机器，它的私有地址是 10.6.0.4。我在 centOS 和 openVPN 网络之间进行了对等连接，并且运行良好，所以我可以互相 ping 通。

当我用电脑连接到 openVPN 时，我的本地电脑被赋予了私有 IP 地址 10.6.0.2。我可以从 10.6.0.2 ping 到 10.6.0.4，这没问题，但我无法从 10.6.0.2 ping 到 10.5.0.4。我认为 openVPN 不会将 10.6.0.2 流量路由到 10.5.0.4。我该如何进行这种路由？

azure
Martin Hope
The Fabio
Asked: 2024-08-08 08:50:11 +0800 CST
  • 6

在 Azure devops 脚本中将 signtool.exe 与“Azure 受信任签名帐户”结合使用时，该过程挂起在：

正在提交摘要以供签名...

这是我们在 Azure devops 使用的 PowerShell 脚本块，它基于Azure 受信任签名帐户的文档：

    - task: PowerShell@2
      displayName: Preparing Windows EXE signing tools
      inputs:
        targetType: 'inline'
        workingDirectory: $(Pipeline.Workspace)/windows-signing-tool
        script: |
          Set-PSDebug -Trace 1
          Invoke-WebRequest -Uri https://dist.nuget.org/win-x86-commandline/latest/nuget.exe -OutFile .\nuget.exe
          .\nuget.exe install Microsoft.Windows.SDK.BuildTools -Version 10.0.22621.3233 -x
          .\nuget.exe install Microsoft.Trusted.Signing.Client -Version 1.0.53 -x
          ./"Microsoft.Windows.SDK.BuildTools\bin\10.0.22621.0\x86\signtool.exe" sign /v /debug /fd SHA256 /tr "http://timestamp.acs.microsoft.com" /td SHA256 /dlib "Microsoft.Trusted.Signing.Client\bin\x86\Azure.CodeSigning.Dlib.dll" /dmdf ".\signing-metadata.json" "<obscurecFolder>/MyProject.exe"

日志输出：

========================== Starting Command Output ===========================
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'D:\a\_temp\c16ea5da-1997-4e32-9ef5-9e9268766943.ps1'"
DEBUG:    5+  >>>> Invoke-WebRequest -Uri https://dist.nuget.org/win-x86-commandline/latest/nuget.exe -OutFile 
.\nuget.exe
DEBUG:    6+  >>>> .\nuget.exe install Microsoft.Windows.SDK.BuildTools -Version 10.0.22621.3233 -x
Feeds used:
  https://api.nuget.org/v3/index.json
  C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\



Attempting to gather dependency information for package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233' with respect to project '<obscurecFolder>\windows-signing-tool', targeting 'Any,Version=v0.0'
Gathering dependency information took 751 ms
Attempting to resolve dependencies for package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233'
Resolved actions to install package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233'
Retrieving package 'Microsoft.Windows.SDK.BuildTools 10.0.22621.3233' from 'nuget.org'.
  GET https://api.nuget.org/v3-flatcontainer/microsoft.windows.sdk.buildtools/10.0.22621.3233/microsoft.windows.sdk.buildtools.10.0.22621.3233.nupkg
  OK https://api.nuget.org/v3-flatcontainer/microsoft.windows.sdk.buildtools/10.0.22621.3233/microsoft.windows.sdk.buildtools.10.0.22621.3233.nupkg 7ms
Installed Microsoft.Windows.SDK.BuildTools 10.0.22621.3233 from https://api.nuget.org/v3/index.json to C:\Users\VssAdministrator\.nuget\packages\microsoft.windows.sdk.buildtools\10.0.22621.3233 with content hash v67zwCb9JOpfPxdSroZukIKHruU6FUB+KwcmSPcVvUFyYtcyvcUign5y8jPQNi54CVzWvaTg646e62LbanUkxg==.
Adding package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233' to folder '<obscurecFolder>\windows-signing-tool'
Added package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233' to folder '<obscurecFolder>\windows-signing-tool'
Successfully installed 'Microsoft.Windows.SDK.BuildTools 10.0.22621.3233' to <obscurecFolder>\windows-signing-tool
Executing nuget actions took 5.09 sec
DEBUG:    7+  >>>> .\nuget.exe install Microsoft.Trusted.Signing.Client -Version 1.0.53 -x
Feeds used:
  C:\Users\VssAdministrator\.nuget\packages\
  https://api.nuget.org/v3/index.json
  C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\



Attempting to gather dependency information for package 'Microsoft.Trusted.Signing.Client.1.0.53' with respect to project '<obscurecFolder>\windows-signing-tool', targeting 'Any,Version=v0.0'
Gathering dependency information took 1.09 sec
Attempting to resolve dependencies for package 'Microsoft.Trusted.Signing.Client.1.0.53' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Microsoft.Trusted.Signing.Client.1.0.53'
Resolved actions to install package 'Microsoft.Trusted.Signing.Client.1.0.53'
Retrieving package 'Microsoft.Trusted.Signing.Client 1.0.53' from 'nuget.org'.
  GET https://api.nuget.org/v3-flatcontainer/microsoft.trusted.signing.client/1.0.53/microsoft.trusted.signing.client.1.0.53.nupkg
  OK https://api.nuget.org/v3-flatcontainer/microsoft.trusted.signing.client/1.0.53/microsoft.trusted.signing.client.1.0.53.nupkg 9ms
Installed Microsoft.Trusted.Signing.Client 1.0.53 from https://api.nuget.org/v3/index.json to C:\Users\VssAdministrator\.nuget\packages\microsoft.trusted.signing.client\1.0.53 with content hash lou6NowgbY3S/Yn0+WSeI+Dl8SCmvmqkeAzt2Pgs51QL5/kHh+w8FJgutYGM+j2TB11a9zNc0EBWjOGWdwWtoQ==.
Adding package 'Microsoft.Trusted.Signing.Client.1.0.53' to folder '<obscurecFolder>\windows-signing-tool'
Added package 'Microsoft.Trusted.Signing.Client.1.0.53' to folder '<obscurecFolder>\windows-signing-tool'
Successfully installed 'Microsoft.Trusted.Signing.Client 1.0.53' to <obscurecFolder>\windows-signing-tool
Executing nuget actions took 1.45 sec

这意味着前三个命令运行正常......

之后我们有：

./"Microsoft.Windows.SDK.BuildTools\bin\10.0.22621.0\x86\signtool.exe" sign /v /debug /fd SHA256 /tr "http://timestamp.acs.microsoft.com" /td SHA256 /dlib "Microsoft.Trusted.Signing.Client\bin\x86\Azure.CodeSigning.Dlib.dll" /dmdf ".\signing-metadata.json" "<obscurecFolder>/MyProject.exe"

Trusted Signing

Version: 1.0.53

"Metadata": {
  "Endpoint": "https://eus.codesigning.azure.net",
  "CodeSigningAccountName": "ObscuredTrustedSignAccName",
  "CertificateProfileName": "ObscuredTrustedSignAccCertificateProfileName",
  "ExcludeCredentials": []
}

Submitting digest for signing...

在本地执行时，同样的最后一条命令的输出是：

Trusted Signing

Version: 1.0.60

"Metadata": {
  "Endpoint": "https://eus.codesigning.azure.net",
  "CodeSigningAccountName": "ObscuredTrustedSignAccName",
  "CertificateProfileName": "ObscuredTrustedSignAccCertificateProfileName",
  "ExcludeCredentials": []
}

Submitting digest for signing...

OperationId 12121212-acbc-acbc-acbc-49603042d34c: InProgress

Signing completed with status 'Succeeded' in 20.5563194s

Successfully signed: <obscurecFolder>/MyProject.exe

Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0

为什么 signtool.exe 在由 devops 运行时无法继续，但在我的本地环境中却可以正常运行？

azure
Martin Hope
JohnLBevan
Asked: 2024-08-02 00:32:34 +0800 CST
  • 5

我有一个应用程序网关，我的后端设置配置了健康探测，允许状态 200-499 为健康（我之所以包含4xx系列代码，是因为某些解决方案的站点根目录返回 404，而其他路径下有内容，而某些站点会自动为未经授权的用户返回 403 / 我不希望这些影响后端健康状态 / 我希望我的解决方案尽可能通用，这样我就可以重复使用一系列站点上的相同设置，以尽量减少新站点加入时的工作量）。

但是，我的后端健康状况显示我的一个站点正在返回HTTP 463状态代码（因此后端仍然健康，但此响应是意外的）。此外，如果我导航到与此后端关联的侦听器的 URI，我会陷入 301 重定向到/来自同一站点。我确实配置了重定向：

  • 对于未经身份验证的用户，后端会从 重定向/到/login.aspx。这使用相对路径，因此不受 AppGW 的主机名或前端与后端协议的影响。
  • AppGW 有 HTTP 和 HTTPS 监听器，HTTP 规则重定向到 HTTPS 监听器，而 HTTPS 规则与后端相关联。

然而，即使我删除这些功能，仍然会得到相同的行为。

同一 AppGW 上的其他站点以相同的方式设置，但没有这个问题。

我有一个用于测试重定向的 PowerShell 脚本：Get-HttpUrlRedirects。如果我们假设配置为example.com，则运行的预期输出Get-HttpUrlRedirects -Url 'http://example.com' -Verbose将是：

VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/login.aspx]
Url                                             StatusCode
---                                             ----------
http://example.com/                                    301
https://example.com/                                   302
https://example/login.aspx                             200

而实际输出是：


VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
Url                                             StatusCode
---                                             ----------
http://example.com/                                    301
https://example.com/                                   301
VERBOSE: Redirecting to [https://example.com/]
https://example.com/                                   301
VERBOSE: Redirecting to [https://example.com/]
https://example.com/                                   301
VERBOSE: Redirecting to [https://example.com/]

# etc - I hit ctrl + C to terminate when I see this loop occurring
azure
Martin Hope
Mark
Asked: 2024-06-22 22:29:33 +0800 CST
  • 6

在 AWS 中 - 我们可以通过创建角色并将 IAM 角色附加到 EC2 实例来从 ec2 实例访问 s3 存储桶。然后 ec2 实例可以从 VM 访问 s3 存储桶，而无需 ACCESSS_KEY 和 SECRET_KEY。

如何使用 Azure VM 和 Azure 存储实现同样的功能？我想使用 Azure CLI 访问 Azure 存储或其他服务，但无需登录，而是使用角色并将其附加到 Azure VM。

azure
Martin Hope
Mark
Asked: 2024-06-20 20:28:24 +0800 CST
  • 6

我正在尝试在 Azure 上设置一个 nat 实例以用于测试目的，但它根本不起作用。

我能够使用以下步骤在 AWS 上创建 nat 实例。但我无法在 Azure 中执行相同的操作。

我在 Azure 公共子网实例虚拟机（10.0.0.6）上尝试了以下设置

vi /etc/sysctl.conf
add "net.ipv4.ip_forward=1" to sysctl.conf
sysctl -p

sudo /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo /sbin/iptables -F FORWARD
sudo service iptables save

在私有子网 Azure VM 中，我尝试添加指向 10.0.0.6 IP 的默认路由0.0.0.0/0。我应该改用route table吗？

但这不起作用。私有子网 VM 无法 ping google。我也允许 NSG 中的所有 IP。

知道为什么这不起作用吗？另外，我在 Google 上找不到任何有关 Azure Nat 实例的文章，好像没人尝试过。

azure
Martin Hope
Sy Zee
Asked: 2024-06-19 13:46:25 +0800 CST
  • 4

我需要导致 Azure 中磁盘存储限制的标准。

高磁盘 IOPS（我在指标中可以看到多高的百分比）是否会导致限制？

导致 Azure 磁盘限制的因素有哪些？

azure