Hands on with Imagr

At the recent MacTech conference in Los Angeles I got a chance to sit in a workshop led by Graham Gilbert walking us through his open source imaging tool, Imagr.

This was a perfect follow-up to last year’s awesome demo by Pepijn Bruienne at last year’s MacTech where he demoed his BSDPy netboot replacement running in a Docker container net booting and imaging a new VM in VMWare. Amazing live netboot demo with bonus points for writing your own netboot replacement in Python, stuffing it into a Docker container!

This year, Graham Gilbert led us through setting up BSDPy Docker container, getting the link to VMware working and using his Imagr tool to image a new VM instance of OS X. Fun stuff.

Here are some screenshots:

  1. VMWare booting up looking for NetBoot services
VMWare booting up

VMWare booting up

2. The lovely NetBoot globe spinning

Netboot globe

NetBoot

3. Progress!

Booting up

Booting up

4. Image NetBoot image booted

Netboot image booted, but there’s an issue with the plist I built by hand. Some of the keys and strings got mixed up when copying from the whiteboard. Thanks to Rich Trouton who was sitting next to me who helped me diff his plist with mine to find how I’d messed it up. Easy to fix, slightly tricky to find. Luckily you only have to edit this plist to do initial set up.

Image NetBoot image booted

Image NetBoot image booted

5. Imagr start up

Imagr start up

Imagr start up

6. Imagr starting, password first

Image password

Image password

7. Imagr restoring OS X image

Imagr restoring OS X image

Imagr restoring OS X image

8. Imgr completed workflow

Imgr completed workflow

Imgr completed workflow

9. Shutting docker down

docker down

docker down

Reference:

Graham Gilbert’s blog post with slides of the workshop.

http://grahamgilbert.com/blog/2015/11/12/mactech-2015-hands-on-with-imagr/

Pepijn Bruienne’s blog, Enterprise Mac

http://enterprisemac.bruienne.com

Thoughts on Documentation: What are we afraid of?

People are afraid of documentation… But mostly people just hate it. They don’t like it. They don’t want it. It shouldn’t exist. Fingers in ears. I can’t hear you.

This is about primal fear. And hate. I hate hate. But these are real emotions. Let’s deal with it. What is the reality? Why is documentation is ignored, abandoned, or resisted at all?

As a Sysadmin perhaps you don’t care about documentation, that is, sharing information with others (co workers / bosses), you want to keep it to yourself. But you care very much about building systems. But there’s perhaps no attempt to explain any of this to anyone else. Who else is there really? No one cares. No one is around that would understand if you explained it.

Lesson # 1 – Document for yourself.

Paranoia makes us set up redundant systems for backups. Layers upon layers. Custom scripts and disparate apps. Where was this explained? Documented? Nowhere. Bin dir. Maybe.

If you could replace all that now with one app that did it all then you would. Time is valuable. Easier to monitor. Easier for someone else to monitor and take over.

Lesson # 2 – document for your replacement (job change, bus hit)

Do it continuously. Automate. Or set up systems that work automatically.

Lesson # 3. DevOps.

Integrate systems. IT systems manage computer but maybe they also built Inventory. Automatically. Alert Systems report continuously. Living systems report on the state of everything. Documentation is easier when it is current and relevant.

Lesson # 4. Sustainability

Commercial vs OpenSource. Support vs excellent team, talent retention and documentation. Pro/Con. If your custom solution is not well documented that can be a big problem. If you code is not shared, peer-reviewed, or supported by anyone that could be an issue. If it makes sense to switch to commercial software that is supported then do it. If an OpenSource project or code is supported by a larger community perhaps that makes sense.

Lesson # 5. Improve. Grow. Get better.

Discovery and Documentation lead to suggestions for improvement. Make changes. Code and disparate systems that struggle to be documented make us think about how to replace them or better balance the risks vs cost.

Lesson # 6. Human problems don’t always tech solutions.

Code doesn’t fix broken workflows. Meetings are with people. Talking through systems helps people understand pain points. Don’t forget people want to do their job, meet deadlines, do stuff.

Let’s make their world and our world better.

Love not hate. Peace.

Documentation-MatX