Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: some configurations don't stick between logins #35

Open
kristovatlas opened this issue May 24, 2016 · 4 comments
Open

Bug: some configurations don't stick between logins #35

kristovatlas opened this issue May 24, 2016 · 4 comments

Comments

@kristovatlas
Copy link
Owner

kristovatlas commented May 24, 2016

I think #29 broke some config fixes; By not running as sudo by default, we temporarily change the defaults value but it doesn't persist.

I've noticed this with the application firewall and stealth mode.

@kristovatlas
Copy link
Owner Author

kristovatlas commented May 24, 2016

The most sensible solution perhaps is to do the following:

  • Allow for configs in the HJson file to omit fix and only supply sudo_fix OR to specify a version of the fix that only applies to the current user. For example, I bet it will stick if we write to ~/Library/... rather than /Library/... without sudo. These config objects would include a sudo_fix and a current_user_fix as a fallback to the sudo_fix failing due to lack of sudoers privs.
  • Note these standards at the top of the HJson in comments.

As I'm considering additional kinds of fixes, it might make sense to turn this into a fixes array with various kinds and allow the HJson author to specify the order in which he wants them attempted, perhaps with individual test conditions.

@kristovatlas
Copy link
Owner Author

After some experimentation, I don't think the problem is whether the configuration fix command is run as sudo; it seems that some configuration states are overwritten by the operating system when written to /Library/Preferences/ rather than ~/Library/Preferences/. Probably the safest thing to do for now is to double up on the commands for which this is observed, and consider phasing out the /Library/Preferences/ version of the command eventually if it proves useless.

This emphasizes the importance of running the app one per user.

kristovatlas added a commit that referenced this issue May 30, 2016
This partially satisfies the bug referenced in issue #35.
kristovatlas added a commit that referenced this issue May 31, 2016
the `/Library/Preferences` version of this command does not seem to
persist. Consider removing it with the others.
#35
@kristovatlas
Copy link
Owner Author

This doesn't seem to stick over time:

A password is required to wake the computer from sleep or screen saver (system-wide)

This is accomplished with the sudo defaults write /Library/Preferences/com.apple.screensaver askForPassword -bool true command.

@kristovatlas
Copy link
Owner Author

This command doesn't stick over time:
sudo defaults -currentHost write /Library/Preferences/com.apple.alf allowsignedenabled -bool false

But the current-user-only version does.
defaults -currentHost write ~/Library/Preferences/com.apple.alf allowsignedenabled -bool false

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant