WireGuard 源 IP 地址"漂移"问题的前因后果
在现代网络架构中，VPN（虚拟专用网络）技术的应用越来越广泛。本文将探讨在我司 IDC 中，使用 WireGuard 实现的 VPN 连接中遇到的一个有趣现象。
centralized logging on Amazon Linux 2023
背景介绍
最近要做个 log server，把所有服务器的系统日志都收上来。我现在的服务器，操作系统有两种：Amazon Linux 2023 和 Ubuntu，但其实 Ubuntu 又有 22.04 和 24.04 两种，所以，其实是一共有三种操作系统。
好在这三种系统，其缺省跑的日志应用，Amazon Linux 2023 是 systemd-journald，而 Ubuntu(22.04 和 24.04) 都是既跑有 systemd-journald，又跑的有 rsyslogd。这两种日志应用，都是支持集中的日志服务器的，或者很容易支持。但是为什么不就用一套 rsyslogd 的日志服务器呢？毕竟大家都支持 rsyslogd 的。主要是因为 systemd-journald 相对于 rsyslogd 是很新的东西，所以这里也拿出来练练手。
AWS 官方的部署 Python 代码到 Lambda function 上去的两种方法
简介
要把 Python 项目部署到 AWS 的 Lambda function，AWS 官方提供了两种方法：Chalice 和 SAM(AWS Serverless Application Model)，当然，其实比较常用的还有第三方的 serverless。
Terraform 官方文档配置导致的 DB Proxy 故障案例
起因
在搭建新环境时，我们选择了 OpenTofu——这是在 Terraform 更改了 license 之后从 Terraform 代码库分支并且开放源码的工具——用于构建VPC、RDS、Redis等基础设施。
但当基础设施就位、开始部署应用程序时，问题出现了。每次部署都不成功，查看日志说是 JDBC 相关错误，DB Proxy 的日志中充斥着诸多 “internal error”，却若隐若现关于具体错误原因的描述。尝试直接通过 MySQL 客户端连接 DB Proxy 时，大多数命令执行都引发错误（help 命令除外）提示：
ERROR 1105 (HY000): Unknown error
错误截图参见：
通过实时监控日志里的敏感信息来实现对应用的监控报警
背景
项目有一些非常重要的后台应用是跑在 AWS 的 lambda 上的，老板和产品非常关注这些应用的执行情况，一旦出错，都会是很严重的故障。
方案变迁
前面做过一些基础设施级别的监控报警，如：监控 AWS 的 RDS 并通过企业微信来报警，那个完全是利用基础设施自动打到 CloudWatch 的基础的 metrics 来做的。
于是，我这里下意识的就想利用现有的 CloudWatch 里现成的 Metrics 来做这个事情，于是我就弄了三个（种）监控：
Chromebook 安装 Debian 12 testing
缘起
本来这台 HP Chromebook 11A G6 EE( 加了一张 128G 的 TF 卡 )，我安装好了 Arch Linux(Xfce)，都弄好了的，但最近在知乎上老被安利说装 Debian 的 testing 版，于是我又开始折腾，把 Debian 13 testing(trixie) 安装到这台 Chromebook 上。
安装时，使用 lvm 分区不成功，系统报错：
partman-lvm: pvcreate: error while loading shared libraries: libaio.so.1: cannot open shared object file: no such file or directory
现在想想可能还有其他办法，比如想办法把这个需要的包注入进去，但当时选择了先用 ext4 分区安装系统自带的 16G 的卡里，装完以后再想办法转成 lvm 并把 TF 卡的空间加进来。