Osxc – Simple configuration tool for OS X | Hacker News Reader

Osxc – Simple configuration tool for OS X

osxc.github.io

110 pointsrobinricard44 comments

Another project that uses the same tools (Ansible/Homebrew) to accomplish the same/similar goals:

https://github.com/32degrees/battleschool

If you're going to do this on a wider scale (multiple machines, managed in an organization), the best tools right now are AutoPKG and Munki:

https://github.com/autopkg/autopkg http://code.google.com/p/munki/

I looked into battleschool. The way it overally works seems better (having it's own command and a simple config with just a dotfile) but I really like ansible roles and I really enjoy using brew and brew cask to install everything, it's more neat and more undoable than using a pkg command directly. For now, I don't know which design I'll choose but I still like using the ansible-playbook command. I don't want to hide the internal mechanics of my tool. Ansible is great ! I still want to use it !

thanks ! That's exactly what I was looking for when I started to create osxc ! I will look into it. In fact osxc should more be seen as a set of roles than anything else, so I think it can be easily plugged with an existing solution such as battleschool.

I'm struggling to see how this is better than a simple bootstrapping script. Every feature you list can be accomplished in very few lines of bash:

https://github.com/taylorlapeyre/.files/blob/master/osx/boot...

The main difference between shell scripts and Ansible playbooks is that shell scripts are imperative, while playbooks are declarative and idempotent.

A shell script will be something like

    install this package
    create this file
    change this line in a configuration file

While a playbook is like

    make sure this package is installed
    make sure this file exists
    make sure this line is like this in this config file

What happens if you want change something in your configuration script? In most cases you can't just replay a shell script, because it will try to do a lot of things that are already done and it is very hard to write idempotent commands.

Ansible on the other hand only performs the tasks in the playbook that need to be performed: if the condition is already satisfied, there's nothing to do.

This is especially convenient if your script fails at some point: you can fix the directive and replay the playbook, and it will restart from where it left off. With shell scripts you have to do it manually (comment out the first part?), which is error-prone and time-consuming.

I can appreciate this explanation, thanks.

I will, however, offer that a well-designed shell script should be able to be run many times in a row without causing any problems. The above script is an example of this.

If I wanted to change something in my configuration script, that's totally fine! In fact, I do change it all the time. Since all it does is ask you whether you want homebrew to install something, there is very little risk (if any) of something "going wrong."

To do the same thing using pure shell scripting, you have to write a large number of helper functions to avoid boilerplate. Things like asserting — in an idempotent way — the existence of files (with the right content, the right ownership and mode flags, etc.), services, packages and so on.

Tools like Ansible and Puppet already provide that set of functionality. If you write it yourself, you pretty much end up with something like Ansible, except it's specific only to your use case. Better to focus on commonality.

I'm a Puppet guy myself (although I appreciate the simplicity Ansible can bring to the table), and make extensive use not just of the primitives, but of the ability to bundle primitives as reusable modules. For example, rather than explicitly putting files in /etc/logrotate.d, I define a "logrotate class" and do:

    logrotate::rotation {
      postgresql:
        pattern => "/var/log/postgresql/*.log",
        keep_count => 10,
        require => Package['postgresql'];
    }

However, this is not merely a macro that is expanded in-place. Rather, it's an object which can be referenced (for example, I can have something else which requires that the object Logrotate::Rotation[postgresql] runs first) as well as "inventoried" (I can ask the system about all the log rotations that have been declared, and use that to drive a UI, for example).

The expressiveness and flexibility of tools like Ansible (which must have something similar) and Puppet is best seen in a multi-node server environment, however.

couldn't explain it better !

I understand what you're saying. I just started this a few days ago and wanted to share it with the community. For now, this is more: how I setup my computer than how everyone should do it. But I found that even if a simple bash script would do the same, the ansible roles gives me the possibility to have reusable components. (my boot.sh is terrible, I know, I have to find something else ...)

Understandable. Cheers!

Standalone, it's 6 o' one, half-dozen of another.

We use ansible for configuring servers. Using this to configure our machines would be cake.

because writing yaml is way easier than writing a bash script.

This yaml approach requires me to know a lot more about existing software than the bash script does. I will need to:

- Read up on the documentation for osxc or battle school

- Look at other configuration files to get a feel for what mine needs to look like.

- Learn about the differences between playbooks or recepies or what have you.

- Download some proprietary software that I will likely never use again.

This is all mental overhead to me.

In comparison, how do you create your own bash script? You already know how to do most of it. If not, just look at the script above. It doesn't require a genius to understand a simple bash function. This approach will take you at most, 5 minutes.

Or maybe I'm just not seeing some huge advantage of these large boxen-esque frameworks for installing some programs.

I tried to learn Puppet in combination with Vagrant for provision rather simple severs, and that was too hard (I had things to do). I then tried to learn Ansible, but didn't get very far. I ended up giving up and writing a shell script that has some simple reusable functions ("is this package installed, if not install it", "does this exact file exist, if not copy it over", etc)

I would rather use Ansible. It seemed like it would fit what I'm trying to do, but everything I can find seems geared towards multiple servers, rather than provisioning a VM and/or an AWS instance identically.

Anyone got some good resources for it?

I think you've hit the nail right on the head. The added complexity of these tools, created ostensibly to simplify configuration, simply cannot accomplish what they set out to do by trading in one language for another.

The way my brain works, I’d rather update yaml files than debugging shell script. And because I obsess over this stuff anyway, osxc looks quite appealing.

One blind spot that all of these OS X configuration tools appear to have is the App Store. Not through any fault of their own I suspect... more that Apple hasn't opened the App Store app to being scriptable. But a command-line way of installing/reinstalling/updating App Store apps would be great.

The zdw-mentioned autopkg has the capability of looking at your installed AppStore apps and checking for updates, and further can package them(with embedded receipt/DRM) to a patch mgmt system. https://github.com/autopkg/nmcspadden-recipes/tree/master/Ap... It works with any pkg deployment system, although autopkg itself ships with Munki support. Ansible and osxc by extension are about ConfigMgmt, of course, but conflating mgmt systems is common and understandable.

I am using Github's Boxen, which works quite well https://boxen.github.com/

boxen looked nice to me, but I really wanted to avoid puppet (even if I never tried, it's often compared to chef and I have lots of bad experiences with chef !)

I've used Puppet extensively for server management (and also done some Chef, and currently som Saltstack.)

Although they are both configuration management tools, they are different.

What kind of issues did you have with chef? And when?

This is neat. I think it'd be pretty awesome if it were possible to download all the dmg's/installers/apps in a folder/drive without installing them so at a later date you could a) install everything without having to wait hours to download or require an internet connection and b) keep your packages up to date (almost as a backup) running the script every once in a while to make sure you have the most up to date packages/installers.

