The video for the talk I gave last week at the Mac Manager Meeting of University of Utah last week is online. You can go and watch it!
Notes for links for the talks, as well as slides are in this previous post.
I hope you like it!
The video for the talk I gave last week at the Mac Manager Meeting of University of Utah last week is online. You can go and watch it!
Notes for links for the talks, as well as slides are in this previous post.
I hope you like it!
These are the links for my presentation at the Marriot Library of the University of Utah. You should soon be able to watch an archived version of the presentation here.
Thanks again for letting me speak and for watching and listening!
Slides for the Presentation (as PDF)
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.
A while back, there was a discussion on Munki-Dev floating the idea of local-only manifests. After some long discussion, the final Pull Request was created and merged. The idea behind local-only ma…
Source: Local-Only Manifests in Munki | OS X Dominion: Mastering OS X Management
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:
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!
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.
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.
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:
git
(added bonus of Spotlight integration and version history)Finally, I will hand the virtual microphone to Rich Trouton, who has (repeatedly) said all of this so much better than I can.