Tag Archives: Autopkgr

New Job, New Server

Adam

If you weren’t aware, when the month changed from June to July, I also changed jobs. I graduated from elementary school to high school. Today was the first day at my new job where I really had time to myself to do what I please. It was time to play with servers.

The school already had a Hyper-V setup, so I installed a copy of Ubuntu and hit the ground running. Once I had the IP setup and SSH enabled, I was ready to go. First thing to install was Docker.

$ wget -qO- https://get.docker.com/ | sh

With that simple command I had Docker running on the server.

For those unaware, Docker is a container system for servers. It allows you to compartmentalize services on a server without the overhead of extra operating systems, like virtualization does. In other words, when you virtualize, you could have 10 virtual servers on one physical machine, all running full copies of Windows. That’s 10 copies of Windows. That’s a lot of overhead. Docker let’s you run on one single OS, sharing resources, but compartmentalizing services.

Once I had my server setup, I had to create a Munki repository. Munki is a program that allows you to easily distribute applications.

I started by creating a data storage container to hold my Munki files. I used this to guide me, https://registry.hub.docker.com/u/macadmins/munki/

$ docker run --name munki-data -v /mnt/docker_data/munki_repo:/munki_repo busybox

Boom, I had a place to store my files, but I needed to get at the files. So I set up an SMB share. This time it takes three lines of code. I’m not inventing anything here, taking generously from here https://registry.hub.docker.com/u/nmcspadden/smb-munki/

$ docker run -d -p 445:445 --volumes-from munki-data --name smb nmcspadden/smb-munki /munki_repo

$ docker exec smb chown -R nobody:nogroup /munki_repo/

$ docker exec smb chmod -R ugo+rwx /munki_repo/

Now I can access my Munki repo through the Finder on my Mac. Now to populate the repo. To do that, I opened up AutoPKGr, pointed it to the new Munki server, and starting running some .munki recipes. There were some new programs I hadn’t used before that I needed to include. Among them were GameSalad and Sonic Pi. There weren’t AutoPKG recipes for them, so I dove in, and now they’re available to the whole community. There’s still a couple titles I need to create recipes for, but I’ll get to that tomorrow.

Next was activating the web server. Munki is just files on a web server. Using Docker to create an Nginx instance shouldn’t be hard, and it’s already been done for Munki. So all I had to was type in:

$ docker run --name munki --rm -p 80:80 --volumes-from munki-data macadmins/munki

Easy peasy, right?

Wrong.

$ sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "http://FQDN/munki_repo"

I, of course, replaced FQDN with the fully qualified domain name. It wasn’t working. Running managedsoftwareupdate on the computer was returning a 404 error. It wasn’t hitting the server properly. What did I do wrong?

After a bit of help from the author of the docker file, I discovered that it’s pointed to http://FQDN/repo, not /munki_repo. D’OH! I could have gone here and seen on the original file that repo is pointing to munki_repo.

But it’s up and running. I could now use Munki to have to client upgraded to OS X 10.10.4, so I can test Yosemite (or Yo, Semite!) in this environment. And that worked like a charm.

That was all I was supposed to do that day, but it was still early. Why not tackle one more job? Let’s set up MunkiReport-PHP!

MR-PHP is a program which lets the client computers report in and give the admin useful data about the state of the fleet. Fantastic! It’s also been Dockerized, so it should be easy. I found it on DockerHub, and I was ready to go…

As you can see from above, my Munki repo is sitting at /mnt/docker_data/munki_repo, so it made sense to put the config file for MR-PHP at /mnt/docker_data/munkireport.

$ sudo mkdir /mnt/docker_data/munkireport

$ cd /mnt/docker_data/munkireport

I needed the config file there.

$ sudo curl -O https://raw.githubusercontent.com/munkireport/munkireport-php/master/config_default.php

$ sudo cp config_default.php config.php

That downloaded the file and copied it, so I had a factory default if needed. I then ran the docker container.

$ docker run -d -v /data/munkireport -v /mnt/docker_data/munkireport/config.php:/app/config.php -p 80:80 macadmins/munkireport-php

Except the ports of 80:80 won’t work! EEK! 80 is in use by Munki. So I ran…

$ docker run -d -v /data/munkireport -v /mnt/docker_data/munkireport/config.php:/app/config.php -p 5000:80 macadmins/munkireport-php

So now I could go to http://FQDN:5000 and generate a password, which I would then throw into the config.php file, along with any other changes I might need to make. Hoorah!

And that’s it, easy peasy lemon squeezy.

Tomorrow I test Yo, Semite!

AutoPKGr

I’ve been using Munki at work for some time. Munki is a system for central management of package installation for OS X computers. It allows end-users to be forced installs from IT, and allows a catalogue of IT-approved installs that end-users can install themselves. It’s really handy.

However, to manually add packages all the time, with constant updates from Google, Mozilla, Adobe, Apple, Evernote, and more and more, all my time would be spent searching for updates. Instead I use a command-line tool called AutoPKG which looks for updates from any program you specify (assuming a recipe has been created), and AutoPKG will download it and install it into your Munki repository.

With the quick command “autopkg run -v Firefox.munki Thunderbird.munki MakeCatalogs.munki”, autopkg will run the Firefox and Thunderbird recipes for Munki and then tell Munki to remake its catalogues.

AutoPKGr is a graphical interface for AutoPKG to make management easier. Instead of having to touch the terminal, I just click off the recipes I want to run and schedule it to run every _ hours. I then give it details to be able to send emails, and I get email notifications of updates.

Screen Shot 2015-02-04 at 11.36.20

I even made a recipe to auto update a package that was missing in the repository. Apparently not enough people use Kobos outside of Canada, and as such, no Kobo recipe was created. I made one!

Recipes have many different functions. For work I mostly just use the .munki one, as it downloads, packages, and imports into Munki. There’s also a recipe format to import into one’s JAMF CasperSuite. We don’t use Casper, as it’s super-expensive, but a fantastic suite. At the core of each recipe is a .download recipe, which just downloads the file. There’s a .pkg recipe which calls the download recipe then packages it. .munki and .jss recipes would just follow the same theme, grabbing from the previous information.

A short while ago, AutoPKG added an .install type. This is what I’m really writing about.

At home I have a computer which I use for classic gaming emulation, and occasional video streaming. If I’m watching CBC’s election coverage on my TV, sadly I can’t get that without a computer. I had an old Mac Mini, so I plugged it into the TV video HDMI, put some classic games on it, and use it to stream video when needed.

During the last provincial election, I found that my Flash was out of date, as my Safari, and Chrome, and Firefox. I needed to update all this software.

Why don’t I automate it?

I installed AutoPKGr. Opened it up, told it run every 24 hours, put in email details so it could report to me. Added the .install recipes for Adobe Flash Player, Firefox, Chrome, Silverlight, and VLC.

Now, once a day, my computer looks to see if any new software is available, and if so, it installs it and emails me to notify me.

I will never again need to anything and have out of date software on this computer.