AskOverflow.Dev

AskOverflow.Dev Logo AskOverflow.Dev Logo

AskOverflow.Dev Navigation

  • 主页
  • 系统&网络
  • Ubuntu
  • Unix
  • DBA
  • Computer
  • Coding
  • LangChain

Mobile menu

Close
  • 主页
  • 系统&网络
    • 最新
    • 热门
    • 标签
  • Ubuntu
    • 最新
    • 热门
    • 标签
  • Unix
    • 最新
    • 标签
  • DBA
    • 最新
    • 标签
  • Computer
    • 最新
    • 标签
  • Coding
    • 最新
    • 标签
主页 / user-325891

chingis's questions

Martin Hope
chingis
Asked: 2023-06-02 00:00:14 +0800 CST

Kubernetes 网络策略阻止 NFS PVC 挂载

  • 6

根据文档,我在集群中安装了 Ganesha NFS 服务器配置程序作为STS。我只使用安装的块存储 PVC 来运行它。

我为每个命名空间部署一个单独的 NFS 服务器,并且希望限制命名空间中的哪些 pod 可以访问 NFS 服务器。name=nfs-server我为入口创建以下网络策略,允许从具有标签(所有端口)的同一命名空间中的 Pod访问 NFS 服务器(标记为app-name=my-app):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  labels:
    name: allow-ingress-nfs
  name: allow-ingress-nfs
  namespace: "my-namespace"
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app-name: my-app
  podSelector:
    matchLabels:
      name: nfs-server
  policyTypes:
  - Ingress

这是 NFS 服务器 Pod(来自 STS):

apiVersion: v1
kind: Pod
metadata:
  labels:
    name: nfs-server
  name: nfs-server-0
  namespace: "my-namespace"
spec:
  containers:
  - args:
    - -provisioner=my-namespace-nfs
    env:
    - name: POD_IP
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: status.podIP
    - name: SERVICE_NAME
      value: nfs-server
    - name: POD_NAMESPACE
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.namespace
    image: registry.k8s.io/sig-storage/nfs-provisioner:v4.0.8
    name: nfs-server
    volumeMounts:
    - mountPath: /export
      name: export
  volumes:
  - name: export
    persistentVolumeClaim:
      claimName: nfs-export

我尝试从以下 pod 挂载此 NFS 服务器的 PVC:

apiVersion: v1
kind: Pod
metadata:
  labels:
    app-name: my-app
    name: nginx
  name: nginx-74c5d976b7-g782p
  namespace: "my-namespace"
spec:
  containers:
    image: my/image
    imagePullPolicy: Always
    name: nginx
    volumeMounts:
    - mountPath: /mnt/files
      name: files
      readOnly: true
  volumes:
  - name: files
    persistentVolumeClaim:
      claimName: files

这是PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  finalizers:
  - kubernetes.io/pvc-protection
  name: files
  namespace: "my-namespace"
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 20Gi
  storageClassName: my-namespace-nfs
  volumeMode: Filesystem
  volumeName: pvc-uuid

这是 NFS 存储类别:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-namespace-nfs
mountOptions:
- vers=4.1
provisioner: my-namespace-nfs
reclaimPolicy: Delete
volumeBindingMode: Immediate

但是,pod 会陷入CreatingContainer以下错误:

Mounting command: mount
Mounting arguments: -t nfs -o vers=4.1 10.245.245.191:/export/pvc-name /var/lib/kubelet/pods/id/volumes/kubernetes.io~nfs/pvc-name
Output: mount.nfs: Connection timed out

我在具有非共享 CPU 节点和 GKE 1.26 的 DigitalOcean Kubernetes 1.27(他们使用 Cilium)中观察到相同的行为

如果我删除所有网络策略,问题就会完全消失。

不确定这是否会影响任何东西,但我不在特权模式下运行 Ganesha,并且我通过内存/CPU 限制它。

kubernetes
  • 2 个回答
  • 91 Views
Martin Hope
chingis
Asked: 2022-11-24 05:33:11 +0800 CST

docker 中的鱿鱼返回 502 但在主机上运行时有效

  • 5

