|
We've been battling this same issue since upgrading to
6.5.1 on our masters. The VRTSat package is related to this and it's not sure if
that package is creating the directory or NBU processes are. Some things of note
so far is that the '/var/VRTSat/.VRTSat/profile/VRTSatlocal.conf'
file is being modified from what appears to be a normal entry
of;
VRTSatlocal.conf:"TrustStoreDirectory"="/var/VRTSat/.VRTSat/profile/truststore"
To an incorrect entry of;
"SystemDefaultTrustDirectory"="%SysTrustDir%"
When the incorrect entry is in place, it seems when you
some or all NBU commands a %SysTrustDir% directory is created in your current
path or in the .VRTSat/profile directory. It's a mystery at this point as to
who's doing what and I've currently got a case open with support on it while we
continue to look into it internally. The only issue we've seen is it created
this directory in the 'remote_versions' directory and causes vnetd to have
issue looking up that invalid host name.
Unfortunately, I don't have an answer, but maybe this
information will help track the root cause down.
-Trey
Has anyone seen where a directory shows up with perms of 700 named
%SysTrustDir%
drwx------ 2 root
root 4096 Apr 17 18:41 %SysTrustDir%
Incidentally, there's nothing in that
directory.
It's all over the place on my NBU v.6.0MP6 environment and
caused my catalogue backup to fail because it was in the staging directory and
NBU couldn't delete it. Once I deleted it the catalogue backup ran
fine. But something is creating it and I think it's NBU when it does a
backup. I know, it doesn't make sense but I can't think of anything
else.
Any ideas?
--
Brian J.
Greenberg
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
| 