We have attempted to implement this fix, however, given the
terseness of the suggestion in the APAR, it is not a complete
fix.

By default, /etc/adsm is owned by root, with permissions set to
700. This makes perfect sense, because that is where encrypted
passwords are stored, and allowing access to that directory to
other users would create a potential security hole.

The APAR does not recommend what permissions should be set
for the child directories, or the file, but the 700 on /etc/adsm
makes the issue moot. No matter what the permissions are set to,
however, the file will never be accessible by a non-root user.

This may not seem to be a problem since the scheduler
process runs as root. For whatever reason, though, the B/A client
also attempts to read this file prior to processing an archive
request. This means that ADSM will create an entry in the
dsmerror.log for every file that is archived by a non-root user.
Since we archive tens of thousands of files per day, this is
not an acceptable situation. Two days ago the root filesystem on
one of our production fileservers reached 100% full because the
dsmerror.log had grown to several hundred megabytes. This could
have easily caused a system crash on a critical system because of
what would seem, at first glance, as a "minor" problem.

If this is to be fixed in PTF6, this will be a six-month
turnaround to fix what appears to be an extremely minor bug. Why
wasn't this picked up and fixed in PTF5?

 -- Tom

Thomas A. La Porte
DreamWorks Feature Animation
tlaporte AT anim.dreamworks DOT com


On Tue Nov 17, Barry Fruchtman <bf AT us.ibm DOT com> wrote:

> It looks like the fix will be in level 6.
>  Have you considered using the workaround described in the
>  APAR closing text?
>
>   TEMPORARY FIX:
>   Create the file manually using touch command:
>     touch /etc/adsm/SpaceMan/config/dsmmigfstab
>
>
>  >> Does anyone, from IBM or otherwise, no when this problem is to be
>  >> fixed?
>
>  >> The details of the APAR are as follows:
>
>  >> ANS917iE: cannot open file /etc/adsm/SpaceMan/config/dsmmigfstab:
>  >> no such file or directory.
>  >> Is received for every file being backed up when not using the
>  >> hasm client for Solaris. The message does not prevent the files
>  >> from being backed up.
>
>  >> This also happens on the SGI client. This was reported in PTF4,
>  >> and still exists in PTF5. We had a 400MB dsmerror.log file
>  >> following last night's backup of one file server, courtesy of
>  >> this problem.
>
>  >> -- Tom
>
>  >> Thomas A. La Porte
>  >> DreamWorks Feature Animation
>  >> tlaporte AT anim.dreamworks DOT com
>
>  Barry Fruchtman
>  ADSM Development
>  bf AT us.ibm DOT com