Mac Managers Meeting Presentation

I will be presenting on packaging Wednesday, Jan 18th (update, I had the wrong date here earlier) at the Mac Managers Meeting of the University of Utah. It will be at 1pm Mountain Time (21:00 Central European). Unfortunately, I will not be present but doing the presentation remotely. There will be a live stream and the talk will be archived to view later.

There will be a brief introduction to some basic pkgbuild and autopkg functions and a more detailed look at the new trust functionality in autopkg 1.0. I hope there will remain time for some Q&A.

BBEdit on Sale

The choice of text editor can turn even the most mild-mannered admin into a fearsome crusader.

I do not want to enter these wars, but I do want to point out that my favorite text editor, BBEdit, is on sale right now. Good opportunity to check it out:

BBEdit Winter Sale

Twelvetide, Day 13 (Bonus): Conference

This is the thirteenth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Join the Community”)

Bonus Day! There are many great conferences for Mac admins available right now: (dates are for 2017)

Of course these are great place to learn and watch sessions. Also to meet other admins from many different businesses and schools. Often many of the companies who make software for Mac Administration will have representatives at these conferences showing off their products and available for your questions.

Also these conferences give you a chance to share your knowledge. Most conferences will be very glad for speaker submissions.

Some of these conferences make the session videos and resources available after the conference, these are great resources to watch and learn, even when you do not have the time and money to travel.

(I am sure there are more that I missed, please add them in the comments!)

Also, there are many smaller Mac Admin meetings organised more regularly (or spontaneously) in local groups. The Slack Mac Admin forum can be a great place to find out about these meet-ups!

Twelvetide, Day 12: Join the Community

This is the twelvth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Share and Blog”)

Probably the largest Mac Admin community is the Mac Enterprise mailing list hosted by PSU. This mailing list is mirrored on Google groups if you prefer that interface.

There is also the Freenode IRC # osx-server channel.

However, most of the chat community has moved to the MacAdmins Slack. You can request access to the Slack forum here. You will need the Slack application which is available for Mac and iOS. The Slack forum has several channels for different tools and topics. Slack has a nice help page that’ll introduce to the many options and terms.

My favorite Slack keyboard short cut is “shift-esc” which marks everything as read.

There is also JamfNation. While it obviously focusses on Jamf solutions, it is still a great place to search for generic resources and solutions as well.

Finally, many open source projects have their own mailing lists or forums. For example AutoPkg has a Google group. The Munki project even has two groups: one for general discussion and one for development. Read the project documentation for details. It is often worth searching the group archives for your particular problem before posting and issue against the project.

Twelvetide, Day 11: Share and Blog

This is the eleventh part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Check the Competition”)

Since you are writing all your documentation anyway, some of that is probably very interesting for the wider MacAdmin audience. The best way is to just get a free blog on WordPress or Tumblr or some other free blog service and start writing.

“But, but, but… I want my own domain,” you say! “And my own design!”

If you already have a domain, or know exactly what you want for a domain, then go ahead, get it, install WordPress and start blogging. Otherwise you are overthinking and procrastinating. If a common wordpress blog is good enough for Rich Trouton and Greg Neagle, it is certainly good enough for every one.

Writing post for everybody is a great way to focus your thoughts on a problem and find flaws in your own reasoning. I often stumble over some preconception I have, research it, and then learn a lot while writing up a blog post (or book chapter). A blog post will obviously make your solution available to other admins through a search engine. Also sharing your problem and the solution to it will make it easier for you and other admins to share the solution in emails and forum posts by linking to your excellent post.

A good blog post should have a description of the problem and how and when you encountered it. What you tried to solve the problem (including the more interesting failed attempts) and then your solution. If the code or scripts required to solve the problem are longer you can post them on gist or turn them into a public GitHub repository. You need to remember to remove data from the scripts such as hostnames, user names and passwords before posting, though.

You should also mention the versions of macOS and any other software involved, so that future readers can quickly figure out if this applies to their problem. (Pet peeve of mine: make sure the post date is visible on your blog. I hate it when I read an article and can’t quickly tell how old it is and if it is still relevant.)

