#2061 Issue closed: ERROR: 'dsmc query filespace' failed

Labels: support / question, no-issue-activity

dcz01 opened issue at 2019-03-01 10:10:

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • ReaR version ("/usr/sbin/rear -V"):
Relax-and-Recover 2.4 / 2018-06-21
  • OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):
OS_VENDOR=RedHatEnterpriseServer
OS_VERSION=6.10
# The following information was added automatically by the mkrescue workflow:
ARCH='Linux-i386'
OS='GNU/Linux'
OS_VERSION='6.10'
OS_VENDOR='RedHatEnterpriseServer'
OS_VENDOR_VERSION='RedHatEnterpriseServer/6.10'
OS_VENDOR_ARCH='RedHatEnterpriseServer/i386'
# End of what was added automatically by the mkrescue workflow.
  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
OUTPUT=ISO
OUTPUT_URL=file:///root/rear
BACKUP=TSM
SSH_ROOT_PASSWORD='$1$HGjk3XUV$lid3Nd3k01Kht1mpMscLw1'
NON_FATAL_BINARIES_WITH_MISSING_LIBRARY='/opt/tivoli/tsm/client/ba/bin/libvixMntapi.so.1.1.0'
  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
    Test virtual machine on VMware
  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
    x86_64
  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
    BIOS and GRUB
  • Storage (lokal disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
    Lokal Disk (one disk)
  • Description of the issue (ideally so that others can reproduce it):
    Problem with the TSM password which has changed on TSM server after 30 days and when an older rescue disk is used with an older stored password. The first automatically launched rear recover doesn't ask for entering a user ID or an password.
  • Workaround, if any:
    Relaunch the rear recover command
  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
    rear-FBD01PSS-1.log
    1
    rear-FBD01PSS.log

gozora commented at 2019-03-01 10:42:

@dcz01 just an idea, but maybe you should exclude /etc/adsm/TSM.PWD from ReaR recovery system (COPY_AS_IS_EXCLUDE_TSM). I'm guessing that presence of this file is causing this behavior.

V.

dcz01 commented at 2019-03-01 11:07:

@gozora Thanks for the fast answer.
But would ReaR ask me the first time booting and executing the automatic recover for the TSM user ID and password?

gozora commented at 2019-03-01 11:12:

Yes I guess so, since TSM.PWD is holding cached login credentials ...

V.

dcz01 commented at 2019-03-01 11:17:

@gozora Ah well, then i'll test it.
But i use an newer TSM client and there isn't a TSM.PWD anymore.
Now there are many password and certification files stored in /etc/adsm, so i must exclude the whole folder.

gozora commented at 2019-03-01 11:52:

You should identify exactly file holding cached password, missing certificates might be fatal ...

V.

dcz01 commented at 2019-03-01 12:08:

@gozora Yes, thats true. Missing certificates can lead to failing connections because TSM is encrypting by default the traffic between server and client at level 8.1.0.0.
Then it's not simply to do so.

gdha commented at 2019-03-01 12:16:

@schabrolles As you are our TSM expert we dare to assign this issue to you - hope you don't mind?

dcz01 commented at 2019-03-01 13:13:

But it isn't possible to exclude only the password file(s) because there is an subfolder which contains the certificates for SSL/TLS.

RESCUE FBD01PSS:~ # ls -la /etc/adsm
total 16
drwxr-xr-x  3 root root    0 Mar  1 10:55 .
drwxr-xr-x 20 root root    0 Mar  1 10:45 ..
drwxr-xr-x  3 root root    0 Feb  5 11:52 Nodes
-rw-rw-r--  1 root root 1290 Mar  1 10:49 TSM.IDX
-rw-rw-r--  1 root root 6319 Mar  1 10:49 TSM.KDB
-rw-------  1 root root  193 Feb  5 11:52 TSM.sth

RESCUE FBD01PSS:~ # ls -la /etc/adsm/Nodes/FBD01PSS/
total 20
drwxr-xr-x 2 root root    0 Mar  1 10:55 .
drwxr-xr-x 3 root root    0 Feb  5 11:52 ..
-rw-rw-r-- 1 root root   80 Feb  5 11:52 spclicert.crl
-rw-rw-r-- 1 root root 5080 Feb  5 11:52 spclicert.kdb
-rw-rw-r-- 1 root root   80 Feb  5 11:52 spclicert.rdb
-rw------- 1 root root  193 Feb  5 11:52 spclicert.sth

And here is some info about the new storing method:
https://www.ibm.com/support/knowledgecenter/en/SSGSG7_7.1.8/client/c_secure_pwd.html

gozora commented at 2019-03-01 13:19:

If I understand it correctly than it should be enough to exclude TSM.IDX, TSM.KDB and TSM.sth, to avoid storing cached passwords in ReaR recovery system.

V.

dcz01 commented at 2019-03-01 15:20:

@gozora Yes, thats true. But now i show you the next issue if you do so.
The restore process hangs because all the output is redirected to an log file and you can't enter the encryption key of some/the files which are encrypted in TSM.

1
2
3

gozora commented at 2019-03-01 15:41:

@dcz01

I'm guessing this redirection comes from 389_check_TSM_connection.sh. Unfortunately I can't do much about it because I'm very limited in my TSM knowledge. Maybe @schabrolles can do something about it if he has some spare time ...

There is however a way how you could deal with this, and it might even be perfect solution to your problem. Some time ago, @jsmeix wrote functionality that can download auxiliary files using curl during rear recover (init) stage.
In general you need to set RECOVERY_UPDATE_URL variable with location pointing to tar ball containing files you want to download and extract during rear recover. In your case, TSM login credentials could be packed in that tar ball, and you could update this tar ball every time your TSM password is changed without need to re-run rear mkbackup.
For more details check default.conf

V.

dcz01 commented at 2019-03-04 08:14:

@gozora Your solution sounds very good, but this won't be possible.
At first this must be done every 30 days when the password at the TSM server expires and the client generates a new one and second how should i do this when the server has crashed?

jsmeix commented at 2019-03-04 10:51:

@dcz01
I am not a TSM user (I have no proprietary third-party backup software at all)
but as far as I understand it what you need is that the TSM restore programs
work interactively so that you get a password dialog from TSM.
Is it what you need or do I misunderstand something?

jsmeix commented at 2019-03-04 10:57:

@dcz01
you should have a look at
usr/share/rear/restore/TSM/default/400_restore_with_tsm.sh
therein in particular things like 0<&6 1>&7 2>&8

jsmeix commented at 2019-03-04 11:05:

@dcz01
right now I noticed in the comments in
usr/share/rear/verify/TSM/default/389_check_TSM_connection.sh
that you had been already involved in
https://github.com/rear/rear/issues/1534#issuecomment-351067465
where to me as a non-TSM user is looked as if in
usr/share/rear/verify/TSM/default/389_check_TSM_connection.sh

dsmc query session 0<&6 1>&7 2>&8

would be enough for the prompt of the general TSM password
cf. the comment there to that after that dsmc query session
the TSM password is known so that later in
usr/share/rear/restore/TSM/default/400_restore_with_tsm.sh
things would work without one more TSM password dialog
so that during dsmc restore we can redirect both stdout and stderr
into the backup restore log file?

dcz01 commented at 2019-03-04 11:39:

@jsmeix @schabrolles Yes, that is right.
The only thing i would like to have or it would also be good for all TSM users here, is that ReaR regardless in which mode it was bootet (manual or automatic restore), if the TSM password is not valid that i can enter it manually.
This actual works only in the manual restore mode when booting/booted like shown in my picture.

1

github-actions commented at 2020-06-28 01:33:

Stale issue message

[Export of Github issue for rear/rear.]