为什么在带有 Debian Stretch 和 pyinotify 的 Google Compute Engine 上使用 IN_CLOSE_NOWRITE？答案

【问题标题】：Why IN_CLOSE_NOWRITE on Google Compute Engine w/Debian Stretch and pyinotify?为什么在带有 Debian Stretch 和 pyinotify 的 Google Compute Engine 上使用 IN_CLOSE_NOWRITE？
【发布时间】：2018-01-17 12:40:34
【问题描述】：

我尝试根据 Google 库存图片在 Google Cloud Compute Engine 虚拟机上设置 Fail2Ban。 Fail2Ban 使用 apt-get 安装并运行良好，但规则永远不会触发。当我使用 fail2ban-regex 验证规则时，规则确实匹配实际日志文件中的行。

经过一番调查，我发现如果我对自己更改的文件运行 pyinotify，我会看到：

<Event dir=False mask=0x20 maskname=IN_OPEN name='' path=/tmp/test pathname=/tmp/test wd=1 >
<Event dir=False mask=0x2 maskname=IN_MODIFY name='' path=/tmp/test pathname=/tmp/test wd=1 >
<Event dir=False mask=0x8 maskname=IN_CLOSE_WRITE name='' path=/tmp/test pathname=/tmp/test wd=1 >

OTOH，日志文件的事件总是以 IN_CLOSE_NOWRITE 结尾。

<Event dir=False mask=0x2 maskname=IN_MODIFY name='' path=/var/log/auth.log pathname=/var/log/auth.log wd=1 >
<Event dir=False mask=0x20 maskname=IN_OPEN name='' path=/var/log/auth.log pathname=/var/log/auth.log wd=1 >
<Event dir=False mask=0x1 maskname=IN_ACCESS name='' path=/var/log/auth.log pathname=/var/log/auth.log wd=1 >
<Event dir=False mask=0x10 maskname=IN_CLOSE_NOWRITE name='' path=/var/log/auth.log pathname=/var/log/auth.log wd=1 >

这就是规则不触发的原因吗？

我尝试将 Fail2Ban 后端设置为轮询，但没有改进。如果我tail -f 日志文件，我可以看到它们在有要记录的事件时被附加。

我不知道 Google 是否以某种方式调整了他们的 Debian 映像，或者这是否是虚拟化环境的副产品。

我的下一步应该是什么？

这是fail2ban.log：

2018-01-19 15:29:23,309 fail2ban.jail    [13935]: INFO    Jail 'sshd' uses pyinotify {}
2018-01-19 15:29:23,312 fail2ban.jail    [13935]: INFO    Initiated 'pyinotify' backend
2018-01-19 15:29:23,313 fail2ban.filter  [13935]: INFO    Set maxRetry = 5
2018-01-19 15:29:23,313 fail2ban.filter  [13935]: INFO    Added logfile = /var/log/auth.log
2018-01-19 15:29:23,314 fail2ban.filter  [13935]: INFO    Set findtime = 600
2018-01-19 15:29:23,314 fail2ban.actions [13935]: INFO    Set banTime = 600
2018-01-19 15:29:23,314 fail2ban.filter  [13935]: INFO    Set jail log file encoding to UTF-8
2018-01-19 15:29:23,315 fail2ban.filter  [13935]: INFO    Set maxlines = 10
2018-01-19 15:29:23,338 fail2ban.server  [13935]: INFO    Jail sshd is not a JournalFilter instance
2018-01-19 15:29:23,342 fail2ban.jail    [13935]: INFO    Jail 'sshd' started

无论 auth.log 得到什么，都没有“[sshd] Found”行。

【问题讨论】：

基本上GCE images changes 与运行客户环境的守护进程有关。 /var/log/fail2ban.log 中有什么内容？
感谢您的关注。我在帖子中添加了日志示例，对于 cmets 来说太长了。

标签： google-cloud-platform google-compute-engine gcp fail2ban pyinotify

【解决方案1】：

已解决：设置时区后我没有重新启动 rsyslog 服务。 Fail2ban 使用本地时间，而 rsyslog 使用 UTC。我花了一段时间盯着上面粘贴的日志。我没有查看小时、分钟和秒是否匹配。内核和用户空间是本地时间，但 rsyslog 不是。

我仍然不知道为什么 pyinotify 会登录 IN_CLOSE_NOWRITE。就我而言，这毕竟是一条红鲱鱼。

【讨论】：