You should aim to post regularly to train the habit and your writing skills. However, since most of us have day jobs, ‘once or twice a month’ is a perfectly fine frequency. You can also use your blog to re-post and promote other administrators’ posts.

Most admin bloggers I know put links to their posts on Twitter. For me Twitter has replaced an RSS reader as the main means of getting notified on blog news. It is usually easy to connect your blogging engine to a twitter account (if not, choose another blogging engine). The MacAdmins Slack has a #blog-feeds channel which can notify for new posts.

A blog is also a vanity project. You can and should use it as an asset when you are applying for a new job or position. Of course, you should check with your current employer, on what and how you can blog about your work.

Some blogs worth following: (in no particular order)

This list is obviously far from complete. Feel free to add your blog and your favorite blog to read in the comments.

Twelvetide, Day 10: Write Documentation

This is the tenth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “File Bugs”)

We have all had this this moment when you are trying to figure how to do something you know you have done before, but just cannot remember what the thing was that made it work.

Documenting everything you do, no matter how trivial it may seem at the time is your protection against these moments.

But also, problems will occur, whether you are present or not. If you want to go on an extended vacation trip away from the internet, spend your week-end with your family, or just go home to sleep, you need the basic documentation so co-workers can resolve the most urgent issues without you. The better and more complete your documentation is, the farther and longer you can be away.

If you are working in a team or organisation, you probably have some tool in place, usually a wiki or CMS. You can spend days, weeks and months discussing and choosing the proper tool. Though I am not saying the tool doesn’t matter at all, any tool that is actually being used is better than a tool that is not used.

There are several great tools for personal documentation:

Finally, I will hand the virtual microphone to Rich Trouton, who has (repeatedly) said all of this so much better than I can.

Twelvetide, Day 9: File Bugs

This is the ninth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Check the Competition”)

As Mac administrators we are often very deep in parts of the OS that most other users, even developers and other power users, never touch. We need support for features from a software vendor that is very specialized. Often the vendors themselves do not understand the needs of admins, even Apple.

So we need to let them know about those needs and if necessary educate them. Not just Apple but all software vendors. And this is not just in the software itself but also the deployment workflow (installers).

For Apple the main way to file bugs is bugreport.apple.com, also known as Radar. Since the interface can be a bit cumbersome, there is a nice tool called QuickRadar that will simplify the process. (Rich Trouton has a nice write-up on Quick Radar.)

If you have an Enterprise Support you should also file your bugs through that channel. Talking with your Apple Systems or Consulting Engineer can also help. They may surprise you with a solution, but at the very least they are aware of your issues and have different channels inside the company to make them heard.

Don’t expect quick resolutions. Apple is a big company and macOS a very big and complex project. However, when requests and bug reports pile up from multiple sources and channels, Apple does take notice.

Don’t forget to file bugs with other vendors, too!

Twelvetide, Day 8: Check the Competition

This is the eighth part of a twelve-day series on my new year’s resolutions to become a better Mac admin. During these twelve days my book “Packaging for Apple Administrators” is on sale! (Previous Post: “Open Source”)

When you have your management system running happily it is time to build a new one. There is much to learn by having an alternative management system up and running, even if it never leaves your testing environment. You will have to question and re-analyze many of your scripts, workflows and presumptions. You will become a better sys admin in the process.

Since you built a solid testing environment after Day 3, you can dedicate part of your testing infrastructure to building a second environment for testing an alternative management system.

If you have a commercial management system, then Munki is the obvious choice for an alternative server. If you have Munki running, you can usually get a demo license for one of the commercial servers. Even if you come to the conclusion that the management system you started out with is the best for your setup, you find pieces of your workflow that can be improved while re-building everything in a different way.

This doesn’t just hold for the management system, but also for the imaging system (DeployStudio, Imagr, Casper Imaging etc.) or your packaging tool (Jamf Composer, Packages, pkgbuild, munkipkg) or any other tool really.