Timeline for Logrotate no longer reads symlinked configuration file due to non-root ownership
Current License: CC BY-SA 3.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 2, 2014 at 7:49 | comment | added | pelle | @phantomwhale Your original approach implicitly gave your deployer user full root privileges. That's not new in logrotate 3.8. If you want to restrict the deployer's rights while still allowing it to update the config, then I think you need to use something other than logrotate. | |
| Sep 2, 2014 at 1:56 | comment | added | phantomwhale | Our approach had always been to prefer to symlink from directories external to the application into application files, such that each deploy not only pushes out the new application, but also any configuration file changes. Even giving the deployer the rights to deploy code outside of the application directory violates this approach - but equally having to chown an application file to be root owned post-deploy feels like a bad thing (tm) too. Perhaps the original approach therefore can no longer work nicely with logrotate 3.8.0+ | |
| Sep 1, 2014 at 13:18 | history | answered | pelle | CC BY-SA 3.0 |