Action: disable/enable TimeMachine

[ari]

A feature request for this excellent application. I'd like to be able to easily disable time machine when my computer is on a remote network from the time machine mount point (I use netatalk on a FreeBSD file server running ZFS at the office). Otherwise, the machine establishes a VPN tunnel and then saturates the link trying to back up remotely.

I have tried doing this as a shell script, but for some reason that is unreliable and works only 50% of the time. If there is a Cocoa API, that would be much better I think.

By the way, I'm creating a task here in github rather than in your RubyMine instance because it is so much easier (no waiting for my account to be approved, existing login, etc).

[dustinrue]

There isn't a way to enable/disable Time Machine programmatically that I've found that doesn't require admin privileges.

There are two ways you can get this to work today however. One option is, if you're familiar with it, configure sudo to not require a password to run either any program as root or just defaults. Once that is done, you can use a shell script action to enable or disable time machine with 'defaults write com.apple.TimeMachine AutoBackup -bool true' and 'defaults write com.apple.TimeMachine AutoBackup -bool false' respectively. This method has obvious security risks involved so it's up to you to decide if it is worth it.

The other option is to run the same set of commands as a normal user, but doing so will cause very strange behavior in System Preferences, at least under Lion.

I think for a long term fix for this issue is to have a helper app/daemon that is running as root that ControlPlane can talk to to perform tasks "normal" users can't do.

[ari]

I've previously just set that script to setuid root, but for some reason it hasn't been reliable. I don't know that changing the default while time machine is already running does what is expected.

