I’ve mentioned the Accusys A16T2-Share Thunderbolt SAN storage before. I first encountered it at NAB 2015 back in April. It was truly a magical find. A 16-drive RAID unit with 64TB raw storage and ready to be part of your Apple Xsan using Thunderbolt connectors. No Thunderbolt to fibre channel adapters necessary, nor is a fibre channel switch required. Just plugin a Mac Mini as your Xsan controller, and there’s room for 3 other clients to plugin with Thunderbolt. Pretty neat.
It’s not for everyone. There’s a limit to the length of Thunderbolt optical cables. And there’s only 3 clients possible using one last Thunderbolt connection for an Xsan controller. But this could work well for small work groups. The magical 4-seat SAN setup is finally here. Bob Kite, master SAN builder, would be happy.
I’ve just gotten word that this unit is available for sale now, as it was recently certified by both Apple and Intel. I believe the street price is approximately $9900 USD, but don’t quote me on that. Information is still emerging on this new product. I do hope to get my hands on one to do some real world application testing. Including testing resilience to failure (drive removals, raid rebuilds, etc).
If the reliability of the Accusys hardware is good, and backed up with solid support then this could be a great product.
Of course, it kinda goes without saying that all storage, including Shared SAN storage, needs solid backups. My preference where possible is a second tier disk (NAS/SAN/DAS) and tape. My preferred vendor is Archiware which makes the very excellent product P5.
With over 10 years of experience with Xsan and setting up storage systems I have learned to always setup excellent backups. Restoring files when a RAID or SAN fails is crucial. Using an a RAID, such as the Accusys Thunderbolt A16T2-Share, as a SAN would be come with a recommendation from me to all my clients to have a secondary Thunderbolt RAID unit of the same size to sync it daily and to use P5 Backup with LTO 6 tape drives (preferably in a tape library). You never can be too paranoid with a client’s data. That’s what my clients pay me for. To plan for failure. I love setting them with excellent SAN storage, but I must counsel them to build also an excellent backups system. Better safe than sorry.
The price point on this A16T2-Share Thunderbolt RAID is attractive, and when it is released many clients in small shops may very well consider it. At approximately $10K US for 64TB of shared storage with free Xsan 4 it is a pretty sweet deal. Add another $5-10K for a large backup RAID drive, and another $5K for a tape library and $2K for Archiware P5 Backup and the cost adds up. But having an affordable price for the main SAN storage makes this a very real possibility for some clients who have been struggling with editing video on NAS like QNAP, Synology or Drobo.
As posted on the munki-dev list by Greg Neagle and posted https://github.com/munki/munki/wiki/Discussion-Group, a list of discussion groups related to Munki:
I’ve been asked about Mac IT sysadmin training ideas, and I thought perhaps sharing some initial ideas might help other aspiring Mac IT sysadmins.
It’s hard to recommend a training site or specific place for Mac IT training these days. It used to be that you could sign up for a Unix SysAdmin or bash scripting class and that would be most helpful. And those both are helpful but Mac IT specific technologies are discussed at Mac IT conferences such as MacTech in LA (and periodically in other cities), PSU Mac Admins (Penn State), MacIT (San Jose), MacSysAdmin in Sweden, MacDeploy in Calgary and MacDevOps:YVR in Vancouver. As well as Apple sponsored camps for ACNs (Apple Consultants). Some of these conferences post their video online for free (PSU, MacSysAdmin and MacDevOps) so these are great resources to learn from.
The most important is local meetups, and right now we’re not hosting anything in Vancouver. But I do want to start some local meetups here to encourage fellow Mac Admins to help each other out learning MacDevOps skills and getting into the greater Mac IT sysadmin community. There are great meetups in many cities across North America and the world. Finding out where they are means looking at afp548.com for info, or check out Watchman Monitoring’s new Mac Meetup site: http://www.macmeetups.com/find/, or check on Jamf Nation (https://jamfnation.jamfsoftware.com/index.html). Lots of options.
Here in Vancouver we are also contemplating some more in depth workshops for the next MacDevOps:YVR conference and perhaps sooner than that. How to get started with Mac IT technologies and how to build a beautiful Mac Admins community by being a part of it, and sharing what you know with others.
Anything you all want to learn specifically? What do you want to know about? Let me know.
I saw something wonderful and new at NAB today. The Accusys ExaSAN Thunderbolt shared storage shouldn’t exist but there it is. With 16 x 4TB drives and 4 Thunderbolt ports out the back to connect 4 clients (one of which could be a Mac mini acting as a Xsan 4 controller). That leaves 3 spots for Mac clients for a small editing SAN or post-production workflow. Prices to be revealed soon, I hope. Very interesting for small setups.
In our ongoing quest to use Munki to manage all software, one eventually gets to the realization that Adobe software must be distributed as well. How we do this?
With Adobe CC Team you can use the excellent CCP (creative cloud packaging) tool to make packages with the settings you want (users can or can’t update, importantly).
Once you have all these packages what do you do? Grab Tim Sutton’s “munkiimport_cc_installers.py” script and scan your folder with all your newly created package and you’re on your way.
$ sudo ./munkiimport_cc_installers.py /tmp/CC/ –subdirectory “apps/Adobe/CC/2014” –developer “Adobe” –category “Media”
Password:
Making disk image containing AE-CC2014_Install.pkg…
created: /tmp/munki-3aetVZ/AE-CC2014_Install.dmg
Disk image created at: /tmp/munki-3aetVZ/AE-CC2014_Install.dmg
Making disk image containing AE-CC2014_Uninstall.pkg…
created: /tmp/munki-3aetVZ/AE-CC2014_Uninstall.dmg
Disk image created at: /tmp/munki-3aetVZ/AE-CC2014_Uninstall.dmg
Copying AE-CC2014_Install.dmg to /Users/Shared/munki_repo/pkgs/apps/Adobe/CC/2014/AE-CC2014_Install-13.0.0.dmg…
Copying AE-CC2014_Uninstall.dmg to /Users/Shared/munki_repo/pkgs/apps/Adobe/CC/2014/AE-CC2014_Uninstall-13.0.0.dmg…
Saving pkginfo to /Users/Shared/munki_repo/pkgsinfo/apps/Adobe/CC/2014/AE-CC2014-13.0.0…
Making disk image containing Pho-CC2014_Install.pkg…
created: /tmp/munki-a005sR/Pho-CC2014_Install.dmg
Disk image created at: /tmp/munki-a005sR/Pho-CC2014_Install.dmg
Making disk image containing Pho-CC2014_Uninstall.pkg…
created: /tmp/munki-a005sR/Pho-CC2014_Uninstall.dmg
Disk image created at: /tmp/munki-a005sR/Pho-CC2014_Uninstall.dmg
Copying Pho-CC2014_Install.dmg to /Users/Shared/munki_repo/pkgs/apps/Adobe/CC/2014/Pho-CC2014_Install-15.0.dmg…
Copying Pho-CC2014_Uninstall.dmg to /Users/Shared/munki_repo/pkgs/apps/Adobe/CC/2014/Pho-CC2014_Uninstall-15.0.dmg…
Saving pkginfo to /Users/Shared/munki_repo/pkgsinfo/apps/Adobe/CC/2014/Pho-CC2014-15.0…
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.
This is Part 3 in our series on getting started with Munki. Part 1 covered the basic installation of Munki and the elusive Part 2 covers using Munki Admin and Munki’s Managed Software Centre. Part 3 covers the after you’ve setup Munki, now what part of the deployment. Munki is installed. Software is downloaded via AutoPkg and manifest contain catalog and clients have manifests. But is it working? Do all the Macs have the latest Flash plugin? Do they really? We will cover basic setup of MunkiReport-PHP to show easy it can be to get going.
Note: It’s a good idea to read through the setup notes on the site
Step 2. Rename folder to “report”
Rename the the expanded folder to whatever you like, I shorten it to “report”
Step 3. Drop in Munki_repo folder
To get started quickly drop this folder into your munki repo site folder (which is presumably accessible via the web for client access to Munki).
rename the munkireport folder
Step 4. Change perms of app/db folder
Your set up will fail is the app/db folder is not accessible. Make it writable.
Note: Do not make your site accessible to the outside Internet if you’re not confident in your security model. This is for inside your LAN testing. Be careful and mindful of security concerns. ‘Nough said
MunkiReport app-db-sqlite
If you get this error you haven’t changed the permissions it requires.
MunkiReport errors
Step 5. Rename default_config to config.php
rename the default config php file
Step 6. Enable php for apache
Enable PHP in Apache or other web server service you’re using. Example below is using Server.app
Enable PHP server.app
Step 7. Create user (and hash)
Load up your MunkiReport-PHP site and create a user and hash.
Step 8. Add hash to config.php
Step 9. Download MunkiReport.plist using curl
Download MunkiReport.plist using curl. Note: use an IP address accessible to your Munki clients, i.e. not ‘localhost’
Step 10. Add MunkiReport.plist to pkgsinfo
Add MunkiReport.plist to pkgsinfo
MunkiReport pkgsinfo
Step 11. Import in munki repo
Use munkiimport or MunkiAdmin to import your MunkiReport.plist to Munki
Step 12. Add to client manifest
Add MunkiReport.plist to client manifest using Munki Admin or Munki cli tools
MunkiReport plist installs in MunkiAdmin
Step 13. Add apps to monitor in config.php
Use the apps_to_track model. See also Rsaeks blog post.
A new kind of conference for Mac IT professionals looking to get into DevOps. You’ll hear some about new automation tools, and get a chance to try new things in the computer lab. Join us! Registration limited to 75.
The cost is $99. Food is included on the day of the conference including a light breakfast and lunch. Register here.
Call for Submissions!
MacDevOpsYVR is seeking presenters from across the Pacific Northwest and beyond to participate in this one-day conference for all things Mac!
If you have an idea for a specific talk, workshop or panel related to deploying Macs in enterprise, corporate or educational environments, we want to hear from you.
While awaiting my awesome Part.2 of how to set up Munki we will look at quick fix I made recently to troubleshoot AutoPkgr issues I was having.
I have AutoPkgr set up with several sites as a quick and easy way to get updates of free and licensed software into Munki. Strangely, I ran into an error on my test box, and not on my deployments with clients. So it was something I had done, but what did I do?
AutoPkgr python error
At first I thought that one of the recent updates to AutoPkgr had broken the application. But since it was running correctly elsewhere I had to quickly rule that out. Running the recipes, which looks for new updates of certain applications, kept giving me a python error. How do you troubleshoot this? Re-install Python? De-compile AutoPkgr? Rant on the MacEnterprise maillist? No, that won’t help. 🙂
AutoPkgr is a very nice GUI front end to the excellent AutoPkg project. AutoPkgr installs Git and AutoPkg which are needed. AutoPkgr makes much of the set up much quicker and faster. It’s a great tool. Thanks to the Linde group.
AutoPkgr update dialog
The best way to troubleshoot this issue with AutoPkgr is to see if it is an issue with AutoPkgr. Let’s see if AutoPkg runs at all, and with the same errors. Now there’s an idea. So how do we run AutoPkg? Terminal. Open Terminal.app, and run AutoPkg directly. I always start with a basic “where is the app binary I want?” and then run the app with no options to see if there’s a help menu with an explanation of the switches.
AutoPkg in Terminal
Looking at what Terminal says we now know that AutoPkg is installed in the path /usr/local/bin which is a very accepted place for non-standard (extra, or optional) binaries to live. We also know that “autopkg run all” is not the correct command to run, but it was enough to elicit a better error message. In fact, the problem seems to be a “plist error” with the TextWrangler override recipe. What’s that you might be asking? AutoPkg allows the use of “overrides” which adjust a recipe. In my use of AutoPkg I set an override to add information to a recipe, specifically developer and category information so that Munki’s Managed Software Update app correctly displays the information and the user has a more logically sorted software self-serve portal. In any case, we know from this error that something is wrong with the override. I can run xmllint and clean it, I can open and find the error, or I can just delete this override and re-run AutoPkg to see if we can get somewhere.
AutoPkg transmit
In this example I run AutoPkg with the Transmit recipe and all runs well. Everything is good now. So what’s the lesson here? Be careful with your plist files. When you make your override, and add useful keys, double-check your work to avoid a broken AutoPkg.
