process

A log analysis script is added to syslog docker. The script uses the shortest edit distance algorithm to collect error logs and send them to the test environment alarm group. The script relies on logrotate. The next morning, the expected error collection alarm is not seen. It is found that logrotate is not working.

xxxxxxxx@xxxxxxxx:/srv/log/p10057_syslog/rsyslog$ cat analyze_error_log.log 
('log_path_not_exist', '/srv/log/rsyslog/ejoy_errors/error.log.xxxxxxx')

Two things are done to add the log analysis script:

• Call the analysis script with crontab.
• build a new syslog docker image and add several python libraries that script depends on.

Guess:
Logrotate relies on crontab, whose configuration covers the regular execution of logrotate.
Rollback docker image version. There is no crontab task before.
In fact, this item has been checked during development. The reason why crontab is suspected is that there are no suspicious changes.

ubuntu# crontab -l
no crontab for root

Finally, it is found that the logrotate.conf file has permission problems:

root@xxxxxxx:/etc# /usr/sbin/logrotate -d -v /etc/logrotate.conf 
Ignoring /etc/logrotate.conf because of bad file mode.
Handling 0 logs
root@xxxxxxxx:/etc# ls -l /etc/logrotate.conf 
-rw-rw-r-- 1 root root 351 Sep 29 03:47 /etc/logrotate.conf
root@xxxxxx:/etc# chmod 644 /etc/logrotate.conf 
root@xxxxxx:/etc# /usr/sbin/logrotate -d -v /etc/logrotate.conf 
reading config file /etc/logrotate.conf
Handling 1 logs
rotating pattern: /srv/log/rsyslog/*/*.log  4096 bytes (14 rotations)
empty log files are rotated, old logs are removed
considering log /srv/log/rsyslog/admin/access.log
  log does not need rotating
considering log /srv/log/rsyslog/admin/admin.log
....

That's weird. Why do the permissions of logrotate.conf change? Before that, I didn't know there was a logrotate.conf file, let alone modify it.
There is such a line in syslog/Dockerfile. The permissions of logrotate.conf file in the image are determined by the permissions of syslog/logrotate.conf on the build docker image machine.
COPY logrotate.conf /etc/logrotate.conf
The filemode of logrotate.conf on the publishing machine is 644, and I am 664. Did I accidentally modify the filemode of logrotate.conf? And the filemode is false, which causes me to ignore the modification of filemode?

git config core.filemode false

Set the core.filemode to true and you can't see diff. after some attempts, you can find a cold knowledge of git:

git only records the executable bit of the file

https://medium.com/@tahteche/...
That is, for git, filemode is only 755 (user executable) and 644 (user not executable).

Well, did I accidentally modify the filemode of logrotate.conf? My logrotate.conf is indeed 664, and it's 644 on the packer. There's solid evidence.
Check out battle again. The logrotate.conf of the new checkout is 664.

umask and usergroups'enab

https://superuser.com/questio...

Found after trying.
The difference is that my umask is 002, and the packer is 0022.
My user name is equal to group name, while the packer user name is different from group name.

~ » touch aa
~ » ls -l aa
-rw-rw-r-- 1 enjolras enjolras 0 Sep 29 19:09 aa
~ » umask
002
platformdeploy@DEPLOY-192-168-0-116:~$ touch a
platformdeploy@DEPLOY-192-168-0-116:~$ ls -l a
-rw-r--r-- 1 platformdeploy platform 0 Sep 29 19:56 a
platformdeploy@DEPLOY-192-168-0-116:~$ umask
0022
less /etc/login.defs
Enable setting of the umask group bits to be the same as owner bits
(examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is
the same as gid, and username is the same as the primary group name.
If set to yes, userdel will remove the user´s group if it contains no
more members, and useradd will create by default a group with the name
of the user.
USERGROUPS_ENAB yes

conclusion

In different environments, the permissions of the checked out files are different. It is better to display the permissions of the specified files in the DockerFile.