

Osxc – Simple configuration tool for OS X - robinricard
http://osxc.github.io/

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

[https://github.com/32degrees/battleschool](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](https://github.com/autopkg/autopkg)
[http://code.google.com/p/munki/](http://code.google.com/p/munki/)

~~~
robinricard
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 !

------
taylorlapeyre
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...](https://github.com/taylorlapeyre/.files/blob/master/osx/bootstrap.sh)

~~~
ot
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.

~~~
taylorlapeyre
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."

~~~
lobster_johnson
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.

------
jimmcslim
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.

~~~
sacrilicious
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...](https://github.com/autopkg/nmcspadden-
recipes/tree/master/AppStoreApp) 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.

------
weitzj
I am using Github's Boxen, which works quite well
[https://boxen.github.com/](https://boxen.github.com/)

~~~
robinricard
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 !)

~~~
hedwall
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?

------
rafeed
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.

~~~
xbryanx
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...](http://docs.puppetlabs.com/references/latest/type.html#package-
provider-appdmg)

~~~
rafeed
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.

------
robinricard
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).

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

~~~
kolev
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.

~~~
phinze
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.

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

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

------
mukundmr
How is this different from Chef / Puppet?

------
runjake
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.

~~~
robinricard
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 !

