> 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'.
You can run dsmc as root via sudo, to gain write access to the error log,
or use the -ERRORLOGNAME option. I do both, depending on what I am doing.
For dsmadmc, I use something like this:
dsmadmc -SE=tsm1 -ERRORLOGNAME=/tmp/dsmadmcerr.log
ls -al /tmp/dsmadmcerr.log
-rw-rw---- 1 spr 0 Mar 5 09:41 /tmp/dsmadmcerr.log
It works with dsmc also. I don't know about dsm(j), as I never use that.
With dsmj not support "-se=", I find it rather useless in a multi-server
installation.
>
> 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
>
>
Thanks,
Steve Roder
University at Buffalo
(spr AT buffalo DOT edu | (716)645-3564)
|