Permission denied on license.log

Unanswered Question
Feb 3rd, 2009

The problem I am facing is accurately described in another thread in this forum, but not solved. See

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=Network%20Management&topicID=.ee71a02&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cc28dbf

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
Joe Clarke Tue, 02/03/2009 - 09:56

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?

Joe Clarke Tue, 02/03/2009 - 10:15

While different than my server, these permissions are still fine. You could manually chmod 0660 license.log, and those permissions should persist across rotations.

g.meerkoetter Tue, 02/03/2009 - 10:18

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.

Joe Clarke Tue, 02/03/2009 - 10:22

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.

g.meerkoetter Tue, 02/03/2009 - 10:30

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.

Joe Clarke Tue, 02/03/2009 - 10:37

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.

g.meerkoetter Tue, 02/03/2009 - 10:56

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.

Joe Clarke Tue, 02/03/2009 - 10:59

By aware that the log level of WARN will be reset to INFO if you ever have to enable debugging.

g.meerkoetter Tue, 02/03/2009 - 11:06

Joe, many thanks for the caveat and also for your quick response!

This could have taken weeks if I had opened a TAC SR...

Actions

This Discussion