我有一个尝试运行docker login命令的系统，它是一个无头的 linux 系统，但不幸的是只安装了Docker Credentials Helper docker-credential-secretservice。
这意味着我收到以下错误：
Error saving credentials: error storing credentials - err: exit status 1, out: `Cannot autolaunch D-Bus without X11 $DISPLAY`
我认为这是有道理的：
默认情况下，Docker 在每个平台上查找本机二进制文件，即 macOS 上的“osxkeychain”、Windows 上的“wincred”和 Linux 上的“pass”。一个特殊情况是，在 Linux 上，如果 Docker 找不到“pass”二进制文件，它将回退到“secretservice”二进制文件。如果这些二进制文件都不存在，它会将凭据（即密码）以 base64 编码存储在上述配置文件中。
由于secretservicehelper 使用 GUI 凭据存储，因此它会尝试打开一个窗口，而在无头系统上则无法打开该窗口。
我无法控制系统，因此我无法删除/usr/bin/docker-credential-secretservice文件以强制docker login回退到配置文件而不是使用secretservice帮助程序。
我可以做的是在用户的主文件夹中创建和列出文件。我试过这样运行命令：
docker --config ./docker login -u <user-name> -p <password> <repository>
我的印象是登录命令会config.json在 ./docker 中创建一个（我注意到docker login如果文件夹不存在会创建它）。这适用于没有安装任何帮助程序的系统，但不适用于相关系统。
我还尝试使用以下内容创建一个~/.docker/config.json： …
我一直在寻找某种官方文档，了解从 AWS API Gateway 等集成发送到 AWS Lambda 的数据类型。我已经能够在 API Gateway 文档中找到一些“示例”，例如此处和此处。创建一个仅将输入事件回显为输出并检查输出的 Lambda 也相对容易。例如（使用带有LAMBDA_PROXY集成的 REST 类型 API），您会得到类似以下内容的信息：
{
"resource": "/another/{parameter}",
"path": "/another/some-parameter",
"httpMethod": "GET",
"headers": {
"Accept": "*/*",
"Accept-Encoding": "gzip, deflate, br",
...
},
"multiValueHeaders": {
"Accept": [
"*/*"
],
"Accept-Encoding": [
"gzip, deflate, br"
],
...
},
"queryStringParameters": null,
"multiValueQueryStringParameters": null,
"pathParameters": {
"parameter": "some-parameter"
},
"stageVariables": null,
"requestContext": {
"resourceId": "some-id",
"resourcePath": "/another/{parameter}",
"httpMethod": "GET",
...
},
"body": null,
"isBase64Encoded": false
}
但这并没有告诉我我总是可以或只是有时期望在有效负载或字段类型中包含哪些字段。 …
documentation amazon-web-services aws-lambda aws-api-gateway
我已经像这样设置了一个 Lambda：
exports.handler = async (event) => {
throw new Error('I AM SAD');
};
它既可以由 SNS 主题调用，也可以从 API 网关调用。
我还设置了一个带有两个订阅的 SNS 主题；一种直接向 Lambda 发送消息（使用 Lamba 协议）；另一个通过 API 网关 (HTTPS) 发送。我希望 SNS 在 lambda 失败时重试发送消息。但它似乎只能通过 API Gateway 工作。当直接调用 Lambda 时，SNS 只尝试一次（并报告 SUCCESS）。
我知道即使对于 SNS -> Lambda 也有某种重试策略，但是这什么时候触发？对于 SNS -> HTTP，它似乎在收到 HTTP 错误代码时触发。
来自Amazon SNS Dead-Letter Queues - Amazon Simple Notification Service：
当 Amazon SNS 具有过时的订阅元数据时，可能会发生客户端错误。这些错误通常发生在所有者删除终端节点（例如，订阅 Amazon SNS 主题的 Lambda 函数）或所有者更改附加到订阅终端节点的策略以阻止 Amazon SNS 向终端节点传送消息时。Amazon SNS 不会重试因客户端错误而失败的消息传递。
失败的 lambda（如上所述）是否被视为客户端错误？我可以强制执行服务器端错误吗？
我正在研究一个bash脚本，试图弄清楚它的工作方式并可能对其进行修补。有问题的脚本是这个 cryptroot从负责在开机解密块设备Debian的脚本。不能完全在家中进行bash肯定会带来挑战。
我找到了这段代码，但不确定它是做什么的。
if [ -r /conf/conf.d/cryptroot ]; then
while read mapping <&3; do
setup_mapping "$mapping" 3<&-
done 3< /conf/conf.d/cryptroot
fi
我的猜测是，它将读取每一行/conf/conf.d/cryptroot并将其传递给setup_mapping。但是我不太了解，以及的意义<&3，意义3&-以及作用3</conf/conf.d/cryptroot是什么？
当我从文件中读取行时，通常会执行以下操作：
while read LINE
do COMMAND
done < FILE
在while循环中将的输出FILE定向到的位置read，COMMAND直到最后一行为止。
我也对重定向有所了解，例如，有时我会用它来重定向STDOUT和STDERR诸如此类/dev/null的东西。但是我不确定重定向的3含义。
根据tldp.org的介绍，在阅读了有关I / O重定向的更多知识之后，我已经接近答案了。
stdin，stdout和stderr的文件描述符分别为0、1和2。要打开其他文件，请保留描述符3到9。
因此3是“仅”对打开文件的引用，或：
...只是操作系统分配给打开文件以跟踪它的数字。考虑它是文件指针的简化类型。
因此，据我了解：
3< /conf/conf.d/cryptroot打开/conf/conf.d/cryptroot读取并将其分配给文件描述符3。read mapping <&3似乎是从读文件描述符3，它指向打开文件的第一行/conf/conf.d/cryptroot …