The problem I am facing is accurately described in another thread in this forum, but not solved. See
How can I configure mode 664 for the license.log file permanently? I've browsed log4j documentation for a while, but could not come up with a solution.
Also in /etc/init.d/dmgtd I see
# setting umask is fix for CSCdk14992
So I would not want to mess with that.
This shouldn't be happening. The typical permissions on license.log are 0660, and the log4j subsystem will preserve those permissions when it recreates the log file. What permissions are you seeing on your license.log? What permissions do you have on /var/adm/CSCOpx/log?
[gerold@lms] $ ls -ld /var/adm/CSCOpx/log
drwxrwx--- 3 casuser casusers 3584 2009-02-03 17:48 /var/adm/CSCOpx/log/
[gerold@lms] $ ls -ld /var/adm/CSCOpx/log/license.log*
-rw-r----- 1 casuser casusers 298761 2009-02-03 19:09 /var/adm/CSCOpx/log/license.log
-rw-r----- 1 casuser casusers 512144 2009-02-03 17:48 /var/adm/CSCOpx/log/license.log.1
While different than my server, these permissions are still fine. You could manually chmod 0660 license.log, and those permissions should persist across rotations.
I'm pretty sure that I've done that before. And
pblanc in the other thread also states that the permissions get changed when the file is rotated.
But I'll give it another try.
I just rotated my license.log again, and the group write bit is dropped. This is due to the umask, but again, this shouldn't cause any functional problems with LicenseServer or any other components in LMS.
Well, all CLI tools I've used complained very noisily when the file was not group writable.
This is at least very annoying, consider using such a command from a cron job.
Annoying yes, but not functionally impacting. You could adjust the umask in dmgtd to 007, but that could introduce other security holes. Another workaround would be to schedule a root cron job which periodically changes the permissions on the log files to allow group write. Finally, you could configure logrot to rotate the files more aggressively than log4j. Logrot simply truncates the file so the inode number is not changed.
I've changed my
/opt/CSCOpx/objects/licenses/log4j-license.properties as follows.
< # Keep one backup file
> # Do not keep a backup file, since rolling strips group write permissions
< log4j.category.com.cisco.nm.license=INFO, LicenseAppender
> log4j.category.com.cisco.nm.license=WARN, LicenseAppender
Now the file does not grow so quickly and is
truncated in place without loosing goup permissions when the size limit is reached.