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