Permission denied on license.log

Unanswered Question
Feb 3rd, 2009
User Badges:

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
Joe Clarke Tue, 02/03/2009 - 09:56
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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
User Badges:

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
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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
User Badges:

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
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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
User Badges:

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
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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
User Badges:

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