cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
910
Views
0
Helpful
6
Replies

LMS 2.6 backup schedule issue

yjdabear
VIP Alumni
VIP Alumni

I got "Cannot read schedule info. Please look into the log files." when trying to change the backup location in LMS 2.6 Common Service. I don't see any pertinent log file getting updated in /var/adm/CSCOpx/log/. Is LMS having trouble reading the crontab?

1 Accepted Solution

Accepted Solutions

Joe Clarke
Cisco Employee
Cisco Employee

Correct, this error indicates a problem accessing the crontab file for casuser. The backup code will try to run crontab -l as casuser. If that fails, but the crontab file actually exists, then you will see this error.

View solution in original post

6 Replies 6

Joe Clarke
Cisco Employee
Cisco Employee

Correct, this error indicates a problem accessing the crontab file for casuser. The backup code will try to run crontab -l as casuser. If that fails, but the crontab file actually exists, then you will see this error.

I got "crontab: you are not authorized to use cron. Sorry." when issuing "crontab -l" as a user with the same uid as casuser, who's in neither cron.allow nor cron.deny. Does that jive with everything happened so far? Can the backup mechanism from the GUI be tweaked to work with any other schedular than cron on Solaris?

Chances are the perms on crontab have been changed. crontab must be:

-r-sr-xr-x 1 root bin 20336 Jan 22 2005 /bin/crontab

Note the setuid bit. As for using a different scheduler, this is not possible.

The permissions look ok.

-r-sr-xr-x 1 root bin 17224 Nov 16 2006 crontab

After getting casuser added to cron.allow, I was able to modify the backup schedule from the GUI.

Would it make sense for the LMS install script to always append "casuser" to cron.allow on Solaris?

cron.allow doesn't exist by default on Solaris. All that is required by default is for casuser NOT to exist in cron.deny. If a cron.allow does exist, then yes, casuser needs to be in there. We do check these things at installation time, but we do not modify these files. Instead, we will throw up a warning. If you check your installation log, the warning should be there provided the cron.allow file existed at installation time.

That makes sense. The cron.allow/deny are recent additions.

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: