Support of burp-2.x

[marcin-github]

Hello! If this code isn't abandoned I'm asking to add posibility to access burp-2.x backup.

[ZungBang]

Code has not been abandoned, it just works (for me...)

I'm using burp 1.x myself, so I can't test burpfs with burp 2.x at the moment, though I was planning to upgrade at some point. In other words, it'll take me a few weeks to get to it.

Note that burpfs uses burp itself in order to actually access files in the backup. Have you tried it at all? if so, what error messages do you get?

hint: try mounting the file system like this

burpfs -o client=CLIENT,allow_other,logging=debug -f /path/to/mountpoint/

and if it works, try to access the file system from another shell/application - any messages in the original shell would come in handy in order to figure out what went wrong.

[marcin-github]

I didn't try before I submit issue. Now I tried and I got: ./burpfs -o client=zserwerek,allow_other,logging=debug -f /mnt/test/ Populating file system ... Getting list of backups with: burp -c /etc/burp/burp.conf -C zserwerek -a l 2016-08-15 22:33:35: burp[13419] /etc/burp/burp.conf: status_port unset 2016-08-15 22:33:35: burp[13419] auth ok 2016-08-15 22:33:35: burp[13419] Server version: 2.0.44 2016-08-15 22:33:35: burp[13419] nocsr ok 2016-08-15 22:33:35: burp[13419] SSL is using cipher: DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD

2016-08-15 22:33:35: burp[13419] extra_comms_begin ok:autoupgrade:incexc:orig_client:uname:sincexc:msg:forceproto=2:rshash=blake2: 2016-08-15 22:33:35: burp[13419] Switched to client zserwerek 2016-08-15 22:33:35: burp[13419] Server is forcing protocol 2 Backup: 0000001 2016-08-03 19:25:57 Backup: 0000002 2016-08-03 20:12:06 Backup: 0000003 2016-08-03 21:20:38 Backup: 0000004 2016-08-10 12:07:33 Backup: 0000005 2016-08-10 12:14:01 Backup: 0000006 2016-08-12 10:59:53 2016-08-15 22:33:35: burp[13419] main socket: Peer closed SSL session 2016-08-15 22:33:35: burp[13419] List finished ok

Backup: 0000006 2016-08-12 10:59:53 Getting list of files in backup with: burp -c /etc/burp/burp.conf -C zserwerek -b 6 -a L -j removing cache directory: /tmp/burpfs-dkzQaA Traceback (most recent call last): File "./burpfs", line 27, in main() File "/var/tmp/portage/burpfs/burpfs/FileSystem.py", line 996, in main server.initialize() File "/var/tmp/portage/burpfs/burpfs/FileSystem.py", line 702, in initialize self.datetime) File "/var/tmp/portage/burpfs/burpfs/FileSystem.py", line 632, in _list_files backup = json.loads(json_string, object_hook=_decode_dict, strict=False) File "/usr/lib64/python2.7/json/init.py", line 351, in loads return cls(encoding=encoding, **kw).decode(s) File "/usr/lib64/python2.7/json/decoder.py", line 366, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/usr/lib64/python2.7/json/decoder.py", line 384, in raw_decode raise ValueError("No JSON object could be decoded") ValueError: No JSON object could be decoded

And output from burp is:

burp -c /etc/burp/burp.conf -C zserwerek -b 6 -a L -j

The configuration file specifies whether burp runs in server or client mode.

Server usage: burp [options]

Options: -a c Run as a stand-alone champion chooser. -c Path to conf file (default: /etc/burp/burp.conf). -d a single client in the status monitor. -F Stay in the foreground. -g Generate initial CA certificates and exit. -h|-? Print this text and exit. -i Print index of symbols and exit. -l Log file for the status monitor. -n Do not fork any children (implies '-F'). -t Dry-run to test config file syntax. -v Print version and exit. Options to use with '-a c': -C Run as if forked via a connection from this client.

Client usage: burp [options]

