Project

General

Profile

Bug #5361

ndmpd compatibility problem with ndmjob client

Added by Eric Bollengier about 6 years ago. Updated almost 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2014-11-20
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

Using the ndmjob (http://sf.net/projects/ndmjob/files/ndmjob-spinnaker/2003-spinnaker/) implementation, the backup part is running fine, but ndmjob is not able to restore files correctly when using the restore PREFIX.

I started to dig in this issue, and I found that all files sent to the ndmpd daemon are rejected by the function is_file_wanted().

In my example, the PREFIX is set to /exports/restore, original files are located in /exports/test and the FILE parameter is set to "/" in order to include everything.

- the original filename to restore is /exports/tests/foo, it comes from the ndmp stream
- the restore list provided by the ndmjob client is "original=/ destination=/exports/restore/" It is supposed to restore everything
- in ndmpd, the function fix_nlist_v3() is changing this original name "/" to "/exports/restore/" in the internal restore file list. (looks strange for me, this is no longer the "original" name)
- in ndmpd, the function is_file_wanted() is trying to match the modified "original" name "/exports/restore/" against the name provided by the ndmp stream, aka, "/exports/tests/foo". Of course, "/exports/restore" is not a part of the filename (not a parent, not a glob, etc...), and the file is rejected.

The ndmjob command line to restore looks like
./ndmjob -x -F / -f FakeTape -B dump -T. -D 192.168.0.202/m,root,xxx -C /export/restore -E DIRECT=n

debug output:
[ndmpd_save_nlist_v3:769]:orig "/export/test"
[ndmpd_save_nlist_v3:770]:dest "/export/restore/export/test"

The fix_nlist function is changing the original path from /export/test to PREFIX+/export/test
[fix_nlist_v3:2772]:orig0: "/export/restore/export/test"
[fix_nlist_v3:2775]:dest0: "/export/restore/export/test"

The is_file_wanted function is trying to match with name coming from the ndmp stream against the wrong pattern.
[is_file_wanted:1586]:is_file_wanted> flg: 0x1 name: [/export/test/]
[is_file_wanted:1592]:match ?> pos: 0 [export/restore/export/test][/export/test/] # debug added by me

When trying to restore at the same location using the following options:
./ndmjob -x -f FakeTape -B dump -T. -D 192.168.0.38/m,root,xxx -C / -E DIRECT=n -F /export/test

We saw the following in the log
[ndmpd_save_env:546]:env(PREFIX): "/"
[ndmpd_save_nlist_v3:769]:orig "/export/test"
[ndmpd_save_nlist_v3:770]:dest "/export/test"

The original filename is not changed (or changed in a way that doesn't break the code)
[fix_nlist_v3:2772]:orig0: "/export/test" (I added a new debug line to display the original name)
[fix_nlist_v3:2775]:dest0: "/export/test"

The file is accepted:
[is_file_wanted:1586]:is_file_wanted> flg: 0x1 name: [/export/test/passwd]
[is_file_wanted:1623]:parent1> pos 0 [export/test][/export/test/passwd]

So, I wonder if this fix_nlist_v3 function is working correctly, and if someone is able to restore files with an other NDMP client using the PREFIX option.

When removing the last part of the fix_nlist_v3 function that is changing the original name (ep->nm3_opath), I'm able to restore at a different location.

#1

Updated by Eric Bollengier almost 6 years ago

Can someone tells me where I can report this issue to get some help?

#2

Updated by Alexander Pyhalov almost 6 years ago

If I understand this correctly, the software was released 10 years ago, so it seems you are at your own. If you want some help, you could ask for help in illumos or OI mailing lists. If you find some difference in behavior between Solaris and illumos which affects this soft, I agree that it's illumos or OI bug. But for now I think that it's too little details to consider this OI bug.

Also available in: Atom PDF