踩坑记录 on 友派博客

Docker + Postgres 密码玄学：一次 Nano 自动换行引发的血案与排错实录

Sun, 26 Apr 2026 21:30:00 +0800

作为一个折腾服务器的独立开发者，经常和 Docker 打交道。本以为 docker-compose up -d 部署个 PostgreSQL 是闭着眼睛都能搞定的常规操作，结果最近却结结实实栽进了一个连环坑里。

报错信息大家都很熟悉：

FATAL: password authentication failed for user "app"

但在我反复核对环境变量、网络配置、甚至是容器间的互通性都没问题后，事情开始变得诡异起来。经过两天的抽丝剥茧，我发现这不仅仅是一个简单的密码拼写错误，而是由幽灵配置、挂载盲区和编辑器特性共同组成的三重陷阱。

这篇博客记录了整个排查过程，希望能帮到同样在终端里怀疑人生的你。

第一重陷阱：“负负得正”的幽灵密码

事情的起因是这样的：我发现新建的应用容器死活连不上 Postgres，但我之前部署的另一个 Auth 服务却能正常连接。

我一开始猜测是不是走 Docker 内部网络（比如 Host=pgsql）就能免密？但 Postgres 的 pg_hba.conf 机制决定了 TCP 连接必须走 scram-sha-256 校验，不可能免密。

通过在容器内部直接 echo 环境变量，我揪出了第一个内鬼——未加引号的 .env 注释。

在早期的项目中，我有个.env文件是这样写的：PGSQL_APP_PASSWORD=app@pgsql # 应用通用密码

然后我在docker-compose.yaml中这样写了：

POSTGRES_APP_PASSWORD: ${PGSQL_APP_PASSWORD:-app@pgsql}

因为.env文件没有加双引号，Docker Compose 粗暴地把后面的空格和中文注释一并吃进了环境变量里。

数据库初始化时，把 app@pgsql # 应用通用密码 当成了完整的密码存了进去。
旧的 Auth 容器读取同样的配置，带着这串超长且带中文的密码去请求，两边竟然完美对上号了（负负得正）！
而我在命令行手动敲写干净的 app@pgsql，自然被无情拒绝。

避坑指南： .env 文件或 docker-compose.yml 中的复杂字符串，特别是带有特殊字符的密码，务必养成加双引号的习惯。

第二重陷阱：被忽视的数据卷（Volume）初始化盲区

发现了上面的问题后，我决定修正配置，改用干净的密码 app#pgsql，并重新启动容器。结果——依然报错！

我进入容器内部打印环境变量，确认 $POSTGRES_APP_PASSWORD 已经是正确的 app#pgsql，为什么还是连不上？

这时候，我注意到了 docker-compose.yml 里的这行代码：

volumes:
 - ./data:/var/lib/postgresql/data

这是 Postgres Docker 镜像的一个经典“潜规则”：只要挂载的目标目录（/var/lib/postgresql/data）不为空，容器启动时就会直接跳过整个初始化流程（包括执行 /docker-entrypoint-initdb.d/ 下的脚本）。

因为我之前已经运行过一次，./data 目录下已经有旧数据了。所以即便我改了配置，重启了容器，数据库里的密码依然是上一次初始化时的那个带中文的“幽灵密码”。

