Linux lastlog2 的数据库与传统lastlog文件有什么区别

我第一次把登录审计从传统 lastlog 迁到 lastlog2 时，最容易误判的地方是：两个命令都在显示“最近一次登录”，背后却不是同一个文件格式。lastlog2 使用 SQLite3 数据库，传统 lastlog 读取按 UID 定位的稀疏文件；它们可以并存，不能只把命令名替换掉就算完成迁移。

lastlog2 和 lastlog，先看它们各自保存什么

传统 lastlog 的数据文件是 /var/log/lastlog。它按用户 UID 计算记录位置，所以高 UID 或 UID 空洞会让文件的逻辑长度看起来很大；这正是稀疏文件的典型特征。lastlog2 则把记录放进 SQLite3，默认路径是 /var/lib/lastlog/lastlog2.db，官方手册还明确把它描述为 Y2038-safe。

这个差异会影响备份、容量判断和故障排查。ls -l 显示的是旧稀疏文件的逻辑大小，不能直接等同于实际磁盘占用；迁移到数据库后，也不能再用“按 UID 计算偏移”的思路去解析文件。

输出相似，不代表字段和接入方式相同

两套命令都能显示登录名、最近登录时间等信息，也都会对从未登录的用户显示相应提示。但传统 lastlog 的默认输出按 /etc/passwd 顺序组织，lastlog2 手册描述的是按记录首次写入数据库的顺序输出；如果脚本依赖输出顺序，迁移后必须显式改成按字段处理，而不要继续按行号认定用户。

lastlog2 还提供了 --database 指定数据库、--import 导入旧文件、--journal 查看或设置 SQLite journal mode，以及 --service 展示 PAM service 的入口。传统命令的选项集合不同，因此“参数看起来差不多”也不能作为兼容证明。

# 分别查看两套数据源；这两个命令不会把文件格式变成相同结构。
lastlog
lastlog2

# 只查看某个用户，避免用输出顺序猜测 UID 对应关系。
lastlog -u deploy
lastlog2 -u deploy

高 UID 和稀疏文件，为什么会成为迁移触发点

旧实现把 UID 和记录位置绑定。系统里如果存在很大的服务账号 UID，/var/log/lastlog 的逻辑大小可能明显膨胀，某些不识别稀疏文件的外部工具还可能把它当成普通大文件处理。lastlog2 把记录放在数据库里，避免了“最高 UID 决定文件布局”的约束；这并不等于数据库永远更小，也不替你解决备份、权限和 SQLite 锁策略。

我会先用 ls -ls /var/log/lastlog 同时看块占用和逻辑大小，再决定是否迁移，而不是看到 ls -l 的大数字就直接删除旧文件。迁移的理由应该是时间安全、工具链和维护方式，而不是单一容量数字。

迁移时不要只替换命令，先处理数据和 PAM

官方工具提供了从旧文件导入的入口。导入会覆盖新数据库中对应的已有记录，所以建议先保存旧文件和数据库，再在维护窗口执行：

# 先保留旧数据与新库，文件名中加入主机角色便于回退。
cp --reflink=auto /var/log/lastlog /var/backups/lastlog.before-lastlog2
cp --reflink=auto /var/lib/lastlog/lastlog2.db /var/backups/lastlog2.before-import.db

# 把传统 lastlog 数据导入 lastlog2；同名记录可能被覆盖。
lastlog2 -i /var/log/lastlog

# 导入后只检查一个明确用户，确认查询入口已经能读到记录。
lastlog2 -u deploy

这里的“能查询到”只说明数据库里有数据，不说明所有登录路径都会继续写它。lastlog2 依赖 pam_lastlog2.so 或相应 PAM 会话配置来展示并保存新登录；上线前要逐个检查实际使用的 PAM service，不能把一个成功的手工查询当成接入完成。

我会怎样安排最后一轮回归检查

迁移完成后，我会把检查拆成四个互不替代的判断：一是用 lastlog2 -u 用户名 确认导入结果；二是检查目标 PAM service 是否加载 pam_lastlog2.so；三是用 lastlog2 -j 了解当前 journal mode，只有确有并发读写压力时再评估 WAL；四是保留旧文件和数据库备份，直到新链路完成一次真实维护窗口。

如果系统仍有旧脚本、旧包或合规工具只认识 /var/log/lastlog，不要在没有兼容方案的情况下删除旧文件。迁移的完成标准不是“新命令能运行”，而是调用方、PAM 写入、备份恢复和审计读取都已经改到同一套数据源。

相关问题

lastlog2 能直接替代所有 lastlog 脚本吗？

不能直接假定。脚本如果依赖旧文件路径、输出顺序或稀疏文件结构，就需要按字段和命令选项重新处理。

lastlog2 数据库文件存在，为什么没有新登录记录？

数据库文件只代表存储位置存在。还要检查实际 PAM service 是否接入 pam_lastlog2.so，以及登录流程是否经过该 PAM 会话栈。

迁移前是否应该删除 /var/log/lastlog？

不应该先删。保留备份能帮助处理旧工具依赖和导入结果不符合预期的回退场景，确认调用方迁移完成后再按发行版策略清理。