问题列表 - 第5160页

我可以通过以下方式登录mysql -u myuser -p mydb -h localhost：

grant all privileges on mydb.* to myuser@'%' identified by
  '1234567890123456789012345678901234567890123456789012345678901234567890123456789';

但不是在我这样做之后：

grant all privileges on mydb.* to myuser@'%' identified by
  '12345678901234567890123456789012345678901234567890123456789012345678901234567890';

数据库密码的 79 个字符的硬限制来自哪里？

我有一个chain.pem包含两个 PEM 编码证书的文件，第一个是 TSA 证书，第二个是自签名 CA。

文件内容正是：

-----BEGIN CERTIFICATE-----
MIIIATCCBemgAwIBAgIJAMHphhYNqOmCMA0GCSqGSIb3DQEBDQUAMIGVMREwDwYD
VQQKEwhGcmVlIFRTQTEQMA4GA1UECxMHUm9vdCBDQTEYMBYGA1UEAxMPd3d3LmZy
ZWV0c2Eub3JnMSIwIAYJKoZIhvcNAQkBFhNidXNpbGV6YXNAZ21haWwuY29tMRIw
EAYDVQQHEwlXdWVyemJ1cmcxDzANBgNVBAgTBkJheWVybjELMAkGA1UEBhMCREUw
HhcNMTYwMzEzMDE1NzM5WhcNMjYwMzExMDE1NzM5WjCCAQkxETAPBgNVBAoTCEZy
ZWUgVFNBMQwwCgYDVQQLEwNUU0ExdjB0BgNVBA0TbVRoaXMgY2VydGlmaWNhdGUg
ZGlnaXRhbGx5IHNpZ25zIGRvY3VtZW50cyBhbmQgdGltZSBzdGFtcCByZXF1ZXN0
cyBtYWRlIHVzaW5nIHRoZSBmcmVldHNhLm9yZyBvbmxpbmUgc2VydmljZXMxGDAW
BgNVBAMTD3d3dy5mcmVldHNhLm9yZzEiMCAGCSqGSIb3DQEJARYTYnVzaWxlemFz
QGdtYWlsLmNvbTESMBAGA1UEBxMJV3VlcnpidXJnMQswCQYDVQQGEwJERTEPMA0G
A1UECBMGQmF5ZXJuMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAtZEE
jE5IbzTp3Ahif8I3UWIjaYS4LLEwvv9RfPw4+EvOXGWodNqyYhrgvOfjNWPg7ek0
/V+IIxWfB4SICCJ0YMHtiCYXBvQoEzQ1nfu4G9E1P8F5YQrxqMjIZdwA6iOzqJvm
vQO6hansgn1gVlkF4i1qWE7ROArhUCgM7jl+mKAS84BGQAeGJEO8B3y5X0Ia8xcS
2Wg8223/uvPIululZq5SPUWdYXc0bU2EDieIa3wBxbiQ14ouJ7uo3S+aKBLhV9Yv
khxlliVIBp3Nt9Bt4YHeDpVw1m+HIgzii2KKtVkG8+4MIQ9wUej0hYr4uaktCeRq
8tnLpb/PrRaM32BEkaSwZgOxFMr3Ax8GXn7u+lPFdfNJDAWdLjLdx2rE1MTHEGg7
l/0b5ZG8YQVRhtiPmgORswe2+R7ZVNqjb5rNah4Uqi5K3xdGS1TbGNu2/+MAgCRl
RzcENs5Od7rl3m/g8/nW5/++tGHnlOkvsJUfiq5hpBLM6bIQdGNci+MnrhoPa0pk
brD4RjvGO/hFUwQ10Z6AJRHsn2bDSWlS2L7LabCqTUxB9gUV/n3LuJMZzdpZumrq
S+POrnGOb8tszX25/FC7FbEvNmWwqjByicLm3UsRHOSLotnv21prmlBgaTNPs09v
x64zDws0IIqsgN8yZv3ZBGWHa6LLiY2VBTFbbnsCAwEAAaOCAdswggHXMAkGA1Ud
EwQCMAAwHQYDVR0OBBYEFG52C3tOT5zhYMptLOknoqKUs3c3MB8GA1UdIwQYMBaA
FPpVDYw0ZlFDTPfns6dsla965qSXMAsGA1UdDwQEAwIGwDAWBgNVHSUBAf8EDDAK
BggrBgEFBQcDCDBjBggrBgEFBQcBAQRXMFUwKgYIKwYBBQUHMAKGHmh0dHA6Ly93
d3cuZnJlZXRzYS5vcmcvdHNhLmNydDAnBggrBgEFBQcwAYYbaHR0cDovL3d3dy5m
cmVldHNhLm9yZzoyNTYwMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cuZnJl
ZXRzYS5vcmcvY3JsL3Jvb3RfY2EuY3JsMIHGBgNVHSAEgb4wgbswgbgGAQAwgbIw
MwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZnJlZXRzYS5vcmcvZnJlZXRzYV9jcHMu
aHRtbDAyBggrBgEFBQcCARYmaHR0cDovL3d3dy5mcmVldHNhLm9yZy9mcmVldHNh
X2Nwcy5wZGYwRwYIKwYBBQUHAgIwOxo5RnJlZVRTQSB0cnVzdGVkIHRpbWVzdGFt
cGluZyBTb2Z0d2FyZSBhcyBhIFNlcnZpY2UgKFNhYVMpMA0GCSqGSIb3DQEBDQUA
A4ICAQClyUTixvrAoU2TCn/QoLFytB/BSDw+lXxoorzZuXZPGpUBYf1yRy1Bpe7S
d3hiA7VCIkD7OibN4XYIe2+xAR30zBniVxqkoFEQlmXpTEb1C9Kt7mrEE34lGyWj
navaRRUV2P+eByCejsILeHT34aDt58AJN/6EozT4syZc7S2O2d9hOWWDZ3/rOCwe
47I+bqXwXfMN57n4kAXSUmb2EvOci09tq6bXv7rBljK5Bjcyn1Km8GahDkPqqB+E
mmxf4/6LXqIydfaH8gUuUC6mwwdipmjM4Hhx3Y6X4xW7qSniVYmXegoxLOlsUQax
Q3x3nys2GxgoiPPuiiNDdPoGPpVhkmJ/fEMQc5ZdEmCSjroAnoA0Ka4yTPlvBCNU
83vKWv3cefeTRqs4i/x58B3JhhJU6mzBKZQQdrg9IFVvO+UTJoN/KHb3gzs3Dnw9
QQUjgn1PU0AMciGNdSKf8QxviJOpo6HAxCu0yJjBPfQcf2VztPxWUVlxphCnsNKF
fIIlqfsgTqzsouiXGqGvh4hqKuPHL+CgquhCmAp3vvFrkhFUWAkNmCtZRmA3ZOda
CtPRFFS5mG9ni5q2r+hJcDOuOr/U60O3vJ3uaIFZSeZIFYKoLnhSd/IoIQfv45Ag
DgUIrLjqguolBSdvPJ2io9O0rTi7+IQr2jb8JEgpH1WNwC3R4A==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIH/zCCBeegAwIBAgIJAMHphhYNqOmAMA0GCSqGSIb3DQEBDQUAMIGVMREwDwYD
VQQKEwhGcmVlIFRTQTEQMA4GA1UECxMHUm9vdCBDQTEYMBYGA1UEAxMPd3d3LmZy
ZWV0c2Eub3JnMSIwIAYJKoZIhvcNAQkBFhNidXNpbGV6YXNAZ21haWwuY29tMRIw
EAYDVQQHEwlXdWVyemJ1cmcxDzANBgNVBAgTBkJheWVybjELMAkGA1UEBhMCREUw
HhcNMTYwMzEzMDE1MjEzWhcNNDEwMzA3MDE1MjEzWjCBlTERMA8GA1UEChMIRnJl
ZSBUU0ExEDAOBgNVBAsTB1Jvb3QgQ0ExGDAWBgNVBAMTD3d3dy5mcmVldHNhLm9y
ZzEiMCAGCSqGSIb3DQEJARYTYnVzaWxlemFzQGdtYWlsLmNvbTESMBAGA1UEBxMJ
V3VlcnpidXJnMQ8wDQYDVQQIEwZCYXllcm4xCzAJBgNVBAYTAkRFMIICIjANBgkq
hkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAtgKODjAy8REQ2WTNqUudAnjhlCrpE6ql
mQfNppeTmVvZrH4zutn+NwTaHAGpjSGv4/WRpZ1wZ3BRZ5mPUBZyLgq0YrIfQ5Fx
0s/MRZPzc1r3lKWrMR9sAQx4mN4z11xFEO529L0dFJjPF9MD8Gpd2feWzGyptlel
b+PqT+++fOa2oY0+NaMM7l/xcNHPOaMz0/2olk0i22hbKeVhvokPCqhFhzsuhKsm
q4Of/o+t6dI7sx5h0nPMm4gGSRhfq+z6BTRgCrqQG2FOLoVFgt6iIm/BnNffUr7V
DYd3zZmIwFOj/H3DKHoGik/xK3E82YA2ZulVOFRW/zj4ApjPa5OFbpIkd0pmzxzd
EcL479hSA9dFiyVmSxPtY5ze1P+BE9bMU1PScpRzw8MHFXxyKqW13Qv7LWw4sbk3
SciB7GACbQiVGzgkvXG6y85HOuvWNvC5GLSiyP9GlPB0V68tbxz4JVTRdw/Xn/XT
FNzRBM3cq8lBOAVt/PAX5+uFcv1S9wFE8YjaBfWCP1jdBil+c4e+0tdywT2oJmYB
BF/kEt1wmGwMmHunNEuQNzh1FtJY54hbUfiWi38mASE7xMtMhfj/C4SvapiDN837
gYaPfs8x3KZxbX7C3YAsFnJinlwAUss1fdKar8Q/YVs7H/nU4c4Ixxxz4f67fcVq
M2ITKentbCMCAwEAAaOCAk4wggJKMAwGA1UdEwQFMAMBAf8wDgYDVR0PAQH/BAQD
AgHGMB0GA1UdDgQWBBT6VQ2MNGZRQ0z357OnbJWveuaklzCBygYDVR0jBIHCMIG/
gBT6VQ2MNGZRQ0z357OnbJWveuakl6GBm6SBmDCBlTERMA8GA1UEChMIRnJlZSBU …

