主页 / user-96893

mesr's questions

Martin Hope
mesr
Asked: 2025-04-27 02:34:42 +0800 CST
  • 5

我正在将老旧的 Debian 11 (bullseye) 服务器上的 NodeJS 和 NPM 升级到最新的 LTS 版本。我清除了发行版中原有的nodejs和npm软件包及依赖项，并使用nodesource成功安装了 NodeJS v22.15.0 和 NPM v10.9.2 。

我现在正试图删除nodejs-legacy包 — — 我假设 — — 可能不再需要了，但是apt和apt-get（它们在这方面的行为完全相同）都抱怨：

$ sudo apt remove nodejs-legacy
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Virtual packages like 'nodejs-legacy' can't be removed
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

据我所知，虚拟软件包仅定义依赖项和/或安装配置文件。为什么一个软件包，即使是“虚拟”的（或者随便怎么叫）也无法卸载？apt（或apt-get）不能直接更新软件包数据库和/或删除上述文件吗？

这个特定的包甚至不属于任何依赖项：

$ sudo apt depends nodejs-legacy
<nodejs-legacy>
$ sudo apt rdepends nodejs-legacy
<nodejs-legacy>

我想我可以把它留在那里，因为它似乎与其他任何东西都不冲突（至少目前是这样）。但我宁愿让我的服务器远离那些垃圾。

删除 Debian 系统中不再需要的旧虚拟包的推荐方法是什么？

debian
Martin Hope
mesr
Asked: 2024-02-26 11:50:07 +0800 CST
  • 8

我知道这不是一个描述性很强的标题（欢迎提出建议），但事实是我已经为此烦恼了好几个小时，而且我不知道问题的根源可能在哪里。

我为本地网络上的对等点之间的 CLI 聊天编写了一个简单的 Bash 脚本：

#!/usr/bin/env bash

# Usage: ./lanchat <local_ip>:<local_port> <remote_ip>:<remote_port>

# set -x
set -o errexit -o nounset -o pipefail

IFS=':' read -a socket <<< "$1"
LOCAL_IP=${socket[0]}
LOCAL_PORT=${socket[1]}

IFS=':' read -a socket <<< "$2"
REMOTE_IP=${socket[0]}
REMOTE_PORT=${socket[1]}

RECV_FIFO=".tmp.lanchat"

trap "rm '$RECV_FIFO'; kill 0" EXIT

mkfifo "$RECV_FIFO"

while true; do nc -n -l -q 0 -s "$LOCAL_IP" -p "$LOCAL_PORT" > "$RECV_FIFO"; done &

TMUX_TOP="while true; do cat '$RECV_FIFO'; done"
TMUX_BOTTOM="while IFS= read -r line; do nc -n -q 0 '$REMOTE_IP' '$REMOTE_PORT' <<< \$line; done"

tmux new "$TMUX_TOP" \; split -v "$TMUX_BOTTOM"

IP 172.16.0.2 上的机器是运行 Debian 11 的 VPS，172.16.0.100 上是我运行 Arch 的本地计算机。

当我在两侧的提示符下手动运行命令时，我得到了想要的结果，这证实了网络通信没有问题，并且脚本的逻辑是正确的。

## VPS (Debian) side as follows; exchange IPs for local (Arch) side.
$ mkfifo .tmp.lanchat
$ while true; do nc -n -l -q 0 -s 172.16.0.2 -p 1234 > .tmp.lanchat; done &
$ tmux new "while true; do cat .tmp.lanchat; done" \; split -v "while IFS= read -r line; do nc -n -q 0 172.16.0.100 1234 <<< \$line; done"
## Test communication in both directions: all right; then CTRL-C twice to exit both tmux panels
$ kill %1; rm .tmp.lanchat

然而，当我将双方作为脚本运行时，只有本地端（Arch）打印来自服务器（Debian）的消息。服务器没有从我的本地计算机打印任何内容。当我使用 跟踪执行时set -x，两侧的所有内容看起来都与我手动输入的命令完全相同，用正确的值代替变量。

现在奇怪的是，如果我在 Arch 端运行脚本并在 Debian 端按照提示符（如上所示）运行命令，那么一切都会再次正常工作。此外，如果我在 Arch 端执行脚本但在 Debian 端获取它，那也可以正常工作。

向 Arch 端的两个nc调用添加详细输出，甚至打印Connection to 172.16.0.2 1234 port [tcp/*] succeeded!。但是，在 Debian 端以监听模式添加 atee log.txt到nc调用中不会捕获任何内容：

#...
while true; do
    nc -n -l -q 0 -s "$LOCAL_IP" -p "$LOCAL_PORT" | tee log.txt > "$RECV_FIFO";
done &
#...

我尝试在两个对等点之间以所有可能的顺序建立连接。我什至重新启动了服务器和本地计算机，以确保不存在以某种方式逃避检测的nc拥抱套接字的孤立或僵尸实例。

现在，Debian 和 Arch 运行不同版本的nc。所以，从表面上看，这听起来可能是一个可能的解释。但是，在 Debian 端获取脚本运行良好的事实是否排除了这种可能性？

这里到底发生了什么事？

bash
Martin Hope
mesr
Asked: 2022-11-18 07:41:03 +0800 CST
  • 5

我看到在 SE 上有很多关于使用exec在 Bash 中重定向的问题，但似乎没有一个能回答我的问题。

我想要完成的是将脚本中所有输出重定向到stderr到临时 fd，并仅在脚本未成功终止的情况下将其恢复到stderr 。在非成功终止的情况下，需要恢复stderr内容的能力，以便向调用者返回有关错误的信息。将stderr重定向到/dev/nul将丢弃不相关的噪音和有用的信息。应尽可能避免显式临时文件，因为它们会增加许多其他问题（请参阅https://dev.to/philgibbs/avoiding-temporary-files-in-shell-scripts）。标准输出的内容应该透明地返回给调用者。如果脚本未成功终止，它将被忽略，但脚本不需要关心这一点。

这样做的原因是脚本是从另一个程序调用的，该程序认为任何输出到stderr都是错误，而不是测试非零退出代码。在下面的示例中，openssl向stderr回显了一个进度指示器，成功完成后应该忽略它。

下面是我的脚本的简化版本（请注意，这里的openssl只是任意且可能更复杂的指令的占位符）：

#!/bin/bash
set -euo pipefail

# Redirect stderr to temp fd 3
exec 3>&2

# In case of error, copy contents of fd 3 to stderr
trap 'cat <&3 >&2' ERR

# Upon exit, restore original stderr and close fd 3
trap 'exec 2>&3 3>&-' EXIT

# This nonetheless outputs the progress indicator to stderr
openssl genpkey -algorithm RSA

但是我显然遗漏了一些东西，因为脚本在成功终止时不断打印出stderr的内容，但现在在失败时会阻塞。我想我对exec的重定向如何工作感到困惑。我错了什么？

bash
Martin Hope
mesr
Asked: 2022-07-11 05:27:27 +0800 CST
  • 7

我试图理解为什么某些 shell 在使用sudo调用时似乎得到了特殊处理。例如，似乎有两种可能的行为：

“隐式”组（pstree是sudo的直接子代，中间没有外壳）：

$ sudo pstree -s $$
systemd───login───bash───sudo───pstree
$ sudo bash -c 'pstree -s $$'
systemd───login───bash───sudo───pstree
$ sudo zsh -c 'pstree -s $$'
systemd───login───bash───sudo───pstree
$ sudo dash -c 'pstree -s $$'
systemd───login───bash───sudo───pstree

“显式”组（shell 是sudo的直接子代）：

$ sudo ksh -c 'pstree -s $$'
systemd───login───bash───sudo───ksh───pstree
$ sudo tcsh -c 'pstree -s $$'
systemd───login───bash───sudo───tcsh───pstree
$ sudo fish -c 'pstree -s $fish_pid'
systemd───login───bash───sudo───fish───pstree

显然sudo和一些 shell之间似乎发生了某种集成，但我找不到关于它的文档。我还 grepped 了sudo和bash的源代码，但也找不到任何线索。

另一个问题似乎是相关的：为什么 (...) 在后台运行时不会产生新的子进程？

我的sudo和bash版本是：

$ sudo --version
Sudo version 1.8.29
...
$ bash --version
GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)
...
bash zsh
Martin Hope
mesr
Asked: 2022-06-21 06:59:47 +0800 CST
  • 3

这个问题是关于理解通过sudo调用可执行文件时记录的行为与实际行为之间感知到的不一致背后的原因。启用secure_path选项（我的系统上的默认设置）时，搜索路径的行为与预期相同。但是当该选项被禁用时，会发生一些奇怪的事情：/usr/local/bin尽管它的位置不在搜索路径中，但可以在没有完全限定路径名的情况下访问可执行文件。

系统信息

我的系统上当前安装了以下软件：

## Yeah... still haven't migrated to Alma
[me@localhost ~]$ cat /etc/centos-release
CentOS Linux release 8.5.2111

[me@localhost ~]$ bash --version | head -1
GNU bash, version 4.4.20(1)-release (x86_64-redhat-linux-gnu)

[me@localhost ~]$ sudo --version
Sudo version 1.8.29
Sudoers policy plugin version 1.8.29
Sudoers file grammar version 46
Sudoers I/O plugin version 1.8.29

[me@localhost ~]$ ssh -V
OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021

PAM 不会在我的系统上设置或更新 PATH 变量的值：

[me@localhost ~]$ grep --recursive 'pam_env\.so' /etc/pam.d
/etc/pam.d/fingerprint-auth:auth        required      pam_env.so
/etc/pam.d/smartcard-auth:auth        required      pam_env.so
/etc/pam.d/su:auth        required    pam_env.so
/etc/pam.d/password-auth:auth        required      pam_env.so
/etc/pam.d/system-auth:auth        required      pam_env.so

[me@localhost ~]$ sudo cat /etc/security/pam_env.conf /etc/environment | grep PATH
# be useful to be set: NNTPSERVER, LESS, PATH, PAGER, MANPAGER .....
#PATH       DEFAULT=${HOME}/bin:/usr/local/bin:/bin\

我的/etc/sudoers文件为所有 sudoers 设置了一个secure_path值：

[me@localhost ~]$ sudo grep --recursive secure_path /etc/sudoers /etc/sudoers.d
/etc/sudoers:Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

Bash 默认为以下 PATH 值：

[me@localhost ~]$ env --ignore-environment bash -c 'echo $PATH'
/usr/local/bin:/usr/bin

最后，我通过 SSH 连接到系统，其/etc/ssh/sshd_config文件包含以下行：

[me@localhost ~]$ sudo grep PATH /etc/sshd_config
# This sshd was compiled with PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

复制过程

为了复制，我首先创建一个虚拟脚本并将其安装在/usr/local/bin：

[me@localhost ~]$ cat > dummy <<EOF
#!/usr/bin/bash
echo 'Found!'
EOF

[me@localhost ~]$ sudo install --owner=root --group=root --mode=755 dummy /usr/local/bin

我验证不使用sudo时搜索路径是否按预期工作：

## The /usr/local/bin location is part of my search path
[me@localhost ~]$ echo $PATH
/home/me/.local/bin:/home/me/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

## This is expected
[me@localhost ~]$ dummy
Found!

并且使用sudo，这里也不足为奇：

## Sudo's secure_path value
[me@localhost ~]$ sudo --user=other env | grep PATH
PATH=/usr/bin:/bin:/usr/sbin:/sbin

## This is expected
[me@localhost ~]$ sudo --user=other which dummy
which: no dummy in (/sbin:/bin:/usr/sbin:/usr/bin)

## This too, of course
[me@localhost ~]$ sudo --user=other dummy
sudo: dummy: command not found

## Indeed, a fully qualified path name is required
[me@localhost ~]$ sudo --user=other /usr/local/bin/dummy
Found!

然后，我禁用secure_path（这里要小心！建议使用visudo），方法是注释掉该行/etc/sudoers或创建一个/etc/sudoers.d/local包含以下行的文件：

# Disable secure_path if set
Defaults !secure_path

这应该可以防止sudo在使用开关调用时用--preserve-env值secure_path覆盖 PATH 环境变量。它按预期工作。

但是，当不使用该--preserve-env开关，并且不使用该开关提示一个完整的登录序列--login（因此不获取任何 Bash 的启动文件），并且在任何 PAM 环境文件中没有分配给 PATH 时，会发生一些奇怪的事情：

## Not sure where this PATH value is from, neither from sudo's secure_path option
## (not set), PAM environment files (contain no assignment to PATH), Bash startup
## scripts (not sourced), nor Bash or sshd default PATH values (no match).
[me@localhost ~]$ sudo --user=other env | grep PATH
PATH=/usr/bin:/bin:/usr/sbin:/sbin

## Regardless, this is expected
[me@localhost ~]$ sudo --user=other which dummy
which: no dummy in (/usr/bin:/bin:/usr/sbin:/sbin)

## But wait! What?!?
[me@localhost ~]$ sudo --user=other dummy
Found!

那么，如何在直接调用没有路径前缀的情况下which dummy抱怨dummy不在搜索路径中呢？dummy

相关文件

以下是对我在研究此问题时发现相关的各种信息的引用。

Sudo 文档说明了有关secure_path选项的内容：

用于从 sudo 运行的每个命令的路径。如果你不相信运行 sudo 的人有一个健全的 PATH 环境变量，你可能想要使用它。另一个用途是，如果您想让“根路径”与“用户路径”分开。exclude_group 选项指定的组中的用户不受secure_path 的影响。默认情况下未设置此选项。

根据手册页中的pam_env文档，默认情况下pam_env模块仅应处理 、/etc/environment和/etc/security/pam_env.conf，除非指定了非默认文件名。在我的系统上不是这种情况，这些文件都没有设置或更新 PATH 的值。~/.pam_environment

Bash 的手册页说：

PATH 命令的搜索路径。它是一个以冒号分隔的目录列表，shell 在其中查找命令（请参阅下面的命令执行）。PATH 值中的零长度（空）目录名称表示当前目录。空目录名称可能显示为两个相邻的冒号，或者显示为初始冒号或尾随冒号。默认路径取决于系统，由安装 bash 的管理员设置。一个常见的值是“/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin”。

这个 gnu.org 上的 Bash 文档页面 ( https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html ) 解释了各种启动文件的来源。在我上面的演示中，不应获取这些文件，因为我既没有在--loginor中生成新的 shell，也没有使用开关--interactive调用sudo 。--login

这个 ServerFault 答案（https://serverfault.com/questions/833762/where-does-the-bash-path-on-centos-7-get-usr-local-bin-from#answer-838552）解释了 Bash 的默认值对于 PATH 变量。即使在 CentOS 7 上回答了 Bash，该答案仍然与 CentOS 8 打包的 Bash 版本相关。根据接受的答案，bash 源代码config-top.h如下：

/* The default value of the PATH variable. */
#ifndef DEFAULT_PATH_VALUE
#define DEFAULT_PATH_VALUE \
  "/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:."
#endif

/* The value for PATH when invoking `command -p'.  This is only used when
   the Posix.2 confstr () function, or CS_PATH define are not present. */
#ifndef STANDARD_UTILS_PATH
#define STANDARD_UTILS_PATH \
  "/bin:/usr/bin:/sbin:/usr/sbin:/etc:/usr/etc"
#endif
bash sudo