02-03-2009 09:14 AM
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
umask 027
So I would not want to mess with that.
02-03-2009 09:56 AM
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?
02-03-2009 10:13 AM
[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
02-03-2009 10:15 AM
While different than my server, these permissions are still fine. You could manually chmod 0660 license.log, and those permissions should persist across rotations.
02-03-2009 10:18 AM
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.
02-03-2009 10:22 AM
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.
02-03-2009 10:30 AM
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.
02-03-2009 10:37 AM
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.
02-03-2009 10:56 AM
I've changed my
/opt/CSCOpx/objects/licenses/log4j-license.properties as follows.
< # Keep one backup file
< log4j.appender.LicenseAppender.MaxBackupIndex=1
---
> # Do not keep a backup file, since rolling strips group write permissions
> log4j.appender.LicenseAppender.MaxBackupIndex=0
10c10
< 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.
02-03-2009 10:59 AM
By aware that the log level of WARN will be reset to INFO if you ever have to enable debugging.
02-03-2009 11:06 AM
Joe, many thanks for the caveat and also for your quick response!
This could have taken weeks if I had opened a TAC SR...
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: