Burning macOS issues

Support
#1

There are two issues right now on macOS that need some guidance:

  1. Macs with multiple users and SIP enabled: how to backup other users? Installing Duplicacy instance to each user is not sustainable and cumbersome (if anything due to port conflicts). Running it as root not really an option since it does not validate integrity and signatures of CLI engine it launches. What is the official guidance here?
  2. Macs with SIP enabled: command line Duplicacy use. Since we can’t whitelist a naked executable for full disk access — can we expect Acrosync signed app bundle wrapper for the CLI engine? Or maybe Duplicacy_web to support interactive mode where instead of launching webserver and running schedules it would take and pass command line arguments to the CLi engine?
1 Like
#2

What if the web GUI checks the signature of the CLI (by running codesign -dv cli_path)?

I can do this for the next release.

Script for configuring duplicacy CLI for Unattended (launchd) Throttled (cpulimit) All Users backup on macOS, without disabling SIP
Shadow copy -vss fails on macOS Big Sur
#3

Would not that break updating CLI? Or are you going to be only checking signature validity and the signing certificate/team ID? That should work I guess.

that would be awesome! Will it be a separate .app or duplicacy_web will have “interactive” mode?

Source of all of that – I finally decided to re-enable SIP on one of my Macs and well, it did not go well :slight_smile: I’m now installing pre-release of Big Sur Preview on one of my older Macs so it would be interesting to see how duplicacy behaves there too.

#4

Up. What are plans with this? Essentially Duplicacy CLI is not usable on macos with SIP enabled.

#5

I made a wrapper app for the CLI, but the remaining issue is how to get the output from the wrapper app. I added a global option to send the output to syslog, but not sure if this is the right way. For one thing, this would definitely pollute the syslog with too many logs.

#6

You mean the os_log? But that’s it’s purpose, isn’t it? to funnel all application logs into one place to make it easier to sift through them with varying degree of verbosity as needed:

https://developer.apple.com/documentation/os/logging/generating_log_messages_from_your_code

For example Info level logs won’t even be persisted to disk unless user is looking at them.

#7

I still don’t understand the usage of the CLI wrapper app, mostly due to lack of the direct output.

If you run this app manually, then you’ll have to view the output in the Console app?

If you run this app in a script, then you’ll need to grep the application logs to find the output from the last invocation?

#8

I’m not sure how launching a bundle manually is supposed to work – I don’t think it has attached terminal by default. But the use case I had in mind was running duplicacy unattended, likely via the scheduler (launchd), where the stdout is dropped on the floor anyway, (unless user explicitly redirects it to file), not the manual backup invocation.

In either case, if user wants to watch the log while the duplicacy is running they would be able to do log stream --info --predicate 'process contains "duplicacy" . Or even --debug instead of --info. But I don’t think you can get log from a bundle without attached console.