在我们的服务器之一， yum history报告：
[tschmidt@sl-was01p ~]$ sudo yum history Loaded plugins: product-id, search-disabled-repos, security, subscription- : manager ID | Login user | Date and time | Action(s) | Altered ------------------------------------------------------------------------------- 30 | <dlewandowski> | 2016-10-07 11:18 | E, I, U | 38 EE 29 | <dlewandowski> | 2016-09-16 16:13 | Erase | 3 [...]
但是，报告的login用户发誓他不在靠近机器（物理上或逻辑上）附近的任何地方， last似乎支持这一点：
[tschmidt@sl-was01p ~]$ last|grep dle dlewando pts/0 al-dlewandowski. Tue Oct 11 09:01 - 09:23 (00:22) dlewando pts/0 al-dlewandowski. Tue Oct 11 08:37 - 08:40 (00:02) dlewando pts/1 al-dlewandowski. Tue Oct 4 11:04 - 11:09 (00:04) dlewando pts/0 al-dlewandowski. Tue Oct 4 10:50 - 11:11 (00:21)
系统日志不会报告有问题的yum活动周围的任何sudo活动。
我想找出为什么yum history报告显然不正确的用户。 它从哪里提取信息？ 用户名不会出现在/var/log/yum.log任何地方。
Yum命令logginglogin到机器的用户（login名）。 您可以使用logname名称查看当前会话的login名。 su （有或没有sudo ）会启动一个新的shell，但不会改变login名。
如果您运行yum history stats {TRANSACTION ID} ，它会告诉您存储yum事务数据的SQLite数据库文件的位置。 你可以用sqlite3打开这个文件来找出各种信息。 名为trans_beg的表有一个名为loginuid的字段。
[root ~]# yum history stats 4 Loaded plugins: amazon-id, rhui-lb, search-disabled-repos File : //var/lib/yum/history/history-2015-11-10.sqlite .. [root ~]# sqlite3 //var/lib/yum/history/history-2015-11-10.sqlite SQLite version 3.7.17 2013-05-20 00:56:22 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> .schema CREATE TABLE trans_beg ( tid INTEGER PRIMARY KEY, timestamp INTEGER NOT NULL, rpmdb_version TEXT NOT NULL, loginuid INTEGER);