I guess Control Plane can use XPC Services ( http://developer.apple.com/library/mac/#documentation/macosx/conceptual/osx_technology_overview/systemtechnology/systemtechnology.html ) as a way to getting root to do the things it needs to. Doesn't it need similar levels of access to change network settings?

[dustinrue]

XPC looks interesting, even if it is Lion only. I'll look into that but I want to be able to support Snow Leopard for awhile yet.

Network settings are changed using scselect which is a command line utility to switch between predefined network locations. I'm pretty sure network locations are a per user thing, where Time Machine is "global."

[djbe]

From what I've seen so far online and from testing it on my own machine, running this command:
defaults write /Library/Preferences/com.apple.TimeMachine AutoBackup -bool false
without the root rights (sudo) works fine (plist file gets edited correctly). Is there a reason why you're not doing this?

Edit: to be clear, this is the command I find everywhere when searching for enabling/disabling TM, so it should work.
Edit2: lol, it's even explained for MarcoPolo here: http://blog.laaz.org/tech/2009/11/16/location-aware-time-machine/

[dustinrue]

Yes. It appears to work but what you get is a new pref file in your user home dir. Once it is there you can no longer control tm via sys prefs properly.

Dustin

On Sep 1, 2011, at 4:39 AM, djbereply@reply.github.com wrote:

From what I've seen so far online and from testing it on my own machine, running this command:
defaults write /Library/Preferences/com.apple.TimeMachine AutoBackup -bool false
without the root rights (sudo) works fine. Is there a reason why you're not doing this?

Reply to this email directly or view it on GitHub:
#3 (comment)

[djbe]

Uhm no, it's editing the plist in /Library/Preferences, not ~/Library/Preferences. Checked it right now to make sure.

[dustinrue]

There is also a command in lion called tmutil, but it requires root privs to toggle tm.

SysPrefs is able to toggle tm without elevated privs and I've been trying figure out how. Unfortunately I've been swamped with work stuff lately and can't give this issue enough time, my brain mush by the end of the day anyway.

If you can find a way interface with tm, that would be great. After reading a bit I want to avoid a suid program and stick with best practices. The BAS lib could do the trick, but I first was trying to see how to tie into what SysPrefs used.

Dustin

On Sep 1, 2011, at 4:39 AM, djbereply@reply.github.com wrote:

From what I've seen so far online and from testing it on my own machine, running this command:
defaults write /Library/Preferences/com.apple.TimeMachine AutoBackup -bool false
without the root rights (sudo) works fine. Is there a reason why you're not doing this?

Reply to this email directly or view it on GitHub:
#3 (comment)

[dustinrue]

Not the behavior I see on my machine at all but what you describe is how I thought it used to work. Is the ownership on your plist file correct?

On Sep 1, 2011, at 6:31 AM, djbereply@reply.github.com wrote:

Uhm no, it's editing the plist in /Library/Preferences, not ~/Library/Preferences. Checked it right now to make sure.

Reply to this email directly or view it on GitHub:
#3 (comment)

[djbe]

NetworkLocation can do it (now called SideKick) without root privileges.

[djbe]

✗ [davidjennes@Davids-MacBook-Pro ~]$ defaults read /Library/Preferences/com.apple.TimeMachine AutoBackup 1 ✓ [davidjennes@Davids-MacBook-Pro ~]$ defaults write /Library/Preferences/com.apple.TimeMachine AutoBackup -bool false ✓ [davidjennes@Davids-MacBook-Pro ~]$ defaults read /Library/Preferences/com.apple.TimeMachine AutoBackup 0 ✓ [davidjennes@Davids-MacBook-Pro ~]$ ls -al /Library/Preferences | grep com.apple.TimeMachine -rw-r--r-- 1 davidjennes wheel 1.2K Sep 1 13:38 com.apple.TimeMachine.plist -rwxr-xr-x 1 root wheel 0B Jul 22 02:41 com.apple.TimeMachine.plist.lockfile

dunno if I should own that file, but it's definitely not the only one in that dir that I own...

[dustinrue]

On the three Mac's I have in the house running Lion, all of them have com.apple.TimeMachine.plist owned by root. I suspect if you did a repair perms on your machine it would get reowned properly.

Dustin
On Sep 1, 2011, at 6:40 AM, djbe wrote:

✗ [davidjennes@Davids-MacBook-Pro ~]$ defaults read /Library/Preferences/com.apple.TimeMachine AutoBackup 1 ✓ [davidjennes@Davids-MacBook-Pro ~]$ defaults write /Library/Preferences/com.apple.TimeMachine AutoBackup -bool false ✓ [davidjennes@Davids-MacBook-Pro ~]$ defaults read /Library/Preferences/com.apple.TimeMachine AutoBackup 0 ✓ [davidjennes@Davids-MacBook-Pro ~]$ ls -al /Library/Preferences | grep com.apple.TimeMachine -rw-r--r-- 1 davidjennes wheel 1.2K Sep 1 13:38 com.apple.TimeMachine.plist -rwxr-xr-x 1 root wheel 0B Jul 22 02:41 com.apple.TimeMachine.plist.lockfile

dunno if I should own that file, but it's definitely not the only one in that dir that I own...

Reply to this email directly or view it on GitHub:
#3 (comment)

[dustinrue]

SideKick does absolutely nothing on my laptop. Need to try it on a different one…

Dustin
On Sep 1, 2011, at 6:37 AM, djbe wrote:

NetworkLocation can do it (now called SideKick) without root privileges.

Reply to this email directly or view it on GitHub:
#3 (comment)

[djbe]

Just did a repair, no changes... But this method won't work anyway if this isn't consistent on all macs.

[dustinrue]

Still interesting that your prefs files are owned by you. I know installed Apps will get owned by you but that's understandable.

On Sep 1, 2011, at 6:54 AM, djbe wrote:

Just did a repair, no changes... But this method won't work anyway if this isn't consistent on all macs.

Reply to this email directly or view it on GitHub:
#3 (comment)

[djbe]

Well a (kind of) solution until we find a better one is the following:

• when creating an action, check if the plist is writable.
• if not, elevate to admin rights for just a short while (password prompt)
• change the rights for the plist file so that we can write to it
• now whenever the action is triggered we can simply use the defaults write method

[dustinrue]

Too hooky, if people want to do this that bad they can change their sudoers file to not require a password for sudo stuff and write a script.

Dustin
On Sep 1, 2011, at 10:16 AM, djbe wrote:

Well a (kind of) solution until we find a better one is the following:

• when creating an action, check if the plist is writable.
• if not, elevate to admin rights for just a short while (password prompt)
• change the rights for the plist file so that we can write to it
• now whenever the action is triggered we can simply use the defaults write method

Reply to this email directly or view it on GitHub:
#3 (comment)

[djbe]

I analyzed the SideKick binary (and its plugin) and it does use the defaults write method (it's in the CoreActions plugin binary). Only I assume this plugin is run with elevated rights (there are references to AuthorizationCreate and such in SideKick), but I don't see a password prompt when running the app...

Edit: checked, and no, there's no helper tool installed for it

[djbe]

The helper tool has been implemented.