| 2004/02/15 Binary hacking bru backup to work over NFS | |
|
π
2004-02-15 23:14
by Merlin
in Linux
What follows is unix centric, and won't tell you much if you're not a programmer/unix user, but you should enjoy it otherwise (please note that I do own a legal copy of bru backup for personal use, which I got with an old boxed set of Red Hat)
I'm trying to get my backup tape library to work as I've never been able to backup the 1TB+ of media files (don't ask) I have (I've been copying them on my other drives, but now I have too many for that to fit) So, I decided to move my tape library to another machine, just for testing (to see if the library was bad, or my SCSI connection or host PC was flaky) But, problem, it wouldn't back up a single file over NFS. After a while, I realized: gargamel:~# bru --version bru: invalid option -- - usage: bru -cdeghitx [-#AabBCEfFGjlLmnNoOpPQRSsuUvVwXYZ] file(s)... Copyright (c) 1994-97, Enhanced Software Technologies, Inc. All Rights Reserved BRU is a backup software product licensed by EST. It is NOT public domain or shareware. Versions are available for almost any type of Unix system. This is the Personal Edition version of BRU 2000. It does not offer ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ support for backup or restore of remote/network filesystems. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ To order a copy of the full version of BRU 2000 or for further information or technical support, please contact Red Hat Software Ah, great. There had to be a way to trick it to backup over NFS anyway (this software is more than 7 years old, I'm probably not able to buy a license today, and I'm not violating the spirit of the license, I'm just doing a backup of one system, but without being able to have the library connected to it) So, I did a couple of straces, one of a local file and one of an NFS file and diffed them. What did I see? open("/bru/.serial_number", O_RDONLY) = -1 ENOENT (No such file or directory) uname({sys="Linux", node="host.svh.domain.tld", ...}) = 0 -lstat64(0x806e5a4, 0xbffff298) = 0 -lstat64(0x8070978, 0xbffff280) = 0 -statfs("dshelf3_X10:D3_MD5_.bz2", {f_type="NFS_SUPER_MAGIC", f_bsize=8192, f_blocks=14836773, f_bfree=1564919, f_files=15073280, f_ffree=14353562, f_namelen=255}) = 0 ^^^^^^^^^^^^^^^^^^^^^^^ -lstat64(0x8070978, 0xbfffee1c) = 0 -access("dshelf3_X10:D3_MD5_.bz2", R_OK) = 0 +lstat64(0x806e5a4, 0xbffff2a8) = 0 +lstat64(0x8070978, 0xbffff290) = 0 +lstat64(0x8070978, 0xbfffee2c) = 0 +access("profile", R_OK) = 0 +lstat64(0x8070978, 0xbfffe6f0) = 0 +access("profile", R_OK) = 0 +open("profile", O_RDONLY|O_NONBLOCK) = 4 +write(1, "c 4k of 6k [1] profile\n", 27) = 27 Aaahahh. man statfs said that NFS_SUPER_MAGIC was 0x6969, which is "ii" in ascii. So, I just opened the bru binary with vi, found one instance of "ii" (I was lucky) and it was around the text strings, so it was definitely in the variable sections of the binary. I changed the string to "ij", and voila, nfs backups. Yeepee! :) The joys of a simple geek may be hard to convey sometimes :) |