我对在主机和 docker 中运行的 squid 5.6 使用相同的配置。当我在主机(Ubuntu 22.10)上运行它时它工作得很好但是当我从ubuntu/squid图像运行它时我得到 502 bad gateway 错误。

鱿鱼配置:

acl localnet src 0.0.0.1-0.255.255.255  # RFC 1122 "this" network (LAN)
acl localnet src 10.0.0.0/8             # RFC 1918 local private network (LAN)
acl localnet src 100.64.0.0/10          # RFC 6598 shared address space (CGN)
acl localnet src 169.254.0.0/16         # RFC 3927 link-local (directly plugged) machines
acl localnet src 172.16.0.0/12          # RFC 1918 local private network (LAN)
acl localnet src 192.168.0.0/16         # RFC 1918 local private network (LAN)
acl localnet src fc00::/7               # RFC 4193 local private network range
acl localnet src fe80::/10              # RFC 4291 link-local (directly plugged) machines
acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
#http_access deny !Safe_ports
#http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
include /etc/squid/conf.d/*.conf
http_access allow localhost
#http_access deny all
http_access allow all
http_port 3128
coredump_dir /var/spool/squid
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
refresh_pattern \/Release(|\.gpg)$ 0 0% 0 refresh-ims
refresh_pattern \/InRelease$ 0 0% 0 refresh-ims
refresh_pattern \/(Translation-.*)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
refresh_pattern .               0       20%     4320
http_upgrade_request_protocols OTHER allow all

debug_options ALL,1 11,3 31,3 65,3

这就是我通过 docker 运行它的方式:

docker run -v /etc/squid/squid.conf:/etc/squid/squid.conf -p 3128:3128 ubuntu/squid

在主机上运行 squid 时的日志(工作正常):

2022/11/23 13:13:56.878 kid1| 11,2| client_side.cc(1357) parseHttpRequest: HTTP Client conn7 local=x.x.x.x:3128 remote=y.y.y.y:56636 FD 11 flags=1
2022/11/23 13:13:56.891 kid1| 11,2| client_side.cc(1358) parseHttpRequest: HTTP Client REQUEST:
---------
GET https://example.com/socket.io/?EIO=3&transport=polling&t=OIadwKA&b64=1 HTTP/1.1
user-agent: node-XMLHttpRequest
accept: */*
Host: example.com:443
connection: close


----------
2022/11/23 13:13:57.233 kid1| 11,3| http.cc(2498) httpStart: GET https://example.com/socket.io/?EIO=3&transport=polling&t=OIadwKA&b64=1
2022/11/23 13:13:57.234 kid1| 11,2| http.cc(2454) sendRequest: HTTP Server conn10 local=x.x.x.x:47078 remote=z.z.z.z:443 HIER_DIRECT FD 13 flags=1
2022/11/23 13:13:57.234 kid1| 11,2| http.cc(2455) sendRequest: HTTP Server REQUEST:
---------
GET /socket.io/?EIO=3&transport=polling&t=OIadwKA&b64=1 HTTP/1.1
User-Agent: node-XMLHttpRequest
Accept: */*
Host: example.com
Via: 1.1 squid-new (squid/5.6)
X-Forwarded-For: y.y.y.y
Cache-Control: max-age=0
Connection: keep-alive


----------
2022/11/23 13:13:57.390 kid1| ctx: enter level  0: 'https://example.com/socket.io/?EIO=3&transport=polling&t=OIadwKA&b64=1'
2022/11/23 13:13:57.390 kid1| 11,3| http.cc(666) processReplyHeader: processReplyHeader: key '0100000000000000FFB9000001000000'
2022/11/23 13:13:57.390 kid1| 11,2| http.cc(720) processReplyHeader: HTTP Server conn10 local=x.x.x.x:47078 remote=z.z.z.z:443 HIER_DIRECT FD 13 flags=1
2022/11/23 13:13:57.391 kid1| 11,2| http.cc(721) processReplyHeader: HTTP Server RESPONSE:
---------
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 23 Nov 2022 13:13:57 GMT
Content-Type: text/plain; charset=UTF-8
Content-Length: 100
Connection: keep-alive
Access-Control-Allow-Origin: *
Set-Cookie: io=TXpnzoBUkck9fUgiAAGO; Path=/; HttpOnly
X-Robots-Tag: noindex, nofollow, nosnippet, noarchive
Strict-Transport-Security: max-age=63072000

当我在 docker(502 网关)中运行它时记录:

1669209346.964    475 y.y.y.y TCP_MISS/502 4012 GET https://example.com/socket.io/? - HIER_DIRECT/z.z.z.z text/html
2022/11/23 13:15:46.488| 11,2| client_side.cc(1357) parseHttpRequest: HTTP Client conn6 local=172.17.0.2:31288 remote=y.y.y.y:56834 FD 10 flags=1
2022/11/23 13:15:46.488| 11,2| client_side.cc(1358) parseHttpRequest: HTTP Client REQUEST:
---------
GET https://example.com/socket.io/?EIO=3&transport=polling&t=OIaeL57&b64=1 HTTP/1.1
user-agent: node-XMLHttpRequest
accept: */*
Host: example.com:443
connection: close


