cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
720
Views
4
Helpful
10
Replies

Permission denied on license.log

g.meerkoetter
Level 1
Level 1

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.

10 Replies 10

Joe Clarke
Cisco Employee
Cisco Employee

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

< 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.

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

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

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

Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco