Merge ~ahasenack/ubuntu/+source/tomcat9:kinetic-tomcat9-logging-fix into ubuntu/+source/tomcat9:ubuntu/devel
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | git-ubuntu bot | ||||
Approved revision: | not available | ||||
Merge reported by: | Andreas Hasenack | ||||
Merged at revision: | 165edec1c2d4dced29ab2a01c4d45ccade3f68b6 | ||||
Proposed branch: | ~ahasenack/ubuntu/+source/tomcat9:kinetic-tomcat9-logging-fix | ||||
Merge into: | ubuntu/+source/tomcat9:ubuntu/devel | ||||
Diff against target: |
74 lines (+21/-4) 5 files modified
debian/changelog (+13/-0) debian/control (+2/-1) debian/logrotate.template (+2/-2) debian/rsyslog/tomcat9.conf (+1/-1) debian/tomcat9.postinst (+3/-0) |
||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
git-ubuntu bot | Approve | ||
Christian Ehrhardt (community) | Approve | ||
Canonical Server Reporter | Pending | ||
Canonical Server | Pending | ||
Review via email: mp+425340@code.launchpad.net |
Description of the change
This fixes tomcat9's logging via ubuntu's unprivileged rsyslog.
PPA: https:/
# Context
The package sets /var/log/tomcat9 to be 2770 tomcat:adm, so newly created files will inherit the adm group ownership.
There are 4 entities writing to /var/log/tomcat9 and they all need to agree on permissions and ownership:
- rsyslog: catalina.out only, runs as syslog:adm. It can write to /var/log/tomcat9 due to the adm group permission
- logrotate: catalina.out and its rotated logs only. Runs as root, can set any permission/
- java (tomcat9 itself): localhost*, catalina.
- tomcat9's maintainer scripts (postinst): chown -Rh tomcat:adm /var/log/tomcat9
With the above in mind, consider that there are only two groups of files in /var/log/tomcat9:
- logs produced by the java process directly, which runs as tomcat:tomcat
- single log file written to by rsyslogd, which runs as syslog:adm
Our main problem is with the rsyslogd-produced log file: /var/log/
I chose to alter 3 of these writers:
- rsyslog: drop the ownership setting of catalina.out. We run unprivileged and cannot set the owner to tomcat, which is what debian does
- logrotate: switch to syslog:adm. Without this, rsyslog won't be able to write to catalina.out. Here I could have just dropped the "create" and "su" lines, because logrotate will keep the permissions and ownership of the file it is rotating in the new empty file it creates. I also don't think we need to use "copytruncate", this seems to be old history from when catalina.out was produced by tomcat itself, and not via rsyslog. But one thing at a time.
- postinst: add another chown, specific to catalina.out*, to adjust the permissions back to syslog:adm. I could have replaced debian's chown -R with something more elaborate, that would loop over the logs and skip catalina.out*, or chown it differently, but here I wanted to keep our delta simple.
The above changes survive logrotation events ("logrotate -f /etc/logrotate.
For testing, an easy way to trigger writing to /var/log/
Wow there are really a lot of combinations of different actions and their order to consider here.
AFAICS you covered them all well and I approve +1
I have one minimal comment to enhance an explanation that you have made, but that is up to you if you agree.
For Kinetic this really is step forward.
I'm a bit scared of SRUing this despite seeming absolutely correct. ownership always has an odd feel of "what if someone manually adapted for this problem".
Changing permissions/
We have had this in the past and depending on the uncertainty level we guarded the changes by evaluating the situation if it matches the expected one (in this case perm/ownership) but back then all changes were in maintainer scripts, here with conf files and such this would not work.
Did you discuss the SRUability of this with anyone on the SRU team already?