我有一个 OpenVPN 服务器和两个客户端，

我可以互相 ping 客户端，但是当我这样做时，我在服务器上看不到任何使用 tcpdump 的数据包

服务器

正在 192.168.0.1 上运行

我尝试使用捕获流量tcpdump -i tun0 icmp --immediate-mode -l -n

客户

正在 192.168.0.2 上运行

我可以 ping client2 ping 192.168.0.3，结果很好：

PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data.
64 bytes from 192.168.0.3: icmp_seq=1 ttl=128 time=32.4 ms

TCP 转储

但我从 tcpdump 中看不到任何内容：

0 packets captured
0 packets received by filter
0 packets dropped by kernel

虽然如果我直接 ping openvpn 服务器ping 192.168.0.1，我可以看到那里捕获的数据包：

18:05:04.022747 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 5, …

systemd 批准的用于从中删除例如 sidekiq.service 的方法是什么/etc/systemd/system/？

请注意，关于此主题有许多相关讨论，例如我已经阅读过的讨论： https ://superuser.com/questions/513159/how-to-remove-systemd-services

我的困惑之处在于，上述讨论中最常见的答案要求用户rm从多个位置手动文件，但后来的答案表明这systemctl disable <service>应该与手动删除文件具有相同的效果。

根据我自己的测试systemctl disable sidekiq，我发现单元文件之后sidekiq.service仍保留在/etc/systemd/system。

我知道，从理论上讲，rm在一堆位置上使用应该可以解决问题，但我想知道真正熟悉systemd或systemctl会这样做的人是如何做到这一点的。这种暴力真的有必要吗？或者是否有systemctl为此目的的实际命令？

您好，我是 github actions 的新手，我正在尝试使用 Github action 创建 CICD pipline。我正在使用数字海洋水滴 UBUNTU 20.04 作为我的服务器，我正在尝试创建一个跑步者，如 ->settings->actions 中所述

当我写下以下命令时 ./config.sh --url https://github.com/basobaasnepal/BasobaasWeb --token DFGFSDF234sf3fg45hd

我得到了这个： 不能使用 sudo 运行

我尝试将 root 用户更改为非 root 用户，但没有成功。我也尝试过export {AGENT_ALLOW_RUNASROOT="1"}，但也没有运气。

我有一个在 Ubuntu 18.04 上运行的 Rails 项目，我刚刚将系统升级到 Ubuntu 20.04。

cap production deploy在以下步骤中失败deploy:assets:precompile：

00:07 deploy:assets:precompile
      01 /home/deploy/.rbenv/bin/rbenv exec bundle exec rake assets:precompile
      01 bundler: failed to load command: rake (/var/www/framelinker/shared/bundle/ruby/2.6.0/bin/rake)
      01 Gem::Exception: can't find executable rake for gem rake. rake is not currently included in the bundle, perhaps you meant to add it to your Gemfile?

