Hi, In return to my question about Crontab problems. This was caused by an interesting bug in SSH, thanks to John Surveyor [jsurveyor@macquarie.net.au] for the answer. His exact words are below: - x-- SNIP --x Could it be the case that you are using Solaris 8, with auditing enabled and logging onto the system using SSH ? I suggest that you check the /var/cron/log file and, if the above is all true, look for errors related to auditing. (Check the file anyway in case you have a different problem) Apparently SSH doesnt authenticate correctly so that the auditing doesnt believe your identity. If you then change the crontab it will refuse to run it. I am told that this is an SSH bug and that Sun don't regard it as their problem. I don't know the exact cause of the problem. If this all applies to you then there are some workarounds. 1. Check whether the bug has been fixed in the latest version of SSH (I havent checked this myself for a while) 2. Log on by other means, eg. console. 3. Turn off auditing, with bsmunconv - the full procedure involves a reboot. 4. After logging on with SSH then use login(1) to reauthenticate. This doesnt close the SSH session. Only then use su.=20 An example of (4) would be $ ssh myname@remotesystem passwd: xxxxxxxx -- /etc/motd appears here $ login myname passwd xxxxxx $ su passwd: yyyyyyyy # crontab -e -- and make your changes x-- SNIP --x CHeers Paul Trippett System Engineer, COLT UK InternetReceived on Tue Jul 17 14:03:15 2001
This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:24:59 EDT