Highlighted
Respected Contributor.
Respected Contributor.
736 views

smdr on OES2018SP2 not working

Jump to solution

After upgrading to OES2018 SP2 I noticed, that smdr crashes, if one tries to authenticate. So backup of Edir and NSS volumes via TSAs not working.

I have already a SR open on this issue, which seems to be a known one. According to support they are working with high priority on this problem.

I have switched to backup the virtual disks, on the Vmware hypervisor level, but would prefer to switch back to the smdr file level backup to allow restore at that level.

Labels (1)
0 Likes
1 Solution

Accepted Solutions
Highlighted
Knowledge Partner
Knowledge Partner

I currently don't have my original lab available, but in another (clustered, that makes a difference) OES2018SP2 offset it seems that you need to have one "tsafs-only" action before loading tsands. So in this offset i need something like the stuff below as after.local. You'll have to set username and password in the "tsatest" line. And you'll have to adapt the path, of course, to match something with just a few files in it...

The "TERM" statement itself is mandatory (the tip mentioned saved me some time), it's value might also be something else (such as "linux").

 

#! /bin/sh
#
# Copyright (c) 2010 SuSE LINUX Products GmbH, Germany. All rights reserved.
#
# Author: Werner Fink, 2010
#
# /etc/init.d/after.local
#
# script with local commands to be executed from init after all scripts
# of a runlevel have been executed.
#
# Here you should add things, that should happen directly after
# runlevel has been reached.
# Thanks to StefanR for the tip mentioned here
# https://askubuntu.com/questions/905027/crontab-error-opening-terminal-unknown


sleep 60

export TERM=xterm-256color

/opt/novell/sms/bin/tsatest --path=/media/nss/DATA/some-very-small-dir -u .admin.services -p password --nowaitonexit

sleep 10

/opt/novell/sms/bin/smsconfig -l tsands

 

 

If you like it: like it.

View solution in original post

0 Likes
12 Replies
Highlighted
Knowledge Partner
Knowledge Partner

This happens if both tsafs and tsands are autoloaded via statements in smdr.conf. From my experience it works if you autoload just tsafs and load tsands manually later via "smsconfig -l tsands". Personally, i load tsands only on specific master boxes (without nss volumes) anyway, but i've some time on troubleshooting this. Defect #1171767 is already open regarding this issue, you might want to open a SR and reference it. The larger the headcount of affected users, the higher the priority.

 

If you like it: like it.
0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

You are correct, loading the tsands manually does work.

Do you load tsands before each backup job and unload it afterwards or do you only load it once and let it run as long as the server is up?

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Personally, (which means for me and my customers) in run dsbk backups on all servers, a tsands backup on ONE box which doesn't host NSS volumes (tsands only), and FS backups on all the others (tsafs only). Hence, i've (let's say WE'VE) never been affected by this issue. But i've played around and based on this playings it SEEMS that it's enough NOT to autoload tsands. So essentially:

- autoload ONLY tsafs

- postload tsands via let's say after.local

- backup whatever you want (NDS, NSS) successfully in any order as often as you like, i've tried with any combination of tsatest and SEP Sesam

While it seems (limited testing,though) to be easy to work around, please open a SR and reference the bug ID given to raise pressure...

 

If you like it: like it.
0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

It seems, that after.local runs too early after the startup of smdr in my case. With after.local it starts about 8 seconds after smdr is up. And then it shows the same behaviour as if it is autoloaded - that means crash.

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

I currently don't have my original lab available, but in another (clustered, that makes a difference) OES2018SP2 offset it seems that you need to have one "tsafs-only" action before loading tsands. So in this offset i need something like the stuff below as after.local. You'll have to set username and password in the "tsatest" line. And you'll have to adapt the path, of course, to match something with just a few files in it...

The "TERM" statement itself is mandatory (the tip mentioned saved me some time), it's value might also be something else (such as "linux").

 

#! /bin/sh
#
# Copyright (c) 2010 SuSE LINUX Products GmbH, Germany. All rights reserved.
#
# Author: Werner Fink, 2010
#
# /etc/init.d/after.local
#
# script with local commands to be executed from init after all scripts
# of a runlevel have been executed.
#
# Here you should add things, that should happen directly after
# runlevel has been reached.
# Thanks to StefanR for the tip mentioned here
# https://askubuntu.com/questions/905027/crontab-error-opening-terminal-unknown


sleep 60

export TERM=xterm-256color

/opt/novell/sms/bin/tsatest --path=/media/nss/DATA/some-very-small-dir -u .admin.services -p password --nowaitonexit

sleep 10

/opt/novell/sms/bin/smsconfig -l tsands

 

 

If you like it: like it.

View solution in original post

0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

Ok, that with the "TERM" statement is new information - I'll try it with that - and thanks for the hint!

 

The other idea with a "tsatest" and some sleep statements I already tried - without success, probably because of the missing "TERM" statement.

 

All in all a quite complicated workaround for this problem. I have a SR open on this issue, but as I am only a small shop, the momentum of my SR is rather tiny, too.

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

tsatest won't run from after.local without a TERM statement, you'd even see the corresponding error in messages (without a hint WHY it failed, though). Nevertheless this pretty dirty workaround should help.

And the more SRs reference the defect, the better.

If you like it: like it.
0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

Indeed it does!

Just tested it on 2 servers. And on one server without NSS volumes (a DSfW server) the "--path=/usr/novell/sys" helped.

This is really weird 😄.

 

0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

 

 

0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

In the meantime (2 days ago) Novell support provided me with a working version of novell-smdr

"novell-sms-1.5.4-0.92.8.1739.0.PTF.1171767.x86_64" with corresponding interface-libs.

 

This version cured all issues described in this thread and 2 backup jobs did work without issues.

 

Now deploying it to all OES production servers.

0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

duplicate

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.