We’ve had incredible feedback from the last two events and it was so much fun we’ve decided to do it again. Join us on June 5-6th in Vancouver, BC, Canada. Early bird tickets are on sale now.
As a conference we like to gather to discuss Open Source solutions to manage Macs in the enterprise and everywhere else. This year we focus on the new APFS filesystem and what that means for all of us. How do we manage macOS if it is becoming more closed and like iOS? They’ll be talks on what is MDM?, Is imaging dead?, managing Macs with various open source tools, and how to leverage the cloud.
Join us for the technical talks by speakers from Google, Facebook, Dropbox, Airbnb, Square, Uber and many more. Or hang out in the break room and the hallway track. You’ll meet the awesome community members that make up the MacDevOps family. We are all here to share what we know, and to learn from others.
Sometimes Autopkg gives an error that doesn’t make sense since you don’t have enough info. Like this one:
That’s no way to make friends. Nope.
If even I understood all that… which is saying a lot. It doesn’t tell us what to do, or where to go to fix it.
Git makes sense, but maybe not in the context of Autopkgr errors. It wants us to “Git add or rm” (remove) offending items, but what does it have to do with what we’re doing at this moment? Hmm. Ok, we know that autopkgr uses autopkg which uses git but that still leaves us in the dark about what’s going on.
Drop down in terminal and poke at autopkg. That always helps.
bash-3.2$ autopkg
Usage: autopkg <verb> <options>, where <verb> is one of the following:
help (Display this help)
info (Get info about configuration or a recipe)
install (Run one or more install recipes. Example: autopkg install Firefox -- equivalent to: autopkg run Firefox.install)
list-processors (List available core Processors)
list-recipes (List recipes available locally)
make-override (Make a recipe override)
processor-info (Get information about a specific processor)
repo-add (Add one or more recipe repo from a URL)
repo-delete (Delete a recipe repo)
repo-list (List installed recipe repos)
repo-update (Update one or more recipe repos)
run (Run one or more recipes)
search (Search for recipes on GitHub.)
version (Print the current version of autopkg)
autopkg <verb> --help for more help for that verb
Looking at all that we notice that “repo-update” is most likely the autopkg command that gets activated when Autopkgr gui “update repos now” button gets clicked.
Running autopkg with repo-update option gets us a better error message.
Attempting git pull for /Users/awesome/Library/AutoPkg/RecipeRepos/
com.github.autopkg.wardsparadox-recipes...
ERROR: Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>'
as appropriate to mark resolution and make a commit.
So, at least we know now what is causing that error that Autopkgr showed us. Quick fix:
And then we go on and pretend like nothing happened and continue on with our day, amirate? Maybe we go to the Mac Admins Slack autopkg channel and ask our colleagues, or post on the autopkg mail-list. Or we write a blog post.
I am about to send an email to a software vendor asking them to please consider shipping their apps in a deployable Apple PKG format and I wanted to ask if anyone has some boilerplate text, excellent blog entry or list of arguments I can use. I could have posted in the MacAdmins slack, tweeted or posted a lovely photo on Instagram, but instead I sent an email to the MacEnterprise mail list.
Hat tip to Rick Heil on the MacEnterprise for pointing me to this post on AFP548 by Gary Larizza in June 2010.
“This one is an oldie but a goodie. It hits all my pain points, such as not assuming GUI interaction and minimizing pre/post scripts.”
Do not assume that your package will be installed interactively via the GUI or on the currently booted volume.
Unnecessary actions are unnecessary.
Licensing should have the option to be managed by Systems Administrators.
Use pre/post-install scripts only when necessary
Be true to the Operating System
Naming Conventions are Necessary and Helpful
All software vendors should aspire to follow these rules.
We should always send feedback to software vendors explaining carefully why their Mac OS X installers are not optimal for deployment when they are custom apps (e.g. InstallAnywhere) and not in Apple package format (i.e. PKG). Also, if the installers (as well as the app) require the legacy Java 6 then this seems to be a security risk and it is our duty to provide feedback if we hope to improve the situation in the future.
Another great source of information is Der Flounder, Rich Trouton’s blog, is worth perusing because of Rich’s excellent documentation and many excellent posts, including this one about re-packaging app:
“Using AutoPkg to build installer packages from installer applications” from May 24, 2016.
As Rich succinctly puts it: “One of the challenges Mac admins have to deal with are Mac application installers which don’t follow one of the following models: Drag-and-drop installation or Package installation”.
Greg’s managingosx blog has many articles on packaging and I thank you for taking the time to write all those posts. We benefit greatly from all the work of everyone in this community. Greg has spoken at many conferences and given great packaging workshops.
Reference: packaging blog posts on Managing OSX
My personal preference for software deployment is to use Munki to deploy apps and not have to deploy app manually. While Mac sysadmins may use difference software for deployment, I think we are all in agreement in not wanting to do this manually when it can be automated. I don’t have a large IT team, and simple solutions based with Munki are best for me. Hence my desire for vendors to use the Apple PKG format where possible.
I’ve been a little busy lately. I’m working on some scripts for Watchman Monitoring that alert when Archiware P5 needs attention. It’s really much more exciting than it sounds. 🙂
UPDATE: The Archiware P5 plugin is now included with the Watchman Monitoring client version 6.6.0
Use the link above to read up about Watchman Monitoring and the Archiware P5 plugin.
This plugin is now part of Watchman Monitoring thanks to Allen and his team! Of course, big thanks to a lot of help from Python magician and MacDevOps:YVR colleague, Wade Robson. I couldn’t have finished this plugin without his help. Merci, mon ami. (Early help to get started with this project is thanks to Scott Neal, automation expert and programming wizard. Thank you so much Scott, and thanks for the tasty Portland beer!).
Watchman Monitoring is a group of plugins that will warn when drives are failing, computers have restarted unexpectedly or backups are not running. All reporting goes to a beautiful web interface in the cloud which can keep a history of plugin issues. Watchman allows for integration with ticket systems and multiple users including clients and IT staff that can keep track of what’s up with their workstations, and servers.
Watchman Monitoring helps me keep tabs of major issues at all my clients before they become disasters. I even use it in discovery for new clients to see what issues exist but are ignored or unknown.
Since I set up a lot of SAN storage for my clients, and I use Archiware P5 for backups and archives I realized I needed to write a plugin for Watchman Monitoring that alerts me to issues. Instead of remoting in with VPN to each and every client every day to check on backups the only alternative is to automate it. These scripts watch the LTO tape drives and emails when they need cleaning, or warns when running jobs need tapes, if workstations haven’t backed up in a while or if tape pools need more tapes. And in Beta 2 we’ve added a check to see if the P5 maintenance support needs to be renewed to give you time to renew it before it expires. As well as better alerts for issues with running jobs, and lots of bug fixes.
We have it working on Mac servers running Archiware P5 and the next step is Linux, and the Unix family. Later on, Watchman will port it to Windows. The scripts are written in Python which is great for portability (except to Windows. Ha ha). And the P5 Watchman plugins should eventually run everywhere that Archiware P5 runs (OS X, Linux, FreeBSD, Solaris and Windows).
The best part of writing plugins for Watchman Monitoring is the great help that Allen and the whole team at Watchman have given us been throughout our development of these Archiware P5 plugins. And of course everyone at Archiware and Mike at PVT have been super helpful in explaining the use of the nsdchat cli for Archiware P5, even going so far as to add some features we needed to nsdchat when we explained how useful they’d be for this project. Mille mercis. Vielen danke.
Using GitHub to check code in, document business logic, write code, build a wiki and then track issues that need bug fixes or enhancement requests has been an adventure. It all starts with an problem that you want to be alerted for. It’s easy enough to add custom plugins to Watchman Monitoring you just need some ideas, a programmer (or two) and some time for testing, debugging, more testing and time. Did I mention you need lots of time? Ha ha
And now for a sneak peak of the Archiware P5 beta 2 plugins for Watchman Monitoring.
Watchman nicely lists the new warnings and expirations for quickly getting to the issues you need to see.
Expirations are tracked with Watchman. In this case we note the date when the maintenance for Archiware P5 needs to be renewed. Don’t want to miss that!
Server info is good to know. Uptime, port used, and what exactly is licensed.
The LTO tape drive is the heart of any tape library, and alerting when it needs cleaning is very important.
Other plugins watch the tape pools, running and completed jobs, as well as Backup2Go (workstation backup).
Big thanks to Ross at Ping Identity for organizing and Jamf for sponsoring the Mac Admin meetup on September 9, 2015.
We filled the tiny meeting room and we will have to expand to the larger conference room (or theatre) next time. It was a well attended meetup with much discussion of the earlier day’s Apple announcements, new OS X “El Capitan” and iOS 9 changes and how this affects management products like Casper which have had to move the binary because of the new SIP implementation in OS X.
The goal of my presentation was to give a quick overview of SAN technology as I’ve seen it change over the last 10 years: from Fibre Channel, to iSCSI to PCIe and Thunderbolt based. The last change to Thunderbolt based SANs is the most interesting for small video production workgroups or anyone that likes working on small scale shared projects but needs a decent bandwidth at an affordable price. Block level storage (SANs) is straight forward storage tech for users and applications to interact with without having to negotiate network protocols (AFP, SMB, or NFS). It’s never been quite that affordable until now.
Having built a lot of Fibre Channel based SANs for media and entertainment companies and post-production editors in corporate environments I know how awesome and fast and solid these SANs are. Lots of editors and clients can hit a large SAN and it won’t blink. Thirty or Sixty users is not unusual. But not everyone believes in fibre channel or the idea of pulling fibre cables. It is surprisingly a large stumbling block to building large SANs, “no, we don’t want fiber cables”. True, sometimes clients have objected to gigabit Ethernet too, but that’s another story.
I found that iSCSI, especially with the DDP units I’ve set up, has been a great alternative to fibre channel. Not fiber cables to pull. Just use the CAT6 cables already in place. Great Ethernet based SANs using 1 x or 2 x CAT6 cables per client, or even 10G. Works well. Very well indeed. It’s been great for smaller (and larger) clients who want a great Ethernet iSCSI SAN solution without needing fibre channel cables, switches, HBAs, Thunderbolt adapters, etc.
That’s why when I stumbled across the Accusys Thunderbolt storage I was kinda really excited. No fibre channel to Thunderbolt adapters. Just use Thunderbolt cables. Brilliant! Finally a solution for small workgroups. And there’s so many video groups sprouting out of every corporate office, or boutique VFX or post-production shops that have been struggling with small NAS solutions that were not meant for video production. Now you can get that SAN that you’ve wanted, you can really get that block-level storage at an affordable price. Instead of working locally and copying raw footage and finished products back and forth across slow network links they can work in a small video group with high speed storage. Sa-weet. (Can you tell I’m excited?).
I’ll include the presentation PDF here as a link if anyone is interested. I’ve added a link at the end from Accusys on how to build an Xsan with the A16T2-Share. Yes, Xsan from Apple still exists and is bundled with the OS for free. Building a SAN is pretty easy and everyone can do it. Don’t forget your backups though.
Lastly, anyone interested in attending any meetings for the upcoming MacDevOps:YVR (June 16-17, 2016) drop me a note. I added the email in the presentation document.
With all this talk about El Capitan, Apple’s as of yet unreleased version 10.11 of OS X, and its wondrous new features in Xsan, I think it might be time to upgrade to last year’s breakthrough version of OS X, Yosemite. Sure, you might be excited by the press releases for the built-in DLC in El Capitan but seriously sane folks stay 1-year behind the bleeding nose upgrades provided by Apple. So if OS X 10.11 is all the rage before its released it must be time to seriously consider upgrading that working Xsan running OS X 10.8 or OS X 10.9.
In my case, I upgraded a working Xsan running on Mac Minis and OS X 10.8.5. Here are some screenshots from the process. As always think worked better than I could have expected, and it is a much easier process that one expects. But stay sharp kids, danger lurks when you wake the dreamer…. Upgrading a SAN is serious business and doing anything like this without proper backups is taking your life in your own hands. In my case, full disk backups on Promise Pegasus RAIDs and full tape backups using Archiware P5.
Download the Yosemite installer form the App Store. Install. Download the new Server.app from the App Store. Install. Now upgrade your Xsan. That’s it. You’re done. No surprises, aren’t you happy? Ha ha. I’m kidding. The fun is just getting started.
If you’re actually following along, this isn’t a step by step recipe. Go to Apple’s site and read this Kbase and check out the migration guide.
Restore Xsan
Step 1 is to launch the new Server.app, find Xsan Admin. Just kidding, it isn’t there. Enable Xsan, and choose to Restore a previous SAN configuration. That wasn’t hard. High five! Actually, we’re not done yet. Set up OD now. Go!
Step 2. Set up your Xsan controller as an Open Directory (OD) master. Does’t matter if it’s joined to another domain, Xsan keeps itself organized in OD, so you need it.
Set up OD
Step 3. Admire your upgraded SAN, “how lovely the flowers do smell…. life is good.”
Xsan list
Step 4. Where did my Xsan admin go? Where do I add clients? Where are my clients? Huh? What? Why did I upgrade a perfectly working SAN to this version? Ha ha.
Take it all in, take a good look at what you’ve done to your Xsan. What? Just so the editors could have the latest version of Final Cut Pro (v.10.2.1) which is only compatible with OS X 10.10.4. I see what you’ve done Apple, very clever indeed. Hmm…
Click on the “Save configuration profile” button and download the profile somewhere. Use this to set up the SAN on your clients. Distribute via Profile Manager or install it manually. Up to you. I haven’t gotten it to work with Munki quite yet. Installing it requires the admin password for the Xsan controller. How convenient.
When you client is configured you’ll see a Profile in System Preferences. Remove it and your client is un-configured. No more Xsan.prefpane to list volumes and mount or unmount them. Nope. That would be too easy. Learn to love “xsanctl”, as in “xsanctl mount Xsan”. Read some xsanctl tips in this Kbase
Step 5. Set up a backup Xsan controller. You have one of those, right? In my case, I had a client which I wanted to promote to be a controller. But first what to do about its status a client of the Xsan?
backup cannot be client
Open Server.app, enable Xsan, join current Xsan as a backup controller and set up a replica OD. Confirm, confirm, confirm. Think about what you’re doing, then do it!
confirm
Apple wizards are the best wizards, uh, i mean Setup Assistants. No wizards here…. So, you’ve setup a backup Xsan controller, and OD replica, and now look in Server.app. How amazing is that… wait, what? Where’d my Xsan volumes go? Huh? Where are the controllers? Weird. Very strange. Not comforting at all.
The Xsan window eventually shows the volumes and controllers, bur geez, almost gave me a heart attack. It’s not like I never seen Xsan go bad before. Xsan 1 nightmare still haunt me. They do. Backups. Need more backups. Archiware P5 Backups, do it now!
OK, you’ve survived the uncertainty of Xsan upgrades…. But wait more minute… cat the fsnameservers (no, it’s not the name of a band, it’s a command). Check it out. Holy smokes, batman. Xsan 4 by default will set your metatadata network to the public LAN, something that’d would be laughed at years ago, but they do it now by default. Of course, upgrading our SAN kept out metadata network the same. But strangely the Xsan backup controller is set to use the public for metadata when the primary controller is not. WTF.
Yes, Apple has restored the ability to set a user and system umask in OS X 10.10.3. This is a huge fix for users of shared storage. Xsan and all SANs where users want to be able to share files, projects and all things without using ACLs or any LDAP directory. This is great. I am jumping up and down. So happy. So many people wanted this. Anyone using shared storage have been demanding this since the upgrade to Yosemite. 10.10.3 is out today and we will be happy.
