Open calestyo opened 7 years ago
I just see: On other nodes the dirs are created as dcache:dcache... so maybe the above isn't new at all and I just never noticed it before ^^
Still the problem is basically that with different users, the log files/dirs are still created (in some cases) as non-root.
I think on Debian they should be owned root:adm ... even if the actual daemon runs as another user. E.g. Apache runs as www-data, but still, the logs are root:adm.
This looks like logback is using some kind of default configuration initially, before switching to the real configuration (usually /etc/dcache/logback.xml).
Well to me it looks like "the first domain wins"... i.e. one the one node where I see the issue there is a webdav door (running as root for port 80/443 binding)... and pool services (running as dcache).
If webdav is started first, it may simply create event/access at these users.
I think this issue actually roots in what I was talking about in the other systemd-related issues: IMO, dcache should normally run always as user dcache, and just bind to ports, open log files, etc. shortly before it drops privileges from root.
systemd might provide better ways for this... (not sure)... e.g. there are things like AmbientCapabilities= which one could set to allow binding to privileged ports (and dCache could later drop that privilige... if Java supports such thing.
Chris, it would be helpful if you limited a report to a single issue.
For example, there appears to be (at least) three issues:
On item 1. I would put this down as somewhere between a feature request and a simple admin error. You modified the logback configuration to use different directories without first creating those directories. If dCache is running as root then it will auto-create those directories with root ownership: logback provides no controls on how parent directories are created. If you care about ownership and permissions of those directories then you should create them with the correct values (since you editing the logback.xml file). For comparison, note that the dCache packaging takes care of the /var/log/dcache
directory, which the default logback configuration targets (at least, for non-systemd packages).
On item 2. this looks like a bug and needs further investigation.
On item 3. Java simply does not support "dropping privileges" (either changing effective uid or dropping capabilities). Feel free to give systemd's AmbientCapabilities a go. I had some success running dCache with CAP_NET_BIND_SERVICE (outside of systemd), but it required some rather intrusive changes to the OpenJDK packaged files. It would be good to learn whether this is a realistic option with systemd.
Hi.
Again, 3.2.8, Debian/systemd.
I've modified logback.xml as attached (basically just the timestamp format and the access/even logs are written to some subdir. logback.xml.txt
In earlier dcaches (3.1) this worked fine, but now there seem to be some permission issues.
logback creates the dirs, i.e.:
but it creates them with owner root:root (which I think it did as well before)... but now it apparently tries to create the actual event/access log files with the user of the domain (in most cases
dcache
).Thus my pools/etc. logs are full of things like:
Any ideas?
Cheers, Chris.