So, recent unixy clients have changed their behavior w.r.t. logfile access; I think I understand (and support) the rationale, but it leaves me with a nontrivial sysadmin problem. Or maybe it's just a silly squeamishness, I dunno.
The change is that, if the client can't write to the error log, it won't do anything. The first time I ran into it, this seemed an irritation; but once I thought about it, I decided it was a superb idea, and was exactly what needed to happen. This way, if something busts, TSM has somewhere to tell you what happened. Fancy that. But we tend to have logfiles 644; this means that any non-root user who attempts to start up the client gets ANS1398E Initialization functions cannot open one of the Tivoli Storage Manager logs or a related file: /var/log/dsmerror.log. errno = 13, The file access permissions do not allow the specified action. OK, working as designed. So how are you folks responding to this? I am squeamish about making the bloody thing world-writable, but can do it. The perfect world would have a fallback errorlog definition available: say, $HOME/dsmerror.log or some such, with a ANSXXXW mentioning the fallback. That would permit me to do things without explicit setup, and separate 'write access to an errorlog' from 'write access to the system errorlogs'. The ability of a random user to do dsmc restore is a -fine- thing IMO. I hate to have it hampered by yet-another-fine-thing, the careful insistence on a place to report errors. - Allen S. Rout