我尝试将 rake 添加到我的 gemfile 中，尽管我有一种感觉这不是答案，因为 a) 它没有任何区别，b) 当一切都在 Ubuntu 18.04 上运行时，rake 不在我的 gemfile 中。

谷歌搜索告诉我要运行gem update --system，但我不想手动弄乱服务器。

我在服务器上使用 rbenv。我的 gemfile 被锁定在 …

我找不到如何列出或“读取 Linux 上打开的端口列表”。我有一个基于 Debian 的服务器。我找到了一系列列出开放端口的命令，但我找不到任何仅列出可以从外部访问的开放端口的命令。我知道 3309 是开放的，但我已将 mySQL 配置为仅回复本地主机，但该端口仍列为开放。再说一遍，我只对对外开放的端口感兴趣。

如果没有这样的命令，也许有一个 grep 来过滤掉仅限内部的端口？

我需要运行 Arch Linux 容器，但我无法在其上安装任何东西：

当我尝试跑步时 pacman -Syyu --noconfirm

error: failed to initialize alpm library
(could not find or read directory: /var/lib/pacman/)

按照那个线程

我跑了

pacman-db-upgrade

但这也失败了：

==> ERROR: You must have correct permissions to upgrade the database.

这个容器是一个archlinux:latest基于vanilla的容器docker run -it archlinux

考虑 nginx 的参数proxy_ssl_verify，proxy_ssl_trusted_certificate这些参数用于保护与上游服务器的通信。

# downstream server: nginx.conf

stream {
  server {
    # ...

    proxy_ssl on;
    proxy_ssl_verify on;

    proxy_ssl_trusted_certificate /etc/nginx/ssl/upstream.example.com/chain.pem;
    proxy_ssl_verify_depth 2;

  }
}

我的印象是，对于，proxy_ssl onnginx 会根据upstream.example.com.proxy_ssl_trusted_certificate

但是，我遇到了一个问题，nginx 无法与上游服务器建立安全连接，并报告上游 SSL 证书验证错误： (2:unable to get Issuercertificate) while SSL 与上游握手，同时使用以下命令验证证书openssl确实有效。

# fullchain.pem: certificate sent by the upstream server
# chain.pem: CA certificate for `proxy_ssl_trusted_certificate`

# openssl verify -CAfile chain.pem fullchain.pem
fullchain.pem: OK

这让我想知道nginx实际上是如何进行验证的。有没有办法单独重现此问题，以便调试为什么会发生错误？

文档

https://nginx.org/en/docs/http/ngx_http_proxy_module.html

proxy_ssl_verify 上 | 离开;

启用或禁用代理 …

我有一个 OpenWRT 路由器设置，192.168.1.1带有搜索域local（而不是默认的lan）。

我有一个服务器设置，192.168.1.200，主机名，server.local。

我有一个工作站 ，192.168.1.10主机名workstation.local。

server.local还运行 NGINX 反向代理，以提供子域，例如sub.server.local.

如果我的工作站尝试访问 ，server.local则会正确解析为指向192.168.1.200。

但是，如果我的工作站尝试访问 ，sub.server.local它无法解析为192.168.1.200。

如果我的工作站已将192.168.1.200 sub.server.local, 添加到其主机文件中，则它可以正确解析，并且服务器反向代理会将传入连接路由到正确的端口。

我该如何解决这个问题，以便所有子域都server.local解析为192.168.1.200？不必为服务器上的每个子域添加主机记录到每个工作站，这显然是不可持续的。

我假设我需要更改 OpenWRT 路由器上的一些 DNS 记录，但是查看 Luci（Web 界面）中的设置，没有发现任何内容能够实现此目的。

有任何想法吗？