Options: -a The action can be one of the following. b: backup delete: delete d: diff e: estimate l: list (this is the default when an action is not given) L: long list m: monitor interface r: restore s: status monitor (ncurses) S: status monitor snapshot t: timed backup T: check backup timer, but do not actually backup v: verify -b Backup number (default: the most recent backup). -c Path to conf file (default: /etc/burp/burp.conf). -d Directory to restore to, or directory to list. -f Allow overwrite during restore. -h|-? Print this text and exit. -i Print index of symbols and exit. -q Randomised delay of starting a timed backup. -r Specify a regular expression. -s Number of leading path components to strip during restore. -t Dry-run to test config file syntax. -v Print version and exit. -x Do not use the Windows VSS API when restoring. Options to use with '-a S': -C Show a particular client. -b Show listable files in a particular backup (requires -C). -z Dump a particular log file in a backup (requires -C and -b). -d Show a particular path in a backup (requires -C and -b).

See http://burp.grke.net/ or the man page ('man burp') for usage examples and additional configuration options.

[ZungBang]

Thanks.

Looks like burp 2.x has different command line options than burp 1.x. I was hoping it would be an easy fix, but it ain't. As I said, this'll take some time to sort out, as I need to setup a suitable development and test environment.

[marcin-github]

I'm not in hurry. Maybe status_port from burp-2 would be usefull to use? http://burp.grke.org/docs/monitor.html

[ZungBang]

Yup. This seems to be the ticket. Thanks for the pointer. It's looks much more involved than what I expected. Thanks.

[ZungBang]

As far as burpfs is concerned there are two problems with the burp 2.x monitor:

1. link targets are not provided in the json directory listings
2. listing is slow - a full listing of file system items requires a monitor query per each directory

Issue (2) is a nuisance, especially for large file systems with many directories. Issue (1), on the other hand, is a show stopper. It can only be fixed by modifying burp proper. I plan to look into this, but it ain't gonna happen soon :-(

[ZungBang]

OK, done. Seems to be sane on my test VM.

You'll need the latest burp from git though, as of commit grke/burp@87ac2ad04f0142588b855cad44f81659b0b6e50e

And you'll need to allow remote monitor connections at the server side if you intend to mount the filesystem at a remote restore-client.

[marcin-github]

Hi! I see that you find time for digging in code, great! And thanks! I'm trying the newest code and I can't access to backup. I turned on debug, used "-o syslog" and I'm getting in log many many lines: Sep 9 10:58:25 localhost BurpFS[19039]: DEBUG - Sep 9 10:58:25 localhost BurpFS[19039]: DEBUG - Sep 9 10:58:25 localhost BurpFS[19039]: DEBUG - Sep 9 10:58:25 localhost BurpFS[19039]: DEBUG -

Nothing is mounted. burp-2.0.46.

[ZungBang]

Have you installed latest burp from git? It's required.

[marcin-github]

Hah, I didn't noticed that there was commit in burp! But... Still it doesn't work for me, symptomps are the same, burp is compiled from just cloned repo.

[ZungBang]

I need you to please try accessing the backup via the burp monitor:

1. run burp -a m
2. make sure you get output like this:

{ "logline": "auth ok" }
{ "logline": "Server version: 2.0.46" }
{ "logline": "nocsr ok" }
{ "logline": "SSL is using cipher: DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
" }
{ "logline": "extra_comms_begin ok:autoupgrade:incexc:orig_client:uname:counters_json:msg:csetproto:" }
{ "logline": "Using protocol=2" }
{ "logline": "in monitor" }

now please type: c:CLIENT:b:NO:p:/ (replace CLIENT with a client name and NO with a valid backup number), hit enter, and check that you get a list of files/directories that are in the backup under the root directory.

[marcin-github]

Strange thing. burp server listens only on ::1 even when I excplicitly set status_port=4972 Temporarly I changed configs to use ipv6 localhost and... burpfs works!:) Thank you:)

[ZungBang]

I've managed to recreate the endless loop at my end. Burp is configured by default to not accept remote status monitor connections, and burpfs enters an endless loop in this case. I pushed a fix for this, and you're supposed to get an error message now.

If this is indeed the cause of the problem at your end, then you should set status_address to :: (ipv6) or 0.0.0.0 (ipv4) in /etc/burp/burp-server.conf and restart the server, so that it'll accept remote status monitor connections.

[ZungBang]

Cool.