----------
2022/11/23 13:15:46.809| 11,3| http.cc(2498) httpStart: GET https://example.com/socket.io/?EIO=3&transport=polling&t=OIaeL57&b64=1
2022/11/23 13:15:46.810| 11,2| http.cc(2454) sendRequest: HTTP Server conn9 local=172.17.0.2:45890 remote=z.z.z.z:443 HIER_DIRECT FD 12 flags=1
2022/11/23 13:15:46.810| 11,2| http.cc(2455) sendRequest: HTTP Server REQUEST:
---------
GET /socket.io/?EIO=3&transport=polling&t=OIaeL57&b64=1 HTTP/1.1
User-Agent: node-XMLHttpRequest
Accept: */*
Host: example.com
Via: 1.1 d6850669e571 (squid/5.6)
X-Forwarded-For: y.y.y.y
Cache-Control: max-age=0
Connection: keep-alive


----------
2022/11/23 13:15:46.963| 11,2| http.cc(1291) readReply: conn9 local=172.17.0.2:45890 remote=z.z.z.z:443 HIER_DIRECT FD 12 flags=1: read failure: (0) No error.
2022/11/23 13:15:46.963| 11,2| Stream.cc(279) sendStartOfMessage: HTTP Client conn6 local=172.17.0.2:31288 remote=y.y.y.y:56834 FD 10 flags=1
2022/11/23 13:15:46.963| 11,2| Stream.cc(280) sendStartOfMessage: HTTP Client REPLY:
---------
HTTP/1.1 502 Bad Gateway
Server: squid/5.6
Mime-Version: 1.0
Date: Wed, 23 Nov 2022 13:15:46 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 3637
X-Squid-Error: ERR_READ_ERROR 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from d6850669e571
X-Cache-Lookup: MISS from d6850669e571:31288
Via: 1.1 d6850669e571 (squid/5.6)
Connection: close
docker
  • 1 个回答
  • 28 Views
Martin Hope
chingis
Asked: 2019-11-21 21:47:44 +0800 CST

为什么有时忽略 tar 标志 --strip-components ?

  • 1

我有一个自动化的 docker 图像构建,我在其中下载 elasticsearch 存档并通过以下方式提取它:

tar zxf archive.tar.gz --strip-components=1 -C /path/to/dir

它一直有效,直到最新版本(6.8.5 和 7.4.2)。它不再适用于 6.8.5,这意味着该标志--strip-components不再有任何效果。但是,它适用于 7.4.2。在比较这两个档案之后,我发现唯一的区别是 6.8.5 对档案中的文件拥有不同的所有权——631:503与root:root7.4.2 相比。但是,如果这是问题标志--no-same-owner,或者--user应该通过他们没有解决问题。我什至使用这些 ID 创建了一个用户/组,并在该用户下提取了存档,但它也没有任何效果。

这是您可以重现的方式(将 6.8.5 替换为 7.4.2 以尝试两者):

$ docker run --rm -ti alpine:3.10.3 sh

### from the container

$ wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.8.5.tar.gz
$ apk add --update tar
$ mkdir elastic
$ tar zxvf elasticsearch-6.8.5.tar.gz --strip-components=1 -C elastic
$ ls -la elastic

使用 6.8.5,您将看到没有被剥离的中间目录,使用 7.4.2,您将看不到它,尽管它存在于两个档案中。

您可能会注意到我没有使用tarmusl,我使用了 alpine 包中的 GNU 版本(版本 1.32),这些包已经存在了几个月。我在许多其他版本中使用具有相同标志的这个包,它对我来说很好用。

tar
  • 1 个回答
  • 1428 Views
Martin Hope
chingis
Asked: 2018-10-30 02:35:22 +0800 CST

Nginx 是否显示 X-Accel 标头作为响应?

  • 2

我尝试通过设置标头来禁用快速 CGI 缓冲,X-Accel-Buffering: no但在 Nginx 响应中看不到此标头。是设计使然还是我的 Nginx 配置有问题?我没有fastcgi_ignore_headers指令。

nginx
  • 1 个回答
  • 2355 Views
Martin Hope
chingis
Asked: 2017-05-30 06:58:33 +0800 CST

神秘的 Debian 8 随机重启

  • 1

我有一个随机重启的 Debian 8 服务器。我试图从以前的引导中查找 journalctl 日志(日志是持久的),但什么也没找到:

$ journalctl -b -1 -e

尝试 grep 遍历所有日志(重新启动、关闭、关闭、关闭、重新启动、恐慌) - 没有任何帮助:

$ grep -rn "reboot" /var/log

我能够在几个 GCP 和 OVH(VPS,专用)节点上重现它。尽管一些具有类似设置的节点工作得很好。

$ last reboot
reboot   system boot  3.16.0-4-amd64   Mon May 29 13:20 - 14:21  (01:00)
reboot   system boot  3.16.0-4-amd64   Mon May 29 13:11 - 14:21  (01:10)
reboot   system boot  3.16.0-4-amd64   Mon May 29 13:06 - 14:21  (01:15)
reboot   system boot  3.16.0-4-amd64   Mon May 29 12:58 - 14:21  (01:23)
reboot   system boot  3.16.0-4-amd64   Mon May 29 10:53 - 14:21  (03:28)
reboot   system boot  3.16.0-4-amd64   Mon May 29 09:51 - 10:52  (01:01)
reboot   system boot  3.16.0-4-amd64   Sun May 28 20:29 - 10:52  (14:23)
reboot   system boot  3.16.0-4-amd64   Sun May 28 20:01 - 10:52  (14:51)
reboot   system boot  3.16.0-4-amd64   Sun May 28 18:45 - 10:52  (16:07)
reboot   system boot  3.16.0-4-amd64   Sun May 28 18:36 - 10:52  (16:16)
reboot   system boot  3.16.0-4-amd64   Sun May 28 18:19 - 10:52  (16:33)
reboot   system boot  3.16.0-4-amd64   Sun May 28 17:51 - 10:52  (17:01)
reboot   system boot  3.16.0-4-amd64   Sun May 28 10:20 - 10:52 (1+00:31)
reboot   system boot  3.16.0-4-amd64   Sun May 28 09:04 - 10:52 (1+01:48)
reboot   system boot  3.16.0-4-amd64   Sun May 28 08:54 - 10:52 (1+01:58)
reboot   system boot  3.16.0-4-amd64   Sun May 28 08:48 - 10:52 (1+02:03)
reboot   system boot  3.16.0-4-amd64   Sun May 28 08:42 - 10:52 (1+02:10)
reboot   system boot  3.16.0-4-amd64   Sun May 28 08:35 - 10:52 (1+02:17)
reboot   system boot  3.16.0-4-amd64   Sun May 28 08:18 - 10:52 (1+02:34)
reboot   system boot  3.16.0-4-amd64   Sun May 28 08:12 - 10:52 (1+02:40)
reboot   system boot  3.16.0-4-amd64   Sun May 28 05:34 - 10:52 (1+05:18)
reboot   system boot  3.16.0-4-amd64   Sun May 28 01:03 - 10:52 (1+09:49)
reboot   system boot  3.16.0-4-amd64   Sun May 28 01:00 - 10:52 (1+09:52)
reboot   system boot  3.16.0-4-amd64   Sat May 27 23:20 - 10:52 (1+11:32)
reboot   system boot  3.16.0-4-amd64   Sat May 27 21:22 - 10:52 (1+13:30)
reboot   system boot  3.16.0-4-amd64   Sat May 27 21:17 - 10:52 (1+13:35)
reboot   system boot  3.16.0-4-amd64   Sat May 27 20:52 - 10:52 (1+14:00)
reboot   system boot  3.16.0-4-amd64   Sat May 27 19:32 - 10:52 (1+15:20)
reboot   system boot  3.16.0-4-amd64   Sat May 27 18:07 - 10:52 (1+16:45)
reboot   system boot  3.16.0-4-amd64   Sat May 27 17:52 - 10:52 (1+17:00)
reboot   system boot  3.16.0-4-amd64   Sat May 27 16:32 - 10:52 (1+18:20)
reboot   system boot  3.16.0-4-amd64   Sat May 27 12:25 - 10:52 (1+22:27)
reboot   system boot  3.16.0-4-amd64   Sat May 27 12:16 - 10:52 (1+22:36)
reboot   system boot  3.16.0-4-amd64   Sat May 27 11:07 - 10:52 (1+23:45)
reboot   system boot  3.16.0-4-amd64   Sat May 27 09:53 - 10:52 (2+00:59)
reboot   system boot  3.16.0-4-amd64   Sat May 27 09:09 - 10:52 (2+01:43)
reboot   system boot  3.16.0-4-amd64   Sat May 27 06:39 - 10:52 (2+04:13)
reboot   system boot  3.16.0-4-amd64   Sat May 27 06:06 - 10:52 (2+04:46)
reboot   system boot  3.16.0-4-amd64   Sat May 27 05:00 - 10:52 (2+05:52)
reboot   system boot  3.16.0-4-amd64   Sat May 27 04:53 - 10:52 (2+05:58)
reboot   system boot  3.16.0-4-amd64   Sat May 27 03:40 - 10:52 (2+07:12)
reboot   system boot  3.16.0-4-amd64   Sat May 27 01:57 - 10:52 (2+08:55)
reboot   system boot  3.16.0-4-amd64   Sat May 27 01:13 - 10:52 (2+09:39)
reboot   system boot  3.16.0-4-amd64   Fri May 26 22:51 - 10:52 (2+12:01)
reboot   system boot  3.16.0-4-amd64   Fri May 26 20:54 - 10:52 (2+13:58)
reboot   system boot  3.16.0-4-amd64   Fri May 26 16:50 - 10:52 (2+18:02)
reboot   system boot  3.16.0-4-amd64   Fri May 26 15:58 - 10:52 (2+18:54)
reboot   system boot  3.16.0-4-amd64   Fri May 26 15:21 - 10:52 (2+19:31)
reboot   system boot  3.16.0-4-amd64   Fri May 26 14:41 - 10:52 (2+20:11)
reboot   system boot  3.16.0-4-amd64   Fri May 26 13:23 - 10:52 (2+21:29)
reboot   system boot  3.16.0-4-amd64   Fri May 26 11:44 - 10:52 (2+23:08)
reboot   system boot  3.16.0-4-amd64   Fri May 26 10:55 - 10:52 (2+23:57)
reboot   system boot  3.16.0-4-amd64   Fri May 26 10:36 - 10:52 (3+00:16)
reboot   system boot  3.16.0-4-amd64   Fri May 26 10:12 - 10:52 (3+00:40)
reboot   system boot  3.16.0-4-amd64   Fri May 26 08:27 - 10:52 (3+02:25)
reboot   system boot  3.16.0-4-amd64   Fri May 26 08:25 - 10:52 (3+02:27)
reboot   system boot  3.16.0-4-amd64   Fri May 26 08:17 - 10:52 (3+02:35)
reboot   system boot  3.16.0-4-amd64   Fri May 26 06:45 - 10:52 (3+04:07)
reboot   system boot  3.16.0-4-amd64   Fri May 26 04:53 - 10:52 (3+05:59)
reboot   system boot  3.16.0-4-amd64   Fri May 26 04:23 - 10:52 (3+06:29)
reboot   system boot  3.16.0-4-amd64   Thu May 25 16:25 - 10:52 (3+18:27)
reboot   system boot  3.16.0-4-amd64   Thu May 25 16:01 - 10:52 (3+18:51)
reboot   system boot  3.16.0-4-amd64   Thu May 25 15:41 - 10:52 (3+19:11)
reboot   system boot  3.16.0-4-amd64   Thu May 25 15:24 - 10:52 (3+19:28)
reboot   system boot  3.16.0-4-amd64   Thu May 25 15:10 - 10:52 (3+19:42)
reboot   system boot  3.16.0-4-amd64   Thu May 25 14:10 - 10:52 (3+20:42)
reboot   system boot  3.16.0-4-amd64   Thu May 25 13:54 - 10:52 (3+20:58)
reboot   system boot  3.16.0-4-amd64   Thu May 25 13:31 - 10:52 (3+21:21)
reboot   system boot  3.16.0-4-amd64   Thu May 25 13:20 - 10:52 (3+21:32)
reboot   system boot  3.16.0-4-amd64   Thu May 25 13:03 - 10:52 (3+21:49)
reboot   system boot  3.16.0-4-amd64   Thu May 25 12:42 - 10:52 (3+22:10)
reboot   system boot  3.16.0-4-amd64   Thu May 25 11:52 - 10:52 (3+23:00)
reboot   system boot  3.16.0-4-amd64   Thu May 25 11:44 - 10:52 (3+23:08)
reboot   system boot  3.16.0-4-amd64   Thu May 25 11:24 - 10:52 (3+23:28)
reboot   system boot  3.16.0-4-amd64   Thu May 25 07:17 - 10:52 (4+03:35)
reboot   system boot  3.16.0-4-amd64   Wed May 24 04:42 - 10:52 (5+06:10)
reboot   system boot  3.16.0-4-amd64   Wed May 24 04:37 - 04:42  (00:05)

日志中没有任何内容表明谁触发了重新启动,没有内核恐慌,这非常奇怪。

我尝试按照服务器神秘重启/sbin/shutdown中的建议进行替换,但似乎没有人运行它。

重启后的 Journalctl 日志:https ://pastebin.com/raw/AmkNVs66

请建议我如何进一步调试它。

linux
  • 1 个回答
  • 992 Views

Sidebar

Stats

  • 问题 205573
  • 回答 270741
  • 最佳答案 135370
  • 用户 68524
  • 热门
  • 回答
  • Marko Smith

    新安装后 postgres 的默认超级用户用户名/密码是什么?

    • 5 个回答
  • Marko Smith

    SFTP 使用什么端口?

    • 6 个回答
  • Marko Smith

    命令行列出 Windows Active Directory 组中的用户?

    • 9 个回答
  • Marko Smith

    什么是 Pem 文件,它与其他 OpenSSL 生成的密钥文件格式有何不同?

    • 3 个回答
  • Marko Smith

    如何确定bash变量是否为空?

    • 15 个回答
  • Martin Hope
    Tom Feiner 如何按大小对 du -h 输出进行排序 2009-02-26 05:42:42 +0800 CST
  • Martin Hope
    Noah Goodrich 什么是 Pem 文件,它与其他 OpenSSL 生成的密钥文件格式有何不同? 2009-05-19 18:24:42 +0800 CST
  • Martin Hope
    Brent 如何确定bash变量是否为空? 2009-05-13 09:54:48 +0800 CST
  • Martin Hope
    cletus 您如何找到在 Windows 中打开文件的进程? 2009-05-01 16:47:16 +0800 CST

热门标签

linux nginx windows networking ubuntu domain-name-system amazon-web-services active-directory apache-2.4 ssh

Explore

  • 主页
  • 问题
    • 最新
    • 热门
  • 标签
  • 帮助

Footer

AskOverflow.Dev

关于我们

  • 关于我们
  • 联系我们

Legal Stuff

  • Privacy Policy

Language

  • Pt
  • Server
  • Unix

© 2023 AskOverflow.DEV All Rights Reserve