Puppet (and Boxen for help on OSX) can do this for you with appdmg package provider: http://docs.puppetlabs.com/references/latest/type.html#packa...

Nice. I'd love to see templates so you can easily customize depending on what kind of environment you want so you can start from zero. E.g. 1. Development 2. Design 3. Engineering 4. Management 5. General use

It's probably just me, but it seems like all of these require too much investment time before you have something usable for future use (replicating your current environment).

Which brings me to this, how about a script that analyzes what you already have installed and creates this set up for you which you can customize to easily add/remove packages/apps/installers using Boxen and similar? Anyone know of such tools? My MBP is full of crud after using SuperDuper!/Time Machine for several years to start new macbook setups and installing new versions of OS X on top of the old OS.

I think the project is not largely usable for now, I just want some feedback from HN to get it usable for everyone (and not just for me).

For some reason I'd never seen Homebrew Cask before, which looks very interesting! Does anyone have experiences with Cask to share?

Homebrew Cask is awesome!

A couple of weeks ago I decided to backup my hard drive, reformat it and reinstall OS X Mavericks to get rid of the cruft that seems to have built up in 4 years, updating from every OS since Mac OS X 10.5 Leopard.

I made halfhearted attempts to organize my dotfiles and configuration in the past, like the cool kids do on Github. That’s when I learned about Homebrew Cask (http://caskroom.io) which makes it super easy to install the GUI apps I install on whatever Mac I’m using—iTerm, Transmission, Vagrant, Virtual Box, etc.

And now I have them in a Brewfile (http://robots.thoughtbot.com/brewfile-a-gemfile-but-for-home...) under version control in case I need to install the whole shebang on another Mac.

And now brew update && brew upgrade updates everything.

I'm hoping someone could answer this for me. How do you trust the applications that `brew cask` installs?

What is preventing `brew cask install firefox` from installing something malicious? When I download an application manually, I trust the site I'm on by virtue of being there and being savvy enough to know it's a legitimate site. But when you script it, you lose the ability to gauge see for yourself what you're downloading.

I realize I could probably do: `brew cask info firefox`, find the ruby file it points to (https://github.com/caskroom/homebrew-cask/commits/master/Cas...), open that up, verify the link is trustworthy.. but I don't want to do that for every installation. And if it's valid now, what's to prevent it from changing in the future?

How do you guys justify using cask?

Hey there! This is a valid concern, but I don't think it's all that different from using Homebrew. The community maintains the cask definitions, and all pull requests are reviewed via the project team. There's a checksum verification feature built in, though we're still figuring out how to reconcile that with un-versioned download URLs [1].

At the end of the day, when you use any package management software, you are implicitly trusting the team that maintains said software. Perhaps it would be better for us to do our best to force users to make that trust more explicit? It's an interesting question - any suggestions you have would be more than welcome - feel free to open an issue to discuss! :)

[1] https://github.com/caskroom/homebrew-cask/issues/1021

Cask could be awesome, but it's not at this stage. There are no upgrades, in many cases it doesn't work. Most apps complain that they are not in /Applications, but are in ~/Applications instead and so on. At the end of the day, it duplicates some of the Homebrew functionality - some non-GUI packages are getting into Cask, because possibly Homebrew doesn't want them - it's a bit confusing as well. I think efforts should be put into merging into Homebrew instead of keeping it separate.

Hiya - author here. Thanks for the feedback on this stuff! It's always good to hear where it's best to focus improvements.

I'm going to address a few of your points specifically.

> There are no upgrades, in many cases it doesn't work.

It's true that `brew cask upgrade` is not yet a thing. I would very much like it to be. I've been sort of avoiding work on the feature for fear of messing it up. But that's no reason to not try to make something work! :) Maybe I'll use this as an occasion to start digging in and getting my hands dirty.

> At the end of the day, it duplicates some of the Homebrew functionality - some non-GUI packages are getting into Cask, because possibly Homebrew doesn't want them - it's a bit confusing as well.

If the purpose of the project is not clear, that's definitely a problem. I'm not aware of many (any?) purely non-gui apps making it in to Cask. The `Homebrew/homebrew-binary` tap is the place for those. I'll go review our included Casks to make sure things are clear.

> I think efforts should be put into merging into Homebrew instead of keeping it separate.

I can understand this opinion, but I think we may actually end up going in the other direction. The places we share code with Homebrew have been the biggest problem areas for us. We are already 90% code independent from Homebrew, and I think moving Cask to its own world may benefit both the project and the users. But of course that's a conversation to have with the (amazing!) project team.

Is there anything Homebrew can do differently to make things easier for your project?

Just saw at least one duplicate - OSXFUSE.

Huh… I’ve installed 17 Casks; no apps have complained about being in ~/Applications. In fact, for properly written apps, it should not matter, so there may be something else going on.

I’ve been using ~/Applications forever for beta testing and accessing two different versions of the same app.

That's true. I hope more apps improve as well as OS X itself. The issue with ~/Application seems to be OS X-related as reported by HyperSwitch (http://bahoom.com/hyperswitch/), which cannot run in background without being under /Applications.

So that’s a HyperSwitch issue that doesn’t have anything to do the operating system itself. Properly written apps (and that probably means not using undocumented APIs or doing otherwise unsupported things) don’t care about being in ~/Applications.

You can override the application directory for Cask:

    export HOMEBREW_CASK_OPTS="--appdir=/Applications"

I know about this, but I would want only the problematic apps to auto select /Application - some work fine in ~/Applications, i.e. the Cask formula can override the appdir default value.

we use Ansible across 300 hosts, including some Mac guests. Well-tested playbooks for Mac are hard to find, so this is awesome.

How is this different from Chef / Puppet?

The osxc website and documentation is riddled with basic grammar and spelling errors and incorporates slang like "osxc got your back". That doesn't inspire much confidence.

Edit: Wow with the downvotes. I'm just offering feedback in a polite manner for what a lot of others are probably thinking.

I know, my english is not very accurate (I'm french). Feel free to do some pull-requests to correct my grammar errors, it'll help me a lot ! Both for this website and my english. Thank you !

Note that you shouldn't be confident using it too, it's still a very early project and, at the beginning, it was only meant to be used by me ... But I intend to make it much better !

Just because this is a software not an English book.

You were probably downvoted because your feedback was not given in a polite manner.

Reply on news.ycombinator.com