避坑指南： 在开发阶段调试初始化脚本时，如果修改了密码或初始数据库结构，必须清空宿主机的 ./data 目录（rm -rf ./data/*），或者进入容器用 ALTER USER 强制修改密码。

最终 Boss：Nano 复制粘贴的“背刺”

好，我删除了旧数据，确信这次一定会重新初始化，docker logs 也清楚地打印出执行了我的自定义脚本 01-init-user-and-permissions.sh，甚至打出了 NOTICE: User created: app。

满心欢喜地去测试连接。 报错：password authentication failed。

那一刻我真的怀疑自己对 Docker 的认知是不是被篡改了。网络没问题、环境变量没问题、数据也清空重来了，究竟是哪里出了鬼？

直到我打开那个 01-init-user-and-permissions.sh 脚本，一行一行地扫，终于发现了这个极其隐蔽的致命伤：

CREATE USER "$POSTGRES_APP_USER" WITH PASSWORD '$POSTGRES_APP_PASSWO
RD');

是的，你没看错。变量名 $POSTGRES_APP_PASSWORD 被从中间腰斩，换行了！

这是怎么发生的？因为我是直接在 SSH 终端里用 nano 编辑器，把另一个服务器的脚本复制粘贴进去的。当你的终端窗口不够宽，且 nano 开启了默认的自动换行（Word Wrap）时，它会在长字符串中间插入一个真正的硬回车（Hard Return）。

在 Bash 的逻辑里，它找不到 $POSTGRES_APP_PASSWO 这个变量（因为后面被回车截断了），于是把它解析为空字符串。最终，数据库真的成功执行了这条 SQL，只不过它执行的是： CREATE USER "app" WITH PASSWORD '';

密码是空的！ 这就是我用正确的密码死活连不上的终极原因。

总结与最佳实践

这三个坑叠在一起，节目效果直接拉满。为了防止自己（或者正在看文章的你）再次踩坑，总结以下几条开发铁律：

终端编辑器防身术： 如果你要在 Linux 终端下用 nano 粘贴长代码或长配置，永远记得带上 -w 参数：
```
nano -w script.sh
```
这会禁用自动换行功能，保命必备。更好的做法是使用 VS Code 的 Remote SSH 插件，直接修改服务器文件，告别终端剪贴板折磨。
环境变量密码规范： .env密码和包含特殊字符的变量，用双引号包起来。行内注释最好另起一行写。
```
# 应用通用密码
PGSQL_APP_PASSWORD="app@pgsql"
```

数据库调试三板斧： 当碰到 Docker DB 密码玄学时，直接在宿主机用超管权限查岗，一秒定音：

# 检查数据库到底吃进去了什么配置
docker exec -it pgsql /bin/bash
echo $POSTGRES_APP_PASSWORD
# 直接用环境变量强制连接测试
PGPASSWORD="$POSTGRES_APP_PASSWORD" psql -h 127.0.0.1 -U app -d postgres

服务器运维就是这样，有时候折磨你两天的并非什么底层内核级 Bug，仅仅是一个看不见的换行符。记录下来，就当是给以后的自己提个醒吧！

全网首发：ColoCrossing 独服踩坑记，用 Docker 优雅征服上古 IPMI 与 KVM 假死

Thu, 02 Apr 2026 21:00:00 +0800

便宜大碗的 ColoCrossing 独立服务器一直备受独立开发者青睐。但当你满怀期待地拿到机器，准备通过 IPMI 挂载 ISO 安装系统时，通常会被现实狠狠地泼一盆冷水——它的底层硬件和 IPMI 管理系统，实在是太老旧了！

翻遍了目前的中文互联网，几乎找不到用现代优雅方式解决这个问题的完整记录。这篇文章记录了我最近在 ColoCrossing 服务器上的一场“受难记”，以及最终如何通过 Docker 实现降维打击的填坑历程。

💥 灾难的开始：现代浏览器与上古协议的冲突

面对基于老旧 Supermicro 主板的 IPMI，我的第一反应是直接用浏览器打开管理地址。然而，噩梦开始了：

现代浏览器早就彻底封杀了不安全的通信协议。无论我是用 Chrome，还是煞有介事地打开 Edge 的 IE 兼容模式，甚至是换用 Firefox，不是“过期的或不安全的 TLS 安全设置”，就是“PR_END_OF_FILE_ERROR”。因为这些老古董 IPMI 使用的是早已被废弃的 TLS 1.0 甚至更古老的弱加密算法。浏览器连登录界面都不让你看。

🌀 越陷越深：IPMIViewer 与 Java Security 地狱

Web 端走不通，那就用官方推荐的方法：下载 IPMIViewer（官方基于 Java 的客户端工具）。

但这引发了第二个深坑。现代版本的本地 JDK 同样对弱加密零容忍。网上的传统教程会教你：找到本地 JDK 目录下的 java.security 文件，把里面禁用的 TLSv1、MD5 等弱加密算法从黑名单里删掉。

我照做了，一顿操作猛如虎，满心欢喜地打开 IPMIViewer 输入 IP 和密码，结果等了半天，直接弹出一个无情的 “Connection failed”。无论怎么调参数、换 Java 版本，就是连不上 KVM 控制台。本地环境被搞得乱七八糟，心态几近崩溃。

🐳 破局之道：Docker 容器化降维打击

在折腾了许久毫无进展后，我意识到：用现代系统去向下兼容上古环境，本身就是一条弯路。 最干净、最优雅的解法是：用 Docker 给它造一个原汁原味的“上古沙盒”。

经过一番搜寻，我找到了一个堪称神器的开源镜像：solarkennedy/ipmi-kvm-docker。这个镜像专门为老旧 IPMI 设计，内置了匹配的 Java 环境和 VNC 桥接。

操作步骤极其简单

只需在任意一台装有 Docker 的机器上（甚至是你的本地电脑）执行以下命令：

docker run -d \
 --name ipmi-kvm \
 -p 8080:8080 \
 solarkennedy/ipmi-kvm-docker

见证奇迹的时刻：

容器启动后，打开你本机的现代浏览器，访问 http://localhost:8080。
此时，你的浏览器里会通过 HTML5 NoVNC 渲染出一个极其清爽的虚拟桌面。
在这个容器提供的浏览器里，输入你 ColoCrossing 服务器的 IPMI IP 地址。在这里，所有的 TLS 协议报错都不复存在。
顺畅登录，点击 Launch KVM，下载 .jnlp 文件并直接在容器内双击运行。
毫无阻碍，KVM 画面瞬间出现！没有 Connection failed，没有任何报错。

用完之后，直接 docker rm -f ipmi-kvm 销毁容器，深藏功与名，宿主机依然一尘不染。

🛑 意料之外的 Boss 战：KVM 画面假死

本以为搞定了 KVM 控制台就可以挂载镜像、一路 Next 安装系统了。结果在尝试安装 Ubuntu 时，我又踩到了最后也是最隐蔽的一个坑。

Ubuntu 的系统引导菜单正常显示，但一敲回车进入安装程序，KVM 画面就瞬间定格，仿佛死机了一样。键盘没反应，无论怎么重新连接 KVM 都没用。

背后的真相是： 当 Ubuntu 等现代系统内核启动，并尝试启用 KMS (Kernel Mode Setting) 切换到高分辨率的现代图形安装界面时，老旧主板上的那颗负责“录制”KVM 画面的底层管理芯片根本无法解码这种高级别/高分辨率的画面，直接“瞎了”。系统其实没死机，还在后台等我点安装，只是我成了盲人。

优雅的解决方案：退守纯文本模式

既然复杂的图形驱动会搞瞎管理芯片，那就彻底放弃图形界面！

放弃死磕 Ubuntu，我果断换用了 Debian 13 (Trixie) 的 ISO。在启动引导菜单中，选择 Command-line install (文本/命令行安装模式)。

Debian 经典的蓝黑相间字符安装界面虽然复古，它极其克制，绝不去触碰底层的复杂显卡驱动。在这个模式下，安装过程异常稳健，行云流水般就完成了磁盘划分（还顺手调教了 LVM 取消了 Swap 分区）和系统安装。

💡 总结与启发

这次 ColoCrossing 的装机之旅可谓一波三折，但也留下了极其宝贵的运维经验：

容器化是跨时代运维的最强武器：面对老旧的硬件和协议，不要试图去降级自己的主力系统，用 Docker 隔离运行特定的上古环境才是正解。
克制即稳定：在老旧服务器上，抛弃花里胡哨的图形安装界面，拥抱纯净的 Debian 文本模式，不仅能避开显卡驱动的暗坑，还能为后期的业务留出最极致的系统资源。

底层基建搭好了，接下来就可以放心跑核心业务了。如果你对后续的高可用架构感兴趣，可以看看我的另一篇实践：《独立开发者的异地灾备实践：PostgreSQL 跨云流复制与全链路 SSL 加固》。

折腾不息，运维不止。祝各位的服务器永不宕机！