We'll respond shortly.
A common question for operations when considering running a platform for the first time is, what do you do to the platform when you are running all your apps on it? Be it for patches, upgrades, routine maintenance, or the ever-present security upgrades—how do you do this easily and without downtime? In this podcast, host Simon Elisha explains how Pivotal Cloud Foundry handles most of the heavy lifting for its users.
On occasion a non-employee will need to connect their laptop to our ethernet network, which begs the question, "How do we allow customers to access our network while protecting our workstations?"
We are a Software Services company, and at any given moment 40% of the 200-odd people in our San Francisco office are not employees. Of those 80 people, 98% of them can access the guest WiFi network without a problem. There are, however, the remaining 2% who, for whatever reason (their WiFi chipset doesn't interoperate well with our WiFi Access Points, their wireless is broken, they've accidentally deleted their drivers, etc...) cannot connect to the WiFi. They need to access the Internet, and they can only use ethernet.
We want to give our guests ethernet connectivity when needed, but not in such a way that it jeopardizes the security of our workstations.
Apple uses its App Store as a mechanism to distribute software, and it works quite well when a human operator is available to interact with it.
Unfortunately, many configuration management tools (e.g. chef, puppet) can't interact with the App Store, but they can interact with MAC OS X installer packages (.pkg, .mpkg files). We'll show you how to extract the underlying installer package file from the App Store.
This was tested under OS X 10.8.1 installing the OS X server package. It may not work for other packages.
You've lost your Open Directory server database. You need to recover it, but you don't have an Open Directory Archive, and you don't have a replica that you can promote. And you don't want to restore the entire server, either.
This blog post covers how to restore an Open Directory database from backup.
This blog post is directed towards system administrators
This procedure worked for us; it may not work for you. YMMV. There is no warranty, express or implied. This is by no means an Apple-approved procedure.
When we moved to a new office, we faced a problem: how do we give printer access to everyone even though we had segregated machines to different networks? And how do we make it transparent to the user?
The solution we found was to add a new VLAN (i.e. network segment) for the printers (and other common resources, e.g. license servers), and use DNS Service Discovery (dns-sd) and a handful of crafted records to our DNS server.
This blog post is directed at Operations staff at companies which have the following characteristics:
The short version: people couldn't print from the WiFi network.
So you have a nice new Apple machine running Lion, but you don't want to spend the next few hours installing software.
The short answer: use chef/soloist in conjunction with a slew of recipes developed at Pivotal Labs to help install the most common set of components.
Here's what to do:
Do the following:
sudo gem install soloist mkdir -p ~/workspace cd ~/workspace git clone https://github.com/pivotal/pivotal_workstation.git cat > ~/soloistrc <<EOF cookbook_paths: - $HOME/workspace recipes: - pivotal_workstation::meta_osx_base - pivotal_workstation::meta_osx_development - pivotal_workstation::meta_ruby_development EOF soloist
It typically takes an hour for the chef run to complete. You can do other things while it's running (but if you reboot or logout you'll need to restart the chef run).
[Chef is a framework written by OpsCode to help configure in maintain one or more machines using 'recipes' (ruby scripts, more or less).]
[Soloist is an application which makes running chef-solo (the version of chef which runs without any centralized server) easier. It was written by my co-worker Matthew Kocher.]
At the end of the chef run [as of this writing, and if all goes well] the following software will be installed:
The following services will be enabled:
The following preferences will be set:
Want to change the software that is installed? It's simple: just change your ~/soloistrc file. Here's a soloistrc that will only install TextMate & node.js:
cookbook_paths: - ./workspace recipes: - pivotal_workstation::textmate - pivotal_workstation::node_js
If you're interested in seeing all the recipes available (and there are quite a few), just browse the recipes in the pivotal_workstation repo.
Early in June, several pivots (Sean Beckett, Matthew Kocher, and David Goudreau, and I) met to decide on the bare minimum set of software and features that our developers would need to function on a new Lion Machine.
This set of chef recipes is the result of that meeting. There have been some changes (we have had great difficulty writing recipes to install firefox addons, so we iceboxed the story; some of our developers contributed recipes for things they wanted, so we added those).
We chose chef/soloist partly because felt that our previous process had reached the end of its usefulness and were familiar with chef from our work automating server configuration.
Here's how our previous process worked:
This approach had several shortcomings:
We looked for alternatives. We wanted the following features:
Integration tests for the cookbook took several days to set up. We use Faronic's Deep Freeze on a fairly pristine mac mini to ensure that we have a clean machine when we run our chef scripts. Continuous integration has proven invaluable for collaboration, for we quickly learn if a commit has unintended consequences.
In the more complex chef recipes, we attempt to write tests to test that they [the recipes] have succeeded; sshd_on.rb is a good example of testing that a service (sshd) was correctly started.
The chef runs, especially the initial one, are flaky. Our current chef run must download software from over 40 different servers, any one of which being down or having changed the download location can cause a failure. For example, Little CMS, a dependency of ImageMagick, resided on littlecms.com, which was down for a few days. Our integration tests failed during that period.
If you encounter a server being down or a file that has moved, please send us a pull request with an updated download location, or just comment-out the broken recipe.
Our target audience is developers, which is great: they understand errors, and often contribute code fixes. Our goal is for Pivotal Ops to provide a framework for Pivotal Engineers to write the recipes that build the workstations they want.
I am grateful to Matthew Kocher, who more than anyone helped me write the bulk of the ruby scripts. Also to Sean Beckett, without whose support this would never have happened. And to the many pivots who offered suggestions & help.